С учетом планов Google на свой Apache Beam, смогут ли они создать единую систему потоковой обработки данных?

Открытые проекты и стандарты хороши тем, что есть из чего выбрать. Вот и сообщество Open Source 10 января торжественно причислило Beam к категории проектов «высшего уровня» (это означает, что в Apache ему уделяют повышенное внимание).

Beam является воплощением стратегии открытых технологий, которую с недавних пор взяла на вооружение Google. По традиции компания держит свою технологию в секрете, публикуя, как правило, исследовательские работы, которые сообщество Open Source затем анализирует под микроскопом и заново претворяет в жизнь. Так были запущены HDFS (основополагающая файловая система Hadoop) и MapReduce.

Но с недавних пор Google стала делиться своими сокровищами, и этот шаг вовсе не случайно совпал с крепнущими намерениями компании конкурировать с Amazon с Microsoft в бизнесе облачных вычислений. Будучи соперником Amazon, Google не может опираться исключительно на проприетарные технологии: она должна сделать ставку на проекты, которые быстро наберут популярность среди разработчиков, и дорогу в жизнь им проложит, скорее всего, именно Open Source.

Помимо ОС Android, которая долгое время была самым известным открытым проектом Google, более действенными средствами привлечения клиентов в облако компании стали программные инструменты TensorFlow и Kubernetes. Собственно говоря, Google явно озвучивает этот факт в блоге Why Apache Beam (зачем нужен Apache Beam).

Beam — это набор интерфейсов, обособляющий процесс создания конвейера обработки данных от фактического движка, на котором он будет работать. Он включает в себя абстракции для задания характеристик конвейера данных, самого потока данных (наподобие устойчивых распределенных наборов данных — Resilient Distributed Datasets, RDD — в Spark), функций преобразования, «исполнителей» (runner, вычислительный движок), а также источников данных и пунктов конечного назначения для результатов. Это один из растущего множества методов опровержения лямбда-архитектуры (при которой пакетный уровень анализа данных отделен от сервисного), посредством которого на базе одного и того же кода, внутри одного и того же кластера можно сочетать обработку данных в реальном режиме с пакетной обработкой (и даже интерактивным доступом к данным).

Несмотря на то, что проект находится на ранних стадиях развития, большинство функций, поддерживаемых Beam, можно выполнять внутри процессингового сервиса Google Cloud Dataflow, а также на открытых движках Spark, Flink и Apex. Принцип действия проекта — напиши код один раз и запускай его где угодно (или, по крайней мере, на вычислительном движке по своему усмотрению) — сильно напоминает оригинальный девиз Java («Write once, run anywhere»). Будем надеяться, что Google преуспеет в этой попытке чуть больше, чем Sun.

Прежде, чем возрадоваться, имейте в виду, что подобно тому, как проект Apache YARN вырос из MapReduce, библиотека Beam позаимствовала SDK и модель потока данных из собственного сервиса Google — Cloud Dataflow. При ближайшем рассмотрении выясняется, что в движках Apache Apex, Flink и Spark Streaming модель программирования Beam поддерживается от силы на 70%. Самый внушительный пробел наблюдается с функциями, основанными на настоящей потоковой обработке данных (способности обрабатывать одно событие за раз и задавать дискретные временные интервалы) — при их применении режим микро-пакетной обработки Spark Streaming либо вообще не работает, либо требует доработок и дописывания кода.

Однако потоковая технология постоянно развивается, вот и движок Structured Streaming, вошедший в релиз Spark 2.0, реструктурирует Spark Streaming таким образом, чтобы вскоре поддержать истинную потоковую обработку данных, поставив под сомнение некоторые из утверждений Google.

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

Разработчики каждого из этих вычислительных движков — Google Cloud Dataflow, Spark, Flink и Apex — хотят, чтобы вы все нужды закрывали именно с помощью их продукта. И здесь Beam, несмотря на общность проектов, составит конкуренцию Spark — он-то работает со Spark, но теоретически он работает еще и с другими движками. И в случае успеха он может лишить Spark роли вашего главного вычислительного инструмента для больших данных.

Spark получил фору в виде хорошего старта: в нем сотни библиотек, не считая быстрорастущей базы дополнительных функций. Но Spark может далеко не все: например, хоть он и работает с SQL, движки Impala или HAWQ все равно эффективнее при решении таких задач, как произвольный доступ и выполнение интерактивных запросов.

Можно ли сказать, что Spark ушел в отрыв и его уже не остановить? С запуском Beam компания Google хочет дать вам возможность не спешить с выводами. И, разумеется, Google не упустит шанса навязчиво напомнить о своем превосходстве с помощью тестов на производительность, демонстрирующих, насколько ее собственный процессинговый сервис Cloud Dataflow обходит Spark по быстроте и удобству программирования (хотя сравнительная таблица Google, опубликованная около года назад, на тот момент еще не учитывала Spark 2.0, а конкретно Structured Streaming).

Для разработчиков актуален другой вопрос: захотят ли они изучить свойства очередного уровня абстракции для своего кода? С одной стороны, их манят смутные перспективы общего API к движкам потоковой обработки, который теоретически позволит им смешивать ингредиенты на свой вкус, а точнее, подгружать и выгружать данные по своему усмотрению. Ведь Google разработала Beam по принципу переносимости, так что рабочие нагрузки по потоковой обработке данных можно переносить как внутрь самого Cloud Dataflow, так и из него.

Однако, как и в случае с любым API, сделанным по принципу швейцарского ножа (один инструмент для разных нужд), добиться взаимной совместимости будет нелегко. Идею абстрагирования логики от исполнения кода новой не назовешь — она была голубой мечтой приверженцев сервисно-ориентированной архитектуры. А недавнее появление микросервисов и контейнеров показало, что эта мечта все еще актуальна.

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