2017年大數據生態圈三強榜單已出，快來看看都有誰？
2017年3月2日，在合眾資料黃山技術交流大會上，OpenFEA總架構師發佈了大數據生態圈三強名單。
之所以給他們起一個簡稱SHE，一方面是因為順口，方便記憶。另一方面是因為這三大系統都是大資料技術圈比較有代表性的生態系統及框架。他們就像母親一樣，承載萬物，哺育萬物，提供了各類大資料解決方案的支撐骨架，並且關係著各類應用的生髮衰亡。
S，代表Spark;
H，代表Hadoop;
E，代表Elastic Stack;
以下將分別進行介紹，並闡述上榜原因。
第一名. Hadoop
自大資料提出時起，
早期，通過不斷提升伺服器的性能，增加伺服器集群數量來處理大規模資料，但成本和代價高昂，最終達到一個無法接受的地步，人們不得不研究其它的處理方法。
2003年，Google發表了三篇大資料技術論文：《MapReduce》、《Google File System》、《Big Table》。這三篇論文描述了採用分散式運算方式來進行大資料處理的全新思路, 其主要思想是將任務分解，然後在多台處理能力較弱的計算節點中同時處理, 最後將結果合併從而完成大資料處理。
這種方式因為採用廉價的P C 伺服器集群, 實現了海量資料的管理，所以成為處理大資料的主要方式。時至今日，這種將資料化大為小，分而治之的處理方法，仍然應用廣泛。但頗為可惜的是，Google雖然通過論文的方式向大資料技術大牛們指明了方向，
Yahoo投入了大量的資源到Hadoop的研究中，目前Yahoo在Hadoop上的貢獻率占了70%。從2005年起，Yahoo就成立了專門的團隊，致力於推動Hadoop的研發，並將集群從20個節點發展到2011年的42000個節點，初具生產規模。在應用領域，Yahoo更是積極地將Hadoop應用於自己的各種產品中，
Facebook擁有超過10億的活躍使用者，需要存儲和處理的資料量巨大。它使用Hadoop平臺建立日誌系統、推薦系統和資料倉庫系統等。2012年，Facebook甚至宣佈放棄自行研發的開源項目Cassan-dra，全面採用Hbase為郵件系統提供資料庫支援。Facebook目前運行著的可能是全球最大規模的基於Hadoop的資料收集平臺。另一方面，
阿裡巴巴同樣是Hadoop技術的積極應用者。2009年，阿裡推出了以Hadoop為基礎的分散式資料平臺，代號“雲梯”。雲梯為淘寶在後來的多次嚴峻挑戰中經受考驗打下了堅實的技術基礎。2014年3月，阿裡宣傳，即將用自主研發的雲梯二代替代開源項目為基礎的雲梯一代。新平臺在性能上提升更大，同時擁有更多的智慧財產權和自主性。除了IT企業，金融、傳媒、零售、能源、製藥等傳統行業在大資料技術應用方面也積極回應，行業應用系統研發、服務需求和計算模型研究都在蓬勃開展。
因此，Hadoop以應用最廣而入三強，並且位列第一名。
Hadoop框架最核心的設計是：HDFS和MapReduce。HDFS用於非結構化海量資料的存儲，MapReduce則為海量資料提供了計算。
另外，還有HBASE、HIVE、YARN等核心元件。Hbase，是運行在Hadoop上的一種分散式資料庫;HIVE，提供了類SQL的HQL語言查詢存放在HDFS上的資料;Yarn，可以很方便的管理諸如Hive、Hbase、Spark等應用，而MapReduce也需要運行在Yarn上面。
一、HDFS
HDFS是分散式運算的存儲基石，對於整個集群有單一的命名空間，具有資料一致性，適合一次寫入多次讀取的模型，用戶端在檔沒有被成功創建之前是無法看到檔存在的。檔會被分割成多個檔塊，每個檔塊被分配存儲到資料節點上，而且會根據配置由複製檔塊來保證資料的安全性。
HDFS通過三個重要的角色來進行檔案系統的管理：NameNode、DataNode和Client。NameNode可以看做是分散式檔案系統中的管理者，主要負責管理檔案系統的命名空間、集群配置資訊和存儲塊的複製等。
NameNode會將檔案系統的Metadata存儲在記憶體中，這些資訊主要包括檔資訊、每一個檔對應的檔塊的資訊和每一個檔塊在DataNode中的資訊等。
DataNode是檔存儲的基本單元，它將檔塊(Block)存儲在本地檔案系統中，保存了所有Block的Metadata，同時週期性地將所有存在的Block資訊發送給NameNode。
Client就是需要獲取分散式檔案系統檔的應用程式。
二、MapReduce
MapReduce是一個高性能的分散式運算框架，用於對海量資料進行並行分析和處理。與傳統資料倉庫和分析技術相比，MapReduce適合處理各種類型的資料，包括結構化、半結構化和非結構化資料。資料量在 TB 和 PB 級別，在這個量級上，傳統方法通常已經無法處理資料。MapReduce 將分析任務分為大量的並行Map 任務和Reduce匯總任務兩類。
Map 任務運行在多個伺服器上。指定一個Map(映射)函數，用來把一組鍵值對映射成一組新的鍵值對，指定併發的Reduce(歸約)函數，用來保證所有映射的鍵值對中的每一個共用相同的鍵組。把一堆雜亂無章的資料按照某種特徵歸納起來，然後處理並得到最後的結果。Map面對的是雜亂無章的互不相關的資料，它解析每個資料，從中提取出key和value，也就是提取了資料的特徵。經過MapReduce的Shuffle階段之後，在Reduce階段看到的都是已經歸納好的資料了，在此基礎上我們可以做進一步的處理以便得到結果。
三、YARN
Yarn是一個分散式的資源管理系統，用以提高分散式集群環境下記憶體、IO、網路、磁片等資源的利用率。嚴格來說，Yarn只是一個資源管理的框架，並不是一個計算框架，MapReduce計算框架需要運行在Yarn上。
Yarn，最主要的作用是，能夠使得各種應用可以互不干擾的運行在同一個Hadoop系統中，共用整個集群資源。
四、HBASE
Hbase是運行在Hadoop上的一種分散式資料庫，部署於HDFS之上，克服了HDFS在隨機讀寫方面的缺點。
HBase是一種Key/Value系統，和Hive不一樣，Hbase能夠在它的資料庫上即時運行，而不是運行MapReduce任務。在Hbase中，行是key/value映射的集合，這個映射通過row-key來唯一標識。Hbase利用Hadoop的基礎設施，可以利用通用的設備進行水準的擴展。
五、HIVE
Hive是一個構建在Hadoop基礎設施之上的資料倉庫。通過Hive可以使用HQL語言查詢存放在HDFS上的資料。
HQL是一種類SQL語言，這種語言最終被轉化為Map/Reduce。雖然Hive提供了SQL查詢功能，但是Hive不能夠進行交互查詢，因為它只能夠在Haoop上批量的執行Hadoop。
Hive被分區為表格，表格又被進一步分割為列簇。列簇必須使用schema定義，列簇將某一類型列集合起來(列不要求schema定義)。例如，“message”列簇可能包含：“to”, ”from” “date”, “subject”, 和”body”. 每一個 key/value對在Hbase中被定義為一個cell，每一個key由row-key，列簇、列和時間戳記。
第二名. Spark
Hadoop MapReduce計算模型雖然大行其道，並且在海量資料分析領域成績斐然，被很多公司廣泛採用。但是，因為Hadoop MapReduce每次操作之後將所有資料寫回到物理存儲介質(磁片)上，而使海量資料的處理性能大大折扣，這是一個令人頭痛的問題!
2009年，Spark誕生於伯克利AMPLab，2010年開源。
與Hadoop相比，Spark真正的優勢在於速度。因為Spark的大部分操作都是在記憶體中，記憶體比硬碟的讀取速度快上了N倍，所以Spark在某些計算類型上比Hadoop快上數倍，這也正是它發展迅速的主要原因。事實上，從創立到如今大紅大紫，Spark只花了8年左右的時間。
但是，Spark並不會取借Hadoop。Spark只是專注於計算，而不承擔資料存儲功能，它需要協力廠商存儲的支援，那就是Hadoop。
目前基於Hadoop和Spark的大資料生態日趨完善，人們對於Hadoop和Spark的認識也更加完整。Hadoop確立了大資料的處理框架，而Spark則是對Hadoop框架的改進，畢竟大資料是不斷發展的，而計算模型也需要與時俱進，計算模型的不斷更新才能適應企業資料發展的新特點。Spark豐富了企業大資料的選擇。
Spark的用戶和應用量一直在迅速增加，其中包括傳統工業廠商TOYOTA和著名O2O公司Uber與Airbnb，說明Spark的用戶領域不斷深化到傳統工業界和互聯網與傳統行業交叉的領域。不僅如此，越來越多的大資料商業版發行商例如Cloudera以及Hortonworks也開始將Spark納入其部署範圍，這無疑對Spark的商業應用和推廣起到巨大作用，另一方面也顯示Spark平臺技術的先進性。
因此，Spark以主流計算框架的地位而入三強，並且位列第二名。
Spark的體系結構不同於Hadoop，Spark主要包括Spark SQL、Spark Streaming、MLlib和GraphX。
一、Spark Streaming
Spark Streaming是基於Spark的上層應用框架，使用內建API，能像寫批次檔一樣編寫流處理任務，易於使用，它還提供良好的容錯特性，能在節點宕機情況下同時恢復丟失的工作和操作狀態。
在處理時間方面，Spark Streaming是基於時間片准即時處理，能達到秒級延遲，輸送量比Storm大，此外還能和Spark SQL與Spark MLlib聯合使用，構建強大的流狀態運行即席(ad-hoc)查詢和即時推薦系統。
二、Spark SQL
Spark SQL僅依賴HQL Parser、Hive metastore和Hive SerDe，即說明在解析SQL生成抽象語法樹(Abstract Syntax Tree，AST)後的部分都是由Spark SQL自身的Calalyst負責，利用scala模式匹配等函數式語言的特性，讓Catalyst開發的執行計畫優化策略比Hive更簡潔。除了HQL以外，Spark SQL還內建了一個精簡的SQL parser，以及一套Scala特定領域語言(Domain Specific Language， DSL)。也就是說，如果只是使用Spark SQL內建的SQL方言或Scala DSL對原生RDD物件進行關係查詢，使用者在開發Spark應用時完全不需要依賴Hive的任何東西，因而日後的發展趨勢重點在Spark SQL，對Shark的支持會逐漸淡化。
Spark SQL從Spark1.3開始支援提供一個抽象的程式設計結構DataFrames，能充當分散式SQL查詢引擎。DataFrame本質就是一張關係型數據庫中的表，但是底層有很多方面的優化，它能從多種資料來源中轉化而來，例如結構型資料檔案(如Avro, Parquet, ORC, JSON和JDBC)、Hive表、外部資料庫或已經存在的RDD。
三、MLlib
MLlib是Spark生態系統在機器學習領域的重要應用，它充分發揮Spark反覆運算計算的優勢，能比傳統MapReduce模型演算法快100倍以上。
MLlib 1.3實現了邏輯回歸、線性SVM、隨機森林、K-means、奇異值分解等多種分散式機器學習演算法，充分利用RDD的反覆運算優勢，能應對大規模資料應用機器學習模型，並能與Spark Streaming、Spark SQL進行協作開發應用，讓機器學習演算法在基於大資料的預測、推薦和模式識別等方面應用更廣泛。
四、GraphX
GraphX是另一個基於Spark的上層的分散式圖計算框架，提供了類似Google圖演算法引擎Pregel的功能，主要處理社交網路等節點和邊模型的問題。因為Spark能很好的支持反覆運算計算，故處理效率優勢明顯。
第三名. Elastic Stack
大資料時代，隨著存儲與計算集群的規模逐漸壯大，系統運維資料和設備日誌也越來越龐大而重要。這些資料既能回饋系統運行狀態，也能説明管理員通過日誌資料來挖掘價值。
日誌是帶有時間戳記的基於時間序列的機器資料，它與Hbase等資料庫存儲的半結構化的資料的資料格式是不一樣。因此，它無法被Hadoop Hbase庫直接處理。
技術人員在日誌處理方面，運用了各種方法及方案，總結起來，按時間先後可以歸納為如下三類：
剛開始，日誌只做事後追查，使用資料庫存儲日誌。這種方式，需要進行解析。
後來，採用Hadoop進行日誌的離線處理。這種方式的缺點是即時性差。
現在，採用開源日誌處理平臺Elastic Stack(ElasticSearch+Logstash+Kibana+Beats)。這種方式更靈活，擴展性更強。同時可配置Logstash 和Elasticsearch 集群用於支援大集群系統的運維日誌資料監控和查詢。自誕生之日起，就因為處理速度快，即時而發展迅速，如今已成為大資料日誌處理方面的標準解決方案。
一、Beats
Beats主要採集網路流量、檔log等資料。採集資料之後可以直接把資料發送給Elasticsearch或者通過Logstash發送給Elasticsearch，然後進行後續的資料分析活動。
Elastic官方的Beats有Packetbeat、Topbeat和Filebeat組成。其中，Packetbeat，有於分析網路報文，Topbeat是伺服器監控程序，而Filebeat用於收集日誌。
Beats獲取的資料都是未經處理的，通過Logstash發送資料給Elasticsearch，主要用於對採集資料進行二次處理。
二、ElasticSearch
根據百度百科的定義，ElasticSearch是一個基於Lucene的搜索伺服器。它提供了一個分散式多使用者能力的全文檢索搜尋引擎，基於RESTful web介面。
Elasticsearch是用Java開發的，並作為Apache許可條款下的開放源碼發佈，是當前流行的企業級搜尋引擎。設計用於雲計算中，能夠達到即時搜索，穩定，可靠，快速，安裝使用方便。
三、Logstash
logstash是一個日誌的傳輸、處理、管理平臺。可以用來對日誌進行收集管理，提供 Web 介面用於查詢和統計。
四、Kibana
Kibana是一個基於web介面的資料展示工具，有點類似於OpenFEA的KA自助功能。
總結
大資料自提出時起至今日，技術更新反覆運算迅速，無數昨天的技術明星成為今日黃花。大浪淘沙，經過多年的發展，我們以擁戴粉絲及應用廣度為評選標準，最終得出如下榜單，各位大資料愛好者，快來看看有沒有您鐘意的技術明星?
End.
同時擁有更多的智慧財產權和自主性。除了IT企業，金融、傳媒、零售、能源、製藥等傳統行業在大資料技術應用方面也積極回應，行業應用系統研發、服務需求和計算模型研究都在蓬勃開展。因此，Hadoop以應用最廣而入三強，並且位列第一名。
Hadoop框架最核心的設計是：HDFS和MapReduce。HDFS用於非結構化海量資料的存儲，MapReduce則為海量資料提供了計算。
另外，還有HBASE、HIVE、YARN等核心元件。Hbase，是運行在Hadoop上的一種分散式資料庫;HIVE，提供了類SQL的HQL語言查詢存放在HDFS上的資料;Yarn，可以很方便的管理諸如Hive、Hbase、Spark等應用，而MapReduce也需要運行在Yarn上面。
一、HDFS
HDFS是分散式運算的存儲基石，對於整個集群有單一的命名空間，具有資料一致性，適合一次寫入多次讀取的模型，用戶端在檔沒有被成功創建之前是無法看到檔存在的。檔會被分割成多個檔塊，每個檔塊被分配存儲到資料節點上，而且會根據配置由複製檔塊來保證資料的安全性。
HDFS通過三個重要的角色來進行檔案系統的管理：NameNode、DataNode和Client。NameNode可以看做是分散式檔案系統中的管理者，主要負責管理檔案系統的命名空間、集群配置資訊和存儲塊的複製等。
NameNode會將檔案系統的Metadata存儲在記憶體中，這些資訊主要包括檔資訊、每一個檔對應的檔塊的資訊和每一個檔塊在DataNode中的資訊等。
DataNode是檔存儲的基本單元，它將檔塊(Block)存儲在本地檔案系統中，保存了所有Block的Metadata，同時週期性地將所有存在的Block資訊發送給NameNode。
Client就是需要獲取分散式檔案系統檔的應用程式。
二、MapReduce
MapReduce是一個高性能的分散式運算框架，用於對海量資料進行並行分析和處理。與傳統資料倉庫和分析技術相比，MapReduce適合處理各種類型的資料，包括結構化、半結構化和非結構化資料。資料量在 TB 和 PB 級別，在這個量級上，傳統方法通常已經無法處理資料。MapReduce 將分析任務分為大量的並行Map 任務和Reduce匯總任務兩類。
Map 任務運行在多個伺服器上。指定一個Map(映射)函數，用來把一組鍵值對映射成一組新的鍵值對，指定併發的Reduce(歸約)函數，用來保證所有映射的鍵值對中的每一個共用相同的鍵組。把一堆雜亂無章的資料按照某種特徵歸納起來，然後處理並得到最後的結果。Map面對的是雜亂無章的互不相關的資料，它解析每個資料，從中提取出key和value，也就是提取了資料的特徵。經過MapReduce的Shuffle階段之後，在Reduce階段看到的都是已經歸納好的資料了，在此基礎上我們可以做進一步的處理以便得到結果。
三、YARN
Yarn是一個分散式的資源管理系統，用以提高分散式集群環境下記憶體、IO、網路、磁片等資源的利用率。嚴格來說，Yarn只是一個資源管理的框架，並不是一個計算框架，MapReduce計算框架需要運行在Yarn上。
Yarn，最主要的作用是，能夠使得各種應用可以互不干擾的運行在同一個Hadoop系統中，共用整個集群資源。
四、HBASE
Hbase是運行在Hadoop上的一種分散式資料庫，部署於HDFS之上，克服了HDFS在隨機讀寫方面的缺點。
HBase是一種Key/Value系統，和Hive不一樣，Hbase能夠在它的資料庫上即時運行，而不是運行MapReduce任務。在Hbase中，行是key/value映射的集合，這個映射通過row-key來唯一標識。Hbase利用Hadoop的基礎設施，可以利用通用的設備進行水準的擴展。
五、HIVE
Hive是一個構建在Hadoop基礎設施之上的資料倉庫。通過Hive可以使用HQL語言查詢存放在HDFS上的資料。
HQL是一種類SQL語言，這種語言最終被轉化為Map/Reduce。雖然Hive提供了SQL查詢功能，但是Hive不能夠進行交互查詢，因為它只能夠在Haoop上批量的執行Hadoop。
Hive被分區為表格，表格又被進一步分割為列簇。列簇必須使用schema定義，列簇將某一類型列集合起來(列不要求schema定義)。例如，“message”列簇可能包含：“to”, ”from” “date”, “subject”, 和”body”. 每一個 key/value對在Hbase中被定義為一個cell，每一個key由row-key，列簇、列和時間戳記。
第二名. Spark
Hadoop MapReduce計算模型雖然大行其道，並且在海量資料分析領域成績斐然，被很多公司廣泛採用。但是，因為Hadoop MapReduce每次操作之後將所有資料寫回到物理存儲介質(磁片)上，而使海量資料的處理性能大大折扣，這是一個令人頭痛的問題!
2009年，Spark誕生於伯克利AMPLab，2010年開源。
與Hadoop相比，Spark真正的優勢在於速度。因為Spark的大部分操作都是在記憶體中，記憶體比硬碟的讀取速度快上了N倍，所以Spark在某些計算類型上比Hadoop快上數倍，這也正是它發展迅速的主要原因。事實上，從創立到如今大紅大紫，Spark只花了8年左右的時間。
但是，Spark並不會取借Hadoop。Spark只是專注於計算，而不承擔資料存儲功能，它需要協力廠商存儲的支援，那就是Hadoop。
目前基於Hadoop和Spark的大資料生態日趨完善，人們對於Hadoop和Spark的認識也更加完整。Hadoop確立了大資料的處理框架，而Spark則是對Hadoop框架的改進，畢竟大資料是不斷發展的，而計算模型也需要與時俱進，計算模型的不斷更新才能適應企業資料發展的新特點。Spark豐富了企業大資料的選擇。
Spark的用戶和應用量一直在迅速增加，其中包括傳統工業廠商TOYOTA和著名O2O公司Uber與Airbnb，說明Spark的用戶領域不斷深化到傳統工業界和互聯網與傳統行業交叉的領域。不僅如此，越來越多的大資料商業版發行商例如Cloudera以及Hortonworks也開始將Spark納入其部署範圍，這無疑對Spark的商業應用和推廣起到巨大作用，另一方面也顯示Spark平臺技術的先進性。
因此，Spark以主流計算框架的地位而入三強，並且位列第二名。
Spark的體系結構不同於Hadoop，Spark主要包括Spark SQL、Spark Streaming、MLlib和GraphX。
一、Spark Streaming
Spark Streaming是基於Spark的上層應用框架，使用內建API，能像寫批次檔一樣編寫流處理任務，易於使用，它還提供良好的容錯特性，能在節點宕機情況下同時恢復丟失的工作和操作狀態。
在處理時間方面，Spark Streaming是基於時間片准即時處理，能達到秒級延遲，輸送量比Storm大，此外還能和Spark SQL與Spark MLlib聯合使用，構建強大的流狀態運行即席(ad-hoc)查詢和即時推薦系統。
二、Spark SQL
Spark SQL僅依賴HQL Parser、Hive metastore和Hive SerDe，即說明在解析SQL生成抽象語法樹(Abstract Syntax Tree，AST)後的部分都是由Spark SQL自身的Calalyst負責，利用scala模式匹配等函數式語言的特性，讓Catalyst開發的執行計畫優化策略比Hive更簡潔。除了HQL以外，Spark SQL還內建了一個精簡的SQL parser，以及一套Scala特定領域語言(Domain Specific Language， DSL)。也就是說，如果只是使用Spark SQL內建的SQL方言或Scala DSL對原生RDD物件進行關係查詢，使用者在開發Spark應用時完全不需要依賴Hive的任何東西，因而日後的發展趨勢重點在Spark SQL，對Shark的支持會逐漸淡化。
Spark SQL從Spark1.3開始支援提供一個抽象的程式設計結構DataFrames，能充當分散式SQL查詢引擎。DataFrame本質就是一張關係型數據庫中的表，但是底層有很多方面的優化，它能從多種資料來源中轉化而來，例如結構型資料檔案(如Avro, Parquet, ORC, JSON和JDBC)、Hive表、外部資料庫或已經存在的RDD。
三、MLlib
MLlib是Spark生態系統在機器學習領域的重要應用，它充分發揮Spark反覆運算計算的優勢，能比傳統MapReduce模型演算法快100倍以上。
MLlib 1.3實現了邏輯回歸、線性SVM、隨機森林、K-means、奇異值分解等多種分散式機器學習演算法，充分利用RDD的反覆運算優勢，能應對大規模資料應用機器學習模型，並能與Spark Streaming、Spark SQL進行協作開發應用，讓機器學習演算法在基於大資料的預測、推薦和模式識別等方面應用更廣泛。
四、GraphX
GraphX是另一個基於Spark的上層的分散式圖計算框架，提供了類似Google圖演算法引擎Pregel的功能，主要處理社交網路等節點和邊模型的問題。因為Spark能很好的支持反覆運算計算，故處理效率優勢明顯。
第三名. Elastic Stack
大資料時代，隨著存儲與計算集群的規模逐漸壯大，系統運維資料和設備日誌也越來越龐大而重要。這些資料既能回饋系統運行狀態，也能説明管理員通過日誌資料來挖掘價值。
日誌是帶有時間戳記的基於時間序列的機器資料，它與Hbase等資料庫存儲的半結構化的資料的資料格式是不一樣。因此，它無法被Hadoop Hbase庫直接處理。
技術人員在日誌處理方面，運用了各種方法及方案，總結起來，按時間先後可以歸納為如下三類：
剛開始，日誌只做事後追查，使用資料庫存儲日誌。這種方式，需要進行解析。
後來，採用Hadoop進行日誌的離線處理。這種方式的缺點是即時性差。
現在，採用開源日誌處理平臺Elastic Stack(ElasticSearch+Logstash+Kibana+Beats)。這種方式更靈活，擴展性更強。同時可配置Logstash 和Elasticsearch 集群用於支援大集群系統的運維日誌資料監控和查詢。自誕生之日起，就因為處理速度快，即時而發展迅速，如今已成為大資料日誌處理方面的標準解決方案。
一、Beats
Beats主要採集網路流量、檔log等資料。採集資料之後可以直接把資料發送給Elasticsearch或者通過Logstash發送給Elasticsearch，然後進行後續的資料分析活動。
Elastic官方的Beats有Packetbeat、Topbeat和Filebeat組成。其中，Packetbeat，有於分析網路報文，Topbeat是伺服器監控程序，而Filebeat用於收集日誌。
Beats獲取的資料都是未經處理的，通過Logstash發送資料給Elasticsearch，主要用於對採集資料進行二次處理。
二、ElasticSearch
根據百度百科的定義，ElasticSearch是一個基於Lucene的搜索伺服器。它提供了一個分散式多使用者能力的全文檢索搜尋引擎，基於RESTful web介面。
Elasticsearch是用Java開發的，並作為Apache許可條款下的開放源碼發佈，是當前流行的企業級搜尋引擎。設計用於雲計算中，能夠達到即時搜索，穩定，可靠，快速，安裝使用方便。
三、Logstash
logstash是一個日誌的傳輸、處理、管理平臺。可以用來對日誌進行收集管理，提供 Web 介面用於查詢和統計。
四、Kibana
Kibana是一個基於web介面的資料展示工具，有點類似於OpenFEA的KA自助功能。
總結
大資料自提出時起至今日，技術更新反覆運算迅速，無數昨天的技術明星成為今日黃花。大浪淘沙，經過多年的發展，我們以擁戴粉絲及應用廣度為評選標準，最終得出如下榜單，各位大資料愛好者，快來看看有沒有您鐘意的技術明星?
End.