序

  最開始使用Elasticsearch是兩年多前，在一家創業公司負責資料系統的建設，當時也有寫一些博文來分享使用方法。然而回過頭去想，覺得當時的很多認知不夠深入，或者說是當時的業務場景下沒有遇到更多的問題。很多時候，一個技術或工具，只有在更復雜的業務場景和更大的資料量下經歷實踐，才能有更深的體會與認識。
  過去一段時間，有幸在專案中繼續實踐Elasticsearch，從設計、研發到調優，逐漸對Elasticsearch有了些新的認知與心得，因此計劃撰寫一個專欄來較系統的整理一下。也許，一段時間後，又會覺得這些認識不夠深入，奈何這就是認知的過程。
  對於Elasticsearch的實踐，主要分為兩塊：應用層面的研發和叢集的運維，本專欄側重於前者。計劃撰寫5篇左右：

• 使用場景，探討幾種常見的業務場景，以及叢集建設的選擇
• 核心概念與原理，以圖文形式整理出核心的概念與原理
• Index與Shard設計，分享如何結合業務來設計Index和合理分配Shard
• 專案應用，分享Elasticsearch在筆者專案中的實踐
• 效能調優，分享資料寫入與查詢過程的效能調優方法

  需要首先指出的是，本專欄所使用的Elasticsearch版本是5.5。

正文

  作為專欄的第一篇，本文將嘗試從兩個角度來探討一下當前Elasticsearch的使用場景。一個是常見的業務場景，目的在於讓大家能夠感性的認識到Elasticsearch可以做什麼。在遇到類似業務場景時，可以想到Elasticsearch，用其形成解決方案或者作為評估物件之一。另一個是叢集建設方面，探討的問題是：自己搭建Elasticsearch叢集還是使用雲服務。

常見的業務場景

  下圖是官方的定位，Elasticsearch的核心特徵是資料搜尋與分析。與這兩個特徵相關的需求都可以考慮使用Elasticsearch，其本身是單純的，複雜的是具體業務。在不同的業務中，Elasticsearch扮演著不同的角色，也有著不同的實踐和優化方法。歸納起來，目前主要有三類常見的業務場景，筆者將逐一分析。

• ELK日誌系統
• 資料聚合分析
• 業務內搜尋

ELK日誌系統

  大概很多網際網路的朋友接觸Elasticsearch都是從ELK開始的，用來解決Log的集中式管理問題。這樣的需求來自於網際網路的快速發展，出現越來越多的叢集部署與分散式系統，導致服務產生的Log資訊分散在不同的機器上，無法有效的檢索與統計。以下面的應用服務叢集為例，為了做集中式Log管理，需要有一個Agent負責從每臺機器收集資訊，送到一個儲存系統集中儲存（該系統需要具備快速的文字搜尋功能)，然後通過一個視覺化UI來檢視和分析資訊。

  ELK以全家桶的形式為這一問題提供瞭解決方案，Logstash負責收集、解析資料，Elasticsearch負責儲存、檢索資料，Kibana提供視覺化功能。筆者曾在創業公司做資料分析（四）ELK日誌系統一文介紹過相關的使用方法。

  當然，這並不意味著ELK必須捆綁使用。一方面，Logstash是基於JRuby編寫，在部署和效能上的表現並不能滿足所有需求，所以很多人會將其替換為自己編寫的資料採集工具。同時Elastic官方也有提供Beats相關輕量級元件，可與Logstash組合使用。另一方面，也有很多人在Kibana的基礎上做二次開發，來增強相應的查詢功能，整合開源的告警功能等。但是Elasticsearch始終是核心元件，很少有人將其替換掉，源於其強大的搜尋功能恰好滿足Log的檢索需求。有一點建議是，ELK本身已經很好使用，除非有強烈的業務需求，否則沒有必要刻意去替換，先考慮用對、用好它。

