去年我們可能還在討論大數(shù)據這個概念,今年我想很多企業(yè)和廠商已經開始行動了。大數(shù)據能掘到多少金子,我覺得這都是后話,目前緊要關頭是迎接大數(shù)據的到來,如果你接不住大數(shù)據那么你在未來的企業(yè)市場將會被淘汰。這不是危言聳聽,我們看到現(xiàn)在生成數(shù)據的設備在增加,個人數(shù)字設備、企業(yè)計算系統(tǒng)產生的數(shù)據量遠遠超過10年前,是1996年的180倍。文件(非結構化數(shù)據)本身的大小在發(fā)生變化,從600MB的RMVB到了30GB的藍光1080P視頻,企業(yè)數(shù)據量增加,造成的數(shù)據庫龐大。這三點無疑都是迫使企業(yè)進入大數(shù)據時代的原因。
我們知道大數(shù)據的4v理論,數(shù)量(Volume)、多樣性(Variety)、速度(Velocity)和真實性(Veracity),為我們制定大數(shù)據的策略提供了很好的方向。但同時我們在處理大數(shù)據的時候還是面臨著很多問題,就目前大數(shù)據處理的現(xiàn)狀來看,基本上處于以下幾種狀態(tài)。
大數(shù)據處理現(xiàn)狀
1、大數(shù)據處理平臺以Hadoop為主
目前大數(shù)據的處理平臺以Hadoop為主,都是自建Hadoop集群或使用AmazonElasticMapReduce服務,而Google的BigQuery由于種種限制推廣得并不理想。微軟的Cosmos/Dryad/Scope由于體系僅限于內部使用,也不能成為大數(shù)據的平臺,同時微軟對外也支持hostingHadoop。
2、大數(shù)據處理技術復雜
大數(shù)據的處理技術紛繁復雜,仍然處于產業(yè)變革早期的戰(zhàn)國時代。由于傳統(tǒng)的OLAP和數(shù)倉的延續(xù)性,HiveSQL有很大市場,但Hive的數(shù)據正確性和Bug仍然比較多。而HadoopMapReduce又過于復雜靈活,寫出高效Job比較困難。Pig、FlumeJava等分布式編程模型技術的門檻較高,所以推廣起來也比較困難。在數(shù)據挖掘和圖算法領域雖然涌現(xiàn)出了Mahout、Hama、GoldenOrb等大量開源平臺,但都不夠成熟。至于基于Hadoop的工作流系統(tǒng)Oozie和數(shù)據傳輸系統(tǒng)Sqoop都需要開發(fā)人員單獨部署。都是各有利弊,還沒有一個很好的完美的解決方案。
3、Hadoop尚難成為公共云服務
為什么說Hadoop很難成為公共云服務呢,原因有以下幾個方面,第一Hadoop的安全體系局限在企業(yè)內網,缺乏多租戶的支持。第二直接暴露HDFS文件系統(tǒng),MapReduce和Hive很難做到多用戶數(shù)據安全。第三數(shù)據文件格式過于復雜多樣,維護成本高,保持數(shù)據兼容比較困難。
綜上三點目前大數(shù)據的現(xiàn)狀,我們可以看出,大數(shù)據處理系統(tǒng)的技術門檻很高,從自備發(fā)電機到公共電網還有很長的路要走。而市場則需要安全性、可用性、數(shù)據正確性都有保障,并且功能完整的一體化大數(shù)據處理服務。
大數(shù)據處理面臨的問題
就目前大數(shù)據的現(xiàn)狀來看,可以看出大數(shù)據目前面臨著以下幾個問題。
1、多租戶
如何保證用戶間隔離、數(shù)據安全和防止有害代碼的威脅?
2、高可用
如何確保服務7*24小時高可用和數(shù)據永久不丟失?
3、大規(guī)模
如何支撐10000個中型網站的數(shù)據規(guī)模?
4、編程模型
如何在紛繁的編程模型中選擇并保持高度的擴展性,并支持工作流程?
5、存儲摸型
如何在存儲不斷發(fā)展中報紙數(shù)據格式的兼容性和互操作性?
6、數(shù)據正確性
如何確保大數(shù)據處理的正確性和一致性,尤其對于金融和科學計算應用?
7、資源調度與效率
如何高效調度和使用計算?
8、可運維可管理
如何確保系統(tǒng)可運維和管理,做到遠程維修?
9、數(shù)據通道
如何處理大數(shù)據的傳輸以及與在線和實時分析系統(tǒng)的整合?
10、運營平臺
如何為數(shù)據和應用的提供者和使用者提供一個交易平臺和生態(tài)環(huán)境?