TOC

Введение в Hadoop

Вступление

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

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

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

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

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

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

  • Информация существует в разных местах (полевые тетради разных студентов)

  • Он собирается в систему (вводится вручную в электронную таблицу)

  • Он сохраняется (сохраняется на диске на компьютере в классе; полевые записные книжки могут быть скопированы или сохранены для проверки целостности данных)

  • Он анализируется (агрегируется, сортируется или иным образом манипулируется)

  • Отображаются обработанные данные (таблицы, диаграммы, графики)

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

Поисковые компании столкнулись с этой конкретной проблемой, когда веб-контент взорвался в эпоху Dot-com. В 2003 году Google выпустил свой влиятельный документThe Google File System, описывающий, как их проприетарное программное обеспечение обрабатывает хранение огромного количества данных, обрабатываемых их поисковой системой. За ним последовал отчет GoogleMapReduce: Simplified Data Processing on Large Clusters 2004 года, в котором подробно описывалось, как они упростили обработку таких больших объемов данных. Эти две статьи сильно повлияли на архитектуру Hadoop.

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

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

  1. Системы больших данных должны были принять этотdata would be distributed. Хранение набора данных по частям на кластере машин было неизбежным.

  2. Если кластеры стали основой хранилища, тогдаsoftware had to account for hardware failure, потому что отказ оборудования неизбежен, когда вы говорите о работе сотен или тысяч машин в кластере.

  3. Поскольку машиныwill выходят из строя, им нужен новый способ связи друг с другом. В повседневных вычислениях данных мы привыкли к какой-то конкретной машине, обычно идентифицируемой по IP-адресу или имени хоста, отправляющей конкретные данные на другую конкретную машину. Этоexplicit communication had to be replaced with implicit communication, где одна машина сообщает другой машине, что она должна обрабатывать определенные данные. В противном случае программисты столкнутся с проблемой проверки, по крайней мере, такой же большой, как сама проблема обработки данных.

  4. Наконец,computing would need to go to the data and process it on the distributed machines вместо перемещения огромных объемов данных по сети.

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

  1. HDFS: Распределенная файловая система Hadoop, отвечающая за хранение данных на нескольких машинах.

  2. MapReduce: Программная среда для обработки данных на месте и параллельно на каждой машине, а также для планирования задач, их мониторинга и повторного запуска неудачных.

HDFS 1.0

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

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

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

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

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

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

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

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

  • No Control over the Distributions of Blocks
    Шаблон блочной репликации HDFS является основой его высокой доступности. Это может быть очень эффективным и избавляет администраторов и разработчиков от необходимости заботиться о уровне блочного хранилища, но, поскольку он не учитывает использование пространства или ситуацию с узлами в реальном времени, администраторам кластера может потребоваться использовать утилиту балансировки перераспределить блоки.

  • The NameNode: A Single Point of Failure
    Более существенное ограничение, чем распределение блоков, NameNode представляет собой единственную точку отказа. Если происходит сбой процесса или компьютера, весь кластер будет недоступен до перезапуска сервера NameNode, и даже после перезапуска он должен получать сообщения пульса от каждого узла в кластере, прежде чем он станет фактически доступным, что продлевает время простоя, особенно при больших кластеры.

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

MapReduce 1.0

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

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

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

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

Мы проиллюстрируем это несколькими предложениями:

Она продает ракушки на шести берегах моря.
Она уверенно продает ракушки хорошо. 

MAPPING         SHUFFLING           REDUCING
{she, 1}        {she, 1, 1}         {she, 2}
{sells, 1}      {sells, 1, 1}       {sells, 2}
{seashells, 1}  {seashells, 1, 1}   {seashells, 2}
{by, 1}         {by, 1}             {by, 1}
{six, 1}        {six, 1}            {six, 1}
{seashores, 1}  {seashores, 1, 1}   {seashores, 2}
{she, 1}        {sure, 1}           {sure, 1}
{sure, 1}       {well, 1}           {well, 1}
{sells}
{seashells, 1}
{well, 1}

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

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

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

  • Tight coupling between MapReduce and HDFS
    В реализации 1.x обязанности уровня MapReduce выходят за рамки обработки данных, включают управление ресурсами кластера и тесно связаны с HDFS. Это означает, что разработчики надстроек для 1.x должны писать многоходовые программы MapReduce, независимо от того, подходит ли она для этой задачи или нет, потому что MapReduce является единственным способом доступа к файловой системе.

  • Static Slots for Data Analysis
    Отображение и сокращение выполняются на узлах данных, что является ключом к работе с большими данными, но на каждом узле данных доступно только ограниченное статическое количество одноцелевых слотов. Слоты сопоставления могут только отображаться, а уменьшенные слоты могут только уменьшаться. Номер задается в конфигурации без возможности динамической настройки, и они простаивают и поэтому теряются всякий раз, когда рабочая нагрузка кластера не соответствует конфигурации. Жесткость распределения слотов также затрудняет надлежащее планирование приложений, не относящихся к MapReduce.

  • The JobTracker: A Single Point of Failure
    Приложения Hadoop отправляют задачи MapReduce в JobTracker, который, в свою очередь, распределяет эти задачи по конкретным узлам кластера, находя TaskTracker либо с доступными слотами, либо географически рядом с данными. TaskTracker уведомляет JobTracker в случае сбоя задачи. JobTracker может повторно отправить задание, отметить запись, которая будет исключена из дальнейшей обработки, или, возможно, внести в черный список ненадежный TaskTracker, но в случае сбоя JobTracker по любой причине все задачи MapReduce будут остановлены.

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

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

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

