Основний перший крок для оцінки впливу на дані в проектах dbt

Що ви перевіряєте після оновлення моделі даних dbt для QA вашої роботи? Для користувачів Recce ми знайшли, що це є різниця в кількості рядків. Порівняння кількості рядків до та після змін у моделі даних є ключовим індикатором змін у даних і ідеальним початковим пунктом для забезпечення цілісності даних.

Поставте все на свої місця

Втрати або додавання рядків у моделі даних можуть сигналізувати про потенційні проблеми в логіці трансформації даних. Якщо ви змінюєте модель, не повинно бути ніяких змін. В залежності від іншої роботи з моделями даних, ви можете очікувати збільшення або зменшення кількості рядків — але вам потрібно підтвердити, що ці зміни відповідають вашим очікуванням.

Щоб ефективно виконувати свою роботу як інженер даних або аналітик, ви повинні бути обізнані про такий тип змін. Для керівників даних це також важлива інформація для підписання PR.

Ось приклад того, як департамент охорони здоров’я Ріо-де-Жанейро використовував функцію порівняння кількості рядків Recce під час огляду PR (перевірте PR тут), щоб продемонструвати, що відсутні рядки були результатом завдання з де-дуплікації даних.

pic

Різниця в кількості рядків через де-дуплікацію даних

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

Аналіз різниці в кількості рядків для кількох моделей

Важливість різниці в кількості рядків як основного кроку для аналізу впливу на дані — ось чому це тепер є на передньому плані в Recce, інструменті, розробленому для команд даних, щоб перевіряти вплив на дані після змін у моделях даних dbt.

pic

Різниця в кількості рядків для кількох моделей у Recce

Отже, як ефективно використовувати різницю в кількості рядків для тестування оновлень вашої моделі даних? Вам не потрібно тестувати кожну модель, і тут на допомогу приходить вибір вузлів.

Природний (вибір) вузлів

Вибір вузлів у dbt використовується для виконання команд dbt проти підмножини вашого проєкту. Ось кілька типових вибірників:

  • modified: Виконати лише для змінених моделей
  • modified+: Виконати для змінених моделей та їх дочірніх
  • materialized:table: Виконати лише для моделей, які були матеріалізовані як таблиця

Використання вибору вузлів ефективне для зменшення часу та витрат на виконання dbt. Для більш детальної інформації про вибір вузлів, перевірте документацію dbt.

Застосування логіки вибору вузлів до перевірок даних

Recce також підтримує цей синтаксис для вибору, які моделі запускати для перевірки даних. Це полегшує вам, як користувачу dbt, перенесення тієї ж логіки на перевірки ваших моделей даних. Це економить час при перевірці кількості рядків між моделями в різних схемах, і ви також можете продовжувати використовувати Recce для більш глибоких перевірок після перевірки кількості рядків.

Ось приклад використання синтаксису вибору вузлів dbt для порівняння кількості рядків конкретних моделей за допомогою готової перевірки Recce:

- name: Кількість рядків для клієнтів, замовлень і зміненої таблиці  
 description: Кількість рядків для клієнтів та замовлень не повинна змінюватися  
 type: row_count_diff  
 params:  
 select: customers orders state:modified,config.materialized:table

Ця перевірка row_count_diff використовує той самий синтаксис, що й вибір вузлів dbt.
Коли він запускається, будуть перевірятися наступні моделі:

  • Модель customers
  • Модель orders
  • state:modified (будь-яка змінена модель)
  • Моделі, які є materialized:table

З цією однією перевіркою ви можете охопити свої критичні моделі (чітко вказавши customers і orders), а також будь-яку змінену таблицю. Незалежно від змін, які ви вносите в свій dbt проєкт, ви можете бути впевнені, що знатимете, якщо кількість рядків відрізняється в будь-якій з цих моделей. Це забезпечує захист від будь-яких несподіваних змін у кількості рядків.

Розумні значення за замовчуванням

Для користувачів Recce, навіть якщо ви вирішите не створювати свої власні стандартні перевірки, як у наведеному прикладі вище, є розумні значення за замовчуванням, які виконуватимуть наступні перевірки:

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

Як це працює в Recce

Коли ви запускаєте Recce для оцінки впливу на дані, перша сторінка — це лінійна діаграма (lineage DAG) — насправді це різниця в лінії, яка показує змінені моделі та їхні дочірні моделі.

Ви вибираєте моделі для виконання різних перевірок (між prod і dev), щоб перевірити вплив на дані, але якщо ваш dbt проєкт великий, або є багато потенційно впливаючих вузлів, складно зрозуміти, з чого почати.

Щоб допомогти, Recce покаже панель повідомлень вгорі сторінки лінії, яка нагадує вам виконати перевірку різниці в кількості рядків на вузлах, зазначених у ваших стандартних перевірках.

pic

Перевірка кількості рядків та різниця в лінії у Recce

Результати згруповані в зручну таблицю, тож немає необхідності перевіряти моделі одну за одною. Усі результати можна переглянути в одному запиті та надіслати на огляд PR разом з іншими пунктами вашого списку перевірки.

Висновок

Як показано в дослідженні випадку департаменту охорони здоров’я Ріо-де-Жанейро, перевірка впливу на дані після внесення змін у моделі dbt є важливою для того, щоб переконатися, що результуючі трансформовані дані відповідають вашим очікуванням.

Різниця в кількості рядків є важливим першим кроком, але щоб отримати повне уявлення про вплив на дані, вам слід також виконати інші перевірки, такі як різниця в профілях даних та інші статистичні перевірки. Ознайомтесь з повним набором інструментів для перевірки різниць, доступних у відкритому доступі в Recce, для оцінки впливу під час розробки dbt та огляду PR.

Перекладено з: The Essential First Step for Data Impact Assessment in dbt Projects

Leave a Reply

Your email address will not be published. Required fields are marked *