Словник для інженерів даних

Інженерія даних зазнала значних змін за останні п’ять років. Словниковий запас розвивався разом з інструментом — від традиційних ETL-конвейерів до сучасних архітектур Lakehouse, від ручних перетворень до інженерії аналітики, що керується рамками. Для не рідних носіїв англійської мови, які працюють з даними, цей розвивається словник може бути заплутаним.

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

---

Патерни руху даних

ETL (витягування, перетворення, завантаження)

У традиційному шаблоні ** ETL ** дані витягуються з систем- джерел, перетворюються (очищаються, з’ єднуються, агрегуються) поза системою призначення, а потім завантажуються у сховище даних.

• “Наш старий конвеєр слідує шаблону ETL — дані перетворюються у зоні очікування перед завантаженням на склад.” *

ELT (Витяг, завантаження, перетворення)

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

“Ми перейшли на шаблон ELT, коли перейшли на BigQuery — необроблені дані потрапляють в зону посадки, а dbt обробляє всі перетворення всередині складу.”

Підтримка даних

** Конвейєр даних ** — це послідовність кроків, які пересувають і перетворюють дані з джерела до призначення.

“Конвейер поглинання запускається кожну годину, витягуючи події з Kafka і переносячи їх до S3.”

---

Архітектура складів

Склад даних

** Склад даних ** це структурована, реляційна система, оптимізована для аналітичних запитів. Приклади: Snowflake, BigQuery, Redshift.

“Бизнес-аналізатори запитують склад даних безпосередньо за допомогою SQL.”

Озеро даних

** Озеро даних ** це велике сховище необроблених даних у їх власному форматі — структурованому, напівструктурованому і неструктурованому — зберігається дешево у об’ єкті зберігання.

“Ми переносимо всі журнали програм і дані потоку клацань у озеро даних у S3 перед обробкою.”

Дейта Лейкхаус

** Data Lakehouse ** поєднує в собі низькоякісне зберігання озера даних з можливостями запитів і управління складом даних. Це архітектура за такими платформами, як Databricks і Apache Iceberg.

“Ми переходимо на архітектуру Lakehouse з використанням Apache Iceberg — це дає нам ACID-трансакції на вершині зберігання S3.”

---

Перетворення і моделювання

dbt (засіб побудови даних)

dbt (вимовляється « dee- bee- tee ») — це фреймворк з відкритим кодом, який дозволяє аналітикам даних та інженерам писати перетворення на основі SQL, застосовувати контроль версій і керувати графіком залежностей між моделями.

• “Вся наша логіка перетворення живе в dbt моделях. Коли ми запускаємо dbt build, він виконує весь DAG від raw до mart.”*

• “Ми пишемо dbt- тести для кожної таблиці mart — перевірки кількості рядків, тверджень, що не є нульовими, і тести унікальності.” *

Модель даних

** Модель даних ** описує структуру і взаємозв’ язки даних. В аналітиці, зазвичай, це відноситься до перетворення SQL, яке формує необроблені дані в корисну форму.

“Модель orders приєднує таблицю raw_orders з розміром customers для створення денормалізованої аналітичної моделі.”

DAG (направлений ациклічний граф)

** DAG ** представляє графік залежностей конвеєра даних — які завдання слід виконати перш ніж інші можуть почати роботу.

“ДБТ DAG показує, що orders mart залежить від чотирьох моделей початкового рівня.”

---

Orchestration

Orchestration

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

“Ми використовуємо Airflow для оркестрування — він керує розкладом наших 200+ завдань DAG і обробляє повторні спроби і попередження.”

Апачі-Ейрфлойд

** Apache Airflow ** — це найбільш широко використовувана платформа оркестрації з відкритим кодом для конвеєрів даних.

“Airflow DAG запускається о 02: 00 UTC кожного ранку, запускаючи завдання поглинання, перетворення і експорту в послідовності.”

---

Кваліфікація та управління

Інформаційний ланцюжок

** Data lineage ** відстежує, звідки походять дані, як їх перетворювали, і куди вони надходять. Це необхідно для зневадження і відповідності.

“Граф послідовності показує, що показник доходу на панелі керування походить з таблиці orders на складі, яку останній раз оновили шість годин тому.”

• “Ми використовуємо вбудовану в dbt візуалізацію послідовності для відстеження даних від первинного джерела до інструменту BI.” *

