Коли у вас ощадних масштабів. Використання Ab Initio при роботі з Hive та GreenPlum

Якийсь час тому перед нами постало питання вибору ETL-засобу для роботи з BigData. Рішення Informatica BDM, що раніше використовувалося, не влаштовувало нас через обмежену функціональність. Її використання звелося до фреймворку із запуску команд spark-submit. На ринку було не так багато аналогів, в принципі здатних працювати з тим обсягом даних, з яким ми маємо справу щодня. У результаті ми вибрали Ab Initio. Під час пілотних демонстрацій продукт показав дуже високу швидкість обробки даних. Інформації про Ab Initio російською майже немає, тому ми вирішили розповісти про свій досвід на Хабрі.

Ab Initio має безліч класичних і незвичайних трансформацій, код яких може бути розширений за допомогою власної мови PDL. Для дрібного бізнесу такий потужний інструмент, ймовірно, буде надмірним, і більшість його можливостей можуть виявитися дорогими та незатребуваними. Але якщо ваші масштаби наближаються до ощадних, то вам Ab Initio може бути цікавим.

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

У пості я розповім про можливості Ab Initio і наведу порівняльні характеристики щодо його роботи з Hive та GreenPlum.

• Опис фреймворку MDW та робіт з його доналаштування під GreenPlum
• Порівняльні характеристики продуктивності Ab Initio по роботі з Hive та GreenPlum
• Робота Ab Initio з GreenPlum у режимі Near Real Time

Функціонал цього продукту дуже широкий і вимагає чимало часу на вивчення. Однак, при належних навичках роботи та правильних налаштуваннях продуктивності результати обробки даних виходять дуже вражаючі. Використання Ab Initio для розробника може надати йому цікавий досвід. Це новий погляд на ETL-розробку, гібрид між візуальним середовищем та розробкою завантажень скрипто-подібною мовою.

Бізнес розвиває свої екосистеми і цей інструмент виявляється йому як ніколи до речі. За допомогою Ab Initio можна накопичувати знання про поточний бізнес та використовувати ці знання для розширення старих та відкриття нових бізнесів. Альтернативами Ab Initio можна назвати із візуальних середовищ розробки Informatica BDM та з невізуальних середовищ – Apache Spark.

Опис Ab Initio

Ab Initio, як і інші ETL-засоби, є набір продуктів.

Ab Initio GDE (Graphical Development Environment) – це середовище для розробника, в якому він налаштовує трансформації даних та з'єднує їх потоками даних у вигляді стрілок. При цьому такий набір трансформацій називається графом:

Вхідні та вихідні з'єднання функціональних компонентів є портами та містять поля, обчислені всередині перетворень. Декілька графів, з'єднаних потоками у вигляді стрілочок у порядку їх виконання називаються планом.

Є кілька сотень функціональних компонентів, що дуже багато. Багато з них вузькоспеціалізовані. Можливості класичних трансформацій у Ab Initio ширші, ніж у інших ETL-засобах. Наприклад, Join має кілька виходів. Крім результату з'єднання датасетів, можна отримати на виході запису вхідних датасетів, за ключами яких не вдалося з'єднатися. Також можна отримати rejects, errors та лог роботи трансформації, який можна в цьому ж графі прочитати як текстовий файл та обробити іншими трансформаціями:

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

Є оригінальні трансформації. Наприклад, трансформація Scan має функціонал як у аналітичних функцій. Є трансформації з назвами, що говорять: Create Data, Read Excel, Normalize, Sort within Groups, Run Program, Run SQL, Join with DB та ін. Графи можуть використовувати параметри часу виконання, у тому числі можлива передача параметрів з операційної системи або в операційну систему . Файли з готовим набором параметрів, що передаються графу, називаються parameter sets (psets).

Як і належить, Ab Initio GDE має власний репозиторій, званий EME (Enterprise Meta Environment). Розробники мають можливість працювати з локальними версіями коду та робити check in своїх розробок у центральний репозиторій.

Є можливість під час виконання або після виконання графа клікнути по будь-якому потоку, що сполучає трансформації, і подивитися на дані, що пройшли між цими трансформаціями:

