Apache Beam

Материал из Национальной библиотеки им. Н. Э. Баумана
Последнее изменение этой страницы: 02:23, 27 декабря 2017.
Apache Beam
Beam logo
Разработчики: Apache Software Foundation
Выпущена: 17 May 2017 года; 3 years ago (2017-05-17)
Постоянный выпуск: 2.1.0 / 23 August 2017 года; 3 years ago (2017-08-23)
Состояние разработки: Активное
Написана на: Java, Python
Операционная система: Cross-platform
Лицензия: Apache License 2.0
Веб-сайт beam.apache.org

Apache Beam - это унифицированная модель для определения как пакетных, так и потоковых конвейеров для параллельной обработки данных, а также набор специфических для языка SDK (Software Development Kit) для построения конвейеров и вычислительных процессов в back-end для их выполнения на серверах распределенной обработки, включая Apache Apex, Apache Flink, Apache SparkGoogle Cloud Dataflow.

Является OSS (Open-Source Software).

Содержание

История

Apache Beam - одна из реализаций документа модели потока данных.

Модель Dataflow основана на предыдущей работе над абстракциями распределенной обработки в Google, в частности на FlumeJava и Millwheel.

Google выпустила открытую реализацию SDK модели Dataflow в 2014 году и среду для локального (нераспределенного) распространения потоков данных, также как и в службе Google Cloud Platform.

В 2016 году Google поcтавил основной SDK, а также реализацию локального бегуна(Runner) и набор IOs (соединителей данных) для доступа к службам данных Google Cloud Platform в Apache Software Foundation. Другие компании и члены сообщества внесли вклад для существующих распределенных платформ выполнения, а также новые модули ввода-вывода для интеграции Beam Runners с существующими базами данных, хранилищами ключевого значения и системами сообщений. Кроме того, были предложены новые DSL для поддержки конкретных потребностей в доменах поверх модели Beam.

Использование

Apache Beam используется для проблемных задач параллельной обработки данных, в которых задача может быть разложена на множество небольших пакетов данных, которые могут обрабатываться независимо и параллельно. Можно также использовать задачи Beam для Extract, Transform и Load (ETL) и чистой интеграции данных. Эти задачи полезны для перемещения данных между различными носителями данных и источниками данных, преобразования данных в более желательный формат или загрузки данных в новую систему.

SDK, предоставляемые Apache Beam

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

В настоящее время Beam поддерживает SDK для следующих языков:

Модель исполнения Apache Beam

Модель Beam позволяет бегунам выполнять ваш конвеер по-разному. Вы можете наблюдать различные эффекты в результате выбора бегуна

Обработка элементов

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

Сериализация и связь

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

Бегун может решить передать элементы между преобразованиями различными способами, такими как:

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

В некоторых ситуациях, бегун может сериализовать и сохранять элементы:

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

Связывание

Конвееры Beam часто фокусируются на проблемах «смущающей параллели». Из-за этого API-интерфейсы подчеркивают параллельные элементы обработки, что затрудняет выражение таких действий, как «присвоить порядковый номер каждому элементу в PCollection». Это преднамеренно, поскольку такие алгоритмы гораздо чаще страдают от проблем с масштабируемостью.

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

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

Ошибки и параллелизм внутри и между преобразованиями

Параллелизм данных в рамках одного преобразования

При выполнении одного ParDo бегун может разделить примерный входной набор из девяти элементов на два пакета, как показано на рисунке 1.

Рис.1 Бегун делит входную коллекцию на два пучка.

Когда ParDo выполняется, система может обрабатывать два пакета параллельно, как показано на рисунке 2.

Рис.2 Обработчики параллельно обрабатывают два пучка

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

Рис.3 Девять обработчиков обрабатывают коллекцию из девяти элементов ввода параллельно

Примечание. Splittable ParDo позволяет разбивать обработку одного входа на несколько пакетов. Эта функция является незавершенной.

Зависимый параллелизм между преобразованиями

Преобразования ParDo, которые в последовательности могут быть зависимыми, могут быть параллельными, если бегун выбирает выполнение потребляющего преобразования на выходных элементах производственного преобразователя без изменения связывания. На рисунке 4 ParDo1 и ParDo2 зависимы друг от друга, если вывод ParDo1 для данного элемента должен обрабатываться одним и тем же обработчиком.

