Англійський словник для обговорення інженерних даних

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

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

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

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

** Еволюція схеми ** — процес зміни схеми даних з часом без руйнування нижніх споживачів. Приклад: «Ми використовуємо Avro з підтримкою еволюції схем, тому додавання нових полів не порушує існуючі конвеєри»

** Обрізання розділів ** — метод оптимізації запиту, за допомогою якого база даних пропускає сканування незначних розділів на основі фільтрів запиту. Приклад: «Запит за датою активує обрізання розділів і зменшує сканування з терабайтів до гігабайтів»

** Дані, що надходять пізно ** — Дані, які надходять до системи після того, як вікно часу, до якого вони належать, вже було оброблено. Приклад: «Ми повинні обробляти дані, що прибувають пізно, тому що події мобільного застосунку можуть бути затримані до 48 годин»

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

** Семантика « тільки- но » — гарантія обробки, яка забезпечує, що кожен шматок даних буде оброблено лише один раз — а не нуль разів, а не двічі. Приклад: «Kafka Streams підтримує семантику точного одного разу для критичних фінансових транзакційних конвеєрів»

** Договір щодо даних ** — формальна угода між виробниками даних і користувачами, яка визначає схему, формат, SLA і очікування щодо якості набору даних. Приклад: «Команда платежів публікує договір з даними, який гарантує, що схема подій не буде порушена без 30-денного попередження про застарівання»

SLA проти SLO для трубопроводів — SLA (Service Level Agreement) є контрактним зобов’ язанням, зазвичай з штрафами за порушення. ** SLO ** (Service Level Objective) є внутрішньою метою. Приклад: «Наш внутрішній SLO має обробляти події протягом п’яти хвилин, але SLA, який ми підписали з клієнтом, гарантує одну годину свіжості»

** CDC (Change Data Capture) ** — метод для запису змін на рівні рядків у базі даних і передачі їх у потоковій формі до нижніх систем. Приклад: «Ми використовуємо CDC для реплікації змін з нашої виробничої бази даних Postgres в сховище даних в майже реальному часі»

Як це використовувати на практиці

У дискусіях з інженерії даних ці терміни часто з’являються в комбінаціях. Практикуйтеся слухати їх разом:

• «Ми повинні обробляти пізно прибувших даних в срібному шарі, розширюючи водний знак»
• “Data contract визначає правила schema evolution — ви не можете видаляти поля без періоду застарівання.”
• «Exactly-once semantics є критичним для цього трубопроводу, тому що ми обробляємо фінансові події»

При обговоренні надійності конвеєра розрізняйте між ** SLA ** (зовнішні, контрактні) і ** SLO ** (внутрішні цілі). Команди часто говорять про «відсутність SLO» як про раннє попередження, перш ніж вони ризикують «порушення SLA»

** Обговорення послідовності даних ** часто використовують дієслова типу « trace », « track », « audit » і « surface »: « Чи можемо ми вивести послідовність даних цього стовпчика на панель приладів? » або « Нам потрібно перевірити послідовність даних перед тим, як вивести з експлуатації це джерело. »

Приклад розмови

** Инженер по данным (Анастасия): ** “Мы видим устаревшие данные в золотом слое. Число відстає на 12 годин»

** Lead Pipeline: ** « Це проблема з запізненням надходження даних або збої в конвеєрі? »

Анастасія: “Це дані, які прибули пізно. Події з мобільних пристроїв від автономних користувачів надходять за межі нашого поточного водяного знака. Я б запропонував продовжити водяний знак з 10 хвилин до 4 годин для цього конкретного джерела»

** Конвейерний ведучий: ** “Це затримає закриття вікна. Чи зможемо ми все ще зустріти нашу SLO однією годиною свіжості для бізнес-панелі?»

Анастасія: “Не для мобільних заходів. Ми повинні оновити контракт на дані для цього джерела, щоб відобразити 4-годинну гарантію свіжості і повідомити команду аналітики»

Практичні поради

1. ** Накреслити конвеєр англійською мовою: ** Намалювати простий конвеєр даних для проекту, який ви знаєте, а потім описати кожен етап уголос англійською мовою за допомогою словника з цього повідомлення. Наприклад: «Рівень необроблених подій в бронзовому шарі через CDC з нашої бази даних Postgres. Задача Spark перевіряє і очищає їх перед підвищенням до срібла…”

2. ** Поясніть шари медальйону людині, яка не є інженером: ** Спробуйте пояснити бронзові, срібні і золоті шари комусь, хто не є інженером з обробки даних, за допомогою аналогії (наприклад: сирова руда, очистений метал, готовий продукт). Це змушує вас перевести технічний словник на просту англійську.

3. ** Прочитайте статтю блогу про архітектуру потокового передачі: ** У блогах Confluent, Databricks Engineering і документації Airflow всі ці терміни використовуються як природні. Прочитайте одну статтю і підсвічуйте всі знайдені вами терміни з цієї статті. Спробуйте вивести значення з контексту, перш ніж перевіряти визначення.

На практиці: Навігація нюансів в спільних дискусіях

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

Розглянемо такий сценарій: ви переглядаєте запит на звантаження нового конвеєра даних. Молодший інженер пише опис PR: «Впроваджено CDC для введення даних з джерельної системи. Покращена пропускна здатність.” Технічно точна, але не містить важливих деталей. Ефективніша формулювання визнає потенційні наслідки вниз по течії. Наприклад, «Вреалізовано зміну захоплення даних (CDC) з застарілої системи в схему зірки. Початкове тестування показує 20% поліпшення швидкості поглинання, але потрібне подальше моніторинг для оцінки потенційного впливу на затримку звітів нижче по течії - конкретно, нам потрібно переконатися, що це не перевищує наш SLA 5 хвилин для створення звітів. “Зауважте додавання фраз, таких як “потенційно вплив”, “далі моніторинг”, і посилання на конкретні метрики (“затримка” і “SLA”). Ці тонкі доповнення демонструють проактивне розуміння принципів інженерії даних і зобов’язання зменшити ризики.

Інша поширена проблема виникає в розмовах Slack, де обговорюється походження даних. Старший інженер може сказати: « Давайте відслідкуємо потік цих даних до їх джерела ». Хоча це зрозуміло, це викликає питання: « Як ми відслідковуємо їх? » Розмова потребує більшої точності. Запропонування використання певного інструменту — можливо, каталогу даних або системи стеження за попередниками — і чітке вказівок на те, яку інформацію ви шукаєте (« Нам потрібно побачити всі перетворення, застосовані до цього поля, включаючи таблицю джерела і будь- які обчислені стовпчики ») значно покращує ясність. Це виходить за рамки простого запитання * що * потрібно знайти, щоб вказати * як * слід проводити пошук. Це уникає розчарування циклу нечітких запитів і переробки.

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

# Example: Using Dbt to document a transformation's lineage

dbt run --select "my_transformation" --profile  --output-json lineage.json

За допомогою цієї команди, у якій використано популярний інструмент перетворення даних dbt, показано, як можна автоматично створювати вивід JSON, у якому містяться відомості про попередників певного перетворення — з’ єднання з таблицями джерела і всіма проміжними кроками. Такий вид автоматизованої документації є безцінним для розуміння залежностей і розв’ язання проблем. Файл lineage.json буде потім вказуватися в описах PR або обговореннях, що забезпечує негайний контекст для команди.