13 April 2011

Apache Hadoop (Доклад Владимира Климонтовича на ADD-2010)

Лаборатория тестирования corporate blogProgramming
Tutorial
Представляем вашему вниманию доклад Владимира Климонтовича, сделанный им на конференции Application Developer Days, в котором он поделился своим опытом обработки ОЧЕНЬ БОЛЬШИХ объемов данных, и использование для этого NOSQL-подходов, в частности Apache Hadoop.



Ниже представлены текстовая версия доклада + видео + аудио и слайды презентации. Спасибо belonesox за работу над подготовкой материалов доклада.


История вопроса .
  • Почему проблема обработки большего объема данных становится все более актуальной (пример роста количества данных в разных областях).
  • Статья от компании Google про парадигму MapReduce. Краткое описание парадигмы.
  • Краткое описание смежных областей (distributed file system, bigtable-like storage).
  • История и краткое описание платформы Apache Hadoop.


Примеры использования.
  • Использование платформы hadoop в трех отдельно взятых областях: в last.fm (построение charts), в online-advertising'e (построение статистики), в Yahoo (построение поискового индекса).
  • Описание традиционного подхода (SQL базы данных) и подхода с использованием Hadoop для каждой из вышеобозначенных проблем. Достоинства и недостатки SQL/Hadoop подхода
  • Общий принцип трансляции некоторого подтипа SQL запросов в MapReduce job'ы.


Платформы, построенные поверх Hadoop.
  • Краткое описание ETL-framework'а Hive and Pig, построенных на базе Hadoop.
  • Примеры использования (на примере facebook.com и Yahoo); сравнение со стандартным SQL подходом


Проблемы с real-time доступом к данным при использовании Apache Hadoop.
  • Описания случаев, когда real-time нужен, а когда нет.
  • Описание решения простых проблем с realtime: кэширование в памяти (memcached), симбиоз со SQL
  • Симбиоз с bigtable-like БД на примере HBase. Краткое описание HBase.


Hadoop как тренд.
  • Краткий обзор технических и бизнес проблем, возникающих при использовании Hadoop
  • Шумиха вокруг Hadoop и NoSQL подхода. Описание случаев, когда SQL оказывается удобным.


Видео

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

Аудио
Аудио-версия доклада доступна по ссылке.

Презентация доклада
Презентация доклада доступна по ссылке.

Объемы данных

Итак, чтобы вы представляли, о чем идет речь, о каких объемах данных. Например, компания Facebook, всем известная, наверно у всех есть там профайлы, у этой социальной сети в день появляется 40 терабайт новых данных — фотографии, посты, комментарии, опять же лог-файл просто — показы страниц и прочее.

Что у нас дальше — опять же Нью-Йорская биржа, — один терабайт транзакций в день, данные о транзакциях, покупки и продажи акций и прочее.

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

И для примера, чтобы вы представляли, что происходит в небольших компаниях, — компания ContextWeb это небольшая американская компания, в которой по сути работаю я, которая занимается онлайн адвертайзингом, совершенно небольшая компания с очень маленьким процентом рынка, тем не менее это 115 гигабайт логов показа контекстной рекламы в день. Причем это не просто текстовые файлы, это 115 гигабайт сжатых данных, т.е. на самом деле данных наверное сильно больше.

DFS/MapReduce

Возникает вопрос, что собственно говоря с ними делать? Потому что надо их как-то обрабатывать. Сами по себе такие объемы данных они никому не интересны и довольно бесполезны.

Один из способов обработки таких объемов данных был придуман компанией Google. В 2003 году компания Гугл выпустила довольно известную статью про distributed file systems, как они хранят у себя внутри данные и индексы, данные о пользователях и прочее.

В 2004 году опять таки компания Гугл выпустила статью, которая описывает парадигму обработки такого объема данных, которая называется MapReduce.

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

Distributed FS

Distributed Filesystem — что это такое вообще? Какие задачи ставятся перед Distributed Filesystem?

  • Во-первых, это хранение больших объемов данных — файлов любого объема…
  • Во-вторых, это просто прозрачность, мы хотим работать с этой файловой системой как с обычной файловой системой — мы хотим открывать файлы, писать что-то туда, закрывать файлы, и не думать о том, что это что-то distrubuted и большое.
  • Также мы хотим… еще одно требование — это масштабируемость. Мы хотим хранить файлы на кластере и довольно легко его масштабировать. Например, у нас вырос бизнес в два раза, стало в два раза больше данных, хочется, чтобы без фиксированных изменений в архитектуре, хранить данных больше в два раза, просто добавив в два раза больше машин.
  • И также надежность. Т.е. у нас кластер, допустим из ста машин, вышло из строя, допустим, пять, надо, чтобы это для нас прошло незаметно — чтобы файлы были доступны, чтобы мы могли читать-писать, да, возможно с чуть меньшей производительностью, но чтобы все работало, пока эти пять машин не заметят.


