Повний посібник з англійської для Дата-інженерів

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

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

Словниковий запас сучасної інженерії даних багатий спеціалізованою термінологією: ETL і ELT, озера даних і будинки озер даних, схеми складів і таблиці фактів, моделі dbt і стратегії матеріалізації, теми Kafka і групи споживачів, завдання Spark і стратегії розділення. Якщо ви перебуваєте на англомовній нараді, де обговорюється розробка схеми, вирішується проблема з помилкою конвеєра або презентується звіт про якість даних бізнес- аналітиці, вам слід знати, як точно і вільно використовувати ці терміни.

Англійська мова є домінуючою мовою екосистеми інженерії даних. Документація dbt, навчальні посібники Databricks, документи з розробки Kafka, посібники Apache Spark, а також переважна більшість розмов на конференціях з інженерії даних (Data Engineering Podcast, Locally Optimistic, поточні події на Data Council) — все це англійською мовою. Вміння читати і робити внесок у дискусії в цих спільнотах без мовного бар'єру є значною професійною перевагою.

У розділах нижче наведено певний англійський словник і шаблони спілкування, які потрібні інженерам даних: мова проектування конвеєрів і ETL, обговорення моделювання даних, презентація даних зацікавленим особам, перегляд SQL, керування якістю даних і спілкування в гнучких спринтах. Остаточний розділ охоплює словниковий запас, який найчастіше виникає в технічних інтерв'ю в компаніях, що спеціалізуються на інженерії даних.

Розділ 1: ETL/ELT Pipeline Communication

Шаблони Extract-Transform-Load (ETL) і Extract-Load-Transform (ELT) є словниковою базою для майже кожного обговорення конвеєра даних. Бути точним щодо того, який шаблон ви використовуєте — і чому — це важлива інженерна комунікаційна вправа.

Описуючи ETL/ELT Pattern

Конвейери ETL обробляють дані перед їх завантаженням: «Ми витягуємо необроблені події clickstream з теми Kafka, застосовуємо перетворення для нормалізації формату часових позначок і фільтрування трафіку ботів, а потім завантажуємо чисті записи до таблиці фактів Redshift. » ELT змінює порядок: « Ми спочатку завантажуємо необроблені відповіді API до озера даних, а потім виконуємо перетворення за допомогою моделей dbt всередині самого сховища. Це дає нам гнучкість для повторного запуску трансформацій без повторного вживання джерел даних»

Ключові слова ETL/ ELT: ingest (для введення необроблених даних до системи), transform (для зміни форми або очищення даних), load (для запису даних до місця призначення), backfill (для переобробки історичних даних), orchestrate (для розкладання і координації кроків конвеєра), idempotent (безпечний для повторного запуску — дає той же результат). Приклад: «Конвейер є ідемпотентним — якщо він зазнає невдачі і ми перезапускаємо його, вивід ідентичний. Ми досягаємо цього, вставляючи на ID події, а не додаючи.»

Підтримка архітектури Pipeline

Під час розробки або перегляду архітектури конвеєра, лексика стає більш архітектурною. « Нам слід обрати між пакетним конвеєром і потоковим конвеєром. Пакетна обробка дає нам простіші операції і легше заповнення, але вводить затримку. Потік даних з Kafka надає нам дані майже у реальному часі, але значно збільшує складність операцій. » Поширені фрази для обговорення архітектури: « Цей конвеєр має одну точку відмови на рівні поглинання. » / « Нам потрібно додати чергу мертвих літер для записів, які не пройшли перевірку — зараз вони мовчки скидаються. » / « Крок перетворення тісно пов’ язаний зі схемою джерела — будь- які зміни в API початкового рівня пошкодять його. »

Говорячи про моніторинг конвеєра: «Ми моніторимо конвеєр, використовуючи метрики тривалості завдання Airflow і встановлюємо SLA на щоденне завдання завантаження — якщо воно не було завершено до 6 ранку, ми отримуємо посилання.» / «SLA свіжості даних для цієї таблиці становить 4 години — зацікавлені сторони очікують, що дані будуть актуальними протягом 4 годин від системи джерела.» / «Ми попереджуємо про аномалії обсягу даних — якщо кількість рядків падає більше ніж на 20% порівняно з 7-денним середнім, ми припускаємо, що джерело вгорі має проблему»

