Hadoop *

Компания Microsoft приняла решение поддержать пользователей, которые хотят делать кластеры Hadoop на Windows Server и Windows Azure. В рамках стратегического сотрудничества с Hortonworks будет разработан стек для Hadoop. Microsoft обещает публиковать код под открытой лицензией, делая коммиты в проект Apache по окончании разработки.

Вдобавок, Microsoft создаст «простые версии, которые можно скачать, инсталлировать и настроить» различных технологий, связанных с Hadoop, в том числе HDFS, Hive и Pig. Это должно стимулировать использование Hadoop корпоративными заказчиками.

Агентство национальной безопасности США предоставило на рассмотрение фонда Apache Software Foundation свой проект Accumulo. Это распределённая СУБД, созданная на основе дизайна Google BigTable с использованием кода Hadoop, Zookeeper и Thrift. Дизайн BigTable обнародован в 2006 году, работа над Accumulo началась в 2008-м, причём он изначально задумывался как свободный проект с использованием открытых библиотек.

Главным улучшением Accumulo по сравнению с BigTable является продвинутая система разграничения прав доступа на уровне отдельных ячеек (cell-level access labels). Различные пользователи могут получать доступ только к определённым полям базы данных, которым присвоен соответствующий уровень доступа (labels).

В Калифорнийском университете в Беркли разработали фреймворк Spark для распределённых вычислений в кластерах. На некоторых задачах он превосходит Hadoop в 10-30 раз, сохраняя при этом масштабируемость и надёжность MapReduce.

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

 

Возможно ли развернуть кластер Hadoop в Windows Azure? Конечно же, да, и как вы сможете убедиться, это совсем нетрудно.

В этой статье я продемонстрирую порядок того, как создать типовой кластер с серверами Name Node, Job Tracker и управляемым числом Slave-серверов. Вы сможете динамически изменять число Slave-серверов с помощью портала Azure Management Portal. Описание механики этого управления я оставлю на следующий пост.

Следуйте следующим шагам для того, чтобы создать пакет Azure для вашего кластера Hadoop с нуля:

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

Отлаживать однопоточное Java приложение просто. Отлаживать многопоточное Java приложение — чуть сложнее, но все равно просто. Отлаживать мультипроцессное Java приложение? С процессами, запущенными на разных машинах? Это определенно сложнее. Именно поэтому все руководства по Hadoop рекомендуют обращаться к отладке только и исключительно тогда, когда другие опции (читай: логгинг) исчерпаны и не помогли. Ситуация зачастую усложняется тем, что на больших кластерах у вас может и не быть доступа к конкретным map/reduce узлам (именно с этим вариантом я и столкнулся). Но давайте решать проблему по частям. Итак…

Сценарий первый: локальный Hadoop

Самый простой вариант из всех возможных. Локальная инсталляция Hadoop — все выполняется на одной машине, и более того — в одном процессе, но в разных потоках. Отладка эквивалентна отладке обычного мультипоточного Java приложения — что может быть тривиальнее?

Как же этого добиться? Мы идем в директорию, где у нас развернут наш локальных Hadoop (я полагаю, что вы умеете это делать или умеете прочитать соответствующую инструкцию и уже теперь с этим справитесь).

    $ cd ~/dev/hadoop
    $ cp bin/hadoop bin/hdebug
    $ vim bin/hdebug

Наша задача — добавить еще одну опцию JVM, где-то в районе 282-283 строки (в зависимости от версии, номер может и измениться), сразу после того, как скрипт закончил формировать $HADOOP_OPTS:

Продолжая статью “Использование Hadoop для решения реальных задач”, хочу напомнить, что в прошлой статье мы остановились на том, что посчитали такую характеристику как tf(t,d), и сказали, что в следующем посте мы будем считать idf(t) и завершим процесс вычисления значения TF-IDF для данного документа и термина. Поэтому предлагаю долго не откладывать и переходить к этой задаче.

Важно заметить, что idf(t) не зависит от документа, потому как считается на всем корпусе. Это нетрудно увидеть, посмотрев на формулу:



Вероятно, она нуждается в некоторых пояснениях. Итак, |D| это мощность корпуса документов — иными словами, просто количество документов. Мы знаем его, поэтому считать ничего не надо. Знаменатель же логарифма — это количество таких документов d которые содержат интересующий нас токен t_i.

Вчера я задал вопрос в своем ХабраБлоге — интересно ли людям узнать, что такое Hadoop с точки зрения его реального применения? Оказалось, интересно. Дело недолгое — статью я написал довольно быстро (по крайней мере, ее первую часть) — как минимум, потому, что уже давно знал, о чем собираюсь написать (потому как еще неплохо помню как я сам тыкался в поиске информации, когда начинал пользоваться Hadoop). В первой статье речь пойдет об основах — но совсем не о тех, про которые обычно рассказывают :-)

