Свежий инструмент Amphi для визуальных ETL процессов, с low-code проектированием труб данных (data pipelines) через интерфейс в Jupyter lab

Из плюсов:
- low code
- не cloud-first
- базовый набор для обработки структурированных и неструктурированных данных
- всё можно делать в UI прямо в Jupyter Lab
- открытый код

Из минусов:
- low-code (для кого-то минус)
- не cloud-first (для кого-то минус)
- мало разнообразия в источниках получения данных
- лицензия Elastic, недоопенсорс

Мне чем-то напомнило Apache Nifi, но только отчасти.

Интеграция в Jupyter Lab - хорошо,но пока что и в целом надо приглядется. Продукт явно сделан пока скорее для инвесторов чем для пользователей, но без пользователей и инвестиций не будет.

В целом из разработки дата инструментов мне нравятся не только продукты, но и команды Clickhouse и Duckdb.

Хочется дождаться ETL сделанное по аналогии с Duckdb. Удобным ядром и большим числом хорошо написанных расширений. Какое-то время назад мне казалось что Meltano на эту роль подходит, но с тех пор как они отдали свои публичные ресурсы довольно хреновым маркетологам читать их стало тяжело. Развитие продукта сложно оценивать.

#etl #opensource #datatools

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

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

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

А в случае индикаторов, хорошие владельцы таких баз данных всё чаще дают возможность выкачать их целиком в режиме bulk download. Как минимум это ECB, Eurostat, FAO, Ilostat и ещё многие. Данные там почти всегда CSV или сжатые CSV и вот тут то срабатывает магия инструментов вроде duckdb. Во всех ситуациях когда CSVшки в кодировке utf8 и имеют предсказуемые схемы данных, с помощью duckdb можно многократно ускорять их обработку заменяя обработку через датафреймы на прямые SQL запросы к CSV, даже без копирования данных в БД и не строя ни одного индекса.

В общем могу сказать что в роли "дешёвого ETL инструмента для бедных" duckdb работает прекрасно. К примеру DISTINCT по разреженному полю по CSV файлу в 15GB и 22 миллиона записей без индекса отрабатывается на 19.8 секунд. Это в режиме когда совсем без оптимизаций, без преобразований в parquet. А если в parquet преобразовать то, ожидаемо, DISTINCT отрабатывает за 0.5 секунд. Выбор очевиден 🛠 надо использовать!

Например, про данные из другого проекта, если кто-то надумает использовать данные по госконтрактам [1], то они вполне себе читаются с помощью duckdb особенно после преобразований в parquet. Например, jsonl файл с госзаказчиками вполне себе легко преобразуется в parquet после всего операции по преобразованиям занимают сотые доли секунд. В этом смысле единственный недостаток открытых данных из Госзатрат только в том что они сжаты в zip, а если сжать их в gz или публиковать в parquet, то можно ещё и ускорить подготовку данных.

Таких примеров много, главный вывод в том что можно удешевить ресурсные требования во многих задачах и многие R&D задачи решать без дополнительных серверных ресурсов, экспериментируя локально.

Ссылки:
[1] https://clearspending.ru/opendata/

#duckdb #tech #dataengineering #etl