我們正處于一場關于大數據和分布式計算的炒作中，該是讓大數據泡沫破裂的時候了。
是的，穿過一個炒作周期來使技術跨越鴻溝，從早期的采用者到更廣泛的大眾群體。而且，至少它暗示了一個超越學術對話和試點項目的技術進步。但是更廣泛的觀眾采用此項技術可能只是隨波逐流，一直就缺少一些重要的警示觀點。
跟隨潮流
在一個炒作周期內，通常有一個跟隨潮流的供應商群，他們倉促實施一個時髦的技術，試圖要保持與其相關而且不會在混亂中迷失方向。但是這些公司的產品可能會使市場混淆，因為最終這些技術會被不恰當地使用。
使用這些產品的項目將面臨失敗的風險 ，即使客戶已經付出了大量的資源和精力，也有可能產出幾乎沒有投資回報率，然后客戶可能會開始質疑被熱炒的技術。現在Hadoop堆棧正在面臨這種局面。
打破大數據泡沫以鑒別有關其產品和模式的某些細微的差別開始。以下是一些重要因素，分為三個重點領域，這些應該在你考慮一個hadoop分布式基礎架構的相關技術之前弄明白。
Hadoop不是RDBBMS的殺手
Hadoop分布式系統在商品硬件和存儲上運行，使它比傳統的關系數據庫管理系統(RDBMS)便宜很多，但它并不是一個數據庫替代品。Hadoop分布式架構的建立是為了利用對較大數據塊的順序數據訪問（一次寫入多次讀取）而不是單獨的記錄中。正因為如此，Hadoop分布式系統針對分析工作負載進行了優化，而不是關系型數據庫管理系統的交易處理工作。
坦白的說，低延遲的讀和寫不在Hadoop的分布式文件系統(HDFS)中并不奏效。僅僅是協調的寫入和讀取單個字節的數據，就要求多個終端控制協議/網端協議連接到Hadoop的分布式系統，這給交易操作帶來了非常高的延遲。
然而，在一個優化好的Hadoop集群中，讀取和寫入大塊數據的吞吐量是非常高的。
Hive文件和非Hive文件
Hive文件允許開發人員查詢Hadoop分布式系統內的數據并使用一個類似結構化查詢語言(SQL)的語言。越來越多的人知道結構化查詢語言可以編寫的Hadoop分布式系統并行編程技術的本地代碼，這使得使用Hive文件能有一個有吸引力的和更便宜的辦法來招聘新的人才，或者讓開發人員學習Java程序設計語言和編程技術代碼編程模式。
然而，在作出關于Hive文件作為你的大數據解決方案的任何決定之前，有一些非常重要的權衡需要注意：
•HiveQL(Hive文件結構化查詢語言的方言)只允許您查詢結構化數據。
•Hive文件本身并沒有一個Extract/Transform/Load(ETL)工具。所以盡管你可以節省錢使用Hadoop分布式系統和Hive文件作為您的數據庫，內部開發人員也可以運行結構化查詢語言的技能組合，但是維護定制加載腳本和隨需求變化準備數據支付費用。
•Hive底層使用HDFS和Hadoop MapReduce計算方法。看來這意味著，其原因就像已經討論過的那樣，從傳統的關系數據庫管理系統到習慣于正常的結構化查詢語言響應時間的最終用戶，可能要對Hive文件使用的有點笨拙的批處理方法來“查詢”而感到失望了。
這是實時的Hadoop分布式系統嗎? 并非真的如此。
讓我們來探索一些使Hadoop分布式系統不適用于實時應用的技術因素。Hadoop分布式系統的MapReduce計算方法沿用了一個Map預處理步驟和一個Reduce數據聚合/提煉的步驟。雖然有可能對實時流數據應用這種Map操作，但是Reduce就不能了。
這是因為Reduce步驟要求所有輸入的數據首先要為每一個獨特的數據鍵進行映射和整理。然而對這個涉及到緩沖區的過程有一個攻擊，甚至黑客都無法進行實時操作，因此緩沖區只能持有少量的數據。
某些NoSQL產品也使用MapReduce來分析工作負載。因此當這些數據存儲庫可以執行接近實時的數據查詢時，它們也不是用于實時分析的工具。
盡管還有其它的一些大數據的謠言需要粉碎，Hadoop分布式系統也無法作為關系數據庫管理系統的更換。Hive文件的各種缺點和編程工具對實時流數據的應用的不適應性是目前在我們的觀察中存在的最大的障礙。
最后，要實現關于對大數據的承諾，需要透過表象去了解合適的應用。信息技術（IT）組織必須沖破大數據泡沫，并將自己對Hadoop分布式系統的努力集中到提供真正的、不同的價值的領域。
京公網安備 11010502049343號