Розділ 2: Дискусійний словник моделювання даних

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

Складська мова схем

Традиційний словник складу даних зосереджений на розмірному моделюванні: «Ми будуємо зіркову схему. У центральній таблиці фактів містяться події замовлення — кожен рядок є одним рядковим елементом з кількістю і сумою доходу. Таблицю фактів оточують таблиці розмірів для клієнтів, продуктів, дат і географічних регіонів. Ключеві терміни: таблиця фактів (таблиця вимірів або подій), таблиця розмірів (таблиця описових атрибутів), зерно (рівень деталізації рядка у таблиці фактів), повільно змінюваний розмір (вимір, у якому атрибути змінюються з плином часу), сурогатний ключ (системно створений первинний ключ, відокремлений від бізнес- ключа).

При обговоренні зерна: «Перед тим, як ми розробимо цю таблицю фактів, ми повинні погодитися на зерно. Зберігати один рядок на замовлення, чи один рядок на елемент рядка замовлення? Різниця має величезний вплив на те, як бізнес-користувачі можуть агрегувати дані. "При обговоренні повільно змінюються розмірів: "Вимір клієнта потребує лікування типу 2 SCD - нам потрібно відстежувати історичні адреси, тому що ми обчислюємо регіональну атрибуцію прибутків, використовуючи адресу на час замовлення, а не поточну адресу. "

Львівський і Дніпропетровський лісгоспи

Сучасні платформи даних ввели новий словник. Архітектура медальйону (бронзові / срібні / золоті шари) описує уточнення даних: «Бронзовий шар містить необроблені, необроблені дані точно так, як вони прийшли з джерела. Срібло застосовує базову чистку і стандартизацію. Gold містить готові до використання агрегати, розроблені для конкретних випадків аналітичного використання»

dbt (data build tool) вводить власну термінологію: «Ми створюємо метрику вартості життя клієнта як модель dbt. Це вигляд у срібному шарі, який з'єднує модель замовлень, модель платежу і вимір клієнта. Ми матеріалізуємо її як таблицю під час першого запуску, а потім скористаємося інкрементальною матеріалізацією для оновлення її під час наступних запусків, обробляючи лише нові замовлення за останні 3 дні. Ключові терміни dbt: model (файл SQL, який визначає перетворення), materialisation (яким чином модель зберігається — перегляд, таблиця, інкрементальний, ефемерний), ref() (функція dbt, яка посилається на іншу модель, створює DAG), test (твердження dbt щодо даних, наприклад, унікальність або ненуль), lineage (графік залежності моделей).

Розділ 3: Зацікавлені сторони повідомляють лексику

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

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

Зацікавлені сторони турбуються про те, чи можуть вони довіряти даним і чи є вони достатньо новими, щоб приймати рішення. Комунікація цього вимагає певного словника: "Таблицю замовлень оновлюють на 4-годинному циклі оновлення - дані на панелі завжди не старші 4 годин. Якщо вам потрібні цифри в реальному часі для внутрішньоденного прийняття рішень, нам потрібно буде побудувати потоковий конвеєр, який буде тритижневим інженерним зусиллям." / "Ми маємо систему моніторингу якості даних, яка виконує перевірки на кожному завантаженні конвеєра. Якщо будь- яка перевірка зазнає невдачі — наприклад, якщо первинний ключ дублюється, або якщо кількість записів впаде більше ніж на 20% — конвеєр зупиняється і попереджає інженера, який знаходиться на зв’ язку. Це означає, що коли дані присутні в панелі, вони пройшли наші ворота якості»

Коли конвеєр не працює і зацікавлені сторони помічають застарілі дані: «Щоденна завантажувальна робота зазнала невдачі о 2 годині ранку через зміну схеми в системі CRM. Ми виявили проблему о 6 годині ранку і виправлення було впроваджено. Зараз канал заповнює пропущений період — ми очікуємо, що дані будуть повністю оновлені до 10 ранку. Ми надамо пост- смертну записку до кінця дня. « Цей вид чіткого, структурованого спілкування — визнання проблеми, пояснення причини і надання графіка відновлення — є необхідним для підтримки довіри зацікавлених сторін.