Також є можливість клікнути по будь-якому потоку і подивитися tracking details – скільки паралелей працювала трансформація, скільки рядків і байт в якому з паралелей завантажилося:

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

У кожній трансформації можна вибрати так званий layout (де вона виконуватиметься): без паралелей або паралельних потоках, число яких можна задати. При цьому тимчасові файли, які створює Ab Initio під час роботи трансформацій, можна розміщувати як у файловій системі сервера, так і HDFS.

У кожній трансформації на базі шаблону за замовчуванням можна створити свій скрипт мовою PDL, яка трохи нагадує shell.

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

Також Ab Initio добре розвинена інтеграція з ОС через shell. Саме Ощадбанку використовується linux ksh. Можна обмінюватися зі shell змінними та використовувати їх як параметри графів. Ви можете викликати виконання графів Ab Initio і адмініструвати Ab Initio.

Крім Ab Initio GDE, в поставку входить багато інших продуктів. Є своя Co> Operation System із претензією називатися операційною системою. Є Control>Center, де можна ставити на розклад і моніторити потоки завантаження. Є продукти для розробки на більш примітивному рівні, ніж дозволяє Ab Initio GDE.

Опис фреймворку MDW та робіт з його доналаштування під GreenPlum

Разом зі своїми продуктами вендор поставляє продукт MDW (Metadata Driven Warehouse), який є конфігуратором графів, призначений для допомоги в типових завданнях по наповненню сховищ даних або data vaults.

Він містить користувацькі (специфічні для проекту) парсери метаданих і готові генератори коду "з коробки".

На вході MDW отримує модель даних, конфігураційний файл з налаштування з'єднання з базою даних (Oracle, Teradata або Hive) та деякі інші налаштування. Специфічна для проекту частина, наприклад, розгортає модель бази даних. Коробкова частина продукту генерує графи та настроювальні файли до них із завантаження даних у таблиці моделі. При цьому створюються графи (і psets) для кількох режимів ініціалізації та інкрементальної роботи з оновлення сутностей.

У випадках Hive і RDBMS генеруються графи, що розрізняються за ініціалізуючим і інкрементальним оновленням даних.

У разі Hive дельти, що надійшли, з'єднується за допомогою Ab Initio Join з даними, які були в таблиці до оновлення. Завантажувачі даних у MDW (як у Hive, так і в RDBMS) не тільки вставляють нові дані з дельти, а й закривають періоди актуальності даних, за первинними ключами яких надійшла дельта. Крім того, доводиться переписати заново незмінну частину даних. Але так доводиться робити, оскільки у Hive немає операцій delete чи update.

У випадку RDBMS графи по інкрементальному оновленню даних виглядають більш оптимально, тому що RDBMS мають реальні можливості оновлення.

Дельта, що надійшла, завантажується в проміжну таблицю в базу даних. Після цього відбувається з'єднання дельти з даними, що були у таблиці до оновлення. І робиться це силами SQL у вигляді згенерованого SQL-запиту. Далі за допомогою SQL-команд delete+insert у цільову таблицю відбувається вставка нових даних із дельти та закриття періодів актуальності даних, за первинними ключами яких надійшла дельта.
Дані, що незмінилися, переписувати немає потреби.

Таким чином, ми дійшли висновку, що у випадку Hive MDW має піти на переписування всієї таблиці, тому що Hive не має функції оновлення. І нічого кращого за повне переписування даних при оновленні не придумано. У разі RDBMS, навпаки, творці продукту вважали за потрібне довірити з'єднання та оновлення таблиць використання SQL.

Для проекту в Ощадбанку ми створили нову реалізацію завантажувача бази даних для GreenPlum. Зроблено це на основі версії, яку MDW генерує для Teradata. Саме Teradata, а чи не Oracle підійшла при цьому краще і найближче, т.к. також є MPP-системою. Способи роботи, а також синтаксис Teradata та GreenPlum виявилися близькими.

Приклади критичних для MDW відмінностей між різними RDBMS є такими. У GreenPlum на відміну від Teradata під час створення таблиць потрібно писати клаузу

distributed by

У Teradata пишуть

delete <table> all

, а у GreеnPlum пишуть

delete from <table>

В Oracle з метою оптимізації пишуть

