Платформа распределенных вычислений Hadoop

Платформа распределенных вычислений Hadoop

Платформа распределенных вычислений Hadoop разрабатывается на принципах opensource в рамках организации TheApacheSoftwareFoundation. Платформа ориентирована на поддержку обработки больших объемов данных и заимствует многие идеи у закрытых технологий Google, например: MapReduce, GFSи BigTable. Hadoop делится на 2 части: HadoopCore и HBase. В состав HadoopCoreвходят распределенная файловая система HDFS и реализация модели MapReduce. HBase содержит реализацию распределенной системы хранения структурированный данныхю. Данный раздел посвящен особенностям реализации модели MapReduceв Hadoop.

Для реализации вычислений в Hadoop используется архитектура "master- worker".

Система реализована на языке Java. Для создания приложений используется прикладной интерфейс программирования на Java. Функции mapи reduceописываются в виде классов, реализующих стандартные интерфейсы Mapperи Reducer.

Запуск задания осуществляется с помощью вызова функции runJob или submitJob, каждой из которых передается объект JobConf. В первом случае приложение блокируется до завершения заданий, а во втором случае вызов сразу возвращает управление коду приложения. При запуске задания его спецификация и jar-файл с кодом автоматически размещаются в HDFS, после чего задание направляется JobTracker-процессу. В описании задания пользователь может указать набор дополнительных файлов, копируемых на рабочие узлы перед запуском вычислений.

Количество map-задач определяется системой автоматически, исходя из указанного пользователем желаемого числа задач, а также максимального (размер HDFS-блока) и минимального размеров фрагмента входных данных. Количество reduce-задач управляется с помощью параметра задания. Пользователь может установить число reduce-задач равным 0. В этом случае фаза reduceне проводится, и промежуточные результаты map-задач записываются в выходные файлы в HDFS. Данная возможность полезна в тех случаях, когда не требуется агрегация или сортировка результатов фазы map.

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

Для отладки и отслеживания статуса выполнения map- и reduce-задач Hadoop позволяет обновлять внутри функций mapи reduceстроку статуса задачи и значения счетчиков, определенных пользователем. Кроме запуска Java-программ, Hadoop позволяет указать в качестве реализаций mapи reduce произвольные программы. Данные программы должны считывать входные данные из потока ввода и записывать результаты в поток вывода.

Технология распределенной обработки данных Dryad

Универсальная технология распределенной обработки данных Dryad разрабатывается компанией Microsoft. В настоящее время эта технология является закрытой и применяется только внутри компании, например, в поисковой системе MSNLiveSearch. Описание технологии было опубликовано в работе .

Модель программирования Dryad основана на представлении приложения в виде ориентированного ациклического графа. Вершинами графа являются процессы. Ребра графа определяют потоки данных между процессами в виде односторонних каналов. У процесса может быть несколько входных и выходных каналов. Вершины графа могут быть сгруппированы в стадии (stage). Важно отметить, что модель программирования Dryadсодержит в себе в качестве частных случаев реляционную алгебру и MapReduce.

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

В качестве вершин графа могут выступать программы на C++ или другом языке. Каналы между вершинами реализуются несколькими способами: файлы в распределенной и сетевой файловой системе, TCP-каналы, FIFO-очереди в оперативной памяти. Выбор того или иного варианта реализации каждого канала в графе может производиться системой автоматически, исходя из текущей конфигурации системы и размещения процессов по машинам.

Пользователь описывает граф приложения с помощь интерфейса прикладного программирования на языке C++. При запуске задания на кластере создается менеджер задания (jobmanager), которые управляет выполнением графа задания. Менеджер задания получает информацию о ресурсах кластера, генерирует граф задания, инициализирует его вершины, пересылает их код на узлы кластера и контролирует выполнение вершин. На узлах кластера запущены процессы, запускающие код вершин графа и позволяющие менеджеру задания отслеживать состояние выполнения вершин. При размещении вершин на узлах кластера система учитывает потоки данных между вершинами и старается разместить взаимодействующие вершины на одной машине или рядом друг с другом.