Зміни в інфраструктурі та транспорті

Коли інженери даних пропонують міграцію (наприклад, перехід з кластера Hadoop до Databricks або зі сховища даних до озера), зацікавлені сторони повинні розуміти вплив бізнесу: «Ми пропонуємо мігрувати платформу аналітики з Redshift до Databricks Delta Lake. Міграція триватиме приблизно шість тижнів. Під час переходу існуючі панелі управління будуть продовжувати обслуговуватися з Redshift. У момент переходу всі історичні дані будуть мігровані, і нові запити будуть запущені проти Delta Lake. Основною перевагою для бізнесу є 3- х разове скорочення часу запиту для найбільших ad- hoc запитів, і 40% скорочення вартості інфраструктури." Ключові слова: cutover (момент переходу від старої до нової системи), migration, parallel run (запуск старих і нових систем одночасно для перевірки виводу), decommission.

Розділ 4: Перегляд SQL і перегляд коду мови

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

Опис SQL-запитів

Коли ви пояснюєте SQL-запит колегі: «Цей запит приєднує таблицю замовлень з розмірністю клієнта на ідентифікаторі клієнта, фільтрує замовлення за останні 30 днів за допомогою часового штампу події, групує за сегментом клієнтів і агрегує загальний прибуток і середню вартість замовлення за сегментом. Після цього клаузула HAVING фільтрує дані до сегментів з принаймні 100 порядками в періоді. » Ключові дієслова опису SQL: join, filter, aggregate, group by, sort by, partition by (функція вікна), rank, deduplicate.

Під час перегляду запиту на швидкодію: « Цей запит буде дуже повільним у таблиці замовлень — він виконує повне сканування таблиці, оскільки застосовує функцію до стовпчика event_ timestamp у клаузулі WHERE, що заважає роботі обрізання розділів. Ми повинні переписати його, щоб фільтрувати за допомогою стовпчика розділу даних безпосередньо." / "Підзапит у клаузулі SELECT є кореляційним підзапитом — він виконується один раз для кожного рядка у зовнішньому запиту. При 10 млн рядках, це буде катастрофа. Ми повинні переформатувати це як LEFT JOIN або функцію вікна. » Поширені фрази SQL: « Це буде дорого, тому що... », « Ми повинні додати індекс до... », « Цей запит не враховує розділи — він сканує всі розділи. », « Ми можемо спростити це за допомогою CTE. »

Коментарі до перегляду коду для моделей dbt

Перегляд моделей dbt вимагає додаткової лексики: "Виклик ref() тут створює залежність від моделі замовлень — переконайтеся, що модель була перевірена перед запуском цієї моделі." / "Ця модель матеріалізована як перегляд, але на неї посилаються 12 моделей нижче за течією і її обчислення досить дорогі. Я б запропонував матеріалізувати її як таблицю або використовувати інкрементну матеріалізацію." / "Тестування для цієї моделі є неповним — немає тесту унікальності на стовпці order_id. Будь ласка, додайте тест dbt." / "Документація моделі відсутня. Будь ласка, додайте запис schema. yml з описом для кожного стовпчика. "Перегляньте словник: materialisation, ref (), lineage, test coverage, schema. yml, incremental.

Розділ 5: Дискусійний словник якості даних

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

Описує виміри якості даних

Якість даних зазвичай описується за шістьма вимірами: повністю (чи всі очікувані записи присутні? Чи заповнені обов’ язкові поля?), точність (чи відображаються значення у реальному часі?), послідовність (чи збігаються дані у різних системах?), своєчасність (чи є дані достатньо свіжими?), коректність (чи відповідають значення очікуваним форматам і діапазонам?) і унікальність (чи є дублікати записів?). Приклад використання: «У нас є проблема повноти в стовпці опису продукту — 23% рядків мають нульове значення там.» / «Є проблема послідовності між таблицею замовлень і системою виконання — лічильники замовлень не збігаються.» / «Поле електронної пошти клієнта має проблему чинності — 1,2% рядків містять значення, які не є чинними адресами електронної пошти.»