Перед прочтением статьи я настоятельно рекомендую изучить как минимум первый и последний источники из списка для чтения — их понимание или хотя бы прочтение практически гарантирует, что статья будет понята без проблем. Ну что, поехали?

Что такое Hadoop?

Ну скажите, какой смысл об этом писать? Уже не раз это проговаривалось, неоднократно начинали писаться посты на тему Hadoop, HDFS и прочая. К сожалению, обычно все заканчивалось на довольно пространном введении и фразе “Продолжение следует”. Так вот: это — продолжение. Кому-то тема, затрагиваемая в этой статье может показаться совершенно тривиальной и неинтересной, однако же лиха беда начало — любые сложные задачи надо решать по частям. Это утверждение, в частности, мы и реализуем в ходе статьи. Сразу замечу, что я постараюсь избежать написания кода в рамках этой конкретной статьи — это может подождать, а понять принципы построения программ, работающих с Map/Reduce можно и “на кошках” (к тому же с текущей частотой кардинального изменения API Hadoop любой код становится obsolete примерно через месяц).

Когда я начинал разбираться с Хадупом, очень большой сложностью лично для меня стало первоначальное понимание идеологии Map/Reduce (я предпочитаю писать это словосочетание именно так, чтобы подчеркнуть, что речь идет не о продукте, а о принципе). Суть и ценность метода станет понятна в самом конце — после того, как мы решим несложную задачу.

Инженер из компании Google весьма критически отозвался о технологиях Microsoft в области распределённой вычислительной инфраструктуры для веб-приложений.

Маленький скандальчик случился на конференции Structure 09, которая посвящена облачным вычислениям. Всё началось с выступления Наджама Ахмада (Najam Ahmad), главного менеджера по глобальным сетевым сервисам Microsoft. Он подробно рассказал, как Microsoft пытается увеличить производительность множества своих сервисов. Мол, проблема в огромном их количестве, так что невозможно подобрать настройки так, чтобы все эти сервисы одинаково эффективно работали на одной платформе. Приходится фрагментировать инфраструктуру, ставить разные серверы с разными настройками для отдельных приложений, таких как Messenger или Virtual Earth, и оптимизировать их по отдельности. Он подробно рассказал, как тщательно они сейчас оптимизируют Virtual Earth.

Сразу после этого слово взял Виджай Гилл (Vijay Gill), старший инженер по архитектуре из Google, и, как говорится, пропесочил конкурента по полной программе.

В дополнение к сервисам Amazon Elastic Compute Cloud (EC2) и Amazon Simple Storage Service (Amazon S3) компания Amazon сообщила об открытии нового сервиса Amazon Elastic MapReduce, который на данный момент пребывает в статусе беты.

Elastic MapReduce — вебсервис, который позволят с легкостью обрабатывать огромные количества разнообразных данных. Сервис основан на совместном использовании EC2 и S3, а также фреймворка Hadoop.

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

Специфика приложений и вычислительной инфраструктуры Google, построенной на огромном количестве недорогих серверов, с присущими им постоянными отказами, привело к разработке собственной закрытой распределенной файловой системы Google File System (GFS). Данная система нацелена на автоматическое восстановление после сбоев, высокую отказоустойчивость, высокую пропускную способность при доступе к данным в потоковом режиме. Система предназначена для работы с большими объемами данных, подразумевающих большие размеры хранимых файлов, поэтому GFS оптимизирована для соответствующих операций. В частности, в целях упрощения реализации и повышения эффективности GFS не реализует стандартный POSIX-интерфейс.

Ответом GFS стал open source проект Hadoop, с его Hadoop Distributed File System.

Маленькая поисковая фирма Zvents выпустила под свободной лицензией уникальную разработку — систему управления базами данных, которая легко распараллеливается на сотни машин. В роли серверов может использоваться стандартное дешёвое железо, оно в случае необходимости заменяется «на лету» без потери данных. Новая программа Hypertable теоретически рассчитана работать на кластере из 1000 узлов, хотя текущая альфа-версия 0.9 испытывалась только на десяти. Но тесты прошло отлично, а интерес к разработке уже проявила компания Yahoo. Дело в том, что в настоящее время в Hypertable используется файловая система Hadoop, ведущий разработчик которой работает как раз в Yahoo.

Руководители компании Zvents говорят, что они были вынуждены открыть свою программу в виде open source, потому что у них маленькая софтверная фирма и совершенно нет денег на инфраструктуру. Подобные СУБД коммерческого масштаба нужно испытывать на громадных кластерах.

Программа Hypertable создана по образцу известной базы данных Bigtable, которая используется в Google. Эта распределённая система, когда она была представлена на суд научной общественности в 2006 году, произвела настоящий фурор как одно из лучших изобретений в компьютерной области. Правда, там в качестве файловой системы используется запатентованная Google File System.