Почему Hadoop не является хранилищем данных?

971
Dennis Jaheruddin

Каковы функциональные причины, по которым Hadoop не может быть хранилищем данных

На нескольких сайтах можно увидеть заявления о том, что кластер Hadoop не является заменой традиционного хранилища данных. Однако я не могу найти реальные причины, почему.

Я знаю, что технически есть некоторые вещи, которые недоступны / не доступны в Hadoop, но я действительно ищу функциональное влияние.

Что я нашел до сих пор, включая смягчение

Я нашел несколько аргументов, но ни один из них не настолько критичен, чтобы я не советовал использовать Hadoop в качестве DWH. Вот выбор:

  1. Вы не можете выполнять быстрые специальные запросы или отчеты, так как Hadoop имеет тенденцию накладывать накладные расходы на карту и сокращать количество рабочих мест.

Тем не менее, в ситуации, которую я рассматриваю, это не должно быть проблемой, поскольку данные доступны только через (обычный) datamart. Кроме того, вы могли бы использовать spark sql, если вы хотите копаться в некоторых таблицах.

  1. Вы не можете получить определенные результаты, так как Hadoop не поддерживает хранимые процедуры.

В ситуации, которую я рассматриваю, не так много хранимых процедур (к счастью!), И с помощью таких инструментов, как R или Python, вы действительно можете получить любой нужный вам результат.

  1. Вы не можете оправиться от бедствий, так как Hadoop не имеет встроенных резервных копий

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

  1. Вы не можете обеспечить соблюдение и конфиденциальность, так как нет безопасности и происхождения данных

С таким инструментарием, как Knox + Ranger + Atlas, этого можно достичь.

  1. Нелегко создавать запросы, так как вы не можете построить поток, но вам нужно написать SQL или PIG-код.

Похоже, есть несколько инструментов, таких как Talend, где вы можете создавать потоки с помощью значков, как в обычных построителях запросов.

  1. Hadoop поддерживать сложнее, так как требует определенных знаний

Да, но в ситуации, на которую я смотрю, есть немало знаний, поскольку в настоящее время они используют аналитическую платформу Hadoop.

3
Я думаю, что оба существующих ответа хороши, я решил принять один и дать щедрость другому. Dennis Jaheruddin 7 лет назад 0

4 ответа на вопрос

3
Luca Natali

Это правда, с помощью Hadoop и некоторых трюков вы можете делать то же самое, что и DWH.

Однако не имеет смысла заново изобретать колесо, чтобы Hadoop выполнял те же самые функции хранилища данных неэффективным способом. Многие могут сказать, что Hadoop дешевле, чем хранилище данных, с точки зрения аппаратного и программного обеспечения: это правда, есть большая разница, но мы должны учитывать время, затрачиваемое на внедрение такой системы, ноу-хау и необходимые навыки, обслуживание кластера, модернизация сервисов и риск использования незрелых инструментов или инструментов, от которых в будущем можно было бы отказаться.

Реальный аспект выбора между Hadoop и хранилищем данных:

  • Тип рабочих нагрузок (чтение против записи, тактика против отчета и т. Д.)
  • Тип данных (структурированные или неструктурированные)
  • Интеграция данных (схема при чтении или схема при записи)
  • Запрос SLA (время выполнения, параллелизм и т. Д.)
  • Требуемые навыки (количество ресурсов и ноу-хау, необходимых для реализации)
  • Соответствие SQL (интеграция с инструментами)
  • Оптимизация (управление рабочей нагрузкой, индексы, хэш-карты и т. Д.)
  • Зрелость (безопасность, ошибка и т. Д.)
  • Тип анализа (анализ SQL или не SQL)

Гибридная архитектура, созданная в обоих случаях, подходит для многих случаев использования. Я могу сэкономить ресурсы (ЦП, хранилище) из хранилища данных, выгружая исторические данные и обработку ETL в Hadoop, я могу выполнять анализ неструктурированных данных, и в то же время я могу иметь более высокую производительность, интеграцию данных и высокую степень параллелизма, запрашивая «горячие» данные. "данные, хранящиеся в хранилище данных.

Ответ на комментарий:

В зависимости от того, что вы хотите сделать с Hadoop, вы можете заполнить хранилище данных напрямую, поместив необработанные данные в hadoop и выполнить ETL для него, чтобы взимать с хранилища.

