Без Iceberg пришлось бы читать все Parquet-файлы, а это сотни мегабайт и гигабайт данных. С Iceberg читаем только метаданные: а это уже всего лишь килобайты данных. В 100 раз меньше I/O только на этапе планирования запроса. Плюс читаются только нужные Parquet-файлы, никакого бродкаста по всем директориям и листинга.
При подсчете count, min, max в паркетах без айсберга так же будут читаться только метаданные при определенном наборе параметров читателя. Выигрыш только в том, что не будет полного листинга
Значит, нам, как промежуточному звену, в процессе надо порезать датасет как минимум по широте+долготе (наложив некий фенсинг для каждого из целевых муниципалитетов), и потом ещё по дням недели (либо по каждому по отдельности, либо по рабочим/выходным) + почасовые интервалы. «Как минимум», потому что некоторые клиенты хотят ещё сильнее раздробить данные, вплоть до первой буквы хеша ID пользователя (который представляет из себя 16-ричную строку), или наложить ещё какие-нибудь особенные способы разбиения.
А результат этого где будет храниться?
Если нужна другая порция, вам придётся опять материализовать датасет, выдернуть другую порцию, записать, потом прочитать её с диска заново, и т.д. — каждую по отдельности, но в общем случае у вас многократно пересчитывается весь датасет.
Датасет уже записан с партицироваем, для получения нужной порции достаточно прочитать нужные партиции
Спасибо за столь интересную статью! Такую проблему я решал с использованием dataframe api df.repartition(keys).write.partitionBy(keys). Чем этот подход уступает подходу, описанному в статье?
@SacredDiablo, спасибо за статью! Показалось, что не раскрыты понятия "Гибкое определение" и "предрасчет".
Как я понял, Гибкое определение + repartition это об этом:
// Получение списка файлов и определение конфигурации
// Определение объема данных
val perfectBlockSize = 256 * 1024 * 1024
val repartitionCount = tableSize / perfectBlockSize
но информацию про остальные столбцы на этом изображении я не увидел:
При подсчете count, min, max в паркетах без айсберга так же будут читаться только метаданные при определенном наборе параметров читателя. Выигрыш только в том, что не будет полного листинга
А результат этого где будет храниться?
Датасет уже записан с партицироваем, для получения нужной порции достаточно прочитать нужные партиции
Ознакомился с исходниками версии 3.2, ничего общего в подходом 1 не увидел. Вы сами читали?
Спасибо за столь интересную статью! Такую проблему я решал с использованием dataframe api df.repartition(keys).write.partitionBy(keys). Чем этот подход уступает подходу, описанному в статье?
Спасибо за ответ!
@SacredDiablo, спасибо за статью! Показалось, что не раскрыты понятия "Гибкое определение" и "предрасчет".
Как я понял, Гибкое определение + repartition это об этом:
но информацию про остальные столбцы на этом изображении я не увидел: