[@tsafin — Обладателя премии Тьюринга Майкла Стоунбрейкера представлять не надо, он и его студенты из Беркли и MIT создали, по ощущениям, большую часть реляционных и нереляционных баз данных за последние пару десятилетий. Ingres и Postgres, C-Store и Vertica, H-Store и VoltDB – вот лишь малая часть проектов и фирм, на который Майкл и его студенты повлияли напрямую, а ведь еще есть множество форков и деривативов…

Т.о. когда он критикует что-то, будь то NoSQL или Hadoop, то индустрии стоит, как минимум, прислушаться, а лучше попытаться измениться.

Мне показалось интересной его точка зрения на Hadoop, высказанная в статьях 2012 и 2014 года, и было интересно проследить развитие точки зрения «классика» за такой короткий промежуток времени.

Первую статью «Possible Hadoop Trajectories», опубликованную в «Comunications of ACM» http://cacm.acm.org/blogs/blog-cacm/149074-possible-hadoop-trajectories/fulltext, Стоунбрейкер написал в мае 2012 года в соавторстве с Джереми Кепнером (Jeremy Kepner), который в тот момент работал как старший технический персонал в MIT, и как исследователь в MIT Mathematics Department и MIT Computer Science and AI Lab. Эта статья, написанная в соавторстве, кажется более дерзкой и задорной, по сравнению со второй, написанной уже им самим двумя годами позже (да и, чего уж там, первая статья написана IMHO в лучшем стиле), но я публикую их в связке, т.к. контекст за прошедшие пару лет сильно изменился, и было бы нечестно по отношению к экосистеме Hadoop/HDFS оставлять это незамеченным.

По-большому счету критика Hadoop в первой части относится только лишь к реализации API MapReduce, и по прошествии нескольких лет индустрия Hadoop сделала многое, чтобы решить проблемы. Но это, все же, не сильно приблизило её к решению проблем вычислительных приложений HPC, означенных в первой статье.]

Возможные траектории применения Hadoop

Майкл Стоунбрейкер, Джереми Кернер, 2 мая 2012

За последние несколько лет Hadoop стал платформой параллельных вычислений в Java. И как таковой он вполне достиг цели принесения параллельных вычислений в практику миллионов программистов в сообществе Java. Заметим, что все предыдущие попытки сделать это (Java Grandle, JavaHPC) не сильно преуспели, и мы аплодируем Hadoop за тот достигнутый успех, большей частью, в силу простоты и доступности созданного окружения.

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

Давайте подробнее рассмотрим эти два сценария использования.

Научные вычисления на Hadoop

Часто в коде, проводящем научные вычисления, узлы организуются в 2-D (или 3-D или N-D) прямоугольные, партиционированные сетки (гриды). И на каждом узле мы исполняем что-то вроде:

Until конечное-условие {
   Локальные вычисления на партиции локальных данных
   Выдача [измененного] состояния
   Послать/получить данные на/из подмножество других узлов, хранящих другие партиции данных
}

Этот шаблон описывает большинство алгоритмов computational fluid dynamics (CFD) [вычислительная гидродинамика из механики сплошных сред], все атмосферные и океанические симуляционные модели, операции линейной алгебры, операции над разреженными графами, обработку изображений и обработку сигналов. При рассмотрении этого класса проблем в Hadoop мы видим следующие задачи и проблемы, которые хорошо бы разрешить:

Локальные вычисления всегда работают с большим состоянием на каждой итерации. Сохранение состояния между шагами MapReduce требует записи в файловую систему, что часто очень дорого. Также, часто такие алгоритмы требуют прямого взаимодействия между узлами, что не поддерживается инфраструктурой MapReduce. Часто, подобные алгоритмы предполагают привязку кода к одному и тому же узлу грида, но на разных итерациях обсчета алгоритма.

Опять же, такая модель напрямую не поддерживается MapReduce.

Наша оценка, что MapReduce будет работать только для 5% пользователей Lincoln Lab. Остальные 95% должны попытаться впихнуть свои алгоритмы в прокрустово горлышко модели MapReduce, заплатив в результате 1-2 порядка замедления скорости. Мало ученых согласятся на такую цену, может быть только на очень малых наборах.

Многие могут поспорить, что в долговременном плане производительность не имеет значения [@tsafin – WTF?]. Это может быть правдой только для low end [машин], но для массивов данных, которые мы видим как в Lincoln Lab, так и в других исследовательских лабораториях, о которых мы знаем, то здесь производительность очень даже имеет значение, и там никогда не бывает достаточно вычислительных ресурсов. Более того, например, наша организация инвестирует 100 миллионов долларов для того, чтобы разместить суперкомпьютерный центр следующего поколения рядом с дамбой гидроэлектростанции и тем самым уменьшить выбросы углерода на порядок. И потеря производительности, получаемая с внедрением Hadoop — это совершенно неприемлемая дополнительная цена. Даже при меньших объемах, применение таких неэффективных систем как Hadoop будет очень недружественным к экологии шагом и зачастую просто потерей энергии.

