用F#從0開始打造一個大資料處理平台(1.整體規劃)

這一大系列部落格将介紹一個偉大的大資料處理平台是如何誕生的.

預計會有很多很多篇,持續很長很長時間. 為什麼說 "偉大" 呢? 因為這将打造一整個新的體系. 不同于現有的大資料生态圈裡各種産品的新的函數式體系結構.  資料處理本是函數式語言的專長, (比如map 和 reduce 是所有函數式語言的最重要的兩個基礎函數---哪怕在某些語言中不叫這兩個名字), 無奈hadoop 根植于jvm, 來源于java,帶動整個社群生态從hdfs, hbase, zookeeper, spark 以及其上的各種組合的平台, 都走java系.  現在說大資料處理, 不管用的哪一套體系, 最終都會走到hadoop的hdfs上去. 全世界都這麼走.

但是, 萬一全世界都錯了呢?  hdfs 并不完美, 而且是跟完美完全不沾, 他有各種問題, 甚至從一開始, 他就做錯了一些事, 并且越錯越遠.   

我們在大資料處理上, 需要的核心是一個bigtable實作, 和一個mapreduce架構. hadoop 的實作上先有hdfs, 後來才有hbase這個bigtable實作, 是以是hbase去适應和遷就hdfs了.  這就導緻了一些不必要的複雜性.

在我們實作裡, 我們在設計我們的分布式檔案系統時, 我們是假設我們已經有一個bigtable實作, 我們的這個實作, 需要什麼樣的分布式檔案系統來支撐它,  我們就打造一個那樣的檔案系統. 而對我們的bigtable實作沒有幫助的功能,我們則盡量不添加. 

整個過程設計遵從 "正交性" 原則, 并且盡力讓一切回歸本源的簡單性, 因為: "如果把簡單的事情做複雜, 那以後事情變複雜以後就會太複雜了!".  hadoop就是把簡單事情做複雜的一個典範, 當然包括大多數 "成熟" 的 java 系的apache開源項目都有這個問題, 就是早期為了以後莫須有的擴充性而過度設計了, 這裡面的罪魁禍首其實是 "開閉原則", 為了不修改現有代碼而增加或修改功能, 增加了大量的抽象層. 而實際上, 最終還是在大版本裡通過重構大量修改了代碼. 

作為有極大量開發者的開源項目, 這可能是沒辦法的事情. 帶來的問題, 也基本是無解的.

我們這個新輪出來的體系, 必須盡力回避這種附加的複雜性.

整體上的規劃:

為什麼用f#?  因為我們需要一個函數式的基因來引導我們走出一條函數式主導之路,  haskell和其他大多數函數式語言缺乏一個足夠強勁的工業化強度的運作時環境作為支撐.  clojure 生成的bytecode品質使得它可能并不是合适的性能熱點位置的選擇.  另外一方面, 作為現在最廣泛的2個高強度的運作時.net 和 jvm , 其實各有優缺點, 選擇一個與hadoop不同的基礎平台, 有助于在未來的演化中引入.net的特色而産生更多差異化.  當然, 出于跨平台考慮, 我們的 f# 将隻使用mono 和 .net core 的交集部分的特性.

我們将會輪哪些部分?  首先mapreduce架構是必須的(相當于hadoop mapreduce或spark的地位), bigtable實作是必須(相當于hbase的地位), bigtable的底層分布式檔案系統(相當于hdfs)是必須的, 作為分布式體系, 一個監控管理的元件是必須的(相當于zookeeper)同時為了在分布式檔案系統以外, 存儲這個架構的各種中繼資料, 包括檔案系統自己的中繼資料, 我們還需要一個 輕量級的 key-value 的nosql資料庫(至少可以當我們的分布式檔案系統的分區表.....) 

上面需要的那些元件, 現在 .net 世界裡都沒有合适的麼? 最後那個nosql資料庫顯然我們已經有類似ravendb這樣的東西了, 不過它太重了, 而且性能特點跟我們需求不太符合, 我們需要的是一個支援超快速寫入和讀取的, 支援非常大資料量的, 越簡單越好的資料庫.  其他幾個, 至少現在我是沒有找到. 

這個項目會開源麼?  當然, 一定會. 我将放在github上.

項目名稱是 longlad 

longlad.metastore 是我們的kv資料庫

longlad.filesystem 是我們的hdfs替代品

longlad.bigtable 是我們的hbase替代品

longlad.mapfold 是我們的spark替代品

longlad.guard 是我們的zookeeper替代品

longlad._______ 未來如果時間夠, 再加吧, 因為上面5個已經是超大工程了(這項目申請國家核高基的資金怕都不過分....)~~~

元件之間的大體關系, 與 hdfs/hbase/spark/zookeeper 的關系類似, 我就不多解釋了. 至于那個longlad.metastore 是作為其他幾個的一個子部件存在的.

開發的順序預計将會是: 1,2,5,3,4 下一篇開始從longlad.metastore實作

萬裡長征, 一步還沒走, 隻是穿了鞋子了,  以後堅持每周更新1-2篇.