我們正處于一場關于大數(shù)據(jù)和分布式計算的炒作中，該是讓大數(shù)據(jù)泡沫破裂的時候了。

是的，穿過一個炒作周期來使技術跨越鴻溝，從早期的采用者到更廣泛的大眾群體。而且，至少它暗示了一個超越學術對話和試點項目的技術進步。但是更廣泛的觀眾采用此項技術可能只是隨波逐流，一直就缺少一些重要的警示觀點。

跟隨潮流

在一個炒作周期內(nèi)，通常有一個跟隨潮流的供應商群，他們倉促實施一個時髦的技術，試圖要保持與其相關而且不會在混亂中迷失方向。但是這些公司的產(chǎn)品可能會使市場混淆，因為最終這些技術會被不恰當?shù)厥褂谩?/p>

使用這些產(chǎn)品的項目將面臨失敗的風險 ，即使客戶已經(jīng)付出了大量的資源和精力，也有可能產(chǎn)出幾乎沒有投資回報率，然后客戶可能會開始質(zhì)疑被熱炒的技術?，F(xiàn)在Hadoop堆棧正在面臨這種局面。

打破大數(shù)據(jù)泡沫以鑒別有關其產(chǎn)品和模式的某些細微的差別開始。以下是一些重要因素，分為三個重點領域，這些應該在你考慮一個hadoop分布式基礎架構(gòu)的相關技術之前弄明白。

Hadoop不是RDBBMS的殺手

Hadoop分布式系統(tǒng)在商品硬件和存儲上運行，使它比傳統(tǒng)的關系數(shù)據(jù)庫管理系統(tǒng)(RDBMS)便宜很多，但它并不是一個數(shù)據(jù)庫替代品。Hadoop分布式架構(gòu)的建立是為了利用對較大數(shù)據(jù)塊的順序數(shù)據(jù)訪問（一次寫入多次讀?。┒皇菃为毜挠涗浿?。正因為如此，Hadoop分布式系統(tǒng)針對分析工作負載進行了優(yōu)化，而不是關系型數(shù)據(jù)庫管理系統(tǒng)的交易處理工作。

坦白的說，低延遲的讀和寫不在Hadoop的分布式文件系統(tǒng)(HDFS)中并不奏效。僅僅是協(xié)調(diào)的寫入和讀取單個字節(jié)的數(shù)據(jù)，就要求多個終端控制協(xié)議/網(wǎng)端協(xié)議連接到Hadoop的分布式系統(tǒng)，這給交易操作帶來了非常高的延遲。

然而，在一個優(yōu)化好的Hadoop集群中，讀取和寫入大塊數(shù)據(jù)的吞吐量是非常高的。

Hive文件和非Hive文件

Hive文件允許開發(fā)人員查詢Hadoop分布式系統(tǒng)內(nèi)的數(shù)據(jù)并使用一個類似結(jié)構(gòu)化查詢語言(SQL)的語言。越來越多的人知道結(jié)構(gòu)化查詢語言可以編寫的Hadoop分布式系統(tǒng)并行編程技術的本地代碼，這使得使用Hive文件能有一個有吸引力的和更便宜的辦法來招聘新的人才，或者讓開發(fā)人員學習Java程序設計語言和編程技術代碼編程模式。

然而，在作出關于Hive文件作為你的大數(shù)據(jù)解決方案的任何決定之前，有一些非常重要的權衡需要注意：

?HiveQL(Hive文件結(jié)構(gòu)化查詢語言的方言)只允許您查詢結(jié)構(gòu)化數(shù)據(jù)。

?Hive文件本身并沒有一個Extract/Transform/Load(ETL)工具。所以盡管你可以節(jié)省錢使用Hadoop分布式系統(tǒng)和Hive文件作為您的數(shù)據(jù)庫，內(nèi)部開發(fā)人員也可以運行結(jié)構(gòu)化查詢語言的技能組合，但是維護定制加載腳本和隨需求變化準備數(shù)據(jù)支付費用。

?Hive底層使用HDFS和Hadoop MapReduce計算方法?？磥磉@意味著，其原因就像已經(jīng)討論過的那樣，從傳統(tǒng)的關系數(shù)據(jù)庫管理系統(tǒng)到習慣于正常的結(jié)構(gòu)化查詢語言響應時間的最終用戶，可能要對Hive文件使用的有點笨拙的批處理方法來“查詢”而感到失望了。

這是實時的Hadoop分布式系統(tǒng)嗎? 并非真的如此。

讓我們來探索一些使Hadoop分布式系統(tǒng)不適用于實時應用的技術因素。Hadoop分布式系統(tǒng)的MapReduce計算方法沿用了一個Map預處理步驟和一個Reduce數(shù)據(jù)聚合/提煉的步驟。雖然有可能對實時流數(shù)據(jù)應用這種Map操作，但是Reduce就不能了。

這是因為Reduce步驟要求所有輸入的數(shù)據(jù)首先要為每一個獨特的數(shù)據(jù)鍵進行映射和整理。然而對這個涉及到緩沖區(qū)的過程有一個攻擊，甚至黑客都無法進行實時操作，因此緩沖區(qū)只能持有少量的數(shù)據(jù)。

某些NoSQL產(chǎn)品也使用MapReduce來分析工作負載。因此當這些數(shù)據(jù)存儲庫可以執(zhí)行接近實時的數(shù)據(jù)查詢時，它們也不是用于實時分析的工具。

盡管還有其它的一些大數(shù)據(jù)的謠言需要粉碎，Hadoop分布式系統(tǒng)也無法作為關系數(shù)據(jù)庫管理系統(tǒng)的更換。Hive文件的各種缺點和編程工具對實時流數(shù)據(jù)的應用的不適應性是目前在我們的觀察中存在的最大的障礙。

最后，要實現(xiàn)關于對大數(shù)據(jù)的承諾，需要透過表象去了解合適的應用。信息技術（IT）組織必須沖破大數(shù)據(jù)泡沫，并將自己對Hadoop分布式系統(tǒng)的努力集中到提供真正的、不同的價值的領域。