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 — это средство, предназначенное для передачи данных между кластерами 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 мы используем как 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 мы используем как 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 — утилита, входящая в состав СУБД 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.
- Hive Table — таблица в Hive, зарегистрированная в метаданных SAS DI;
- Transform — трансформ, шаги которого опишу дальше;
- Greenplum Table — целевая или work таблица в Greenplum;
Что делает трансформ:
- Создаёт внешнюю таблицу в work БД в Hive. Внешняя таблица создаётся с использованием сериализатора, понятным для gphdfs (т.е. или CSV, или TEXT);
- Выполняет перегрузку из нужной нам таблицы Hive (источник), в work таблицу в Hive (созданную в предыдущем пункте). Делаем для того что бы переложить нужные нам данные в формат понятный для gphdfs. Т.к. задача выполняется на кластере, в производительности не теряем. В дополнение мы получаем независимость от формата данных используемого в таблице источнике в Hive (PARQUET, ORC и т.д.);
- Создаёт в work схеме задания (job) в Greenplum внешнюю таблицу gphdfs, которая смотрит на файлы в hdfs, которые были записаны в результате выполнения предыдущего шага;
- Выполняет select из внешней таблицы (созданной в предыдущем шаге) — profit! Данные потекли c узлов данных кластера Hadoop на сегмент сервера кластер Greenplum.
Разработчику остается добавить этот трансформ в job (задание) и указать названия входной и выходной таблиц.
Разработка такого процесса занимает около 15 минут.
По аналогии был реализован трансформ для публикации данных из Greenplum в Hadoop.
ВАЖНО. Ещё один из бенефитов который мы получили решив эту задачу, мы потенциально готовы организовывать процесс offload-а данных из корпоративного DWH в более дешевый Hadoop.
Что я этим хотел рассказать. Основных момента два:
1. Когда вы работаете с большими объемами данных очень внимательно подходите к выбору технологии. Внимательно изучайте задачу, которую собираетесь решать, со всех сторон. Обращайте внимание на сильные и слабые стороны технологии. Старайтесь избегать узких мест. Неправильный выбор технологии может сильно повлиять, пусть и не сразу, на производительность работы системы и как следствие на бизнес процесс, в которым участвует ваша система;
2. Не пугайтесь, а наоборот приветствуйте доработки вашей платформы интеграции данных самописными компонентами. Это позволяет на порядки снизить стоимость и время дальнейшей разработки и поддержки.