DFS: архитектура

Собственно говоря, как это реализуется. Здесь есть небольшой график, наверное его не видно, но в целом видно, да.



Есть кластер из машин, которых много, на которых хранятся данные. Есть одна машина, которая называется master node, и которая координирует все.

Что хранится на мастер-ноде? На мастер-ноде просто хранится таблица файлов. Структура файловой системы, каждый файл разбит на блоки, на каких конкретно кластерных машинах, храниться какие блоки файлов.

Как происходит запись и чтение? Мы хотим прочитать какой-то файл, мы спрашиваем у мастер-ноды где хранятся блоки такого-то файла, он нам говорит, на какой машине хранятся конкретные блоки, и мы уже читаем напрямую из кластерных машин.

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

А для обеспечения надежности, каждый блок хранится в нескольких экземплярах, на нескольких машинах. Этим обеспечивается надежность, даже если у нас выйдет из строя, скажем, 10% машин в кластере, скорее всего, мы ничего не потеряем. Т.е. да, мы потеряем какие-то блоки, но поскольку эти блоки хранятся в нескольких экземплярах, мы сможем опять таки и читать и записывать

Конфигурация

Типичная конфигурация, которая, например, используется у нас в компании. Чтобы хранить большие объемы данных, например, в нашей компании это 70 терабайт, которые мы регулярно анализируем, что-то с ними собираемся делать, это где-то сорок машин, каждая машина это слабенький сервер, если смотреть по индустрии, это где-то 16 гигабайт оперативной памяти или 8 гигабайт, терабайтный диск, никакого RAID, просто обычный диск.

Какой-нибудь Intel Xeon, в общем, какой-то дешевенький сервер. Таких серверов тоже сорок, и это позволяет хранить такие объемы данных, скажем, сотни терабайт.

MapReduce

После того, как все файлы хранятся на distributed файловой системе, возникает вопрос, как их обрабатывать. Для этого компанией Гугл была придумана парадигма, которая называется MapReduce. Выглядит она довольно странно. Это обработка данных, в три операции.

Первая операция…, у нас есть какие-то входные данные, например, набор каких-нибудь input record-ов.

Первая операция, которая называется Map, которая по каждому input record-у выдает нам пару «ключ → значение». После этого, внутри, эти пары «ключ → значение» группируются, каждому ключу, когда мы обработаем все входные записи может соответствовать несколько значений. Группируются, и выдаются на процедуру Reduce, которая получает ключ, и соответственно, набор значений, и выдает уже, окончательно финальный результат.

Таким образом, у нас уже есть набор каких-то input record-ов, например, это строчки в лог-файле, и мы получаем какой-то набор output record-ов.

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

Пример

На самом деле, очень хорошо может применяться на широкой практике.

Самый простой пример. Пусть мы компания Facebook, у нас очень много данных,… ну просто логи показываем страниц на фейсбуке. И надо посчитать, каким броузером кто пользуется.

Это сделать, с помощью парадигмы MapReduce довольно легко.

Мы определяем операцию Map, которая по строчке в access loge определяет ключ-значение, где ключ — это броузер, а значение — просто единичка.

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

Мы запускаем эту задачу MapReduce на кластере, в начале у нас много-много лог файлов, в конце у нас такой маленький файлик, в котором у нас есть броузер, и соответственно, количество показов. Таким образом мы узнаем статистику.

Параллельность

Почему это хорошо, MapReduce?

Такие вот программы, когда мы задаем Map и задаем Reduce, они очень хорошо параллелятся.

Допустим у нас есть какой-то Input, это большой файл, или наборы файлов, этот файл можно разбить на много-много маленьких кусочков, например, по числу машин в кластере, или больше. Соответственно, на каждом кусочке мы запустим нашу функцию Map, это можно делать параллельно, все это запускается на кластере, по-тихонечку вычисляется, результат каждого map-а, внутри как-то сортируется, и отправляется на Reduce.

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

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



Apache Hadoop


