Источник Hadoop MR: HDFS против HBase. Преимущества каждого?

Question

Если я правильно понимаю экосистему Hadoop, я могу запустить мои данные поиска источников MapReduce из HDFS или HBase. Предполагая, что предыдущее предположение верно, почему я должен выбирать один за другим? Есть ли преимущество производительности, надежности, стоимости или простоты использования для использования HBase в качестве источника MR?

Лучшее, что мне удалось найти, это цитата: «HBase - это приложение Hadoop, которое необходимо использовать, когда вам требуется доступ в режиме реального времени для чтения и записи в очень большие массивы данных». - Том Уайт (2009) Hadoop: The Definitive Guide, первое издание

Answer 1

Использование прямой вверх Hadoop Map/Reduce над HDFS, ваши входы и выходы, как правило, хранятся как плоские текстовые файлы или Hadoop SequenceFiles, которые просто сериализованная объекты, передаваемые на диск. Эти хранилища данных более или менее неизменяемы. Это делает Hadoop подходящим для задач пакетной обработки.

HBase - это полноценная база данных (хотя и не реляционная), которая использует HDFS в качестве хранилища. Это означает, что вы можете запускать интерактивные запросы и обновления в вашем наборе данных.

Что хорошего в HBase заключается в том, что он хорошо играет с экосистемой Hadoop, поэтому, если вам нужно выполнять пакетную обработку, а также интерактивные, гранулированные операции на уровне записи на огромных наборах данных, HBase будет хорошо работать.

Answer 2

Некоторые соответствующие ограничения HDFS (который является открытым исходным кодом для файловой системы Google) находятся в the original Google File System paper.

О случаях целевого использования, мы читаем:

В-третьих, большинство файлов мутируют путем добавления новых данных , а не перезаписывать существующие данные. Случайные записи в пределах Файл практически не существует. [...]

[...] Учитывая эту модель доступа на больших файлах, добавление становится центром оптимизации производительности и атомарность гарантий, [...]

В результате :

[...] мы расслабились модель согласованности GFS к значительно упростить файловую систему без наложения обременительной нагрузки на приложениях. Мы также представили операцию атомарного добавления, чтобы несколько клиентов могли добавлять одновременно к файлу без дополнительной синхронизации между .

Запись добавить данные причины («звукозапись»), чтобы быть добавлена ​​атомарно по крайней мере один раз даже в присутствии параллельных мутаций, [...]

Если я прочитал статью правильно, то несколько реплик каждого файла (в смысле HDFS) не обязательно будут точно такими же. Если клиенты используют атомарные операции, каждый файл можно рассматривать как объединение записей (каждый из одной из этих операций), но они могут дублироваться в некоторых репликах, и их порядок может отличаться от реплики к реплике. (Хотя, видимо, также может быть вставлено некоторое дополнение, поэтому оно даже не так чистое - читайте бумагу.) Пользователь должен управлять границами записей, уникальными идентификаторами, контрольными суммами и т. Д.

Так что это совсем не похоже на файловые системы, к которым мы привыкли на наших настольных компьютерах.

Обратите внимание, что HDFS не хорошо для многих маленьких файлов, потому что:

1. Каждый выделит обычно 64 Мб кусок (source).

2. Его архитектура не является хорошим в управлении огромным количеством файлов имена (источник: такой же, как в пункте   1). Существует один мастер, поддерживающий все имена файлов (которые, мы надеемся, вписываются в его ОЗУ).