Наиболее интересной особенностью Dryad является поддержка динамической модификации структуры графа задания во время его выполнения. Приведем несколько примеров. Система обнаруживает вершины, выполняемые медленнее других вершин данной стадии, и автоматически создает дублирующие вершины (аналогично backup- заданиям в MapReduce). Вершина, выполняющая агрегацию данных из множества вершин, может быть снабжена вспомогательными вершинами, которые производят локальную агрегацию данных из вершин в пределах серверной стойки и т.п. (аналогично combine-функции в MapReduce). Вершина может быть заменена на несколько вершин путем разбиения обрабатываемых вершиной данных. Для равномерного разбиения входных данных по значениям их ключей система создает вспомогательные вершины, которые определяют распределение данных по ключам и разбивают данные на равные части. Пользователь также может реализовывать собственные стратегии динамической модификации графа.

Возможности Dryadинтегрированы в высокоуровневые языки и системы, такие как DryadLINQи MicrosoftSQLServer. В настоящее время не существует общедоступных аналогов Dryad.

Инфраструктурный сервис Chubby

Из соображений отказоустойчивости и масштабируемости, описанные выше технологии Googleспроектированы как распределенные системы, компоненты которых слабо связаны друг с другом (loosely-coupled). Это означает, что компоненты системы должны динамически обнаруживать и отслеживать состояние друг друга, автоматически выбирать в случае отказа новый главный сервер и гибким образом координировать свои действия. Возложение подобных функций на главный сервер делает его уязвимым местом системы. С другой стороны, реализация полностью децентрализованных механизмов в присутствии большого количества машин может оказаться сложной и неэффективной в сравнении с централизованными решениями.

Для решения этой проблемы в компании Google был создан отдельный высоконадежный сервис Chubby, используемый такими системами, как GFS, BigTableи MapReduce. Наличие готового сервиса координации упрощает создание сложных распределенных систем. Внутренние системы Googleиспользуют Chubby для обнаружения серверов, выбора главного сервера и хранения важных данных. По сути, GFSи BigTable используют Chubbyв качестве корневого сервиса для своих распределенных структур данных.

С точки зрения клиентов Chubby выглядит как централизованный сервис. Высокая надежность сервиса обеспечивается за счет репликации его на пяти машинах и использования децентрализованного механизма выборов главной реплики. Сервис доступен до тех пор, пока большинство реплик функционируют и могут взаимодействовать друг с другом. Выбор главного сервера среди множества узлов является частным случаем задачи о консенсусе в распределенной системе. Для выбора главной реплики в Chubby используется известный алгоритм Paxos.

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

Обслуживаемые Chubby файлы и директории образуют узлы файловой системы. Клиенты могут создавать произвольные узлы и записывать в них данные. Кроме того, узлы могут использоваться в качестве блокировки (lock). Блокировка может быть исключающей (exclusive) или совместной (shared). Также существует специальный тип временных узлов, которые автоматически удаляются в том случае, если они не открыты ни одним клиентом (или пусты, в случае директорий).

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

Приведем несколько примеров использования Chubby для координации компонентов распределенной системы. Для определения главного сервера в системе может использоваться исключительная блокировка выделенного файла в Chubby. Первый сервер, получивший блокировку файла, считается главным, после чего он записывает свой адрес в данный файл. Другие сервера отслеживают содержимое файла для определения текущего главного сервера и статус блокировки файла для обнаружения отказа главного сервера. Для получения главным сервером списка подчиненных серверов может использоваться выделенная директория, в который каждый сервер создает временный файл со своим адресом. При отказе сервера его сессия в Chubby истекает, и файл автоматически удаляется. Подобные события могут отслеживаться главным сервером системы с помощью механизма уведомлений Chubby. Система BigTableхранит в Chubbyразличные метаданные и местоположение корневого таблета. Сервис также активно используется в качестве альтернативы сервису разрешения имен DNS.

В заключение, отметим что, как и другие описанные ранее технологии Google, сервис Chubby является закрытой разработкой, используемой только внутри компании

Инфраструктурный сервис ZooKeeper

Общедоступным аналогом описанной выше технологии Chubby является сервис ZooKeeper, разработка которого ведется сотрудниками компании Yahooна принципах opensource. Опустим описание архитектуры и принципы реализации ZooKeeper, поскольку они практически совпадают с Chubby. Отметим, что ZooKeeper может быть применен в сочетании с платформой Hadoopдля повышения надежности системы и координации отдельных серверов. Например, с помощью ZooKeeper можно произвести динамическую конфигурацию Hadoop во время запуска системы по требованию на вычислительном кластере. В этом случае клиент и развернутые на кластере TaskTracker-процессы могут определить через ZooKeeper адрес развернутого JobTracker-процесса.

10. Особенности интеграции приложений в сети Интернет

