談談分散式運算的運算元層

標籤：分散式運算   流式計算   storm   spark   增量計算   

本文是我對分散式運算的運算元這層的一些認識和想法。因為最近自己的開發工作單位也是這方面相關的，公司內部有自研的類流式計算架構需要做一層運算元層。我主要分析的是流式系統上實現運算元這一點入手，對比現有計算架構和業界正在開展的項目，分析分析這件事的表面和背後深層的含義，以及可想象空間。

趨勢

Yahoo! 的Pig on Storm項目，讓Pig-latin能夠執行在Storm這種流式引擎上，最終使得Pig-latin能夠混用於流式計算和批次運算情境下。應該說，無論是Spark，Summingbird，還是Pig，都在嘗試做同一件事情：藉助自己的DSL或原語在流式和批量兩套引擎上表達(近)即時和離線資料處理能力。

Spark本身依賴RDD，實現了Spark Streaming這種小批StreamCompute，其DStream就是RDD，所以在Spark上寫批量作業和流式作業API自然是統一的。

Summingbird在API層面統一了Storm上和Hadoop上的作業，對於Hadoop上任務的編寫藉助的是Cascading，屬性上看更多的是一種適配的角色，雖然Summingbird也稱為Lambda Architecture的一種解決方案。

總結：表面上看，DSL需要支援不同的計算引擎，以達到運算元層面的混用，這是趨勢。那麼實現上的難度在哪呢？

挑戰

在流式系統上實現pig-latin這種本身就誕生於批次運算情境裡的DSL，對某些關係型操作會有語義層面的不清晰性，具體可以看Pig on Storm初步討論。對於filter，foreach，union，甚至稍微複雜點的需要藉助state的distinct，limit，在批量和流式情境下都是沒有歧義的，實現起來不會有太大的區別或難度。但是像兩流做sql語義裡的join，或者多流做pig語義裡的group，cross的時候，流式上的實現就不一致了，而且這個原語的定義也不同了。

在流式系統上實現DSL或者一套FlumeJava，關鍵在能把UDAF給實現了。而要實現UDAF，就涉及到了跨批的事情。這件事情本質上需要引擎的支援，比如Trident有SpoutCoordinator作流控，還具備一定的事務性，那麼在你要做跨批之間的UDAF的時候呢，可以藉助Trident的State，也就是輔助儲存，調用persistAggregate這樣的操作來完成。如果引擎不支援的話，比如原生Storm的介面，就沒辦法做流式DSL。

那麼像Spark那樣又不同，因為Spark本身不是流式系統，他的Spark Streaming上可以實現DSL，甚至可以和Spark SQL結合起來跑Streaming形式的SQL，原因是Spark是批次運算架構，所以他可以做類流式DSL。

總結：實現上看，流式系統上實現DSL痛點在UDAF，本質上是跨批次計算。那麼流式上的跨批可以抽象為一種怎樣的模式呢？

增量計算增量計算，理論上可以包含批次運算，流式計算，也包括了迭代計算。怎麼理解呢。增量計算可以表達為 newValue = function ( currentValue, oldValue )，而newValue被儲存為oldValue與之後新來的currentValue繼續產生關係，而這個不斷傳承下去的oldValue就是增量計算結果。
增量計算和前面提到的流式系統上實現運算元有什麼關係？這個增量的模型就是跨批次計算的一種形式。function可以理解為一個運算元，currentValue可以理解為本批次計算結果，oldValue可以理解為UDAF的計算結果。
這個模型只有流式系統能實現嗎？不是的，批次運算架構也可以做，大不了newValue每次都落盤嘛。如果Hadoop MR來做這件事情，其實是把每一次MR的資料當作一批，跨批的結果是額外儲存的。如果RDD來做這件事情，那就不同了，上述這種模型很適合RDD來做，因為迭代計算可以看成是增量計算的一種，而RDD很擅長構建DAG來完成迭代計算，只是每次計算出來的都是immutable的新RDD。
流式系統怎麼實現這種增量計算模型呢？這就是我們組之前老大和同事智慧的結晶了，具體不方便說。其實實現它不是痛點，痛點是計算架構內需要對oldValue進行容錯。RDD不用擔心容錯，因為有lineage來記錄，大不了可以重算，而且是可以並行的。Storm和Trident也不用擔心容錯，因為他把fail邏輯都交給使用者了！而我們組目前的增量計算引擎完成了這件事情，並且一直在checkpoint的最佳化上做著努力。
總結：計算模型上，在流式系統上實現增量計算引擎，是實現豐富運算元層，做流式SQL的一個必要條件。流式上實現的增量計算模型，有什麼本質缺陷嗎？
深入RDD

之前在杭州Spark meetup，分享Spark SQL的時候，我提到過Spark RDD最重要的兩層意義：原語的豐富和資料表示能力。前者使得Spark編程很easy，後者使得計算結果做到了reuse，適應了MR模型、迭代計算模型、BSP模型。基於這兩點，Spark Core上可以輕鬆衍生出SQL產品、機器學習產品、圖計算產品、StreamCompute產品。

反觀流式系統，比如Storm，原語要簡單豐富易用不是難事，問題是你資料能reuse嗎？！reuse有什麼優點？拿RDD來說，節省記憶體空間以及並發的計算能力。RDD在設計之初就是immutable的，而且在計算內部消化掉了MapReduce，而暴露出豐富的Transformation和Action。在論文中，RDD與DSM(Distributed Shared Memory)也進行了多維度對比。應該說，Matei在設計RDD之前的參與Hadoop MapReduce源碼的開發經驗，加上當時其他系統內DSM的差異設計，以及Google FlumeJava，微軟DryadLINQ在API層面的理念，最終揉合成了RDD這套東西。現在只有Spark現在實現了它。

最近我在增量計算引擎上實現的運算元層，也是參考了FlumeJava，Trident，RDD設計出來的，還在測試中。就像我開頭說的，Pig on Storm這件事情，換引擎是表面。背後意義是運算元層面的混用，最終的想象空間是一層統一的DAG，上面承接Pig、Hive、SQL等DSL，下面對接不同的計算系統。實現起來是不困難的，困痛點可能不是技術問題。

總結：RDD兩個致命優點，easy to use和資料的reuse，是其他系統難達到的，特別是第二點，也是RDD的精髓所在。

對比Storm

marz做了Storm，ElephentDB之後，按照他的理解在how to beat CAP裡提出了一種解決方案。在他提出的lambda achitecture裡，Storm的定位在串流，而做類似ad-hoc的service layer是HBase。如果換做是我們目前的增量計算架構的願景的話，我認為，流式和ad-hoc這層有望被增量計算引擎統一。為什嗎？

Query = Function(All Data)

Data靜，Query動，是ad-hoc計算；Data動，Query靜，是流式計算；Data動，Query動，是持續計算。Storm處於第二者，增量計算架構可以做到第三者。Storm的拓撲提交是個嚴重問題，等Nimbus拉起bolt和spout的時候，黃花菜都涼了。它的確適合流式計算，為什麼呢，因為流式的本質就是訊息。Storm抽象的那層拓撲，bolt之間的訊息通道，ack機制都很不錯，這層抽象滿足了流式計算，但是work這層以及調度這層遠遠不滿足Query不斷變化而仍需要流式計算的情境。我們現在做的架構將來會滿足這件事情，從此統一了流式、批量、迭代，超越現在的流式計算，不僅僅是StreamSQL，Stream上的DSL都是可以通過運算元層來實現的。

總結：Data動，Query動的情境如何統一解決？增量計算想象空間巨大，運算元層重要性突顯。

全文完 :)

談談分散式運算的運算元層