Apache Beam支持多個亞軍後端，包括Apache Spark和Flink。我熟悉Spark/Flink，我正在嘗試查看Beam的批處理優點/缺點。Apache Beam對Spark/Flink進行批處理有什麼好處？
看着Beam word count example，它感覺它與本機的Spark/Flink等價物非常相似，可能稍微有些冗長的語法。
我目前沒有看到選擇Beam作爲Spark/Flink這種任務的好處。目前爲止唯一的觀察結果是：
是否有更好的例子來突出梁模型的其他優點/缺點？有沒有關於失控如何影響性能的信息？
請注意，我並不是要求在流式方面存在差異，部分在this question中進行了介紹，並在this article（歸因於Spark 1.X）中進行了總結。
Beam增加了許多現有的引擎。
Unifying batch and streaming。許多系統可以同時處理批處理和流式處理，但他們經常通過單獨的API來處理。但是在Beam中，批處理和流式傳輸只是延遲，完整性和成本範圍上的兩點。沒有學習/重寫從批處理到流式處理的懸崖。所以如果你今天寫了一個批處理管道，但是明天你的延遲需要改變，那麼調整起來非常容易。你可以在Mobile Gaming examples中看到這種旅程。
的API，提高抽象水平：梁的API，集中於捕捉您的數據和邏輯性，而不是通過讓潛在的運行時泄漏的詳細信息。這對於可移植性來說是關鍵（參見下一段），並且還可以爲運行時在執行方式上提供很大的靈活性。類似ParDo融合（又名函數合成）是絕大多數跑步者已經做的基本優化。其他優化仍在爲一些跑步者實施。例如，Beam的Source APIs專門爲避免流水線內的分片過分指定而構建。相反，他們爲跑者提供了正確的機會，以動態平衡可用機器上的工作。這可以通過基本消除零散碎片來實現巨大的性能差異。一般來說，我們可以在跑步者身上建立的智慧越多，我們就會越好。隨着數據，代碼和環境的變化，即使是最仔細的手部調整也會失敗。
跨運行時的可移植性。：由於數據形狀和運行時需求是整齊分開的，因此可以通過多種方式運行相同的管道。這意味着，當您必須從內部部署轉移到雲端時，或者從經過驗證的真正系統轉移到最前沿時，最終不會重寫代碼。您可以非常輕鬆地比較各種選項，找到最適合當前需求的環境和性能組合。這可能是一個混合的事情 - 在開放源代碼運行器的前提下處理敏感數據，並在雲中管理服務上處理其他數據。
將Beam模型設計成對許多不同引擎有用的抽象是棘手的。梁既不是所有引擎的功能（太有限！）的交集，也不是聯合（太多的廚房水槽！）。相反，Beam試圖走在數據處理的最前沿，既能將功能推入運行時引擎，又能將模式拉出運行引擎。