Как расшифровывается hdfs что это такое

Hadoop Distributed File System

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

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

Ответом GFS стал open source проект Hadoop, с его Hadoop Distributed File System. Проект активно поддерживается и развивается компанией Yahoo (18 человек). Проведем сравнительный анализ терминов, используемых в данных системах, установим их соответствие и остановимся подробнее на HDFS:

HDFS — распределенная файловая система, используемая в проекте Hadoop. HDFS-кластер в первую очередь состоит из NameNоde-сервера и DataNode-серверов, которые хранят непосредственно данные. NameNode-сервер управляет пространством имен файловой системы и доступом клиентов к данным. Чтобы разгрузить NameNode-сервер, передача данных осуществляется только между клиентом и DataNode-сервером.

Secondary NameNode:

Основной NameNode-сервер фиксирует все транзакции, связанные с изменением метаданных файловой системы, в log-файле, называемом EditLog. При запуске основного NameNode-сервера, он считывает образ HDFS (расположенный в файле FsImage) и применяет к нему все изменения, накопленные в EditLog. Затем записывается новый образ уже с примененными изменениями, и система начинает работу уже с чистым log-файлом. Следует заметить, что данную работу NameNode-сервер выполняет единожды при его первом запуске. В последующем, подобные операции возлагаются на вторичный NameNode-сервер. FsImage и EditLog в конечном итоге хранятся на основном сервере.

Механизм репликации:

При обнаружении NameNode-сервером отказа одного из DataNode-серверов (отсутствие heartbeat-сообщений от оного), запускается механизм репликации данных:

— выбор новых DataNode-серверов для новых реплик
— балансировка размещения данных по DataNode-серверам

Аналогичные действия производятся в случае повреждении реплик или в случае увеличения количества реплик присущих каждому блоку.

Стратегия размещение реплик:

Данные хранятся в виде последовательности блоков фиксированного размера. Копии блоков (реплики) хранятся на нескольких серверах, по умолчанию — трех. Их размещение происходит следующим образом:

— первая реплика размещается на локальном ноде
— вторая реплика на другой ноде в этой же стойке
— третья реплика на произвольной ноде другой стойки
— остальные реплики размещаются произвольным способом

При чтении данных клиент выбирает ближайшую к нему DataNode-сервер с репликой.

Целостность данных:

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

Запись данных:

«При записи данных в HDFS используется подход, позволяющий достигнуть высокой пропускной способности. Приложение ведет запись в потоковом режиме, при этом HDFS-клиент кэширует записываемые данные во временном локальном файле. Когда в файле накапливаются данные на один HDFS-блок, клиент обращается к NameNode-серверу, который регистрирует новый файл, выделяет блок и возвращает клиенту список datanode-серверов для хранения реплик блока. Клиент начинает передачу данных блока из временного файла первому DataNode-серверу из списка. DataNode-сервер сохраняет данные на диске и пересылает следующему DataNode-серверу в списке. Таким образом, данные передаются в конвейерном режиме и реплицируются на требуемом количестве серверов. По окончании записи, клиент уведомляет NameNode-сервер, который фиксирует транзакцию создания файла, после чего он становится доступным в системе»

Удаление данных:

В силу обеспечения сохранности данных (на случай отката операции), удаление в файловой системе происходит по определенной методике. Вначале файл перемещается в специально отведенную для этого /trash директорию, а уже после истечения определенного времени, происходит его физическое удаление:

— удаление файла из пространства имен HDFS
— освобождение связанных с данными блоков

Текущие недостатки:

— отсутствие автоматического запуска главного сервера в случае его сбоя (данная функциональность реализована в GFS)
— отсутствие операций append (предполагается в версии 0.19.0) и snapshot (данные функциональности также реализованы в GFS)

Почитать, что будет в следующих версиях HDFS можно в вики проекта на сайте Apache Foundation. Дополнительную информацию и мнения людей работающих с Hadoop можно найти в блогах компаний активно использующих данную технологию: Yahoo, A9, Facebook, Last.fm, Laboratory

Источники:

— Dhruba B. Hadoop Distributed File System, 2007
— Tom W. A Tour of Apache Hadoop
— Sanjay Ghemawat, Howard Gobioff, and Shun-Tak Leung The Google File System
— Сухорослов О.В. Новые технологии распределенного хранения и обработки больших массивов данных

Источник

Hadoop: введение в системы больших данных

Apache Hadoop – один из важнейших открытых инструментов для хранения и обработки большого количества цифровых данных, накопленных с ростом World Wide Web. Он развился из открытого проекта под названием Nutch, который предназначался для поиска в Интернете. Создатели Nutch были в большой степени подвержены влиянию Google. В конечном итоге функции хранения и обработки были выделены в проект Hadoop, а Nutch разрабатывается как инструмент поиска.

Данная статья расскажет, что такое системы больших данных.

Системы данных

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

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

Этот проект хорошо иллюстрирует систему данных:

Этот проект – очень простой пример системы данных. Один компьютер может хранить, анализировать и отображать ежедневные измерения уровня воды в одном ручье. А теперь представьте весь контент на всех веб-страницах в мире – несоизмеримо больший набор данных. Это большие данные: столько информации не может поместиться на одном компьютере.

Чем отличаются большие данные?

Статьи Google и реализация этих идей в Hadoop основаны на четырех изменениях в восприятии данных, которые необходимы для учета объема данных:

Выпущенная в 2007 году версия 1.0 основанного на Java фреймвока Hadoop стала первым открытым проектом, который учитывал все эти изменения. Его первая версия состоит из двух уровней:

HDFS 1.0

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

Как работает HDFS 1.0?

Для надежного хранения очень больших файлов на нескольких компьютерах HDFS использует блочную репликацию на основе двух компонентов программного обеспечения: это сервер NameNode, который управляет пространством имен файловой системы и доступом клиентов, а также DataNodes, ответственный за выполнение запросов на чтение и запись, создание блоков, удаление и репликацию. Базовое понимание шаблона репликации полезно для разработчиков и администраторов кластеров, поскольку дисбаланс в распределении данных может повлиять на производительность кластера и потребовать дополнительной настройки.

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

NameNode принимает все решения о репликации блоков на основе алгоритма пульсации и отчетов, которые он получает от каждого DataNode в кластере. Алгоритм пульсации позволяет убедиться, что DataNode работает, а отчет о блоках предоставляет список всех блоков в DataNode.

Когда создается новый блок, HDFS помещает первую реплику на ноду, где выполняется запись. Вторая реплика сохраняется на случайно выбранной ноде в этом же раке (это не может быть та же нода, где была записана первая реплика). Затем третья реплика помещается на случайно выбранную машину о втором раке. Если в конфигурации указано больше трех реплик (по умолчанию), оставшиеся реплики помещаются случайным образом, при этом действует такое ограничение: не более одной реплики на ноду, не более двух реплик на рак.

Ограничения HDFS 1.0

HDFS 1.0 сделал Hadoop лидером среди открытых инструментов для хранения больших данных. Отчасти этот успех был вызван решениями в архитектуре, которые упростили распределенное хранение. Но при этом ограничения оставались. К основным ограничениям версии 1.0 относятся:

Несмотря на эти ограничения, HDFS сделал большой вклад в работу с большими данными.

MapReduce 1.0

Второй уровень Hadoop – MapReduce – отвечает за пакетную обработку данных, хранящихся на HDFS. Внедрение в Hadoop модели Google MapReduce позволяет разработчикам использовать ресурсы HDFS без параллельных и распределенных систем.

Как работает MapReduce 1.0

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

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

Давайте рассмотрим, как это работает на таком примере:

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

Компоненты более высокого уровня могут подключаться к MapReduce для предоставления дополнительных функций. Например, Apache Pig предоставляет разработчикам язык для написания программ анализа данных, абстрагируя идиомы Java MapReduce на более высокий уровень (аналогично тому, что делает SQL для реляционных баз данных). Apache Hive поддерживает анализ данных и отчетность с помощью SQL-подобного интерфейса для HDFS. Он абстрагирует запросы MapReduce Java API для обеспечения функциональности запросов высокого уровня. Для Hadoop 1.x доступно множество дополнительных компонентов, но экосистема MapReduce также имеет некоторые ограничения.

