Apache Hadoop (Владимир Климонтович на ADD-2010) — различия между версиями

* {{libcustis-review|ADD 2010: Отчет Глеба Тарасова/Apache Hadoop}}
* {{libcustis-review|ADD 2010: Отчёт Русецкого Георгия/Apache Hadoop}}
* {{libcustis-review|ADD 2010: Отчет Алексеева Алексея/Владимир Климантович. Apache Hadoop}}
* {{libcustis-review|Отчет о конференции ADD-2010 - Владислав Иофе/Apache Hadoop}}


[[Категория:ADD-2010]]
[[Категория: Параллельное программирование ]]
[[Категория: Доклад со стенограммой]]
[[Категория:NOSQL ]]
{{stats|disqus_comments=0|refresh_time=2017-12-25T21:42:092018-01-10T21:03:06.061817905552|vimeo_comments=0|vimeo_plays=3424|youtube_comments=0|youtube_plays=19}}

Версия 18:03, 10 января 2018

Аннотация

Владимир Климонтович

Владимир Климонтович поделился своим опытом обработки ОЧЕНЬ БОЛЬШИХ объемов данных, и использование для этого NOSQL-подходов, в частности Apache Hadoop.

История вопроса.

• Почему проблема обработки большего объема данных становится все более актуальной (пример роста количества данных в разных областях).
• Статья от компании 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 оказывается удобным.

Видео

on youtube

Подкаст

Презентация

Стенограмма

Стенограмму по видеозаписи записал Стас Фомин.

Summary

Собственно говоря, про что я вам такое сегодня расскажу. Так, ничего не видно, так что придется сегодня больше рассказывать, чем смотреть. Последнее время, за последние, скажем, лет десять, в IT в целом, стала проблема обработки большого объема данных. В первую очередь, она стала перед такими компаниями как Гугл, которая занимается поиском, и прочими компаниями.

В общем, сегодня я расскажу, как задача решается. Как она решается в целом, что было придумано компанией Гугл, в 2003-2004 году и также про open-source реализацию этих способов обработки и хранения больших объемов данных, под названием Apache Hadoop.

И также если останется время, я немножко расскажу про column-oriented databases, это базы данных, которые устроены немного по-другому, чем реляционные, и также про реализацию.

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

Итак, чтобы вы представляли, о чем идет речь, о каких объемах данных. Например, компания Facebook, всем известная, наверно у всех есть там профайлы, у компании 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

input record  ⇒  (key, value)

(key, {v1, ..., vn})  ⇒  output record

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

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

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

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

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

Пример

log record  ⇒  (Browser, 1)

(Browser, [1, .., 1])  ⇒  {Browser, sum}

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

Самый простой пример. Пусть мы компания 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

{userId, band, track}  ⇒  (user_band, 1)

(user_band, [1, ... , 1])  ⇒  (user_band, sum)

Опять же 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 получает собственно в качестве ключа эти поля, в качестве значений, набор полей, которые мы агрегируем, т.е. какие-то , и просто делает суммирование.

Собственно говоря и все, мы задали такие 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-sourc-ный 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

(row key, column name)  ⇒  value

(row key, column name, timestamp)  ⇒  value

Он был представлен компанией Гугл, и до сих пор они его используют, если мне не изменяет память, это статья «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 Hadoo, реализует проект, называющийся 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 можно использовать в таких задачах, когда нам не нужно гарантированное время ответа, когда нам не критична потеря данных, опять же вот, хранение информации о уникальных пользователях. К нам пришел пользователь на сайт, если мы не смогли его идентифицировать, не знаю .… выключился... (выключился микрофон).

Вопросы

Идея чего? Идея вообще этого MapReduce? Идея состоит в том, что это довольно большой класс задач обработки данных, можно выразить …

Ну в смысле, как ищет? Вы задали эти два процесса, map и reduce, и после этого, процесс map-а …

В Map-е функция, просто функция, которая получает на вход строчку, а на выход — ключ и значение. Просто задается такая функция…

Как ключ и значение? Просто пара двух строк, условно говоря.

В случае подсчета статистики? Ключ — это броузер, как я сказал, значение, это единица.

На самом деле, что будет являтся ключем, а что — значением, довольно важно, ибо дальше будет происходить группировка перед процессов reduce.

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

Да.

Ну, собственно говоря, это и есть, значение какой-то константы, т.е. единица.

Единичка — это число. Ключ — броузер, а единица — это число.

Да, именно.

Ну это конечно не совсем SQL, я рассказал о том, как он используется в виде SQL, поскольку это самый простой пример, на самом деле, с помощью MapReduce можно решать намного более сложные задачи. Например, мы, с помощью Map-Reduce, строим статистическую модель по кликам на контекстную рекламу, которая позволяет искать вероятность, конкретного клика на конкретном объявлении. Еще вопросы?

Да, это опять же делаю не я, это делает Apache Hadoop, т.е. для программиста это выглядит довольно прозрачно. Я просто даю эти функции, и дальше там внутри как-то делится, на каждом кусочке запускается отдельный процесс, который называется mapper, который выполняет map. Потом, все группируется, начинается этап reduce, для программиста там все прозрачно, не нужно определять, как мы там делим файлы.

Ну, …

На самом деле, да, это сложная система, но с хорошим системным администратором она работает стабильно. Т.е. в принципе никаких проблем нет. Опять же Hadoop, несмотря на то, что это сложная система, если у вас какой-нибудь маппер упал, или потерялся connection к node, ничего страшного, вы перезапустите на другой ноде, с теми же там... и в целом, сам дизайн, он довольно стабильный, но вот с конкретно реализацией Hadoop, есть небольшие проблемы.

