Что такое data lake
Data Lake
Data Lake — это репозиторий для хранения, который может вмещать большой объем данных в собственном необработанном формате. Хранилища Data Lake оптимизированы для масштабирования до нескольких терабайт и даже петабайт данных. Данные обычно поступают из нескольких разнородных источников и могут быть структурированными, частично структурированными и неструктурированными. Идея, лежащая в основе Data Lake, — хранение всех данных в исходном состоянии без каких-либо преобразований. Такой подход отличает Data Lake от традиционного хранилища данных, в котором данные преобразуются и обрабатываются во время приема.
Преимущества хранилища Data Lake:
Полное решение Data Lake состоит из компонентов хранения и обработки данных. Хранилище Data Lake создано для обеспечения отказоустойчивости, бесконечной масштабируемости и высокой пропускной способности при получении данных любых форм и размеров. Компонент обработки Data Lake включает в себя один или несколько модулей обработки, созданных для этих целей, и может работать с данными, хранящимися в Data Lake в нужном масштабе.
Когда следует использовать Data Lake
К наиболее распространенным сферам применения Data Lake относятся исследования данных, анализ данных и машинное обучение.
Data Lake также может служить источником данных для хранилища данных. При таком подходе необработанные данные поступают в Data Lake, а затем преобразуются в структурированный формат, поддерживающий запросы. Обычно для этого преобразования задействуется конвейер ELT (извлечение, загрузка и преобразование), в котором данные принимаются и преобразуются на месте. Исходные данные, которые уже являются реляционными, могут передаваться непосредственно в хранилище данных с помощью процесса извлечения, преобразования и загрузки, минуя Data Lake.
Хранилища Data Lake Store часто используются при потоковой передаче событий или в сценариях Интернета вещей, так как они могут хранить большие объемы реляционных и нереляционных данных без преобразования или определения схемы. Они предназначены для обработки больших объемов мелких записей с низкой задержкой и оптимизированы для высокой пропускной способности.
Нужно ли нам озеро данных? А что делать с хранилищем данных?
Это статья перевод моей статьи на medium — Getting Started with Data Lake, которая оказалась довольно популярной, наверное из-за своей простоты. Поэтому я решил написать ее на русском языке и немного дополнить, чтобы простому человеку, который не является специалистом по работе с данными стало понятно, что такое хранилище данных (DW), а что такое озеро данных (Data Lake), и как они вместе уживаются.
Почему я захотел написать про озеро данных? Я работаю с данными и аналитикой больше 10 лет, и сейчас я точно работаю с большими данными в Amazon Alexa AI в Кембридже, который в Бостоне, хотя сам живу в Виктории на острове Ванкувер и часто бываю и в Бостоне, и в Сиэтле, и в Ванкувере, а иногда даже и в Москве выступаю на конференциях. Так же время от времени я пишу, но пишу в основном на английском, и написал уже несколько книг, так же у меня есть потребность делиться трендами аналитики из Северной Америке, и я иногда пишу в телеграмм.
Я всегда работал с хранилищами данных, и с 2015 года стал плотно работать с Amazon Web Services, да и вообще переключился на облачную аналитику (AWS, Azure, GCP). Я наблюдал эволюцию решений для аналитики с 2007 года и сам даже поработал в вендоре хранилищ данных Терадата и внедрял ее в Сбербанке, тогда-то и появилась Big Data с Hadoop. Все стали говорить, что прошла эра хранилищ и теперь все на Hadoop, а потом уже стали говорить про Data Lake, опять же, что теперь уж точно хранилищу данных пришел конец. Но к счастью (может для кого и к несчастью, кто зарабатывал много денег на настройке Hadoop), хранилище данных не ушло.
В этой статье мы и рассмотрим, что такое озеро данных. Статья рассчитана на людей, у которых мало опыта с хранилищами данными или вовсе нет.
На картинке озеро Блед, это одно из моих любимых озер, хотя я там был всего один раз, но запомнил его на всю жизнь. Но мы поговорим о другом типе озера — озеро данных. Возможно многие из вас уже не раз слышали про это этот термин, но еще одно определение никому не повредит.
Прежде всего вот самые популярные определения Озера Данных:
«файловое хранилище всех типов сырых данных, которые доступны для анализа кем-угодно в организации» — Мартин Фовлер.
«Если вы думаете, что витрина данных это бутылка воды — очищенной, запакованной и расфасованной для удобного употребления, то озеро данных это у нас огромный резервуар с водой в ее естественном виде. Пользователи, могу набирать воды для себя, нырять на глубину, исследовать» — Джеймс Диксон.
Теперь мы точно знаем, что озеро данных это про аналитику, оно позволяет нам хранить большие объемы данных в их первоначальной форме и у нас есть необходимый и удобный доступ к данным.
Я часто люблю упрощать вещи, если я могу рассказать сложный термин простыми словами, значит для себя я понял, как это работает и для чего это нужно. Как то, я ковырялся в iPhone в фотогалерее, и меня осенило, так это же настоящее озеро данных, я даже сделал слайд для конференций:
Все очень просто. Мы делаем фотографию на телефон, фотография сохраняется на телефон и может быть сохранено в iCloud (файловое хранилище в облаке). Также телефон собирает мета-данные фотографии: что изображено, гео метка, время. Как результат, мы может использовать удобный интерфейс iPhone, чтобы найти нашу фотографию и при этому мы даже видим показатели, например, когда я ищу фотографии со словом огонь (fire), то я нахожу 3 фотографии с изображение костра. Для меня это прям как Business Intelligence инструмент, который работает очень быстро и четко.
И конечно, нам нельзя забывать про безопасность (авторизацию и аутентификацию), иначе наши данных, могут легко попасть в открытый доступ. Очень много новостей, про крупные корпорации и стартапы, у которых данные попали в открытый доступ из-за халатности разработчиков и не соблюдения простых правил.
Даже такая простая картинка, помогает нам представить, что такое озеро данных, его отличия от традиционного хранилища данных и его основные элементы:
С другой стороны, вендор Snowflake заявляет, что вам больше не нужно думать про озеро данных, так как их платформа данных (до 2020 это было хранилище данных), позволяет вам совместить и озеро данных и хранилище данных. Я работал не много со Snowflake, и это действительно уникальный продукт, который может так делать. Конечно Snowflake стоит денег, но у крупных компаний на западе серьезные бюджеты на аналитику.
В заключении, мое личное мнение, что нам все еще нужно хранилище данных как основной источник данных для нашей отчетности, и все, что не помещается, мы храним в озере данных. Вся роль аналитики — это предоставить удобный доступ бизнесу для принятия решений. Как ни крути, но бизнес пользователи работаю эффективней с хранилищем данных, чем озером данных, например в Amazon — есть Redshift (аналитическое хранилище данных) и есть Redshift Spectrum/Athena (SQL интерфейс для озера данных в S3 на базе Hive/Presto). Тоже самое относится к другим современным аналитическим хранилищам данных.
Давайте рассмотрим типичную архитектура хранилища данных:
Это классическое решение. У нас есть системы источники, с помощью ETL/ELT мы копируем данные в аналитическое хранилище данных и подключаем к Business Intelligence решению (мое любимое Tableau, а ваше?).
Такое решение имеет следующие недостатки:
Цель любого аналитического решения — служить бизнес пользователям. Поэтому мы всегда должны работать от требований бизнеса. (В Амазон это один из принципов — working backwards).
Работая и с хранилищем данных и с озером данных, мы можем сравнить оба решения:
Главный вывод, который можно сделать, что хранилище данных, никак не соревнуется с озером данных, а больше дополняет. Но это вам решать, что подходит для вашего случая. Всегда интересно, попробовать самому, и сделать правильные выводы.
Я хотел бы также рассказать по один из кейсов, когда я стал использовать подход озера данных. Все довольно банально, я попытался использовать инструмент ELT (у нас был Matillion ETL) и Amazon Redshift, мое решение работала, но не укладывалось в требования.
Мне необходимо было взять веб логи, трансформировать их и агрегировать, чтобы предоставить данные для 2х кейсов:
Один файл весил 1-4 мегабайта.
Но была одна трудность. У нас было 7 доменов по всему миру, и за один день создавалось 7 тысяч файлов. Это не очень больше объем, всего 50 гигабайт. Но размер нашего кластера Redshift был тоже небольшим (4 ноды). Загрузка традиционным способом одного файла занимала около минуты. То есть, в лоб задача не решалась. И это был тот случай, когда я решил использовать подход озера данных. Решение выглядело примерно так:
Оно достаточно простое (я хочу заметить, что преимущество работы в облаке это простота). Я использовал:
Совсем недавно я узнал один из недостатков озера данных — это GDPR. Проблема в том, когда клиент просит его удалить, а данные находятся в одном из файлов, мы не можем использовать Data Manipulation Language и операцию DELETE как в базе данных.
Надеюсь, статья прояснила разнице между хранилищем данных и озером данных. Если было интересно, то могу перевести еще свои статьи или статье профессионалов, которых читаю. А также рассказать про решения, с которыми работаю, и их архитектуру.
Хранилище данных vs. Data Lake. Или почему важно научиться ходить перед тем, как начать бегать
Всем привет! Я Игорь Гончаров — руководитель Службы управления данными Уралсиба. В этой статье я поделился нашим видением ответа на вопрос, который периодически слышу от коллег: зачем мы развиваем хранилище данных банка, когда есть технологии Data Lake?
Очевидно, что бизнес всё больше становится датацентричным. Раньше данные, необходимые для аналитической поддержки, группировались вокруг существующих процессов и продуктов. Теперь всё иначе — новые продукты и процессы возникают вокруг данных.
В таком случае на старте надо серьёзно подумать, как лучше организовать сбор, хранение и обработку данных из множества источников, а также какой вариант выбрать — DWH или Data Lake. Сначала это было проблемой для телекома, затем — для финансовых организаций. Сейчас такой же вопрос стоит и перед производственными компаниями.
Геометрический рост объёма окружающих нас данных и происходящий на глазах прорыв в технологиях машинного обучения показывают, что классические хранилища не в состоянии поддерживать идею, которая основана на росте вычислительных мощностей и технологий распределённых вычислений — чем больше данных, тем потенциально лучший результат может выдать модель машинного обучения.
И ещё надо помнить, что хранилища — это история про структурированные данные. А вот для хранения и обработки изображений, аудио и всех остальных видов так называемых NoSQL-данных DWH не предназначены. В ответ на новые требования возникли «озёра данных», основанные на технологиях Hadoop.
Преимущества Data Lake
Один из плюсов Data Lake в том, что они базируются на Open Source решениях и, как следствие, не требуют существенных инвестиций в ПО. Кроме того, «озёра данных» предполагают идею почти бесконечного горизонтального масштабирования, а значит, не надо вкладываться в дорогие серверные мощности.
После создания инфраструктуры Data Lake можно в максимально короткие сроки стартовать загрузку и начать использовать данные. И на первый взгляд, всё понятно: чем больше данных зальём, тем лучше, а что с ними делать дальше — разберётся искусственный интеллект.
А с хранилищами данных сложнее: это недёшево и строить такие вещи надо годами. К тому же появился негативный опыт — в банках не все смогли справиться. Требовалось разбираться с методологией, заниматься построением моделей, организовывать потоки трансформации данных по слоям DWH с использованием специализированного ПО.
Способных на это специалистов было мало и они шли буквально нарасхват. К тому же требовалось создавать команду поддержки, потому что волшебного AI здесь не было.
Могут ли «озёра» вписаться в тренд демократизации данных
«Озеро данных» — это в каком-то смысле дитя цифровой трансформации. А её обязательное свойство — демократизация данных. Поэтому в любой компании работать с данными должны буквально все, а не только специально обученные люди (аналитики, дата-сайентисты).
И даже у последних должна зеркально поменяться стандартная статистика работы с данными. Если раньше 80% времени уходило на поиск данных и 20% — на аналитику, то теперь всё должно было быть наоборот. Но по факту «озеро данных» только увеличило время на добычу информации: теперь у сотрудников 90% времени уходит на поиск.
Более того, принцип информатики, который по-русски звучит как «мусор на входе, мусор на выходе», стал как никогда актуальным. Выяснилось, что модели продвинутой аналитики, позволяющие строить предиктивный анализ, хорошо работают на консистентных, структурированных данных, и плохо — на несопоставимых и сильно прорежённых.
К тому же раньше набор данных (dataset) собирался буквально за часы с помощью SQL-запросов, теперь же на основе Hadoop приходится тратить в разы больше времени.
Важно не превратить озеро в болото
Сейчас на рынке наступило своего рода протрезвление: все чаще от коллег можно услышать, что вопрос правильной организации управления данными (Data Governance) важнее, чем их количество. Даже возник новый термин — «болото данных» (Data Swamp). Пришло понимание, что даже в «озёра» надо заливать не все подряд, а классифицированные и систематизированные данные.
Всё это говорит о том, что самоцель получить как можно больше данных ведёт в тупик. Пользователи в организации хотят, чтобы данные были описаны: откуда они приходят, как модифицируются, что означают и как правильно их интерпретировать.
К тому же полные и структурированные данные имеют высокую бизнес-ценность — речь идёт о том, какую добавленную стоимость в бизнесе они позволяют получить. И на практике такие данные дают свыше 90 процентов ценности в аналитике.
Я считаю, что правильно организованное корпоративное хранилище — оптимальный способ хранения и доступа к таким данным при условии, что концепция хранилища учитывает требования к максимальной демократизации данных.
BI и песочницы для демократизации данных
В Уралсибе хранилище играет роль единого источника данных организации. Однако есть ещё два критично важных элемента архитектурного ландшафта. Первый — это песочницы данных, которые по умолчанию организуются для каждого подразделения, оформляющего учётную запись для доступа к данным хранилища.
Если в хранилище всё пронизано идеей Data Governance, то песочницы — это «царство свободы», где пользователи вольны строить свои наборы данных, комбинировать информацию из слоя оперативных данных и витрин, обогащать внешними данными, а также тем, что получено в ходе построения моделей.
В свою очередь, BI позволяет максимально расширить круг пользователей, которые без специализированных ИТ-навыков могут формировать и проверять гипотезы, основанные на данных, а также разрабатывать и делиться оперативной отчётностью, которая автоматически обновляется при изменении данных в хранилище или песочницах.
Таким образом, это современный способ организации доступа к данным и их визуализации. Правильное использование всех перечисленных компонентов на основе хранилища данных и позволяет нам органично сочетать Data Governance и Data Democracy — устойчивость и гибкость.
Витрины данных: надёжно, долго и дорого
В самом же хранилище данных есть два слоя, к которым пользователи обычно получают доступ. Это сырые или оперативные данные, которые являются копиями данных, хранящихся в системах-источниках. А в другом слое находятся специализированные витрины. Они готовятся на основе бизнес-требований и являются квинтэссенцией концепции Data Governance.
Я часто слышу о том, что тщательно задокументированные и находящиеся на сопровождении витрины — это долго и дорого. Признаю, что это отчасти верно. Но в жизни есть вещи, которые не могут стоить дёшево и за которые мы готовы платить: к примеру, бизнес-задачи, требующие особого подхода к процессу подготовки данных. В таких случаях требования к качеству данных или регламенту их сборки оправдывают временные и финансовые затраты на создание таких специализированных витрин.
В первую очередь, речь идет об отчётности, будь то пруденциальная (которая особенно важна для банков), налоговая или управленческая — цена ошибок в таких кейсах слишком велика. Второй момент — жёсткие требования не только к качеству, но и к регламенту формирования наборов данных. Например, если речь идет о данных для маркетинговых кампаний и формирования предложений клиентам, либо мы говорим о формировании данных, на которых строятся ежедневные стратегии действий по взысканиям проблемной задолженности.
В Уралсибе данные по таким витринам за предыдущий день должны быть готовы к 8:00, при этом часть данных захватывается только после завершения процедуры закрытия предыдущего операционного дня. Без хранилища данных миссия становится невыполнимой, учитывая десятки миллионов счетов, сотни миллионов транзакций, а также то, что часть показателей необходимо рассчитать накопительным итогом или в виде усреднённых за период величин.
Как мы организовали слой оперативных данных
Формализованная отчётность — это наследие эпохи, предшествующей цифровой трансформации. А в нынешних условиях ключ к успеху — это скорость изменений и ранее упомянутая демократизация данных. В то же время витрины дорабатываются и меняются относительно медленно.
Как в таком случае хранилище данных может поддерживать постоянно меняющиеся потребности в ad hoc анализе, оперативных и гибких отчётностях по продажам, а также расширяющихся наборах данных для предиктивной аналитики? Здесь поможет правильная идеология организации слоя оперативных данных, представляющих по сути snapshot состояния систем источников.
Некоторые хранилища данных развиваются в парадигме, когда в слой оперативных данных загружаются только те данные, которые необходимы для загрузки в детальный слой или в витрины. Мы же изначально зафиксировали концепцию, согласно которой каждый день в слой оперативных данных загружаются не выборочные атрибуты, необходимые для построения витрин, а вся таблица целиком. Это первый столп, на котором базируется построение оперативного слоя хранилища данных в Уралсибе.
Второй элемент фундамента: спецификации для всех загружаемых таблиц. Они на языке бизнеса описывают виды данных, которые должны содержаться в загружаемой таблице. Это позволяет всем пользователям быстро разобраться, где лежат нужные им данные, существующие в системах-источниках, и тут же начать их использовать.
По сути, слой оперативных данных становится неким «озером» для внутренних систем источников организации. Обращаться в ИТ или в подразделение управления данными в таком случае не нужно. И ещё одна наша фишка — еженедельный релиз-процесс.
Так что же лучше: DWH или DataLake?
Всё написанное выше отражает наш опыт и убеждение в том, что начинать работу с построения хранилища данных нужно как финансовой, так и любой другой организации, для которой работа с данными — ключевой аспект развития и успешности в конкурентной борьбе. Это основа, то есть, образно говоря, базовый навык ходьбы.
Впрочем, неправильно будет утверждать, что Data Lake — это ошибочный путь развития. Противопоставление DWH и Data Lake в принципе не совсем правильно. Это не исключающие друг друга решения. Напротив, они способны отлично дополнять друг друга.
Если мы говорим про NoSQL-данные или модели машинного обучения, где оптимальное решение может быть выработано на основе факторов, которые мы не всегда сможем отследить и понять, то Data Lake — это правильный и оптимальный по стоимости инструмент.
Но перед тем, как начать бегать (в нашем случае это переход на машинное обучение и «озёра данных»), важно сначала научиться ходить: использовать внутренние данные организации, DWH и BI. И конечно же, следует ориентироваться на потребности бизнеса и монетизацию данных.
Озеро, хранилище и витрина данных
Рассмотрим три типа облачных хранилищ данных, их различия и области применения.
Озеро данных
Озеро данных (data lake) — это большой репозиторий необработанных исходных данных, как неструктурированных, так и частично структурированных. Данные собираются из различных источников и просто хранятся. Они не модифицируются под определенную цель и не преобразуются в какой-либо формат. Для анализа этих данных требуется длительная предварительная подготовка, очистка и форматирование для придания им однородности. Озера данных — отличные ресурсы для городских администраций и прочих организаций, которые хранят информацию, связанную с перебоями в работе инфраструктуры, дорожным движением, преступностью или демографией. Данные можно использовать в дальнейшем для внесения изменений в бюджет или пересмотра ресурсов, выделенных коммунальным или экстренным службам.
Хранилище данных
Хранилище данных (data warehouse) представляет собой данные, агрегированные из разных источников в единый центральный репозиторий, который унифицирует их по качеству и формату. Специалисты по работе с данными могут использовать данные из хранилища в таких сферах, как data mining, искусственный интеллект (ИИ), машинное обучение и, конечно, в бизнес-аналитике. Хранилища данных можно использовать в больших городах для сбора информации об электронных транзакциях, поступающей от различных департаментов, включая данные о штрафах за превышение скорости, уплате акцизов и т. д. Хранилища также могут использовать разработчики для сбора терабайтов данных, генерируемых автомобильными датчиками. Это поможет им принимать правильные решения при разработке технологий для автономного вождения.
Витрина данных
Витрина данных (data mart) — это хранилище данных, предназначенное для определенного круга пользователей в компании или ее подразделении. Витрина данных может использоваться отделом маркетинга производственной компании для определения целевой аудитории при разработке маркетинговых планов. Также производственный отдел может применять ее для анализа производительности и количества ошибок, чтобы создать условия для непрерывного совершенствования процессов. Наборы данных в витрине данных часто используются в режиме реального времени для аналитики и получения практических результатов.
Озеро, хранилище и витрина данных: ключевые различия
Все упомянутые репозитории используются для хранения данных, но между ними есть существенные различия. Например, хранилище и озеро данных — крупные репозитории, однако озеро обычно более рентабельно с точки зрения затрат на внедрение и обслуживание, поскольку в нем по большей части хранятся неструктурированные данные.
За последние несколько лет архитектура озер данных эволюционировала, и теперь способна поддерживать бо́льшие объемы данных и облачные вычисления. Большие объемы данных поступают от разных источников в централизованный репозиторий.
Хранилище данных можно организовать одним из трех способов:
Витрина данных содержит небольшой по сравнению с хранилищем и озером объем данных, которые разбиты на категории для применения конкретной группой людей или подразделением компании. Витрина данных может быть представлена в виде различных схем (звезды, снежинки или свода), которые определяются логической структурой данных. Формат свода данных (data vault) является самым гибким, универсальным и масштабируемым.
Существует три типа витрин данных:
IBM предлагает различные решения для облачного хранения и интеллектуального анализа данных.
Data Lake – от теории к практике. Методы интеграции данных Hadoop и корпоративного DWH
В этой статье я хочу рассказать про важную задачу, о которой нужно думать и нужно уметь решать, если в аналитической платформе для работы с данными появляется такой важный компонент как Hadoop — задача интеграции данных Hadoop и данных корпоративного DWH. В Data Lake в Тинькофф Банке мы научились эффективно решать эту задачу и дальше в статье я расскажу, как мы это сделали.
Данная статья является продолжением цикла статей про Data Lake в Тинькофф Банке (предыдущая статья Data Lake – от теории к практике. Сказ про то, как мы строим ETL на Hadoop).
Задача
Лирическое отступление. Выше на рисунке изображено живописное озера, а точнее система озер – одно поменьше, другое побольше. То, что поменьше, красивое такое, облагороженное, с яхтами – это корпоративное DWH. А то, что виднеется на горизонте и не помещается на картинке в силу своих размеров – это Hadoop. Лирическое отступление окончено, к делу.
Задача у нас была достаточно тривиальная с точки зрения требований, и нетривиальная с точки зрения выбора технологии и реализации. Нам надо было прорыть канал между этими двумя озерами, наладить простой и эффективный способ публикации данных из Hadoop в DWH и обратно в рамках регламентных процессов, проистекающих в Data Lake.
Выбор технологии
Далее расскажу про преимущества и недостатки каждого из них.
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.
Разработчику остается добавить этот трансформ в job (задание) и указать названия входной и выходной таблиц.
Разработка такого процесса занимает около 15 минут.
По аналогии был реализован трансформ для публикации данных из Greenplum в Hadoop.
ВАЖНО. Ещё один из бенефитов который мы получили решив эту задачу, мы потенциально готовы организовывать процесс offload-а данных из корпоративного DWH в более дешевый Hadoop.