[英]Improve performance by using Flink instead of Kafka Streams when Source and Sink are in Kafka?
假設我有通過 Kafka 主題輸入的數據，並且 output 數據也將發送到 Kafka 主題，那么在什么情況下 Flink 能夠比 Kafka Streams 更快地處理數據？ 至少在消耗和生產時間方面，我不認為 Flink 會比 Kafka Streams 快。
Flink 和 Kafka Streams 都建立在相同的 Producer 和 Consumer API 之上，因此在一定程度上它們的行為相似。 一旦進入特定的 API/DSL，堆棧跟蹤就會變得更加嵌套。
除了記錄序列化之外，與 Kafka 的 KSQL 相比，Flink 可以執行更多任務，例如使用 Flink SQL，但在這些情況下，您正在管理外部集群。
就個人而言，我發現 Kafka Streams 的開發和維護速度更快，因為應用程序本身是可部署的單元，而不是提交到可能被某些調度程序搶占的資源池的東西。 但如果你想使用的不僅僅是 JVM 語言，那么你需要冒險使用 Flink 甚至 Beam。 而那些其他語言會更慢，因為代碼將與那些本地 Java 庫交互。
將Kafka用作Flink的輸入源是否會成為性能瓶頸？
[英]Is using Kafka as an input source for Flink a performance bottleneck?
flink：處理背壓（來源：kafka，sink：elasticsearch）
[英]flink: handling backpressure (source: kafka, sink: elasticsearch)
Flink 應用程序在工作中擁有多個數據/密鑰流都共享同一個 Kafka 源和接收器是否安全？
[英]Is it safe for a Flink application to have multiple data/key streams in s job all sharing the same Kafka source and sink?
聲明:本站的技術帖子網頁，遵循CC BY-SA 4.0協議，如果您需要轉載，請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.
