dbt Snapshots і SCD2: Англійський словник для інженерів даних

Інженери даних, які працюють з dbt, часто опиняються в standups, дизайн-оглядах і ретроспективах, де точний англійський словник має таке ж значення, як і технічні знання. Такі терміни, як «SCD типу 2», «зерно» і «недійсні рядки» мають певні значення, які носії англійської мови використовують точно — і зловживання ними може викликати справжню плутанину. У цьому повідомленні ви дізнаєтеся про шаблони мови, що стосуються знімків dbt і повільних змін розмірів, щоб ви могли стежити за обговореннями, ставити відповідні питання і чітко пояснювати свої рішення.

Ключовий словник

** Повільно змінювана вимірність (SCD) ** — таблиця вимірностей у сховищі даних, де значення змінюються з часом і вам потрібно відстежувати історію. Інженери розрізняють між SCD «типу 1» (перезапис), «типу 2» (додати новий рядок) та іншими. Ви почуєте « ми реалізуємо SCD2 » або « це моделюється як вимір типу 2. »

«Таблиця адрес клієнтів повинна бути SCD2 — ми не можемо просто перезаписувати, коли хтось переїжджає, тому що фінанси потребують історичних адрес доставки для своїх звітів»

** Матеріалізація знімків ** — специфічний для dbt механізм для захоплення записів з таблиці джерела у певний момент часу. Інженери кажуть, що модель «використовує матеріалізацію знімків» або посилаються на «наші знімки» як на категорію моделей dbt.

«Ми маємо знімок матеріалізації на таблиці замовлень — він працює кожну годину і захоплює будь-які зміни статусу або суми»

** Унікальний ключ ** — стовпчик або комбінація стовпчиків, які визначають один запис у знімку. У dbt ви можете налаштувати це у блоку знімок. Рідні носії кажуть «унікальний ключ для цього знімка» або запитують «яке зерно цього знімка?»

«Ми використовуємо order_id як унікальний ключ, але будьте обережні — є деякі застарілі дублікати ID в системі джерела, які нам потрібно дедуплікувати вгору.»

** Перевірити стратегію ** — стратегія зніму dbt, яка визначає зміни за допомогою порівняння вказаних стовпчиків. Інженери кажуть «ми використовуємо стратегію перевірки» або «стратегія перевірки стежить за цими колонками на зміни»

«Ми пішли зі стратегією перевірки тут і перерахували п’ять стовпців, які нам насправді цікаві — інакше шумна колонка аудиту викликала б хибно позитивні зміни кожну годину»

** Стратегія часу ** — Стратегія зніму dbt, яка виявляє зміни за допомогою порівняння стовпчика часу updated_at. Ви почуєте повідомлення « стратегія часу залежить від надійного updated_at » або « неможливо використовувати стратегію часу, оскільки це джерело не оновлює це поле »

«Стратегія часового штампу простіше розуміти, але вона розпадається, якщо система джерела заповнює записи без оновлення часового штампу»

** Недійсні рядки ** — у SCD2, коли змінюється запис, стара версія « анульована » — її стовпчик dbt_valid_to встановлюється на поточний часовий штамп. Інженери кажуть, що рядки «недійсні» або посилаються на «логіку недійсності»

«Одна річ, яка нас вразила: коли запис вилучається в джерелі, dbt не анульовує рядок зніму за замовчуванням — ви повинні обробляти жорсткі вилучення окремо.»

** Видалення за допомогою жорсткого диска ** — записи, які було фізично вилучено з системи- джерела, а не просто позначено як неактивні. Це поширена проблема зі знімками. Інженери кажуть: «ми повинні обробляти жорсткі вилучення» або «м’які вилучення проти жорстких вилучень»

Команда CRM підтвердила, що вони роблять жорсткі вилучення на деактивованих рахунках, тому нам потрібна конфігурація invalidate_hard_deletes або ми матимемо записи зомбі в нашому знімку

** Зерно ** — рівень деталізації, який відповідає одному рядку у таблиці. Інженери запитують «яке зерно цієї таблиці?», щоб зрозуміти, що означає один запис. Це фундаментальна концепція моделювання даних.

«Перед тим, як ми створимо цей знімок, давайте вирівняємо зерно — це один рядок на замовлення, або один рядок на елемент рядка замовлення?»

** Суррогатний ключ ** — Створений системою ідентифікатор (зазвичай, геш), який використовується замість природного бізнес- ключа, особливо у SCD2, де одна і та ж бізнес- особа має декілька рядків. Інженери кажуть: «ми додаємо сурогатний ключ» або «сурогатний ключ є гешом унікального ключа плюс штамп часу зніму»

«Ми генеруємо сурогатний ключ з dbt_utils.generate_surrogate_key — моделі нижнього рівня приєднуються до цього, тому вони завжди отримують правильну версію»

** Ефективне датування ** — Практика відстеження, коли версія запису стала активною і коли вона була замінена, використовуючи стовпці dbt_valid_from і dbt_valid_to. Ви почуєте «ефективне датування», «приєднання у момент часу» або «запити стану»

«Фінансова команда хоче відтворити, як виглядав запис клієнта на дату фактури — це класичний ефективний випадок використання датування, який саме обробляє наш знімок»

Фрази в контексті

** Пояснення вибору дизайну в стендапі: **

«Ми вибрали стратегію перевірки, а не часовий штамп, тому що updated_at джерельної системи не є надійним — він не потрапляє в певні пакетні оновлення. Отже, ми явно спостерігаємо за трьома стовпцями, які мають значення: статус, кількість і assigned_rep”

