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

隨著社會的資訊化發展，企業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、 計算層提供並行框架，並行節點擴充容易，成本低廉。且資料塊的拆分比較靈活，允許程式設計師根據實際情況隨意指定。 
5、 計算層對外提供標準的資料訪問介面, 如JDBC等 


作者介紹：張淳，從2008年起一直從事BI領域資料計算和分析方面的諮詢和專案實施工作。在電信、移動、金融、能源等領域處理海量結構化資料業務方面，具有豐富的諮詢和專案實施經驗。現在北京某IT公司擔任資深產品支援顧問。 

轉自：http://www.iteye.com/topic/1131172