三種大資料流處理框架選擇比較：Apache Kafka流、Apache Spark流和Apache Flink - quora

• 您是否已在另一個專案中使用這些框架之一？已經經歷過？然後評估它是否也適用於您的下一個專案。學習曲線要​​簡單得多（但也要了解這些專案的技術折衷）。
• 您是否已經使用Kafka進行訊息傳遞/資料提取（例如，匯入Hadoop，S3或Elastic）？問問自己，您是否真的需要基礎結構中的其他元件，或者Kafka原生技術（例如Kafka Streams或ksqlDB）是否也可以解決您的問題。優勢：只需執行一個基礎架構，就可以與一個供應商合作。
• 無論如何，大多數Spark和Flink專案都使用Kafka作為訊息傳遞和接收層。評估Spark或Flink是否提供其他/更好的功能來滿足您的需求。Spark專為“真正的批處理”而構建，對此仍然很棒。Flink非常適合進行更復雜的流處理作業（包括stream + batch）。
• Kafka Streams，Flink和Spark Streaming的功能重疊可能超過90％。所有這些都可以用於類似的用例。找出Flink是否能增加足夠的附加價值（再次，使用多個群集的主要缺點是您在基礎架構中還需要另一個系統，這導致運維和支援更加困難，尤其是在端到端關鍵業務交易中）。特別是對於業務應用程式的關鍵任務生產部署（例如即時付款），您將非常感激只支援一個部署。考慮一下一次語義（EOS）：僅使用Kafka本機EOS而不是組合用於這些事務的不同框架會更容易，風險也更低。
• 您需要哪種部署型別？Kafka Streams是一個庫包。輕鬆嵌入到任何現有（舊版）應用程式中，並易於構建輕量級但可擴充套件的新現代應用程式。但是您必須自己構建包裝器，或使用其他工具/框架（例如Spring Boot）。Spark和Flink均構建為具有自己基礎結構的分散式叢集。兩者都被“Dock化”以作為更輕量級的應用程式執行，但這並不是他們最初設計的目的。評估這種方法的權衡和成熟度！
• 不要忘了評估ksqlDB 。這是另一個Kafka本機流處理框架，結合了兩種方法的優點（Kafka Streams與Spark / Flink）：它是Kafka本機，不需要其他基礎結構。部署為單獨的，獨立的，可擴充套件的群集（但高可用性，保證的排序，一次準確的語義等，透過Kafka群集和內部Kafka主題進行管理）。

概要：
問問自己這些問題，並做出正確的決定。所有這些框架（Kafka Streams，ksqlDB，Flink，Spark）對於特定的用例和需求都是很棒的。在大多數基礎架構中，將其中的兩個或多個結合起來以解決各種不同的問題。
等等，Apache Beam呢？
Apache Beam是最小的公分母。如果要使用多個框架（或能夠遷移到GCP），那麼Beam是正確的方法。但是，如果您想為問題選擇最佳的流處理框架，則不會。
例如，幾年前，Kafka Streams社群決定不實施Beam介面，因為這會限制功能和功能。