戳破大資料泡沫

我們正處於一場關於大資料和分散式運算的炒作中，該是讓大資料泡沫破裂的時候了。

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

跟隨潮流

在一個炒作週期內，通常有一個跟隨潮流的供應商群，他們倉促實施一個時髦的技術，試圖要保持與其相關而且不會在混亂中迷失方向。 但是這些公司的產品可能會使市場混淆，因為最終這些技術會被不恰當地使用。

使用這些產品的專案將面臨失敗的風險 ，即使客戶已經付出了大量的資源和精力，也有可能產出幾乎沒有投資回報率，然後客戶可能會開始質疑被熱炒的技術。 現在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分散式系統的努力集中到提供真正的、不同的價值的領域。

(責任編輯：蒙遺善)