Hadoop и автоматизация: Часть 1

    Привет, коллеги!

    Последние пару недель я трудился над интереснейшим (с моей точки зрения) занятием, которое представляло собой создание Hadoop-as-a-Service решения для приватного облака нашей компании. В первую очередь мне было интересно, что же за зверь Hadoop, почему так часто сейчас слышны сочетания слов Big Data и Hadoop. Для меня знакомство с Hadoop началось с чистого листа. Конечно же, я не являлся и не явлюясь Big Data специалистом, посему вдавался в суть на столько, на сколько необходимо было для понимания процессов в разрезе автоматизации развертывания кластера.

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

    Архитектура кластера


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

    Как позже я понял — достаточно простая архитектура "голого" кластера (без Hbase, Hive, Pig и прочих сторонних продуктов, относящихся к Hadoop). Но, на первый взгляд — все было непонятно. Ну что ж, Google в помощь, и вот что оказалось в итоге…

    Hadoop кластер можно поделить на 3 части: Masters, Slaves и Clients.
    Masters контролируют две основных функции кластера — размещение данных и вычисления/процессинг, связанные с этими данными.
    За размещение данных отвечает HDFSHadoop Distributed File System — представленная в нашей архитектуре NameNode и JournalNode.
    За координацию выдачи заданий и проведения распределенных вычислений отвечает YARN, также известный как MapReduce v.2.

    Slaves выполняют всю "грязную" работу, именно они получают и выполняют задания, связанные с вычислениями. Каждый Slave состоит из HDFS-части (DataNode) и YARN-части (NodeManager) соответственно. Каждая часть отвечает за соответствующую функцию, будь то распределенное хранение данных или распределенные вычисления.

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

    Hadoop написан на Java, поэтому любой из компонентов требует ее наличия. Взаимодействие между частями кластера сокрыто в недрах Java-классов, нам же доступна только часть настройки кластера путем внесения нужных настроек в нужное место.
    По умолчанию, файлы настройки находятся по пути /etc/hadoop/conf и представляют собой параметры, которые можно переназначить в кластере:
    • hadoop-env.sh и yarn-env.sh — содержит специфические настройки переменных окружения, именно сюда рекомендуется выносить настройки путей и опций, необходимых Hadoop;
    • core-site.xml — содержит значения, которые могут быть переназначены вместо значений по умолчанию для кластера, такие как адрес корневой ФС, указания различных директорий для Hadoop и т.п.;
    • hdfs-site.xml — содержит настройки для HDFS, а именно для NameNode, DataNode, JournalNode, а также для Zookeeper, такие как доменные имена и порты, на которых запущен тот или иной сервис, либо директории, необходимые для сохранения распределенных данных;
    • yarn-site.xml — содержит настройки для YARN, а именно для ResourceManager и NodeManager, такие как доменные имена и порты, на которых запущен тот или иной сервис, настройки распределения ресурсов для процессинга и т.п.;
    • mapred-site.xml — содержит конфигурацию для MapReduce заданий, а также настройки для JobHistory MapReduce сервера;
    • log4j.properties — содержит конфигурацию процесса логирования при помощи Apache Commons Logging framework;
    • hadoop-metrics.properties — указывает куда Hadoop будет отправлять свои метрики, будь то файл или система мониторинга;
    • hadoop-policy.xml — настройки Security и ACL для кластера;
    • capacity-scheduler.xml — настройки для CapacityScheduler, который отвечает за планирование задач и постановку их в очереди исполнения, а также распределение ресурсов кластера по очередям;

    Соответственно, для нашего процесса автоматизации, необходима не только автоматизированная установка, но и возможность изменения и составления данной конфигурации без фактического ее редактирования на узлах.
    Кластер разворачивался на Ubuntu с использованием HortonWorks (HDP) дистрибутива версии 2.0.*.
    Для создания кластера были выделены по 1 виртуальной машине на каждую часть Masters, 1 виртуальная машина Clients и 2 виртуальных машины как Slaves.
    При написании wrapper cookbook-а я использовал наработки Community, а именно данный проект Chris Gianelloni, который оказался очень активным разработчиком, быстро реагирующим на найденные баги в cookbook-e. Этот cookbook предоставлял возможность установки различных частей Hadoop-кластера, базовой конфигурации кластера путем установки атрибутов cookbook-а и генерации файлов конфигурации на их основании, а также верификации наличия достаточной конфигурации для запуска кластера.

    Автоматизация развертывания Clients


    Clients — это виртуальные машины, которые предоставляют данные и задачи для Hadoop кластера, а также снимают результаты распределенных вычислений.
    После добавления в репозитории Ubuntu записей о HortonWorks repo — стали доступны различные собранные deb пакеты, отвечающие за те или иные части кластера.
    Нас, в данном случае, интересовал пакет hadoop-client, установка которого осуществлялась следующим образом:
    package "hadoop-client" do
      action :install
    end
    

    Просто? Проще не бывает, спасибо коллегам из HortonWorks, которые избавили системных администраторов от необходимости сборки Hadoop из исходников.
    Конфигурация исключительно для Clients не нужна, они опираются на конфигурации для Masters/Slaves (о том, как реализован процесс создания конфигурационных файлов на основе атрибутов — в следующей статье).
    В итоге, после завершения установки, мы получим возможность отправки заданий для нашего кластера. Задания описываются в .jar-файлах посредством использования классов Hadoop. Примеры запуска заданий я постараюсь описать в конце цикла статей, когда наш кластер будет полностью работоспособен.
    Результаты работы кластера складываются в директории, указанные при запуске задания либо в конфигурационных файлах.
    Что должно происходить дальше? Далее, после того, как мы отправляем задание в наш кластер, наши Masters должны получить задание (YARN) и файлы (HDFS), необходимые для выполнения оного, и произвести процесс дистрибуции полученных ресурсов по Slaves. Ну а пока что — у нас нет ни Masters, ни Slaves. Именно о детальном процессе установки и настройки этих частей кластера я и хочу рассказать в дальнейших статьях.

    Часть 1 вышла облегченной, вводной частью, в которой я описал что мне нужно было сделать и какой путь я выбрал для выполнения задачи.
    Дальнейшие части будут более наполненными кодом и аспектами запуска и конфигурации Hadoop кластера.
    Комментарии по поводу неточностей и ошибок в описании — приветствуются, мне явно есть чему поучится в сфере Big Data.

    Всем спасибо за внимание!
    • +6
    • 11,2k
    • 6
    EPAM
    147,00
    Компания
    Поделиться публикацией

    Похожие публикации

    Комментарии 6

      0
      1. Не используйте виртуалки на продакшн (вы же не собирались, правда?). Слишком непредсказуемое окружение.
      2. Не используйте Ubuntu на продакшн (вы же не собирались?). Одно неразумное автоматическое обновление, и все ваши данные дружно улетают в небытие.
      3. Не используйте MapReduce нигде. Ну нафиг он вам, когда есть Spark? ;)
        0
        1. Ага, забыл уточнить, это чисто для приватных/внутренних дел :) Для девелоперов, которым нужно иногда. Да и учитывая легкость поднятия кластера через template для клауда — не проблема, даже если внезапно умрет. Естественно реальные аналитические задачи никто туда кидать не будет.
        2. А у нас кросплатформенное решение, так что Убунту не показатель. Просто для примера выбрано, как самая популярная ОС в нашем клауде.
        3. А вот это уже интересная интеграция, есть над чем подумать. На самом деле, этот таск из self-education только начинает превращаться в боевое задание, так что — спасибо, попробуем!
        • НЛО прилетело и опубликовало эту надпись здесь
            0
            Элементарно — конкретно в нашем клауде — она деплоится быстрее всего, т.к. ее чаще всего используют другие тимы. + большинство комьюнити наработок показывают себя хорошо оптимизированными под бубунту.
            • НЛО прилетело и опубликовало эту надпись здесь
                0
                «пару команд» это те кукбуки, в которых туча антипатернов, execute-ов и пр., без нужды.
                популярные кукбуки практически лишены такого.

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

      Самое читаемое