Apache Hadoop — что это такое? После того, как Гугл опубликовал эти статьи, все решили, что это очень удобная парадигма, в частности, возник проект Apache Hadoop. Они просто решили, что то, что написано в этих статьях, про distributed file systems и парадигму MapReduce, реализовать, как open-source проект на Java.

Началось это еще в 2004 году, когда люди захотели написать открытую поисковую систему Nutch, после этого, где-то в 2005 году, из нее Apache Hadoop выделился как отдельный проект, как реализация distributed file system и парадигмы MapReduce. Сначала это был небольшой проект, не очень стабильный, где-то в 2006 году компания Yahoo начала пробовать использовать Hadoop в своих проектах, и в 2008-2009, компания Yahoo запустила свой поиск, вернее не поиск, а индексацию, которая была полностью устроена на платформе Apache Hadoop, и сейчас Yahoo индексирует интернет, используя платформу Apache Hadoop. Индекс хранится в distributed file system, а само построение индекса сделано как серия Map-Reduce задач.

Да, опять же Hadoop недавно выиграл соревнование по сортировке данных, есть такой «1TB sort contest», когда какие-то люди собираются и пытаются быстрее отсортировать один терабайт данных. Регулярно выигрывает система, построенная на основе Apache Hadoop, которая запускается на кластере Yahoo.

Mодули Hadoop

Hadoop состоит собственно из двух модулей. Это реализация парадигмы распределенной файловой системы, которая называется HDFS, и MapReduce, т.е. реализация MapReduce-фреймворка.

Yahoo: web graph

Еще вот немного примеров, про то, как допустим, Yahoo, использует Hadoop. Yahoo нужно, например, строить граф всего интернета. В качестве вершин у нас будут странички, если с одной страницы будет ссылка на другую, это будет ребро в графе, и помечено это ребро текстом ссылки.

Например, как это делает Yahoo. Это тоже из серии Map-Reduce задач. Сначала Yahoo скачивает все страницы, которые им интересно индексировать, и хранит их, опять таки, в HDFSе. Чтобы построить такой граф, запускается map-reduce задача.

Итак, Map, мы просто берем страницу, и смотрим, куда она ссылается, и просто выдает такое вот в качестве ключа, Target URL, т.е. куда ссылается с страница, значение → SourceURL, т.е. куда мы ссылаемся и текст ссылки.

Reduce просто получает все эти пары, … т.е. он получает ключ, это TargetURL и набор значений, т.е. набор SourceURL-ев и текстов, делает какую-то фильтрацию, ибо у нас очевидно есть какие-то спамные ссылки, которых мы не хотим индексировать, и возвращает все это в виде таблицы — TargetURL, SourceURL и текст.



Такая таблица это граф всего интернета.

Last.fm



Опять же Last.fm, наверное многие пользуются, кто не пользуется — немного объясню. Это такой сервис, вы ставите плагин к вашему iTunes-у или WinAmp-у, он посылает на last.fm в реальном времени то, что вы слушаете, после этого Last.fm делает две вещи — например, он строит такие красивые chart-ы, т.е. за последние семь дней или три месяца, какие группы вы слушали, какие у вас композиции, и еще делает какие-то last.fm ??? радио на основе статистики прослушанных вами композиций, они вам рекомендуют что-то другое, что-то новое и интересное для вас, то, что якобы будет вам интересно. Если кто-то заметил, то эти chart-ы, они обновляются не в real-time, раз в день, что-ли, не помню, в общем, нечасто.

Собственно эти chart-ы, они строятся снова, на платформе Apache Hadoop. Когда вы слушаете какую-то композицию, просто записывается строчка в лог-файл, «юзер с таким-то идентификатором прослушивал такую-то композицию такой-то группы». После этого раз в день запускается Map-Reduce задача. Как она выглядит?
  • Input — это тот самый лог файл этих прослушиваний.
  • Map выглядит как — берем строчку из этого логфайла, ее парсим, и в качестве ключа выдаем пару «юзер и группа», а в качестве значения — единица.
  • Соотвественно потом все это попадает на Reduce в ввиде пары «юзер и группа» и с значением в виде набора единиц, и пишется в конце всего в файл, как «пользователь-группа и количество прослушиваний».


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

SQL

На самом деле, большое количество SQL-запросов легко параллелится в виде…, легко можно выразить в виде Map-Reduce задач. Например, стандартный SQL, многие пишут, многие таким пользуются, — набор полей, f1, f2, сумма, where, какое-нибудь условие и group by.

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

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