Ограничения MapReduce 1

Улучшения в Hadoop 2.x

Ветка Hadoop 2.х, выпущенная в декабре 2011 года, представила четыре основных усовершенствования и исправила ключевые ограничения версии 1. Hadoop 2.0 устраняет ограничение производительности и единую точку отказа NameNode. Кроме того, он отделяет MapReduce от HDFS с введением YARN (Yet Another Resource Negotiator), открыв экосистему дополнительных продуктов и разрешив моделям обработки взаимодействовать с HDFS и обходить слой MapReduce.

1: Федерация HDFS

Федерация HDFS вводит четкое разделение пространства имен и хранилища, что делает возможным наличие нескольких пространств имен в кластере. Благодаря этому появляются такие улучшения:

Как работает федерация HDFS

Федерация управляет пространством имен файловой системы. NameNodes работают независимо и не координируются друг с другом. DataNodes регистрируются в кластере с каждым NameNode, отправляют пульс и отчеты блоков и обрабатывают входящие команды из NameNode.

Блоки распространяются по всему хранилищу с той же случайной репликацией, что и в Hadoop 1.x. Все блоки, принадлежащие одному пространству имен, называются пулом блоков. Такие пулы управляются независимо, позволяя пространству имен генерировать идентификаторы блоков для новых блоков без согласования с другими пространствами имен. Комбинация пространства имен и пула блоков называется томом пространства имен; том формирует автономный блок, так что когда один из NameNode удаляется, его пул блоков удаляется вместе с ним.

Помимо улучшенной масштабируемости, производительности и изоляции, Hadoop 2.0 также обеспечил высокую доступность NameNodes.

2: Высокая доступность NameNode

Если в предыдущих версиях NameNode прекращал работу, весь кластер был недоступен, пока NameNode не перезапустится или не появится на новом компьютере. Модернизация программного или аппаратного обеспечения NameNode также создавала окна простоя. Чтобы предотвратить это, Hadoop 2.0 реализовал конфигурацию active/passive, чтобы обеспечить быстрый переход на другой ресурс.

Как работает высокая доступность NameNode

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

3: YARN

Hadoop 2.0 отделяет MapReduce от HDFS. Управление рабочими нагрузками, многоуровневым обслуживанием, безопасностью и функциями высокой доступности было выделено в YARN (Yet Another Resource Negotiator). YARN – это, по сути, крупномасштабная распределенная операционная система для приложений больших данных, которая позволяет использовать Hadoop как для MapReduce, так и для других приложений, которые не могут дождаться завершения пакетной обработки. YARN устранил необходимость работы через инфраструктуру MapReduce с высокой задержкой ввода-вывода, что позволяет использовать новые модели обработки HDFS.

У пользователей Hadoop 2.x есть доступ к таким моделям обработки.

Это лишь несколько альтернативных моделей и инструментов обработки. Подробное руководство по экосистеме Hadoop можно найти здесь.

4: Высокая доступность ResourceManager

В первом релизе YARN было свое узкое место: ResourceManager. Единственный JobTracker в MapReduce 1.x обрабатывал управление ресурсами, планирование задач и мониторинг работы. Ранние релизы YARN улучшили это, разделив обязанности между глобальным ResourceManager и ApplicationMaster для каждого приложения. ResourceManager отслеживал ресурсы кластера и планировал приложения, такие как MapReduce Jobs, но был единственной точкой отказа до версии 2.4, в которой была представлена архитектура Active/Standby.

В Hadoop 2.4 единый ResourceManager был заменен одним активным ResourceManager и одним или несколькими резервными. В случае сбоя активного ResourceManager администраторы могут вручную активировать один из менеджеров. Чтобы обеспечить автоматический переход на другой ресурс, можно добавить в свой стек Apache Zookeeper. Помимо прочих обязанностей по координации задач, Zookeeper может отслеживать состояние нод YARN и в случае сбоя автоматически запускать переход в режим ожидания.

Источник

Как расшифровывается hdfs что это такое

HDFS (Hadoop Distributed File System) – это распределенная файловая система, которая предназначена для хранения данных больших размеров данных, которые поблочно разделены между узлами вычислительного кластера.

Как устроена HDFS: основные свойства

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

Схема хранения данных в HDFS

Файловая система HDFS имеет следующие свойства:

Как появилась и развивалась HDFS: краткая история

Самый первый проектный документ для HDFS был написан в 2007 году Дхрубой Бортакуром. Однако разработка началась в еще начале 2005 года Дугом Катингом в рамках проекта для распределенных вычислений Nutch. В январе 2008 года проект Hadoop становится проектом верхнего уровня системы проектов Apache Software Foundation. Как полноценная файловая система, HDFS вышла 10 декабря 2011 года в рамках версии Hadoop 1.0. В мае 2012 года в HDFS добавлены возможности высокой доступности, что позволило узлу имен вручную переключаться на резервные копии.

Таким образом, благодаря своей высокой отказоустойчивости, HDFS является весьма эффективным средством хранения больших массивов данных в распределенной среде. Именно поэтому HDFS является неотъемлемой частью фреймворков экосистемы Hadoop, таких как Spark, Hive, Pig и других технологий работы с большими данными. Прочие направления Big Data, в т.ч. Data Science, включая подготовку и анализ данных, а также аналитические системы на базе алгоритмов машинного обучения (Machine Learning), также активно используют Hadoop Distributed File System.

Источник

Как расшифровывается hdfs что это такое

HDFS (Hadoop Distributed File System) — распределенная файловая система Hadoop для хранения файлов больших размеров с возможностью потокового доступа к информации, поблочно распределённой по узлам вычислительного кластера [1], который может состоять из произвольного аппаратного обеспечения [2]. Hadoop Distributed File System, как и любая файловая система – это иерархия каталогов с вложенными в них подкаталогами и файлами [3].

Применение Hadoop Distributed File System

HDFS – неотъемлемая часть Hadoop, проекта верхнего уровня Apache Software Foundation, и основа инфраструктуры больших данных (Big Data). Однако, Hadoop поддерживает работу и с другими распределёнными файловыми системами, в частности, Amazon S3 и CloudStore. Также некоторые дистрибутивы Hadoop, например, MapR, реализуют свою аналогичную распределенную файловую систему – MapR File System [1].

HDFS может использоваться не только для запуска MapReduce-заданий, но и как распределённая файловая система общего назначения, обеспечивая работу распределённых СУБД (HBase) и масштабируемых систем машинного обучения (Apache Mahout) [1].

Архитектура HDFS

Кластер HDFS включает следующие компоненты [3]:

Взаимодействие узлов имен, узлов данных и клиентов осуществляется по протоколам на основе TCP/IP.

Отличительные характеристики распределенной файловой системы хадуп

Благодаря репликации блоков по узлам данных, распределенная файловая система Hadoop обеспечивает высокую надежность хранения данных и скорость вычислений. Кроме того, HDFS обладает рядом отличительных свойств [4]:

В связи с особенностями архитектуры и принципом действия, для HDFS характерны следующие недостатки [3]:

Подробно о том, как работает HDFS, читайте в нашей отдельных статьях: взаимодействие компонентов и файловые операции (запись, чтение, удаление и репликации).

Практика работы с HDFS, настройка, администрирование и использование всей инфраструктуры Hadoop для больших данных и машинного обучения на наших компьютерных курсах для пользователей, инженеров, администраторов и аналитиков Big Data и Machine Learning в Москве:

Источник

Hadoop: что, где и зачем

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

Поставщики: Apache, Cloudera, Hortonworks, MapR

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

Cloudera. Ключевой продукт — CDH (Cloudera Distribution including Apache Hadoop) — связка наиболее популярных инструментов из инфраструктуры Hadoop под управлением Cloudera Manager. Менеджер берёт на себя ответсвенность за развёртывание кластера, установку всех компонентов и их дальнейший мониторинг. Кроме CDH компания развивает и другие свои продукты, например, Impala (об этом ниже). Отличительной чертой Cloudera также является стремление первыми предоставлять на рынке новые фичи, пусть даже и в ущерб стабильности. Ну и да, создатель Hadoop — Doug Cutting — работает в Cloudera.

Hortonworks. Так же, как и Cloudera, они предоставляют единое решение в виде HDP (Hortonworks Data Platform). Их отличительной чертой является то, что вместо разработки собственных продуктов они больше вкладывают в развитие продуктов Apache. Например, вместо Cloudera Manager они используют Apache Ambari, вместо Impala — дальше развивают Apache Hive. Мой личный опыт с этим дистрибутивом сводится к паре тестов на виртуальной машине, но по ощущениями HDP выглядит стабильней, чем CDH.

MapR. В отличие от двух предыдущих компаний, основным источником доходов для которых, судя по всему, является консалтинг и партнёрские программы, MapR занимается непосредственно продажей своих наработок. Из плюсов: много оптимизаций, партнёрская программа с Amazon. Из минусов: бесплатная версия (M3) имеет урезанный функционал. Кроме того, MapR является основным идеологом и главным разработчиком Apache Drill.

Фундамент: HDFS

Когда мы говорим про Hadoop, то в первую очередь имеем в виду его файловую систему — HDFS (Hadoop Distributed File System). Самый простой способ думать про HDFS — это представить обычную файловую систему, только больше. Обычная ФС, по большому счёту, состоит из таблицы файловых дескрипторов и области данных. В HDFS вместо таблицы используется специальный сервер — сервер имён (NameNode), а данные разбросаны по серверам данных (DataNode).

В остальном отличий не так много: данные разбиты на блоки (обычно по 64Мб или 128Мб), для каждого файла сервер имён хранит его путь, список блоков и их реплик. HDFS имеет классическую unix-овскую древовидную структуру директорий, пользователей с триплетом прав, и даже схожий набор консольных комманд:

Почему HDFS так крута? Во-первых, потому что она надёжна: как-то при перестановке оборудования IT отдел случайно уничтожил 50% наших серверов, при этом безвозвратно было потеряно всего 3% данных. А во-вторых, что даже более важно, сервер имён раскрывает для всех желающих расположение блоков данных на машинах. Почему это важно, смотрим в следующем разделе.

Движки: MapReduce, Spark, Tez

При правильной архитектуре приложения, информация о том, на каких машинах расположены блоки данных, позволяет запустить на них же вычислительные процессы (которые мы будем нежно называть англицизмом «воркеры») и выполнить большую часть вычислений локально, т.е. без передачи данных по сети. Именно эта идея лежит в основе парадигмы MapReduce и её конкретной реализации в Hadoop.

Классическая конфигурация кластера Hadoop состоит из одного сервера имён, одного мастера MapReduce (т.н. JobTracker) и набора рабочих машин, на каждой из которых одновременно крутится сервер данных (DataNode) и воркер (TaskTracker). Каждая MapReduce работа состоит из двух фаз:

На самом деле между этими фазами есть ещё фаза combine, которая делает то же самое, что и reduce, но над локальными блоками данных. Например, представим, что у нас есть 5 терабайт логов почтового сервера, которые нужно разобрать и извлечь сообщения об ошибках. Строки независимы друг от друга, поэтому их разбор можно переложить на задачу map. Дальше с помощью combine можно отфильтровать строки с сообщением об ошибке на уровне одного сервера, а затем с помощью reduce сделать то же самое на уровне всех данных. Всё, что можно было распараллелить, мы распараллелили, и кроме того минимизировали передачу данных между серверами. И даже если какая-то задача по какой-то причине упадёт, Hadoop автоматически перезапустит её, подняв с диска промежуточные результаты. Круто!

Проблема в том, что большинство реальных задач гораздо сложней одной работы MapReduce. В большинстве случаев мы хотим делать параллельные операции, затем последовательные, затем снова параллельные, затем комбинировать несколько источников данных и снова делать параллельные и последовательные операции. Стандартный MapReduce спроектирован так, что все результаты — как конечные, так и промежуточные — записываются на диск. В итоге время считывания и записи на диск, помноженное на количество раз, которые оно делается при решении задачи, зачастую в несколько (да что там в несколько, до 100 раз!) превышает время самих вычислений.

И здесь появляется Spark. Спроектированный ребятами из университета Berkeley, Spark использует идею локальности данных, однако выносит большинство вычислений в память вместо диска. Ключевым понятием в Spark-е является RDD (resilient distributed dataset) — указатель на ленивую распределённую колекцию данных. Большинство операций над RDD не приводит к каким-либо вычислениям, а только создаёт очередную обёртку, обещая выполнить операции только тогда, когда они понадобятся. Впрочем, это проще показать, чем рассказать. Ниже приведён скрипт на Python (Spark из коробки поддерживает интерфейсы для Scala, Java и Python) для решения задачи про логи:

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

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

Но не Spark-ом единым. Компания Hortonworks решила сделать упор на альтернативный движок — Tez. Tez представляет задачу в виде направленного ациклического графа (DAG) компонентов-обработчиков. Планировщик запускает вычисление графа и при необходимости динамически переконфигурирует его, оптимизируя под данные. Это очень естественная модель для выполнения сложных запросов к данным, таких как SQL-подобные скрипты в Hive, куда Tez принёс ускорение до 100 раз. Впрочем, кроме Hive этот движок пока мало где используется, поэтому сказать, насколько он пригоден для более простых и распространённых задач, довольно сложно.

SQL: Hive, Impala, Shark, Spark SQL, Drill

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

Hive — самая первая и до сих пор одна из самых популярных СУБД на этой платформе. В качестве языка запросов использует HiveQL — урезанный диалект SQL, который, тем не менее, позволяет выполнять довольно сложные запросы над данными, хранимыми в HDFS. Здесь надо провести чёткую линию между версиями Hive Личный опыт

NoSQL: HBase

Несмотря на популярность SQL решений для аналитики на базе Hadoop, иногда всё-таки приходится бороться с другими проблемами, для которых лучше приспособлены NoSQL базы. Кроме того, и Hive, и Impala лучше работают с большими пачками данных, а чтение и запись отдельных строк почти всегда означает большине накладные расходы (вспомним про размер блока данных в 64Мб).

И здесь на помощь приходит HBase. HBase — это распределённая версионированная нереляционная СУБД, эффективно поддерживающая случайное чтение и запись. Здесь можно рассказать про то, что таблицы в HBase трёхмерные (строковый ключ, штамп времени и квалифицированное имя колонки), что ключи хранятся отсортированными в лексиграфическом порядке и многое другое, но главное — это то, что HBase позволяет работать с отдельными записями в реальном времени. И это важное дополнение к инфраструктуре Hadoop. Представьте, например, что нужно хранить информацию о пользователях: их профили и журнал всех действий. Журнал действий — это классический пример аналитических данных: действия, т.е. по сути, события, записываются один раз и больше никогда не изменяются. Действия анализируются пачками и с некоторой периодичностью, например, раз в сутки. А вот профили — это совсем другое дело. Профили нужно постоянно обновлять, причём в реальном времени. Поэтому для журнала событий мы используем Hive/Impala, а для профилей — HBase.

При всём при этом HBase обеспечивает надёжное хранение за счёт базирования на HDFS. Стоп, но разве мы только что не сказали, что операции случайного доступа не эффективны на этой файловой системе из-за большого размера блока данных? Всё верно, и в этом большая хитрость HBase. На самом деле новые записи сначала добавляются в отсортированную структуру в памяти, и только при достижении этой структурой определённого размера сбрасываются на диск. Консистентность при этом поддерживается за счёт write-ahead-log (WAL), который пишется сразу на диск, но, естественно, не требует поддержки отсортированных ключей. Подробнее об этом можно прочитать в блоге компании Cloudera.

Ах да, запросы к таблицам HBase можно делать напрямую из Hive и Impala.

Импорт данных: Kafka

Обычно импорт данных в Hadoop проходит несколько стадий эволюции. Вначале команда решает, что обычных текстовых файлов будет достаточно. Все умеют писать и читать CSV файлы, никаких проблем быть не должно! Затем откуда-то появляются непечатные и нестандартные символы (какой мерзавец их вставил!), проблема экранирования строк и пр., и приходится перейти на бинарные форматы или как минимум переизбыточный JSON. Затем появляется два десятка клиентов (внешних или внутренних), и не всем удобно посылать файлы на HDFS. В этот момент появляется RabbitMQ. Но держится он недолго, потому что все вдруг вспоминают, что кролик старается всё держать в памяти, а данных много, и не всегда есть возможность их быстро забрать.

И тогда кто-то натыкается на Apache Kafka — распределённую систему обмена сообщениями с высокой пропускной способностью. В отличие от интерфейса HDFS, Kafka предоставляет простой и привычный интерфейс передачи сообщений. В отличие от RabbitMQ, он сразу пишет сообщения на диск и хранит там сконфигурированный период времени (например, две недели), в течение которого можно прийти и забрать данные. Kafka легко масштабируется и теоретически может выдеражать любой объём данных.

Вся эта прекрасная картина рушится, когда начинаешь пользоваться системой на практике. Первое, что нужно помнить при обращении с Kafka, это то, что все врут. Особенно документация. Особенно официальная. Если авторы пишут «у нас поддерживается X», то зачастую это значит «мы бы хотели, чтобы у нас поддерживалось X» или «в будущих версиях мы планиуем поддержку X». Если написано «сервер гарантирует Y», то скорее всего это значит «сервер гарантирует Y, но только для клиента Z». Бывали случаи, когда в документации было написано одно, в комментарии к функции другое, а в самом коде — третье.

Kafka меняет основные интерфейсы даже в минорных версиях и уже долгое время не может совершить переход от 0.8.x к 0.9. Сам же исходный код, как структурно, так и на уровне стиля, явно написан под влиянием знаменитого писателя, давшего название этому чудовищу.

Простой рецепт, к которому мы постепенно пришли, это запускать по одному потребителю на партицию очереди (topic, в терминологии Kafka) и вручную контролировать сдвиги.

Потоковая обработка: Spark Streaming

Если вы дочитали до этого абзаца, то вам, наверное, интересно. А если вам интересно, то вы, наверное, слышали про лямбда-архитектуру, но я на всякий случай повторю. Лямбда-архитектура предполагает дублирование конвеера вычислений для пакетной и потоковй обработки данных. Пакетная обработка запускается периодически за прошедший период (например, за вчера) и использует наиболее полные и точные данные. Потоковая обработка, напротив, производит рассчёты в реальном времени, но не гарантирует точности. Это бывает полезно, например, если вы запустили акцию и хотите отслеживать её эффективность ежечасно. Задержка в день здесь неприемлима, а вот потеря пары процентов событий не критична.

За потоковую обработку данных в экосистеме Hadoop-а отвечает Spark Streaming. Streaming из коробки умеет забирать данные из Kafka, ZeroMQ, сокета, Twitter и др… Разработчику при этом предоставляется удобный интерфейс в ввиде DStream — по сути, коллекции небольших RDD, собранной из потока за фиксированный промежуток времени (например, за 30 секунд или 5 минут). Все плюшки обычных RDD при этом сохраняются.

Машинное обучение

Картинка выше прекрасно выражает состояние многих компаний: все знают, что большие данные — это хорошо, но мало кто реально понимает, что с ними делать. А делать с ними нужно в первую очередь две вещи — переводит в знания (читать как: использовать при принятии решений) и улучшать алгоритмы. С первым уже помогают инструменты аналитики, а второе сводится к машинному обучению. В Hadoop для этого есть два крупных проекта:

