Twitter 新一代流處理利器——Heron 論文筆記之Heron架構
标簽（空格分隔）： Streaming-process realtime-process
Heron Architecture
Heron 架構如下圖：
使用者編寫釋出topoloy到Aurora排程器。每一個topology都作為一個Aurora的job在運作。每一個job包括幾個container，這些container由Aurora來配置設定和排程。第一個container作為Topology Master，其他的Container作為Stream Manager。所有的中繼資料資訊包括誰送出的job，job的運作資訊，啟動時間等等都會儲存在Zookeeper中。
每個Heron Instance都是用java寫的，且都是JVM程序。Heron程序之間用protocol buffers進行通信。
Heron Instance
值得一提的是每個HI都是隻跑一個task，即要麼是spout要麼是bolt。這樣有利于debug。
這種設計也為以後資料的複雜性考慮，當以後資料複雜性變高的時候，我們還可以考慮用其他語言來實作HI。
HI的設計有以下兩種：
- 單線程
- 雙線程
Single-threaded approach
主線程有一個TCP channel與本地的SM通信，等待tuple的到來，一旦tuple來了，就會調用使用者的邏輯代碼來執行，如果需要輸出，該線程就會緩存資料，直到達到門檻值，然後輸出到downstream的SM。
這種設計簡單，但是也有一些缺點，由于某些原因，使用者的邏輯可能被block：
- Invoking the sleep system call for a finite duration of time
- Using read/write system calls for file or socket I/O
- Calling thread synchronization primitives
Two-threaded approach
顧名思義，兩個thread：Gateway thread 和Task Execution thread，如下圖：
Gateway thread負責資料的輸入輸出和通信
Task Execution thread則負責運作使用者邏輯代碼
Gateway thread要和Task Execution thread要進行資料通信，他們之間通過如上圖的三種queue來通信。Gateway thread用data-in往Task Execution thread輸入資料，Task Execution thread用data-out往Gateway thread，metrics-out是用Task Execution thread用來收集metric然後往Gateway thread發送。
Toplogy Master
TM（Topology Master）主要負責topology的throughout，在startup的時候，TM把資訊存放在Zookeeper上，以便其他程序能夠發現TM。是以TM有如下兩個目的：
- 阻止多個TM的産生
- 允許其他屬于該topology的程序發現該TM
Topology Backpressure
Heron提供一種背壓機制來動态調整資料流動的速率。這種機制可以讓topology中的各個components以不同speed來跑。也可以動态更改它的speed。
TCP Backpressure
這個政策利用TCP視窗的機制來梳理HI（Heron Instance）和其他Componet的背壓。所有的消息都是通過TCP sockets來做通信，如果某個HI處理緩慢，那麼它的本地接收buffer就會被裝滿，在這個HI上遊和資料通信的SM也會發現這個然後填滿發送的buffer，這樣該HI的處理速度就加快了。
Spout backpressure
這個背壓政策是和TCP背壓政策協同使用的，當SM發現它本地的HI運作慢時，SM就會通知本地的SPout停止讀取資料，那麼往該Spout發送資料的SM的buffer就會阻塞以緻fill up，這是受影響的SM就會發送一條start backpressure的msg到其他與之相連的SM，當其他SM收到該msg時就會告訴他們本地的Spout不再讀取資料，當上遊緩慢的HI速度趕上來之後，SM再發一個stop backpressure的msg到下遊，然後停止backpressure。
當topoloy處于backpressure模式時，它的運作速度取決于最慢的那個HI。
Architecture Features: Summary
- First, the provisioning of resources (e.g. for containers and even the Topology Master) is cleanly abstracted from the duties of the cluster manager, thereby allowing Heron to “play nice” with the rest of the (shared) infrastructure.
- Second, since each Heron Instance is executing only a single task (e.g. running a spout or bolt), it is easy to debug that instance by simply using tools like jstack and heap dump with that process.
- Third, the design makes it transparent as to which component of the topology is failing or slowing down, as the metrics collection is granular, and lets us easily map an issue unambiguously to a specific process in the system.
- Fourth, by allowing component-level resource allocation, Heron allows a topology writer to specify exactly the resources for each component, thereby avoiding unnecessary over-provisioning.
- Fifth, having a Topology Master per topology allows each topology to be managed independently of each other (and other systems in the underlying cluster). In additional, failure of one topology (which can happen as user-defined code often gets run in the bolts) does not impact the other topologies.
- Sixth, the backpressure mechanism allows us to achieve a consistent rate of delivering results, and a precise way to reason about the system. It is also a key mechanism that allows migrating topologies from one set of containers to another (e.g. to an upgraded set of machines).
- Finally, we now do not have any single point of failure.
Performance
直接看圖吧
Reference
Twitter Heron: Stream Processing at Scale
如有錯誤地方還請指正，不勝感激~~
上一篇：Twitter 新一代流處理利器——Heron 論文筆記之Storm Limitations