Як говорити про контракти з даними англійською мовою

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

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

** Реєстр схем ** Реєстр схем — це централізована служба, яка зберігає і керує визначеннями схем (зазвичай, Avro, Protobuf або JSON Schema). Виробники реєструють схеми перед публікацією даних; споживачі отримують їх для правильної десеріалізації. Команди «реєструють», «опубліковують», «пошукують» і «керують» схемами в реєстрі.

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

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

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

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

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

** Тестування пакту ** Pact є найпоширенішою структурою для тестування договорів, що керуються споживачами. Споживачі «писають тести Пакту», «опубліковують Пакти» і «перевіряють контракти» проти Брокера Пакту. Виробники «перевіряють» споживчі пакти перед розгортанням.

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

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

• Приклад: « Ми працюємо з версією 3. 1 — оновлення до 4. 0 є критичним кроком, тому ми будемо запускати обидві версії паралельно під час вікна міграції. » *

** Дані SLA ** Договором про рівень обслуговування (SLA) визначаються гарантії якості та своєчасності, які виробник даних зобов’язується забезпечити, наприклад, свіжість (дані надходять протягом 30 хвилин після події), повність (не більше 0,1% відсутніх записів) та доступність (схема є чинною 99,9% часу).

• Приклад: « Договором про рівень обслуговування даних для конвеєра clickstream гарантується, що події будуть доступні у сховищі протягом 15 хвилин після їх виникнення. » *

** Виробник / споживач ** У контексті конвеєра даних, виробник є системою, яка генерує і публікує дані; споживач є системою, яка читає і обробляє їх. Цей словник походить з систем обміну повідомленнями, таких як Kafka, і зараз є стандартом у інженерії даних.

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

Фрази і фразеологізми

** “зареєструвати схему” ** Дія додавання нової схеми або версії схеми до реєстру схем. Завжди « register » — не « upload » або « push »

• Приклад: « Перед випуском нового типу події зареєструйте схему у реєстрі і підтвердіть, що вона пройшла перевірку сумісності. » *

“опублікувати пакт” Використовується, коли користувач ділиться своїми очікуваннями щодо договору з брокером Pact. « Опублікувати » — це стандартне дієслово у потоках роботи Pact.

• Приклад: “Конвейєр CI публікує пакт брокеру після кожного тестового запуску споживача, тому виробник завжди може перевірити його на відповідність останнім очікуванням.” *

** “зворотньо сумісна зміна” ** Безпечна модифікація схеми, яку існуючі користувачі можуть обробляти без змін. Скористайтеся цією фразою, щоб повідомити, що зміна безпечно розгортати. Приклад: “Додання додаткового поля metadata є зворотньо сумісною зміною - споживачі, які не знають про це, просто проігнорують його.”

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

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

• Приклад: « Задача ETL порушила договір, опублікувавши нульові значення у полі, яке було визначено як не нульове — завдання споживача завершилося аварійно. » *

Практичні рекомендації

1. «Ми повинні версувати цю зміну контракту, тому що видалення застарілого поля є зміною для двох споживачів нижче по течії»
2. «Реєстр схеми заблокував розгортання, тому що нова схема не є зворотньо сумісною з поточною зареєстрованою версією.»
3. «Спостереження за даними SLA вимагає свіжості протягом однієї години — попередження про моніторинг спалахує, коли останній розділ старший за 90 хвилин»
4. «Чи можете ви написати тест Pact, щоб задокументувати, які поля ваш сервіс читає з теми профілю користувача?»
5. «Перевірка сумісності вперед зазнала невдачі, тому що старий код споживача не знає, як обробляти нове обов’язкове поле.»

Необхідно уникати помилок

Скажите “контракт”, когда вы имеете в виду “схему” Схема визначає структуру даних (назва полів, типи). Контракт на дані включає схему, але також покриває якість, доступність, SLA, власність і політику версії. У обговоренні договору з даними, будьте точними щодо того, чи ви маєте на увазі конкретну схему чи більш широкий контракт.

** Плутанина « назад » і « вперед » сумісності ** Це дуже поширена помилка навіть серед носіїв рідної мови. Зворотна сумісність означає, що старі користувачі працюють з новими даними. Сумісність вперед означає, що нові користувачі працюють зі старими даними. Корисний пам’ ятний: « backward » = ви можете повернутися назад (старий код все ще працює).

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

Summary

Словник договорів з даними — реєстр схем, режими сумісності, зміни, що порушують, контракти, що керуються споживачами, тестування пакту і SLA даних — є спільною мовою сучасних команд інженерів даних. Використання цих термінів у технічних документах, документах з проектування трубопроводів і оглядах подій показує, що ви розумієте як технічні концепції, так і спільну природу створення надійних систем даних. Найкращі англійські ресурси в цьому просторі включають офіційну документацію Pact, сховище Data Contract CLI на GitHub, а також статті з блогів інженерії платформи даних в таких компаніях, як Airbnb, Netflix і Spotify.

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

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

Одна з поширених областей плутанини виникає при обговоренні «розривних змін» в договорі з даними. Просто сказати, що “Ця зміна порушує сумісність” недостатньо. Нерідний мовець може спробувати впоратися з наслідками. Замість цього, сформулюйте його більш чітко: «Це оновлення вводить зміну, яка перервала - конкретно, поле customer_id тепер обов’язкове і більше не нульове. Це означає, що існуючим користувачам цього договору на обробку даних слід буде оновити свої програми для виконання цієї нової вимоги. » Додання конкретних відомостей про те, що змінилося і чому, значно полегшить розуміння. Аналогічно, коли ви описуєте взаємодії з реєстром схеми, уникайте жаргонних слів на зразок « реєстрація схеми ». Замість цього спробуйте: « Ми додаємо цю оновлену схему до реєстру, щоб всі системи, що виконують цю дію, мали змогу дізнатися про останню версію і її обмеження ». Таким чином, ви поясните дію і її мету.

Іншою ключовою областю є пояснення даних SLAs - Угоди про рівень обслуговування - пов’язані з контрактами на дані. Часто, просто заявивши «ми повинні підтримувати 99,9% часу роботи для цього потоку даних» може бути неправильно інтерпретовано. Розбивати його: “Для того, щоб забезпечити надійну доставку оновлень каталогу продуктів, ми встановили SLA, що гарантує 99,9% рівень доступності для потоку даних. Це означає мінімальний час простою і швидке відновлення в разі будь-яких проблем - на даний момент наші інструменти моніторингу налаштовані на автоматичне виявлення і виправлення проблем протягом п’яти хвилин.” Кількісне оцінювання очікувань з ясними метриками і опис процесу відповіді є ключовим для уникнення неоднозначності.

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