作者：劉旭晖 Raymond 轉載請注明出處
Email：colorant at 163.com
BLOG：http://blog.csdn.net/colorant/
== 目标問題 ==
MillWheel的設計目标是提供一個大規模分布式的低延遲流式資料處理架構，基本的要求包括：
- 資料的及時可用性 - 也就是低延遲啦，盡可能避免不必要的中間緩沖層造成的資料延遲
- 全局可用的資料持久性API - 主要用來處理各種需要資料Buffer的場合，如Window, join類操作
- 能處理亂序到達的資料 - 即資料非嚴格按照來源時間戳排序到達
- 保證資料滿足嚴格一次投遞(exactly-once delivery)要求 - 也就是說對應用程式而言，資料不會遺漏，也不會重複接收，減輕應用程式的實作負擔
== 核心思想 ==
資料流程
和其它的Streaming Processing系統 (e.g. storm) 類似 ，MillWheel的資料處理流程架構基本上就是一個由使用者自定義的處理單元（MillWheel裡叫computation）按照一定的拓撲結構連接配接在一起的一個有向圖
computation之間的資料流以(key,value, timestamp) 這樣的三元組為機關組成，每個computation都可以按Key的範圍動态的分布在多個的節點上運作。
來自同一個KEY的資料按照時間戳順序由一個處理節點單獨處理，來自不同key的資料則可以并發在不同的節點上處理，到這裡為止，和其它的流式處理系統基本大同小異
亂序資料的處理
MillWheel中差別于其它相似系統的根本，大概是它的Low WaterMarks（低水位？）這樣一個概念，其核心思想是針對分布式環境下，各個資料來源由于網絡延遲或其它種種原因，同類資料不能保證嚴格按照時間戳順序到達處理節點，是以有必要知道什麼時候特定時間範圍的資料在處理節點上已經完全擷取完畢。以保證各種依賴于時間順序或資料完整性才能正常工作的應用的運作。
Low WaterMarks基于資料處理單元之間的資料流來定義，它辨別了目前資料流中最老的未被處理的資料包的時間戳，也就是說它試圖保證在目前資料流中，不會再産生時間戳上更老的資料包。後續的節點基于low watermarks資訊就可以判斷目前已接收資料是否完備。
時間戳的最早來源來自資料輸入子產品 （MillWheel中叫Injector），injector自身因各種資料來源的不同，有各自的時間戳生成方式，是以很可能不能絕對保證不違反Low WaterMarks的要求，這時候系統架構可以忽略後續違反低水位要求的資料包，也可以由應用程式自行處理這些例外資料包。
資料持久化
對于一個流式處理架構來說，常常要遇到的問題就是如何擷取曆史資料用于各種window類運算或其它依賴于曆史狀态的運算，很容易想到的解決方案就是将曆史資料持久化後在後續運算中在擷取出來，此外資料持久化也是防止節點崩潰以及容錯處理的一種有效手段
在MillWheel中，當持久化作為Exactly-oncedelivery的實作手段之一使用時（用來記錄已經處理過的資料，以及崩潰恢複曆史狀态等）資料的持久化可以由架構在資料流輸出時（upstream backup）全局自動完成。如果應用程式本身對Exactly-once delivery沒有要求，也可以按需僅對部分資料流進行持久化。這一點，相對Spark streamming來說，使用起來更加靈活一些
MillWheel使用Big Table/Spanner等系統作為持久化的手段，主要針對一次寫，多次讀這樣的應用模式。
資料處理模式
MillWheel的資料處理單元主要對使用者提供了兩種資料處理的應用模式：
一是按資料包三元組觸發使用者處理函數，就是來一個包處理一次了。比較接近Storm的概念
二是按時間視窗或絕對時間（Wall time）觸發使用者處理函數，這種模式類似于Spark Streaming這樣的小批量處理方式
這兩種模式也可以在一個處理單元内部混合使用，簡單來說比如按資料包觸發計數，然後按時間視窗觸發，在特定時間間隔向下遊發送計數包之類。從應用模式上來說，相對比較靈活
== 小結 ==
總體而言，MillWheel的總體思路類似于其它開源流式處理系統，但是強化了對資料嚴格一次投遞的要求以及對亂序資料的有效處理，同時在資料持久性方面提供了較大的靈活性。這些方面的要求和實作，應該說與Google在以往的各種架構中一貫表現出來的學術嚴謹性保持了一緻。