作者介紹：李猛(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首月免費
