Які переваги Apache Beam над Spark / Flink для пакетної обробки?

Apache Beam підтримує декілька бікендів бігунів, включаючи Apache Spark та Flink. Я знайомий з Spark / Flink і намагаюся зрозуміти плюси / мінуси Beam для пакетної обробки.

Дивлячись на приклад підрахунку слів Beam , він відчуває, що він дуже схожий на рідні еквіваленти Spark / Flink, можливо, з трохи більш багатослівним синтаксисом.

На даний момент я не бачу великої вигоди від вибору Beam замість Spark / Flink для такого завдання. Єдине спостереження, яке я можу зробити на даний момент:

• Плюс: Абстракція за різними бэкэндами виконання.
• Недолік: Ця абстракція коштує меншою мірою контролю над тим, що саме виконується в Spark / Flink.

Чи є кращі приклади, які висвітлюють інші плюси / мінуси моделі Beam? Чи існує якась інформація про те, як втрата контролю впливає на ефективність?

Зауважте, що я не прошу розбіжностей у аспектах потокового передавання, які частково висвітлюються у цьому питанні та узагальнені в цій статті (застаріли завдяки Spark 1.X).

Є кілька речей, які Beam додає до багатьох існуючих двигунів.

• Об'єднання пакетного та потокового передавання. Багато систем можуть обробляти пакетні та потокові передачі, але вони часто роблять це за допомогою окремих API. Але в Beam пакетне та потокове передавання - це лише два пункти щодо спектру затримок, повноти та вартості. Там немає навчання / переписування скелі від пакетного до потокового. Отже, якщо ви пишете пакетний конвеєр сьогодні, але завтра вашу затримку потрібно змінити, це неймовірно легко відрегулювати. Ви можете побачити подібну подорож на прикладах мобільних ігор .

• API, що підвищують рівень абстракції : API Beam зосереджуються на зйомці властивостей ваших даних та вашої логіки, замість того, щоб пропускати деталі основного середовища виконання. Це одночасно є ключовим фактором для переносимості (див. Наступний абзац), а також може забезпечити велику гнучкість виконання під час виконання. Щось на зразок ParDo fusion (він же склад функцій) є досить базовою оптимізацією, яку переважна більшість бігунів вже робить. Інші оптимізації все ще застосовуються для деяких бігунів. Наприклад, API джерела Beamспеціально побудовані, щоб уникнути надмірної специфікації заточування в трубопроводі. Натомість вони дають бігунам потрібні гачки для динамічного збалансування роботи на наявних машинах. Це може суттєво змінити продуктивність, по суті, усуваючи осколки відсталих. Загалом, чим більше розуму ми можемо вбудувати у бігунів, тим краще нам буде. Навіть найретельніша настройка рук зазнає невдачі, оскільки дані, код та середовища змінюються.

• Переносимість в режимах виконання. : Оскільки форми даних та вимоги до часу виконання акуратно відокремлені, один і той же конвеєр можна запускати різними способами. А це означає, що ви в кінцевому підсумку не переписуєте код, коли вам доведеться переходити від попередньої до хмари або від перевіреної і справжньої системи до чогось на передньому краї. Ви можете дуже легко порівняти варіанти, щоб знайти поєднання середовища та продуктивності, яка найкраще відповідає вашим поточним потребам. І це може бути поєднанням речей - обробці конфіденційних даних у приміщенні з відкритим вихідним кодом та обробці інших даних про керовану службу в хмарі.

Розробити модель Beam як корисну абстракцію для багатьох різних двигунів складно. Балка не є ні перетином функціональності всіх двигунів (занадто обмежено!), Ні об’єднання (занадто велика кухонна мийка!). Натомість Бім намагається бути в авангарді того, куди йде обробка даних, одночасно просуваючи функціональність і витягуючи шаблони з середовищ виконання.

• Keyed State - чудовий приклад функціональності, який існував у різних двигунах та уможливлював цікаві та поширені випадки використання, але спочатку не був виражений у Beam. Нещодавно ми розширили модель Beam, включивши версію цієї функціональності відповідно до принципів дизайну Beam .
• І навпаки, ми сподіваємось, що Beam також вплине на дорожні карти різних двигунів. Наприклад, на семантику DataStreams Flink вплинула модель Beam (née Dataflow).
• Це також означає, що можливості не завжди будуть абсолютно однаковими у різних бігунів Beam у певний момент часу. Ось чому ми використовуємо матрицю можливостей, щоб спробувати чітко повідомити про стан речей.