Як ми перейшли з IBM DataStage на CDC + Apache Airflow

💡 Усі статті, обговорення, новини про DevOps — в одному місці. Приєднуйтесь до DevOps спільноти!

Мене звати Максим, я працюю в ПУМБ з 2018 року на позиції керівника відділу автоматизації процесів. Наша команда займається дата-інженерингом, інтеграцією даних та побудовою пайплайнів наповнення сховища даних (DWH).

За цей час ми побудували та масштабували багато критичних для банку інтеграцій, пройшли кілька етапів трансформації архітектури та накопичили значний практичний досвід у сфері обробки великих обсягів даних. Одним із ключових технологічних поворотів став перехід від класичних ETL-рішень до CDC-архітектури у зв’язці з Apache Airflow.

У цій статті я опишу наш шлях міграції з IBM DataStage на CDC + Apache Airflow, ключові рішення, проблеми, з якими ми зіткнулися, та результати, яких досягли. Описаний досвід є моїм суб’єктивним баченням, що базується на практичній роботі в банківському DWH.

Вступ

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

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

У цій статті будуть докладно описані усі етапи, які нам довелося пройти; які технології було застосовано та які були альтернати, і чому вони не були використані.

Перехід на нову архітектуру. Стандартні виклики та неординарні рішення

Бекграунд

Команда, до якої я належу, відповідає за серце банківської аналітики — сховище даних (Data WareHouse, далі DWH). Наш DWH побудований на SAP IQ і зберігає терабайти історичної та актуальної інформації: від щоденних операцій клієнтів до даних для скорингу, звітності та ухвалення бізнес-рішень.

До 2022 року ми вантажили дані у DWH через IBM DataStage 11.7 — класичний ETL-гігант з великим набором Ентерпрайз-функцій і таким же великим цінником. Це була стабільна та перевірена часом платформа, але з кожним роком вона ставала для нас усе менш зручною: обмежена гнучкість, дорогі ліцензії, складність інтеграцій з новими джерелами і сучасними технологіями.

Ми бачили, що ринок рухається до потокових технологій і CDC (Change Data Capture), де дані оновлюються автоматично майже в реальному часі. Це призводить до кратного зменшення навантаження на джерела даних, через що не потрібно чекати вільного вікна для завантаження, як це відбувається у DataStage. Саме тому постало питання: переосмислювати підхід до інтеграції даних чи залишатися в минулому?

Далі я розповім, як ми пройшли шлях від DataStage до зв’язки CDC + Apache Airflow, з якими викликами зіткнулися та як побудували стабільний пайплайн, який задовольняє навіть вередливий SAP IQ.

DataStage і нічні вікна

Як і багато великих організацій, ми використовували IBM DataStage 11.7 як основний інструмент для завантаження даних у DWH. Архітектура була класична: джерело → DataStage → staging у DWH → бізнес-логіка.

Між ETL (extract, transform, load) та ELT (extract, load, transform) через специфіку DataStage використовувався другий спосіб. Головна різниця полягає в тому, що при ELT-підході дані потрапляли в фінальну точку призначення (DWH в нашому випадку) у «брудному» вигляді й основна обробка відбувалася вже на стороні бази через SQL, view, staging-таблиці тощо.

В той час, як при ETL усі трансформації виконувалися б у бізнес-логіці ще до завантаження, що дозволило б знизити навантаження на DWH та сильно спростити сприйняття й можливість використання отриманої інформації.

На практиці це мало кілька суттєвих проблем:

• Навантаження на джерела. DataStage не має можливості автоматично виділяти в БД зміни в момент їх появлення, тому це відбувається шляхом порівняння нових і старих даних раз в деякий період. Такий підхід призводив до неймовірно високого навантаження. До того ж той факт, що з цими БД одночасно працювали фронт-системи та користувачі, позбавляв нас можливості проводити часті оновлення.

  

