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

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

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

Що таке dbt?

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

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

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

Переваги

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

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

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

У 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 — це стратегії того, як саме зберігаються та оновлюються моделі. Їх п’ять типів:

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

Snapshots (знімки)

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

Macros (макроси)

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

Наприклад:

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

Hooks (хуки)

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

Analyses (аналізи)

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

Tests (тести)

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

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

Jinja

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

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

Packages (пакети)

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

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

Джерела

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

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

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

+Список статей: