大量數據的搜索和觀察 – Elasticsearch的應用

Posted by Mr. March

在資訊量越來越多,數據處理越來越繁忙的現代,對於海量數據的收集和觀察與搜索就成了一個很大的問題

Elasticssearch就是在這樣子的背景之下誕生,為了解決上述問題而提出的一套開放源碼的套件,而且它還不只單純可以用在搜尋上;合併Logstash和Kibana這兩個套件一起使用還能夠用在收集log data上,而這三種套件縮寫合稱ELK

筆者近來初次接觸使用ELK這套系統,算是小玩了一下這套件,就趁這個機會簡短跟大家介紹一下和分享自己的使用心得吧!
Elasticssearch(以下簡稱ES)使用的核心基底是Apache Lucene,於2010年間正式面世,並且在目前為只也獲得了廣泛的使用,例如Github,Stackoverflow,Wikipedia等等網站目前都使用elasticsearch做為搜尋引擎來使用;一方面是因為ES本身的擴展性佳,多語言支持,和擁有廣大的社群討論之外,ES本身所擁有的快速搜索速度也是其非常重要的一個優點,另外也有財經公司使用ES來做投資分析,從這裡也可以看出它在統計分析上也做的不錯,而目前最新的版本是5.1版
筆者本身也有導入使用ES做為搜尋系統,對於ES的處理和搜索速度留下了深刻的印象,在同時打入1000筆搜索要求,系統資料100多萬筆;ES對每筆搜索需求仍然在100-200ms內就回傳了結果,相較於筆者原先在使用的舊搜尋系統的效能簡直是有著數十倍天差地別的效能差異….(舊系統到差不多同時打入100筆左右就陣亡開始吐不出資料了);在資料建置上也有著壓倒性的快速,筆者所擁有的100多萬筆資料建置到ES內只花了20分鐘不到;而在系統穩定性方面由於是採用分散式備份的架構,除非所有儲存資料的機台同時全滅,系統所具有的自動同步修補機制,會自動將檔案補齊,雖然大部分的使用者仍然不建議將非常重要的資料只儲存在ES上,最好仍然在傳統DB上留有備份,但是以筆者用了差不多半年來看,基本上只要整個儲存系統內至少有兩個node,掉資料掉到找不回來的機率是很低的;在搜尋準確度的部分,個人認為ES所提供的搜尋結果算是很準確的,ES對於搜索的評分機制主要是使用tf/idf評分機制來做為文件回傳的排序依據,但是你也可以對文件內的各欄位設定權重值(例如可以覺得title欄位比較重要,就將title的權重設高一點);除了文字搜索之外,ES還可以做到數值轉換(直接將某欄位的數字值轉成分數加上文字搜索的評分結果再重新排序),衰減函數(時間,地區等等,離搜索者所指定的某個值越近則獲得越高的額外分數)等等計算文件分數的方式,這也讓使用者在客製化符合自己需求的ES搜索權重有了更高的彈性;在語系支援方面,ES原生支援非常多種語言的斷詞方式,但是卻沒有中文,所幸ES擁有龐大的使用者社群,有人開發了支援中文的plug-in,筆者目前是使用ik這一套,斷詞基本上倚賴套件內所儲存好的字典檔(當然,每個人可以自由修改自己系統所使用的字典檔,這點算是非常有彈性的,但是這套件並不具有自我學習新詞的能力,需要人餵給它新字詞,算是比較不方便的地方….)

ES除了用在搜尋之外,ELK這套體系更是很常被用於收集log上,想像一下你現在管理了幾十台上線的機台,而一旦發生了問題你必須去幾十台機台上一台台檢查log….,這實在是一件非常痛苦又折磨人的事情,而導入ELK之後,事情變得很簡單,你只需要運用Logstash將這些機台的log都收入進ELK內,並透過Kibana讓你可以方便下關鍵字搜索出所有機台上的log,不得不說這簡直是維運工程師的福音,因為你較以往減少了非常多垃圾時間在找log上,而可以將時間更專注在處理你系統所發生的問題上,同時藉助ELK的收集和統計,你可以更簡單的獲得一些你系統上的統計資訊(只要你有埋相關重要資訊的log進去),現今有許多製造業已經導入ELK做為工廠生產log分析的工具,而有些網站也導入ELK做為網站維運系統分析的部分

ELK做為開放源碼套件,大部分的基礎功能都是免費的,當然針對企業部分他們有推出顧問和其他的加值服務(X-pack的部分),筆者對於加值服務部分尚未有太多的接觸,並不很熟悉(就筆者的了解主要是著重在ES的security,ES健康度監控,事件觸發通知部分),但我覺得在免費所能取得的搜尋,資料收集與整理的部分,著實讓我吃驚於它優異的處理速度和準確度,更重要的是整套系統個人認為學習使用和建置都非常的容易上手,推薦給有空的人也可以拿來玩玩研究看看

 

參考資料 : https://www.elastic.co/guide/en/elasticsearch/reference/5.1/index.html

喜歡這篇文章嗎? 分享出去給作者一點鼓勵吧!