Tel: +380677640202
Email: ceo@cubodrom.com

Address: 65000 Odessa, Ukraine ln. Botanicheskiy 6, office 34

  • LinkedIn Basic Black
  • Facebook Basic Black
Поиск

Hadoop для Data Like

Технологии внедрения Озер Данных.

Что такое Data Lake мы уже обсудили ранее, и если переходить от теории к практике, то достаточно логичен вопрос – какие из технологий современного “big data” мира можно наиболее эффективно использовать под эту задачу? Прежде всего давайте вспомним основные отличия Data Lake от Staging area:

  • Озеро источник данных для разных потребителей (sandboxes, аналитика, отчеты, MDM-приложения и т.д.);

  • В Озере Данных хранятся в том числе и неструктурированные данные – изображения, аудио, видео, текст;

  • Озеро Данных должно быть достаточно дешевым в части хранения данных.


HDFS


Именно последний пункт подводит нас к причине, по которой Hadoop или, точнее, HDFS – может быть не очень удачным решением для реализации Озера Данных. Просто-напросто это может быть слишком дорого, коэффициент репликации в hdfs – это плата за надежность хранения и «широкую полосу пропускания» на чтение. А учитывая стандартное значение этого коэффициента равное 3, мы получаем примерно след. зависимость – для хранения 1Gb информации необходимо 3Gb суммарного physical storage. И если уж быть совсем точным, то этот коэф. в реальности несколько больше – учитывая доп. накладные расходы (каждая нода – это отдельный linux и только “user space” это hdfs блоки, т.е. локальные файлы, а кроме того, NameNode тоже где-то должна хранить свои метаданные). С другой стороны, памятуя о возможности хранения данных в сжатом виде (например SequenceFile формат), реальный коэффициент утилизации data storage может быть значительно меньше чем коэф. репликации.

MapReduce


Кроме хранения данных, Hadoop — это еще и вычислительные мощности. MapReduce, как средство выполнения ETL процессов, достаточно хорошо себя зарекомендовало как с точки зрения производительности так и в контексте широты масштабирования. И это является следствием того факта, что большинство ETL’ей могут быть хорошо распараллелены как в принципе, так и в рамках «физической» реализации паттерна map-shuffle-reduce. Но, к сожалению, так часто необходимые и уже очень давно привычные по реляционным базам данных задачи объединения двух и более datasets - Mapeduce’ом реализуются достаточно топорно и не без ограничений. Distributed Cache join – хорош, но только если одна из таблиц (правильнее - одни из hdfs файлов) сравнительно мал; Reduce Side join – может выполнять not equal join только с одним «финальным» Reduser’ом; а Map Side join – это вообще «костыль», который, честно говоря, использует MapReduce очень опосредованно. Именно по этой причине в Hive реализованы сложные типы данных (array, map, struct, uniontype), призванные снизить потребность в join’ах. И да, файлы сложной структуры (json, xml, etc) так же правильно мапить в complex datatypes, но подобный вариант утилизации этого функционала востребован далеко не всегда.


Hadoop for BI


В списке отличий Озера от Staging Area было упомянуто «аналитика и отчеты» - и это еще один weak point Hadoop’а как системы, использующей под капотом MapReduce engine. Дело в том, что этот «двигатель» требует достаточно долгого времени разогрева перед тем, как поехать (т.е. начать процессировать данные). Детальное рассмотрение причин невозможности использования MR для BI будет вынесено в отдельную публикацию, главное уяснить внешние признаки этих недостатков – у пользователей нет желания ждать формирования даже самых простых отчетов несколько минут. Именно по этой причине существуют решения, на первый взгляд выглядящие как казус нежели шаг в светлое бедующее:

  • использование гибридных Big Data – RDBMS архитектур (само Озеро для хранения и трансформации данных – это Hadoop, а аналитическая часть + отчеты – это Data Marts созданные на отдельно стоящей реляционной БД);

  • использование таких big data решений как Impala или Tez (первое – это замена MR абсолютно другим MPP engine; второе – это глубокая модернизация самого MR);

  • использование NoSQL engines вместо Hadoop (cassandra или mongodb + some custom app, в таком случае ad-hoc reporting практически не возможен, зато заранее предусмотренные отчеты и аналитика работают даже очень шустро).

Выводы


  • Hadoop в части HDFS очень неплох для Data Lake;

  • Hadoop в части MapReduce (лучше заменить на Hive) - sufficiently good для ETL;

  • MapReduce не стоит использвать для BI задач;

  • MapReduce может быть заменен на альтернативы (Impala, Tez, NoSQL), но возникают свои negative side effects;

  • Spark – не единственная, но очень неплохая альтернатива Hadoop’у для реализации Data Lake.

Возможно, звучит резко и кажется необоснованным, зато подтверждается практикой. На этом все, see you soon, TBD…