作者介紹：李猛(ynuosoft)，Elastic-stack 産品深度使用者，ES 認證工程師，2012 年接觸 Elasticsearch，對 Elastic-Stack 開發、架構、運維等方面有深入體驗，實踐過多種 Elasticsearch 項目，最暴力的大資料分析應用，最複雜的業務系統應用；業餘為企業提供 Elastic-stack 咨詢教育訓練以及調優實施。
Elasticsearch 認知
Elasticsearch 是什麼
Elasticsearch 是什麼，不同的人有不同的了解定位，之前寫過 Elasticsearch 對比其它資料産品的文章
《 Elasticsearch 對壘8大競品技術，孰優孰劣？》，看了文章下面的評論，很多人定位它是搜尋引擎，我覺得也很片面，下面就談談我的認知：
1）Elasticsearch 是搜尋引擎
Elasticsearch 在搜尋引擎資料庫領域排名絕對第一，核心基于 Lucene 建構，支援全文搜尋是職責所在，提供了豐富友好的 API。個人早期基于 Lucene 建構搜尋應用，需要考慮的因素太多，自接觸到 Elasticsearch 就再無自主開發搜尋應用。普通工程師要想掌控 Lucene 需要一些代價，且很多機制并不完善，需要做大量的周邊輔助程式，而 Elasticsearch 幾乎都已經幫你做完了。
2）Elasticsearch 不是搜尋引擎
說它不是搜尋引擎，估計很多從業者不認可，在個人涉及到的項目中，傳統意義上用 Elasticsearch 來做全文檢索的項目占比越來越少，多數時候是用來做精确查詢加速，查詢條件很多，可以任意組合，查詢速度很快，替代其它很多資料庫複雜條件查詢的場景需求；甚至有的資料庫産品直接使用 Elasticsearch 做二級索引，如 HBase、Redis 等。Elasticsearch 由于自身的一些特性，更像一個多模資料庫。
圖示：Elasticsearch 綜合資料庫排名熱度已經到第 7
3）Elasticsearch 是資料庫
Elasticsearch 使用 Json 格式來承載資料模型，已經成為事實上的文檔型資料庫，雖然底層存儲不是 Json 格式，同類型産品有大名鼎鼎的 MongoDB，不過二者在産品定位上有差别，Elasticsearch 更加擅長的基于查詢搜尋的分析型資料庫，傾向 OLAP；MongoDB 定位于事務型應用層面 OLTP，雖然也支援資料分析，筆者簡單應用過之後再無使用，誰用誰知道。
4）Elasticsearch 不是資料庫
Elasticsearch 不是關系型資料庫，内部資料更新采用樂觀鎖，無嚴格的 ACID 事務特性，任何企圖将它用在關系型資料庫場景的應用都會有很多問題，很多其它領域的從業者喜歡拿這個來作為它的缺陷，重申這不是 Elasticsearch 的本質缺陷，是産品設計定位如此。
Elasticsearch 做什麼
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 從業者，首先是定位好自己的角色，依據角色需求去學習掌握必備的知識點。以下是筆者對于一個技術産品的劃分模型：
1、概念
Elasticsearch 涉及到的概念很多，核心概念其實就那麼幾個，對于一個新手來說，掌握概念目的是為了建立起自己的知識思維模型，将之後學習到的知識點做一個很好的歸納劃分；對于一個其它資料産品的老手來說 ，掌握概念的目的是為了與其它資料産品劃分比較，深入的了解各自的優劣，在之後工作中若有遇到新的業務場景，可以迅速做出抉擇。
IT 從業者普遍都有個感受，IT 技術發展太快了，各種技術架構産品層出不窮，學習掌握太難了，跟不上節奏。其實個人反倒覺得變化不大，基礎理論核心概念并沒有什麼本質的發展變化，無非是工程技術實操變了很多，但這些是需要深入實踐才需要的，對于概念上無需要。
作為一個技術總監，前端工程師工作 1～2 年的問題都可以問倒他，這是大家對于概念認知需求不一樣。
2、開發
開發工程師的職責是将需求變成可以落地運作的代碼。Elasticsearch 的應用開發工作總結起來就是增删改查，掌握必備的 Elasticsearch REST API，熟練運用足以。筆者之前任職某物流速運公司，負責 Elasticsearch 相關的工作，公司 Elasticsearch 的需求很多，尤其是查詢方面，Elasticsearch 最厲害的查詢是 DSL，這個查詢文法需要經常練習使用，否則很容易忘記，當每次有人詢問時，都安排一個工程師專門負責各種解答，他在編寫 DSL 方面非常熟練，幫助了很多的工程師新手使用 Elasticsearch，屏蔽了很多細節，若有一些難搞定的問題，會由我來解決，另外一方面作為負責人的我偶然還要請他幫忙編寫DSL。
Elasticsearch 後面提供了 SQL 查詢的功能，但比較局限，複雜的查詢聚合必須回到 DSL。
3、架構
Elasticsearch 叢集架構總體比較複雜，首先得深入了解 Elasticseach 背後實作的原理，包括叢集原理、索引原理、資料寫入過程、資料查詢過程等；其次要有很多案例實戰的機會，遇到很多挑戰問題 ，逐一排除解決，增加自己的經驗。
對于開發工程師來說，滿足日常需求開發無需掌握這些，但對于 Elasticsearch 技術負責人，就非常有必要了，面對各種應用需求，要能從架構思維去平衡，比如日志場景叢集需求、大資料分析場景需求、應用系統複雜查詢場景需求等，從實際情況設計叢集架構以及資源配置設定等。
4、運維
Elasticsearch 本質是一個資料庫，也需要有專門的 DBA 運維，隻是更偏重應用層面，是以運維職責相對傳統 DBA 沒有那麼嚴苛。對于叢集層面必須掌握叢集搭建，叢集擴容、叢集更新、叢集安全、叢集監控告警等；另外對于資料層面運維，必須掌握資料備份與還原、資料的生命周期管理，還有一些日常問題診斷等。
5、源碼
Elasticsearch 本身是開源，閱讀源碼是個很好的學習手段，很多獨特的特性官方操作文檔并沒有寫出來，需要從源碼中提煉，如叢集節點之間的連接配接數是多少，但對于多數 Elasticsearch 從業者來說，卻非必要。了解到國内主要是頭部大廠需要深入源碼定制化改造，更多的是集中在應用的便捷性改造，而非結構性的改造，Elastic 原廠公司有幾百人的團隊做産品研發，而國内多數公司就極少的人，是以從産量上來說，根本不是一個等級的。
如果把 Elasticsearch 比喻為一件軍事武器，對于士兵來說 ，熟練運用才是最重要的，至于改造應該是武器制造商的職責，一個士兵可以使用很多武器裝備，用最佳的組合才能打赢一場戰争，而不是去深入原理然後造輪子，容易本末倒置。
6、算法
算法應該算是資料産品本質的差別，關系型資料庫索引算法主要是基于 B-Tree， Elasticserach 索引算法主要是反向索引，算法的本質決定了它們的應用邊界，擅長的應用領域。
通常掌握一個新的資料産品時，個人的做法是看它的關鍵算法。早期做過一個地理位置搜尋相關的項目，基于某個坐标搜尋周邊的坐标資訊，開始的時候采用的是三角函數動态計算的方式，資料量大一點，掃描一張資料表要很久；後面接觸到 Geohash 算法，按照算法将坐标編碼，存儲在資料庫中，基于字首比對查詢，性能高效幾個數量級，感歎算法的偉大；再後面發現有專門的資料庫産品內建了 Geohash 算法，使用起來就更簡單了。
Elasticsearch 內建很多算法，每種算法實作都有它的應用場景。
擁抱 Elasticsearch 的方法
1、官方文檔
Elasticsearch 早期出過一本參考手冊《 Elastic 權威指南》，是一本很好的入門手冊，從概念到實戰都有涉及，缺點是版本針對的 2.0，過于陳舊，除去核心概念，其餘的皆不适用，目前最新版本已經是 7.7 了，跨度太大，
Elasticsearch 在跨度大的版本之間更新稍微比較麻煩，索引資料幾乎是不相容的，更新之後需要重建資料才可。
Elasticsearch 目前最好的參考資料是官方文檔，資料最全，同步釋出版本，且同時可以參考多個版本。
Elasticsearch 官方參考文檔也是最亂的，什麼資料都有，系統的看完之後感覺仍在此山中，有點類似一本字典，看完了字典，依然寫不好作文；而且資料還是英文的，至此就阻擋了國内大部分程式進入。
但想要學習 Elasticsearch，官方文檔至少要看過幾遍，便于迅速查詢定位。
2、系統學習
Elasticsearch 成名很早，國内也有很多視訊課程，多數比較碎片，或是紙上談兵，缺乏實戰經驗。Elasticsearch 有一些專門的書籍，建議購買閱讀，國内深度一些的推薦《 Elasticsearch 源碼解析與優化實戰》，國外推薦《 Elasticsearch 實戰》，而且看書還有助于培養系統思維。
Elasticsearch 技術棧功能特性很多，系統學習要保持好的心态，持之以恒，需要很長時間，也需要參考很多資料。
3、背後原理
Elasticsearch 是站在巨人肩膀上産品，背後借鑒了很多設計思想，內建了很多算法，官方的參考文檔在技術原理探讨這塊并沒有深入，僅僅點到為止。想要深入了解，必須得另辟蹊徑。
Elastic 官方的部落格有很多優質的文章，很多人因為英文的緣故會忽視掉，裡面有很多關鍵的實作原理，圖文并茂，寫得非常不錯；另外國内一些雲廠商由于提供了 Elasticsearch 雲産品，需要深度定制開發，也會有一些深入原理系列的文章，可以去閱讀參考，加深了解。對于已經有比較好的程式設計思維的人，也可以直接去下載下傳官方源碼，設定斷點調試閱讀。
4、項目實戰
項目實戰是非常有效的學習途徑，考過駕照的朋友都深有體會，教練一上來就直接讓你操練車，通過很多次的練習就掌握了。Elasticsearch 擅長的領域很多，總結一句話就是“非強事務 ACID 場景皆可适用”，是以可以做的事情也很多。
日志領域的需求會讓你對于資料寫入量非常的關心，不斷的調整優化政策，提高吞吐量，降低資源消耗；業務系統的需求會讓你對資料一緻性與時效性特别關心，從其它資料庫同步到 Elasticsearch，關注資料同步的速度，關注資料的準确性，不斷的調整你的技術方案與政策；大資料領域的需求會讓你對于查詢與聚合特别關注，海量的資料需要快速的檢索，也需要快速的聚合結果。
項目實戰的過程，就是一個挖坑填坑的過程，實戰場景多了，解決的問題多了，自然就掌握得很好了。
之前筆者在前公司任職時，所有涉及到的 Elasticsearch 疑難雜症都會找我解決，有一些項目采用别的資料産品問題比較多，也來找我評估更換 Elasticsearch 是否合适，以及給出相關建議。筆者認為最好的學習方式是找到組織，找到經驗豐富的大咖，持續交流學習，成長最快也最好。
聲明：本文由原文作者“李猛”授權轉載，對未經許可擅自使用者，保留追究其法律責任的權利。
【
阿裡雲Elastic Stack】100%相容開源ES，獨有9大能力，提供免費 X-pack服務（單節點價值$6000）
相關活動
更多折扣活動，請
通路阿裡雲 Elasticsearch 官網 阿裡雲 Elasticsearch 商業通用版，1核2G ,SSD 20G首月免費 阿裡雲 Logstash 2核4G首月免費