推特大規模應用的流處理框架：Apache Heron

與Storm關係
Twitter 將其構建的“下一代 Storm”專案分享給Apache。這是 Twitter 的一個內部團隊對 Apache Storm 進行的徹底重寫。作為開源專案歷史回顧，Apache Storm 最初由一家名為 Backtype 的初創公司構建，該專案由 Backtype 的技術創始人 Nathan Marz 領導。然後，Backtype 被 Twitter 收購，Storm 成為 Twitter 大規模流處理（推文、推文分析和其他事情）的主要元件。
然而，在某個時刻，Nathan Marz 離開了 Twitter，另一組工程師試圖在 Twitter 內部重新思考 Storm。當時還有很多圍繞 Apache Mesos 的工作正在進行。Heron 是他們對 Storm 的“重新思考”的合併，同時也使使用 Mesos 管理類似 Storm 的 Heron 叢集成為可能。
很多 Storm 是用 Java 編寫的，但“核心”是用 Clojure 編寫的。與其說是社群“機會”，不如說是放棄 Clojure 的“決定”。我的理解是，Storm 的生產採用者之一阿里巴巴做了一個從 Clojure 到 Java 的清潔移植，他們稱之為 jstorm。然後他們將該實現捐贈/提供給了 Apache Storm 專案，該專案決定基於它構建 Storm 2.x 系列。所以 Storm 1.x 仍然擁有 Clojure 核心，沿襲原始 Backtype 版本，但 2.x 來自 jstorm。Storm 2.x 的一大重點是大規模效能、延遲和背壓管理。與此同時，在 Storm 2.x 成型之前，Heron 作為一個專注於效能的 Storm 替代品而出現，它的 API 與 Storm 相容。
同時，Storm 在 1.x 系列中變得非常非常穩定，然後在 2.x 系列中從 Clojure 到 Java 進行了乾淨的重寫，主要是為了進一步提高效能。上一個穩定版/主要 Storm 版本是在 2020 年。
Storm 提供了流處理程式設計 API、多語言線協議和叢集管理方法。但是某些叢集計算問題現在可能可以在基礎設施層得到更好的解決。（比如Storm是在整個容器+docker+k8s專注於雲操作之前開發的。）Storm解決的核心問題：將資料處理建模為計算圖；執行緒、程式和節點之間的高速網路通訊；訊息傳遞保證和重試能力；可調並行性；內建監控和日誌記錄；以及更多。
Heron 與 Apache Storm 的 API 相容，因此遷移不需要更改程式碼。
 

定位區別：

• - Hadoop 是一個生態系統。
• - Kafka 是一個分散式日誌。
• - Storm/Heron、Samza 和 Flink 是流處理引擎。
• - Spark 是一個 Map/Reduce 框架，它使用記憶體來快取計算，以提供比其他基於磁碟的框架的一些效能提升。如果您眯眼足夠用力，它還可以進行一些流式計算。

流處理用處：
流處理的標準用例是：

• 1.豐富事件流。假設您有一個帶有 IP 地址欄位的日誌記錄流。在將日誌傳送到 Elasticsearch 之前，您希望豐富地理位置。
• 2. 視窗聚合。也許您有一個發出“登入”事件的應用程式，並且您想檢測彼此在 X 分鐘內來自不同 IP 地址的登入嘗試。
• 3. 加入多個事件流。您有多個不同的事件流，並且希望使用一些通用的連線鍵（可能是會話 ID 或類似的東西）將它們連線在一起，以計算聚合所有這些的指標。