splunk VS elasticsearch

時間 2019-11-09

原文原文鏈接

本文就架構，功能，產品線，概念等方面就ElasticSearch和Splunk作了一下全方位的對比，但願可以你們在制定大數據搜索方案的時候有所幫助。html

簡介

ElasticSearch （1）（2）是一個基於Lucene的開源搜索服務。它提供了一個分佈式多用戶能力的全文搜索引擎，基於RESTful web接口。Elasticsearch是用Java開發的，並做爲Apache許可條款下的開放源碼發佈，是當前流行的企業級搜索引擎。設計用於雲計算中，可以達到實時搜索，穩定，可靠，快速，安裝使用方便。node

ELK是ElasticSearch，Logstash，Kibana的縮寫，分別提供搜索，數據接入和可視化功能，構成了Elastic的應用棧。python

Splunk 是大數據領域第一家在納斯達克上市公司，Splunk提供一個機器數據的引擎。使用 Splunk 可收集、索引和利用全部應用程序、服務器和設備（物理、虛擬和雲中）生成的快速移動型計算機數據。從一個位置搜索並分析全部實時和歷史數據。使用 Splunk 處理計算機數據，可以讓您在幾分鐘內（而不是幾個小時或幾天）解決問題和調查安全事件。監視您的端對端基礎結構，避免服務性能下降或中斷。以較低成本知足合規性要求。關聯並分析跨越多個系統的復瑣事件。獲取新層次的運營可見性以及 IT 和業務智能。ios

根據最新的數據庫引擎排名顯示，Elastic，Solr和Splunk分別佔據了數據庫搜索引擎的前三位。git

從趨勢上來看，Elastic和Splunk上升明顯，Elastic更是表現出了很是強勁的勢頭。github

基本概念

Elasticweb

準實時(NRT)
Elasticsearch是一個準實時性的搜索平臺，從數據索引到數據能夠被搜索存在必定的時延。docker
索引（Index）
索引是有共同特性的文檔的集合，索引有本身的名字，能夠對索引執行搜索，更新，刪除等操做。數據庫
類型（Type）
每一個索引能夠包含一個或者多個類型，類型能夠看做一個索引數據的邏輯分組，一般咱們會把擁有相同字段的文檔定義爲同一個類型。apache
文檔（Document）
文檔是索引信息的基本單元。Elastic中文檔表現爲JSON對象，文檔物理存貯在索引中，並須要被制定一個類型。由於表現爲JSON，很天然的，文檔是由一個個的字段（Feilds）組成，每一個字段是一個名值對（Name Value Pair）
評分（score）
Elastic是基於Lucene構建的，因此搜索的結果會有一個打分。來評價搜索結果和查詢的相關性。

下圖是一個Elastic的搜索在Kibana中看到的例子，原始的數據是一個簡單的日誌文件：

咱們經過logstash索引到Elasticsearch後，就能夠搜索了。

Splunk

實時性
Splunk一樣是準實時的，Splunk的實時搜索（Realtime Search）能夠提供不間斷的搜索結果的數據流。
事件（Event）
對應於Elastic的文檔，Splunk的數據索引的基本單元是事件，每個事件包含了一組值，字段，時間戳。Splunk的事件能夠是一段文本，一個配置文件，一段日誌或者JSON對象。
字段（Fields）
字段是能夠被搜索的名值對，不一樣的事件可能擁有不一樣的字段。Splunk支持索引時（index time）和搜索時（search time）的字段抽取（fields extraction）
索引（Indexes）
相似Elastic的索引，全部的事件物理存儲在索引上，能夠把索引理解爲一個數據庫的表。
知識對象（Knowledge Object）
Splunk的知識對象提供對數據進一步的解釋，分類，加強等功能，包括：字段（fields），字段抽取（fields extraction），事件類型（event type），事務（transaction），查找（lookups），標籤（tags），別名（aliases），數據模型（data model）等等。

下圖是一個Splunk的搜索在Splunk客戶端看到的和前一個例子一樣的日誌數據的搜索結果。

從基本概念上來看，Elasticsearch和Splunk基本一致。從例子中咱們能夠看到不少的共性，事件／文檔，時間戳，字段，搜索，時間軸圖等等。其中有幾個主要的差異：

