[spoiler]Наиболее рьяные поклонники Hadoop не без оснований отмечают, что сегодня эта платформа «перемалывания» данных просто идеальное решение для ETL -- доступные ETL-решения с учетом требуемой для них инфраструктуры, заметно проигрывают Hadoop и по способностям масштабирования, и по цене. То есть пользователям потенциально доступна новая свободная платформа с отличными ТТХ. И это хорошо.
Но начнем с плохого:)
Данные все равно требуется как минимум «извлекать» из исходных источников, а потом грузить в 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» есть также и явные плюсы (далее), которые в ряде проектов могут перевесить упомянутые минусы.
