Я знаю, что оба выполняются в столбце таблицы, но как каждая операция отличается.
В чем разница между разделением и балансировкой таблицы в Hive?
Ответ 1
Данные разбиения часто используются для распределения нагрузки по горизонтали, это имеет преимущество в производительности и помогает в организации данных логически. Пример: если мы имеем дело с большой таблицей employee и часто запускаем запросы с предложениями WHERE, которые ограничивают результаты в определенной стране или отделе. Для более быстрого запроса ответа таблица Hive может быть PARTITIONED BY (country STRING, DEPT STRING). Таблицы разделов изменяют, как Hive структурирует хранилище данных, а Hive теперь создает подкаталоги, отражающие структуру разбиения, такие как
.../сотрудники/страны = ABC/DEPT = XYZ.
Если лимит запросов для сотрудника из country=ABC, он будет сканировать только содержимое одного каталога country=ABC. Это может значительно повысить производительность запросов, но только в том случае, если схема разделения отражает общую фильтрацию. Функция разбиения на разделы очень полезна в Hive, однако дизайн, который создает слишком много разделов, может оптимизировать некоторые запросы, но быть вредным для других важных запросов. Другим недостатком является то, что слишком много разделов - это большое количество файлов и каталогов Hadoop, которые создаются без необходимости и накладных расходов для NameNode, поскольку он должен хранить все метаданные для файловой системы в памяти.
Bucketing - еще один способ разложения наборов данных в более управляемые части. Например, предположим, что таблица с использованием date в качестве раздела верхнего уровня и employee_id, поскольку раздел второго уровня приводит к слишком большому количеству небольших разделов. Вместо этого, если мы ведем таблицу employee и используем employee_id в качестве столбца bucketing, значение этого столбца будет хэшироваться с помощью определенного пользователем числа в ковши. Записи с тем же employee_id всегда будут храниться в одном ведре. Предполагая, что число employee_id намного больше, чем количество ведер, в каждом ковше будет много employee_id. При создании таблицы вы можете указать как CLUSTERED BY (employee_id) INTO XX BUCKETS;, где XX - количество ковшей. Букинг имеет ряд преимуществ. Количество ведер фиксировано, поэтому оно не колеблется с данными. Если две таблицы заключены в ведомости employee_id, Hive может создать логически правильную выборку. Bucketing также помогает в эффективном объединении карт и т.д.
Ответ 2
В предыдущих объяснениях отсутствуют некоторые детали. Чтобы лучше понять, как работает секционирование и группирование, вам следует посмотреть, как данные хранятся в кусте. Допустим, у вас есть стол
CREATE TABLE mytable (
name string,
city string,
employee_id int )
PARTITIONED BY (year STRING, month STRING, day STRING)
CLUSTERED BY (employee_id) INTO 256 BUCKETS
тогда куст будет хранить данные в иерархии каталогов, как
/user/hive/warehouse/mytable/y=2015/m=12/d=02
Итак, вы должны быть осторожны при разделении, потому что, если вы, например, разделите по employee_id, и у вас есть миллионы сотрудников, в вашей файловой системе будут миллионы каталогов. Термин "мощность" относится к числу возможных значений поля может иметь. Например, если у вас есть поле "страна", стран в мире около 300, поэтому количество элементов будет ~ 300. Для поля типа timestamp_ms, которое меняется каждую миллисекунду, количество элементов может составлять миллиарды. В целом, при выборе поля для разбиения оно не должно иметь большой мощности, потому что в вашей файловой системе будет слишком много каталогов.
С другой стороны, кластеризация, известная как группирование, приведет к фиксированному количеству файлов, поскольку вы указываете количество сегментов. Что улей сделает, так это возьмет поле, вычислит хеш и назначит запись этому сегменту. Но что произойдет, если вы используете, скажем, 256 сегментов, а поле, в котором вы формируете пакет, имеет низкую мощность (например, это штат США, поэтому может быть только 50 различных значений)? У вас будет 50 блоков с данными и 206 блоков без данных.
Кто-то уже упоминал, как разделы могут существенно сократить объем запрашиваемых данных. Так что в моей таблице примеров, если вы хотите делать запросы только с определенной даты вперед, разделение по годам/месяцам/дням значительно сократит количество операций ввода-вывода. Я думаю, что кто-то также упомянул, как группирование может ускорить объединение с другими таблицами, которые имеют точно такое же распределение, поэтому в моем примере, если вы объединяете две таблицы с одним employee_id, куст может выполнять объединение за сегментом (еще лучше если они уже отсортированы по employee_id, так как они собираются для сортировки частей, которые уже отсортированы, что работает за линейное время, иначе O (n)).
Таким образом, группирование хорошо работает, когда поле имеет высокую мощность и данные равномерно распределяются по сегментам. Разделение работает лучше всего, когда количество элементов в поле разделения не слишком велико.
Кроме того, вы можете разбивать на несколько полей с порядком (год/месяц/день - хороший пример), в то время как вы можете использовать только одно поле.
Ответ 3
Я думаю, что опаздываю, отвечая на этот вопрос, но он продолжает подниматься в моем канале.
Navneet предоставил отличный ответ. Добавление к нему визуально.
Разделение помогает в устранении данных, если они используются в предложении WHERE, где, поскольку bucketing помогает в организации данных в каждом разделе на несколько файлов, так как один и тот же набор данных всегда записывается в том же ведро. Помогает в объединении столбцов.
Предположим, у вас есть таблица с пятью столбцами, именем, server_date, some_col3, some_col4 и some_col5. Предположим, вы разделили таблицу на server_date и разделили на столбец имен в 10 ведрах, ваша файловая структура будет выглядеть примерно так.
- server_date = хуг
- 00000_0
- 00001_0
- 00002_0
- ........
- 00010_0
Здесь server_date = xyz - это раздел, а 000 файлов - это ведра в каждом разделе. Ведра вычисляются на основе некоторых хеш-функций, поэтому строки с именем = Сэнди всегда будут в одном ковше.
Ответ 4
Разделение кустов:
Разделение разделяет большой объем данных на несколько срезов на основе значения столбца (ов) таблицы.
Предположим, что вы храните информацию о людях во всем мире, распространяющихся по странам с более чем 50-кратным числом. Если вы хотите запросить людей из той или иной страны (города Ватикана), в отсутствие разделения, вам нужно отсканировать все 500 кролов записей, даже чтобы получить тысячи записей в стране. Если вы разбиваете таблицу на основе страны, вы можете настроить процесс запроса, просто проверив данные только для одного раздела страны. Раздел Hive создает отдельный каталог для значения столбца (ов).
Плюсы:
- Распределить нагрузку выполнения по горизонтали
- Более быстрое выполнение запросов в случае раздела с низким объемом данных. например Получить население из " города Ватикана" очень быстро возвращается, а не ищет целую популяцию мира.
Минусы:
- Возможность слишком большого количества небольших созданий разделов - слишком много каталогов.
- Эффективно для данных с низким объемом для данного раздела. Но некоторые запросы, такие как группа на большом объеме данных, все еще требуют много времени для выполнения. например Группировка населения Китая займет много времени по сравнению с группировкой населения в Ватикане. Раздел не решает проблему отзывчивости в случае перекоса данных в сторону определенного значения раздела.
Bucketing для улья:
Bucketing разлагает данные на более управляемые или равные части.
При разбиении на разделы существует возможность создания нескольких небольших разделов на основе значений столбцов. Если вы идете на bucketing, вы ограничиваете количество ведер для хранения данных. Этот номер определяется в сценариях создания таблицы.
Pros
- Из-за равных объемов данных в каждом разделе соединения на стороне карты будут быстрее.
- Быстрая реакция на запрос, как разметка
против
- Вы можете определить количество ковшей во время создания таблицы, но загрузка одинакового объема данных должна выполняться программистами вручную.
Ответ 5
Разница bucketing делит файлы по имени столбца, а разбиение на разделы делит файлы под определенным значением внутри таблицы
Надеюсь, я правильно определил его
Ответ 6
Прежде чем перейти к Bucketing, мы должны понять, что такое Partitioning. Давайте возьмем приведенную ниже таблицу в качестве примера. Обратите внимание, что я дал только 12 записей в приведенном ниже примере для понимания уровня начинающих. В сценариях реального времени вы можете иметь миллионы записей.
PARTITIONING
--------------------- Partitioning используется для получения производительности при запросе данных. Например, в приведенной выше таблице, если мы напишем приведенный ниже sql, необходимо просканировать все записи в таблице, что снижает производительность и увеличивает накладные расходы.
select * from sales_table where product_id='P1'
Чтобы избежать полного сканирования таблицы и прочитать только записи, относящиеся к product_id='P1' мы можем разделить (разбить файлы таблицы кустов) на несколько файлов на основе столбца product_id. Таким образом, файл таблицы кустов будет разделен на два файла: один с product_id='P1' а другой с product_id='P2'. Теперь, когда мы выполним вышеуказанный запрос, он будет сканировать только файл product_id='P1'.
../hive/warehouse/sales_table/product_id=P1
../hive/warehouse/sales_table/product_id=P2
Синтаксис для создания раздела приведен ниже. Обратите внимание, что мы не должны использовать определение столбца product_id вместе с неразделенными столбцами в приведенном ниже синтаксисе. Это должно быть только в partitioned by.
create table sales_table(sales_id int,trans_date date, amount int)
partitioned by (product_id varchar(10))
Минусы: мы должны быть очень осторожны при разделении. То есть его не следует использовать для столбцов, в которых количество повторяющихся значений очень мало (особенно для столбцов первичного ключа), так как это увеличивает количество разбитых на разделы файлов и увеличивает накладные расходы для Name node.
BUCKETING
------------------ Bucketing используется для преодоления cons которые я упомянул в разделе разбиения. Это следует использовать, когда в столбце очень мало повторяющихся значений (пример - столбец первичного ключа). Это похоже на концепцию индекса для столбца первичного ключа в РСУБД. В нашей таблице мы можем взять столбец Sales_Id для группирования. Это будет полезно, когда нам нужно запросить столбец sales_id.
Ниже приведен синтаксис для группирования.
create table sales_table(sales_id int,trans_date date, amount int)
partitioned by (product_id varchar(10)) Clustered by(Sales_Id) into 3 buckets
Здесь мы далее разделим данные на несколько файлов поверх разделов.
Поскольку мы указали 3 сегмента, он разделен на 3 файла для каждого product_id. Он внутренне использует modulo operator по modulo operator чтобы определить, в каком sales_id должен храниться каждый sales_id. Например, для product_id='P1' sales_id=1 будет сохранен в файле 000001_0 (т. Е. 1% 3 = 1), sales_id=2 будет сохранен в файле 000002_0 (т. Е. 2% 3 = 2), sales_id=3 будет сохранен в файле 000000_0 (т.е. 3% 3 = 0) и т.д.
Ответ 7
Здесь есть отличные отзывы. Я хотел бы быть кратким, чтобы запомнить разницу между разделами и сегментами.
Вы обычно делите раздел на менее уникальный столбец. И ведро на самой уникальной колонне.
Пример, если вы рассматриваете население мира с указанием страны, имени человека и его биометрического идентификатора в качестве примера. Как вы можете догадаться, поле страны будет менее уникальным столбцом, а биометрический идентификатор будет самым уникальным столбцом. Так что в идеале вам нужно разделить таблицу по странам и объединить ее по биометрическому идентификатору.
Ответ 8
Использование разделов в таблице Hive настоятельно рекомендуется по основным причинам -
Вставка в таблицу Hive должна выполняться быстрее (поскольку для записи данных в разделы используются несколько потоков) Запрос из таблицы Hive должен быть эффективным с низкой задержкой.
Пример :-
Предположим, что входной файл (100 ГБ) загружен во временную таблицу и содержит банковские данные из разных регионов.
Улей стол без перегородок
Insert into Hive table Select * from temp-hive-table
/hive-table-path/part-00000-1 (part size ~ hdfs block size)
/hive-table-path/part-00000-2
....
/hive-table-path/part-00000-n
Проблема этого подхода заключается в том, что он будет сканировать все данные для любого запроса, который вы выполняете в этой таблице. Время отклика будет высоким по сравнению с другими подходами, где используются разбиение на разделы и группирование.
Улей стол с перегородкой
Insert into Hive table partition(country) Select * from temp-hive-table
/hive-table-path/country=US/part-00000-1 (file size ~ 10 GB)
/hive-table-path/country=Canada/part-00000-2 (file size ~ 20 GB)
....
/hive-table-path/country=UK/part-00000-n (file size ~ 5 GB)
Плюсы - здесь можно получить доступ к данным быстрее, когда речь идет о запросе данных для определенных географических транзакций. Минусы - вставка/запрос данных могут быть улучшены путем разделения данных в каждом разделе. См. Вариант Bucketing ниже.
Улейный стол с перегородкой и ковшом
Примечание: Создайте таблицу кустов..... с "CLUSTERED BY (Partiton_Column) в 5 сегментов
Insert into Hive table partition(country) Select * from temp-hive-table
/hive-table-path/country=US/part-00000-1 (file size ~ 2 GB)
/hive-table-path/country=US/part-00000-2 (file size ~ 2 GB)
/hive-table-path/country=US/part-00000-3 (file size ~ 2 GB)
/hive-table-path/country=US/part-00000-4 (file size ~ 2 GB)
/hive-table-path/country=US/part-00000-5 (file size ~ 2 GB)
/hive-table-path/country=Canada/part-00000-1 (file size ~ 4 GB)
/hive-table-path/country=Canada/part-00000-2 (file size ~ 4 GB)
/hive-table-path/country=Canada/part-00000-3 (file size ~ 4 GB)
/hive-table-path/country=Canada/part-00000-4 (file size ~ 4 GB)
/hive-table-path/country=Canada/part-00000-5 (file size ~ 4 GB)
....
/hive-table-path/country=UK/part-00000-1 (file size ~ 1 GB)
/hive-table-path/country=UK/part-00000-2 (file size ~ 1 GB)
/hive-table-path/country=UK/part-00000-3 (file size ~ 1 GB)
/hive-table-path/country=UK/part-00000-4 (file size ~ 1 GB)
/hive-table-path/country=UK/part-00000-5 (file size ~ 1 GB)
Плюсы - Быстрая вставка. Быстрый запрос.
Минусы - Bucketing будет создавать больше файлов. В некоторых случаях может возникнуть проблема со многими небольшими файлами.
Надеюсь, это поможет!
Ответ 9
Разделы: Разделы - это в основном горизонтальные срезы данных, которые позволяют сегментировать большую часть данных на более управляемые куски.
CREATE TABLE customer (
id INT,
name STRING,
address1 STRING )PARTITION BY (REGION STRING,country STRING );
Поддерживаются множественные "слайсер" или столбцы разбиения (т.е. регион/страна).
Для разницы между разбиением и балансировкой таблицы в Hive эта ссылка