Waggle dance hadoop что это
Big Data от А до Я. Часть 2: Hadoop
Привет, Хабр! В предыдущей статье мы рассмотрели парадигму параллельных вычислений MapReduce. В этой статье мы перейдём от теории к практике и рассмотрим Hadoop – мощный инструментарий для работы с большими данными от Apache foundation.
В статье описано, какие инструменты и средства включает в себя Hadoop, каким образом установить Hadoop у себя, приведены инструкции и примеры разработки MapReduce-программ под Hadoop.
Общая информация о Hadoop
Как известно парадигму MapReduce предложила компания Google в 2004 году в своей статье MapReduce: Simplified Data Processing on Large Clusters. Поскольку предложенная статья содержала описание парадигмы, но реализация отсутствовала – несколько программистов из Yahoo предложили свою реализацию в рамках работ над web-краулером nutch. Более подробно историю Hadoop можно почитать в статье The history of Hadoop: From 4 nodes to the future of data
Изначально Hadoop был, в первую очередь, инструментом для хранения данных и запуска MapReduce-задач, сейчас же Hadoop представляет собой большой стек технологий, так или иначе связанных с обработкой больших данных (не только при помощи MapReduce).
Основными (core) компонентами Hadoop являются:
Некоторым из перечисленных компонент будут посвящены отдельные статьи этого цикла материалов, а пока разберём, каким образом можно начать работать с Hadoop и применять его на практике.
Установка Hadoop на кластер при помощи Cloudera Manager
Раньше установка Hadoop представляла собой достаточно тяжёлое занятие – нужно было по отдельности конфигурировать каждую машину в кластере, следить за тем, что ничего не забыто, аккуратно настраивать мониторинги. С ростом популярности Hadoop появились компании (такие как Cloudera, Hortonworks, MapR), которые предоставляют собственные сборки Hadoop и мощные средства для управления Hadoop-кластером. В нашем цикле материалов мы будем пользоваться сборкой Hadoop от компании Cloudera.
Для того чтобы установить Hadoop на свой кластер, нужно проделать несколько простых шагов:
После установки вы получите консоль управления кластером, где можно смотреть установленные сервисы, добавлять/удалять сервисы, следить за состоянием кластера, редактировать конфигурацию кластера:
Более подробно с процессом установки Hadoop на кластер при помощи cloudera manager можно ознакомиться по ссылке в разделе Quick Start.
Если же Hadoop планируется использовать для «попробовать» – можно не заморачиваться с приобретением дорогого железа и настройкой Hadoop на нём, а просто скачать преднастроенную виртуальную машину по ссылке и пользоваться настроенным hadoop’ом.
Запуск MapReduce программ на Hadoop
Теперь покажем как запустить MapReduce-задачу на Hadoop. В качестве задачи воспользуемся классическим примером WordCount, который был разобран в предыдущей статье цикла. Для того, чтобы экспериментировать на реальных данных, я подготовил архив из случайных новостей с сайта lenta.ru. Скачать архив можно по ссылке.
Напомню формулировку задачи: имеется набор документов. Необходимо для каждого слова, встречающегося в наборе документов, посчитать, сколько раз встречается слово в наборе.
Решение:
Map разбивает документ на слова и возвращает множество пар (word, 1).
Reduce суммирует вхождения каждого слова:
Теперь задача запрограммировать это решение в виде кода, который можно будет исполнить на Hadoop и запустить.
Способ №1. Hadoop Streaming
Самый простой способ запустить MapReduce-программу на Hadoop – воспользоваться streaming-интерфейсом Hadoop. Streaming-интерфейс предполагает, что map и reduce реализованы в виде программ, которые принимают данные с stdin и выдают результат на stdout.
Программа, которая исполняет функцию map называется mapper. Программа, которая выполняет reduce, называется, соответственно, reducer.
Streaming интерфейс предполагает по умолчанию, что одна входящая строка в mapper или reducer соответствует одной входящей записи для map.
Вывод mapper’a попадает на вход reducer’у в виде пар (ключ, значение), при этом все пары соответствующие одному ключу:
Данные, которые будет обрабатывать Hadoop должны храниться на HDFS. Загрузим наши статьи и положим на HDFS. Для этого нужно воспользоваться командой hadoop fs:
Утилита hadoop fs поддерживает большое количество методов для манипуляций с файловой системой, многие из которых один в один повторяют стандартные утилиты linux. Подробнее с её возможностями можно ознакомиться по ссылке.
Теперь запустим streaming-задачу:
Утилита yarn служит для запуска и управления различными приложениями (в том числе map-reduce based) на кластере. Hadoop-streaming.jar – это как раз один из примеров такого yarn-приложения.
Дальше идут параметры запуска:
В интерфейсе доступном по этому URL можно узнать более детальный статус выполнения задачи, посмотреть логи каждого маппера и редьюсера (что очень полезно в случае упавших задач).
Сам результат можно получить следующим образом:
Способ №2
Сам по себе hadoop написан на java, и нативный интерфейс у hadoop-a тоже java-based. Покажем, как выглядит нативное java-приложение для wordcount:
Этот класс делает абсолютно то же самое, что наш пример на Python. Мы создаём классы TokenizerMapper и IntSumReducer, наследуя их от классов Mapper и Reducer соответсвенно. Классы, передаваемые в качестве параметров шаблона, указывают типы входных и выходных значений. Нативный API подразумевает, что функции map на вход подаётся пара ключ-значение. Поскольку в нашем случае ключ пустой – в качестве типа ключа мы определяем просто Object.
В методе Main мы заводим mapreduce-задачу и определяем её параметры – имя, mapper и reducer, путь в HDFS, где находятся входные данные и куда положить результат.
Для компиляции нам потребуются hadoop-овские библиотеки. Я использую для сборки Maven, для которого у cloudera есть репозиторий. Инструкции по его настройке можно найти по ссылке. В итоге файл pom.xmp (который используется maven’ом для описания сборки проекта) у меня получился следующий):
Соберём проект в jar-пакет:
После сборки проекта в jar-файл запуск происходит похожим образом, как и в случае streaming-интерфейса:
Дожидаемся выполнения и проверяем результат:
Как нетрудно догадаться, результат выполнения нашего нативного приложения совпадает с результатом streaming-приложения, которое мы запустили предыдущим способом.
Резюме
В статье мы рассмотрели Hadoop – программный стек для работы с большими данными, описали процесс установки Hadoop на примере дистрибутива cloudera, показали, как писать mapreduce-программы, используя streaming-интерфейс и нативный API Hadoop’a.
В следующих статьях цикла мы рассмотрим более детально архитектуру отдельных компонент Hadoop и Hadoop-related ПО, покажем более сложные варианты MapReduce-программ, разберём способы упрощения работы с MapReduce, а также ограничения MapReduce и как эти ограничения обходить.
Спасибо за внимание, готовы ответить на ваши вопросы.
Австрийский этолог и лауреат Нобелевской премии Карл фон Фриш был одним из первых, кто перевел значение танца виляния.
СОДЕРЖАНИЕ
Описание
Покачиваясь, танцующие пчелы, которые были в гнезде в течение длительного времени, регулируют углы своего танца, чтобы приспособиться к изменяющемуся направлению солнца. Следовательно, пчелы, которые следуют за покачиванием в танце, по-прежнему правильно направляются к источнику пищи, даже если его угол относительно солнца изменился.
Кевин Эбботт и Реувен Дукас из Университета Макмастера в Гамильтоне, Онтарио, Канада, обнаружили, что если мертвую западную медоносную пчелу поместить на цветок, пчелы будут выполнять гораздо меньше танцев покачивания, вернувшись в улей. Ученые объясняют, что пчелы ассоциируют мертвую пчелу с присутствием хищника у источника пищи. Таким образом, уменьшение частоты повторения танцев указывает на то, что танцующие пчелы выполняют и передают форму анализа риска / пользы.
«В каждом путешествии пчела не перелетает от цветка одного вида к цветку другого, а переходит, скажем, с одной фиалки на другую фиалку и никогда не вмешивается в другой цветок, пока тот не вернется в улей; улей они сбрасывают свою ношу, и за каждой возвращающейся пчелой следуют три или четыре товарища. Что именно они собирают, трудно увидеть, а как они это делают, не наблюдалось ».
Юрген Таутц также пишет об этом в своей книге «Шут о пчелах» (2008):
Многие элементы коммуникации, используемые для набора минисогрева на места кормления, также наблюдаются в «истинном» роящем поведении. Миниогары собирателей не подвергаются тому же давлению отбора, что и настоящие стаи, потому что судьба всей колонии не стоит на кону. По-настоящему многочисленную колонию нужно быстро привести в новый дом, иначе она погибнет. Поведение, используемое для вербовки к источникам пищи, возможно, развилось из «истинного» роения.
Механизм
Полемика
Танцевальный язык против танца виляния
Пчелы, которые следуют за танцем виляния, могут успешно добывать корм, не расшифровывая информацию о языке танца, несколькими способами:
Танцевальный язык как язык
Эффективность и адаптация
Танец виляния может быть менее эффективным, чем думали раньше. Некоторые пчелы наблюдают более 50 пробежек без успешного кормления, в то время как другие будут успешно кормиться после наблюдения 5 пробежек. Точно так же исследования показали, что пчелы редко используют информацию, передаваемую в танце виляния, и, похоже, делают это только в десяти процентах случаев. Очевидно, существует конфликт между личной информацией или индивидуальным опытом и социальной информацией, передаваемой через танцевальное общение. Это проливает свет на тот факт, что отслеживание социальной информации более затратно с точки зрения энергии, чем самостоятельный поиск пищи, и не всегда выгодно. Используя обонятельные сигналы и память об обильных местах кормления, пчелы могут успешно добывать корм самостоятельно, не тратя потенциально значительную энергию, необходимую для обработки и выполнения указаний, переданных их собратьями-сборщиками.
Танец виляния полезен в одних средах, но не в других, что дает правдоподобное объяснение того, почему информация, предоставляемая танцами виляния, используется редко. В зависимости от погоды, других конкурентов и характеристик источника пищи передаваемая информация может быстро ухудшиться и стать устаревшей. В результате, как сообщается, фуражиры привязаны к своим местам кормления и продолжают многократно посещать один участок после того, как он стал убыточным. Например, танец виляния играет значительно большую роль в поиске пищи, когда источников пищи не так много. Например, в средах с умеренным климатом семьи медоносных пчел обычно исполняют танец виляния, но все же были в состоянии успешно добывать корм, когда информация о местоположении, предоставленная танцем, была экспериментально скрыта. Однако в тропических местах обитания медоносные пчелы собирают пищу, если предотвращают виляние движения. Считается, что это различие связано с неоднородностью ресурсов в тропической среде по сравнению с однородностью ресурсов в условиях умеренного климата. В тропиках пищевые ресурсы могут быть представлены в виде цветущих деревьев, богатых нектаром, но редких и непродолжительных цветущих. Таким образом, в тропических зонах информация о местонахождении кормов может быть более ценной, чем в зонах с умеренным климатом.
Эволюция
Предки современных медоносных пчел, скорее всего, совершали возбуждающие движения, чтобы побудить других собратьев по гнезду на корм. Эти возбуждающие движения включают тряску, зигзагообразные движения, жужжание и врезание в сокамерников. Подобное поведение наблюдается и у других перепончатокрылых, включая безжалостных пчел, ос, шмелей и муравьев.
Одна многообещающая теория эволюции танца виляния, впервые предложенная Мартином Линдауэром, состоит в том, что танец виляния изначально способствовал передаче информации о новом месте гнездования, а не пространственной информации о местах кормления.
Наблюдения показали, что разные виды медоносных пчел имеют разные «диалекты» виляющего танца, причем танец каждого вида или подвида различается по кривой или продолжительности. Исследование 2008 года показало, что смешанная колония азиатских медоносных пчел ( Apis cerana cerana ) и европейских медоносных пчел ( Apis mellifera ligustica ) постепенно стала понимать «диалекты» танца виляния друг друга.
Приложения для исследования операций
В этой статье мы представляем новый алгоритм маршрутизации BeeHive, который был вдохновлен коммуникативными и оценочными методами и процедурами медоносных пчел. В этом алгоритме пчелиные агенты путешествуют через сетевые регионы, называемые зонами кормодобывания. По пути их информация о состоянии сети доставляется для обновления локальных таблиц маршрутизации. BeeHive отказоустойчив, масштабируем и полностью полагается на локальную или региональную информацию соответственно. Мы демонстрируем с помощью обширного моделирования, что BeeHive обеспечивает аналогичную или лучшую производительность по сравнению с современными алгоритмами.
Еще одна пчелы вдохновленного stigmergic техника вычислительная называется оптимизацией колонии пчел используются в серверной оптимизации Интернета.
Протокол Zigbee RF назван в честь танца виляния.
Hive remote databases/tables
Abstract
At the 2018 DataWorks conference in Berlin, Hotels.com presented Waggle Dance, a tool for federating multiple Hive clusters and providing the illusion of a unified data catalog from disparate instances. We’ve been running Waggle Dance in production for well over a year and it has formed a critical part of our data platform architecture and infrastructure.
We believe that this type of functionality will be of increasing importance as Hadoop and Hive workloads migrate to the cloud. While Waggle Dance is one solution, significant benefits could be realized if these kinds of abilities were an integral part of the Hive platform.
This proposal outlines why such a feature is needed in Hive, the benefits gained by offering it as a built-in feature, and representation of a possible implementation. Our proposed implementation draws inspiration from the remote table features present in some traditional RDBMSes, which may already be familiar to you.
The cloud, a rich source of new architectures
Waggle Dance was created to overcome the problems created by architectural patterns that arose in cloud deployments of Hive. Unlike the monolithic deployment model typical of on premises deployments, in the cloud users are able to trivially create multiple cluster instances, either by design or unintentionally through organic growth. This ability to create new clusters in the cloud provides new levels of flexibility and agility to organizations. They are no longer bound to inelastic resource pools, specific platform versions, and lengthy upgrade cycles. Different parts of an organization are free to technologically innovate at their own pace.
However, Hive is designed around the monolithic cluster architecture and provides no means to enable cross cluster access of datasets. One Hive cluster cannot concurrently access local datasets and those in another cluster. This results in a set of data silos in the cloud, inhibiting data exploration, discovery and sharing and ultimately limiting an organization’s ability to realize the full potential of their datasets.
How Waggle Dance works
Waggle Dance provides a federated view of these disparately located datasets, allowing users in one cluster to explore and access datasets in multiple other clusters. Waggle Dance operates as a request routing metastore proxy service. It implements the Hive metastore Thrift API, so that as far as a workload (ETL, Query, Analytics tool) is concerned, it is communicating directly with a Hive metastore service instance. Waggle Dance connects to multiple metastore services, located in otherwise unconnected clusters. It routes and transforms metadata requests from the workload, to the appropriate metastore using database identifiers encoded in the payloads. Finally it returns the responses from the different metastores to the workload. These responses typically contain data file paths that the workload then uses to consume data. Typically these are located in a region wide object store such as S3, and hence the underlying dataset data can be read fairly seamlessly between clusters.
Problems with Waggle Dance
We’ve been successfully using Waggle Dance in production to federate many Hive instances, often bridging across different AWS accounts in the same region. It has enabled the sharing of large datasets across different organizational units and has restored the ability to easily explore, discover and share datasets as we once did on our on-premises organisation-wide Hive cluster. Our user groups include Data scientists, analysts, and engineers who are interacting with the platform using a diverse range of tools including Hive, Spark, Cascading, HS2+JDBC (+ many clients), Qubole, and Databricks.
While we are very happy with the functionality that Waggle Dance provides, there are some drawbacks:
Additional infrastructure requirements
To deliver Waggle Dance as a highly available service we must operate multiple additional load balanced virtual servers in a cross availability zone arrangement. These servers have a similar memory footprint to our HMS instances as they are required to serialize and deserialize Thrift objects passing between workloads and federated metastore instances. This Waggle Dance infrastructure creates an additional operational burden on our data platform.
Thrift API limits integration opportunities
The HMS Thrift API has proved to be a very convenient integration and interception point for Waggle Dance. However, we are seeing a trends and possible needs for alternative means of integrating data catalogue services with Hive.
Federation management is externalised
Waggle Dance is a service separate from HMS, any configuration relating to the metastores and databases we wish to expose in a federated view must be managed separately via YAML config files that are loaded by Waggle Dance on start up. This creates an administration overhead, and prevents Hive users from creating and managing federated access to the datasets that they require.
Name overloads
As our multiple cloud-based Hive clusters are independent, they have no shared global schema namespace. Consequently it is possible for database and/or table name overloads to occur when federating multiple metastores; some may well include database or table names that are already in use in one or more of the other metastores in the federation. Waggle Dance handles this by either applying a prefix to remote database names, or by allowing administrators to carefully curate a list of databases that should be exposed locally, so that overloads can at least be excluded. However, both approaches have drawbacks. Prefixing creates localized database names, and consequently encourages the creation of non-portable Hive SQL scripts. The curation of imported databases is an operational burden, and is not useful when one wants to access two databases with the same name in a unified view.
Federation with remote databases and tables
While Waggle Dance is working well for us, its design was highly influenced by our need to quickly prove a concept and unblock groups of users. Therefore we intentionally avoided any design that might require changes to HMS and by implication, extended release cycles. However, in the data warehousing world there are already good examples of features that solve these kind of federation based problems. These features are often tightly integrated into the data warehousing platform, giving users a seamless experience. For example, the Oracle platform includes features such as Database links, and Remote tables that allow catalog entities to be projected and accessed from a remote database server into a local instance.
An implementation of ‘remotes’ in Hive
We therefore propose that the concept of remotes be added to Hive. Practically this would encapsulate and deliver the proven functionality and utility of Waggle Dance while simultaneously overcoming the deficiencies in the Waggle Dance design. Before exploring the full scope of this idea, let’s consider the anatomy of the most typical use case from a user’s perspective; creating a link to a table in a remote cluster to enable local access:
Once the remote table has been created the user is free to interact with it as they would any other table (we assume read only at this time). As we demonstrated with Waggle Dance, users are able to efficiently and transparently select, join, and describe tables from multiple distributed clusters in a single local unified view.
The HiveMetaStoreClientFactory abstraction
Other use cases
Our first example dealt with the simple federating of a single table from one remote metastore. The following examples aim to describe the greater scope of the implementation.
Remote databases
Waggle Dance actually federates databases, and hence sets of tables. We could achieve a similar feat with a CREATE REMOTE DATABASE (CRD) statement. This would expose all tables in the remote database to the local Hive cluster
Statement defaults
The CRT and CRD statements can be simplified if we assume some sensible defaults. Here we assume that if a VIA stanza is not supplied, we’ll default to the HMS Thrift implementation. If the CONNECT TO stanza is omitted, the remote database name is assumed to be equal to user supplied local name:
Now, for a remote table we can also derive the local database name from the user’s currently selected database, and expect that the remote table name is equal to the user supplied local name:
SSH Tunneling and bastion hosts
With a suitable connector, remotes could be configured to use a SSH tunnel to access a remote Hive metastore in cases where certain network restrictions prevent a direct connection from the local cluster to the machine running the Thrift Hive metastore service. A SSH tunnel consists of one or more hops or jump-boxes. The connection between each pair of nodes requires a user and a private key to establish the SSH connection.
Non-Thrift catalog integrations
Using different HiveMetastoreClientFactory we can import database and table entities for other catalog implementations, or HMS endpoints that use alternative protocols such as REST or GRPC. Consider these illustrative examples:
AWS Glue
Netflix iceberg
Behaviour of DESCRIBE and SHOW operations
On executing DESCRIBE operations on remote tables and databases, we envisage that the user be returned the description from the remote catalog to which the remote configuration is appended.
Summary
The proposed solution of Hive ‘remotes’ offers feature parity with Waggle Dance while overcoming its deficiencies. It also offers opportunities to integrate with more recent HMS alternatives in a complimentary manner.
Why not replicate tables between clusters instead?
We could instead replicate tables between our siloed clusters in the cloud. However there are some significant drawbacks. Replication creates large operational overheads. Processes must be deployed, configured, and managed. Greater storage costs are also incurred for each new replica. Finally, one needs to ensure all replicas are in sync, and detect and communicate information concerning any divergent tables.
How is authentication applied?
Waggle Dance has rudimentary support for the propagation of identity to remote federated metastores. It does this by simply passing along the current UGI principal in the Thrift requests. Clearly, this principal needs to be known in the target HMS. The proposed remoting feature could provide similar functionality. At this time Waggle Dance does not support Kerberos. However, we see no technical reason why this could not be implemented both in Waggle Dance and the remote tables feature.
How is authorization applied?
Currently, the only comprehensive authorization scheme that Hive offers is applied in the HiveServer2 component, and not the HMS. Additionally, HMS resident authorization schemes (file based) do not function on the file stores offered by the cloud providers targeted by the remotes feature. Therefore, authorization appears to be a client issue and is not in the scope of this proposal.
What access patterns are supported?
Waggle Dance is primarily used for read only access of tables in remote Hive clusters, and full control of tables in the local cluster. This proposal assumes a similar set of constraints. However, one can imagine that it might be useful to write to AWS Glue, or Netflix iceberg tables for the purposes of incremental migration to those platforms.
Will it work with ACID tables?
Remote tables should work in the context of read only access. To read ACID, one needs only the ValidTxnList from the remote metastore and access to the set of base and delta files. Writing of remote ACID tables does not seem practical as there is no global transaction manager in this architecture. Note that at this time ACID does not function reliably on S3, although this capability has been promised.