** Позначення проблеми з жорстким вилученням у перегляді: **

«Одна річ, яку потрібно викликати в цьому знімку: якщо запис буде жорстко вилучено в Salesforce, ми не будемо знати про це. Рядок просто залишається відкритим на нашому знімку без dbt_valid_to. Чи є у нас процес, щоб примирити це, або ми повинні додати invalidate_hard_deletes: true?”

** Прояснення зерен під час обговорення дизайну: **

“Перед тим, як ми зробимо знімок цього столу, я хочу переконатися, що ми вирівняні на зерні. Це один рядок на підписку, чи один рядок на підписку на цикл розрахунку? Відповідь змінює конфігурацію унікального ключа значно»

** Документування рішення: **

«Ми використовуємо SCD типу 2 тут, тому що команда аналітики повинна приєднатися до історичних сегментів клієнтів - перезапис втрачає цю історію і порушує їх квартальний аналіз когорти.»

** Обговорення виступу в ретроспективі: **

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

Ключові слова

Корінні носії комбінують ці слова певним чином. Вивчати їх як фіксовану фразу:

• ** реалізувати SCD2 ** (не « створити SCD2 » або « виконати SCD2 »)
• ** захоплення змін ** / ** виявлення змін ** (знімки « захоплення » або « виявлення » змін)
• ** відкритий запис ** — рядок знімок без dbt_valid_to (все ще активний): « відкритий запис для цього клієнта »
• ** закриття запису ** — встановити dbt_valid_to, позначивши версію як замінену
• ** point- in- time join ** — приєднання для отримання значення за певною датою
• ** backfill records ** — переобробка історичних даних: « якщо вони заповнюють записи без оновлення часового штампу… »
• ** downstream models ** — моделі dbt, які залежать від знімку: « downstream models join on the surrogate key »
• ** викликати запуск знімку ** / ** знімок отримує ** зміни

Practice

Перейдіть до сторінки документації dbt, присвяченої знімкам, і прочитайте розділ « Як працюють знімки dbt ». Для кожного з десяти словників у цьому повідомленні знайдіть, де dbt використовує цю концепцію (навіть якщо її формулювання трохи відрізняється). Потім напишіть пояснення з трьох абзаців, так само, як ви пояснюєте налаштування знімка новій людині у повідомленні Slack, використовуючи принаймні шість слів з цього повідомлення. Писання у форматі Slack (трохи неформально, коротко) відрізняється від написання документації, і вправляння у обох стилях допоможе вам у реальних робочих ситуаціях.

Розробка навігаційних систем

Будьмо чесними, отримання зворотнього зв’язку - особливо технічного зворотного зв’язку - може бути неймовірно складним, коли ваша перша мова не природно спрямована на точне, детальний зв’язок. Концепції знімок і Повільно змінюються виміри (SCD2) вже складні, але додавання шарів англійського словника для їх опису, особливо навколо * чому * за рішеннями, підвищує розмову значно. Це не просто про те, що ви зробили; це про вираження ваших міркувань, передбачення потенційних проблем і ефективне співробітництво з вашою командою.

Один з найпоширеніших сценаріїв під час перегляду коду. Уявіть, що ви отримали такий коментар на моделі dbt: «Це зображення не повністю захоплює всі зміни в таблиці клієнтів. Стовпчик updated_at відсутній у критеріях фільтрування. “Зараз, якщо вам не зручно виражати себе чітко, це може здатися захисним або схожим на суперечку. Замість цього, намагайтеся сказати щось на зразок: “Гаразд, я розумію. Моєю метою було зосередитись на змінах транзакційних даних, які безпосередньо впливають на сам запис клієнта - зокрема дати замовлень і ідентифікатори продуктів. Стовпчик updated_at представляє більш широкі оновлення на системному рівні, які не обов’язково пов’язані з однією клієнтською транзакцією. Можливо, ми могли б додати цю умову як додаткову умову фільтра, якщо це бажана поведінка для звітування, враховуючи потенційний вплив на швидкість виконання запиту. Зауважте, що формулювання * намір * і визнання потенційних наслідків демонструє розуміння і бажання співпрацювати. Це уникає звучання обвинувачення і запрошує подальшу дискусію про оптимальний підхід. Аналогічно, у повідомленні Slack, що пояснює ваш проект dbt, ви можете сказати: «Я створив модель знімок, щоб представити історію замовлень клієнтів, зосередившись на змінах, внесених під час кожної транзакції. Ця реалізація SCD2 забезпечує, що історичні дані залишаються точними для звітів шляхом відстеження змін через updated_at стовпці. ”

Іншим важливим елементом є активне вирішення потенційних проблем * до того, як * вони стануть проблемами. Під час перегляду дизайну, обговорюючи реалізацію моделі SCD2, ви можете сказати: “Ми використовуємо знімки, щоб забезпечити перегляд ключових показників у реальному часі, а структура SCD2 дозволяє нам відстежувати зміни з часом без порушення існуючих конвеєрів звітів. Я розглянув потенційний вплив на продуктивність з більшими таблицями знімок і реалізував стратегії індексування - ми можемо обговорити їх далі, якщо це потрібно. “Наголос тут робиться на демонстрації передбачення і прихильності до найкращих практик. Це про те, щоб показати, що ти продумав усі наслідки, а не просто представити рішення.

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

-- Example dbt model query demonstrating a snapshot filter (simplified)
SELECT *
FROM {{ ref('customer_orders') }}
WHERE order_date >= '2023-10-26' AND updated_at >= '2023-10-26'