Англійська мова для інженерів трубопроводів даних: словник і фрази
Словник конвеєра даних, мова ETL/ELT, оркестрація, якість даних і шаблони комунікації для інженерів даних.
Інженерія даних має свій власний діалект. Незалежно від того, чи ви приєднуєтесь до виступу, пишете пост- морт або переглядаєте PR колеги, ви зіткнетеся з щільною групою термінів, які не з’ являються у загальних словниках англійської мови. У цій статті розглянуто найважливіші слова для інженерів з конвеєрів даних — з визначеннями простою англійською мовою і прикладами реальних розмов, щоб ви могли впевнено використовувати кожен з цих термінів.
Основні терміни: трубопроводи і графіки
** Конвейєр ** — послідовність автоматичних кроків, які пересують або перетворюють дані з джерела до призначення. Слово запозичено з Unix shell scripting, але зараз широко використовується у всіх стеках даних.
«Конвейєр поглинання безшумно відмовляється — він записує нульові рядки, але виходить з кодом 0. Чи можеш ти додати твердження про кількість рядків в кінці?»
«Ми маємо три окремі трубопроводи для clickstream, CRM і платежів. Зрештою ми хочемо об’єднати їх, але зараз кожна команда володіє своїм»
** DAG (направлений ациклічний граф) ** — спосіб представлення залежностей завдань у вигляді графіка, де ребра вказують на один напрямок і жодна задача не може залежати від самої себе (прямо або опосередковано). Більшість сучасних оркестраторів моделюють робочі потоки як DAG.
« Ваш DAG має цикл — Завдання C залежить від Завдання B, яке залежить від Завдання A, яке залежить від Завдання C. Планувальник відмовиться його запускати»
«Я додам нове перетворення як вузол в DAG, нижче за крок нормалізації.»
** Оркестрація ** — автоматичне планування і координація завдань конвеєра. Такі інструменти, як Airflow, Prefect і Dagster є найбільш широко використовуваними оркестраторами в індустрії.
“Ми перейшли з Airflow на Prefect в минулому кварталі. Динамічне відображення завдань в Prefect набагато чистіше для нашого випадку використання»
«Оркестрація обробляє повторні спроби, попередження і розв’язання залежностей, тому нам не потрібно керувати цим самостійно з роботами cron.»
** Залежність завдань ** — правило, за яким одне завдання має бути завершено (успішно) перед тим, як можна буде розпочати інше завдання.
«Існує залежність завдання між сирим завантаженням і кроком дедуплікації — якщо завантаження зазнає невдачі, дедуплікація ніколи не запускається, що саме того, що ми хочемо»
ETL/ELT Language and Load Patterns (англійською)
** Інкрементне завантаження проти повного оновлення ** — дві фундаментальні стратегії оновлення набору даних. * Приростове завантаження * додає або об’ єднує лише нові або змінені записи з часу останнього запуску. * повне оновлення * скидає і замінює весь набір даних під час кожного запуску.
“Для таблиці транзакцій ми використовуємо інкрементальний заряд, ключ на
updated_at. Для каталогу продуктів ми робимо повне оновлення щоночі, тому що він малий, а логіка SCD не варте складності»
«Обережно — повне оновлення на 200-мільйонній таблиці рядків призведе до конфлікту блокування. Давайте перейдемо до інкрементального»
** Backfill ** — запуск конвеєра для історичного діапазону часу, який було пропусчено, зазвичай, тому що конвеєра ще не існувало або він зазнав невдачі під час цього періоду.
“Ми додали відстеження подій минулого місяця. Нам потрібно заповнити шість місяців історичних даних, перш ніж ми зможемо зробити будь-який значущий аналіз трендів»
«Задача заповнення є ідемпотентною, тому ви можете перезапустити її безпечно, якщо вона закінчиться на півдорозі»
** Ідемотентний конвеєр ** — конвеєр, який дає однаковий результат незалежно від того, скільки разів його було запущено для одного і того ж вхідного даних або вікна часу. Це критична властивість проектування для безпечних повторних спроб і заповнення.
“Всегда проектируйте трубопроводы таким образом, чтобы они были идемотентными. Якщо завдання вставки-перезапису виконується двічі, таблиця повинна виглядати ідентично — не має дублюючих рядків»
“Транспортний трубопровод не є ідемпотентним зараз, тому що він безумовно приєднується. Нам потрібно додати
MERGEабо шаблон видалення-потім-вставлення»
Кваліфікація та управління проектами
** Перевірка якості даних ** — крок перевірки, який перевіряє, чи відповідають дані визначеним правилам, перед тим, як їх буде передано нижче. Перевірки можуть охоплювати повність, унікальність, посилання на цілісність, діапазони значень і багато іншого.
“У нас є перевірка якості даних, що працює після кожного завантаження. Якщо нульовий рівень на
customer_idперевищує 2%, завдання нижче за течією блокуються автоматично.”
** Сподівання (великі сподівання) ** — у контексті структури ** Великі сподівання **, * сподівання * є декларативним твердженням щодо ваших даних (наприклад, « цей стовпчик ніколи не повинен бути нульовим », « значення повинні бути між 0 і 100 »). Термін став звичайним скороченням у всій індустрії.
«Я додав очікування, що
order_totalзавжди буде додатним. Він виявив помилку введення даних в CRM в перший день»
“Список очікувань зберігається в системі контролю версій разом з кодом конвеєра. Таким чином схема і правила якості розвиваються разом»
** еволюція схеми ** — процес обробки змін у структурі набору даних (додання стовпчиків, перейменування полів, зміна типів) без порушення роботи споживачів, що знаходяться нижче за ними.
Команда добавила три новые колонки без предупреждения. Наш трубопровод зламався, тому що ми робили
SELECT *і схема Avro не збігалася. Нам потрібна правильна стратегія еволюції схеми»
«Ми використовуємо автоматичну еволюцію схеми Delta Lake для додавання змін, але зміни, які порушують — наприклад, перейменування стовпця — все ще вимагають скоординованої міграції»
** Data lineage ** — запис, який містить інформацію про те, звідки походять дані, як їх було перетворено і куди вони були перенесені. Lineage є необхідним для зневадження, відповідності і аналізу впливу.
«Ми не можемо просто вилучити цю таблицю джерел — графік послідовності даних показує, що на неї посилаються чотирнадцять моделей нижче. Нам потрібно правильно його викинути»
«З OpenLineage, інтегрованим в Dagster, ми отримуємо метадані про родовід автоматично. Це величезна допомога при відстеженні проблеми якості назад до її джерела»
Надійність, затримка і помилки
** Дані, що надходять пізно ** — записи, які надходять до системи обробки після того, як вікно часу, до якого вони логічно належать, вже було оброблено. Поширений в системах, що керуються подією і IoT.
«Ми бачимо запізнілі дані від мобільних клієнтів весь час — події, створені офлайн, синхронізуються через кілька годин. Наші агрегації повинні враховувати це»
** Водяний знак ** — поріг, який говорить потоковій або мікро- пакетній системі, скільки часу чекати на дані, які надходять пізно, перед тим, як закрити вікно часу. Після того, як водяний знак буде знято, пізні записи для цього вікна можуть бути відкинуті або перенаправлені у інше місце.
“Встановити водяний знак на 30 хвилин. Все, що приходить пізніше, ніж це, потрапляє в чергу мертвих листів для вручну перегляду»
«Водяний знак занадто агресивний — ми скидаємо події, які запізнюються лише на 10 хвилин. Давайте продовжимо його до години і переоцінимо»
** Черга мертвих листів ** — окреме місце зберігання записів, обробка яких зазнала невдачі (через помилки схеми, порушення якості або системні помилки). Замість того, щоб знищувати весь конвеєр, погані записи виокремлюються, щоб інші могли продовжувати.
“Ми відправляємо неправильно сформований JSON прямо в чергу мертвих листів. Команда операцій переглядає його щотижня і або виправляє продюсера або відкидає записи. ”
«Упевніться, що черга мертвих листів має налаштовані попередження — це режим безшумної невдачі, якщо ніхто не помічає, що вона заповнюється»
** Порушення SLA (в контексті даних) ** - ситуація, коли конвеєр або набір даних не відповідає узгодженій угоді про рівень обслуговування, зазвичай визначається як крайній термін, до якого нові дані повинні бути доступні вниз по течії.
“Конвейер звітів має SLA 06:00 UTC. Мы взломали его сегодня утром - на панели управления финансовой команды были вчерашние цифры до 08:30. Нам потрібно пост-мортем»
“Я додам перевірку SLA в Airflow, щоб ми отримали попередження Slack, якщо DAG не завершиться до 05:45. Це дає нам п’ятнадцять хвилин, щоб вступити в дію до порушення»
Як використовувати їх у розмові
Інженери даних регулярно спілкуються в трьох контекстах: standups / syncs, огляди інцидентів і обговорення архітектури. Ось як словосполучення вписується в практику.
** Під час стояння: **
“Вчера я закончил идемпотентную заполнительную таблицу для заказов. Сьогодні я працюю над додаванням очікувань для еволюції схеми у потоку подачі продукту. Жодних блокувань, але я хочу позначити, що пізні дані з мобільного додатку викликають проблеми з водяним знаком в потоковій роботі»
** Під час перегляду інциденту: **
“Порушення SLA о 06:20 було викликане помилкою залежності завдання від попереднього. Перевірка якості даних на необробленому завантаженні зазнала невдачі, що призвело до блокування DAG нижнього рівня. Записи з нульовими
user_idпішли в чергу мертвих листів. Корінь причини: виробник розгорнув зміну схеми без оновлення набору очікувань. ”
** При запропонуванні дизайну: **
«Я б хотів перейти від повного оновлення до інкрементального завантаження, і зробити конвеєр ідемпотентним за допомогою
MERGE. Ми також повинні додати відстеження лінії даних з самого початку — це заощадить багато часу, коли нам потрібно зневаджувати проблеми оркестрації пізніше»
Використання точної термінології сигналізує про компетентність і робить розмову ефективною. У випадку сумнівів, віддайте перевагу конкретному терміну над неясним описом — «DAG має цикл» є яснішим і швидшим, ніж «завдання залежать один від одного в петлі».
Краткий справочник
| Term | Plain-English Meaning |
|---|---|
| Pipeline | Automated sequence of steps moving or transforming data |
| DAG | Graph of tasks with directional, non-circular dependencies |
| Orchestration | Automated scheduling and coordination of pipeline tasks |
| Backfill | Running a pipeline over a missed historical time range |
| Idempotent pipeline | Pipeline that produces the same result on repeated runs |
| Incremental load | Loading only new/changed records since the last run |
| Expectation | Declarative data quality assertion (Great Expectations term) |
| Schema evolution | Handling structural changes to datasets without breaking consumers |
| Watermark | Lateness threshold for closing a streaming time window |
| Dead letter queue | Isolated storage for records that failed processing |
| SLA breach | Failure to deliver fresh data by an agreed deadline |
| Data lineage | Record of data’s origin, transformations, and destinations |