Англійська мова для Data Lakehouse Engineers

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

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

Лейкхаус Архітектура даних, яка зберігає дані у відкритих форматах файлів на дешевому об’ єкті зберігання (наприклад, на озері даних) з використанням шарів транзакційних гарантій, застосування схеми і оптимізації продуктивності, зазвичай пов’ язаних зі сховищем даних.

• Приклад: «Ми перейшли з традиційного складу на озерний будинок, щоб команди з науки про дані могли запитувати ті ж таблиці, що і команда BI, без окремого конвеєра ETL.» *

** Формат таблиці (Дельта озера, Айсберг, Худі) ** Відкрита специфікація, яка додає транзакційні метадані — схему, розділення і історію версій — до необроблених файлів (наприклад, Parquet) у об’ єкті зберігання, що забезпечує гарантії ACID на базі даних.

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

Архітектура медальйону Поширений шаблон дизайну lakehouse, який впорядковує дані у поступово перевірені шари: бронзові (сирі, необроблені), срібні (очищені і відповідні) і золоті (агреговані, готові до використання).

• Приклад: « Бронзовий шар зберігає необроблений JSON так, як він був введений; срібний шар дедуплікує і перевіряє його; золотий шар агрегує його до метрик, які запитують наші панелі управління. » *

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

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

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

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

Уплотнение Процес об’ єднання багатьох невеликих файлів даних у менші, більші файли для поліпшення швидкодії запиту, оскільки таблиці типу « lakehouse » можуть накопичувати надто малі файли через часті невеликі записи.

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

** З-упорядкування/кластеризація** Метод фізичного розміщення пов’ язаних даних у файлах на основі значень певних стовпчиків, таким чином, запити, які фільтрують за цими стовпчиками, можуть пропускати читання непов’ язаних файлів.

• Приклад: « Ми впорядкували цю таблицю за customer_id і event_date, що скоротило час сканування файлів нашого типового запиту більш ніж на 80% ». *

Договор на передачу данных Формальна, часто машинно-читаюча угода між виробником даних і його споживачами про схему набору даних, семантику і гарантії якості, призначені для запобігання безмовним змінам. Приклад: «Команда розробників змінила значення поля без попередження — якщо б у нас був контракт з даними на місці зі схемою і семантичними перевірками, це б не вдалося CI замість того, щоб безшумно порушувати наші золоті таблиці.»

Звичайні фрази

** В обзорах коду: **

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

В стоячих позах:

• «Вчора я встановив перевірку на основі подорожей у часі, щоб ми могли порівняти сьогоднішню золоту таблицю з вчорашньою перед публікацією; сьогодні я досліджую завдання стискання, яке закінчується»
• «Я заблокований на проблемі еволюції схеми — система джерела перейменувала поле, і наша срібна трансформація беззвучно скидає стару і нову колонки.»
• «Я закінчив міграцію Z-упорядкування на найбільшій таблиці фактів; середній час запиту впав з 40 секунд до менше ніж 8»

** У обговореннях архітектури: **

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

Фрази, яких слід уникати

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

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

Слово “склад” і “озерний будинок” взаємозамінні. Вони описують справді різні архітектури з різними гарантіями і профілями витрат. Точне вказування того, який з них ви маєте на увазі, уникає плутанини під час обговорення можливостей і обмежень між членами команди.

Краткий справочник

Term	How to use it
lakehouse	”The lakehouse lets BI and data science query the same gold tables.”
medallion architecture	”Bronze holds raw data; silver is cleaned; gold is business-ready.”
schema evolution	”Schema evolution let us add a column without rewriting the table.”
time travel	”We used time travel to inspect yesterday’s table version.”
compaction	”Nightly compaction merges small files to keep queries fast.”
Z-ordering	”Z-ordering on customer_id cut our scan volume significantly.”

Ключеві моменти

• Будьте точними щодо того, у якому шарі (бронзовий, срібний, золотий) розташовано проблему — це значно зменшить обсяг зневадження.
• Розумійте еволюцію схеми і подорожі у часі як можливості першого класу, а не як можливості крайнього випадку, під час проектування конвеєрів.
• Стиснення і Z- впорядкування/ кластеризація є стандартним словником для обговорення проблем з продуктивністю lakehouse, викликаних компонуванням файлів.
• Ніколи не вважати повторний запуск безпечним — описувати і перевіряти ідемпотентність явно перед тим, як рекомендувати її як виправлення.
• Контракти з даними стають стандартною практикою для керування схемами і семантичними змінами по всій команді - активізуйте їх у проектуванні міжкомандного конвеєра.

Національний гідрографічний інститут: Відповідь і відповіді

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

Розглянемо таку ситуацію: Ви надіслали запит на звантаження (PR) для оновлення схеми таблиці зберігання даних, щоб вмістити нові дані датчиків. Рецензент, Сара, залишає коментар до вашого опису PR: « Ця зміна вводить значну складність. Чи можете ви пояснити, як це впливає на послідовні запити і які стратегії відновлення є на місці, якщо нова схема спричиняє зниження продуктивності? ” Сара не просто критикує * зміну * сама по собі; вона піднімає занепокоєння щодо ширших наслідків для системи - якість даних, продуктивність запиту і оперативну стійкість. Фраза «значна складність» є тут ключовим показником. Это не значит, что твоя работа по сути плоха, но это сигнал, что нужно дальнейшее расследование и обсуждение. Важливо, щоб ти відповідав з розумом, демонструючи, що розумієш її занепокоєння. Хороший ответ мог бы быть: “Подтверждаю, Сара. Я додав розділ, в якому детально описано вплив на існуючі запити за допомогою команди explain analyze — особливо при пошуку потенційних повних сканувань таблиць. Ми також реалізували стратегію версії схеми з автоматичними можливостями відновлення, що запускаються порогами продуктивності запиту. ”

Іншою поширеною ситуацією є обговорення архітектури медальйону з колегою по команді в Slack. Ви можете сказати: « Я думаю про додавання ще одного шару до цього бази даних, щоб отримати більш детальні дані про події — ми дійсно можемо отримати користь від часового виміру ». Ваш колега відповість: « Це цікаво! Але як це поєднується з нашою теперішньою моделлю бронзи-срібла-золото? Чи ми готові до збільшення вартості зберігання і потенційної складності управління запитами на подорожі у часі?» Ключовим тут є розпізнавання встановленої термінології (« бронза », « срібло », « золото ») і розуміння її наслідків. Просто оголосити ваш намір недостатньо; вам потрібно сформулювати, як це вписується в більшу архітектурну структуру і активно вирішувати потенційні операційні проблеми. Це про демонстрацію цілого розуміння дизайну системи.

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

Ось приклад того, як ви можете використовувати dbt для перевірки швидкодії запиту після зміни схеми:

-- Inspecting query performance after a schema update using dbt
SELECT
  query_id,
  execution_duration,
  num_rows,
  distribution_cost
FROM
  performance_metrics
WHERE
  query_text LIKE '%new_sensor_data%' -- Filter for queries related to the changed table
ORDER BY
  execution_duration DESC;

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