Объединение HDFS обеспечивает четкое разделение между пространством имен и хранилищем, что делает возможным использование нескольких пространств имен в кластере. Это обеспечивает некоторые ключевые улучшения:

  • Namespace scalability Возможность добавлять больше NameNodes в кластер позволяет горизонтальное масштабирование. Большие кластеры или кластеры с большим количеством маленьких файлов могут выиграть от добавления дополнительных имен.

  • Performance gains Единственный NameNode с ограниченной пропускной способностью чтения / записи файловой системы 1.x. Несколько NameNode смягчают это ограничение для операций файловой системы.

  • Isolation between namespaces В многопользовательских средах с одним NameNode один шумный сосед мог повлиять на всех остальных пользователей системы. С федерацией стало возможным изолировать систему жителей.

Как работает HDFS Federation

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

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

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

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

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

Как работает NameNode HA

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

3 - пряжа

Hadoop 2.0 отделил MapReduce от HDFS. Управление рабочими нагрузками, многопользовательским режимом, средствами управления безопасностью и функциями высокой доступности были выделены в YARN (еще один посредник по согласованию ресурсов). По сути, YARN - это крупномасштабная распределенная операционная система для приложений с большими данными, которая делает Hadoop подходящим как для MapReduce, так и для других приложений, которые не могут дождаться завершения пакетной обработки. YARN избавил от необходимости работать с часто интенсивной I / O-инфраструктурой MapReduce с высокой задержкой, позволяющей использовать новые модели обработки с HDFS. Decoupled-MapReduce оставался пользовательской средой, предназначенной исключительно для выполнения задачи, для которой он предназначен: пакетной обработки.

Ниже приведены некоторые модели обработки, доступные пользователям Hadoop 2.x:

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

    Where batch processing shines: Индексирование данных, сканирование Интернета и обработка данных

    Some programs that can do this for Hadoop: MapReduce, Tez, Spark, Hive и Flink

  • Interactive Processing
    Системы интерактивной обработки необходимы, когда вы не знаете заранее все свои вопросы. Вместо этого пользователь интерпретирует ответ на запрос, а затем формулирует новый вопрос. Для поддержки такого рода исследования ответ должен быть возвращен гораздо быстрее, чем обычное задание MapReduce.

    Where interactive processing shines: Интерактивная обработка поддерживает исследование данных.

    Some programs that do this for Hadoop: Impala, Drill, HAWQ, Presto, Vortex и Vertica SQL, Tez

  • Stream Processing
    Системы потоковой обработки принимают большие объемы дискретных точек данных и выполняют непрерывный запрос для получения результатов почти в реальном времени по мере поступления новых данных в систему.

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

    Some programs that do this for Hadoop: Искровой поток, Буря

  • Graph Processing
    Графические алгоритмы обычно требуют связи между вершинами или переходов, чтобы переместить ребро из одной вершины в другую, что требует много ненужных накладных расходов при передаче через 1.x MapReduce.

    Where graphing shines: Графики идеально подходят для демонстрации нелинейных отношений между вещами: отношениями друзей Facebook, подписчиками Twitter, базами данных распределенных графиков, как в ядре сайтов социальных сетей.

    Some programs that do this for Hadoop: Apache Giraph, Apache Spark’s GraphX, Hama, Titan

Это лишь некоторые из альтернативных моделей обработки и инструментов. Полное руководство по экосистеме Hadoop с открытым исходным кодом, включая модели обработки, отличные от MapReduce, см. ВThe Hadoop Ecosystem Table

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

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

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

Hadoop 3.x

На момент написания этой статьи Hadoop 3.0.0-alpha1 был доступен для тестирования. Целью ветки 3.x является обеспечение таких улучшений, как кодирование стирания HDFS для экономии места на диске, усовершенствования службы временной шкалы YARN для повышения его масштабируемости, надежности и удобства использования, поддержка более двух имен узлов, балансировщик внутридатоданных и многое другое. Чтобы узнать больше, посетите обзорmajor changes.

Заключение

В этой статье мы рассмотрели, как Hadoop развивался для удовлетворения потребностей все более крупных наборов данных. Если вы хотите поэкспериментировать с Hadoop, вы можете взглянуть наInstalling Hadoop in Stand-Alone Mode on Ubuntu 16.04. Дополнительные сведения о концепциях больших данных в целом см. ВAn Introduction to Big Data Concepts and Terminology.

Related