• Жорстке нічне вікно. З попередньої проблеми витікає те, що через мінімізацію навантаження на джерела найзручнішим часом для оновлення була ніч. Для систем на кшталт АБС «SCROOGE» чи системи карткових операцій був доступний взагалі дуже короткий час. Щобільше, в нештатних ситуаціях при запізненні EOD цей проміжок зменшувався ще більше.
• Відсутність онлайн-оновлень. Як результат, такий підхід дозволяв оновлювати дані лише один раз на добу, що унеможливлювало оперативну аналітику протягом дня та серйозно ускладнювало пошук помилок при їх виникненні, адже було неможливо просто перезапустити процес.
• Ефект доміно. Через жорстку послідовність кожного кроку в цій системі затримка одного процесу зрушувала весь ланцюг.
• Технічні обмеження. Хоч DataStage чудово працював з традиційними системами, як-от MSSQL, Postgres, Oracle, DB2, він був негнучким у роботі з REST, NoSQL і Kafka тощо. При виникненні потреби в трохи нестандартних правилах завантаження даних в таких системах доводилося витрачати немало часу та зусиль на пошук зрозумілого для DataStage рішення.

Якщо додати сюди високу ціну ліцензій, залежність від GUI та складність автоматизації — стане зрозуміло, чому ми почали шукати альтернативу.

Масштаб і команда

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

• У банку було понад 2000 автоматизованих процесів обробки даних у DataStage, які взаємодіяли з ДВХ. Кожен мав залежні від нього звіти, розклади та інтеграції різного рівня критичності. Більш того, система не стояла на місці й кожного дня додавалися нові або змінювалися вже існуючі процеси.
• За цим усім стояла команда не менше ніж з 10 розробників, які займалися створенням нових та наглядом за правильністю відпрацювання вже існуючих процесів.
• Окремо потрібно виділити те, що система мала декількох адміністраторів, які відповідають за усе пов’язане з самим DWH. Починаючи від створення нових таблиць або редагування і видалення інформації з існуючих та закінчуючи наглядом за коректністю роботи самого ДВХ й DataStage у позаштатних ситуаціях.

Усе це дає зрозуміти, що це був великий командний проєкт міграції, який вимагав повної технічної та організаційної перебудови. Це була не «точкова оптимізація» через перехід на нове ПО, а повна зміна існуючої архітектури.

Чому ми обрали CDC і з чим зіштовхнулись у SAP IQ

Логічним кроком став CDC (Change Data Capture). Він дозволив нам вирішити низку проблем наведених вище, а саме:

• можливість читати лише журнали транзакцій, що знизило навантаження на джерела через відсутність потреби постійно порівнювати дані;
• оновлення даних протягом дня, а не один раз на добу, що стало можливо як раз коштом суттєвого зниження навантаження;
• близька до real-time аналітика, що своєю чергою стала доступна через постійне оновлення даних без добових затримок.
• якість даних (при завантаженні через DataStage часто важко було виявити записи, які були просто оновлені в таблицях без оновлення якогось технічного timestamp-поля, що призводило до помилок у звітності).

Але ідеальні ситуації трапляються дуже рідко, і в цьому випадку дива не сталося. Головний плюс (читання журналів транзакцій) CDC став і головним мінусом, адже генерував дрібні зміни (insert/update/delete по одному). Конкретно для нас це було проблемою через те, що SAP IQ не любить поодинокі транзакції. Як колонкова аналітична СУБД він оптимізований під одномоментну обробку великого об’єму даних. Якщо обробляти кожну зміну, згенеровану CDC напряму, це може призвести до падіння продуктивності та появи блокування і нестабільності.

Як ми помирили SAP IQ та CDC

• Буферизація і батчування. Іноді найочевидніший шлях дійсно є найкращим. SAP IQ погано працює з малими обсягами даних? Тоді чому б не поєднувати їх разом. CDC дозволяє агрегувати зміни за деякий час в один пакет, що дозволяє уникати тисяч одиночних транзакцій.

  