Существует много вариантов использования, связанных с интеграцией Hadoop с хранилищем данных, например:

  • Озеро данных: все необработанные данные, хранящиеся в Hadoop. Это может дать вам место, где вы можете собирать, уточнять и исследовать исходные необработанные данные и метаданные и, возможно, выполнять агрегирование или ETL для заполнения модели данных в хранилище данных.
  • Историзация: вы можете разработать сценарии для разгрузки холодных данных в Hadoop (например, прошлогодние транзакции на DWH и старые транзакции на Hadoop). Вы можете получить доступ к обоим данным через федератор запросов (например, Presto), который может дать вам возможность объединить данные, которые находятся на разных платформах (т.е. сделать UNION ALL между исторической частью таблицы в Hadoop и недавней частью в данных склад)

Если вы хотите использовать Hadoop в качестве озера данных, поток данных будет следующим: источник -> HDFS (очистка) -> хранилище данных

Если вы используете Hadoop только для историзации: источник -> хранилище данных -> HDFS

Федераторы запросов, такие как Presto, открывают множество вариантов использования и дают возможность использовать данные из разных систем в одном запросе. Это открывает возможность иметь холодные данные в Hadoop и горячие данные в хранилище данных ИЛИ возможность иметь «базовые» данные в хранилище данных, а остальные - в Hadoop.

Очень полезный ответ, я все же оставлю вопрос открытым, чтобы посмотреть, последуют ли еще, но у вас уже есть мой голос. Одна вещь, которая заставила меня задуматься, это гибрид, о котором ты упоминаешь. В моей нынешней ситуации мне приходится работать с огромными / неструктурированными источниками данных, поэтому Hadoop кажется обязательным. Но я также признаю, что на обычных решениях все проще / надежнее. Итак, не могли бы вы описать вашу гибридную архитектуру / поток, поскольку все тривиальные формы кажутся очень неэффективными? (1. Вы загружаете данные дважды из источника ИЛИ сначала загрузить его в A, а затем из A в B || 2. У вас есть 2 инструмента для создания потоков данных и т. д.) Dennis Jaheruddin 7 лет назад 0
Одним из наиболее важных и сложных аспектов для рассмотрения в сценарии с озером данных является управление данными. У вас есть все ваши необработанные данные о Hadoop, и ими нужно управлять. Luca Natali 7 лет назад 0
3
harrymc

Кластер Hadoop ни в коем случае не является заменой традиционного хранилища данных. Голый Hadoop делает только две вещи:

  1. Распределенное хранилище и ресурсы
  2. Уменьшение карты

На вершине Hadoop построена целая экосистема программных пакетов, в частности, Pig, Hive, HBase, Phoenix, Spark, ZooKeeper, Cloudera Impala, Flume, Sqoop, Oozie, Storm.

Сегодня вы можете выбрать то, что вы хотите из множества продуктов.

Хотите использовать SQL? Взгляните на следующие серверы виртуализации данных: Cirro Data Hub, Cisco / Composite Information Server, платформа Denodo, Informatica Data Services, Red Hat JBoss Data Virtualization и Stone Bond Enterprise Enabler Virtuoso.

Хотите, чтобы продукт сохранял данные в собственной базе данных SQL или в Hadoop? Примерами являются EMC / Greenplum UAP, HP Vertica (на MapR), Microsoft PolyBase, Actian ParAccel и база данных Teradata Aster (через SQL-H).

Добавьте к этим:

  • Apache Hive - оригинальный SQL-на-Hadoop
  • Стингер Хортонворкс
  • Apache Drill - открытая реализация Google Dremel (он же BigQuery)
  • Spark SQL - параллельная обработка в реальном времени, в памяти
  • Apache Phoenix - «SQL-скин для HBase»
  • Cloudera Impala - еще одна реализация Dremel / Apache Drill
  • HAWQ для Pivotal HD - параллельная обработка SQL и высокое соответствие стандартам SQL в собственном дистрибутиве Hadoop Pivotal
  • Presto - Создан инженерами Facebook и используется внутри компании
  • Oracle Big Data SQL - интегрируется только с Oracle Database 12c
  • IBM BigSQL - привязан к Hadoop от IBM и InfoSphere BigInsights