Ну вот как я сказал — мы строим вероятностную модель, которая позволяет предсказывать вероятность клика на контекстной рекламе. Если вам интересна эта конкретная модель…

Ну не знаю… Мы используем концепцию decision tree, по алгоримту IT Tree, не знаю, если это вам что-то говорит…

Ну это очень долгий рассказ, как это использовать, в Hadoop, не знаю, могу после рассказать.

Можно. Большой пласт задач решается, мне сложно прямо перечислить их все.

Допустим, если вам нужно, какой-нибудь отчет показывать, если вам нужно строить такое дерево или показывать результаты пользователей realtime, когда нажимают какую-нибудь кнопочку на сайте, то у вас это не получится, поскольку такая джоба у вас может занимать минуту, десять секунд…

Матрица… Сложный вопрос. Надо подумать. Возможно нет, даже скорее нет.

Смотря какие. Некоторые математические вычисления очень хорошо выражаются и параллелятся на map reduce. Некоторые нет.

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

Я, например, использую Hadoop для построения поиска, для построения поискового индекса. Компания Facebook использует Hadoop для research and development, они записывают действия пользователей в лог-файлы, которые хранятся на distributed file system, их research developers пишут какие-то map-reduce jobs, какие-то расчеты пишут, какие-то корреляции ищут, изучают какие-то статистические модели.

На самом деле много компаний его используют, вот, например, Yahoo, Facebook — наверное самые крупные.

А я даже не знаю, что это такое.

Да, сейчас они вообще закрывают этот бизнес, переходят на Bing-овский поисковик. Но тем не менее, сейчас поисковик работает, он работал два год на Hadoopе, и в общем-то, поиск был такой, что у них работало.

Гугл использовал map-reduce и distributed file systems для построения и хранения индекса, до недавнего момента. Где-то месяц назад они аннонсировали, что их новая система поиска и построения индекса не использует map reduce, использует что-то новое.

BigTable она использует для собственно говоря хранения индекса, чтобы был real-time доступ, это всегда использовалось. Тем не менее, именно для обработки данных, для того, чтобы по большому объему страниц построить индекс, построить собственно говоря BigTable, в котором хранятся данные, раньше использовался map reduce, сейчас используется что-то новое.

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

Например, что вместо Hadoopа делать, тащем-то? Есть какая-то реализация, тоже опенсорсная, на сишарпе, которая используется в MySpace…

Нет, Windows Azure это что-то другое, это ведь аналог Amazon EC2, там можно покупать машины…

Нет, насколько я знаю, нет. Если они конечно выпустят какой-нибудь map-reduce, он будет стабильней, чем hadoop.

Что значит похожие? Подход map-reduce, это обработка большого объема данных на кластере, так чтобы...

Ну вот BigTable, опять таки. Вы обработали данных, храните их в BigTable, в HBase, как я описал.

Вы хотите все сразу — и обработать данные и куда-то их сохранить, и все это real-time.

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

Если у вас маленькое количество данных, то используйте обычный SQL и не выпендривайтесь.

Про Pig? Я уже сказал, что это фреймворк поверх Apache Hadoop, вместо того, чтобы писать конкретные мапперы и reduce, вот у меня был слайд с примером кода,

Вот пример кода,

Мы пишем в таком виде, в декларативном виде, какие данные нам нужны, и этот запрос будет распараллелен на map-reduce.

Ну там есть интерпретатор, он строит синтаксическое дерево, потом анализатор этого синтаксического дерева, который понимает, какие какая процедура мапа, какой редьюс, ведь это скорее не один мап-редьюс, это будет скорее sequence мап-редьюс задач, и все это запускает.

Ну нативное API на Java, потому что сам Hadoop написан на Java.

Есть SDK, есть. Есть такое понятие streaming, это что-то вроде CGI, когда вы пишете скрипты, которые получают тексты и выдают тексты, и писать вы их можете на чем угодно. Есть более продвинутое API для С++, COM, для Python-а. Вообще можно писать на чем угодно, на Java быстрее всего, поскольку API нативный.

Нету, нету.

Мы изучали… , у нас есть свой фреймворк, in-house, который описывать flow XML-ей, из которого потом снова генерируются map-reduce jobы. Мы пытались перейти на Hive, на Pig. С Hive ничего не получилось, с Pig-ом, … уже не я занимаюсь этим проектом, в принципе вроде получается, и довольно быстро.

У нас средняя компания.

Конечно выполняет, что-то он пытается делать. Я не могу сказать, насколько хорошо он это делает, сформулировать класс задач, которых он оптимизирует.

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

Plays:0   Comments:0

Примечания

• страничка доклада на сайте ADD-2010
• MapReduce: внутри, снаружи или сбоку от параллельных СУБД?
• Шпаргалка по Hadoop
• MapReduce без зауми

• «libcustisru:ADD 2010: Отчет Глеба Тарасова/Apache Hadoop»
• «libcustisru:ADD 2010: Отчёт Русецкого Георгия/Apache Hadoop»
• «libcustisru:ADD 2010: Отчет Алексеева Алексея/Владимир Климантович. Apache Hadoop»
• «libcustisru:Отчет о конференции ADD-2010 - Владислав Иофе/Apache Hadoop»

Plays:3443   Comments:0