У нас есть следующий сценарий:
- У нас есть существующая таблица, содержащая ок.15 миллиардов записей.Он не был явно разделен при создании.
- Мы создаем копию этой таблицы с разделами, надеясь на более быстрое время чтения для определенных типов запросов.
- Наши таблицы находятся в облаке Databricks Cloud, имы используем Databricks Delta.
- Обычно мы фильтруем по двум столбцам, один из которых является идентификатором сущности (350 000 различных значений), а один - датой, когда произошло событие (на данный момент 31 отдельное значение)., но увеличивается с каждым днем!).
Итак, при создании нашей новой таблицы мы запустили такой запрос:
CREATE TABLE the_new_table
USING DELTA
PARTITIONED BY (entity_id, date)
AS SELECT
entity_id,
another_id,
from_unixtime(timestamp) AS timestamp,
CAST(from_unixtime(timestamp) AS DATE) AS date
FROM the_old_table
Этот запрос выполнялся в течение 48 часов и подсчитывал,Мы знаем, что он делает успехи, потому что мы нашли около 250 тыс. Префиксов, соответствующих первому ключу раздела в соответствующем префиксе S3, и, конечно, в префиксах существуют большие файлы.
Однако мы 'У нас возникли некоторые трудности с отслеживанием того, сколько именно прогресса было достигнуто и как долго мы можем ожидать, что это займет.
Пока мы ждали, мы опробовали такой запрос:
CREATE TABLE a_test_table (
entity_id STRING,
another_id STRING,
timestamp TIMESTAMP,
date DATE
)
USING DELTA
PARTITIONED BY (date);
INSERT INTO a_test_table
SELECT
entity_id,
another_id,
from_unixtime(timestamp) AS timestamp,
CAST(from_unixtime(timestamp) AS DATE) AS date
FROM the_old_table
WHERE CAST(from_unixtime(timestamp) AS DATE) = '2018-12-01'
Обратите внимание, что главное отличие в схеме новой таблицы заключается в том, что мы разбили раздел только на дату, а не на идентификатор объекта.Выбранная нами дата содержит почти ровно четыре процента данных старой таблицы, на которые я хочу указать, потому что она намного больше 1/31.Конечно, поскольку мы выбираем по единственному значению, которое оказывается тем же самым, на которое мы разбили раздел, мы фактически пишем только один раздел, по сравнению с, вероятно, сотнями тысяч или около того.
Создание этоготестовая таблица заняла 16 минут с использованием того же количества рабочих узлов, поэтому мы ожидаем (исходя из этого), что создание таблицы в 25 раз больше займет около 7 часов .
Этот ответ , по-видимому, частично подтверждает, что использование слишком большого количества разделов может вызвать проблему, но основные причины, по-видимому, сильно изменились за последние пару лет, поэтому мы стремимся понять, какими могут быть текущие проблемы;документы Databricks не были особенно освещены.
На основании опубликованных рекомендаций по скорости запросов для S3 кажется, что увеличение количества разделов (ключевых префиксов) должно улучшить производительность.Пагубные разделы кажутся нелогичными.
В итоге: мы ожидаем записать тысячи записей в каждый из тысяч разделов.Похоже, что сокращение количества разделов значительно сокращает время, необходимое для записи данных таблицы.Почему это так?Существуют ли общие рекомендации по количеству разделов, которые должны быть созданы для данных определенного размера?