• Різні затримки для різних систем. На відміну від DataStage, CDC дозволяє налаштувати різний час агрегації для різних систем. Для критичних напрямів (фінмоніторинг, комплаєнс) проблемою малих обсягів даних можна знехтувати, а от для другорядних систем є можливість встановити більшу затримку.
• Оптимальні параметри завантаження. В додаток до попереднього плюса, CDC дозволяє налаштувати синхронізацію не тільки по таймеру, а і по розміру. На практиці це означає, що завантаження починається в момент досягнення певного розміру загальним обсягом змін. Це дозволяє підібрали оптимальні розміри батчів під кожну систему, що дасть можливість DWH працювати стабільно.

Замість «стріляти одиночними пострілами» ми почали «стріляти чергами» — і SAP IQ це оцінив. Сьогодні у нас CDC реплікації з понад 60 БД з основних реляційних СУБД (MSSQL, Oracle, DB2, PostgreSQL), і для кожного налаштований свій CDC-task.

Airflow як заміна DataStage: від кубиків до DAG-ів

Хоч і вдалося налаштувати ефективну взаємодію між CDC і SAP IQ, сам CDC вирішив лише задачу автоматичної синхронізації даних у джерелах та DWH. Під питанням залишалися інші сценарії, такі як:

• Full Load — повне перезавантаження усіх даних в таблиці.
• REST API — можливість стягувати дані з зовнішніх джерел.
• NoSQL — інтеграція баз даних, які не використовують SQL.
• Трансформації — обробка отриманих даних будь-яким чином перед заливкою їх у DWH.

Раніше усі ці проблеми вирішував DataStage, але оскільки через критичні мінуси, описані вище, було вирішено повністю від нього відмовлятися, з’явилася потреба у додаткових інструментах. Таким інструментом став Apache Airflow.

Ми обрали саме Apache Airflow, бо він мав доволі багато дуже важливих для нас переваг, таких як:

• гнучкість — замість вбудованих інструментів з’явилася можливість описати все кодом, що означало набагато вищий контроль за процесом, легкий менеджмент версій та зрозумілий CI/CD (автоматизація процесу розробки);
• масштабованість — можливість створення стількох автоматизованих процесів скільки потрібно, 10 чи 100 — не важливо;
• прозорість — використання самостійно написаного коду також відкриває доступ до дуже гнучкого логування, адже це робиться в коді, тому є можливість точно вказати, що і коли має бути записано;
• візуалізацію — за допомогою групування задач (task groups) легко зрозуміти що, за чим, у який час, і з якими параметрами було запущено.

Ми проаналізували усі процеси в DataStage і розділили їх:

• що можна покрити CDC,
• що треба перенести в Airflow.

У результаті з’явився зручний пайплайн, за допомогою якого дані витягуються з різних джерел, трансформуються у потрібний нам вигляд і завантажуються у SAP IQ за допомогою SP (stored procedure). Щобільше, впродовж всього процесу відбувається зручне та зрозуміле логування, за допомогою якого можна швидко зрозуміти, що і коли відбулося.

Наш власний оркестратор усередині Airflow

Хоч Airflow сам по собі був дуже зручним рішенням, при переході но нову технологію майже завжди виникає ситуація, коли не вистачає чогось дуже конкретного, що було у минулому рішенні. І наш випадок не став виключенням. Поряд з DataStage в нас був orchestrator від Microsoft. Він слугував як шедулер всіх процесів в DataStage і в ньому були зашиті всі залежності.

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

Коштом відкритості системи ми змогли розширити функціонал і додати оркестратор власноруч. Ми розробили власний модуль AirOrc (можна побачити на наступних двох скріншотах), який інтегрували у UI Airflow. Він дозволяє:

• налаштовувати групи процесів;
• задавати інтервали виконання SP (stored procedure);
• управляти залежностями між DAG-ами та групами;
• запускати черги вручну;
• відображати все у єдиному меню.

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

CDC + Airflow-інтеграції: два канали живлення DWH

В результаті у нашій архітектурі дані потрапляють у DWH двома шляхами:

1. Через CDC. Потоковий канал, що реплікує зміни зі стандартних джерел у SAP IQ майже real-time.
2. Через Airflow-інтеграції. Гнучкий канал для будь-яких нетипових джерел на кшталт full load, API, NoSQL і специфічних кейсів, коли є потреба в розширеній трансформації даних.

У результаті SAP IQ отримує і потокові, і пакетні дані, а далі всі процеси управляються DAG-ами й модулем AirOrc.

Неочікуваний поворот від вендора: відмова від підтримки Sybase IQ

Коли ми вже стабілізували процеси, трапився ризик, який було важко передбачити: вендор CDC оголосив про припинення підтримки SAP IQ у своєму продукті. Щобільше, варіанту залишитися на старій версії теж не було, зупинка підтримки була всеосяжною. Тому при продовженні ліцензій ми ризикували в будь-який момент отримати повний злам усіх процесів у проді.

Наша реакція

Хоч новини про це і відчувалися як град посеред ясного неба, робити щось з цим потрібно було в будь-якому випадку. Тому ми почали опрацьовувати всі можливі варіанти. З одного боку, CDC нам дуже подобався своєю зручністю, і ми не хотіли від нього відмовлятися. З іншого, міняти DWH-СУБД теж було за рамками наших можливостей — не тільки тому, що перехід на нову БД і переніс всіх даних потребує велетенських людських і технічних ресурсів, а і тому, що SAP IQ ідеально підходив під наші потреби й лишався для нас базовим і стратегічним.

Після аналізу стало очевидно: найзручніший для нас варіант — це реплікація у файли з подальшим завантаженням у DWH. Але тут відкрилась ціла низка нових проблем:

• у файлах немає «update/delete» для вже записаних рядків;
• як обробляти тисячі одночасно генерованих файлів;
• як завантажувати їх у потрібні таблиці SAP IQ (конекти, логіка групування даних, контроль первинних ключів);
• як візуалізувати й логувати увесь процес;
• як забезпечити швидку та безперебійну обробку цього масиву даних.

Які варіанти ми розглядали

• Airflow. Використати його як оркестратор для файлового потоку: завантаження, парсинг, групування, контроль.
• Створення власного ПО з нуля. Розгортання прямо на сервер CDC-реплікації, де програма в реальному часі буде відстежувати появу нових файлів і відразу їх обробляти.

В результаті було вирішено, що розробка власного ПО буде новим рівнем архітектурного рішення, що дозволить отримати стовідсотковий контроль за усім процесом та дасть нам досвід, якого в нас ще не було. Це стало окремим великим проєктом, про який ми плануємо написати наступну статтю на DOU.

Що ми отримали після міграції

• SLA та швидкість оновлення. Дані оновлюються майже онлайн, процеси стартують одразу після EOD завдяки AirOrc.
• Швидке розгортання пайплайнів. Те, що раніше займало тиждень, тепер можна підняти за день. З’явилась фабрика пайплайнів з Git і CI/CD.
• Зниження вартості. Відмова від DataStage зекономила компанії понад $170 000 на рік.
• Вигоди для команди. Контроль версій, прозорі логи, менше рутини, більше гнучкості. Команда з «ручних операторів ETL» перетворилась на інженерів екосистеми даних.

Висновки

Перехід з IBM DataStage на CDC + Airflow був не просто технічною міграцією, а повною зміною філософії роботи з даними.

Ми перейшли:

• від нічних завантажень — до майже онлайн-оновлень;
• від GUI та ручного керування — до майже повної автоматизації через код;
• від дорогих ліцензій — до open-source екосистеми.

Так, були доволі важкі виклики, головні з яких: проблеми в роботі SAP IQ з дрібними транзакціями написання свого orchestrator; навчання команди нового стеку. Але результат — стабільний і масштабований пайплайн, що відкрив двері до real-time аналітики.

Метафора:

• DataStage був як старий Volvo — надійний, але повільний і дорогий у сервісі.
• CDC + Airflow — як Tesla: вимогливий на старті, але дає зовсім інший рівень швидкості, керованості і контролю.

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