delete from t where rowid in (<соединение t с дельтой>)

, а в Teradata та GreenPlum пишуть

delete from t where exists (select * from delta where delta.pk=t.pk)

Ще зазначимо, що для роботи Ab Initio з GreenPlum потрібно встановити клієнт GreenPlum на всі ноди кластера Ab Initio. Це тому, що ми підключилися до GreenPlum одночасно з усіх вузлів кластера. А для того, щоб читання з GreenPlum було паралельним і кожен паралельний потік Ab Initio читав свою порцію даних з GreenPlum, довелося до секції «where» SQL-запитів помістити конструкцію, що розуміється Ab Initio.

where ABLOCAL()

і визначити значення цієї конструкції, вказавши, що читає з БД трансформації параметр

ablocal_expr=«string_concat("mod(t.", string_filter_out("{$TABLE_KEY}","{}"), ",", (decimal(3))(number_of_partitions()),")=", (decimal(3))(this_partition()))»

яка компілюється в щось типу

mod(sk,10)=3

, тобто. доводиться підказувати GreenPlum явний фільтр кожної партиції. Для інших баз даних (Teradata, Oracle) Ab Initio може виконати це розпаралелювання автоматично.

Порівняльні характеристики продуктивності Ab Initio по роботі з Hive та GreenPlum

У Ощадбанку був проведений експеримент порівняно продуктивності згенерованих MDW графів стосовно Hive і GreenPlum. В рамках експерименту у випадку Hive було 5 нод на тому ж кластері, що і Ab Initio, а у випадку GreenPlum було 4 ноди на окремому кластері. Тобто. Hive мав деяку перевагу над GreenPlum «залізом».

Було розглянуто дві пари графів, що виконують одну і ту ж задачу оновлення даних у Hive та GreenPlum. При цьому запускали графи, згенеровані MDW конфігуратором:

• ініціалізуюче завантаження + інкрементальне завантаження випадково згенерованих даних у таблицю Hive
• ініціалізуюче завантаження + інкрементальне завантаження випадково згенерованих даних у таку саму таблицю GreenPlum

В обох випадках (Hive та GreenPlum) запускали завантаження в 10 паралельних потоків на тому самому кластері Ab Initio. Проміжні дані для розрахунків Ab Initio зберігав HDFS (у термінах Ab Initio був використаний MFS layout using HDFS). Один рядок випадково згенерованих даних займав в обох випадках по 200 байт.

Результат вийшов такий:

Вулик:

Ініціалізуюче завантаження в Hive

Вставлено рядків
6 000 000
60 000 000
600 000 000

Тривалість ініціалізує
завантаження в секундах
41
203
1 601

Інкрементальне завантаження в Hive

Кількість рядків, які були в
цільової таблиці початку експерименту
6 000 000
60 000 000
600 000 000

Кількість рядків дельти, застосованих до
цільової таблиці під час експерименту
6 000 000
6 000 000
6 000 000

Тривалість інкрементальної
завантаження в секундах
88
299
2 541

GreenPlum:

Ініціалізоване завантаження в GreenPlum

Вставлено рядків
6 000 000
60 000 000
600 000 000

Тривалість ініціалізує
завантаження в секундах
72
360
3 631

Інкрементальне завантаження в GreenPlum

Кількість рядків, які були в
цільової таблиці початку експерименту
6 000 000
60 000 000
600 000 000

Кількість рядків дельти, застосованих до
цільової таблиці під час експерименту
6 000 000
6 000 000
6 000 000

Тривалість інкрементальної
завантаження в секундах
159
199
321

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

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

Інкрементальне завантаження в GreenPlum слабо залежить від обсягу наявних в цільовій таблиці раніше завантажених даних і проходить досить швидко. Вийшло це завдяки SQL Joins та архітектурі GreenPlum, що допускає операцію delete.

Отже, GreenPlum вливає дельту шляхом delete+insert, а в Hive немає операцій delete або update, тому весь масив даних при інкрементальному оновленні були змушені переписувати повністю. Найбільш показовим є порівняння виділених жирних осередків, оскільки воно відповідає найчастішому варіанту експлуатації ресурсомістких завантажень. Бачимо, що GreenPlum виграв у Hive у цьому тесті у 8 разів.