Elastic不支持搜索時的字段抽取，也就是說Elastic的文檔中的全部字段在索引時已經固定了，而Splunk支持在搜索時，動態的抽取新的字段
Elastic的搜索是基於評分機制的，搜索的結果有一個打分，而Splunk沒有對搜索結果評分
Splunk的知識對象能夠提供對數據更高級，更靈活的管理能力。

用戶接口

ElasticSearch提供REST API來進行

集羣的管理，監控，健康檢查
索引的管理（CURD）
搜索的執行，包括排序，分頁，過濾，腳本，聚合等等高級的搜索功能。

Elasticsearch 自己並無提供任何UI的功能，搜索能夠用Kibana，可是沒有管理UI仍是讓人不爽的，好在開源的好處就是會有不少的開發者來構建缺失的功能：

ElasticHQ
cerebro (推薦，界面乾淨，我喜歡)
dejavu

另外一選擇就是安裝X-Pack，這個是要收費的。

Splunk做爲企業軟件，管理及訪問接口比較豐富，除了REST API 和命令行接口，Splunk的UI很是友好易用，基本上全部的功能都能經過集成的UI來使用。同時提供如下接口

REST API
Splunk UI
CLI

功能

數據接入和獲取

Elastic棧使用Logstash和Beats來進行數據的消化和獲取。

Logstash用jruby實現，有點像一個數據管道，把輸入的數據進行處理，變形，過濾，而後輸出到其它地方。Logstash 設計了本身的 DSL，包括有區域，註釋，數據類型(布爾值，字符串，數值，數組，哈希)，條件判斷，字段引用等。

Logstash的數據管道包含三個步驟，Input，Filter和Output，每一步均可以經過plugin來擴展。另外Input和Output還支持配置Codecs，完成對輸入輸出數據的編解碼工做。

Logstash支持的常見的Input包含File，syslog，beats等。Filter中主要完成數據的變形處理，能夠增刪改字段，加標籤，等等。做爲一個開源軟件，Output不只僅支持ElasticSearch，還能夠和許多其它軟件集成和目標，Output能夠是文件，graphite，數據庫，Nagios，S3，Hadoop等。

在實際運用中，logstash 進程會被分爲兩個不一樣的角色。運行在應用服務器上的，儘可能減輕運行壓力，只作讀取和轉發，這個角色叫作 shipper；運行在獨立服務器上，完成數據解析處理，負責寫入 Elasticsearch 的角色，叫 indexer。

logstash 做爲無狀態的軟件，配合消息隊列系統，能夠很輕鬆的作到線性擴展

Beats是 Elastic 從 packetbeat 發展出來的數據收集器系統。beat 收集器能夠直接寫入 Elasticsearch，也能夠傳輸給 Logstash。其中抽象出來的 libbeat，提供了統一的數據發送方法，輸入配置解析，日誌記錄框架等功能。

開源社區已經貢獻了許多的beats種類。

由於Beats是使用Golang編寫的，效率上很不錯。

Splunk使用Farwarder和Add-ons來進行數據的消化和獲取。

Splunk內置了對文件，syslog，網絡端口等input的處理。當配置某個節點爲Forwarder的時候，Splunk Forwarder能夠做爲一個數據通道把數據發送到配置好的indexer去。這時候，它就相似logstash。這裏一個主要的區別就是對數據字段的抽取，Elastic必須在logstash中經過filter配置或者擴展來作，也就是咱們所說的Index time抽取，抽取後不能改變。Splunk支持Index time的抽取，可是更多時候，Splunk 在index time並不抽取而是等到搜索是在決定如何抽取字段。

對於特定領域的數據獲取，Splunk是用Add-on的形式。Splunk 的App市場上有超過600個不一樣種類的Add-on。

用戶能夠經過特定的Add-on或者本身開發Add-on來獲取特定的數據。

對於大數據的數據採集，你們也能夠參考個人另外一篇博客。

數據管理和存儲

ElasticSearch的數據存貯模型來自於Lucene，基本原理是實用了倒排表。你們能夠參考這篇文章。

Splunk的核心一樣是倒排表，推薦你們看這篇去年Splunk Conf上的介紹，Behind the Magnifying Glass: How Search Works

