Майкл Стоунбрейкер — Hadoop на распутье

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

[И, кстати, Майкл про такое расщепление понятия Hadoop на подпонятия написал.]

Так смысл Spanner не в хранении, а в доступе к данным. Если у вас 100ПБ данных, то вы точно не хотите запускать MR job для извлечения 0.1% нужных данных. То есть слабость концепции MR в том, что скорость доступа пропорциональна количеству сохранённых данных, а не количеству извлекаемых, что мы видим в классических СУБД (я тут слегка утрирую, конечно, но в случае простых запросов это так).

Поправил, спасибо!

А как hadoop применим в поиске? Фильтрация с помощью MR — стандартная операция, но это очень узкоспециализированный вариант поиска. В голову приходит сборка lucene'овских индексов мапредом, но к поиску в этом случае hadoop отношения фактически не имеет.