Якість даних

** Якість даних ** стосується точності, повноти, послідовності і своєчасності даних.

• “Ми виконуємо перевірки якості даних після кожного запуску конвеєра — перевірки на нульові значення, перевірки на дублікати і перевірки цілісності посилань.” *

Каталог даних

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

“Каталог даних показує, що стовпчик customer_id у таблиці замовлень відповідає стовпчику id у таблиці клієнтів.”

Схема еволюції

** Еволюція схеми ** — це керування змінами структури даних з плином часу — додавання стовпчиків, перейменування полів, зміна типів даних.

“Ми використовуємо Apache Iceberg, тому що він граціозно обробляє еволюцію схеми — ми можемо додавати стовпчики без переписування всієї таблиці.”

---

Корисні фрази для обговорення інженерних даних

Розглянемо архітектуру

• “Ми розглядаємо можливість переходу на схему “lakehouse”, щоб зменшити дублювання між нашим озером даних і складом.”
• “Підхід ELT дозволяє нам швидко завантажувати необроблені дані і ітерувати перетворення без повторного вживання.”
• • “Ми використовуємо dbt для всієї нашої логіки перетворення — вона дає нам контроль версій, тестування і послідовність безпосередньо з коробки.” *

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

• “Конвейєр має ворота якості даних — якщо якийсь тест зазнає невдачі, моделі нижче не виконуються.”
• “Ми відстежуємо SLO свіжості для кожної таблиці марту — март замовлень повинен бути оновлений протягом двох годин після висадки даних джерела.”

Розглядають випадки

• • “На панелі інструментів показувалися застарілі дані, оскільки завдання Airflow зазнало невдачі о 03: 00. Лінійка допомогла нам відстежити, які моделі були вражені.»*

---

Словник інженерії даних все більше стандартизується в індустрії, в основному завдяки сучасному стеку даних (dbt, Snowflake / BigQuery, Airflow, Fivetran). Вивчення цих термінів допоможе вам читати документацію, брати участь у обговоренні проекту і точніше спілкуватися з аналітиками даних, інженерами з аналітики і науковцями з даних.

Національні мови: мова, що використовується для спілкування між ненаціональними групами

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

Однією з поширених проблем є тонкі відмінності у формулюванні, що впливають на ясність. Наприклад, рідний мовець може сказати «Давайте оптимізуємо цей запит» — хоча це технічно коректно, це може звучати вкрай вимогливо. Більш дипломатичний підхід, особливо при перегляді чиєїсь роботи, буде “Чи можемо ми дослідити потенційні оптимізації для цього запиту? Можливо, додавання індексу або зміна стратегії з’ єднання може покращити швидкодію. » Формування запитів у вигляді питань сприяє співпраці і уникненню обов’ язкового звучання. Аналогічно, опис проблеми з точки зору * впливу *, а не просто заява про проблему може бути неймовірно ефективною. Замість того, щоб сказати «Дані неправильні», спробуйте «Ця невідповідність у цифрах продажів впливає на нашу здатність точно прогнозувати попит»

Іншим частим камінням преткнення є розуміння нюансів зворотного зв’язку. Отримати коментар на кшталт «Це потребує більше контексту» не обов’язково є критикою; це запрошення до пояснення. Це може означати, що рецензент не розуміє * чому * ви прийняли певне рішення, або що їм потрібна додаткова інформація, щоб оцінити ваші аргументи. Відповідь на зразок: «Я розглядав [розуміння], коли робив цю зміну. Чи хотіли б ви, щоб я розглянув будь-який аспект мого процесу мислення?» демонструє залучення і проактивно звертається до основної проблеми. Не бійтеся просити про пояснення — набагато краще шукати розуміння, ніж приймати за нерозуміння.

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

Ось приклад, який показує, як jq можна використовувати для фільтрування даних і підкреслює важливість точного визначення бажаного результату:

jq '.[] | select(.price > 100) | .name' data.json

Ця команда бере файл JSON з назвою data.json, фільтрує записи, у яких поле « price » більше 100, а потім витягує поле « name » з цих фільтрованих об’ єктів. Коли ви повідомляєте це колегі, ви хочете бути точним: «Я хочу, щоб ви використовували jq для вилучення назв всіх продуктів з ціною понад $100 з файлу data.json»