В этой статье я хочу рассказать про важную задачу, о которой нужно думать и нужно уметь решать, если в аналитической платформе для работы с данными появляется такой важный компонент как 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 минут.

Анализ полученных результатов

Для наглядности в таблице ниже приведены результаты исследований.

Вывод получился двусмысленный — с наименьшими проблемами в производительности работы процессов, мы получаем утилиту, которую совершенно неприемлемо использовать в разработке 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, ORC и т.д.);
3. Создаёт в work схеме задания (job) в Greenplum внешнюю таблицу gphdfs, которая смотрит на файлы в hdfs, которые были записаны в результате выполнения предыдущего шага;
4. Выполняет select из внешней таблицы (созданной в предыдущем шаге) – profit! Данные потекли c узлов данных кластера Hadoop на сегмент сервера кластер Greenplum.

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

По аналогии был реализован трансформ для публикации данных из Greenplum в Hadoop.

ВАЖНО. Ещё один из бенефитов который мы получили решив эту задачу, мы потенциально готовы организовывать процесс offload-а данных из корпоративного DWH в более дешевый Hadoop.

Заключение

Что я этим хотел рассказать. Основных момента два:
1. Когда вы работаете с большими объемами данных очень внимательно подходите к выбору технологии. Внимательно изучайте задачу, которую собираетесь решать, со всех сторон. Обращайте внимание на сильные и слабые стороны технологии. Старайтесь избегать узких мест. Неправильный выбор технологии может сильно повлиять, пусть и не сразу, на производительность работы системы и как следствие на бизнес процесс, в которым участвует ваша система;
2. Не пугайтесь, а наоборот приветствуйте доработки вашей платформы интеграции данных самописными компонентами. Это позволяет на порядки снизить стоимость и время дальнейшей разработки и поддержки.

ссылка на оригинал статьи https://habrahabr.ru/post/281196/