Робота Ab Initio з GreenPlum у режимі Near Real Time

У цьому експерименті перевіримо можливість Ab Initio проводити оновлення таблиці GreenPlum порціями даних, що випадково формуються, в режимі, близькому до реального часу. Розглянемо таблицю GreenPlum dev42_1_db_usl.TESTING_SUBJ_org_finval, з якою вестиметься робота.

Будемо використовувати три графи Ab Initio по роботі з нею:

1) Граф Create_test_data.mp – створює в 10 паралельних потоків файли з даними HDFS на 6 000 000 рядків. Дані випадкові, їх структура організована для вставки в нашу таблицю

2) Граф mdw_load.day_one.current.dev42_1_db_usl_testing_subj_org_finval.pset – згенерований MDW граф за ініціалізуючою вставкою даних у нашу таблицю в 10 паралельних потоків (використовуються тестові дані, згенеровані графом)

3) Граф mdw_load.regular.current.dev42_1_db_usl_testing_subj_org_finval.pset - згенерований MDW граф по інкрементальному оновленню нашої таблиці в 10 паралельних потоків з використанням порції свіжих даних (дельти), згенерованих граф

Виконаємо нижченаведений сценарій у режимі NRT:

• згенерувати 6 тестових рядків
• зробити ініціалізуюче завантаження вставити 6 000 000 тестових рядків у порожню таблицю
• повторити 5 разів інкрементальне завантаження
  • згенерувати 6 тестових рядків
  • зробити інкрементальну вставку 6 000 000 тестових рядків у таблицю (при цьому старими даними проставляється час закінчення актуальності valid_to_ts і вставляються свіжіші дані з тим самим первинним ключем)

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

Тепер подивимося лог роботи сценарію:

Start Create_test_data.input.pset at 2020-06-04 11:49:11
Finish Create_test_data.input.pset at 2020-06-04 11:49:37
Start mdw_load.day_one.current.dev42_1_db_usl_testing_subj_org_finval.pset at 2020-06-04 11:49:37
Finish mdw_load.day_one.current.dev42_1_db_usl_testing_subj_org_finval.pset at 2020-06-04 11:50:42
Start Create_test_data.input.pset at 2020-06-04 11:50:42
Finish Create_test_data.input.pset at 2020-06-04 11:51:06
Start mdw_load.regular.current.dev42_1_db_usl_testing_subj_org_finval.pset at 2020-06-04 11:51:06
Finish mdw_load.regular.current.dev42_1_db_usl_testing_subj_org_finval.pset at 2020-06-04 11:53:41
Start Create_test_data.input.pset at 2020-06-04 11:53:41
Finish Create_test_data.input.pset at 2020-06-04 11:54:04
Start mdw_load.regular.current.dev42_1_db_usl_testing_subj_org_finval.pset at 2020-06-04 11:54:04
Finish mdw_load.regular.current.dev42_1_db_usl_testing_subj_org_finval.pset at 2020-06-04 11:56:51
Start Create_test_data.input.pset at 2020-06-04 11:56:51
Finish Create_test_data.input.pset at 2020-06-04 11:57:14
Start mdw_load.regular.current.dev42_1_db_usl_testing_subj_org_finval.pset at 2020-06-04 11:57:14
Finish mdw_load.regular.current.dev42_1_db_usl_testing_subj_org_finval.pset at 2020-06-04 11:59:55
Start Create_test_data.input.pset at 2020-06-04 11:59:55
Finish Create_test_data.input.pset at 2020-06-04 12:00:23
Start mdw_load.regular.current.dev42_1_db_usl_testing_subj_org_finval.pset at 2020-06-04 12:00:23
Finish mdw_load.regular.current.dev42_1_db_usl_testing_subj_org_finval.pset at 2020-06-04 12:03:23
Start Create_test_data.input.pset at 2020-06-04 12:03:23
Finish Create_test_data.input.pset at 2020-06-04 12:03:49
Start mdw_load.regular.current.dev42_1_db_usl_testing_subj_org_finval.pset at 2020-06-04 12:03:49
Finish mdw_load.regular.current.dev42_1_db_usl_testing_subj_org_finval.pset at 2020-06-04 12:06:46

