Сообщение Re[20]: [Ref] Почему не смогли применить готовое решение для от 30.09.2022 13:20
Изменено 30.09.2022 13:26 Shmj
Re[20]: [Ref] Почему не смогли применить готовое решение для
Здравствуйте, Gt_, Вы писали:
Gt_>ну в нашей задачи еще вторая колонка с цифрами есть, она поможет шафлу раскидать на партиции.
А как ваш шафл решает как раскидывать, какие данные для этого использовать?
Gt_а вот если обе колонки одинаковы, да, шафл у spark 2.4 просто все отправит в одну партицию и OM гарантирован.
И даже если буквы разные, но данных, к примеру, 260 Гб. — на одну букву около 10 Гб. при равномерном, но если слова словарные — то может быть и 30 Гб. на какую-либо из букв. И все — тот же привет.
По этому и нужно точно знать как оно работает и можете ли вы этим управлять.
Gt_>классический подход к борьбе с перекосами данных — подсовывать свою соль. генерируется левая колонка с рандомными значениями и она помогает шафлингу раскидывать более равномерно. вроде в вышедшем пару лет назад spark3 это уже автоматом делается.
Будет ошибка в данных — это все равно что разбить на части без учета содержимого, потом отсортировать каждую часть, потом склеить на основе порядка, в котором происходила разбивка.
Вот в этом и проблема — вы не знаете что вы делаете и когда это применимо а когда нет.
Gt_>ну в нашей задачи еще вторая колонка с цифрами есть, она поможет шафлу раскидать на партиции.
А как ваш шафл решает как раскидывать, какие данные для этого использовать?
Gt_а вот если обе колонки одинаковы, да, шафл у spark 2.4 просто все отправит в одну партицию и OM гарантирован.
И даже если буквы разные, но данных, к примеру, 260 Гб. — на одну букву около 10 Гб. при равномерном, но если слова словарные — то может быть и 30 Гб. на какую-либо из букв. И все — тот же привет.
По этому и нужно точно знать как оно работает и можете ли вы этим управлять.
Gt_>классический подход к борьбе с перекосами данных — подсовывать свою соль. генерируется левая колонка с рандомными значениями и она помогает шафлингу раскидывать более равномерно. вроде в вышедшем пару лет назад spark3 это уже автоматом делается.
Будет ошибка в данных — это все равно что разбить на части без учета содержимого, потом отсортировать каждую часть, потом склеить на основе порядка, в котором происходила разбивка.
Вот в этом и проблема — вы не знаете что вы делаете и когда это применимо а когда нет.
Re[20]: [Ref] Почему не смогли применить готовое решение для
Здравствуйте, Gt_, Вы писали:
Gt_>ну в нашей задачи еще вторая колонка с цифрами есть, она поможет шафлу раскидать на партиции.
А как ваш шафл решает как раскидывать, какие данные для этого использовать?
Gt_>а вот если обе колонки одинаковы, да, шафл у spark 2.4 просто все отправит в одну партицию и OM гарантирован.
И даже если буквы разные, но данных, к примеру, 260 Гб. — на одну букву около 10 Гб. при равномерном, но если слова словарные — то может быть и 30 Гб. на какую-либо из букв. И все — тот же привет.
По этому и нужно точно знать как оно работает и можете ли вы этим управлять.
Gt_>классический подход к борьбе с перекосами данных — подсовывать свою соль. генерируется левая колонка с рандомными значениями и она помогает шафлингу раскидывать более равномерно. вроде в вышедшем пару лет назад spark3 это уже автоматом делается.
Будет ошибка в данных — это все равно что разбить на части без учета содержимого, потом отсортировать каждую часть, потом склеить на основе порядка, в котором происходила разбивка.
Вот в этом и проблема — вы не знаете что вы делаете и когда это применимо а когда нет.
Gt_>ну в нашей задачи еще вторая колонка с цифрами есть, она поможет шафлу раскидать на партиции.
А как ваш шафл решает как раскидывать, какие данные для этого использовать?
Gt_>а вот если обе колонки одинаковы, да, шафл у spark 2.4 просто все отправит в одну партицию и OM гарантирован.
И даже если буквы разные, но данных, к примеру, 260 Гб. — на одну букву около 10 Гб. при равномерном, но если слова словарные — то может быть и 30 Гб. на какую-либо из букв. И все — тот же привет.
По этому и нужно точно знать как оно работает и можете ли вы этим управлять.
Gt_>классический подход к борьбе с перекосами данных — подсовывать свою соль. генерируется левая колонка с рандомными значениями и она помогает шафлингу раскидывать более равномерно. вроде в вышедшем пару лет назад spark3 это уже автоматом делается.
Будет ошибка в данных — это все равно что разбить на части без учета содержимого, потом отсортировать каждую часть, потом склеить на основе порядка, в котором происходила разбивка.
Вот в этом и проблема — вы не знаете что вы делаете и когда это применимо а когда нет.