Собственно говоря, как это устроено.

Map-процесс. В качестве inputа у нас строчки в лог-файле, в качестве output-а, мы эту строчку парсим и выдаем в качестве ключа, поля, которые нас интересуют в качестве group by, и качестве значения, поле, которое мы агрегируем, в данном случае мы считаем сумму a.

Reduce получает собственно в качестве ключа эти поля, в качестве значений, набор полей, которые мы агрегируем, т.е. какие-то A1,....An, и просто делает суммирование.

Собственно говоря и все, мы задали такие map-reduce процедуры на кластере и получили результаты для этого запроса.

SQL: Принцип

На самом деле множество SQL-запросов можно распараллелить…, можно выразить в терминах map-reduce job.

Если у нас есть GROUP BY, поля, по которому мы делаем GROUP BY мы определяем как ключ в процессе Map.

WHERE — это просто фильтрация в процессе Map-а.

Опять же все суммы, AVG, и прочие агрегирующие функции мы считаем на этапе Reduce.

Очень легко реализуется условие HAVING, JOIN и прочее.

SQL: partitioning

Немного про Partitioning. Когда мы так обрабатываем данные, допустим, вот в том же last.fm, мы строим эту статистику, у нас данные хранятся в файле, если мы будем каждый раз запускать map-reduce job-ы на всех файлах, которые есть, это будет очень долго и неправильно.

Обычно для данных используется partitioning, например, по дате. Т.е. мы храним все не в одном едином лог-файле, а разбиваем его по часам или по дням. Тогда, когда мы map-аем наш SQL-запрос на MapReduce-job-ы, мы сначала ограничиваем набор входных данных как…, собственно говоря, по файлам. Допустим, если нас интересуют данные за последний день мы берем данные только за последний день, и только потом запускаем map-reduce-jobы.

Apache Hive

Собственно говоря, этот принцип реализован в проекте Apache Hive, это такой фреймворк, построенный на базе Hadoop.

Как все это выглядит с точки зрения пользователя? Мы задаем некоторый SQL-запрос, определяем, где у нас лежат данные, после этого, этот фреймворк выражает этот SQL-запрос в виде map-reduce задач, в виде одной или целой последовательности, запускает их…, для пользователя все выглядит довольно прозрачно.

Т.е. мы определили набор входных данных, задали SQL-запрос, и на выходе получили тоже, какую-то таблицу.

Apache Pig

Второй фреймворк, это Apache Pig, это тоже самое, примерно, решает ту же задачу, т.е. прозрачное для пользователя создание map-reduce job-ов, без того, чтобы писать какой-нибудь код.

Мы задаем в таком вот ETL-языке, последовательность, что мы хотим, откуда мы хотим что-то загрузить, как мы будем эти данные фильтровать, какие колонки нас интересуют, и все это транслируется в map-reduce job-ы.



Области применения

Собственно говоря, области применения, всего этого Hadoop-а и прочего.

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

Если у нас есть много лог-файлов, мы хотим найти какие-то корреляции, как ведет себя пользователь, в зависимости от чего, такие задачи очень хорошо решаются с помощью Hadoopа, соответственно построение отчетов, опять же, тот же Last.fm. Когда у нас есть много данных, и мы должны строить какие-то отчеты, они нам не нужны real-time, мы готовы их обновлять раз в день, или в несколько часов, тоже все очень удобно.

Достоинства


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

Нулевая стоимость software. Там у вас много данных, вы можете пойти в компанию Oracle, купить за пару миллионов долларов кластерный Oracle, и столько же консультантов, это не всем компаниям подходит, особенно startup-ам. Не знаю, ну какая-нибудь новая социальная сеть, они просто не могут себе позволить потратить несколько миллионов на Oracle. Они могут себе позволить Hadoop, взять кластер и использовать open-source-ный Hadoop, как систему анализа и хранения данных.

Еще Hadoop удобен для research-задач. Например, вы researcher, и вы хотите исследовать корреляцию поведения пользователей с чем-нибудь на фейсбуке, где-нибудь еще в вашей социальной сети, у вас есть много файлов, hadoop доступен, как on-demand сервис на Амазоне.

Т.е. вы написали что-то у себя, локально отладили, говорите, ОК, теперь мне нужен кластер из ста машин на два часа, вам сразу Амазон представляет кластер из ста машин, вы запускаете там свою задачу, получаете какие-то результаты, и все как бы.