Если вкратце то мы наблюдали такие шаги при применении Hadoop в [научной] вычислительной среде:

• Шаг 1. попробовать Hadoop в пилотных проектах;
• Шаг 2. Масштабировать Hadoop для продуктового использования;
• Шаг 3. Упереться в стену в силу означенных выше проблем;
• Шаг 4. Изменить форму решения, чтобы обойти ограничения.

В Lincoln Lab у нас есть проекты в каждом из 4 состояний.

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

Вполне допускаем, что в других конторах смесь актуальных для его пользователей задач может оказаться более совместимой с инфраструктурой MapReduce. Тем не менее, наши ощущения подсказывают нам, что мы больше норма, чем исключение. Движение Google в сторону от MapReduce к другим моделям подтверждают такие подозрения. Посему, мы ожидаем драматические изменения в инфраструктуре Hadoop.

Управление данными в Hadoop

40 лет исследований и применений СУБД в промышленности подтверждают тезис Теда Кодда, высказанного еще в 1970: эффективность программиста и системы в-целом тем больше, чем более высокоуровневые операции манипулирования данными применяются на языке высокого уровня, и [эффективность меньше] если приходится работать на языках, манипулирующих записями в один момент времени. Хотя Hadoop и вполне высокоуровневый, по сравнению с языками «запись-за-раз», но, все равно, легче закодировать запросы к данным используя Hive, а не использовать MapReduce напрямую. Потому, нам представляется возможным движение всех средств управления данными Hadoop в сторону языков более высокого уровня, таким как SQL и SQL-like языки.

Например, согласно отчетам Девида Девитта [1-1], Hadoop кластер в Facebook почти полностью программируется на Hive, языке высокого уровня для доступа к данным, который очень похож на SQL. В Lincoln Lab наблюдается очень похожая траектория движения, хотя и выбираются другие языки высокого уровня (не Hive), которые имеют скорее высокоуровневые, алгебраические интерфейсы для доступа к разреженным данным [1-2, 1-3].

Как таковой, MapReduce кажется становится внутренним интерфейсом [инкапсулированным внутрь] СУБД.
Другими словами, пользователи Hive не сильно переживают что у них внутри запроса на HiveQL, и интерфейс MapReduce становится невидимым и тонет в глубинах внутренностей СУБД. В конце концов, многие ли из вас переживают какой протокол используется при передаче по сети параллельной СУБД для взаимодействия между обработчиками на разных узлах?

Кстати, один из авторов данной статьи создал 5 параллельных СУБД, и, конечно же, вполне ознакомлен с протоколами коммуникации между координатором запроса и несколькими исполнителями на разных узлах. И знает, что узлы исполнителей должны взаимодействовать с остальными для передачи промежуточных данных между собой. В таком сценарии для создания высокопроизводительной системы потребуются следующие характеристики системы:

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

В целом, СУБД обычно требует весь тот же набор условий, что и алгоритмы для научных вычислений упомянутые выше. В итоге получаем MapReduce как внутренний интерфейс в параллельной СУБД, но с интерфейсом не очень хорошо подходящим СУБД.

Один из нас написал в 2009 статью, сравнивающую технологии параллельных СУБД с Hadoop [1-4]. Грубо говоря, СУБД быстрее Hadoop на 1-2 порядка. Это преимущество идет от использования индексов для данных, от посылки запросов только к узлам, где лежат данные (а не наоборот), от преимуществ в компрессии, и лучших протоколов между узлами. Насколько мы можем судить, ситуация в 2012 не сильно изменилась относительно 2009: Hadoop по-прежнему на 1-2 порядка медленнее согласно неформальным оценкам. Например, в одном большом Web проекте был 5-петабайтовый Hadoop кластер, развернутый на 2700 узлах, в другом же, при похожей 5-петабайтовой инсталляции, но управляемой коммерческой СУБД, было всего 200 узлов, что, заметим, в 13 раз меньше.

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

• Шаг 1. Попробовать Hadoop в пилотных проектах.
• Шаг 2. Масштабировать Hadoop для продуктового использования.
• Шаг 3. Получить неприемлемые накладные расходы на производительность.
• Шаг 4. Изменить форму решения, используя параллельную СУБД.

