Twitter Heron閱讀筆記
說明：本文是《Twitter Heron: Stream Processing at Scale》的閱讀記錄整理，再結合網上其他資料整理而成，文中圖檔主要來自Heron論文和InfoQ上的宣傳資料。
Storm的問題所在
Worker級别
Storm在worker設計上的問題應該是最多的。
- 所有task都一視同仁，無法對單個Task進行資源設定，會造成比較嚴重的資源浪費。拓撲越複雜，資源浪費越多。
- Task之間互相影響，單個Task故障會導緻整個worker故障，進而産生連鎖反應，導緻其他worker也故障。
- 日志混合列印，worker的日志中，有spout和bolt的所有日志，比較亂，也比較多，對于問題定位和調試分析都是不利的。
- 對于dump等比較耗時的操作，會導緻jvm暫停，然後worker的心跳會暫時無法寫入，supervisor會誤以為worker已經故障，會kill worker。
一個tuple在worker中處理要經過多個線程，比較繁瑣，并且資料在多個線程之間切換比較低效。
至少會有四個線程：
Upstream thread：入口接收資料線程
Downstream thread：資料發送總出口
User logic thread：使用者邏輯線程
Send thread：emit線程
Nimbus
- Nimbus任務過多，包含資源排程，jar包和序列化檔案分發，metics彙聚，拓撲計數器等功能，在拓撲很多的情況下，很容易成為瓶頸
- 不支援資源隔離和資源預留，多個拓撲之間會互相影響。
- 和zookeeper之間會儲存大量連接配接，頻繁也會也會導緻zookeeper成為瓶頸
Nimbus是單點
注：Nimbus HA在社群1.0版本中已經實作
缺少背壓機制(BackPressure)
三種背壓機制實作
效率
- 單個tuple在整個tuple tree中如果在任何一個地方失敗，都會從最開始的位置重發
- 垃圾回收周期過長，導緻時延高和tuple失敗
- Worker中的隊列過多，導緻隊列之間互相競争。
Heron架構設計
資料模型和API設計
資料模型和Storm保持一緻，仍然包含spout和bolt的設計，twitter認為這是一個好的設計，是以仍然得以保留。
Heron 中的Toploogy就相當于資料庫中的邏輯執行計劃。隻有在實際執行的時候才會變成實體執行計劃。
在tuple的處理上，仍然和Storm保持一緻，提供至少一次和最多一次的兩種可靠性機制。
API完全相容Storm，Twitter從Storm到Heron遷移隻花了三個月就完成了全部遷移。
整體架構
Heron的整體架構如上圖所示，拓撲送出之後，會通過排程器将topology分發到不同的節點。
以前的Storm有一個很大的缺點就是無法內建在Yarn或者Mesos上，即使後面有了Storm On Yarn也不是很理想的方案。資源仍然無法合理利用，還有多租戶功能都依賴于資源管理的權限而無法實作。
Heron從架構上就解決了該問題，Scheduler就是一個Yarn或者Mesos的排程器。
拓撲總體架構上上圖所示。
整個拓撲由一個Toplogy master和多個Container構成，拓撲中的運作邏輯就跑在Container中。一個continer就是一個資源隔離單元，包含了預留的CPU和記憶體資源。
Topology Master
負責管理目前拓撲，可以有多個執行個體，主備方式部署。
管理目前拓撲的路由資訊，同時也會彙聚收集metrics資訊。同時還包含拓撲的監控。
Stream Manager
Container内的獨立程序。
負責tuple的有效路由，每個Heron Instance負責連接配接本地Stream Manager接收和發送資料，這種收發是通過protobuffer實作的。同時提供本地直接通訊方式。
提供Spout級别的背壓機制，當流量過大，Heron處理不過來時候，從入口上減少資料量。在每個Socket channel上提供應用程式的buffer，并在此基礎上加入高水位和低水位功能，當buffer中的資料超過高水位之後，背壓觸發，減少Spout的入口資料，直到降低到低水位以下。
Heron Instance
Heron Instance也是一個獨立程序，主要用來處理使用者邏輯，内部有兩個線程，一個網關線程用于資料發送，發送 Stream Manager接收和發送資料，還有Metric manager用到的監控統計資訊。
Metrics Manager
獨立線程，收集各個Heron Instance的監控統計資訊。
啟動順序和故障恢複
- 在Yarn，mesos，aurora中的多個節點上申請資源
- Topology Master啟動，并由主在zookeeper上寫入資料，可以被其他 Stream manager發現。
- 啟動Stream Manager并且連接配接zookeeper監控topology master資訊
- 當所有stream manager都連上Topology master之後，Toplogy master開始進行任務配置設定，當邏輯計劃轉為實體執行計劃，将資訊放入zookeeper
- 一旦配置設定結束，Stream Manager從zookeeper中擷取配置設定資訊，以幫助每Stream Manager去發現彼此。
- 一旦每個Strema Manager互相建立連接配接之後，啟動Heron Instance程序，發現本地 stream manager, 下載下傳自己的實體執行計劃并開始執行。當所有的Heron instance都初始化成功之後，才開始執行。
如果Topology master故障，容器會重新啟動，同時還會觸發主備選舉。Stream manager會重新發現它。
Stream manager故障，程序重新開機，重新發現Heron Instance和topology master。
Heron Instance故障，重新啟動，重新發現本地stream manager。
多程序的部署方式避免了strom 中任何錯誤導緻整個worker退出問題。
Heron在twitter上的增強
Heron tracker
通路拓撲資訊，儲存拓撲中繼資料資訊，監控拓撲健康狀态和拓撲的遷移。負載均衡情況
Heron UI
Storm UI的增強。
Heron Viz
用于收集和檢視拓撲的metrics資訊提供Dashbord。
性能對比
參見論文和Heron宣傳材料。
附錄
1) Twitter Heron: Stream Processing at Scale
2) http://www.infoq.com/cn/presentations/twitter-heron-streaming-at-scale