Комментарии 10
> но несколько лет назад они заменили MapReduce реализацией BigTable

Меня терзают смутные сомненья… Аналог BigTable в экосистеме Hadoop это HBase. HBase и MapReduce прекрасно в этой экосистеме сосуществуют: HBase — для random read, MapReduce — для batch. Другими словами, BigTable и MapReduce — это сравнение теплого с мягким.
Это сейчас выглядит как теплое с мягким, когда экосистема разбилась на файловую систему HDFS и парадигму MapReduce. А тогда в 2006 году Google именно что замещал универсальное решение, которым до этого казался mapreduce (GFS в основе, ключи-значения в SSTable как структуре данных, MapReduce как парадигма обработки массивов данных) на другое, более близкое им решение с большой таблицой, хранящей уже строки-колонки-время (в основе которой были все те же самые GFS & SSTable). Решение получалось менее низкоуровневым, и более близким к поисковому бизнесу и задачами решаемыми их фермой машин.
Вся остальная индустрия пройдет этот самый путь с большой задержкой и с другими акцентами. Это сейчас, да, есть HBase как аналог BigTable и звучит странным менять MapReduce на BigTable. Но если, перенеся это в экосистему Hadoop, прочесть это как замена более раннего Hadoop (==MapReduce) на более позднее, компонентизированное, специализированное решение, то все вроде становится логичным.

[И, кстати, Майкл про такое расщепление понятия Hadoop на подпонятия написал.]
Эээ… ерунда какая-то однако. MapReduce — система обработки данных. Bigtable, Spanner/F1 — хранения. MR прекрасно работает со Spanner'ом.

upd: уже выше написали. Надо читать комменты :-)
Так смысл Spanner не в хранении, а в доступе к данным. Если у вас 100ПБ данных, то вы точно не хотите запускать MR job для извлечения 0.1% нужных данных. То есть слабость концепции MR в том, что скорость доступа пропорциональна количеству сохранённых данных, а не количеству извлекаемых, что мы видим в классических СУБД (я тут слегка утрирую, конечно, но в случае простых запросов это так).
Полезный перевод, спасибо. Стоунбрейкер давно критикует Hadoop. Наверное, с 2009г со статьи в SIGMOD 2009 (тут есть ссылка database.cs.brown.edu/projects/mapreduce-vs-dbms). И судя по этим более поздним статьям суть его претензий не меняется, Hadoop — это универсальный, но достаточно неэффективный инструмент для тех задач, которые им чаще всего пытаются решать, если сравнивать со специализированными инструментами. А попытка сделать его эффективным приводит к тому, что от Hadoop почти ничего не остается. Что не отменяет того, что есть задачи, когда Hadoop оправдан, тот же неструктурированный поиск.

Кстати, довольно странно, что он пишет об Impala, но не упоминает о Stinger.
А как hadoop применим в поиске? Фильтрация с помощью MR — стандартная операция, но это очень узкоспециализированный вариант поиска. В голову приходит сборка lucene'овских индексов мапредом, но к поиску в этом случае hadoop отношения фактически не имеет.
Операция MR принципиально оффлайновая. Второй её минус — отсутствие итеративности, каждый раз нужно лопатить все данные.
Если говорить конкретно про поиск, то с помощью MR можно собрать из документов обратные индексы, которые уже подкладывать под специальные демоны, работающие в реалтайме (возможно, эту конструкцию получится соорудить на стеке Hadoop, тут я не знаток). Получится классический гугл 10-летней давности, то есть на самом деле крутой поиск :).
В этом сценарии Hadoop превращается в стандартную СУБД с архитектурой shared-nothing

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