Вступ
Як консультант з даних, один з моїх головних обов'язків - запропонувати найкращу архітектуру даних для наших клієнтів. Критично важливим компонентом цієї архітектури є рівень трансформації.
До запуску Dataform вибір інструменту трансформації був відносно простим - Dbt зазвичай був найбільш гідним вибором для більшості проєктів.
Однак після того, як Dataform став загальнодоступним на початку 2023 року, прийняття рішення стало більш складним, особливо для клієнтів, які вже використовують екосистему GCP.
Функціональні можливості та механізми Dataform дуже схожі на Dbt. Крім того, Dataform пропонує деякі функції, які присутні як в Dbt Core, так і в Dbt Cloud, безкоштовно, що робить його кращим і дешевшим варіантом на перший погляд.
Але чи дійсно він кращий?
Щоб з'ясувати це, я вирішив використовувати Dataform для всіх завдань, пов'язаних з типовим життєвим циклом коду, таких як розробка коду в локальному середовищі, проходження процесу рецензування, розгортання коду у виробництво, його підтримка та усунення будь-яких помилок.
➡️ Основними цілями були остерігатися будь-яких потенційних пасток з Dataform та провести справедливе порівняння між Dataform та Dbt.
Наступний огляд базується на шести основних аспектах:
- 1. Розробка: функції, які допомагають інженерам розробляти моделі даних у середовищі розробки.
- 2. Співпраця: функції, які допомагають інженерам співпрацювати один з одним, наприклад, контроль версій.
- 3. Розгортання: функції для планування побудови моделей у виробничому середовищі та налаштування робочого процесу CI/CD.
- 4. Управління: функції, пов'язані з управлінням даними, включаючи тестування даних, документацію, родовід та метадані.
- 5. Інтеграція: наскільки легко Dataform може інтегруватися з іншими інструментами обробки даних.
- 6. Вартість платформи
⚔️ Відмова від відповідальності 1: Будь ласка, зверніть увагу, що всі функції, описані в цьому блозі, описані станом на березень 2024 року.
⚔️ Застереження 2: Цей блог не є посібником з використання Dataform або Dbt. Якщо ви не знайомі з жодним з цих інструментів, я наполегливо рекомендую вам ознайомитися з документацією Dataform або Dbt (або спробувати їх самостійно), перш ніж читати цей блог.
1. Розвиток
1.1 Місце розташування проекту
Досвід розробки в Dataform дуже схожий на досвід розробки в Dbt. Існує два способи розробки кодів: або за:
- Клацання у веб-консолі Dataform Console
- Написання командних рядків локально у вашому терміналі за допомогою Dataform CLI
Dataform Console
Загалом Dataform IDE інтуїтивно зрозуміле та просте у використанні.
✅ Однією з чудових особливостей Dataform IDE є те, що вона автоматично компілює запити та повертає повідомлення про валідність кодів та кількість обчислювальних ресурсів, які вона споживатиме в режимі реального часу.
🔴 Однак, я маю скаргу на користувацький інтерфейс Dataform. The Execution tab and Code є окремими, що означає, що вам доведеться перемикатися між цими двома вкладками кілька разів під час кодування. Це може забирати багато часу і дратувати. Щоб дати вам уявлення, вам потрібно написати код на вкладці Код, виконати його, а потім переключитися на вкладку Виконання, щоб побачити, чи все пройшло успішно. Якщо є якісь помилки, поверніться до кроку 1.
Dataform CLI
✅ Dataform CLI з відкритим вихідним кодом дозволяє виконувати такі операції з Dataform, як ініціалізація, компіляція, тестування та запуск моделей даних локально за допомогою терміналу.
Нижче наведено список доступних команд в Dataform CLI
🔴 На мою думку, інструмент Dataform CLI не дотягує до інструменту dbt CLI. У ньому відсутня важлива функція виконання команд на конкретному файлі або тезі, що може дуже засмучувати під час процесу розробки. Натомість, команди компіляції, тестування та запуску можуть бути виконані лише на всіх ресурсах проекту, що не завжди є необхідним. Це робить Dataform CLI малопридатним для використання розробниками. Якщо вам потрібен більш ефективний і зручний інструмент для ваших проектів розробки, dbt CLI буде кращим вибором.
1.2 Конфігурація файлу моделі
✅Якщо ви використовуєте BigQuery для перетворення даних, то при використанні Dataform замість dbt ви не втратите жодних важливих параметрів конфігурації, за винятком декількох параметрів, таких як період зберігання даних, шифрування KMS та надання ролей, які вам, можливо, доведеться налаштовувати вручну.
Щоб допомогти вам прийняти обґрунтоване рішення, ми надали вичерпне порівняння конфігурацій моделі BigQuery в dbt та Dataform у наступній таблиці:
*Запити, які посилаються на конфігуровану таблицю, повинні використовувати фільтр на стовпці розбиття, інакше BigQuery поверне помилку (ref)
📓У блоці конфігурації доступно 5 типів таблиць, що охоплює майже всі типи матеріалізацій, які може запропонувати BigQuery:
- стіл: звичайний стіл
- інкрементний: інкрементна таблиця
- вид: табличний вигляд
- матеріалізований: матеріалізований вигляд таблиці
- операції: кастомні SQL-коди. Це може бути корисно, коли вам потрібно створити порожню таблицю, щоб інший сервіс міг заповнити її даними.
📓Ви можете повторно використовувати документацію в Dataform так само, як це можна зробити з блоком docs в dbt.
🔴Я задоволений можливостями конфігурації, які пропонує Dataform для налаштування файлів моделей. Однак, на відміну від dbt, немає можливості замінити налаштування на рівні каталогу. Це означає, що я більше не можу швидко налаштувати окремі схеми для вихідних, постановочних і маркет-моделей, використовуючи лише кілька рядків коду.
1.3 Конфігурація залежностей
Як і в dbt, ви можете легко посилатися на залежності в Dataform за допомогою функції ref
✅Однак, на відміну від dbt, посилання та залежності в Dataform - це два окремих поняття. Ви можете:
- 1 – посилатися на інші об'єкти, не оголошуючи їх як залежності. Іншими словами, ви можете використовувати оголошення таблиці або джерела даних в операторі SELECT так само, як і функцію ref, але вони не будуть відображатися в лінії даних як залежності моделі. Цього можна досягти за допомогою функції resolve.
- 2- оголосити інші об'єкти як залежні, не посилаючись на них. Іншими словами, Dataform виконає ці залежні об'єкти (таблиці, твердження, оголошення джерел даних) перед залежною таблицею. Але на ці об'єкти не буде посилань у функції ref в операторі SELECT. Цього можна досягти, використовуючи параметр dependencies у блоці конфігурації
➡️ Це буде корисно у випадку додавання тверджень як залежностей.
Наприклад: Коли таблиця B залежить від таблиці A, яка має твердження, збій тверджень таблиці A не блокує Dataform від створення таблиці B. Щоб виконати таблицю B тільки якщо твердження таблиці A пройшли, додайте ці твердження як залежності до залежностей: [ "" ] у блоці конфігурації таблиці B.
1.4 Підтримувані мови
Dataform підтримує розробку робочих процесів SQL на SQL та JavaScript.
✅Роль JavaScript в Dataform подібна до ролі Jinja в Dbt. JavaScript дозволяє користувачам розробляти повторювані коди один раз і використовувати їх пізніше в межах одного файлу, проекту або навіть між проектами, використовуючи пакети Dataform. Спільнота розробила кілька корисних пакетів, таких як:
- bigquery-ml-pipeline: Шаблон для побудови машинного конвеєра на Bigquery ML з використанням Dataform
- dataform-scd: Шаблон для створення таблиць з повільною зміною розмірів типу 2 зі змінних джерел даних у Dataform.
Спробуйте їх самі, якщо вам цікаво!
2. Співпраця
✅ Dataform сумісний з усіма популярними git-хостингами
🔴 Однак, виконувані дії Git'а в консолі обмежені кількома основними командами, як показано нижче:
- Зафіксуйте зміну(и) X
- Перейти до гілки за замовчуванням
- Натисніть на назву вашої філії
- Витягнути з гілки за замовчуванням
- Витягнути з назви вашої філії
- Повернутися до останньої фіксації
➡️ Якщо вам потрібно використовувати додаткові команди git'а, наприклад, git rebase для вирішення конфліктів замість git merge, ви можете використовувати Dataform CLI для запуску цих команд локально у вашому терміналі. Однак, як згадувалося раніше, CLI не дозволяє виконувати одну модель або тег, що є суттєвим обмеженням.
3. Розгортання
Існує три способи запланувати автоматичне розгортання в Dataform:
- Використання конфігурації Workflow
- За допомогою Cloud Composer або за допомогою робочих процесів і хмарного планувальника.
- Використання API Dataform
Плюси і мінуси кожного з підходів добре пояснює Хьюго у своїй статті тут
✅В інтерфейсі Dataform UI ви можете легко налаштувати розклад компіляції та розклад виконання без необхідності писати жодного рядка коду:
- Конфігурації випуску: налаштування розкладу для "компіляції" виробничих кодів, що є еквівалентом dbt compile.
- Конфігурації робочого процесу: налаштування розкладу для "виконання" останніх скомпільованих кодів, що є еквівалентом запуску dbt.
➡️ Розділення розкладів компіляції та виконання підвищує надійність та відмовостійкість вашого пайплайну. Це дозволяє безперебійно виконувати заплановані запуски результатів компіляції з конфігурацій релізів, навіть якщо ваш віддалений Git-провайдер недоступний.
🔴Однак, робочий процес, налаштований в IDE, не може бути викликаний такими подіями, як git push до гілки або git merge до main. Тому ви не можете реалізувати CI/CD або Slim CI в Dataform так само легко, як з dbt, що вимагає лише декількох кліків в консолі. Для автоматизації та інтеграції з вашим конвеєром CI/CD ви повинні вдатися до останнього підходу, який полягає у використанні RESTful API. Однак це рішення вимагає більше зусиль з розробки та обслуговування, як і будь-яке інше кастомне рішення.
4. Управління
Тестування
✅ Ви можете використовувати як вбудовані, так і кастомні твердження в Dataform для тестування ваших моделей.
⛔ Вбудовані твердження обмежуються лише унікальним тестом, а не тестом на нуль. Однак ви можете легко налаштувати інші типи тестів за допомогою тверджень rowConditions або ручних тверджень у файлах SQXL. Для порівняння, якщо ви використовуєте dbt, ви можете використовувати деякі тести "з коробки", які вам доведеться створювати вручну в Dataform.
Документація та родовід даних
У Dataform ви можете писати описи для таблиць/поглядів та їхніх стовпців у блоці конфігурації так само, як і в dbt. У Dataform також доступний родовід таблиць, щоб користувачі могли відстежувати залежності моделей.
✅Одним із зручних аспектів використання Dataform є те, що описи та DAG автоматично відображаються в інтерфейсі BigQuery UI, без будь-яких додаткових налаштувань. Це може заощадити вам купу часу, який інакше був би витрачений на перемикання між різними інтерфейсами, як це потрібно при використанні dbt.
Ведення журналу та сповіщення
✅Кожен виклик робочого процесу Dataform автоматично реєструється за допомогою хмарного логування. Ви можете переглянути ці журнали в Google Cloud CLI або Logging API. Ви також можете використовувати Хмарний моніторинг для спостереження за тенденціями викликів сценаріїв обробки Dataform, щоб випередити проблеми у вашому пайплайні.
Для налаштування сповіщень про збої в збірках Dataform ви можете використовувати Logs Explorer в Google Cloud Console або за допомогою API моніторингу. Для більш детальної інформації ви можете прочитати цей документ.
5. Інтеграція
✅Dataform можна легко інтегрувати з іншими інструментами в екосистемі GCP, такими як BigQuery для сховища даних, Cloud Logging для реєстрації викликів, Terraform для управління архітектурою тощо.
✅Dataform CLI також дозволяє використовувати Dataform з іншими сховищами даних за межами GCP:
- BigQuery
- Snowflake
- Redshift
- Сховище даних Azure SQL
- Postgres
🔴Однак, якщо ви хочете використовувати Dataform з цими додатками, вам потрібно використовувати Dataform CLI, який має багато обмежень, як я вже згадував раніше.
🔴Dataform має мінус, коли мова йде про масштабованість. Максимальний розмір одного репозиторію Dataform становить близько 1000 вузлів робочого процесу SQL (посилань). Якщо у вашій компанії більше 1000 моделей або ви можете скоро перевищити цю межу, ви можете розглянути можливість розбиття вашого гігантського сховища Dataform на менші, відповідного розміру. На жаль, Dataform не має функцій для підтримки крос-репозиторіїв, таких як dbt mesh. Тому розділення репозиторію за допомогою Dataform має багато недоліків:
- Конфігурація CI/CD, необхідна для кожного репозиторію Dataform та відповідного йому Git-репозиторію.
- Для кожного репозиторію Dataform та відповідного йому Git-репозиторію потрібна спеціальна конфігурація планування.
- Складність в управлінні залежностями між об'єктами вашого робочого процесу, розміщеними в декількох сховищах.
- Відсутність повної візуалізації DAG робочого процесу SQL, розподіленого між декількома сховищами. У кожному сховищі згенерована група DAG представляє лише частину повного робочого процесу SQL.
6. Вартість
Dataform - це безкоштовний сервіс, який пропонує Google. Однак, за винятком витрат на запити та зберігання даних, існують інші витрати, пов'язані з Dataform, про які слід пам'ятати.
- Хмарне логування: Для моніторингу викликів робочого процесу. Однак Cloud Logging є відносно недорогим ($0.50/гігабайт + 50 безкоштовних гігабайт на проект/місяць). Ви можете прочитати більше про ціни на Cloud Logging тут
- Крім того, вартість оркестрування залежить від інструментів планування, які ви використовуєте для збірок.
– Cloud Composer: див. розділ “Ціни“.
– Хмарний планувальник: див. розділ “Ціни“.
– Хмарні робочі процеси: див. розділ “Ціни“.
✅Більшість з цих інструментів доступні за ціною і пропонують безкоштовний рівень, якого має бути достатньо для невеликих проектів.
✅Ще однією перевагою Dataform є те, що він не стягує плату за кількість користувачів, як dbt. Тому ви можете бути спокійні, працюючи з Dataform, без додаткового стресу, пов'язаного з розміром вашої команди.
📓Ви можете використовувати цей інструмент, щоб оцінити вартість Dataform на основі додаткових даних про ваш проект.
Що стосується dbt, то dbt Core є безкоштовним. Однак, якщо ви хочете мати сервер для розміщення вашого dbt-проекту, вам потрібно буде використовувати dbt Cloud, схема ціноутворення якого наведена нижче:
Як бачите, безкоштовний пакет Dbt Cloud постачається з багатьма фіксованими лімітами:
- Тільки 1 місце для розробників
- 3 000 успішних моделей на місяць ➡️ Якщо припустити, що у вас є лише щоденні виробничі завдання і CI запускається один раз на день, ваше dbt-репо може мати максимум 3000/30/2 = 50 моделей, що є скромною кількістю навіть для невеликих проектів
Підсумок
Я вважаю, що конкуренція між Dataform та dbt не є грою з нульовою сумою. Кожен інструмент має свої переваги та недоліки, що робить їх придатними для різних типів проектів. Таким чином, я створив структуру, яка може допомогти вам вирішити, який інструмент використовувати між Dataform та dbt. Якщо ви візьмете лише одну річ з мого блогу, то це має бути ось що:
Посилання
https://cloud.google.com/dataform/docs?authuser=1
https://github.com/dataform-co
https://cloud.google.com/dataform/pricing
ОРИГІНАЛ СТАТТІ:Dbt vs. Dataform: Which one should you choose?
АВТОР СТАТІ:Na Nguyen (Anna)
🚀Долучайтесь до нашої спільноти Telegram:
🚀Долучайтесь до нашої спільноти FaceBook:
🚀Долучайтесь до нашої спільноти Twiter X: