НовостиСобытияКонференцииФорумыIT@Work
Идеи и практики автоматизации:

Блог

Hadoop как ETL-killer

Сергей Бобровский
22.01.2014 14:38:23

ETL-процессинг -- одна из ключевых концепций хранилищ данных, подразумевающая сбор, обработку и загрузку (Extract, Transform, Load) информации из различных источников. Зародившись практически одновременно с СУБД как узкоспециализированная технология, она постепенно доросла до масштабных интеграционных задач. Коммерческие ETL-продукты выпускают IBM, Microsoft, Oracle, SAP, SAS... Есть и мощные СПО, например, Pentaho.

Наиболее рьяные поклонники Hadoop не без оснований отмечают, что сегодня эта платформа «перемалывания» данных просто идеальное решение для ETL -- доступные ETL-решения с учетом требуемой для них инфраструктуры, заметно проигрывают Hadoop и по способностям масштабирования, и по цене. То есть пользователям потенциально доступна новая свободная платформа с отличными ТТХ. И это хорошо.
Но начнем с плохогоsmile:)

Данные все равно требуется как минимум «извлекать» из исходных источников, а потом грузить в Hadoop. Да и мощь Hadoop в плане обработки информации не снимает проблем с качеством/верификацией данных, а средства управления ETL-процессом в рамках Hadoop, мягко говоря, очень аскетичны.

Формально, в модели MapReduce можно без проблем написать ETL-скрипты, только они будут работать куда медленнее, нежели «фирменные» средства. Другое дело, что Hadoop начинает менять классическую схему ETL -- скоростное извлечение данных из источника с минимальным влиянием на него, перевод этих данных в подходящий формат, и загрузку их в некое условное (возможно, виртуальное) хранилище с учётом его технических ограничений. Все эти операции должны быть прозрачными-измеряемыми и защищёнными.

Есть мнение, что Hadoop пока может отвечать фактически только за Transform, и очень частично за Load (в HDFS/HBase). Сегодня его довольно бессистемно прикручивают буковкой «T» к действующим инфраструктурам примерно по такой гибридной схеме: данные поступают извне в Hadoop, где перемалываются и затем «выгружаются» -- например, в его же файловую систему, а уже оттуда цепляются внешними движками бизнес-аналитики.

Вот еще типичный use case: исходная информация уже хранится в Hadoop (например, сырые данные от датчиков грузятся напрямую в HDFS в виде двоичных файлов), а выход из Hadoop оптимизирован под форматы BI-движков (фактически в Hadoop осуществляется свой внутренний цикл ETL). Вариант: исходные данные помещаются «внутрь» Hadoop из каких-то промежуточных баз или хранилищ. Недостаток встраивания цикла ETL внутрь Hadoop в основном связан с высокими требованиями ETL к ресурсам, которых обычно самому Hadoop маловато. Поэтому пока Hadoop чаще всего расценивается как некий вторичный ускоритель для ETL.

Но у подхода «Hadoop + ETL» есть также и явные плюсы (далее), которые в ряде проектов могут перевесить упомянутые минусы.

Комментариев: 11

Только зарегистрированные и авторизованные пользователи могут добавлять комментарии

22.01.2014 20:13:21

"Большие данные" как состояние отрасли
http://arbinada.com/main/node/1351
smile;)

23.01.2014 15:32:21

Похоже, что терабайтов уже действительно достаточно для "текстовых" организационных задач, любых учёток. Но теперь приходит очередь петабайтных объёмов от всяческих АСУ ТП, телеметрии с датчиками, которые детальную инфу собирают в реалтайме, итд.

23.01.2014 16:01:50

По идее АСУ ТП как раз заточены на оперативное реагирование и выполнение плановых задач, там анализ больших данных даже не знаю куда можно прикрутить.

Если задачи типа "следить за перемещениями людей в телефонной сети", то это давно успешно делалось. Можно уменьшить дискретность интервалов, но тогда мгновенно просядет сеть. Да и данные старее 5 лет нельзя хранить по закону.

В общем, применения видятся очень ограниченные, связанны прежде всего с глобальными службами и научными исследованиями. Где все это уже было и просто продолжает развиваться.

24.01.2014 11:47:01

А мне применения видятся максимально широкие, связанные напрямую с производством и промышленностью. Например, Shell устанавливает на свои нефтяные вышки новую систему мониторинга с датчиками HP, которые после запуска на тестовой вышке уже сгенерили петабайт данных. У Шелла 10 тыс. так вышек, они им за неделю нагеренят экзабайты -- больше объёма всея Сети smile:)

24.01.2014 12:18:36

Нагенерировать данные - не проблема.
Проблема "нагенерировать" осмысленные данные.
Броуновское движение в капле воды нагенерит тебе экзабайты за несколько минут если выбрать соответствующую дискретность. Потом из полученных экзабайтов можно выводить астрологические законы природы.

24.01.2014 12:37:07

Не думаю, что в HP и Shell инженеры глупее нас, и не понимают этих очевидных моментов.

24.01.2014 12:38:43

Я не уверен что решения принимают инженеры.
Они бы в первую очередь написали, какого характера будет сбираться информация и с какими целями.

24.01.2014 14:05:42

Оценивать нужно по реальным результатам, а не по генерации байтов.

24.01.2014 14:12:59

С результатами проблема. Я несколько раз спрашивал пропагандистов бигдаты (не имею в виду Сергея Б.) о примерах проектов и их рентабельности, но в ответ не получил ничего конкретного... Потоком идет обычный "маркетинговый буллшит", за которым трудно увидеть действительные выгоды.

24.01.2014 14:52:52

Я уже давно понял для себя, что Big Data - это чистой воды "мыльный пузырь".

24.01.2014 14:03:51

+1! Согласен!

Только зарегистрированные и авторизованные пользователи могут добавлять комментарии