Рис.4: Два преобразования в последовательности и их соответствующие входные коллекции.

На рисунке 5 показано, как эти зависимые параллельные преобразования могут выполняться. Первый рабочий выполняет ParDo1 на элементах в пакете A (что приводит к расслоению C), а затем выполняет ParDo2 на элементах в пучке C. Аналогичным образом второй рабочий выполняет ParDo1 на элементах в пакете B (что приводит к расслоению D) , а затем выполняет ParDo2 на элементах в расслоении D.

Рис.5: Два обработчика выполняют зависимые параллельные преобразования ParDo.

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

Ошибки в пределах одного преобразования

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

В этом примере мы будем использовать ParDo на рисунке 1, который имеет входную коллекцию с девятью элементами и делится на два пакета.

На рисунке 6 первый обработчик успешно обрабатывает все пять элементов в пучке A. Второй обработчик - четыре элемента в пакете B: первые два элемента были успешно обработаны, обработка третьего элемента завершилась неудачно, и еще один элемент все еще ожидает обработки.

Мы видим, что бегун повторяет все элементы в связке B, и обработка завершается успешно во второй раз. Обратите внимание, что повтор не обязательно происходит у того же обработчика, что и при первоначальной обработке, как показано на рисунке.

Рис.6: Обработка элемента в пакете B завершается с ошибкой, а другой обработчик повторяет весь пакет.

Сбой связи: сбои между преобразованиями

Если отказ обработать элемент в ParDo2 заставляет ParDo1 повторно выполнить, эти два шага, являются совместными. В этом примере мы будем использовать два ParDo с рисунка 4. На рисунке 7 второй обработчик успешно выполняет ParDo1 для всех элементов в связке B. Однако он не обрабатывает элемент в пакете D, поэтому ParDo2 не работает (отображается как красный X). В результате, бегун должен отказаться и пересчитать результат ParDo2. Поскольку бегун выполнял ParDo1 и ParDo2 вместе, выходной пакет из ParDo1 также должен быть выброшен, и все элементы входящего пакета должны быть повторены. Эти два ParDo несовместимы.

Рис.7: Рисунок 7: Обработка элемента в расслоении D завершается неудачей, поэтому все элементы входного пакета повторяются.

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

Apache Beam Pipeline Runners

Beam Pipeline Runners переводит конвейер обработки данных, который вы определяете с помощью вашей программы Beam, в API, совместимый с распределенным серверным интерфейсом по вашему выбору. Когда вы запускаете свою программу Beam, вам нужно указать соответствующий бегун для бек-энда, где вы хотите выполнить свой конвейер.

В настоящее время Beam поддерживает Runners, которые работают со следующими распределенными обработчиками:

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

Матрицы возможностей

Apache Beam предоставляет переносимый уровень API для создания сложных параллельных потоков данных, которые могут выполняться во множестве механизмов выполнения или бегунов. Основные понятия этого слоя основаны на модели Beam (ранее называемой моделью потока данных) и реализованы в различной степени в каждом бегуне Beam. [2]

Матрица возможностей по вопросу "Что вычисляется?"

Beam Model Google Cloud Dataflow Apache Flink Apache Spark Apache Apex Apache Gearpump Apache Hadoop MapReduce JStorm IBM Streams
ParDo Да: обработка по элементам

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

Да: полностью поддерживается

В пакетном режиме используются большие размеры пакетов. Потоковая передача использует меньшие размеры пакетов.

Да: полностью поддерживается

Сам ParDo, как преобразование элементов с помощью UDF, полностью поддерживается Flink для пакетной и потоковой передачи.

Да: полностью поддерживается

Сам ParDo, как преобразование элементов с помощью UDF, полностью поддерживается Flink для пакетной и потоковой передачи.

Да: полностью поддерживается

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

Да: полностью поддерживается

Gearpump переносит функцию преобразования каждого элемента в выполнение процессора.

Да: полностью поддерживается Да: полностью поддерживается Да: полностью поддерживается
GroupByKey Да: группировка по ключам

Группировка пар ключ-значение для каждого ключа, окна и панели. (См. Также другие таблицы)

Да: полностью поддерживается Да: полностью поддерживается

Использует ключевое слово Flink для группировки ключа. При группировке по окну в потоковой передаче (создание панелей) бегун Flink использует код Beam. Это гарантирует поддержку всех оконных и триггерных механизмов.

Частично: полностью поддерживается в пакетном режиме

Использование группы Spark'sByKey. GroupByKey с несколькими срабатываниями триггера в потоковом режиме - работа в процессе.

Да: полностью поддерживается

Apex runner использует код Beam для группировки по окну и, таким образом, поддерживает все механизмы окон и триггеров. Runner еще не реализует разделение (BEAM-838)

Да: полностью поддерживается

Используйте группу GroupBy Gearpump и окно для группировки клавиш и переведите оконное окно Beam и запускайте его во внутреннюю реализацию Gearpump.

Да: полностью поддерживается Да: полностью поддерживается Да: полностью поддерживается
Flatten Да: объединение конкатенаций

Объединение нескольких однородно типизированных коллекций.

Да: полностью поддерживается Да: полностью поддерживается Да: полностью поддерживается Да: полностью поддерживается Да: полностью поддерживается Да: полностью поддерживается Да: полностью поддерживается Да: полностью поддерживается
Combine Да: ассоциативная и коммутативная агрегация.

Применение ассоциативной, коммутативной операции по всем значениям («глобально») или по всем значениям, связанным с каждым ключом («за ключ»). Может быть реализована с использованием ParDo, но часто существуют более эффективные реализации.

Да: эффективное исполнение Да: полностью поддерживается

Использует объединитель для предварительной агрегации для пакетной и потоковой передачи.

Да: полностью поддерживается

Использование функций CombarkByKey и агрегатов Spark.

Да: полностью поддерживается

По умолчанию преобразование Beam. В настоящее время нет эффективной предварительной агрегации(BEAM-935).

Да: полностью поддерживается Да: полностью поддерживается Да: полностью поддерживается Да: полностью поддерживается
Composite Transforms Да: пользовательские трансформационные подграфы

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

Частично: поддерживается через inlining

В настоящее время составные преобразования встроены во время выполнения. Структура позже воссоздана из имен, но другая информация об уровне преобразования (если она добавлена в модель) будет потеряна.

Частично: поддерживается через inlining Частично: поддерживается через inlining Частично: поддерживается через inlining Частично: поддерживается через inlining Да: полностью поддерживается Да: полностью поддерживается Частично: поддерживается через inlining
Side Inputs Да: дополнительные элементы, доступные во время выполнения DoFn

Боковые входы - это дополнительные ПК-фрагменты, содержимое которых вычисляется во время выполнения конвейера, а затем становится доступным для кода DoFn. Точная форма бокового входа зависит как от PCollectionView, используемого для описания шаблона доступа (interable, map, singleton), так и для окна элемента из основного ввода, который в настоящее время обрабатывается.

Да: некоторые ограничения по размеру потоковой передачи

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

Да: некоторые ограничения по размеру потоковой передачи

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

Да: полностью поддерживается

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

Да: ограничения по размеру

Никакой распределенной реализации и, следовательно, ограничений по размеру.

Да: полностью поддерживается

Implemented by merging side input as a normal stream in Gearpump

Да: полностью поддерживается Да: некоторые ограничения по размеру Да: полностью поддерживается
Source API Да: пользовательские источники

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

Да: полностью поддерживается

