Data Lake – від теорії до практики. Методи інтеграції даних Hadoop і корпоративного DWH

У цій статті я хочу розповісти про важливу задачу, про яку потрібно думати і потрібно вміти вирішувати, якщо аналітичної платформи для роботи з даними з'являється такий важливий компонент як Hadoop — завдання інтеграції даних Hadoop і даних корпоративного DWH. У Data Lake Тинькофф Банку ми навчилися ефективно вирішувати цю задачу і далі у статті я розповім, як ми це зробили.



Дана стаття є продовженням циклу статей про Data Lake Тинькофф Банку (попередня стаття Data Lake – від теорії до практики. Розповідь про те, як ми будуємо ETL на Hadoop).



Завдання
Ліричний відступ. Вище на малюнку зображено мальовнича озера, а точніше система озер – одну трохи менше, іншу більше. Те, що поменше, гарне таке, ушляхетнене, з яхтами – це корпоративне DWH. А те, що видніється на горизонті і не поміщається на картинці в силу своїх розмірів – це Hadoop. Ліричний відступ закінчено, до справи.
Завдання у нас була досить тривіальна з точки зору вимог, і нетривіальна з точки зору вибору технології і реалізації. Нам треба було прорити канал між цими двома озерами, налагодити простий і ефективний спосіб публікації даних з Hadoop в DWH і назад в межах регламентних процесів, що виникають в Data Lake.

Вибір технології
Здавалося б, завдання дуже проста – навчитися швидко переганяти дані таблиці Hive в таблицю Greenplum і назад. Вирішувати такі задачі, як правило, прийнято через ETL. Але, замислившись про обсяги таблиць (десятки мільйонів рядків, гігабайти даних) ми з початку провели дослідження. У дослідженні ми порівняли чотири підходи:
  • Sqoop — інструмент, що входить в екосистему Hadoop, для пересилання даних між структурованими сховищами і HDFS;
  • Informatica Big Data Edition – використовується у нас як ETL платформа для batch обробки даних в Hadoop;
  • SAS Data Integration Studio — використовується у нас як ETL платформа для обробки даних в корпоративному DWH (Greenplum);
  • gphdfs – інструмент/утиліта, що входить до складу СУБД Greenplum, для роботи (читання/запис даних) з HDFS.


Далі розповім про переваги і недоліки кожного з них.

Sqoop
Sqoop — це засіб, призначений для передачі даних між кластерами Hadoop і реляційними базами даних. З його допомогою можна імпортувати дані з системи управління реляційної базою даних реляційної СУБД), наприклад, SQL Server, MySQL або Oracle, в розподілену файлову систему Hadoop (HDFS), перетворити дані в системі Hadoop з використанням MapReduce або Hive, а потім експортувати дані назад в реляційну СУБД.
Оскільки в задачі спочатку не передбачалася трансформація, то начебто Sqoop ідеально підходить для вирішення поставленого завдання. Виходить, що як тільки з'являється потреба публікації таблиці (або в Hadoop, або в Greenplum), необхідно написати завдання (job) на Sqoop і це завдання навчитися викликати на одному з планувальників (SAS або Informatica), в залежності від регламенту.
Все добре, але Sqoop працює з Greenplum через JDBC. Ми зіткнулися з дуже низькою продуктивністю. Тестова таблиця 30 Gb вивантажується в Greenplum близько 1 години. Результат вкрай незадовільний. Від Sqoop відмовилися. Хоча в цілому, це дуже зручний інструмент для того що б, наприклад, вивантажити разово в Hadoop, дані якої-небудь не дуже великий таблиці реляційної БД. Але, для того що б будувати регламентні процеси на Sqoop, потрібно чітко розуміти вимоги до продуктивності роботи цих процесів і на основі цього приймати рішення.

Informatica Big Data Edition
Informatica Big Data Edition ми використовуємо як ELT движок обробки даних в Hadoop. Тобто якраз з допомогою Informatica BDE ми будуємо в Hadoop ті вітрини, які потрібно опублікувати в Greenplum, де вони стануть доступні іншим прикладним системам банку. Начебто логічно, після того як ELT процеси відпрацювали на кластері Hadoop, побудували вітрину даних, зробити push цієї вітрини в Greenplum. Для роботи з СУБД Greenplum в Informatica BDE є PWX for Greenplum, який може працювати як в режимі Native, так і в режимі Hive. Тобто, як тільки з'являється потреба публікації таблиці з Hadoop в Greenplum, необхідно написати завдання (mapping) на Informatica BDE і це завдання викликати на планувальнику Informatica.
Все добре, але є нюанс. PWX for Greenplum в режимі Native працює як класичний ETL, тобто вичитує з Hive дані на ETL сервер і вже на ETL сервері піднімає сесію gpload і завантажує дані в Greenplum. Виходить, що весь потік даних впирається в ETL-сервер.
Далі провели експерименти в режимі Hive. PWX for Greenplum в режимі Hive працює без участі ETL сервера, ETL сервер тільки керує процесом, вся робота з даними відбувається на стороні кластера Hadoop (компоненти Informatica BDE встановлюються так само і на кластер Hadoop). У цьому випадку сесії gpload піднімаються на вузлах кластера Hadoop і вантажать дані в Greenplum. Тут ми не отримуємо вузьке місце у вигляді ETL сервера і продуктивність роботи такого підходу вийшла доволі хорошою — тестова таблиця 30 Gb вивантажується в Greenplum близько 15 хвилин. Але PWX for Greenplum в режимі Hive працював, на момент проведення досліджень, нестабільно. І є ще один важливий момент. Якщо потрібно зробити зворотний публікацію даних (з Greenplum в Hadoop) PWX for Greenplum працює через ODBC.
Для вирішення задачі було прийнято рішення не використовувати Informatica BDE.

