У далекому королівстві Даних панував хаос. Колись процвітаюча земля була розділена, поділена непорозуміннями та неефективністю. Дані, кров королівства, були розкидані по таємних сховищах, заховані серед гір силосів, і обтяжені стародавнім прокляттям застарілих відомостей.
Три відомі лиходії тероризували королівство роками:
- Тінь Невідомих Локацій Даних, що ховала важливу інформацію, роблячи її майже неможливою для пошуку.
- Перевертень Змінюваних Схем, що любив ламати запити і дратувати інженерів.
- Прокляття Застарілих Даних, через яке лідери королівства приймали погані рішення, спираючись на застарілу інформацію.
У розпачі, намагаючись відновити порядок, правителі королівства шукали рішення. Вони не потребували одного героя для боротьби з цими ворогами, їм потрібні були правильні інструменти та принципи, які б дозволили їхнім доменам повернути контроль. Це історія того, як вони впровадили модель даних Mesh, створивши децентралізовану, стійку систему, яка вигнала хаос і відновила процвітання.
Лиходії Хаосу
Тінь Невідомих Локацій Даних
У королівстві Даних величезні скарби інформації були заховані в таємних місцях. Кожен домен — Замовлення, Запаси, Клієнти та інші — ховав свої власні дані, приховуючи їх від інших.
Кожного разу, коли сміливий аналітик шукав відповіді, його зустрічала та сама розчарованість: "Де дані?" Ніхто не знав, де знайти потрібну інформацію. Центральний сховище даних, монолітний замок в столиці королівства, було переповнене запитами, що призводило до довгих затримок.
- Звіти готувались днями.
- Відділи звинувачували один одного у відсутності інформації.
- Громадяни королівства втомлювались від неефективності.
Перевертень Змінюваних Схем
Навіть коли загадкові дані знаходились, їх структура рідко була стабільною. Поля зникали без попередження, типи даних змінювались непередбачувано, і запити, що працювали вчора, сьогодні ламаються. Перевертень зрадів цьому хаосу, сіючи розчарування серед інженерів і аналітиків.
- ETL пайплайни несподівано збоїли.
- API ламались без попередження, спричиняючи збої.
- Команди боялись змін схем, втрачаючи години на відлагодження.
Прокляття Застарілих Даних
Останній і найпідступніший лиходій — це Прокляття Застарілих Даних. Рішення, що приймались у королівстві, базувались на даних, які були старі днями або навіть тижнями. Коли звіти доставлялись, інформація вже ставала непотрібною. Це прокляття призводило до пропущених можливостей, дорогих помилок та зростаючої недовіри до здатності королівства ефективно працювати.
- Рішення щодо запасів призводили до дефіциту або перенасичення.
- Тенденції клієнтів були застарілими, що призводило до поганих маркетингових кампаній.
- Лідери ставили під сумнів, чи можна взагалі довіряти даним.
Поклик до Дії
Правителі королівства зібрали найкращі уми з усього краю. Вони зрозуміли, що не можуть боротися з цими лиходіями поодинці. Відповідь полягала не в одному герої, а в зміщенні філософії: децентралізувати відповідальність, уповноважити домени та впровадити принципи mesh даних.
Модель даних Mesh — це не інструмент, а мислення — ставтесь до даних як до продукту, який належить і керується доменами, що найбільше знають його.
Правителі розробили план, зібравши потужні інструменти та створивши систему, яка назавжди вигнала цих лиходіїв.
Подорож до Моделі Даних Mesh
Основи: Власність Доменів
Перший крок у їхній подорожі — це децентралізація володіння даними. Кожен домен — Замовлення, Запаси, Клієнти — має володіти та керувати своїми даними. Вони будуть надавати свої набори даних як продукти, доступні іншим через API.
Реальний Паралель: Магазини в Районі
Замість одного величезного складу, що намагається забезпечити все королівство, кожен район відкривав свій власний магазин.
Ці магазини зберігали лише ті товари, в яких вони спеціалізувалися, і клієнти могли відвідати будь-який магазин, щоб отримати те, що їм потрібно.
Акт 1: Перемога над Тінню Невідомих Локацій Даних
Для боротьби з Тінню королівство створило Реєстр Метаданих. Цей реєстр слугував картою всіх даних королівства, детально описуючи, де знаходяться набори даних, хто їх власник та як до них можна отримати доступ.
Вхід до DataHub
Реєстр був підживлений DataHub, платформою для метаданих з відкритим кодом. Кожен набір даних реєструвався з деталями про свою схему, власника та методи доступу.
Приклад Реєстрації
Домен Замовлень зареєстрував
-H "Content-Type: application/json" \
-d '{
"name": "Orders",
"owner": "Orders Team",
"schema": {
"fields": [
{ "name": "id", "type": "integer" },
{ "name": "total", "type": "decimal" }
]
}
}'
```
З цим, Тінь Невідомих Локацій була вигнана. Тепер аналітики та інженери могли знаходити будь-які дані через реєстр.
Реєстр метаданих робить дані доступними, приносить світло в темні куточки королівства.
Акт 2: Перемогти Перевертня Змінюваних Схем
Наступним було звернення до Перевертня. Ключем до перемоги над цим ворогом стало версіонування схем. Створюючи контракти між виробниками даних і споживачами, вони забезпечили стабільність навіть коли схеми змінювались.
Реєстр Схем
Королівство впровадило Реєстр Схем для версіонування і валідації схем. Виробники повинні були реєструвати свої схеми, а споживачі могли бути впевнені, що їхні API залишатимуться сумісними.
Приклад Оборони
Домен Замовлень опублікував схему:
curl -X POST http://schema-registry/orders \
-H "Content-Type: application/json" \
-d '{
"version": "1.0.0",
"fields": [
{ "name": "id", "type": "integer" },
{ "name": "total", "type": "decimal" }
]
}'
Коли схема була оновлена, реєстр перевірив її на зворотну сумісність перед тим, як дозволити зміну.
Контракти схем приносять порядок в хаос, забезпечуючи надійність у світі змін.
Акт 3: Зламати Прокляття Застарілих Даних
Щоб зняти прокляття, королівство потребувало потоків даних в реальному часі. Вони впровадили NATS, легку систему повідомлень, для забезпечення асинхронної комунікації між доменами.
Як це працювало
- Сервіс Замовлень: Публікував події, як-от
order.created. - Сервіс Запасів: Підписувався на ці події, оновлюючи рівень запасів миттєво.
Приклад Події
Сервіс Замовлень публікував подію:
public void PublishOrderCreatedEvent(OrderDto order)
{
var orderEvent = JsonSerializer.Serialize(order);
_natsConnection.Publish("orders.created", Encoding.UTF8.GetBytes(orderEvent));
}
}
Сервіс Запасів підписувався на подію і оновлював свою базу даних:
var subscription = natsConnection.SubscribeAsync("orders.created");
subscription.MessageHandler += (sender, args) =>
{
var order = JsonSerializer.Deserialize(args.Message.Data);
UpdateInventory(order);
};
subscription.Start();
З потоками даних у реальному часі прокляття застарілих даних було знищене. Рішення тепер базувались на найсвіжішій інформації.
Повідомлення в реальному часі підтримує дані королівства свіжими, а рішення — точними.
Акт 4: Об'єднання Королівства
Останнім викликом було створення єдиного погляду на дані королівства.
Правителі впровадили Trino, федеративний двигун запитів, щоб забезпечити виконання запитів між доменами.
Уніфікований Запит
Один із громадян запитав деталі замовлення разом з іменами клієнтів:
curl -X POST http://gateway/query \
-H "Content-Type: application/sql" \
-d 'SELECT o.id, o.total, c.name FROM orders o JOIN customers c ON o.customer_id = c.id;'
Trino виконав запит до доменів Замовлень та Клієнтів, об'єднавши результати в один відповідь.
Федеративні запити дозволяють децентралізованим доменам спілкуватися спільною мовою.
Королівство Відновлено
З впровадженням data mesh, Королівство Даних процвітало:
- Невідомі локації стали доступними через реєстр.
- Змінні схеми були приборкані контрактами і версіонуванням.
- Застарілі дані були знищені завдяки повідомленням у реальному часі.
Злочинці були переможені не одним героєм, а завдяки наданню інструментів і принципів, що допомогли доменам королівства відновити контроль.
Справжня сила data mesh полягає в децентралізації, коли кожен домен стає опікуном своїх власних даних.
І так, Королівство Даних стало маяком порядку та інновацій, надихаючи інших розпочати свої власні подорожі до data mesh.
Які злочинці чекають у твоєму Королівстві Даних? Зберіть свої інструменти, об'єднайте домени та зробіть перший крок до побудови вашого data mesh сьогодні.
Перекладено з: The Quest for the Data Mesh: A Tale of Order Over Chaos