關于ES的幾個問題

本文來說下關于ES的幾個問題

文章目錄

• 概述
• ES認知
• • ES是什麼
  • ES做什麼
• 需求等級
• • 概念
  • 開發
  • 架構
  • 運維
  • 源碼
  • 算法
• 擁抱ES的方法
• • 官方文檔
  • 系統學習
  • 背後原理
  • 項目實戰
• 本文小結

概述

經常遇到很多朋友詢問，如何學好Elasticsearch？這個問題本質上很不好回答，但我一直又很想好好回答，是以本文就以我個人的經驗視角，跟大家探讨一下如何正确的擁抱Elasticsearch。若有不當之處，歡迎留言指正。

ES認知

ES是什麼

這個世界已然被資料淹沒。多年來，我們系統間流轉和産生的大量資料已讓我們不知所措。 現有的技術都集中在如何解決資料倉庫存儲以及如何結構化這些資料。 這些看上去都挺美好，直到你實際需要基于這些資料實時做決策分析的時候才發現根本不是那麼一回事。Elasticsearch是一個分布式、可擴充、實時的搜尋與資料分析引擎。無論你是需要全文搜尋，還是結構化資料的實時統計，或者兩者結合，Elasticsearch不僅僅隻是全文搜尋，我們還将介紹結構化搜尋、資料分析、複雜的人類語言處理、地理位置和對象間關聯關系等 — Elasticsearch: 權威指南

Elasticsearch是什麼，不同的人有不同的了解定位，下面就談談我的認知：

1）Elasticsearch是搜尋引擎

Elasticsearch在搜尋引擎資料庫領域排名絕對第一，核心基于Lucene建構，支援全文搜尋是職責所在，提供了豐富友好的API。個人早期基于Lucene建構搜尋應用，需要考慮的因素太多，自接觸到Elasticsearch就再無自主開發搜尋應用。普通工程師要想掌控Lucene需要一些代價，且很多機制并不完善，需要做大量的周邊輔助程式，而Elasticsearch幾乎都已經幫你做完了。

2）Elasticsearch不是搜尋引擎

說它不是搜尋引擎，估計很多從業者不認可，在個人涉及到的項目中，傳統意義上用Elasticsearch來做全文檢索的項目占比越來越少，多數時候是用來做精确查詢加速，查詢條件很多，可以任意組合，查詢速度很快，替代其它很多資料庫複雜條件查詢的場景需求；甚至有的資料庫産品直接使用Elasticsearch做二級索引，如HBase、Redis等。Elasticsearch由于自身的一些特性，更像一個多模資料庫。

3）Elasticsearch是資料庫

Elasticsearch使用Json格式來承載資料模型，已經成為事實上的文檔型資料庫，雖然底層存儲不是Json格式，同類型産品有大名鼎鼎的MongoDB，不過二者在産品定位上有差别，Elasticsearch更加擅長的基于查詢搜尋的分析型資料庫，傾向OLAP；MongoDB定位于事務型應用層面OLTP，雖然也支援資料分析，筆者簡單應用過之後再無使用，誰用誰知道。

4）Elasticsearch不是資料庫

Elasticsearch不是關系型資料庫，内部資料更新采用樂觀鎖，無嚴格的ACID事務特性，任何企圖将它用在關系型資料庫場景的應用都會有很多問題，很多其它領域的從業者喜歡拿這個來作為它的缺陷，重申這不是Elasticsearch的本質缺陷，是産品設計定位如此。

ES做什麼

Elasticsearch雖然是基于Lucene建構，但應用領域确實非常寬泛。

1）全文檢索

Elasticsearch靠全文檢索起步，将Lucene開發包做成一個資料産品，屏蔽了Lucene各種複雜的設定，為開發人員提供了很友好的便利。很多傳統的關系型資料庫也提供全文檢索，有的是基于Lucene内嵌，有的是基于自研，與Elasticsearch比較起來，功能單一，性能也表現不是很好，擴充性幾乎沒有。

如果，你的應用有全文檢索需求，建議你優先遷移到Elasticsearch平台上來，其提供豐富的Full text queries會讓你驚訝，一次用爽，一直用爽。

2）應用查詢

Elasticsearch最擅長的就是查詢，基于反向索引核心算法，查詢性能強于B-Tree類型所有資料産品，尤其是關系型資料庫方面。當資料量超過千萬或者上億時，資料檢索的效率非常明顯。

個人更看中的是Elasticsearch在通用查詢應用場景，關系型資料庫由于索引的左側原則限制，索引執行必須有嚴格的順序，如果查詢字段很少，可以通過建立少量索引提高查詢性能，如果查詢字段很多且字段無序，那索引就失去了意義；相反Elasticsearch是預設全部字段都會建立索引，且全部字段查詢無需保證順序，是以我們在業務應用系統中，大量用Elasticsearch替代關系型資料庫做通用查詢，自此之後對于關系型資料庫的查詢就很排斥，除了最簡單的查詢，其餘的複雜條件查詢全部走Elasticsearch。

3）大資料領域

Elasticserach已經成為大資料平台對外提供查詢的重要組成部分之一。大資料平台将原始資料經過疊代計算，之後結果輸出到一個資料庫提供查詢，特别是大批量的明細資料。

這裡會面臨幾個問題，一個問題是大批量明細資料的輸出，如何能在極短的時間内寫到資料庫，傳統上很多資料平台選擇關系型資料庫提供查詢，比如MySQL，之前在這方面吃過不少虧，瞬間寫入性能極差，根本無法滿足要求。另一個問題是對外查詢，如何能像應用系統一樣提供性能極好的查詢，不限制查詢條件，不限制字段順序，支援較高的并發，支援海量資料快速檢索，也隻有Elasticsearch能夠做到比較均衡的檢索。

從官方的釋出版本新特性來看，Elasticseacrch志在大資料分析領域，提供了基于列示存儲的資料聚合，支援的聚合功能非常多，性能表現也不錯，筆者有幸之前大規模深度使用過，頗有感受。

Elasticsearch為了深入資料分析領域，産品又提供了資料Rollup與資料Transform功能，讓檢索分析更上一層樓。在資料Rollup領域，Apache Druid的競争能力很強，筆者之前做過一些對比，單純的比較确實不如Druid，但自Elasticsearch增加了Transfrom功能，且單獨建立了一個Transfrom的節點角色，個人更加看好Elasticseach，跳出了Rollup基于時間序列的限制。

4）日志檢索

著名的ELK三件套，講的就是Elasticsearch，Logstash，Kibana，專門針對日志采集、存儲、查詢設計的産品組合。很多第一次接觸到Elasticsearch的朋友，都會以為Elasticsearch是專門做日志的，其實這些都是誤解，隻是說它很擅長這個領域，在此領域大有作為，名氣很大。

日志自身特點沒有什麼通用的規範性，人為的随意性很大，日志内容也是任意的，更加需求全文檢索能力，傳統技術手段本身做全文檢索很是吃力。而Elasticsearch本身起步就是靠全文檢索，再加上其分布式架構的特性，非常符合海量日志快速檢索的場景。今天如果還發現有IT從業人員用傳統的技術手段做日志檢索，應該要打屁股了。

如今已經從ELK三件套發展到Elastic Stack了，新增加了很多非常有用的産品，大大增強了日志檢索領域。

5）監控領域

名額監控，Elasticsearch進入此領域比較晚，卻趕上了好時代，Elasticsearch由于其反向索引核心算法，也是支援時序資料場景的，性能也是相當不錯的，在功能性上完全壓住時序資料庫。

Elasticsearch搞監控得益于其提供的Elastic Stack産品生态，豐富完善，很多時候監控需要立體化，除了名額之外，還需要有各種日志的采集分析，如果用其它純名額監控産品，如Promethues，遇到有日志分析的需求，還必須使用Elasticsearch，這對于技術棧來說，又擴增了，相應的掌控能力會下降，個人精力有限，無法同時掌握很多種資料産品，如此選擇一個更加通用的産品才符合現實。

6）機器學習

機器學習最近幾年風吹的很大，很多資料産品都內建了，Elasticsearch也必須有，而且做的更好，真正将機器學習落地成為一個産品 ，簡化使用，所見所得；而不像其它資料産品，僅僅內建算法包，使用者還必須開發很多應用支援。

Elasticsearch機器學習提供了兩種方式，一種是異常檢測類型，屬于無監督學習，采用聚類模型，通常應用在安全分析領域，檢測異常通路等；一種是資料幀分析，屬于分類與回歸，屬于監督學習，可用于在業務模型領域，如電商行業，價格模型分析。

Elasticsearch本身是資料平台，內建了部分機器學習算法，同時又內建了Kibana可視化操作，使得從資料采集、到模型訓練、到模型預測應用都可以一鍵式完成。

Elasticserach提供的機器學習套件，個人認為最應該應用在資料品質這個領域，幫助大資料平台自動檢測資料品質，進而降低人力提供效率。

需求等級

Elasticsearch整個的技術棧非常複雜，涉及到的理論與技術點非常多，完全掌握并不現實，作為一個IT從業者，首先是定位好自己的角色，依據角色需求去學習掌握必備的知識點。以下是筆者對于一個技術産品的劃分模型：

概念

Elasticsearch涉及到的概念很多，核心概念其實就那麼幾個，對于一個新手來說，掌握概念目的是為了建立起自己的知識思維模型，将之後學習到的知識點做一個很好的歸納劃分；對于一個其它資料産品的老手來說 ，掌握概念的目的是為了與其它資料産品劃分比較，深入的了解各自的優劣，在之後工作中若有遇到新的業務場景，可以迅速做出抉擇。

IT從業者普遍都有個感受，IT技術發展太快了，各種技術架構産品層出不窮，學習掌握太難了，跟不上節奏。其實個人反倒覺得變化不大，基礎理論核心概念并沒有什麼本質的發展變化，無非是工程技術實操變了很多，但這些是需要深入實踐才需要的，對于概念上無需要。

作為一個技術總監，前端工程師工作1～2年的問題都可以問倒他，這是大家對于概念認知需求不一樣。

開發

開發工程師的職責是将需求變成可以落地運作的代碼。Elasticsearch的應用開發工作總結起來就是增删改查，掌握必備的ES REST API，熟練運用足以。筆者之前任職某物流速運公司，負責Elasticsearch相關的工作，公司Elasticsearch的需求很多，尤其是查詢方面，ES最厲害的查詢是DSL，這個查詢文法需要經常練習使用，否則很容易忘記，當每次有人詢問時，都安排一個工程師專門負責各種解答，他在編寫DSL方面非常熟練，幫助了很多的工程師新手使用Elasticsearch，屏蔽了很多細節，若有一些難搞定的問題，會由我來解決，另外一方面作為負責人的我偶然還要請他幫忙編寫DSL。

Elasticsearch後面提供了SQL查詢的功能，但比較局限，複雜的查詢聚合必須回到DSL。

架構

Elasticsearch叢集架構總體比較複雜，首先得深入了解Elasticseach背後實作的原理，包括叢集原理、索引原理、資料寫入過程、資料查詢過程等；其次要有很多案例實戰的機會，遇到很多挑戰問題 ，逐一排除解決，增加自己的經驗。

對于開發工程師來說，滿足日常需求開發無需掌握這些，但對于Elasticsearch技術負責人，就非常有必要了，面對各種應用需求，要能從架構思維去平衡，比如日志場景叢集需求、大資料分析場景需求、應用系統複雜查詢場景需求等，從實際情況設計叢集架構以及資源配置設定等。

運維

Elasticsearch本質是一個資料庫，也需要有專門的DBA運維，隻是更偏重應用層面，是以運維職責相對傳統DBA沒有那麼嚴苛。對于叢集層面必須掌握叢集搭建，叢集擴容、叢集更新、叢集安全、叢集監控告警等；另外對于資料層面運維，必須掌握資料備份與還原、資料的生命周期管理，還有一些日常問題診斷等。

源碼

Elasticsearch本身是開源，閱讀源碼是個很好的學習手段，很多獨特的特性官方操作文檔并沒有寫出來，需要從源碼中提煉，如叢集節點之間的連接配接數是多少，但對于多數Elasticsearch從業者來說，卻非必要。了解到國内主要是頭部大廠需要深入源碼定制化改造，更多的是集中在應用的便捷性改造，而非結構性的改造，Elastic原廠公司有幾百人的團隊做産品研發，而國内多數公司就極少的人，是以從産量上來說，根本不是一個等級的。