Сто машин на час у Амазона стоят относительно дешево, дешевле чем у себя хранить кластер. Для research-а это достаточно удобно, то, в том смысле, что вам все это нужно раз в неделю, не нужно хранить у себя кластер, можно заказывать его у Amazon-а.

Из зала: Сколько стоит, порядок цифр?

На час… ну это порядка сотен долларов. Я, честно говоря, уже у амазона цену не помню, но это довольно дешево, это вполне доступно.

Из зала: Пятьдесят центов в час…

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

Недостатки

А какие недостатки в Hadoop-е?

Во-первых, это довольно высокая стоимость поддержки. Если у вас есть Hadoop-кластер, из многих машин, вам нужно найти умного системного администратора, который разберется в архитектуре Hadoop-а, в том, как это работает, и будет все это поддерживать. Т.е. это действительно непросто, это действительно занимает много времени.

Это в отличие от каких-нибудь промышленных и дорогих хранилищ, стоимость новых процессов обработки данных достаточно высокая. Т.е. если вы покупаете какой-нибудь Oracle, или что-то подобное в этом стиле, вам в принципе достаточно, нанять каких-то бизнес-аналитиков, которые будут писать просто SQL-запросы и получать какие-то результаты. В данном случае, такое не получится с Hadoopом, вам нужны будут люди, которые будут придумывать бизнес-часть, какие именно данные им нужны, и вам будет нужна команда Java-разработчиков, которые будут писать эти map-reduce job-ы.

Команда не очень большая, но тем не менее, все равно это стоит денег, разработчики довольно дорогие.

И опять же, проблема с real-time-ом. Hadoop это не real-time система. Если вы хотите получать какие-то данные, у вас не получится так, что вы будете запускать map-reduce job-ы, когда пользователь заходит на сайт. Вам нужно обновлять данные, хоть раз час, в background-е, а пользователю показывать уже рассчитанные данные.

Real-Time?

С real-timом проблема относительно решаемая. Например, как это решается у нас в компании. Нам не нужно предоставлять real-time доступ, ко всему объему данных, что у нас есть, мы запускаем map-reduce job-ы, получаем какие-то результаты, довольно ценные, но разумного размера, которых мы храним в SQL-базе данных, в MemCache, в памяти, это тем не менее, не будет работать, когда этих данных будет у вас много.

Поэтому сейчас … время еще осталось?

Осталось десять минут, поэтому я расскажу о column-oriented базах данных, тоже подход к хранению большого объема данных, к которым нужен realtime доступ.

Column oriented databases

Как это устроено? Какие вообще есть проблемы с SQLем? В SQL, в MySQL вы не сможете хранить объемы, скажем, в несколько терабайт, такая таблица просто не будет работать, вы не сможете из нее получать данные.

Другие проблемы с SQL-ем, если вы меняете схему, допустим, какой-нибудь ALTER TABLE, долго и проблематично на большой таблице добавить какие-нибудь колонки. Это довольно проблематично, и когда вам этого не нужно, когда вам не нужно хранить структурированные данные, когда вы снимаете ограничения… не пользуетесь возможностями SQL, как хранилища структурированных данных, не используете реляционность, можете хранить данные в немного более эффективной структуре, и за это получать большую производительность.

Это как раз немного другой подход, который называется column-oriented database.

BigTable

Он был представлен компанией Гугл, и до сих пор они его используют, если мне не изменяет память, это статья «BigTable», которая была опубликована в 2004 году.

Собственно говоря, что такое BigTable?

Он построен на нескольких принципах.

Первый принцип, что мы отказываемся от реляционности, от индексации по полям, в нашей таблице есть ровно одно поле, по которому можно производить поиск, то, что называется rowkey, аналог — это primary key в таблице.

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

BigTable: пример

Давайте, я приведу пример, когда это используется. Мы хотим хранить данные о пользователях нашего сайта. Зашел на сайт, сделал какие-то действия, в случае Гугл — сделал какие-то запросы, что-то посмотрел, посмотрел какие-то рекламные объявления, это анонимный пользователь … и мы хотим помнить про то, что он сделал. Как решается эта задача? Многие люди, хранят информацию о пользователях в Cookies, что он сделал, какие страницы посмотрел, какие рекламные объявления посмотрел, на что кликнул. С этим подходом есть большая проблема — размер cookie сильно ограничен, туда нельзя, допустим, записать, историю действий пользователя за последний месяц, не получится, нет места. Как эту проблему можно решить с помощью BigTable?

