Сумісність схем, API та потоків даних під час змін

Data Architecture / Schema Evolution / Enterprise Integration

Чому невелика зміна структури даних може зупинити роботу кількох корпоративних систем

Корпоративні інформаційні системи постійно змінюються. Підприємства додають нові функції ERP, модернізують CRM, розширюють електронний документообіг і створюють додаткові аналітичні звіти.

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

Проте таблиця вже використовується в кількох інтеграційних процесах. Один ETL-процес передає замовлення до корпоративного DWH. Інший компонент формує документи для партнерського порталу. Третій сервіс публікує повідомлення в Apache Kafka.

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

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

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

Вона охоплює не лише таблиці СУБД, а й API, файлові формати, повідомлення, ETL-процеси, корпоративні довідники та метадані.

Що саме потрібно версіонувати

У корпоративному інформаційному середовищі зміни можуть стосуватися різних рівнів архітектури.

Структури баз даних

Наприклад, створення нової таблиці, додавання поля, зміна типу або індексу.

Такі операції можуть впливати на прикладні запити, збережені процедури та ETL.

API-контракти

Зміни REST або SOAP можуть впливати на споживачів, які використовують відповідні інтерфейси.

Наприклад, зміна формату JSON-відповіді може порушити роботу партнерського порталу.

Схеми повідомлень

У потоковій архітектурі producer і consumer можуть працювати з різними версіями повідомлень.

ETL- і ELT-процеси

Зміни правил трансформації впливають на аналітичний результат.

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

MDM-правила

Зміна способу зіставлення контрагентів або товарів може призвести до іншого результату консолідації.

Бізнесові визначення

Наприклад, поняття «активний клієнт» може отримати нове визначення.

Тому контроль версій має охоплювати не лише програмні файли, а й семантику корпоративної інформації.

Backward Compatibility та Forward Compatibility

Для управління змінами важливо розрізняти типи сумісності.

У загальному сенсі backward compatibility означає можливість нового компонента працювати зі старими даними або контрактами.

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

Наприклад, у Schema Registry для Avro напрям сумісності визначається відносно версій writer і reader schema.

Тому не можна механічно переносити правила Avro на JSON API або SQL-таблиці.

Сумісне розширення

Розглянемо початкове повідомлення:

{
  "orderId": "ORD-1842",
  "customerId": "CUST-501",
  "amount": 1200.00
}

Підприємство хоче додати канал продажу.

Нова версія може виглядати так:

{
  "orderId": "ORD-1842",
  "customerId": "CUST-501",
  "amount": 1200.00,
  "salesChannel": "ONLINE"
}

Для JSON API така зміна може бути сумісною, якщо споживачі ігнорують невідомі поля. Але це залежить від конкретного контракту та реалізації.

Якщо старий споживач суворо перевіряє перелік допустимих атрибутів, він може відхилити нове повідомлення.

Несумісна зміна

Припустімо, поле amount замінено на:

{
  "orderId": "ORD-1842",
  "total": {
    "value": 1200.00,
    "currency": "EUR"
  }
}

Тепер змінилася структура повідомлення. Старі споживачі, які очікують поле amount, можуть перестати працювати.

Для такої модернізації необхідний окремий план переходу.

Expand–Migrate–Contract: поступова зміна без одночасного оновлення всіх систем

Одним із найпрактичніших підходів до керування структурними змінами є Expand–Migrate–Contract.

Його ідея полягає в тому, щоб розділити потенційно несумісну зміну на кілька етапів.

Expand — розширення

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

Наприклад, до таблиці замовлень додається поле total_amount, але старе amount тимчасово залишається.

Migrate — перехід

Застосунки й інтеграційні процеси поступово переводяться на новий контракт.

Може використовуватися контрольоване заповнення нових атрибутів на основі старих.

Contract — завершення

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

1. Expand

Додати нову структуру, зберігши старий контракт

2. Migrate

Перевести споживачів і перевірити результати

3. Contract

Вилучити старий контракт після підтвердження сумісності

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

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

Для великих фінансових систем також потрібні контрольні звірки.

Flyway 5.1: версіонування структури реляційних баз даних

Одним із доступних інструментів керування міграціями є Flyway. На початку серпня 2018 року доступна лінійка Flyway 5.1, зокрема випуск 5.1.4 від 4 липня.

Flyway дозволяє описувати зміни схеми через SQL-міграції та зберігати історію їх застосування.

Наприклад, підприємство хоче додати новий атрибут замовлення.

Міграція може зберігатися у файлі:

V12__add_sales_channel.sql

Вміст:

ALTER TABLE orders
ADD sales_channel VARCHAR(30);

Після застосування відповідний запис фіксується в історії міграцій.

Це дозволяє встановити, які зміни були виконані в конкретній базі.

Чому це важливо для DataOps

Без контролю версій DBA може вручну додати поле в продуктивну базу. А тестове середовище залишиться зі старою структурою.

У результаті поведінка систем відрізнятиметься.

Керовані міграції допомагають відтворювати зміни у відповідній послідовності.

Контроль сумісності