Splunk的Event存在許多Buckets中，多個Buckets構成邏輯分組的索引分佈在Indexer上。

每一個Bucket中都是倒排表的結構存儲數據，原始數據經過gzip壓縮。

搜索時，利用Bloom filter定位數據所在的bucket。

在對數據的存儲管理上，Elastic 和Splunk都是利用了倒排表。Splunk對數據進行壓縮，因此存儲空間的佔用要少不少，尤爲考慮到大部分數據是文本，壓縮比很高的，固然這會損失一部分性能用於數據的解壓。

數據分析和處理

對數據的處理分析，ElasticSearch主要使用 Search API來實現。而Splunk則提供了很是強大的SPL，相比起ES的Search API，Splunk的SPL要好用不少，能夠說SPL就是非結構化數據的SQL。不管是利用SPL來開發分析應用，仍是直接在Splunk UI上用SPL來處理數據，SPL都很是易用。開源社區也在試圖爲Elastic增長相似SPL的DSL來改善數據處理的易用性。例如：

https://github.com/chenryn/ESPL

從這篇反饋能夠看出，ES的search還有許多的不足。

做爲對此的響應，Elastic推出了painless script，該功能還處於實驗階段。

數據展示和可視化

Kibana是一個針對Elasticsearch的開源分析及可視化平臺，用來搜索、查看交互存儲在Elasticsearch索引中的數據。使用Kibana，能夠經過各類圖表進行高級數據分析及展現。

Splunk集成了很是方便的數據可視化和儀表盤功能，對於SPL的結果，能夠很是方便的經過UI的簡單設置進行可視化的分析，導出到儀表盤。

下圖的比較來自https://www.itcentralstation.com/products/comparisons/kibana_vs_splunk

在數據可視化的領域的排名，Splunk僅僅落後於Tableau而已

擴展性

從擴展性的角度來看，兩個平臺都擁有很是好的擴展性。

Elastic棧做爲一個開源棧，很容易經過Plugin的方式擴展。包括：

Splunk提供一系列的擴展點支持應用和Add-on的開發，在http://dev.splunk.com/能夠找到更多的信息和文檔。包括：

比起Elastic的Plugin，Splunk的擴展概念上比較複雜，開發一個App或者Add-on的門檻都要相對高一些。作爲一個數據平臺，Splunk應該在擴展性上有所改進，使得擴展變的更爲容易和簡單。

架構

Elastic Stack

如上圖所示，ELK是一套棧，Logstash提供數據的消化和獲取，Elasticsearch對數據進行存儲，索引和搜索，而Kibana提供數據可視化和報表的功能。

Splunk

Splunk的架構主要有三個角色：

Indexer
Indexer提供數據的存儲，索引，相似Elasticsearch的做用
Search Head
Search Head負責搜素，客戶接入，從功能上看，一部分是Kibana，由於Splunk的UI是運行在Search Head上的，提供全部的客戶端和可視化的功能，還有一部分，是提供分佈式的搜索功能，包含對搜索的分發到Indexer和搜索結果的合併，這一部分功能對應在Elasticsearch上。
Forwarder
Splunk的Forwarder負責數據接入，相似Logstash

除了以上的三個主要的角色，Splunk的架構中還有：Deployment Server，License Server，Master Cluster Node，Deployer等。

Splunk和ELK的基本架構很是相似，可是ELK的架構更爲簡單和清楚，Logstash負責數據接入，Kibana負責數據展示，全部的複雜性在Elasticsearch中。Splunk的架構更爲複雜一些，角色的類型也更多一些。

若是裝單機版本，Splunk更容易，由於全部的功能一次性就裝好了，而ELK則必須分別安裝E/L/K，從這一點上來看，Splunk有必定的優點。

分佈集羣和擴展性

ElasticSearch

ElasticSearch是爲分佈式設計的，有很好的擴展性，在一個典型的分佈式配置中，每個節點（node）能夠配製成不一樣的角色，如上圖所示：

Client Node，負責API和數據的訪問的節點，不存儲／處理數據
Data Node，負責數據的存儲和索引
Master Node，管理節點，負責Cluster中的節點的協調，不存儲數據。