資料聚合分析

  資料的維度統計查詢，是當前資料業務的一個主要需求。其配合相應的視覺化UI可以幫助使用者直觀的獲取資訊、做出決策等。比如，針對網路流量資料，檢視上班時間段，員工訪問視訊類網站的流量佔比。
  這樣的統計查詢基本可以歸納為：按照某些條件過濾 --> 針對某個維度分組 --> 統計資料（Sum/Count）。在海量資料下，如何實現快速查詢？（億級以上資料量，秒級查詢）

  首先，諸如MySQL這類關係型資料基本是無法勝任的，其無法突破單機的儲存和處理能力限制，而引入分片又會帶來應用層面的複雜度。其次，面對這樣的海量資料，通常有兩個思路：一個是根據需求，制定相應的預計算方案，通過ETL來提前算好相關的統計資料，但是不能很好的應對未知的維度資料。另一個就是不做預計算，Elasticsearch便是其中一個選擇，其他方案還有Presto/Spark SQL這樣基於記憶體的Map/Reduce計算框架等。
  Elasticsearch強大的搜尋與分析聚合能力使其可以很好的適用於這一業務場景。以筆者當前的專案來看，百億級資料可以做到秒級查詢。另外，Elasticsearch的一些特性，諸如alias等可以很好的幫助我們完成一些業務邏輯。
  當然，任何事情都不是完美的，選擇Elasticsearch得有兩個前提：第一，受限於其工作機制，聚合結果可能存在較小的偏差的；第二，資料需要規劃好，保持扁平結構，不能有JOIN的需求。

業務內搜尋

  現如今，搜尋功能幾乎是網際網路產品的標配，用於幫助使用者快速在產品中找到所需的資訊。筆者將這樣一類需求定義為業務內搜尋，其特性是在業務範圍內提供搜尋功能。比如下圖中的食譜類App，只需要支援對菜譜、食材這些業務內容進行搜尋，而無需關注其他資訊。

  基於Elasticsearch，可以快速構建這樣的搜尋功能。通常是採用DB與Elasticsearch配合的方案，DB負責資料儲存，Elasticsearch負責關鍵詞檢索。Elasticsearch可以在多維度上檢索與關鍵詞相關的資料，併為每個匹配結果生成一個相關度分數。當服務收到搜尋請求時，首先根據關鍵詞到Elasticsearch中進行檢索，然後根據檢索結果去DB中查詢資訊，並在應用層進行資料整理和排序。
  搜尋精度的調優是重點，也是最難的一部分。比如，如何建立業務內容的詞庫，如何進行合理分詞建立索引，如何調整搜尋權重等等。筆者曾經在做搜書系統（打造私人搜書系統之系統設計）時有過相關的簡單實踐，抽空會繼續將其整理出來。

叢集建設的選擇

  伴隨著雲服務的發展，Elasticsearch叢集的建設出現了以下三種選擇：

• 在自有的伺服器上構建Elasticsearch叢集，自己運維
• 在雲廠商提供的EC2機器上構建Elasticsearch叢集，自己運維
• 使用雲廠商提供的Elasticsearch雲服務構建Elasticsearch叢集

  第一種選擇以大公司為主，多以平臺的形式為整個公司提供服務；後面兩種主要面向中小型企業，多以產品為導向，即每個產品維護自己的叢集。對於第二種選擇，通常是需要構建穩定執行的Elasticsearch叢集，由專業的運維人員負責管理。而第三種選擇，通常是企業需要構建穩定執行的Elasticsearch叢集，並希望將更多的人力、物力放到業務層面而非叢集運維上面。隨著Elasticsearch雲服務的成熟，越來越多處於第二種選擇的企業開始考慮或正在遷移。
  Elasticsearch雲服務可幫助企業更好的做叢集擴充套件，解放運維，把關注點放到業務層面。以AWS Elasticsearch雲服務為例，它可以幫助使用者實現沒有downtime的擴充套件、版本升級等。目前，提供相關服務的有AWS、阿里雲、Elastic官方等等。當然，任何事情都有兩面性，在方便的同時也會帶來不方便，比如無法觸及到機器導致一些調優方案無法實施。
  其實，究竟應該如何選擇，更多是由一個企業所處的行業、企業戰略以及歷史背景來決定。


  不同的業務場景，加上不同的叢集構建方法，就會導致在使用Elasticsearch時的側重點不同，相關設計與優化的方法也會有所不同。筆者當前專案是採用AWS Elasticsearch雲服務構建，針對大資料聚合分析的業務場景，所以，在後面的博文中，會側重於這方面。

Bruce
2018/10/08 晚