Проте Flyway не гарантує автоматично, що міграція не порушить залежні застосунки. Наприклад, видалення стовпця може успішно виконатися в СУБД, але зупинити роботу ETL.

Тому необхідні інтеграційні тести та аналіз залежностей.

Важливість резервування

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

Тому для критичних змін потрібні перевірені процедури резервування та відновлення.

Liquibase: декларативні зміни й контроль структури

Альтернативним інструментом є Liquibase. Він дозволяє описувати міграції через відповідні change sets.

Залежно від підходу зміни можуть визначатися у XML, YAML, JSON або SQL. Наприклад, підприємство може створити окремий change set для нового стовпця.

Важливо, що система контролює історію застосованих змін.

Перевага декларативного опису

Для певних типових операцій можна використовувати платформонезалежніші конструкції.

Однак це не означає абсолютної переносимості між СУБД.

Наприклад, можливості індексації PostgreSQL і SQL Server можуть суттєво відрізнятися.

Тому для складних міграцій часто потрібен спеціалізований SQL.

Change Sets

Кожна зміна повинна мати визначений ідентифікатор.

Це дозволяє відстежувати її застосування.

Preconditions

Для відповідних сценаріїв можуть використовуватися попередні перевірки.

Наприклад, чи існує таблиця або стовпець.

Rollback

Для окремих змін можливе визначення зворотної процедури.

Проте не слід припускати, що будь-яка зміна корпоративних даних є повністю оборотною.

Особливо якщо міграція включає перерахунок або видалення інформації.

Apache NiFi Registry 0.2: контроль версій інтеграційних потоків

Для корпоративних інтеграцій значення має не лише версіонування SQL.

Apache NiFi дозволяє будувати інформаційні потоки через графічну модель процесорів і відповідних зв’язків.

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

Це створює ризик неконтрольованого порушення роботи.

У червні 2018 року вийшла Apache NiFi Registry 0.2.0.

Серед важливих можливостей — Git Flow Persistence Provider, який дозволяє зберігати версії потоків у Git-репозиторії. Також було розширено можливості event hooks та конфігурації службової бази метаданих.

Версіонування Flow

Наприклад, підприємство має інтеграційний потік для отримання документів із CRM.

Кожна затверджена версія може бути збережена у Registry.

Порівняння

Команда може аналізувати відмінності між версіями.

Наприклад, які процесори були додані або змінені.

Git

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

Обмеження

Наявність версії Flow не означає, що відповідні SQL-процедури, зовнішні API та корпоративні довідники також перебувають у правильному стані.

Тому потрібно контролювати всю сукупність залежностей.

Крім того, необхідно окремо захищати секрети й параметри підключень.

Confluent Schema Registry та Apache Avro

У потокових архітектурах важливу роль відіграє керування схемами повідомлень.

Наприклад, ERP публікує події замовлень до Apache Kafka.

Кілька незалежних застосунків отримують їх.

Одним із можливих підходів є використання Apache Avro разом із Confluent Schema Registry.

Schema Registry зберігає версії схем і дозволяє контролювати визначені типи сумісності.

Приклад Avro Schema

{
  "type": "record",
  "name": "Order",
  "fields": [
    {"name": "orderId", "type": "string"},
    {"name": "amount", "type": "double"},
    {
      "name": "salesChannel",
      "type": "string",
      "default": "UNKNOWN"
    }
  ]
}

Нове поле має значення за замовчуванням.

Для відповідної моделі Avro це може забезпечувати backward compatibility: новий reader здатний читати попередні повідомлення, у яких цього поля ще не було.

Однак результат залежить від конкретних схем, типів і правил сумісності.

Режими сумісності

У Schema Registry використовуються відповідні режими, зокрема BACKWARD, FORWARD та FULL.

Вони визначають, які зміни можуть бути прийняті.

Проте перевірка схем не гарантує семантичної сумісності.

Наприклад, поле amount може залишатися числовим, але його значення почнуть передаватися в копійках замість гривень.

Формальна схема не обов’язково виявить таку зміну.

Тому потрібні бізнесові контракти та додаткові тести.

Версіонування API: коли потрібний новий контракт

Для REST API підприємства можуть використовувати різні стратегії розвитку.

Одним із підходів є підтримка окремих версій.

Наприклад:

/api/v1/orders
/api/v2/orders

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

Проте надмірна кількість паралельних версій збільшує витрати на підтримку.

Тому не кожне додавання необов’язкового поля повинно призводити до створення нового API.

Swagger 2.0 та OpenAPI 3.0

У серпні 2018 року доступні Swagger 2.0 та OpenAPI Specification 3.0, опублікована ще в липні 2017 року.

Вони дозволяють документувати контракти програмних інтерфейсів.

Для корпоративних проєктів це важливо, оскільки зміни API можна аналізувати до продуктивного впровадження.

Contract Testing

Наприклад, тест може перевіряти, чи присутні необхідні поля та чи відповідають вони очікуваним типам.

Проте необхідно контролювати й бізнесову семантику.

Якщо API починає повертати інший статус документа під тією самою назвою, формальна перевірка структури може не виявити проблему.

Data Lineage як основа аналізу наслідків змін

