- PVSM.RU - https://www.pvsm.ru -
В этой статье я хочу рассказать про важную задачу, о которой нужно думать и нужно уметь решать, если в аналитической платформе для работы с данными появляется такой важный компонент как Hadoop — задача интеграции данных Hadoop и данных корпоративного DWH. В Data Lake в Тинькофф Банке мы научились эффективно решать эту задачу и дальше в статье я расскажу, как мы это сделали.
Данная статья является продолжением цикла статей про Data Lake в Тинькофф Банке (предыдущая статья Data Lake – от теории к практике. Сказ про то, как мы строим ETL на Hadoop [1]).
Лирическое отступление. Выше на рисунке изображено живописное озера, а точнее система озер – одно поменьше, другое побольше. То, что поменьше, красивое такое, облагороженное, с яхтами – это корпоративное DWH. А то, что виднеется на горизонте и не помещается на картинке в силу своих размеров – это Hadoop. Лирическое отступление окончено, к делу.
Задача у нас была достаточно тривиальная с точки зрения требований, и нетривиальная с точки зрения выбора технологии и реализации. Нам надо было прорыть канал между этими двумя озерами, наладить простой и эффективный способ публикации данных из Hadoop в DWH и обратно в рамках регламентных процессов, проистекающих в Data Lake.
Казалось бы, задача очень простая – научиться быстро перегонять данные таблицы Hive в таблицу Greenplum [2] и обратно. Решать такие задачи, как правило, принято через ETL. Но, задумавшись об объемах таблиц (десятки миллионов строк, гигабайты данных) мы с начала провели исследование. В исследовании мы сравнили четыре подхода:
Далее расскажу про преимущества и недостатки каждого из них.
Sqoop [3] — это средство, предназначенное для передачи данных между кластерами 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 [4] мы используем как 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 [5] мы используем как 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 [6] – утилита, входящая в состав СУБД 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.
Что делает трансформ:
Разработчику остается добавить этот трансформ в job (задание) и указать названия входной и выходной таблиц.
Разработка такого процесса занимает около 15 минут.
По аналогии был реализован трансформ для публикации данных из Greenplum в Hadoop.
ВАЖНО. Ещё один из бенефитов который мы получили решив эту задачу, мы потенциально готовы организовывать процесс offload-а данных из корпоративного DWH в более дешевый Hadoop.
Что я этим хотел рассказать. Основных момента два:
1. Когда вы работаете с большими объемами данных очень внимательно подходите к выбору технологии. Внимательно изучайте задачу, которую собираетесь решать, со всех сторон. Обращайте внимание на сильные и слабые стороны технологии. Старайтесь избегать узких мест. Неправильный выбор технологии может сильно повлиять, пусть и не сразу, на производительность работы системы и как следствие на бизнес процесс, в которым участвует ваша система;
2. Не пугайтесь, а наоборот приветствуйте доработки вашей платформы интеграции данных самописными компонентами. Это позволяет на порядки снизить стоимость и время дальнейшей разработки и поддержки.
Автор: Тинькофф Банк
Источник [7]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/sql/117396
Ссылки в тексте:
[1] Data Lake – от теории к практике. Сказ про то, как мы строим ETL на Hadoop: https://habrahabr.ru/company/tcsbank/blog/259173/
[2] Greenplum: https://habrahabr.ru/company/tcsbank/blog/267733/
[3] Sqoop: http://sqoop.apache.org/
[4] Informatica Big Data Edition: https://www.informatica.com/products/data-integration/powercenter.html
[5] SAS Data Integration Studio: http://support.sas.com/documentation/cdl/en/etlug/67323/HTML/default/viewer.htm#titlepage.htm
[6] gphdfs: http://gpdb.docs.pivotal.io/4340/admin_guide/load/topics/g-gphdfs.html
[7] Источник: https://habrahabr.ru/post/281196/
Нажмите здесь для печати.