Поддержка включает функции автонастройки (https://cloud.google.com/dataflow/service/dataflow-service-desc#autotuning-features).

Да: полностью поддерживается Да: полностью поддерживается Да: полностью поддерживается Да: полностью поддерживается Частично: только ограниченный источник Да: полностью поддерживается Да: полностью поддерживается
Splittable DoFn Частично: DoFn, где обработка каждого элемента может быть разделена на параллели или приостановлена и возобновлена

Позволяет пользователям разрабатывать DoFn, обрабатывая один элемент порциями («ограничения»), выполняемые параллельно или последовательно. Это заменяет неограниченные и ограниченные API-интерфейсы Source, поддерживая все их функции на основе каждого элемента. See http://s.apache.org/splittable-do-fn. Выполняется проектирование по достижению паритета с исходным API в отношении сигналов прогресса.

Частично: поддерживается в потоковом режиме

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

Нет: реализация в потоковом режиме в ближайшее время Нет: не выполнено Нет: реализация в потоковом режиме в ближайшее время Нет: не выполнено Нет: не выполнено Нет: не выполнено Нет: не выполнено
Metrics Частично: пользовательские показатели

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

Частично: в пакетном режиме Dataflow поддерживает фиксированные и попытки счётчиков и распределений.

Матричные показатели не поддерживаются в пакетном режиме. Метрики пока не поддерживаются в потоковом режиме, но эта поддержка скоро появится ([BEAM-2059](https://issues.apache.org/jira/browse/BEAM-2059)).

Частично: поддерживаются все типы показателей.

Поддерживаются только попытки. Никаких фиксированных значений для показателей метрик

Частично: поддерживаются все типы показателей.

Поддерживаются только попытки. Никаких фиксированных значений для показателей.

Нет: не выполнено в раннере. Нет: не выполнено Частично: поддерживаются только попытки счётчиков Частично: Метрики поддерживаются только в локальном режиме. Частично: поддерживаются все типы показателей.

Поддерживаются только попытки. Никаких фиксированных значений для показателей.

Stateful Processing Да: хранение на ключ, за окно

Позволяет получить мелкий доступ к каждому ключу, постоянному состоянию каждого окна. Необходимо для определенных случаев использования (например, для больших объемов окон, которые хранят большие объемы данных, но обычно имеют доступ только к небольшим его частям, сложным машинам состояний и т.д.), Которые нельзя легко или эффективно устранять с помощью Combine или GroupByKey + ParDo.

Частично: без слияния окон

Состояние поддерживается для несовпадающих окон. SetState и MapState еще не поддерживаются.

Частично: без слияния окон

Состояние поддерживается для несовпадающих окон. SetState и MapState еще не поддерживаются.

Нет: не выполнено

Spark поддерживает состояние с ключом с помощью mapWithState (), поэтому поддержка должна быть простой.

Частично: без слияния окон

Состояние поддерживается для несовпадающих окон. SetState и MapState еще не поддерживаются.

Нет: не выполнено Частично: без слияния окон Частично: без слияния окон Частично: без слияния окон

Матрица совместимостей по вопросу "Где в момент события?"

Beam Model Google Cloud Dataflow Apache Flink Apache Spark Apache Apex Apache Gearpump Apache Hadoop MapReduce JStorm IBM Streams
Global windows Да: все время

Окно по умолчанию, которое охватывает все время. (В принципе, как традиционные пакетные случаи подходят в модели.)

Да: по умолчанию Да: поддерживается Да: поддерживается Да: поддерживается Да: поддерживается Да: поддерживается Да: поддерживается Да: поддерживается
Fixed windows Да: периодические, неперекрывающиеся

Окна с фиксированным размером, основанные на временной шкале. (Почасовая, ежедневная и т.д.)

Да: встроенный Да: поддерживается Да: поддерживается Да: поддерживается Да: поддерживается Да: поддерживается Да: поддерживается Да: поддерживается
Sliding windows Да: периодические, перекрывающиеся

Возможно перекрытие окон с фиксированными размерами на основе временной метки (каждую минуту используйте последние десять минут данных).

Да: встроенный Да: поддерживается Да: поддерживается Да: поддерживается Да: поддерживается Да: поддерживается Да: поддерживается Да: поддерживается
Session windows Да: активность

На основе всплесков активности, разделенных размером зазора. Разные за ключ.

Да: встроенный Да: поддерживается Да: поддерживается Да: поддерживается Да: поддерживается Да: поддерживается Да: поддерживается Да: поддерживается
Custom windows Да: пользовательские окна

Все окна должны реализовывать BoundedWindow, который определяет максимальную временную метку. Каждый WindowFn назначает элементы связанному окну.

Да: поддерживается Да: поддерживается Да: поддерживается Да: поддерживается Да: поддерживается Да: поддерживается Да: поддерживается Да: поддерживается
Custom merging windows Да: пользовательские слияния окон

Пользовательский WindowFn дополнительно определяет, как и как объединить окна.

Да: поддерживается Да: поддерживается Да: поддерживается Да: поддерживается Да: поддерживается Да: поддерживается Да: поддерживается Да: поддерживается
Timestamp control Да: метка времени для оконных стекол

Для преобразования группировки, такого как GBK или Combine, OutputTimeFn указывает (1), как комбинировать временные метки ввода в окне и (2), как объединить агрегированные временные метки при слиянии окон.

Да: поддерживается Да: поддерживается Да: поддерживается Да: поддерживается Да: поддерживается Да: поддерживается Да: поддерживается Да: поддерживается

Матрица совместимостей по вопросу "Когда во время обработки?"

Beam Model Google Cloud Dataflow Apache Flink Apache Spark Apache Apex Apache Gearpump Apache Hadoop MapReduce JStorm IBM Streams
Configurable triggering Да: пользователь настраивает

Пользователь может задавать триггер (вместо просто управляемых жестко настроенными значениями по умолчанию).

Да: полностью поддерживается

Полностью поддерживается в потоковом режиме. В пакетном режиме промежуточные триггерные срабатывания фактически бессмысленны.

Да: полностью поддерживается No Да: полностью поддерживается No Нет: бегун только для партии Да: полностью поддерживается Да: полностью поддерживается
Event-time triggers Да: относительно времени события

Триггеры, которые срабатывают в ответ на сигналы полноты времени события.

Да: в потоковой передаче, фиксированная зернистость в партии

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

Да: полностью поддерживается Нет Да: полностью поддерживается Да: полностью поддерживается Нет Да: полностью поддерживается Да: полностью поддерживается
Processing-time triggers Да: относительно времени обработки

Триггеры, которые срабатывают в ответ на время обработки.

Да: в потоковой передаче, фиксированная зернистость в партии

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

Да: полностью поддерживается Да: это родная модель Spark streaming

Spark обрабатывает потоки в микропаках. Размер микропакетов на самом деле является предварительно заданным фиксированным временным интервалом. В настоящее время бегун принимает первый размер окна в конвейере и устанавливает его размер как пакетный интервал. Любые последующие операции окна будут считаться временем обработки окон и будут влиять на запуск.

Да: полностью поддерживается Нет Нет Да: полностью поддерживается Да: полностью поддерживается
Count triggers Да: каждый элемент N

Триггеры, которые срабатывают после просмотра N элементов.

Да: полностью поддерживается

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

Да: полностью поддерживается Нет Да: полностью поддерживается Нет Нет Да: полностью поддерживается Да: полностью поддерживается
[Meta]data driven triggers Нет: в ответ на данные (BEAM-101)

Триггеры, которые срабатывают в ответ на атрибуты обрабатываемых данных.

Нет: поддержка ожидающих моделей Нет: поддержка ожидающих моделей Нет: поддержка ожидающих моделей Нет: поддержка ожидающих моделей Нет: поддержка ожидающих моделей Нет Нет: поддержка ожидающих моделей Нет: поддержка ожидающих моделей
Composite triggers Да: композиции одного или нескольких суб-триггеров

Триггеры, которые формируют другие триггеры в более сложных структурах, таких как логическое И, логическое ИЛИ, раннее / время / время и т. Д.

Да: полностью поддерживается Да: полностью поддерживается Нет Да: полностью поддерживается Нет Нет Да: полностью поддерживается Да: полностью поддерживается
Allowed lateness Да: привязка времени к времени жизни окна

Способ связать полезное время жизни окна (время события), после которого могут быть материализованы любые неработающие результаты, содержимое окна может быть собрано в мусор, и любые дополнительные поздние данные, которые поступают в окно, могут быть отброшены.

Да: полностью поддерживается

Полностью поддерживается в потоковом режиме. В пакетном режиме данные не задерживаются.

Да: полностью поддерживается Нет Да: полностью поддерживается Да: полностью поддерживается Нет Да: полностью поддерживается Да: полностью поддерживается
Timers Да: отложенные обратные вызовы обработки

Мелкозернистый механизм для выполнения работы в какой-то момент в будущем, как во время события, так и во время обработки. Полезно для организации задержанных событий, тайм-аутов и т. Д. В сложных состояниях с ключом для каждого окна состояний.

Частично: без слияния окон

Dataflow поддерживает таймеры в несовпадающих окнах.

Частично: без слияния окон

Flink Runner поддерживает таймеры в несовпадающих окнах.

Нет: не выполнено Нет: не выполнено Нет: не выполнено Нет Частично: без слияния окон Частично: без слияния окон

Матрица совместимостей по вопросу "Как связаны уточнения?"

Beam Model Google Cloud Dataflow Apache Flink Apache Spark Apache Apex Apache Gearpump Apache Hadoop MapReduce JStorm IBM Streams
Discarding Да: панели отбрасывают элементы при запуске

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

Да: полностью поддерживается Да: полностью поддерживается Да: полностью поддерживается

Поток Apache Spark изначально отбрасывает элементы после обжига.

Да: полностью поддерживается Да: полностью поддерживается Нет: бегун только для партии Да: полностью поддерживается Да: полностью поддерживается
Accumulating Да

Элементы накапливаются в состоянии через несколько панелей для одного окна.

Да: полностью поддерживается

Требуется, чтобы накопленная панель помещалась в память, после прохождения через сумматор (если это необходимо)

Да: полностью поддерживается Нет Да: полностью поддерживается

Ограничение размера, см. Поддержку комбинирования.

Нет Нет Да: полностью поддерживается Да: полностью поддерживается
Accumulating & Retracting Нет: накопление плюс ретракция старых панелей (BEAM-91)

Элементы накапливаются между несколькими панелями, а старые испускаемые значения убираются. Также известен как «backsies»

Нет: поддержка ожидающих моделей Нет: поддержка ожидающих моделей Нет: поддержка ожидающих моделей Нет: поддержка ожидающих моделей Нет: поддержка ожидающих моделей Нет Нет: поддержка ожидающих моделей Нет: поддержка ожидающих моделей

Запуск Apache Beam

Запуск Apache Beam для Java

  1. Настройте среду разработки
    1. Загрузите и установите Java Development Kit (JDK) версии 1.7 или новее. Убедитесь, что переменная среды JAVA_HOME установлена и указывает на вашу установку JDK.
    2. Загрузите и установите Apache Maven, выполнив руководство по установке Maven для вашей конкретной операционной системы
  2. Получить код WordCount
    1. Самый простой способ получить копию конвейера WordCount - использовать следующую команду для создания простого проекта Maven, который содержит примеры Beam's WordCount и строит по самой последней версии Beam:
$ mvn archetype:generate \
  -DarchetypeGroupId=org.apache.beam \
  -DarchetypeArtifactId=beam-sdks-java-maven-archetypes-examples \
  -DarchetypeVersion=2.2.0 \
  -DgroupId=org.example \
  -DartifactId=word-count-beam \
  -Dversion="0.1" \
  -Dpackage=org.apache.beam.examples \
  -DinteractiveMode=false 

Это создаст каталог-счет-лучевой каталог, содержащий простой pom.xml и ряд примеров конвейеров, которые подсчитывают слова в текстовых файлах.

Запуск Apache Beam для Python

Проверьте версию Python

Beam SDK для Python требует Python версии 2.7.x. Убедитесь, что у вас есть версия 2.7.x, запустив:

 python --version

Установить pip

Установите pip - менеджер пакетов Python. Убедитесь, что у вас есть версия 7.0.0 или новее, запустив:

 pip --version

Установка виртуальной среды Python

Для первоначальных экспериментов рекомендуется установить виртуальную среду Python. Если у вас нет virtualenv версии 13.1.0 или новее, установите его, запустив:\

 pip install --upgrade virtualenv

Если вы не хотите использовать виртуальную среду Python (не рекомендуется), убедитесь, что setuptools установлен на вашем компьютере. Если у вас нет setuptools версии 17.1 или новее, установите его, запустив:

 pip install --upgrade setuptools

Установка Apache Beam

Создание и активация виртуальной среды

Виртуальная среда - это дерево каталогов, содержащее собственный дистрибутив Python. Чтобы создать виртуальную среду, создайте каталог и запустите:

 virtualenv /path/to/directory

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

Чтобы активировать виртуальную среду в Bash, запустите:

 . /path/to/directory/bin/activate
Загрузка и установка

Установите последнюю версию Python SDK из PyPI.

pip install apache-beam

Источники

  1. Apache Beam Execution Model// The Apache Software Foundation URL: https://beam.apache.org/documentation/execution-model/ (Дата обращения: 22.12.2017)
  2. Beam Capability Matrix // The Apache Software Foundation URL:http://https://beam.apache.org/documentation/runners/capability-matrix/ (дата обращения: 22.12.2017)