大資料計算：結構化大資料計算的理想模式

随着社會的資訊化發展，企業IT化的不斷完善，業務的不斷擴充，服務品質的不斷提高，企業資料越來越龐大：如何從海量資料中快速擷取自己需要的資料？如何能夠完成越來越複雜的資料計算？在資料倉庫和資料庫中的資料以TB\GB級增長的時候，如何能夠保證資料查詢和計算的高效率和響應度？這些問題都給CIO帶來了嚴峻的挑戰。

針對上述的問題，包括Teradata、IBM、ORACLE、EMC、Apache基金會等衆多的公司和機構，都提出了自己的解決方案。筆者在多年的BI實施過程中，對上述公司的解決方案，或多或少都有所涉及，在這裡，僅按自己的了解，對這些方案進行歸納和總結，因為筆者的水準有限，觀點難免有錯誤和片面之處，也希望讀者給予指正。

筆者認為：目前資料計算所面臨的問題，主要集中在三個方面：第一是資料存取和資料交換時的I/O瓶頸問題，第二是複雜計算模型的完備性問題，第三是資料計算本身的性能問題。

I/O瓶頸問題，主要表現在和硬碟的互動以及通過網絡輸入輸出，一般來說使用高轉速的硬碟以及增加網絡帶寬可以獲得一定程度的緩解，大部分情況下不會成為瓶頸。資料量大到一定程度時可以使用資料庫叢集，不過資料庫擴容成本很高，該方案不是一個很優的選擇。

複雜計算模型的完備性問題，影響的主要是開發效率。程式員一般采取兩種方式實作資料計算：第一是使用SQL/存儲過程，衆所周知，SQL是結構化查詢語言的最小完備集。但是最小完備集并不是最好用的完備集，SQL的問題有很多：無序集合、集合化不徹底、沒有對象引用等等。雖然在SQL 2003标準中增加了一些視窗函數，但是擴充的程度有限，易用性也有限。是以SQL雖然提供了完備的計算體系,可是開發效率太低。第二是程式設計實作或者使用第三方工具。目前市面上很少有第三方工具具備完備的計算體系，程式設計則遇到同樣的問題：開發效率太低。

資料計算本身的性能問題則是一個最嚴重的問題。理論上，以存儲過程或複雜SQL來實作計算邏輯是保證性能最好的做法，資料庫有很多優化措施，且本身是c語言開發，可以讓計算更快。但是優化總是有限的，資料量大到一定程度，性能終究是個瓶頸。

能有效解決性能問題的唯一辦法就是并行計算。目前提供并行計算的産品有兩大類，一類是以TD、GreenPlum為代表的MPP資料庫産品，其優點是計算快，并行算法透明，缺點是資料庫擴容成本太高，每增加一個并行節點則要增加不菲的費用，一般使用者承受不起。

另一類以Hadoop為代表的分布式資料處理的軟體架構，該方案把資料存儲在分布式檔案系統HDFS裡。HDFS分布式檔案系統很好地解決了IO問題，并具有很強的容錯能力，是個很優秀的資料存儲方案。但是Hadoop提供的并行架構MapReduce則不敢苟同了，該架構是為非結構化資料的搜尋統計而設計的, 由于本身不提供算法，又沒有現成的類庫，導緻程式員編寫算法難度很高，工作量很大。同時由于MapReduce架構把任務拆分得過細，使得很簡單的一個計算任務，需要編寫數個Map 和Reduce方法來實作，開發和運作效率都很低。

是以筆者認為，理想的大資料計算模式，應該具備以下特征：

1、計算層獨立于資料庫和應用程式之外，既不受資料庫難擴容的影響，也不受應用程式的限制。

2、計算層能夠通路分布式檔案系統（如HDFS等），便于在海量資料時避開IO瓶頸。

3、具有足夠完備的計算體系，在編寫算法時，有豐富的類庫和方法支援，減輕開發工作量。

4、計算層提供并行架構，并行節點擴充容易，成本低廉。且資料塊的拆分比較靈活，允許程式員根據實際情況随意指定。