Вывод: какими бы ни были ваши требования к хранилищу базы данных, вы можете найти какой-то продукт на Hadoop или комбинацию продуктов, которая делает то, что вы хотите.

Недостаток: поиск вашего идеального продукта (ов), изучение того, как управлять ими и каковы их недостатки, разработка приложения распределенной базы данных, сообщение об ошибках и стремление к улучшениям - все это займет ужасное количество времени с вашей стороны. Вы ищете функциональное влияние - поэтому обратите внимание на влияние на вас и ваше время, особенно если в вашей команде нет специалиста Hadoop.

Окончательный вывод: Hadoop - это не хранилище данных, а приложения, построенные на нем, и все возможные варианты учитываются. Но удачи в навигации в этих джунглях. Если ваши потребности достаточно скромны, я бы предложил создать ваше собственное приложение, построенное на MapReduce, или перейти на более классическое решение с использованием известных вам инструментов. Знайте также, что MapReduce не подходит для всех проблем.

Еще немного чтения:

Очень хороший обзор решений SQL! Я понимаю, что hadoop без продуктов - это «ничто», и что существует несколько способов «общаться» с базами данных. Однако мне интересно, будет ли также система баз данных, которая выходит за рамки улья (внешние ключи, уникальность) и по-прежнему может быть подключена в общем Hadoop (например, Hortonworks). Dennis Jaheruddin 7 лет назад 0
Механизмы баз данных, которые подключаются к Hadoop MapReduce, безусловно, делают это - Oracle и IBM. Вам понадобится продукт, который индексирует данные, а не только сканирует их. Джетро, ​​кажется, делает это, но я не проанализировал все продукты, перечисленные выше. harrymc 7 лет назад 0
Вы также можете посмотреть на кластерные базы данных, отличные от Hadoop. Например, [VoldDB] (https://www.voltdb.com/) - это совершенно другая концепция. harrymc 7 лет назад 0
1
Adir Akerman

Hadoop - это один из нескольких вариантов перечисленных вами ситуаций. Похоже, вы ищете одну систему / federator / datapipe, из которой вы можете выполнять специальные запросы к нескольким источникам данных. Другими опциями для функций Hadoop являются Spark, Pentaho, Apache Pig, Hortonworks.

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

A. У вас есть несколько источников данных

B. Вы хотите запускать специальные запросы

C. Вам необходимо управлять этими несколькими источниками данных с точки зрения их доступности и «запросов» для ваших аналитиков / конечных пользователей. И вы (думая здесь с точки зрения ИТ) должны иметь возможность управлять этим, не превращаясь во вторую работу.

D. Я предполагаю, что со временем вы добавите больше источников данных.

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

F, вы хотите аварийного восстановления и безопасности / соответствия.

G. Вы хотели бы использовать различные методы запросов, включая хранимые процедуры.

Посмотрев сначала, определите, какие инструменты удовлетворяют этим потребностям. Существуют IPaaS (Integration Platform as a Service - в основном, интеграция данных в облаке), такие как Mulesoft и SnapLogic. У вас есть Hadoop и его двоюродные братья, я говорю двоюродные братья, потому что в этом пространстве у продуктов, как правило, достаточно различий, и я не могу их объединить, как базы данных SQL. У вас есть озера данных, которые используют необработанные данные и, таким образом, облегчают необходимость интенсивной работы по преобразованию. И у вас есть обработка потока данных, которая обрабатывает несколько потоков данных и фильтрует данные, а не отбрасывает их.

Посмотрите на потребности вашего бизнеса (включая бюджет и ресурсы), сравните это с тем, что доступно, а затем определите лучший инструмент для вашей компании. Если вам нужны ресурсы по ETL и интеграции данных, есть сайт ETLTools.net, на котором есть много информации, включая описания различных типов сред.

0
Vamsikrishna YVS

Hadoop - это фреймворк, а хранилище данных - это программное обеспечение ... В замешательстве? Хранилище данных будет просто координировать между данными и вами. Он будет просто заниматься хранением и поддержанием жизненного цикла данных. Где, как Hadoop, в дополнение к координации между данными и вами он выполняет простые / сложные операции с данными, если вы попросите это сделать.

Причина, по которой hadoop не может лучше подходить для хранилища данных, состоит в том, что есть несколько других инструментов для выполнения той же эффективной задачи, что и hadoop.

Похожие вопросы