2、大數(shù)據(jù)處理技術(shù)復(fù)雜

大數(shù)據(jù)的處理技術(shù)紛繁復(fù)雜，仍然處于產(chǎn)業(yè)變革早期的戰(zhàn)國(guó)時(shí)代。由于傳統(tǒng)的OLAP和數(shù)倉(cāng)的延續(xù)性，Hive SQL有很大市場(chǎng)，但Hive的數(shù)據(jù)正確性和Bug仍然比較多。而Hadoop MapReduce又過(guò)于復(fù)雜靈活，寫(xiě)出高效Job比較困難。Pig、FlumeJava等分布式編程模型技術(shù)的門(mén)檻較高，所以推廣起來(lái)也比較困難。在數(shù)據(jù)挖掘和圖算法領(lǐng)域雖然涌現(xiàn)出了Mahout、Hama、GoldenOrb等大量開(kāi)源平臺(tái)，但都不夠成熟。至于基于Hadoop的工作流系統(tǒng)Oozie和數(shù)據(jù)傳輸系統(tǒng)Sqoop都需要開(kāi)發(fā)人員單獨(dú)部署。都是各有利弊，還沒(méi)有一個(gè)很好的完美的解決方案。

3、Hadoop尚難成為公共云服務(wù)

為什么說(shuō)Hadoop很難成為公共云服務(wù)呢，原因有以下幾個(gè)方面，第一Hadoop的安全體系局限在企業(yè)內(nèi)網(wǎng)，缺乏多租戶(hù)的支持。第二直接暴露HDFS文件系統(tǒng)，MapReduce和Hive很難做到多用戶(hù)數(shù)據(jù)安全。第三數(shù)據(jù)文件格式過(guò)于復(fù)雜多樣，維護(hù)成本高，保持?jǐn)?shù)據(jù)兼容比較困難。

綜上三點(diǎn)目前大數(shù)據(jù)的現(xiàn)狀，我們可以看出，大數(shù)據(jù)處理系統(tǒng)的技術(shù)門(mén)檻很高，從自備發(fā)電機(jī)到公共電網(wǎng)還有很長(zhǎng)的路要走。而市場(chǎng)則需要安全性、可用性、數(shù)據(jù)正確性都有保障，并且功能完整的一體化大數(shù)據(jù)處理服務(wù)。

大數(shù)據(jù)處理面臨的問(wèn)題

就目前大數(shù)據(jù)的現(xiàn)狀來(lái)看，可以看出大數(shù)據(jù)目前面臨著以下幾個(gè)問(wèn)題。

1、多租戶(hù)

如何保證用戶(hù)間隔離、數(shù)據(jù)安全和防止有害代碼的威脅?

2、高可用

如何確保服務(wù)7*24小時(shí)高可用和數(shù)據(jù)永久不丟失?

3、大規(guī)模

如何支撐10000個(gè)中型網(wǎng)站的數(shù)據(jù)規(guī)模?

4、編程模型

如何在紛繁的編程模型中選擇并保持高度的擴(kuò)展性，并支持工作流程?

5、存儲(chǔ)摸型

如何在存儲(chǔ)不斷發(fā)展中報(bào)紙數(shù)據(jù)格式的兼容性和互操作性?

6、數(shù)據(jù)正確性

如何確保大數(shù)據(jù)處理的正確性和一致性，尤其對(duì)于金融和科學(xué)計(jì)算應(yīng)用?

7、資源調(diào)度與效率

如何高效調(diào)度和使用計(jì)算?

8、可運(yùn)維可管理

如何確保系統(tǒng)可運(yùn)維和管理，做到遠(yuǎn)程維修?

9、數(shù)據(jù)通道

如何處理大數(shù)據(jù)的傳輸以及與在線和實(shí)時(shí)分析系統(tǒng)的整合?

10、運(yùn)營(yíng)平臺(tái)

如何為數(shù)據(jù)和應(yīng)用的提供者和使用者提供一個(gè)交易平臺(tái)和生態(tài)環(huán)境?

zhaohang