Словник якості даних на практиці: перевірка (перевірка даних за правилами), порівняння (порівняння двох наборів даних для підтвердження їх збігу), видалення дублікатів (вилучення дублікатів записів), виконання схеми (вимога до даних відповідати визначеній структурі), виявлення аномалій (автоматичне виявлення незвичайних шаблонів даних), договір щодо даних (формальна угода між виробником і споживачем щодо схеми даних і SLA). Приклад: «Ми реалізували контракт на дані з командою мобільного додатку. Вони зобов’ язуються підтримувати схему подій протягом 90 днів перед тим, як відмовитися від будь- якого поля, і ми зобов’ язуємося будувати наш конвеєр на версії схеми, яку вони декларують. Це запобігає безшумним змінам, які спричинили два відключення трубопроводу в минулому кварталі»

Мова контролю якості даних

При налаштуванні моніторингу якості даних: «Ми використовуємо Великі очікування, щоб визначити набір очікувань для таблиці замовлень. Комплект перевіряє, чи є ідентифікатор_ замовлення унікальним і не нульовим, чи є сума доходу додатною, чи стовпчик стану належить до набору коректних значень, і чи число рядків за день не перевищує 20% від середнього значення за 7 днів. Якщо якесь очікування зазнає невдачі, конвеєр зазнає невдачі і виникає попередження. / "Ми додали перевірку свіжості даних до панелі управління Grafana — вона показує час з моменту останнього успішного виконання конвеєра для кожної критичної таблиці. SLA для таблиці замовлень становить 4 години."

Розділ 6: Планування спринту для команд даних

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

Інженерно-технічна робота

Оцінка є особливо складною для інженерії даних, тому що проблеми якості даних, зміни схеми в системах-джерелах і обмеження інфраструктури можуть значно збільшити необхідні зусилля. Ясно повідомити про цю невизначеність є важливим: «Я оцінюю цей трубопровід на 5 днів інженерних зусиль, але є дві значні невідомі. По-перше, я не знаю якості джерельних даних — ми тільки виявимо проблеми, коли почнемо вживання, а виправлення проблем з якістю даних може додати 2-3 дні. По-друге, схема системи джерела не задокументована. Я побудував шип, щоб провести 1 день, щоб зрозуміти це, перш ніж зобов'язатися до повної оцінки»

Словник планування спринту, специфічний для команд даних: spike (дослідження з часовими рамками), data discovery (розуміння схеми нової системи джерела і якості даних), proof of concept (PoC) (мінімальна реалізація для перевірки технічної можливості), backfill (заповнення історичних даних — часто окремий елемент роботи), scope creep (обсяг конвеєра розширюється за межі початкових вимог). Приклад: «Я хочу позначити потенційне порушення обсягу на цьому квитку. Початковою вимогою було побудувати трубопровід для замовлень ЄС. Після розмови з аналітиками, вони тепер хочуть також історичні дані за останні 3 роки. Заповнення само по собі займає окремий тиждень роботи — чи повинні ми створювати окремий квиток для цього?»

Блокування та блокування зв'язків

Конвейери даних сильно залежать від систем і команд, що виходять з них. Яскраве повідомлення блокувальникам і відповідне ескалація є критичним вмінням: «Я заблокований на конвеєрі Salesforce — мені потрібен доступ для читання до об'єкта Opportunities у виробничому екземплярі Salesforce. Я подав запит в адміністраторську команду Salesforce, але не чув відповіді вже 3 дні. Чи можете ви допомогти ескалації цього?» / «Це завдання залежить від команди мобільного додатку, яка завершує реалізацію відстеження подій. Вони планують розгорнути його наступного вівторка, але я ризикую - якщо вони прослизнуть, наше зобов'язання спринту під загрозою. Я буду стрімко, якщо щось почую»

Розділ 7: Інтерв'ю Словник для інженерів даних

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

Основний технічний словник

Словник інтерв'ю для інженерії даних зосереджений на наборі ключових технічних концепцій. Data warehouse vs data lake vs data lakehouse : «Склад даних зберігає структуровані, оброблені дані в моделі схеми-при-записі. Озеро даних зберігає необроблені дані у своєму власному форматі — схема- при- читанні — що дає гнучкість, але вимагає більшої роботи з перетворенням. Data lakehouse поєднує можливості структурованих запитів і ACID-транзакцій складу з недорогим сирим зберіганням озера, використовуючи формати, такі як Delta Lake або Apache Iceberg

