Let`s try: dbt Частина 1 – пролог

З dbt ми можемо впорядкувати процес трансформації даних у злагоджений конвеєр (pipeline).

dbt — інструмент, добре відомий дата-інженерам та іншим фахівцям, які працюють з даними. То чому ж варто про нього знати?

---

Що таке dbt?

dbt розшифровується як «data build tool». Цей інструмент чудово підходить для трансформації даних у сучасному стеку.

dbt дає змогу керувати процесом трансформації як єдиним упорядкованим потоком. Усі таблиці та view можуть посилатися одне на одне. Реалізувати це можна за допомогою SQL і синтаксису Jinja.

Ось домашня сторінка dbt: getdbt.com

---

Переваги

dbt дозволяє керувати конвеєрами (pipelines) завдяки таким можливостям:

1. для роботи достатньо володіти SQL і Jinja;
2. підтримка багатьох сховищ даних: Snowflake, BigQuery, Redshift, Postgres, DuckDB та інших;
3. скрипти впорядковані в чітку структуру з явними посиланнями між ними, тож супроводжувати потік даних просто й зрозуміло;
4. документація створюється дуже легко;
5. можна реалізовувати функції — macros — для складної логіки та рутинних операцій;
6. доступні для встановлення зовнішні бібліотеки;
7. тести легко створювати й запускати;
8. відкритий код і варіант self-host (dbt core), а також доступний dbt cloud;
9. велика спільнота розробників, готова допомогти.

---

Ключові поняття

У dbt є кілька понять, які варто знати, щоб використовувати інструмент на повну.

Seeds (початкові дані)

Seeds — це файли у форматі CSV. За їх допомогою можна завантажувати невеликі статичні набори даних у сховище.

Sources (джерела)

Sources — це таблиці або view, які вже є у сховищі даних. На них ми посилаємося у своїх моделях.

Джерело описується через:

• database (відповідник project у BigQuery);
• schema (відповідник dataset у BigQuery);
• table (назва таблиці або view).

Models (моделі)

Це одне з базових понять dbt.

Models — це файли із SQL-запитами SELECT. Одна модель відповідає одній таблиці або одному view; за замовчуванням це view, а назва файлу стає назвою таблиці чи view.

У межах одного файлу модель може налаштовувати source, матеріалізацію, макроси та хуки.

Materializations (матеріалізації)

Materializations — це стратегії того, як саме зберігаються та оновлюються моделі. Їх п’ять типів:

1. View
   • Матеріалізація моделі за замовчуванням.
   • Працює як «обгортка», що виконує заданий запит поверх реальних таблиць або інших view.
   • Найкраще підходить для нескладних перетворень: вибір стовпців, перейменування, фільтрація.
2. Table (таблиця)
   • Фізична таблиця для зберігання даних.
   • Перебудовується щоразу, коли запускається модель.
   • Найкраще підходить для тривалих перетворень або важких обчислень.
3. Incremental (інкрементальна)
   • Вставлення або оновлення даних у наявній таблиці.
   • Потребує додаткових налаштувань для логіки insert/update.
   • Найкраще підходить для транзакційних даних або оптимізації часу обробки.
4. Ephemeral (ефемерна)
   • Працює як CTE (Common Table Expression) у SQL.
   • Не створює жодної таблиці чи view, тож напряму зробити з неї вибірку не вийде.
   • Найкраще підходить для простих і проміжних перетворень або підготовки даних.
5. Materialized views
   • Поєднання view і таблиці.
   • Підтримується деякими сховищами: BigQuery, Redshift, Snowflake.
   • Заздалегідь зберігають результат запиту з об’єднаннями, агрегаціями та віконними функціями; можуть періодично оновлюватися.
   • Найкраще підходить для оптимізації продуктивності складних запитів.

Snapshots (знімки)

Snapshots — це моделі, що зберігають історію записів таблиці. За їх допомогою можна відстежувати зміни у вихідних даних із часом.

Macros (макроси)

Macros — це функції, написані на Jinja. Вони стають у пригоді для складної логіки та рутинних операцій.

Наприклад:

• макрос, який обчислює найновішу мітку часу в таблиці, щоб запустити інкрементальні моделі;
• макрос, який додає записи про запуск до таблиці логів.

Hooks (хуки)

Hooks — це SQL-інструкції, які виконуються до або після запуску моделей. Їх використовують, щоб підготувати середовище чи прибрати за собою ресурси.

Analyses (аналізи)

Analyses — це файли із запитами SELECT, схожі на моделі, але вони не є частиною потоку трансформації. Придатні для ad-hoc запитів і дослідження даних.

Tests (тести)

dbt пропонує два види тестів:

1. Загальні (generic) тести
   • Іноді їх називають schema-тестами.
   • Це наперед визначені перевірки: unique, not_null, accepted_values, relationships та інші.
   • Налаштовуються у YAML-файлі.
2. Одиничні (singular) тести
   • Іноді їх називають data-тестами.
   • Це власні SQL-запити SELECT; тест вважається пройденим, якщо запит не повертає жодного рядка.
   • Створюються у SQL-файлі всередині каталогу tests.

Jinja

dbt працює в середовищі Python, використовує SQL для запитів трансформації даних і Jinja — для керування потоком, оголошення змінних, виклику макросів тощо.

Про Jinja детальніше в окремій статті автора: Let’s try: Jinja2

Packages (пакети)

Пакети — це зовнішні бібліотеки, які розширюють можливості dbt. Багато з них доступні в dbt Hub.

---

Ось і все для першого розділу нової серії про dbt. Далі буде.

---

Джерела

• Materializations | dbt Developer Hub
• CTE in SQL — GeeksforGeeks
• dbt snapshot Command: Strategies & Examples — PopSQL
• Model Materializations | Paradime Help Docs
• Optimizing Materialized Views with dbt | dbt Developer Blog

---

ОРИГІНАЛ СТАТТІ: Let’s try: dbt part 1 – prologue
АВТОР СТАТТІ: bluebirz

Оригінал опубліковано під ліцензією CC BY 4.0. Цей матеріал є перекладом українською мовою.

---

Доєднуйтесь до наших спільнот 👇

• Telegram
• Facebook
• X
• Threads