Словник для архітектури мережі даних: продукти даних, домени і управління
Словник сітки основних даних: домен даних, продукт даних, федеративне управління, платформа самообслуговування даних і власність даних для обговорення сучасної архітектури даних.
Дана сітка, популяризована Zhamak Dehghani, є архітектурною парадигмою, яка децентралізує власність даних від центральної команди даних до доменных команд, які виробляють дані. Якщо ви працюєте в інженерії даних, аналітиці або на платформах, то вільне володіння цим словником стає все більш очікуваним.
4 принципи оцінки цінності інформації
Сетка даних базується на чотирьох принципах. Знання словника для кожного з них є обов’ язковим:
- Доменно-орієнтована децентралізована власність даних
- ** Дані як продукт **
- ** Інфраструктура даних самообслуговування як платформа **
- Федеративне управління обчисленнями
Доменні дані
** Домен даних ** це обмежена область бізнесу, вирівняна з організаційними можливостями (наприклад, «Клієнт», «Замовлення», «Запаси»). Кожен домен власник даних, які він виробляє.
Ключові фрази
- Домен Orders володіє канонічними даними про життєвий цикл замовлення
- «Ми ** вирівняли ** кожен домен даних до існуючої інженерної команди.»
- «Домен ** відповідає за ** якість і доступність своїх продуктів даних.»
- «Ми ** ідентифікували ** вісім доменів даних під час вправи з розкладання.»
Продюсером є Євген Коноплянка
- ** Домен- виробник ** — команда, яка створює дані і є їх власником
- ** Домен- споживач ** — будь- яка команда, яка використовує дані, опубліковані іншим доменом
«Команда маркетингу ** споживає ** дані з домену клієнта — вони не є виробником»
Інформаційний продукт
** Продукт даних ** є первинною одиницею сітки даних. Це відкритий, адресований, надійний набір даних, який команда домену публікує і підтримує як продукт - а не побічний продукт.
Якості продукту даних
(Восьми якостей Дехгані):
- ** Відкритий ** — знайдено у каталогу даних
- ** Адреса ** — має стабільний, унікальний ідентифікатор
- ** Надійний ** — визначено SLO і перевірки якості
- ** Самоописувальні ** — включає схему, метадані і документацію
- ** Сумісна з іншими програмами ** — відповідає загальним стандартам
- ** Натуральний доступ** — доступний за допомогою стандартних інтерфейсів
- ** Безпечний ** — контролюється доступ
- ** Цінний сам по собі ** — не просто витяг для одного випадку використання нижче
У розмові
- «Кожна команда опублікує один або більше продуктів даних зі свого домену.»
- Продукт даних ** виставляє ** стабільну схему і має SLO 99,9% доступності
- «Ми розглядаємо нашу таблицю подій як першокласний продукт даних, а не просто дамп журналу.»
- «Споживачі ** підписуються ** на продукт даних через платформу самообслуговування.»
Федеральне управління комп’ютерних систем
Федеративне управління означає, що правила управління (стандарти схем, правила якості, керування доступом) встановлюються глобально, але примушення до виконання здійснюється локально командою кожного домену, а не центральною командою з обробки даних.
Ключовий словник
- ** Глобальні правила ** — стандарти, які стосуються всієї організації і яких повинні дотримуватися всі домени
- ** Локальний контроль** — кожен домен реалізує правила у своєму власному конвеєрі
- ** Обчислювальний контроль ** — правила кодуються в програмному забезпеченні і застосовуються автоматично, без ручного аудиту
- ** Договір на надання даних ** — формальна угода між виробником і споживачем щодо схеми, якості і SLA
У реченнях
- Команда управління ** встановлює ** стандарти якості даних; кожен домен ** реалізує ** їх
- «Наші контракти з даними визначають версію схеми, SLO і процес повідомлення про зміну»
- «Управління є федерованим — немає центральної команди, яка схвалює кожну зміну даних»
- «Платформа примусить правила доступу автоматично на основі чутливих даних тегів.»
Платформа самообслуговування даних
** Платформа самообслуговування даних ** є шаром інфраструктури, який надає змогу командам домену створювати і публікувати продукти даних без допомоги центральної команди інженерів даних для кожного завдання.
Что она обеспечивает
- Шаблони конвеєра даних
- Реєстр схеми
- Каталог даних
- Датчики контролю якості
- Інтерфейси контролю доступу
Ключові фрази
- Команда платформи ** надає ** інструменти; команди домену ** використовують ** його автономно
- «Команда домену може встановити новий продукт даних за день, використовуючи шаблони платформи.»
- «Платформа ** абстрагує ** складність зберігання, обчислення і каталогізації.»
- «Ми вимірюємо прийняття платформи за кількістю продуктів даних, опублікованих за квартал»
Контрактний словник даних
Контракти даних є швидко розвивається практикою в мережі даних. Ключеві терміни:
| Term | Meaning |
|---|---|
| Producer | The team publishing the data |
| Consumer | The team using the data |
| Schema version | The version of the data structure (SemVer) |
| Breaking change | A change that is incompatible with existing consumers |
| Backward compatible | New schema works with old consumers |
| SLO | Service Level Objective for data freshness, quality, availability |
| Data quality dimension | Completeness, accuracy, timeliness, uniqueness |
Використання мови контрактів даних
- Ми ввели переломну зміну до схеми Замовлення — всі споживачі повинні оновити
- «Контракт визначає дані ** свіжість ** не більше 15 хвилин.»
- «Споживачі ** погодилися ** на контракт до того, як їх трубопровід був забезпечений»
Порівняння даних Mesh з іншими парадигмами
Під час обговорення, можливо, вам слід буде порівняти сітку даних з існуючими підходами:
| Approach | Description | Data mesh contrast |
|---|---|---|
| Data warehouse | Centralised storage, managed by one team | Data mesh distributes ownership |
| Data lake | Centralised storage, schema-on-read | Data mesh adds product thinking and governance |
| Data lakehouse | Hybrid warehouse+lake | Data mesh is an organisational pattern, not a storage technology |
| Data fabric | Metadata-driven, often centralised | Data mesh is decentralised; fabric is often centralised |
Ключеві моменти
- ** Домен даних ** — підрозділ власності на дані, що відповідає бізнес- вимогам
- ** Продукт даних ** — опублікований, надійний набір даних з SLO, схемою і можливістю виявлення
- ** Федеративне керування ** — глобальними стандартами, які локально виконуються командами домену
- ** Платформа самообслуговування ** — інфраструктура інструментів, яка дозволяє автономним командам домену
- ** Договір на надання даних ** — формальна угода виробника- споживача щодо схеми, якості та SLA
- Ключові дієслова: опублікувати, споживати, володіти, застосовувати, виявляти, підписуватися, впроваджувати
На практиці: Навігація нюансів — перспектива розробника
Будьмо чесними; коли ви боретеся з такими поняттями, як «продукти даних» або «доменно-орієнтований дизайн», це може здатися трохи абстрактним. Як не-рідні англомовні носії, особливо ті, що переходять в професійне середовище розвитку, точні формулювання і наслідки не завжди відразу ясно. Це не просто знання слів; це розуміння того, як вони використовуються в розмові і документації, і як вони формують прийняття рішень.
Нещодавно я провів розчаруючу годину, переглядаючи запит на нову функцію - давайте назвемо його «Спостереження за сегментацією клієнтів». Опис PR був… рідкісним. У ній згадується «продукт даних», але не вказано, * що * це за продукт, які дані він містить, чи хто його власник. Рецензент зазначив: «Це відчувається як значна залежність від даних маркетингового домену. Чи могли б ви пояснити обсяг цього продукту і як він інтегрується з існуючими панелями звіту? Чи є якісь засоби контролю доступу, необхідні для забезпечення відповідності з GDPR?” Ключовим тут є не тільки те, що він просить про пояснення; це як він формулює свої питання - використовуючи такі терміни, як “обсяг”, “інтеграція” і “контроль доступу”, які є ключовими в контексті Data Mesh. Ці фрази не просто технічний жаргон; вони представляють собою фундаментальний зсув у мисленні про власність даних, відповідальність і управління.
Інший приклад з’явився під час обговорення Slack щодо домену «Sales Performance». Розробник запитав, чи може він безпосередньо запитати необроблені дані транзакції, не проходячи через призначений продукт даних - попередньо агрегований перегляд, розроблений для звітів. Відповідь від команди була твердою: «Це не так працює, Марк. Пам’ятайте, що кожен продукт даних створюється з певними SLA і контролем доступу. Безпосередній доступ до цих необроблених даних обходить модель управління, яку ми встановили для підтримки якості і безпеки даних. Вам потрібно використовувати sales_reporting_api - це наш стандартизований інтерфейс для доступу до очищених і агрегованих даних про продажі. “Це ілюструє важливість розуміння * чому * певні процеси існують, а не тільки * що * вони роблять. Це стосується визнання того, що здавалося б прості запити можуть мати значні наслідки для цілісності даних і оперативної ефективності в рамках децентралізованої архітектури.
Нарешті, описуючи еволюцію домени «Дані клієнта», я побачив, як розробник використовує фразу «перехід до платформи даних самообслуговування». Він розробив: «Ми намагаємося надати командам домену інструменти, які дозволяють їм створювати власні продукти даних і керувати власними правилами управління в чітко визначених межах. Це зменшує залежність від центральних ІТ і прискорює час до отримання прибутку. » Основний принцип тут полягає в *розширенні прав * - надання кожному домену автономії для управління його активами даних, при цьому дотримуючись загальних стандартів управління. Це делікатний баланс, що вимагає чіткого спілкування і взаєморозуміння.
# Example: Using the sales_reporting_api to query for monthly revenue
curl -s "https://sales_reporting_api.example.com/monthlyRevenue?year=2023&month=10"Цей API надає змогу отримати попередньо агрегований перегляд, що забезпечує послідовність звітів і зменшує навантаження на базу даних транзакцій.