Если у нас есть такое хранилище, как BigTable, мы можем хранить в cookie единственный параметр — уникальный идентификатор пользователя. В BigTable мы будем хранить UserUID, как основной ключ в таблице, и много-много полей, которые нас интересуют, например, история посещений, клики на рекламу, клики на ссылки, и прочее.

Чем это хорошо? Тем, что нам заведомо не надо искать ничего по остальным полям. Если мы хотим знать какую-то информацию о юзере, чтобы показать ему соответствующую рекламу, нам нужно искать только информацию по UserID.

И также хорошо, что поскольку бизнес может меняться, мы можем добавлять много разных полей, и это будет дешево и хорошо. Собственно для этого очень хорошо использовать BigTable, userID, как rowkey, и все остальные данные, как таблица.

BigTable: дизайн

Как это все работает? Такой подход, как у BigTable, он очень хорошо масштабируется на большое количество компьютеров. Т.е. если у нас rowkey, и мы ищем исключительно по rowkey, например, по юзер айди, как я привел в предыдущем примере, то мы можем все данные отсортировать по этому юзерайди, и хранить разные rang-и этих данных на разных серверах. Т.е. как будет происходить запрос «получить всю информацию по данному юзер-айди»? На мастер-ноде хранится информация, какие range-ы хранятся на каких серверах, мы сначала справшиваем, у мастер-ноды, где хранятся интересующие нас данные, затем обращаемся напрямую к этой ноде, и читаем оттуда данные.

Опять же очень хорошо — в два раза больше данных → купили в два раза больше машин, немного переструктурировали хранилище, причем не мы переструктурировали, а система, которая представляет нам доступ, и все, мы можем хранить в два раза больше данных.

HBase

Эту парадигму BigTable, развивающийся в рамках Apache Hadoop, реализует проект, называющийся HBase.

Данные хранятся в Hadoop Distributed File System, которую мы уже обсудили, все прозрачно интегрируется с Hadoop-ом, если мы пишем, какие-то map-reduce jobы, которые возвращают какие-то результаты, есть очень прозрачная интеграция, т.е. результаты Reduce можно писать напрямую в базу данных. Поскольку Reduce операция распределенная, данные опять таки будут писать в распределенную базу данных, в HBase, и в принципе, в сочетании с Hadoopом, все получается очень удобно.

HBase: производительность

Например, пример производительности. Вот, довольно простой кластер из семи нодов, нода — это 16 или 8 гигабайт оперативной памяти, довольно простой диск, 10К RPM, несколько ядер на каком-нибудь обычном Intel Xeon, вот тут написаны точные данные.

Таблица из трех миллиардов записей, это довольно много, каждая запись это 3-5 полей… И если запустить тест на 300 запросов в секунду на запись и на чтение, чтение будет занимать где-то 18 миллисекунд, запись —— быстрее, где-то 10 миллисекунд. Такой производительности на каком-нибудь MySQLе добится невозможно. С HBase это получается.

HBase: недостатки

Какие недостатки у HBase, и вообще, у этого BigTable подхода? Неструктурированность, т.е. нереляционность. У нас есть только одно индексное поле, по которому мы можем искать, у нас нет join-ов, у нас нет сложных запросов WHERE, ну да, это действительно большие недостатки, но тем не менее, в большой классе задач это просто не нужно.

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

Hadoop: области использования

И еще немножко про области использования, собственно говоря, map-reduce мы обсудили, это research, это анализ данных, это построение статистических моделей, собственно говоря HBase и BigTable…, да, забыл сказать про один недостаток HBase-а, хотя запросы в целом, довольно быстрые, иногда случается, что какой-то запрос занимает очень много, допустим секунду, нет, секунда это врядли, ну, скажем, полсекунды, триста миллисекунд.

HBase можно использовать в таких задачах, когда нам не нужно гарантированное время ответа, когда нам не критична потеря данных, опять же вот, хранение информации о уникальных пользователях. К нам пришел пользователь на сайт, если мы не смогли его идентифицировать, не знаю .… выключился… (выключился микрофон).

Вопросы

Вопросы к докладу и ответы, — можно увидеть в видео, услышать в аудио (см. выше) или прочесть по ссылке.

Tags:nosqlapache hadoophighloadaddconfоблачная платформа
Hubs: Лаборатория тестирования corporate blog Programming
+56
6.8k 133
Comments 24
Information
Founded

6 March 2009

Location

Россия

Employees

Unknown

Registered

21 August 2013