Перед зміною корпоративної схеми важливо встановити залежні інформаційні ресурси.

Наприклад, підприємство хоче змінити атрибут customer_group.

Він використовується в CRM, ETL, DWH та кількох BI-звітах.

Data Lineage дозволяє визначити відповідні залежності.

• CRM — зміна структури клієнта
• ETL / Mapping
• API / Kafka
• DWH — клієнтські виміри
• BI — звіти за клієнтськими групами

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

Для такого аналізу можуть використовуватися корпоративні Data Catalog, Apache Atlas та інші системи метаданих.

Однак важливо враховувати повноту каталогу.

Якщо окремі SQL-скрипти не зареєстровані, автоматичний Impact Analysis може не знайти всі залежності.

Тому каталог потрібно підтримувати в актуальному стані.

Версіонування MDM та бізнесових правил

Окреме завдання — зміна правил корпоративної ідентифікації.

Наприклад, підприємство використовує MDM для зіставлення постачальників із кількох ERP.

Раніше достатнім критерієм збігу були назва й адреса.

Після аналізу помилок компанія вирішує приділяти більше уваги перевіреному реєстраційному коду.

У результаті відповідні правила Matching змінюються.

Це може призвести до іншого об’єднання записів.

Наприклад, два контрагенти, які раніше вважалися одним, тепер можуть бути розділені.

Тому необхідно зберігати версію правил та результати їх застосування.

Golden Record

Зміна правил може впливати на корпоративні ідентифікатори.

DWH

Аналітичні звіти можуть отримати інші результати консолідації.

Історичність

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

Data Stewardship

Неоднозначні випадки повинні проходити відповідну перевірку.

Таким чином, MDM-версіонування є не менш важливим, ніж контроль структури SQL.

Практичний сценарій: модернізація замовлень у холдингу

Розглянемо умовний холдинг, який використовує ERP, CRM, Kafka та DWH.

Компанія хоче додати нову характеристику замовлення — канал продажу.

Етап 1. Інвентаризація

Команда визначає всі системи, які використовують замовлення.

Етап 2. Інформаційний контракт

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

Етап 3. Розширення SQL

До ERP додається нове поле без негайного видалення старих структур.

Етап 4. Avro Schema

Для Kafka створюється нова версія схеми з відповідними правилами сумісності.

Етап 5. ETL

Оновлюються процедури перенесення до DWH.

Етап 6. Тестування

Перевіряються старі й нові повідомлення.

Етап 7. BI

Створюються відповідні аналітичні виміри.

Етап 8. Поступове впровадження

Споживачі переходять на новий контракт у визначеній послідовності.

Етап 9. Контроль

Порівнюються результати й кількість інформаційних помилок.

Етап 10. Завершення переходу

Застарілі контракти виводяться з експлуатації після підтвердження сумісності.

Головне — не змушувати всі корпоративні системи одночасно переходити на нову версію без необхідності.

Інформаційна безпека й GDPR

Після початку застосування GDPR підприємствам необхідно враховувати відповідні вимоги під час зміни процесів, що обробляють персональні дані.

Наприклад, нове поле CRM може містити персональну інформацію.

Тому його додавання до API або DWH потребує оцінки мети, правової підстави та доступу.

Важливо також не переносити секрети до Git.

Наприклад, файли міграцій і конфігурації NiFi не повинні містити відкриті паролі продуктивних СУБД.

Контроль змін

Для критичних інформаційних контрактів потрібне належне погодження.

Data Minimisation

Нові атрибути повинні передаватися лише тим споживачам, для яких вони потрібні.

Audit Trail

Необхідно документувати версію процесу та відповідальних за зміну.

Retention

Тимчасові структури, створені під час міграції, повинні мати визначений життєвий цикл.

Таким чином, Schema Evolution необхідно поєднувати з Data Governance.

Компетенції Intecracy Group у керуванні інформаційними змінами

Версіонування корпоративних даних потребує поєднання інформаційних, інтеграційних та інфраструктурних компетенцій.

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

Практичні орієнтири для впровадження

Управління версіями інформаційних структур стає важливим компонентом сучасної корпоративної архітектури.

Зміни в ERP, CRM, API та потокових системах можуть впливати на десятки незалежних споживачів.

Для зменшення ризиків необхідно використовувати контрольовану еволюцію схем, перевірку сумісності та поступові процедури переходу.

Flyway і Liquibase допомагають керувати міграціями реляційних баз.

Apache NiFi Registry забезпечує версіонування інтеграційних потоків.

Confluent Schema Registry та Apache Avro дозволяють контролювати визначені зміни схем повідомлень.

Data Catalog і Data Lineage допомагають встановлювати інформаційні залежності.

Проте жоден інструмент не гарантує автоматично правильності бізнесових результатів.

Для цього потрібні Data Quality, MDM, інтеграційне тестування та відповідальні власники інформації.

Головний принцип Schema Evolution полягає в тому, що корпоративні дані повинні змінюватися контрольовано: нові інформаційні можливості впроваджуються поступово, сумісність перевіряється до продуктивного запуску, а наслідки для аналітики та бізнес-процесів залишаються передбачуваними.