每一種角色能夠經過ElasticSearch的配置文件或者環境變量來配置。每一種角色均可以很方便的Scale，由於Elastic採用了對等性的設計，也就是全部的角色是平等的，（Master Node會進行Leader Election，其中有一個是領導者）這樣的設計使得在集羣環境的伸縮性很是好，尤爲是在容器環境，例如Docker Swarm或者Kubernetes中使用。

參考：

Splunk

Splunk做爲企業級的分佈式機器數據的平臺，擁有強大的分佈式配置，包括跨數據中心的集羣配置。Splunk提供兩種集羣，Indexer集羣和Search Head集羣。

Splunk Indexer集羣

如上圖所示，Splunk的indexer集羣主要由三種角色：

Master Node，Master Node負責管理和協調整個的集羣，相似ES的Master。可是隻有一個節點，不支持多Master（最新版本6.6）。Master Node負責
- 協調Peer Node之間的數據複製
- 告訴Search Head數據在哪裏
- Peer Node的配置管理
- Peer Node故障時的故障恢復
Peer Nodes，負責數據索引，相似ES的Data Node，Peer Node負責
- 存儲索引數據
- 發送／接收復制數據到其餘Peer節點
- 響應搜索請求
Search Head，負責數據的搜索和客戶端API訪問，相似ES的Client Node，但不徹底相同。Search Head負責發送搜索請求到Peer Nodes，並對搜索的結果進行合併。

有人會問，那Master是否是集羣中的單點故障？What if Master node goes down？Splunk的回答是否。即便Master 節點出現故障，Peer Nodes仍然能夠正常工做，除非，同時有Peer Node出現故障。

Splunk Search Header 集羣

Search Head集羣是由一組Search Head組成，它們共享配置，搜索任務等狀態。該Cluster主要有如下角色：

Deployer，負責分發狀態和應用到peers
Cluster Member，其中有一個是Captain，負責協調。Cluster Memeber之間會互相通訊，來保證狀態一致。Load Balancer是個可選項，能夠負責Search的接入。
Search Peers，負責數據索引的 Indexer Nodes

另外Splunk還曾經提供過一個功能叫作Search Head Pooling，不過如今已經Depecated了。

Indexer集羣能夠和Search Head集羣一塊兒配置，構成一個分佈式的Splunk配置。

相比較ES的相對比較簡單的集羣配置，Splunk的集羣配置比較複雜，ES中全部每個節點能夠靈活的配置角色，而且能夠相對比較容易的擴展，利用例如Kubernetes的Pod的複製能夠很容易的擴展每個角色。擴展Splunk相對比較困難，要作到動態的伸縮，須要比較複雜的配置。你們能夠參考這裏，在容器環境裏配置一個Splunk的集羣須要比較多的佈置，例如在這個Master的配置中，用戶須要考慮：

如何配置License
修改缺省的用戶名口令
爲每個Search Head配置Search Head Cluster
等待Splunk進程成功啓動
配置業務發現
安裝應用
… …

而且集羣的擴展很難直接利用容器編排平臺提供的擴展接口，這一點Splunk還有不少提升的空間。

產品線

Elastic

Elastic的產品線除了你們熟悉的ELK（ElasticSearch，Logstash，Kikana），主要包含

Beats Beats是一個開源組件，提供一個代理，把本地抓到的數據傳送到ElasticSearch
Elastic Cloud， Elasti提供的雲服務
X-Pack， Elastic的擴展組件，提供安全，告警，監控，機器學習和圖處理能力。主要功能須要付費使用。

Splunk

Splunk的產品線包括

Splunk Enterprise
Splunk Cloud， Splunk運營的雲服務，跑在AWS上
Splunk Light，Splunk Light版本，功能有所精簡，面向中小企業
Hunk， Splunk on Hadoop
Apps ／ Add-ons, Splunk提供大量的應用和數據獲取的擴展，能夠參考 http://apps.splunk.com/
Splunk ITSI （IT Service Intelligence）， Splunk爲IT運維專門開發的產品
Splunk ES （Enterprise Security）， Splunk爲企業安全開發的產品，這個是Splunk 公司的拳頭產品，連續被Gartner評爲SIEM領域的領導者，挑戰了該行業的傳統巨鱷IBM，HP
Splunk UBA （User Behavior Analytic）， UBA是Splunk在15年收購的Caspidia帶來的基於機器學習的安全產品。