Большинство установок Hadoop находятся сейчас между шагами 2 и 3, и стадия «упереться в стену» будет только следующим шагом. Или Hadoop вырастет в реальную параллельную СУБД за ограниченное количество времени, или пользователи перейдут на другие решения, замещая части Hadoop решения, или с применением интерфейсов к Hadoop, поставляющие в того внешние данные, или каким другим способом. С учетом малого прогресса, наблюдаемого последние 3 года, наши ставки скорее на 2ом решении [переход на другие решения].

И завершая можем сказать: когда-то Gartner Group сформулировал свою широко известную кривую «hype cycle» [1-5] [@tsafin – на русский переводят как «кривая зрелости технологий», sic], которую можно использовать для описания эволюции новых технологий от самого их зарождения. Текущее состояние дел в экосистеме Hadoop скорее предоставляется как «лучшее решение со времен изобретения хлеба с маслом», но мы все же надеемся, что со временем, упомянутые нами ограничения будут сняты, и мы немного приблизимся к обещанному.

Ссылки

• [1-1]  http://searchsqlserver.techtarget.com/news/2240126683/Cloaked-in-secrecy-Microsoft-project-aims-to-wed-SQL-NoSQL-databases
• [1-2] Jeremy Kepner, et. al., «Dynamic Distributed Dimensional Data Model (D4M) Database and Computation System,» ICASSP, March 25-30, 2012
• [1-3] http://accumulo.apache.org
• [1-4] Andy Pavlo, et. al., «A Comparison of Approaches to Large Scale Data Analysis,» Proc. SIGMOD 2009,  Providence, RI, June 2009.
• [1-5]  http://www.gartner.com/technology/research/methodologies/hype-cycle.jsp 

Hadoop на распутье

Майкл Стоунбрейкер, 5 августа 2014

