Я обещал запилить FAQ по Data Cooker ETL. Запиливаю. Q. Что это

такое?

A. Специализированный инструмент для а) быстрого создания ETL процессов и б) эффективного по стоимости их выполнения.

Промка: http://dcetl.ru
Исходники: https://github.com/PastorGL/datacooker-etl
Официальная группа в телеге: https://t.me/data_cooker_etl


Q. Что за маркетинговый булшит. Пруфы будут?

A. Да, у меня есть конкретный кейс. Сравнивать будем с реализацией скриптом на pyspark (SQL и датафреймы).

Дано: геолокационные данные от внешнего поставщика в файлах Parquet, выложенные в бакет на S3.
Объём: 1–5 ТБ, загружаются раз в сутки по отдельному префиксу.
Поля: latitude, longitude, user_id, time_stamp, horizontal_accuracy, + ещё ~2 десятка полей, не имеющих значения для рассматриваемого процесса.

Требуется: произвести ingestion по нижеследующему алгоритму.
1. Отфильтровать по полю horizontal_accuracy (исключить не-числовые значения и числовые > 100).
2. Разбить поле time_stamp на компоненты year, month, day, dow, hour, minute со сменой часового пояса на GMT.
3. Посчитать по (latitude; longitude) хеш Uber H3 заданного уровня.
4. Разбить на 2 набора данных по полю dow (1–5 рабочие дни и 6–7 выходные).
5. Результат должен оказаться в другом бакете на S3 в файлах формата TSV.

Написание скрипта для данного процесса на Python заняло 6 часов времени аналитика (вместе с отладкой). Прогон процесса на кластере EMR из 5 нод размера c6i.xlarge занимает в среднем 48 минут, стоимость — 14 $.

Написание SQL скрипта для Data Cooker ETL заняло 47 минут времени аналитика. Прогон на кластере того же размера — 8 минут, стоимость — 1.8 $.

Тестировался процесс на EMR версии 6.9 на 7 прогонах (по данным, поставленным за 1 неделю) в августе 2023 года.

С учётом того, что данный процесс выполняется у нас каждые сутки, и всего таких процессов полтора десятка, то экономия времени и денег на перспективе получается существенная. Причём, у нас они ещё и меняются раз в несколько недель, так что даже на времени разработки большая экономия.


Q. И что это за волшебный SQL такой?

A. Специализированный диалект, заточенный специально только на задачи ETL. У языка есть формальная спецификация — https://pastorgl.github.io/datacooker-etl/TDL4.html

Намеренно не содержит поддержки аналитических и агрегирующих языковых конструкций, подразумевает только итерацию по набору данных целиком, динамическую параметризацию и вызов подключаемых функций. Ещё он умеет в циклы и ветвления, чтобы развесистые процессы писать.


Q. Зачем мне учить какой-то специальный SQL? У меня уже есть Spark SQL и датафреймы.

A. Во-первых, подмножество языка простое и компактное, и ничего особенно учить не нужно. Даже редакторы кода подсвечивают его вполне приемлемо без дополнительной настройки.

Во-вторых, наборы данных в Data Cooker ETL в некоторых аспектах покруче будут, чем датафреймы.


Q. В каком это смысле?

A. В том смысле, что датафрейм — это Dataset[Row], и заточен он конкретно под табличные данные. А DS в датакукере — это коллекция объектов, которые не обязательно соответствуют таблице.

Конкретно, типов 6:
- колоночные (то есть, аналог табличных),
- структурированные (то есть, произвольные объекты, загруженные, к примеру, из JSON),
- непрозрачный / простой текст (то есть, byte[]),
- и ещё три геометрических: точки, полигоны, сегментированные треки.


Q. И что, в Spark SQL тоже есть поддержка JSON полей через функции.

A. А в датакукере поддержка реализована прямо на уровне языка. JSON объект в датакукеровском DS — это объект первого класса, к его свойствам можно напрямую обращаться из SELECT:

SELECT "categories[1:]", "address.city", "contact.email" FROM places INTO places_secondary_cats WHERE "categories[0]" IN $categories AND "categories[1]" IS NOT NULL;

(То же и с сегментированным треком, например. В SELECT можно обратиться к свойствам трека, сегментов, и точек напрямую. Проект, для которого изначально разрабатывался датакукер, геоинформационный, для него это важно.)

не понятно зачем было связываться со schema less если входной файл имеет четкую структуру latitude, longitude, user_id, time_stamp, horizontal_accuracy ну и не понятно зачем сравнивать с каким-то json, если у спарка подержка struct полей

> Все, что ожидается от SQL > Очень знакомый, поэтому удобный > Намеренно не содержит поддержки аналитических и агрегирующих конструкции

1) структура зависит от поставщика, которые меняются как перчатки. и даже в разных поставках от одного и того же она бывает разная 2) полей может быть много, а нужно только несколько. тратить время на описание всех остальных, которые всё равно будут выброшены, не имеет никакого смысла есть смысл заниматься поддержкой схемы в таких условиях, как по вашему? 3) структура внутри поля vs. структурированный объект на верхнем уровне. или вы не понимаете разницу?