Проект Dual ETL або як ми будували Disaster Recovery для Greenplum

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

Ні для кого не секрет, що вимоги до наявності Recovery (далі DR) у сучасних бізнес інформаційних системах відносяться до категорії «must have». Так, трохи більше року тому, команді, яка займається розвитком DWH в банку, було поставлено завдання реалізувати DR для DWH, на якому побудовані як автономного, так і порівняйте процеси банку.





Постановка завдання
Отже, що було дано:
  • Система захоплення змін на стороні джерел даних і застосування їх в шар Online Operational Data (далі OOD) — Attunity Replicate;
  • Завантаження, перетворення даних, IN/OUT інтеграція даних, розрахунок вітрин і весь ETL/ELT — SAS Data Integration Studio, ~1700 ETL завдань;
  • Основна СУБД на якій побудовано DWH в банку — MPP СУБД Pivotal Greenplum, обсяг даних ~30ТБ;
  • Звітність, Business Intelligence, Ad-hoc — SAP BusinessObjects + SAS Enterprise Guide;
  • Два дата-центру, територіально рознесених по різних кінцях Москви, між якими є мережевий канал.


Завдання: забезпечити протягом години після збою, що приводить до непрацездатності Greenplum на основній площадці, працездатність всіх процесів DWH на резервному контурі Greenplum. По суті задача зводиться до того, що б побудувати hot standby для Greenplum.

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

Звичайно ж, перше, що прийшло нам у голову — це покопати в напрямку вендора — Pivotal, тобто EMC. В результаті проведених досліджень, ми з'ясували, що Greenplum не має штатного інструменту для побудови hot standby, а рішення DR для Greenplum потенційно можна побудувати з допомогою EMC Data Domain. Але при більш глибокому вивченні Data Domain, прийшло розуміння, що ця технологія заточена на створення великої кількості бекапів і причини цього досить дорога. Так само Data Domain «з коробки» не має функціональних можливостей підтримки другого контуру в актуальному стані. Від розгляду EMC Data Domain ми відмовилися.

Другий варіант, який ми пропрацювали, використання стороннього інструменту реплікації GreenplumToGreenplum. Варіант досить швидко вичерпав себе, оскільки на той момент в природі не існувало інструментів реплікації, що підтримують Greenplum як джерело.

Третій варіант за що ми взялися, це рішення класу Dual Applay. Підглянувши в Teradata і Informatica їх рішення під назвою Informatica dual load for Teradata dual active solution (Teradata Magazine), почали досліджувати ринок технологій, що б побудувати аналогічне рішення для Greenplum. Але нічого готового не знайшли.

Після проведених досліджень, вирішили, що кращим варіантом буде власна розробка. Так ми взялися за написання власної системи і назвали її Dual ETL (в колах розробників проект отримав назву «Ятрань»).

Duet і як ми його будували
Концептуальна архітектура
В основу концепції побудови системи увійшов принцип: як тільки ETL відбудував таблицю на основному контурі Greenplum, система повинна відловити це подія і передати дані цієї таблиці на резервний контур Greenplum. Таким чином, дотримуючись цей принцип, ми синхронно, з деякою тимчасовою затримкою, будуємо DWH на двох контурах у двох територіально віддалених дата-центрах.


Рис.1 Концептуальна архітектура

В ході опрацювання архітектури система була розбита на шість компонент:
  • Компонента Backup, яка повинна працювати на основній площадці і відповідати за одержання даних;
  • Транспортна компонента, що відповідає за передачу даних між основною і резервної майданчиками;
  • Компонента Restore, яка повинна працювати на резервному майданчику і відповідати за застосування даних;
  • Компонента перенесення на СГД та збору денного backup;
  • Керуюча компонента, яка повинна керувати всіма процесами системи;
  • І компонента моніторингу, яка повинна була давати розуміння, що відбувається в системі і на скільки резервна майданчик відстає від основного майданчика.


Доопрацювання існуючого ETL
Для того, що б повідомляти системі про готовність таблиці, була реалізована чергу, в яку ми навчили наш ETL додавати об'єкт (тобто таблицю) як тільки він закінчив її побудова. Таким чином була реалізована функціональність передачі події системі, після якого система повинна була відбудувати цю таблицю на резервному контурі Greenplum.

Реалізація керуючої компоненти
В силу того, що наш планувальник ETL-завдань написаний на SAS, плюс у команди DWH є в наявності велика експертиза роботи з мовою SAS Macro, було прийнято рішення писати керуючий механізм на SAS.

Реалізований механізм виробляє такі прості дії, як: отримати нову таблицю з черги, запустити компоненту Backup, надіслати отриманий dump таблиці на резервну майданчик, запустити компоненту Restore. В додаток до цього реалізована багатопоточність, при тому що кількість потоків можна регулювати для кожного виду завдань (Backup, транспорт, Restore, перенесення buckup-ів на СГД), і звичайно ж така необхідна функціональність, як журналювання та e-mail нотифікації.

Реалізація компоненти Backup
Компонента Backup, переданої для таблиці, викликає утиліту gp_dump. Ми отримуємо dump таблиці, розмазаний по сегмент серверів Greenplum основної площадки. Приклад виклику утиліти gp_dump:

gp_dump --username=gpadmin --gp-d=$DIRECTORY --gp-r=$REPORT_DIR $COMPRESS-t $TABLE db_$DWH_DP_MODE &> /tmp/gp_dump_$NOW


Реалізація транспортної компоненти
Основне завдання транспортної компоненти — швидко передавати dump-файли сегмент серверів Greenplum основній площадці на відповідні сегмент-сервера Greenplum резервної майданчики. Тут ми зіткнулися з мережевим обмеженням, а саме: сегменти основного контуру не бачать по мережі сегменти резервного контуру. Завдяки знанням наших адміністраторів DWH був придуманий спосіб як це обійти за допомогою SSH-тунелів. Були підняті SSH-тунелі на secondary master серверах Greenplum кожного з контурів. Таким чином кожен шматочок dump-а таблиці передавався з сегмент-сервера основної площадки на сегмент-сервер резервної майданчика.

Реалізації компоненти Restore
Після завершення роботи транспортної компоненти, ми отримуємо dump таблиці, розмазаний по сегмент серверів Greenplum резервної майданчики. Для цієї таблиці компонента Restore запускає утиліту gp_restore. В результаті ми отримуємо оновлену таблицю на резервному майданчику. Далі наведено приклад виклику утиліти gp_restore:

gp_restore $COMPRESS --gp-d=$SOURCE --gp-r=$REPORT_DIR --gp-k=$KEY-s --status=$SOURCE-d db_$DWH_DP_MODE > /tmp/gp_restore_$(echo $KEY)_$RAND 2>>/tmp/gp_restore_$(echo $KEY)_$RAND


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

Метрики виділили досить швидко, які на наш погляд, повинні були в цілому однозначно давати зрозуміти в конкретний момент часу що відбувається в системі:
  • Кількість об'єктів в статусах;
  • Кількість помилок в статусах;
  • Відставання від моменту потрапляння в чергу;
  • Затримка на старті етапу;
  • Середня тривалість етапу (по 10 останніми об'єктів);
  • А так само моніторинг кількості працюючих потоків на кожному з етапів.


З технічною реалізацією визначилися теж досить швидко — Graphite + Graphana. Розгорнути Graphite на окремій віртуальній машині і запрограмувати придумані метрики не склало праці. А за допомогою Graphana над працюючим Graphite був розроблений красивий dashboard.

Всі перераховані вище метрики знайшли візуалізацію і що не мало важливо онлайновость:


Рис.2 Кількість об'єктів в статусах


Рис.3 Кількість помилок в статусах


Рис.4 Відставання від моменту потрапляння в чергу


Рис.5 Затримка на старті етапу


Рис.6 Середня тривалість етапу (по 10 останніми об'єктів)


Рис.7 Кількість працюючих потоків на кожному з етапів

Постобробка
Після завершення процесу restore dump-файли переносяться на СГД, на резервній майданчику. Між СГД на резервному майданчику та СГД на основній площадці налаштована реплікація, ця реплікація реалізована на основі технології NetApp SnapMirror. Тим самим якщо на основному майданчику відбувається збій, вимагає відновлення даних, у нас вже є підготовлений бекап на СГД для проведення цих робіт.

Підсумки
Що ми отримали
Система була розроблена і все вийшло дуже навіть не погано. Завдання, які покликана вирішувати система, закриваються їй повністю. Після завершення розробки, було розроблено певну кількість регламентів, які дозволяли в рамках процесу підтримки DWH здійснювати перехід на резервну майданчик.
Основне що ми отримали, це звичайно ж можливість протягом 30 хвилин переїхати на резервну майданчик у разі збою на основний, що значно мінімізує простий DWH як інформаційної системи і як наслідок дає можливість бізнесу безперервно працювати зі звітами, даними для аналізу, виконуючи ad-hoc і не зупиняти ряд online процесів. Система так само дозволила нам відмовитися від процедури щоденного регламентного бекапа, на користь бекапа, що отримується системою Dual ETL.

Статистика роботи
Через систему в день проходить близько 6500 тисяч об'єктів (таблиць) сумарним обсягом близько 20ТБ.
На прикладі метрики «Відставання від моменту потрапляння в чергу» (див. рис.8)


Рис.8 Відставання від моменту потрапляння в чергу

можна спостерігати відставання резервної майданчику від основної. Під час роботи нічного планувальника, коли ETL активно будує сховище, відставання в піку доходить до 2-3 годин. До моменту завершення побудови сховища, 10-й ранку, відставання знижується і тримається на рівні 5-10 хвилин. Протягом дня можуть з'являтися сплески відставання під час роботи online планувальника, в межах 30 хвилин.

А так само відносно недавно у нашої системи трапився маленький ювілей, через неї пролетів 1 000 000 (мільйонний) об'єкт

Епілог
Команда DWH в Тінькофф Банку бере стратегічний курс в напрямку Hadoop. В наступних статтях плануємо висвітлити теми «ETL/ELT на Hadoop» і «Ad-hoc звітність на Hadoop».

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.