寫一篇隨筆，談談大半年來做的一些事情。
這大半年來其實一直在嘗試真正搞懂兩個概念，dag和pipeline。
首先是dag。和不同人交流，大家對dag的理解都不一樣。有的人認為dag與stage by stage是繫結的，有明確的stage劃分和執行步驟的才能稱為dag，這和它的始祖dryad，以及一脈相承的spark分不開。在我看來，至少在bh的實現中，dag更多地被泛化成乙個計算模式，stage和pipeline只是執行實現的不同，與dag本身無關，dag就是個執行計畫，它重點在於靈活，每個節點可以把執行計畫最大程度地下推到掛在的engine裡(包括資料庫、olap engine及各種儲存介質等)，極簡的dag就是下發和merge兩層，極優的dag就是可以把sql優化執行為與原生sql語言的mpp等系統一樣優化的效果，所以dag是計算表達的統一。
其次是pipeline。pipeline其實剛開始於streaming**出現，直到半年前我終於明白了streaming是什麼。其實剛開始做bh的時候，我就是把streaming與pipeline混淆的，pipeline帶來的好處就是每一批(一條、若干條或全部)資料的lantency低，各自併發可亂序，中間資料不容易膨脹。後來看了微軟的一些**和系統之後，特別是dataflow**的出現，讓我看到了streaming的本質。streaming的資料有先天的屬性：產生時間、系統處理時間。真正完備的streaming可以在程式設計模型上清晰地定義，何時或什麼條件下要觸發計算，遲到的資料需不需要及如何處理，放在那部分區間處理，如何對已輸出結果做補償。在這塊，思想最先進的就是谷歌的dataflow，它沒有給出實現細節，但是把模型這層說的很清楚，真正統一了streaming和batch計算，微軟的trill也更早意識到了這點，只是**層面沒有dataflow說的清晰(個人拙見)。
在後半階段，bh開始往圖計算走，在我看來是典型的流式圖計算做法。bh的dag被進行了擴充套件，帶環，使之可以做高效的流式迭代計算。這邊值得一提的是，我們不僅可以做asp、bsp，也可以輕鬆做到ssp，不需要新增任何新模組和新原語。這得益於pipeline系統的執行本身就是stage by stage多了協調模型，在bh中做得比流式的協調者更複雜和靈活。這種流式迭代的表達讓bh可以很適合無barrier的圖演算法，比如n度擴充套件、標籤傳播等。當然也有tradeoff，像pagerank在我看來並不佔優勢。因為在圖這個領域，同步bsp模型、非同步模型，本身就是不同系統的執行選型，比如pregel、graphx、giraph、graphlab。bh在模型這層都可以做支援，並且在個別場景中可以發揮所長，做的比較極致，甚至執行起來有點像mpi模型。
所以bh做到現在，我基本覺得分布式計算基本都差不多，流也好，批也好，圖也好，以及大部分的mldm演算法，對core這層都沒有區別。當然我認為spark的core在執行方式上，支援流還是有問題的。雖然分布式計算都類似，但框架作為通用的架構，真的要支援的時候，還是要面臨專有系統的挑戰，我們不能真的定製成極致，這也是tradeoff。所以機會可能就在於資料復用和混合計算的場景，這和spark、flink是很像的:)
再接著圖計算談，很多圖計算系統都使用標準的圖計算演算法來做benchmark以說明自己的效能。其實真實場景中：第一，這種寫在lib裡包出去用的所謂標準演算法基本套不上，很雞肋或者說脫離事實；第二，要參雜圖查詢。後者其實是個更嚴峻的話題，我目前還是認為圖查詢和圖計算是兩碼事，前者我認為就和olap一樣，毫秒級要求，有一套自己的dsl，標準原語，並且要在建模這層下些功夫，可能要在儲存這層額外建點、邊以外的索引，真正在計算表達上，就只是dag的locality。除此之外，我看到圖查詢的場景裡，還帶了很多關係型查詢，看上去圖建模和關係型建模必須混存，或者，我的乙個觀點是，圖儲存裡面包括關係型儲存。所以在我看來，圖這塊是三個層次，圖計算、圖建模、圖儲存。建模確定了計算的api，不同的建模對應不同的api實現，比如pregel的、類似graphx/gelly的。同時建模決定了圖儲存的組織，可以是純的切點/切邊，按矩陣分割槽的圖儲存，也可以帶上kv關係型儲存作為輔助的，並且加上定製索引。說白了，圖建模之所以承上啟下，主要是因為它知道儲存的元資料，可以為計算提供正確的partitioner，做更好的locality計算。甚至圖查詢這塊，和搜尋的做法更類似，比如facebook的unicorn，基本上就是做搜尋的方式做圖查詢。
另外，tensorflow開源那陣子，作為小白的我還研究了些ml、dl的系統和架構，想著這塊的計算是否也有統一的可能。基本上，parameter server這樣的架子勉強可以在bh裡實現，不會很醜，比spark結合要乾淨點，bh確實可以做online learning，對於一些model不是很大但要實時更新的場景。
手寫的好冷，基本上我覺得大半年來，搞清了統一分布式計算的模型，探索了streaming和graph，從無到有與三四位同事一起做了乙個屬於我們自己的計算框架，接下來的專案落地有更多的挑戰可以做，加油吧 :)
Solaris大半年使用感觸
原文寫於 2010 08 22 20 21 13 網易部落格,已刪.從元旦後接手了乙個測試產品 從一期做到二期,再轉型 後,就一直在solaris上測試這個東東.從solaris安裝到日常使用維護,也斷斷續續地學習了一些,總結了一些東西.然而一直沒有把這些東西好好記錄下來.最初只想過能用solari...
貼一下這大半年的工作總結
哈哈，寫的跟過家家似的，主要是人少，重複說做了什麼就沒多大意思了，所以吧，就當調節氣氛了 2011.12 2012.06個人工作總結 雖然和工作沒有關係，但是想回顧一下來這裡工作前的大半年。那叫啥，承前啟後？不過，老實講，那半年沒啥好寫的。過的很輕鬆，真的很輕鬆，就像是完成了一項偉大的工作後老闆和我...
半年來，我的腳步
2008 年下半年從原來的單位辭職了，自己辦起了一家小公司。自己在以前的單位是乙個單純的技術人員 管理人員，偏技術更多一些。原先的單位屬於國家事業單位，市場觀念差一些，傳統的老事業單位拿事業費 研究費的思想，雖然也年年說要加大拓寬外部市場，但雷聲大雨點小，實際效果很不好，我也是主要因為這個原因離開了...