Технологии и механизмы реализации распределенной обработки информации спроектированы для работы в масштабе отдельной локальной вычислительной сети. Особую актуальность приобрела необходимость автоматизации взаимодействия удаленных предприятий и компаний посредством глобальной информационно-коммуникационной сети Интернет, такое взаимодействие означает вызов службы, размещенной в другой компании. Расширение на Интернет достигается соединением нескольких систем друг с другом. В системах с брокерами объектов это делается с помощью обобщенного межброкерного протокола GIOP, который определяет, каким образом вызов от одного брокера передается другому и как назад отправляется ответ на вызов. Протокол GIOP расширен и превращен в межброкерный протокол Интернета IIОР. В протоколе IIОР определено, как транслировать вызовы протокола GIOP в вызовы стека протоколовTCP/IP (Transmission Control Protocol/Internet Protocol – протокол управления передачей/межсетевой протокол), которые уже можно посылать в Интернет.

На практике брокеры соединены с Интернетом через межсетевые экраны, которые ограничивают взаимодействие. Межсетевой экран – барьер на пути нежелательного сетевого трафика, который блокирует коммуникационные каналы. В Интернете проблематично рассчитывать на использование удаленных вызовов процедур, удаленных обращений к методам и протоколов GIOP/IIOP. Другим препятствием является различие определений интерфейсов и форматов данных, применяемых в разных приложениях. При наличии межсетевых экранов также невозможно осуществлять прямое взаимодействие интегрируемых систем. Протоколы, которые могли бы быть заблокированы межсетевыми экранами, «скрываются» под протоколами, которые этими экранами допускаются.

В традиционных системах представление данных скрыто в языке IDL, который выполняет две задачи: определение интерфейса и введение промежуточного машинно-независимого представления данных. В разнородной сети Интернет часто используется язык разметки XML. Язык XML предоставляет стандартные правила определения структуры документов. Стандартизация способа кодирования структуры позволяет разрабатывать инструментарий для просмотра, автоматического разбора документов, для извлечения информации из них.

Традиционные подходы к построению распределенных систем и традиционные методы интеграции приложений направлены на интеграцию автономных систем и автоматизацию бизнес-процессов, распространяющихся на несколько таких систем. Применение традиционных подходов требует от участников взаимодействия достижения соглашения по использованию и совместному управлению конкретной системной платформой. Этот подход не всегда пригоден, поскольку трудно достичь необходимого уровня доверия между участниками. Другой причиной непригодности традиционного подхода является неверность предположений, делавшихся при интеграции предприятий (длительность взаимодействия в сети Интернет препятствует применению традиционных протоколов типа 2РС они блокируют ресурсы на слишком большой срок, делая невозможным параллельное выполнение других операций).

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

Протоколы, с которыми работают сетевые службы, должны быть пригодны для работы без выделенных серверов. Традиционные протоколы (2PC) работают с центральным транзакционным координатором, который обладает возможностями блокировать ресурсы. Протокол 2РС и другие протоколы взаимодействия и координации должны быть модифицированы, чтобы работать в децентрализованном режиме в отсутствии доверительных зон и гибко проводить блокировки.

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

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

← Предыдущая
Страница 1
Следующая →

Файл

экзамен вопросы 6-10.docx

экзамен вопросы 6-10.docx
Размер: 26.5 Кб

.

Пожаловаться на материал

Технология распределенной обработки данных Dryad, Инфраструктурный сервис Chubby, Инфраструктурный сервис ZooKeeper, Особенности интеграции приложений в сети Интернет

У нас самая большая информационная база в рунете, поэтому Вы всегда можете найти походите запросы

Искать ещё по теме...

Похожие материалы:

Морське міжнародне право

Поняття і визначення прилеглої зони та територіального моря. Правовий режим територіального моря. Юрисдикція в територіальному морі. Прилегла зона. Делімітація та демаркація у морському праві.

Общественные движения и политические течения в России во второй половине XIX века

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

Понятие и виды таможенных платежей

Таможенные платежи — это денежные средства, взимаемые таможенными органами с лиц, участвующих в процессе перемещения товаров и транспортных средств через таможенную границу Российской Федерации. Уплата платежей — одно из основных условий операций, связанных с внешней торговлей.

Индивидуальная гигиена полости РТАС оветы по выбору зубной щетки

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

Мінеральні (штучні) добрива – сукупність поживних елементів  для ґрунту і рослин

Доповідь наукової роботи.

Сохранить?

Пропустить...

Введите код

Ok