作者：朱小虎XiaohuZhu；
來源：https://www.jianshu.com/p/2c7b0c76fa04
IT界在過去幾年中出現了一個有趣的現象。很多新的技術出現並立即擁抱了“大數據”。稍微老一點的技術也會將大數據添進自己的特性，避免落大部隊太遠，我們看到了不同技術之間的邊際的模糊化。假如你有諸如Elasticsearch或者Solr這樣的搜索引擎，它們存儲著JSON文檔，MongoDB存著JSON文檔，或者一堆JSON文檔存放在一個Hadoop集群的HDFS中。你可以使用這三種配置完成很多同養的事情。
ES是否可以作為一個NoSQL數據庫？粗看，這句話說的不太對，但是這是一個合理的場景。類似地，MongoDB在MapReduce的基礎上使用分片的技術同樣可以完成Hadoop可以做的工作。當然使用眾多功能，我們可以在Hadoop之上（Hive、HBase、Pig和同樣的一些）你也可以用多種方式查詢Hadoop集群中的數據。
那麼，我們現在是否能說Hadoop、MongoDB和Elasticsearch這三個是完全相同的呢？顯然不行！每個工具都有自身最為適用的場景，但是每個都有相當的靈活性能夠勝任不同的角色。現在的問題就變成“這些技術的最合適的使用場景是什麼？”。下面我們來瞧瞧。
Elasticsearch已經超越了其最初的純搜索引擎的角色，現在已經增加了分析和可視化的特性——但是它的核心仍舊是一個全文搜索引擎。Elasticsearch建立在Lucene之上並且支持極其快速的查詢和豐富的查詢語法。如果你有數百萬的文檔需要通過關鍵詞進行定位時，Elasticsearch肯定是最佳選擇。當然，如果你的文檔是JSON的，你就可以把Elasticsearch當作一種輕量級的“NoSQL數據庫”。但是Elasticsearch不是一個合適的數據庫引擎，對複雜的查詢和聚合並不是很強，儘管統計facet可以提供一定的關於給定查詢的統計信息的支持。Elasticsearch中的facet主要是用來支持分面的瀏覽功能。
目前Elasticsearch已經增加了aggregation的功能如果你在尋找一個對應於一個關鍵詞查詢的少量的文檔集合，並且要支持在這些結果中分面的導航，那麼Elasticsearch肯定是最好的選擇。如果你需要進行更加複雜的計算，對數據執行服務端的腳本，輕鬆地運行MapReduce job，那麼MongoDB或者Hadoop就進入待選項中。
MongoDB是NoSQL數據庫，被設計成一個高可擴展，並且有自動分片的功能及一些額外性能優化的功能。MongoDB是一個面向文檔的數據庫，以JSON的形式進行數據的存儲（準確地說可以稱為BSON，對JSON進行了一些增強）——例如，一個native數據類型。MongoDB提供了一個文本索引類型來支持全文檢索，所以我們可以看到在Elasticsearch和MongoDB之間的界限，基本的關鍵詞搜索對應於文檔的集合。
MongoDB超過Elasticsearch的地方在於其對於服務器端js腳本的支持、聚合的管道、MapReduce的支持和capped collections。使用MongoDB，你可以使用聚合管道來處理一個集合中的文檔，通過一個管道操作的序列來多步地對文檔進行處理。管道操作可以生成全新的文檔並且從最終的結果中移除文檔。這是一個在檢索數據時的相當強的過濾、處理和轉化數據的特點。MongoDB也支持對一個數據collection進行map/reduce job的執行，使用定製的js函數進行操作的map和reduce過程。這就保證了MongoDB可以對選定的數據執行任意類型的計算或者轉換的終極的靈活性。
MongoDB另一個極其強大的特性稱之為“Capped collections”。使用這個特性，用戶可以定義一個collection的最大size——然後這個collection可以被盲寫，並且會roll-over必須的數據來獲取log和其他供分析的流數據。
你看到，Elasticsearch和MongoDB有一個可能的應用場景的重疊，它們不是同樣的工具。但是Hadoop呢？Hadoop就是MapReduce，這已經有MongoDB就地支持了啊！是不是還有一個專屬於Hadoop的場景，MongoDB就只是適合。
有！Hadoop是老MapReduce了，提供了最為靈活和強大的環境來進行大量數據的處理，毫無疑問的是能夠搞定不能使用Elasticsearch或者MongoDB處理的場景。
為了更加清楚地認識到這點，看看Hadoop如何使用HDFS抽象存儲的——從關聯的計算特性上。通過HDFS中存儲的數據，任意job都可以對於數據進行運算，使用寫在核心MapReduce API上，或者使用Hadoop流技術直接使用native語言編程。基於Hadoop 2和YARN，甚至核心編程模型都已經被抽象了，你不再受到MapReduce的牽制了。使用YARN你可以在Hadoop上實現MPI並且用那種方式寫job。
額外地，Hadoop生態系統提供了一個交錯的工具集合，建立在HDFS和核心MapReduce之上，來進行數據的查詢、分析和處理。Hive提供了一個類似SQL的語言，使得業務分析可以使用一個用戶習慣的語法進行查詢。HBASE提供了一個基於Hadoop的面向列的數據庫。Pig和Sizzle提供了兩個更加不同的編程模型來查詢Hadoop數據。對存儲在HDFS中的數據的使用，你可以繼承Mahout的機器學習的能力至你的工具集。當使用RHadoop時，你可以直接使用R統計語言來對Hadoop數據執行高級的統計分析
所以，儘管Hadoop和MongoDB也有部分重疊的應用場景並且共同擁有一些有用的功能（無縫的水平擴展），但是兩者之間還是有著特定的場景。如果你僅僅想要通過關鍵字和簡單的分析，那麼Elasticsearch可以完成任務；如果你需要查詢文檔，並且包含更加複雜的分析過程，那麼MongoDB相當適合；如果你有一個海量的數據，需要大量不同的複雜處理和分析，那麼Hadoop提供了最為廣泛的工具和靈活性。
一個亙古不變的道理就是選擇手頭最適合的工具做事。在大數據這樣的背景下，技術層出不窮，技術間的界限也是相當的模糊，這對我們的選擇是一件相當困難的事情。正如你所見，特定的場景有著最適合的技術，這種差異性是相當重要的。最好的消息就是你不在限定在某一種工具或者技術上。依賴於你面對的場景，這就使得我們能夠構建一個整合的系統。例如，我們知道Elasticsearch和Hadoop是可以很好地一起共事的，使用Elasticsearch快速的關鍵詞查詢，Hadoop job則能處理相當複雜的分析。
最終，採用了最大的搜索和細緻的分析來確認最為合適的選擇。在選擇任何技術或者平臺時，需要仔細地驗證它們，理解這個東東適合哪些場景，哪裡可以進行優化，需要做出哪些犧牲。從一個小小的預研項目開始，確認完畢後，再將技術應用到真正的平臺上，緩慢地升級到新的層級。
跟隨這些建議，你可以成功地在大數據技術中遨遊，並且獲得相應的回報。
閱讀更多 javafirst 的文章
關鍵字: HDFS ElasticSearch 模糊化