[@tsafin — вторая статья была написана 2 годами позже, в августе 2014 года, и опубликована в том же журнала «Communications of ACM» http://cacm.acm.org/blogs/blog-cacm/177467-hadoop-at-a-crossroads/fulltext]

Много воды утекло со времен нашей предыдущей, совместной с Jeremy Kepner, статьи по данной теме, написанной в 2012 году [2-1]. Я считаю необходимым указать на несколько произошедших фактов и возникших мнений, а также сообщить о паре важных анонсов. В итоге, я завершу статью предсказаниями того, куда стек Hadoop может двигаться в будущем.

Первый анонс, который стоит упомянуть, это выпуск новой СУБД — Cloudera Impala [2-2], которая работает поверх HDFS. Проще говоря, Impala создана, как и все остальные shared-nothing параллельные SQL СУБД [@tsafin – еще не очень понятно каким будет устоявшийся перевод термина SN, предлагаем остановиться на версии Сергея Кузнецова «архитектура без совместно используемых ресурсов»], и нацелена на обслуживание рынка хранилищ данных. Особенно обращает на себя внимание тот факт, что MapReduce слой был удален, и удален осознанно. Как многие из нас указывали годами, MapReduce не самый лучший внутренний интерфейс для SQL (или Hive) СУБД [2-3, 2-4]. Impala была создана разработчиками, которые знали про данный факт. На самом деле, похожая на Impala активность уже происходит как внутри HortonWorks, так и Facebook. Это ставит поставщиков Hadoop перед дилеммой — исторически «Hadoop»-ом называлась open-source реализация MapReduce, созданная Yahoo. Тем не менее, Impala выбросила этот слой из своего стека решения.

Как кто-то может оставаться вендором Hadoop если Hadoop уже не лежит в основе его стека?

Ответ прост – надо переопределить значение «Hadoop» и это то, что вендоры Hadoop в итоге и сделали. «Hadoop» теперь означает весь стек: внизу HDFS, на вершине работает Impala, MapReduce или другие системы. Над этими системами могут работать еще более высокоуровневые решения, такие как Mahout. Понятие «Hadoop» теперь относится ко всей коллекции получаемых решений.

Другой недавний анонс сделан Google, который сообщил, что MapReduce это уже «прошлый век», и что они пошли дальше, и стали применять решения лучше, строя свои системы на системах типа Dremmel, BigTable, и F1/Spanner [2-5]. Google должно быть адски смеется сейчас: они изобрели MapReduce для поддержки своего краулера в их поисковом движке в 2004, но несколько лет назад они заменили MapReduce реализацией BigTable, т.к. им нужна была интерактивная система хранения данных, а MapReduce работал только в пакетном режиме. В итоге получаем, что основная движущая сила за MapReduce отказалась от него еще некоторое время назад. И сейчас Google сообщает, что в будущем MapReduce не потребуется.

На самом деле это достаточно иронично, что Hadoop выбирает поддержку этой парадигмы спустя 5 лет от того момента как Google от нее отказался и пошел дальше. Получается, что весь остальной мир последовал за Google в Hadoop с неслабой задержкой около 10 лет. Хотя Google уже давно от этого отказался. Интересно, как долго осознание этого факта займет у остального мира?

В итоге получается, что поставщики Hadoop решений движутся сейчас на пересекающихся курсах с поставщиками хранилищ данных. Они реализовывают в данный момент (или уже реализовали) по сути ту же самую архитектуру, что и поставщики хранилищ данных. Как только у них будут пара лет на укрепление созданных реализаций, то они смогут показать адекватную производительность. Заметим, что в настоящий момент большинство поставщиков хранилищ данных уже поддерживают HDFS, и многие предлагают реализацию частично-структурированных данных. Посему, я убежден, что рынок поставщиков хранилищ данных и рынок поставщиков Hadoop скоро объединится. И пусть лучшая система выиграет в такой уличной битве лицом-к-лицу!

Теперь повернемся к HDFS, который стал одним из основных кирпичиков в основе стека Hadoop. Заметим, что HDFS это файловая система, прежде всего умеющая хранить байты данных, что вполне естественно ожидать на любой вычислительной платформе. Существуют 2 возможных взгляда на то куда HDFS может двинуться в будущем.

Если посмотреть на это глазами мира файловых систем, то пользователи хотят иметь общую распределенную файловую систему, и с этой точки зрения HDFS — идеальный кандидат.

С точки же зрения параллельного SQL/Hive в СУБД, HDFS несет «участь хуже смерти». СУБД всегда и всюду хотят послать запрос (малое количество килобайт) к данным (много гигабайт) и никогда наоборот. Потому, скрытие расположения данных от движка СУБД смерти подобно, и СУБД всегда будет очень, очень сильно пытаться обойти такое ограничение. Все параллельные СУБД, и от поставщиков хранилищ данных и до поставщиков Hadoop, будут выключать прозрачность расположения, превращая HDFS просто в коллекцию
файловых систем Linux, по одной файловой системе на узел.

Аналогичным образом нет СУБД, которая хотела бы работать с репликами файловой системы. В [2-6] вы можете ознакомиться с подробной дискуссией по этому поводу. Вкратце получаем, что и для распределения нагрузки, и оптимизации запросов и проблем обработки транзакций, для всего предпочитаем системы репликаций, применяемые в СУБД.

Если со временем окажется, что точка зрения поставщиков СУБД возобладает на рынке, то HDFS истощится, т.к. поставщики СУБД перестанут его использовать. В их мире на каждом узле уже есть локальная файловая система, параллельные СУБД поддерживают высокоскоростной язык запросов и поверх всего этого работает множество инструментов и расширений, определенных через пользовательские функции. В этом сценарии Hadoop превращается в стандартную СУБД с архитектурой shared-nothing с некоторым количеством альтернативных поставщиков СУБД, борющихся за ваш доллар.

С другой стороны, если возобладает точка зрения файловой системы, то выживает HDFS с широким набором различных инструментов, работающих поверх файловой системы. Такие стандартные для СУБД окружений функции как балансировка-нагрузки, аудит, регуляторы ресурсов, независимость от данных, целостность данных, высокая доступность, управление параллелизмом, и качеством обслуживание, все эти функции будут медленно идти к пользователям файловой системы. В таком сценарии не будет высокоуровневых стандартных интерфейсов. Другими словами, взгляд на мир со стороны СУБД предлагает большой набор дополнительных, полезных сервисов, и пользователей заранее предупредят, чтобы те были крайне аккуратны, запуская низкоуровневые интерфейсы.

В любом из этих сценариев общей частью остается файловая система, и поставщики Hadoop будут продавать или инструменты на базе файловой системы, или на базе СУБД (ну или и на том, и на другом). В итоге они присоединятся к сонму поставщиков программного обеспечения, продающих софт или сервисы. И пусть лучшие продукты выигрывают!

Ссылки

• [2-1] http://cacm.acm.org/blogs/blog-cacm/149074-possible-hadoop-trajectories/fulltext
• [2-2] http://www.cloudera.com/content/cloudera/en/products-and-services/cdh/impala.html
• [2-3] http://dl.acm.org/citation.cfm?id=1629197
• [2-4] Pavlo, A. et. al., «A Comparison of Approaches to Large-Scale Data Analysis,» SIGMOD 2009.
• [2-5] http://www.datacenterknowledge.com/archives/2014/06/25/google-dumps-mapreduce-favor-new-hyper-scale-analytics-system/
  
• [2-6] Stonebraker, M., et. al., «Enterprise Data Applications and the Cloud: A Difficult Road Ahead,» Proc IEEE IC2E, Boston, Ma., March 2014