[open-falcon] 在 open-falcon 監控系統中看到 lambda-architecture 的影子

這 

個人的工作，是基於 open-falcon 發展適合公司內部使用的監控軟體，每次因為工作的需求，要在 open-falcon 上增加功能時，我就不由得開始思考，這樣子加功能好嗎？會不會不小心破壞了所謂的「概念一致性」(conceptual integrity)？那什麼是最重要的「概念」呢？哪些是可以妥協？哪些是不該妥協的？

網路上介紹 open-falcon 的文章裡，有一篇是講，編寫 open-falcon 的構思過程。我也提了，從抽象的層次看待 open-falcon ，它像是什麼。目的是希望提出抽象層次的觀點，講述其概念一致性。日後在思考增加新功能時，優先考慮不傷害概念一致性的解法。

 

左側兩張圖，是大數據計算常使用的 lambda-architecture 計算模型。概念是，大數據分析系統收集資料之後，將資料分成兩份，一條路是走 batch view ，另一條路是走 real time view。

其中，batch view 因為要用完整的資料做批次處理的關系，資料的處理會略有延遲。這段延遲的時間，如果還是有提供運算結果的需求，就由 real time view 的模組來提供資料。

這樣子處理大數據的模型，我彷彿也在 open-falcon 裡看到了「似曾相似的東西」。參考右圖。就是 graph 和 judge 。其中，graph 類似於 batch view 。一方面，graph 某種程度地可以保存一年的資料，也算是 immutable data。graph 的 batch view 是用 RRD tool 做的。對資料做了某些程度的篩選，特別適合用來畫圖。所以圖就是 open-falcon lambda architecture 的 batch view 或稱 precompute view 。

judge 處理 stream data ，而且會做「實時告警」，也就是一查到符合告警條件，就會立刻觸發。 judge 做的工作，是對不斷送進來的資料流做是否觸發告警條件的檢查。 judge 產生的告警，則可以視為是一種 real time view 或 incremental view 。

略有不同的地方，是大數據的 lambda architecture 其實暗示了 batch view 和 real time view 都通過 serving layer 來呈現，所以使用者不知道裡頭存在了這兩種運算模組，甚至感覺這是同樣的模組做出的運算結果。另一方面，操作 open-falcon 的使用者，其實也未必分得清楚，繪圖功能和告警功能是在兩個不同的模組獨立計算的。