SAS Data Integration Studio
SAS Data Integration Studio ми використовуємо як ELT движок обробки даних в Greenplum. Тут виходить інша картина. Informatica BDE будує необхідну вітрину в Hadoop, далі SAS DIS робить pull цієї вітрини в Greenplum. Або інакше, SAS DIS будує якусь вітрину в Greenplum, далі робить push цієї вітрини в Hadoop. Начебто красиво. Для роботи з Hadoop в SAS DIS є спеціальні компонент SAS Access Interface to Hadoop. Проводячи паралель з PWX for Greenplum, SAS Access Interface to Hadoop немає режиму роботи Hive і тому всі дані поллються через ETL сервер. Отримали незадовільну продуктивність роботи процесів.

gphdfs
gphdfs – утиліта, що входить до складу СУБД Greenplum, що дозволяє організувати паралельний транспорт даних між сегмент серверами Greenplum і вузлами з даними Hadoop. Провели експерименти з публікацією даних з Hadoop в Greenplum, і назад – продуктивність праці процесів просто вразила. Тестова таблиця 30 Gb вивантажується в Greenplum близько 2 хвилин.



Аналіз отриманих результатів
Для наочності в таблиці нижче наведені результати досліджень.

Технологія Складність інтеграції в регламентні процеси Трудомісткість розробки процесів Продуктивність роботи процесів (Hadoop -> Greenplum) Продуктивність роботи процесів (Greenplum -> Hadoop)
Sqoop Складно Низька Незадовільна (JDBC) Незадовільна (JDBC)
Informatica Big Data Edition (PWX for Greenplum в режимі Native) Легко Низька Незадовільна (gpload на ETL сервері) Незадовільна (ODBC)
Informatica Big Data Edition (PWX for Greenplum в режимі Hive) Легко Низька Задовільна (gpload на вузлах кластера Hadoop) Незадовільна (ODBC)
SAS Data Integration Studio (SAS Access Interface to Hadoop) Легко Низька Незадовільна Незадовільна
gphdfs Складно Висока Дуже висока (gphdfs) Дуже висока (gphdfs)


Висновок вийшов двозначний — з найменшими проблемами в продуктивності роботи процесів, ми отримуємо утиліту, яку абсолютно неприйнятно використовувати в розробці ETL процесів як є. Ми задумалися… ELT платформа SAS Data Integration Studio дозволяє розробляти на ній свої компоненти (трансформы) і ми вирішили, для того що б знизити трудомісткість розробки ETL процесів і знизити складність інтеграції в регламентні процеси, розробити два трансформації, які полегшать роботу з gphdfs без втрати продуктивності роботи цільових процесів. Далі розповім про деталі реалізації.

Реалізація трансформов
У цих двох трансформов досить просте завдання, виконати послідовно набір операцій навколо Hive і gphdfs.
Приклад (дизайн) трансформації для публікації даних з Hadoop в Greenplum.



  1. Hive Table — таблиця Hive, зареєстрована в метаданих SAS DI;
  2. Transform — трансформ, кроки якого опишу далі;
  3. Greenplum Table – цільова або work таблиця Greenplum;


Що робить трансформ:
  1. Створює зовнішню таблицю work БД в Hive. Зовнішня таблиця створюється з використанням сериализатора, зрозумілим для gphdfs (тобто або CSV, або TEXT);
  2. Виконує перевантаження з потрібної нам таблиці Hive (джерело), work таблицю в Hive (створену у попередньому пункті). Робимо для того що б перекласти потрібні нам дані у формат зрозумілий для gphdfs. Т. к. завдання виконується на кластері, в продуктивності не втрачаємо. На додаток ми отримуємо незалежність від формату даних використовуваного в таблиці джерелі у Hive (PARQUET, ЗАЛІЗНИЧНІ тощо);
  3. Створює work схемою завдання (job) в Greenplum зовнішню таблицю gphdfs, яка дивиться на файли в hdfs, які були записані в результаті виконання попереднього кроку;
  4. Виконує select зовнішньої таблиці створеної на попередньому кроці) – profit! Дані потекли c даних вузлів кластера Hadoop на сегмент сервера кластер Greenplum.


Розробнику залишається додати цей трансформ у job (завдання) і вказати назви вхідний і вихідний таблиць.
Розробка такого процесу займає близько 15 хвилин.


За аналогією був реалізований трансформ для публікації даних з Greenplum в Hadoop.

ВАЖЛИВО. Ще один з бенефітів який ми отримали вирішивши цю задачу, ми потенційно готові організовувати процес offload-а даних з корпоративного DWH в більш дешевий Hadoop.

Висновок
Що я цим хотів розповісти. Два основних моменти:
1. Коли ви працюєте з великими обсягами даних дуже уважно підходите до вибору технології. Уважно вивчайте задачу, яку збираєтеся вирішувати, з усіх сторін. Звертайте увагу на сильні і слабкі сторони технології. Намагайтеся уникати вузьких місць. Неправильний вибір технології може сильно вплинути, нехай і не відразу, на продуктивність роботи системи і як наслідок на бізнес-процес, у яких бере участь ваша система;
2. Не лякайтеся, а навпаки вітайте доопрацювання вашої платформи інтеграції даних самописними компонентами. Це дозволяє значно знизити вартість і час подальшої розробки і підтримки.

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

0 коментарів

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