Пакетне проти потокового: "Пакетна обробка працює за розкладом - щодня, щогодини - і простіше в експлуатації, але вводить затримку. Обробка потоків з Kafka і Flink або Spark Streaming дозволяє обробку даних майже в реальному часі, але є операційно складнішою і важче переробляти історичні дані. Вибір залежить від вимог щодо затримки в конкретному випадку використання.» Spark : « Apache Spark — це фреймворк розподілених обчислень для обробки даних у великому масштабі. Він виконує обчислення в пам'яті по кластеру, що робить його набагато швидшим, ніж MapReduce для ітеративних алгоритмів. Я використовую його для великих завдань перетворення, які перевищують можливості одного складу. Kafka : « Apache Kafka — це платформа для розподіленого потокового передачі подій. Вона діє як довговічна, високопродуктивна черга повідомлень. Ми використовуємо його як надійну шину подій між службами, що дозволяє нам асинхронно вводити потоки подій в платформу даних без з'єднання джерельних систем з конвеєром. "

Обговорення dbt і Modern Data Stack

«Сучасний стек даних» є поширеною темою інтерв'ю: «Я працюю з сучасним стеком даних: Fivetran для вживання даних з SaaS-джерел, Snowflake як хмарний склад даних, dbt для трансформацій — які ми затверджуємо в git і розгортаємо через GitHub Actions — і Looker для бізнес-інтелекту. dbt є шаром трансформацій, який замінив наші ad-hoc SQL-скрипти. Кожна модель має версію, перевірену і задокументовану. Ми маємо повний потік даних від джерела до панелі управління»

При обговоренні компромісів у рішеннях щодо дизайну: «Ми вирішили використовувати шаблон ELT, а не ETL, тому що наш склад — Snowflake — має достатню обчислювальну потужність, щоб обробляти перетворення дешевше і в масштабі. Перевагою є те, що ми завжди маємо необроблені дані в сховищі, отже, якщо нам потрібно додати нове перетворення або виправити історичну проблему, нам не потрібно перезаписувати з джерела. Компроміс полягає в тому, що сирі дані на складі можуть містити PII, що вимагає ретельного контролю доступу." Такий вид обговорення компромісів - заява про рішення, обґрунтування і компроміси - це те, що шукають співрозмовник на старших рівнях.

Найбільш корисні слова та фрази для інженерів даних

Рекомендований навчальний шлях для інженерів даних

Стадія 1: Фундація — Основний словник даних

1. 1-й

   Інженерно-технічний словник

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

2. 2-й

   Інженерно-технічна документація

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

3. 3-й

   Бази даних

   Освоєння лексики SQL і бази даних, що використовується під час перегляду коду і обговорення архітектури: запит, індекс, нормалізація, міграція, кешування.

Стадія 2: Проміжна — трубопровід і якісне спілкування

1. 4-й

   Підтримка файлових систем

   Дієслова конвеєрів ETL/ELT: ingest, process, transform, validate, load — вправляються в реальних реченнях інженерії даних.

2. П'ять

   Архітектурно-планувальні роботи

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

3. 6-й

   Перегляд коду коллокації

   Англійська мова перегляду моделей SQL і dbt: запитування змін, адресування коментарів, обговорення швидкодії запиту і залишення реальних відгуків.

Стадія 3: Просунута — комунікація з зацікавленими сторонами та інтерв'ю

1. Сім

   Мова управління Stakeholder

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

2. 8-й

   Технічна мова інтерв'ю

   Визначте компроміси між сховищем даних і озерним будинком, поясніть рішення щодо проектування ETL/ ELT, а також обговоріть архітектуру Spark, Kafka і dbt у контексті інтерв’ ю.

3. Дев'ять

   Мова презентації

   Представте пропозиції щодо інфраструктури даних, плани переходу і звіти про якість даних аудиторії зацікавлених сторін, використовуючи чітку, структуровану професійну англійську мову.

Інформаційні технології для інженерів

Вправляйтеся у словниковому запасі і моделях спілкування, які описано у цьому підручнику, за допомогою таких груп вправ: