Зачем использовать DuckDB в ваших конвейерах данных (при участии Нильса Клэйса)

Описание: Доклад Нильса Клэйса (@Dataminded) на одной из встреч MotherDuck/DuckDB, которая прошла в сентябре в Лёвене, Бельгия.
Спасибо @dataroots за организацию!

☁️🦆 Начните использовать DuckDB в облаке БЕСПЛАТНО с MotherDuck: https://hubs.la/Q02QnFR40

Ссылки Нильса:
Linkedin:   / nielsclaeys  
Medium:   / niels.claeys  

➡️ Подписывайтесь на нас
LinkedIn:   / 8192.  .
Twitter:   / motherduck  
Блог: https://motherduck.com/blog/

#duckdb #motherduckdb #motherduckduckdb #dataengineering

В этой презентации рассматривается использование DuckDB в конвейерах данных как современной и эффективной альтернативы традиционным инструментам проектирования данных. Начнём с описания типичной архитектуры платформы пакетной обработки данных, где данные поступают в озеро данных (например, S3 или хранилище BLOB-объектов Azure) и обрабатываются с помощью Spark для всех задач ETL. Это подготавливает почву для распространённой проблемы: неэффективности использования распределённого движка, такого как Spark, в 80–90% случаев использования данных малого или среднего объёма, определяемого здесь как данные объёмом до 100 ГБ.

Мы предлагаем более эффективный технологический стек, объединяющий DBT и DuckDB, чтобы заменить Spark для большинства рабочих нагрузок по обработке данных. Такой подход позволяет аналитикам данных, владеющим SQL, создавать собственные конвейеры данных, освобождая специализированные команды по разработке данных. DBT привносит в SQL лучшие практики разработки программного обеспечения, такие как модуляризация и документирование, а DuckDB выступает в качестве высокопроизводительного внутрипроцессного SQL-движка, который превосходно выполняет запросы к данным непосредственно из файлов Parquet в озере данных, что делает его идеальным решением для аналитической разработки.

Узнайте о практической реализации с помощью адаптера `dbt-duckdb`, который обеспечивает бесперебойный рабочий процесс. Ключевой особенностью является возможность чтения из внешнего хранилища, что делает DBT с DuckDB готовой заменой существующих заданий Spark без изменения входных и выходных интерфейсов. Эта совместимость обеспечивает постепенную миграцию данных от случая к случаю, предлагая схожий опыт разработки как локально, так и в удаленных средах, таких как Kubernetes.

Наконец, мы подробно рассмотрим сравнение производительности DuckDB, Spark и Trino с использованием набора данных TPCDS объемом 100 ГБ. Результаты показывают, что для данных среднего объема DuckDB значительно быстрее и экономичнее, выполняя более половины запросов до того, как Spark завершит свой первый запрос, благодаря меньшим накладным расходам. Этот анализ подтверждает, что использование DBT с DuckDB является мощным и производительным решением для многих конвейеров данных, оставляя Spark для действительно масштабных или сложных задач обработки.