如果把Elasticsearch比喻為一件軍事武器，對于士兵來說 ，熟練運用才是最重要的，至于改造應該是武器制造商的職責，一個士兵可以使用很多武器裝備，用最佳的組合才能打赢一場戰争，而不是去深入原理然後造輪子，容易本末倒置。

算法

算法應該算是資料産品本質的差別，關系型資料庫索引算法主要是基于B-Tree， Elasticserach索引算法主要是反向索引，算法的本質決定了它們的應用邊界，擅長的應用領域。

通常掌握一個新的資料産品時，個人的做法是看它的關鍵算法。早期做過一個地理位置搜尋相關的項目，基于某個坐标搜尋周邊的坐标資訊，開始的時候采用的是三角函數動态計算的方式，資料量大一點，掃描一張資料表要很久；後面接觸到Geohash算法，按照算法将坐标編碼，存儲在資料庫中，基于字首比對查詢，性能高效幾個數量級，感歎算法的偉大；再後面發現有專門的資料庫産品內建了Geohash算法，使用起來就更簡單了。

Elasticsearch內建很多算法，每種算法實作都有它的應用場景。

擁抱ES的方法

官方文檔

Elasticsearch早期出過一本參考手冊《Elastic權威指南》，是一本很好的入門手冊，從概念到實戰都有涉及，缺點是版本針對的2.0，過于陳舊，除去核心概念，其餘的皆不适用，目前最新版本已經是7.7了，跨度太大，Elasticsearch在跨度大的版本之間更新稍微比較麻煩，索引資料幾乎是不相容的，更新之後需要重建資料才可。

Elasticsearch目前最好的參考資料是官方文檔，資料最全，同步釋出版本，且同時可以參考多個版本。Elasticsearch官方參考文檔也是最亂的，什麼資料都有，系統的看完之後感覺仍在此山中，有點類似一本字典，看完了字典，依然寫不好作文；而且資料還是英文的，至此就阻擋了國内大部分程式進入。

但想要學習Elasticsearch，官方文檔至少要看過幾遍，便于迅速查詢定位。

系統學習

Elasticsearch成名很早，國内也有很多視訊課程，多數比較碎片，或是紙上談兵，缺乏實戰經驗。Elasticsearch有一些專門的書籍，建議購買閱讀，國内深度一些的推薦《Elasticsearch源碼解析與優化實戰》，國外推薦《Elasticsearch實戰》，而且看書還有助于培養系統思維。

Elasticsearch技術棧功能特性很多，系統學習要保持好的心态，持之以恒，需要很長時間，也需要參考很多資料。

背後原理

Elasticsearch是站在巨人肩膀上産品，背後借鑒了很多設計思想，內建了很多算法，官方的參考文檔在技術原理探讨這塊并沒有深入，僅僅點到為止。想要深入了解，必須得另辟蹊徑。

Elastic官方的部落格有很多優質的文章，很多人因為英文的緣故會忽視掉，裡面有很多關鍵的實作原理，圖文并茂，寫得非常不錯；另外國内一些雲廠商由于提供了Elasticsearch雲産品，需要深度定制開發，也會有一些深入原理系列的文章，可以去閱讀參考，加深了解。對于已經有比較好的程式設計思維的人，也可以直接去下載下傳官方源碼，設定斷點調試閱讀。

項目實戰

項目實戰是非常有效的學習途徑，考過駕照的朋友都深有體會，教練一上來就直接讓你操練車，通過很多次的練習就掌握了。Elasticsearch擅長的領域很多，總結一句話就是“非強事務ACID場景皆可适用”，是以可以做的事情也很多。

日志領域的需求會讓你對于資料寫入量非常的關心，不斷的調整優化政策，提高吞吐量，降低資源消耗；業務系統的需求會讓你對資料一緻性與時效性特别關心，從其它資料庫同步到ES，關注資料同步的速度，關注資料的準确性，不斷的調整你的技術方案與政策；大資料領域的需求會讓你對于查詢與聚合特别關注，海量的資料需要快速的檢索，也需要快速的聚合結果。

項目實戰的過程，就是一個挖坑填坑的過程，實戰場景多了，解決的問題多了，自然就掌握得很好了。

本文小結

本文在宏觀上介紹了一下ES相關的知識與内容，後面會對ES的細節部分和核心知識進行詳細的介紹。