真的有很久沒有更新部落格了，上一次更新還是2014年。那時候就在寫雲端計算君臨天下。感嘆變化太快，自己14-15年從storm到全棧工程師，到產品經理，現在又重回大資料，不勝唏噓。

      這兩年裡，許多新的開源系統釋出，平均1、2年技術棧都要變一下。當然，其中最火爆的莫過於spark了。spark集批量計算，實時計算，SQL計算，圖計算，機器學習與一身。以scala語言的易程式設計特點幾乎一統大資料"計算“領域的江湖。

      不過streaming始終還是以min batch來作為最小單位進行計算，實時性上更適合分鐘級的分析統計類應用。對於ms或者秒級實時的場景依然不太合適。當然目前實時計算領域還有一個flink設計上很牛逼，天然支援了狀態計算，只可惜社群不夠活躍，難以被大多數公司所採用。

      以上只是一個大致的概覽，回到本文的主角——Heron，storm的繼承者。沿用了storm的資料模型——經典spout-bolt模型。而又從架構上彌補了storm存在的缺點。

      1、資源最小單位——topology採用了程序的方式開併發，而不是以往的執行緒方式。利於資源隔離，debug，profilling以及troubleshooting等更加友好。但其實也有所失就是開程序開銷總是要比執行緒要大。

      2、資源約束——topologies會嚴格使用自己所allocate的資源，而不會佔用其他元件資源造成競爭，執行起來更加安全。當然安全的缺點就是可能會造成資源的浪費。這和虛擬機器超賣是一個道理，有利有弊

      3、相容性——完全相容storm的程式碼，甚至做到不改一行程式碼直接編譯後就能在Heron上執行

      4、背壓機制——分散式系統中元件的執行速度各不相同，背壓機制可以讓各個元件自適應，而不至於造成堆積(具體實現還待了解)

      5、效能——吞吐量和延遲上大幅提升。看論文是採用了一些避免瓶頸的做法，例如輕依賴zk，c++寫部分程式碼

      6、語義——最多一次，最少一次的語義。這一點相對spark來講是劣勢，和storm持平。exactly once目前看來是難點，Heron也正在實現中

      7、各種元件重新設計——Topology Master、Container、Stream Manager、Heron Instance、Metrics Manager、Heron Tracker

(1)Topology Master

      管理Topology的全生命週期，每個topology會開啟一個TM，多個Container，TM會在zk中註冊，TM會構建物理執行計劃分配給其他元件

(2)Container

      容器，一個topology會啟動多個容器。容器包含有Heron Instances，Steam Manager，Metrics Manager。容器就可以做資源格力

(3)Stream Manager

      Container中用來和其他Container網路互動的出口點

當然還有其他的一些元件：

Heron CLI、Heron Tracker、Heron UI。

這裡不得不提的是Heron UI，可以顯示當前的執行拓撲、執行速度、資源消耗，還可以知己看日誌，總體來說是靠向生產系統的監控體系。

先mark，以後再補充！