Виходить така картина:

Графік
Час початку
Час закінчення
довжина

Create_test_data.input.pset
04.06.2020 11: 49: 11
04.06.2020 11: 49: 37
00:00:26

mdw_load.day_one.current.
dev42_1_db_usl_testing_subj_org_finval.pset
04.06.2020 11: 49: 37
04.06.2020 11: 50: 42
00:01:05

Create_test_data.input.pset
04.06.2020 11: 50: 42
04.06.2020 11: 51: 06
00:00:24

mdw_load.regular.current.
dev42_1_db_usl_testing_subj_org_finval.pset
04.06.2020 11: 51: 06
04.06.2020 11: 53: 41
00:02:35

Create_test_data.input.pset
04.06.2020 11: 53: 41
04.06.2020 11: 54: 04
00:00:23

mdw_load.regular.current.
dev42_1_db_usl_testing_subj_org_finval.pset
04.06.2020 11: 54: 04
04.06.2020 11: 56: 51
00:02:47

Create_test_data.input.pset
04.06.2020 11: 56: 51
04.06.2020 11: 57: 14
00:00:23

mdw_load.regular.current.
dev42_1_db_usl_testing_subj_org_finval.pset
04.06.2020 11: 57: 14
04.06.2020 11: 59: 55
00:02:41

Create_test_data.input.pset
04.06.2020 11: 59: 55
04.06.2020 12: 00: 23
00:00:28

mdw_load.regular.current.
dev42_1_db_usl_testing_subj_org_finval.pset
04.06.2020 12: 00: 23
04.06.2020 12: 03: 23
00:03:00

Create_test_data.input.pset
04.06.2020 12: 03: 23
04.06.2020 12: 03: 49
00:00:26

mdw_load.regular.current.
dev42_1_db_usl_testing_subj_org_finval.pset
04.06.2020 12: 03: 49
04.06.2020 12: 06: 46
00:02:57

Бачимо, що 6 рядків інкременту обробляються за 000 хвилини, що досить швидко.
Дані в цільовій таблиці вийшли розподіленими таким чином:

select valid_from_ts, valid_to_ts, count(1), min(sk), max(sk) from dev42_1_db_usl.TESTING_SUBJ_org_finval group by valid_from_ts, valid_to_ts order by 1,2;

Можна розглянути відповідність вставлених даних моментів запуску графів.
Отже, можна запускати в Ab Initio інкрементальне завантаження даних у GreenPlum з дуже високою частотою і спостерігати високу швидкість вставки цих даних у GreenPlum. Звичайно, раз на секунду запускатися не вийде, тому що Ab Initio, як і будь-який ETL-засіб, при запуску вимагає часу "на розгойдування".

Висновок

Зараз Ab Initio використовується в Ощадбанку для створення єдиного семантичного шару даних (ЕСС). Цей проект передбачає побудову єдиної версії стану різних банківських бізнес-сутностей. Інформація надходить із різних джерел, репліки яких готуються на Hadoop. Виходячи з потреб бізнесу, готується модель даних та описуються трансформації даних. Ab Initio завантажує інформацію в ЄСС і завантажені дані не тільки представляють інтерес для бізнесу власними силами, а й служать джерелом для побудови вітрин даних. При цьому функціонал продукту дозволяє використовувати як приймач різні системи (Hive, Greenplum, Teradata, Oracle), що дає можливість без особливих зусиль готувати дані для бізнесу в різних необхідних йому форматах.

Можливості Ab Initio широкі, наприклад, фреймворк MDW, що додається, дає можливість будувати технічну і бізнес-історичність даних "з коробки". Для розробників Ab Initio дає можливість "не винаходити велосипед", а користуватися безліччю наявних функціональних компонентів, які є бібліотеками, потрібними при роботі з даними.

Автор – експерт професійної спільноти Ощадбанку SberProfi DWH/BigData. Професійна спільнота SberProfi DWH/BigData відповідає за розвиток компетенцій у таких напрямках, як екосистема Hadoop, Teradata, Oracle DB, GreenPlum, а також BI інструменти Qlik, SAP BO, Tableau та ін.

Джерело: habr.com