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

Дана сітка є соціотехнічним підходом до архітектури даних, який розподіляє власність аналітичних даних командам, які їх виробляють. Введений Zhamak Dehghani в 2019 році, він швидко розробив свій власний словник, який поєднує інженерію даних, дизайн, орієнтований на домені, і платформне мислення.

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

---

4 принципи оцінки цінності інформації

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

1. Власник домену

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

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

2-й. Дані як продукт

У даних mesh, набори даних розглядаються як ** дані продуктів ** - першого класу активи з власниками, споживачами, SLA, документації, і гарантії якості.

“Продукт даних не є сирим зливом даних — він повинен бути знайденим, зрозумілим, надійним і взаємодіючим.”

• “Продукт даних Customer 360 належить команді Customer Experience. Він має документовану схему, SLA свіжості 15 хвилин і рейтинг якості даних, опублікований в каталогу даних. “*

3-й. Платформа самообслуговування даних

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

“Платформа самообслуговування надає командам домену шаблони для створення продуктів даних, автоматизовану реєстрацію схем і стандартний стек спостережливості — все доступне без відкриття квитка.”

• “Без платформи самообслуговування, кожна команда домену повинна наймати власних спеціалістів з інфраструктури. Платформа абстрагує цю складність.»*

4-й. Федеральне управління комп’ютерних систем

Federated computing governance розподіляє відповідальність за встановлення правил між командами домену, використовуючи автоматизацію для послідовного застосування правил у масштабі.

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

---

Продуктовий словник даних

Контракт з даними

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

• “Перед використанням продукту даних Замовлення, кожна команда, що виконує наступний крок, має підписати договір на обробку даних. Якщо виробник повинен зробити зміну схеми розбиття, вони повинні повідомити всіх власників контракту за 30 днів до цього. “*

Схема реєстрації

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

• “Всі теми Kafka на нашій платформі повинні мати схеми, зареєстровані у реєстрі схем. Це забезпечує правила сумісності і запобігає змінам від тихого розбиття споживачів. “*

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

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

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

---

Інтероперабельність і стандарти

Interoperability

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

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

Глобальний ідентифікатор

** Глобальний ідентифікатор ** це спільний ключ, який використовується у всіх продуктах даних домену для зв’ язку об’ єктів (наприклад, клієнта, замовлення або продукту) між доменами.

• “Без глобального ідентифікатора клієнта, узгодженого між доменами, приєднання до продуктів даних Замовлення і поведінка клієнтів потребувало б крихкої, нетипової логіки відображення.” *

---

Правознавство та правознавча література

Кваліфікаційні вимоги

** SLA якості даних ** визначає вимірювані зобов’язання щодо якості, які власник продукту даних робить для споживачів - зазвичай, що стосуються свіжості, повноти і точності.

• « Продукт даних транзакцій має SLA свіжості п’ ять хвилин і SLA повноти 99, 9%. Вони автоматично моніторяться і виявляються в каталогу даних.”*

Спостереження за даними

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

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

---

Практичні фрази для архітекторів мережі даних

• • “Це продукт даних домену — він має належати команді з платежів і публікуватися не на центральній платформі даних.” *
• “Нам нужен договор на передачу данных, прежде чем эта зависимость потребителя станет неявной и неизменяемой.”
• “Платформа самообслуговування зменшує бар’єр для команд домену, щоб стати виробниками даних.”
• “Федеративне управління дозволяє нам встановити захисні огорожі один раз і застосовувати їх скрізь — без ручного перегляду.”
• • “Каталог даних є механізмом виявлення для нашої мережі. Якщо продукт даних не в каталозі, він фактично не існує.»*

---

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

Навигація по нумерації: практичний підхід до термінології

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

Роздуми через сценарії англійською допомагають закріпити розуміння. Уявіть розмову на Slack: «Гаразд, команда Northwind повинна оновити свою схему клієнтів. Чи можемо ми отримати від них визначення спільного формату адреси за допомогою наших стандартів співпраці, щоб він відповідав очікуванням домену фінансів? » Зауважте багатошарове значення — це не тільки про зміну схеми, але також про дотримання стандартів і вирівнювання між доменами. Під час перегляду коду такі фрази, як «цей продукт даних потребує більш детального попередника» або «відповідь API повинна бути задокументована за допомогою нашої стандартної схеми» є неймовірно важливими. Сфокусування на тому, * чому * рекомендується певний підхід - «для забезпечення відстежуваності» або «для полегшення інтеграції» - додає важливий контекст і допомагає вам ефективно сформулювати своє розуміння. Це про активне слухання для основного намір, а не просто перекладати слова.

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

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

jq '.[] | if .customer_segment == "Retail" then .name + ": " + .email else empty end' data.json

Ця команда бере файл JSON ( data.json ) і фільтрує його, щоб включити лише імена клієнтів і адреси електронної пошти, де атрибут customer_segment дорівнює « Роздрібна торгівля ». Це демонструє, як атрибути, специфічні для домену, використовуються для цілей доступу і обробки, вирівнюючи концепцію самообслуговуючих продуктів даних.