Mahout — первая большая библиотека, реализовавшая многие популярные алгоритмы средствами MapReduce. Включает в себя алгоритмы для кластеризации, коллаборативной фильтрации, случайных деревьев, а также несколько примитивов для факторизации матриц. В начале этого года организаторы приняли решение перевести всё на вычислительное ядро Apache Spark, которое гораздо лучше поддерживает итеративные алгоритмы (попробуйте прогнать 30 итераций градиентного спуска через диск при стандартном MapReduce!).

MLlib. В отличие от Mahout, который пытается перенести свои алгоритмы на новое ядро, MLlib изначально является подпроектом Spark. В составе: базовая статистика, линейная и логистическая регрессия, SVM, k-means, SVD и PCA, а также такие примитивы оптимизации как SGD и L-BFGS. Scala интерфейс использует для линейной алгебры Breeze, Python интерфейс — NumPy. Проект активно развивается и с каждым релизом значительно прибавляет в функционале.

Форматы данных: Parquet, ORC, Thrift, Avro

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

Parquet — колончатый формат, оптимизированный для хранения сложных структур и эффективного сжатия. Изначально был разработан в Twitter, а сейчас является одним из основных форматов в инфраструктуре Hadoop (в частности, его активно поддерживают Spark и Impala).

ORC — новый оптимизированный формат хранения данных для Hive. Здесь мы снова видим противостояние Cloudera c Impala и Parquet и Hortonworks с Hive и ORC. Интересней всего читать сравнение производительности решений: в блоге Cloudera всегда побеждает Impala, причём со значительным перевесом, а в блоге Hortonworks, как несложно догадаться, побеждает Hive, причём с не меньшим перевесом.

Thrift — эффективный, но не очень удобный бинарный формат передачи данных. Работа с этим форматом предполагает определение схемы данных и генерацию соответсвующего кода клинета на нужном языке, что не всегда возможно. В последнее время от него стали отказываться, но многие сервисы всё ещё используют его.

Avro — в основном позиционируется как замена Thrift: он не требует генерации кода, может передавать схему вместе с данными или вообще работать с динамически типизированными объектами.

Прочее: ZooKeeper, Hue, Flume, Sqoop, Oozie, Azkaban

Ну и напоследок коротко о других полезных и бесполезных проектах.

ZooKeeper — главный инструмент координации для всех элементов инфраструктуры Hadoop. Чаще всего используется как сервис конфигурации, хотя его возможности гораздо шире. Простой, удобный, надёжный.

Hue — веб-интерфейс к сервисам Hadoop, часть Cloudera Manager. Работает плохо, с ошибками и по настроению. Пригоден для показа нетехническим специалистам, но для серьёзной работы лучше использовать консольные аналоги.

Flume — сервис для организации потоков данных. Например, можно настроить его для получения сообщений из syslog, агрегации и автоматического сбрасывания в директорию на HDFS. К сожалению, требует очень много ручной конфигурации потоков и постоянного расширения собственными Java классами.

Sqoop — утилита для быстрого копирования данных между Hadoop и RDBMS. Быстрого в теории. На практике Sqoop 1 оказался, по сути, однопоточным и медленным, а Sqoop 2 на момент последнего теста просто не заработал.

Oozie — планировщик потоков задач. Изначально спроектирован для объединения отдельных MapReduce работ в единый конвеер и запуска их по расписанию. Дополнительно может выполнять Hive, Java и консольные действия, но в контексте Spark, Impala и др., этот список выглядит довольно бесполезным. Очень хрупкий, запутанный и практически не поддаётся отладке.

Azkaban — вполне годная замена Oozie. Является частью Hadoop-инфраструктуры компании LinkedIn. Поддерживает несколько типов действий, главное из которых — консольная команда (а что ещё надо), запуск по расписанию, логи приложений, оповещения об упавших работах и др. Из минусов — некоторая сыроватость и не всегда понятный интерфейс (попробуйте догадаться, что работу нужно не создавать через UI, а заливать в виде zip-архива с текстовыми файлами).

Источник