上圖中，精確數據是指每條數據都有著準確的含義和確定的價值，表達很明確的信息。比如，制造業的一條生產記錄。傳統關系型數據庫以處理這類數據。并基于此類數據通過復雜邏輯分析推演出業務價值為強項。

大數據時代數據的特點是大量模糊數據。單條數據沒有確定的價值和明確的含義。比如，一個網頁的點擊記錄。Hadoop的優勢是能對海量模糊數據進行匯總排序比對等操作，把他們變成有意義的數據，再通過海量的樣本比對等方式歸納產生業務價值。

所以，從本質上說這是兩種針對不同場景不同對象的不同技術。如果要采用Hadoop去取代RISC架構的數據庫，BI應用。那么必須打破原來企業經 典的沿用幾十年的數據結構，重新定義數據模型，表結構等等。還是我以前提過的，就是要重新從頭練另一門武功。但那樣下來效率是否一定就會比以前高， 效果是否一定比以前好，從我幾個項目試驗的結果來看也并不樂觀。

但是，在某些情況下大數據技術也能比RISC架構更好的解決一些傳統的結構化數據問題，比如ETL。在一些行業里，ETL工作往往需要一個很長的處 理流程。利用Map/Reduce技術可以大大縮短ETL的工作流程，提高效率，而且隨著數據量的不斷增長，這種優勢會越來越明顯。所以說，是否用 Hadoop去嘗試替代原先的RISC架構，關鍵還是看數據量是否夠大以及數據類型是否多樣化。

以上這張圖取自BI Reasrch。以數據查詢的延遲性需求為縱軸，數據量和結構化程度為橫軸列出了Hadoop技術和傳統關系型即RDBMS的應用場景區別。Hadoop 之所以會出現其實就是為了應付海量的非結構化數據的離線分析的。所以其應用場景也基本是以此類為強項，即數據量大，結構化程度低，分析的實時性要求不高。 當然隨著其技術的發展，外沿通過不同組件如Hive的補充有所拓展。但要其完全取代原先的RDBMS基本是不可能的事情。

正如第一張圖所說，大數據時代，沒有一種方案是可以包打天下的。企業內部未來也必將是多種方案并存來處理各類不同類型數據的環境。下面試著將目前數 據庫的幾類應用場景分分類，同時列出了每一類國內外的一些解決方案名字。國外的方案我為了簡單起見，只列出特性比較鮮明的。沒有寫Exadata是因為它 有點屬于混合方案，把它簡單定位在一個領域有點不太合適。而且國內可以和它具備相同類型的方案也沒有，就先不提了。改天有空我再整理下我對于 Exadata的一 些粗淺認識給大家來噴一下。 關于國內方案，我列出的是僅限于我知道的或是合作過的方案提供商，當然還有很多遺漏的。當然也有些我認為特色不鮮明沒有什么核心技術的也就不提了。這里只 列出他們的名字和專注領域類型，詳細的一些介紹就不在這里貼出來了，反正他們都可以在新浪微博里找到，呵呵。

當然，上圖所列出的場景所針對的解決方案也不是唯一的。一些場景是多個方案都可以勝任的。

比如Mongo DB也可以做MAP/Reduce的工作。Hive能夠為Hadoop體系提供SQL的接口等等

最后，再談一下我對國內大數據解決方案提供商的一些總體感覺。當然，還是那句話，這些觀點只是在我接觸過的幾個方案中得出的，并不代表國內總體的情況，我沒有這么多的精力去了解，也沒有這個能力。這些感覺僅供參考。

關于適宜客戶群，我上面說的也只是我個人的一些建議。我覺得，這些國內解決方案的供應商，需要通過一些實際企業應用案例實施的磨練，以及一些合作伙 伴的幫助，才能真正走向成熟，走向商用，去挑戰那些國外的知名產品。我覺得從目前來看，技術不是問題，路線方向也沒有什么錯誤。關鍵是 對自身的規劃和技術走向商用，走向產品化流程化的運作能力。我也真心希望國內的那些大企業大公司能夠給國內的這些有技術有想法的方案提供商一些機會，讓他 們能夠積累經驗，成長壯大。

先寫這些吧。還有一部分關于國內那些大數據方案同國外方案的對比，以及Intel Hadoop方案同Cloudera的對比，目前我寫的主要還是針對我們公司內部分享的用途，就不對外公開了。有興趣的朋友我們下次可以口頭討論。還有幾個我自己親身參與的行業案例，回頭如果得到那些公司許可了再公開給大家分享吧。