Elasticsearch大咖說|攜程旅行：從日志分析平台到綜合性 Elasticsearch 管理平台

如果您想了解更多關于Elasticsearch中國開發者，請點選下載下傳 《Elasticsearch 中國開發者調查報告》 ，探索開發者的現狀和未來

第一期分享嘉賓

吳曉剛

攜程旅行網 系統研發總監

攜程旅行是國内領先的線上旅遊網站，主營業務是機票酒店和旅遊度假産品的線上預訂。目前ES平台，不僅是攜程日志分析的集中平台，也應用在很多其他垂直搜尋業務中，很好地解決了搜尋的資料規模化等問題。自2012年引入ELK技術棧以來，攜程的Elasticsearch叢集已發展到300多個，并積累了大量的運維經驗。

一、ES技術指南

話題1:如何學習ES及相關技術棧的知識？有什麼樣的學習資源推薦？

初級階段

對于新手入門最淺顯易懂的，還是官方那本Elasticsearch權威指南，而且中文社群的熱心網友已經将其翻譯成中文版。對于國内的使用者來說，這本書基于是ES2.0版本的，但對新手快速了解Elasticsearch的全貌，有非常大的幫助作用。

Elasticsearch是基于Lucene的，是以如果想深入了解底層技術的同學，有必要去學習Lucene的底層運作原理。這方面我推薦的書籍是《Lucene in Action》。

進階階段

對ES有一定基礎，還需要了解ES核心細節的同學，推薦閱讀中文社群大牛張超撰寫的《Elasticsearch源碼解析與優化實戰》。

另外，可以經常關注阿裡雲同學在知乎上開設Elasticsearch核心技術專欄，裡面有不少讨論ES核心技術内容。

最後，需要強調的是，隻是閱讀書籍和技術文章是遠遠不夠的，因為ES裡面有很多非常複雜的理論和知識，是以我們應該在實際工作中通過實踐去加深了解。如果你的項目中有ES的應用需求，就應該盡早地在項目中去嘗試使用。很顯然，你會在初期使用中踩到很多很多的坑，但是好處是，你帶着這些問題，再去進行發散性的學習，進步會更快。

話題2:ES開發者除了掌握ELK相關技術棧知識外，還需要了解哪些領域的知識？

我認為這主要取決于ES開發者在哪一種業務場景下工作。

比如ES應用在搜尋領域，目前ES對中文分詞器支援還不太友好，打分算法也難以滿足複雜的業務需求，這就需要ES開發者掌握自然語言處理相關知識，還需要深入學習Lucene和Elasticsearch内部的打分機制。結合具體的業務場景，開發者還需要做一些分詞插件或打分插件的開發。

還有一類應用場景，即開發者将ES用在資料分析領域，那麼他就需要學習大資料生态下的其他技術，比如傳統的Hadoop以及時下流行的Spark和Flink等等。通常情況下，沒有一種單一系統能滿足所有資料分析場景需求。

在架構方面，我們通常需要綜合多種技術，通過一些資料管道上的建設，将資料在不同系統之間打通，結合流式計算、批量計算或者全文索引等元件，建構比較完備的資料平台。

除此之外，玩大資料的同學，還需要掌握機器學習等相關技術，這樣可以針對存儲在ES中的資料，進行預測分析和異常檢測。

另外還有一類ES開發者專注在ES基礎平台建構方面，他們通常需要深入了解JVM内部原理、Linux等作業系統工作原理，以及Docker、Kubernetes等平台技術。如果想把ES更好地平台化，就需要對這些雲計算相關技術有更好的掌握。

二、ES從業者的職業發展

話題3:對ES開發者技術發展方向的看法

Elasticsearch 在分布式搜尋、實時資料分析、監控和安全等領域有非常多的成 功案例。近兩年來，國内各大公司基于 Elasticsearch 開發出商業化産品或内部 技術平台數不勝數，也越來越成熟。在未來幾年 Elastic Stack 也會像目前流行的 Flink 和 Kubernetes 等技術一樣，加速發展，應用範圍會越來越廣。我已經能感 受到，相關技術的架構、咨詢、開發及運維人員在人力資源市場上的需求正變得 越來越旺盛。

三、ES應用實踐

話題4:所在團隊業務背景介紹

攜程旅行是國内領先的線上旅遊網站，主營業務是機票酒店和旅遊度假産品的線上預訂。我主要負責網站工具和内部資訊系統研發以及公司IT部門的日常運作。在ES這部分，主要負責工具研發。

在早期的時候，我們公司的網站每天會産生大量監控資料和日志資料，但缺乏很好的收集和分析手段。大約從2012年開始，經過調研，我們發現在國外比較活躍的ELK技術棧能夠實作這些功能，是以，我們把他引入到攜程。然後經過這麼多年的不斷發展，目前ES平台，不僅是攜程日志分析的集中平台，也有大量的其他業務在使用。比如在搜尋方面，可以很好地解決搜尋的資料規模化問題，并支援靈活定制，是以在過去幾年在攜程的垂直搜尋業務領域也得到越來越多的應用。目前我們的Elasticsearch叢集，已經發展到300多個，運維問題變得至關重要。而我們團隊在運維方面擁有較多經驗，是以我組建了兩到三人的ES運維專家組，負責整個攜程ES叢集的管理平台開發和所有線上300多個叢集的運維和技術咨詢工作。

話題5:平台現狀以及未來發展方向

我們的ES叢集管理平台主要功能還是聚焦在叢集的監控、運維中繼資料管理等方面。但叢集本身還是跑在實體機和虛拟機上面，通過Ansible做集中控制，在叢集傳遞速度、擴縮容彈性、規範化治理、問題自動化診斷等方面還有相當的不足。近期ES團隊加深了和公司雲計算團隊的合作，正在基于Docker/K8s開發下一代的ES PAAS平台。

另外一些頭部網際網路公司已經在嘗試基于ES做搜尋中台，對上層的業務和資料分析系統的開發者屏蔽掉ES底層的複雜性，讓搜尋應用的開發進一步簡化，我想這也是我們未來要努力的方向。

話題6:ES在安全領域的應用

攜程安全團隊在安全資料收集和分析時大量應用到ES，比如通過FileBeat收集安全資料，通過MetricBeat收集性能名額，然後寫入到ES裡面，一方面通過Kibana去做資料可視化，另一方面在ES的API基礎上，會做一些資料異常檢測的規則。我們基于ELK不同的産品，陸續做了很多小工具。我們看到Elastic官方現在基于ELK推出了SIEM整體方案，這是一個很好的思路，從資料收集、實時索引、到關聯分析，以及機器學習等商業化元件，在安全領域系統性提出了解決方案，為安全開發人員降低了開發應用的難度。

話題7:ECS（Elastic Common Schema）和日志規範

ECS這樣的日志規範是非常有必要的。不同來源不同類型的日志，需要通過ECS去規範，後續才有可能進行關聯分析。前段時間，在參與我們公司新安全産品的開發過程中，我做了關于ECS的布道，希望可以參照ECS的方式，對日志進行schema的規範化定義。

話題8:攜程資料采集的現狀如何？

因為曆史遺留問題，資料采集在攜程有自己的特點。基于檔案的系統級資料，特别是日志資料采集，目前是由平台方去統一提供的，早期是自行開發的agent，現在已經全面參照Elastic官方的采集元件進行收集，比如Filebeat收集檔案日志，Winlogbeat收集Windows日志等等。在應用日志的收集方面，為減輕業務方的改動負擔，沿用了原有日志收集SDK，我們增加了資料通道，再轉運到ES中。

話題9: 日志平台的資料治理問題

日志平台存在的最大痛點還是資料治理問題。ELK 做為資料平台，是缺乏資料治理 能力的。當上線初期，資料規模還不是很大的時候，資料治理這方面需求還不是很 迫切。随着業務發展，接入的日志類型和資料增量快速增加，資料治理的痛點就會 逐漸凸顯。通常 Kibana 無法滿足使用者所有個性化的資料可視化需求，是以我們還 開放了 API 接口給業務方擷取資料，去做個性化的分析。API 接口一旦開放，當數 據規模達到一定程度，查詢、聚合或寫入等操作不當的話，經常會對叢集性能和穩 定性造成較大影響。這些問題都需要通過資料治理的方式來解決。是以，我們在日志平台的基礎上做一些日志資料治理工作，比如标準化規範化資料擷取方式。

四、ES技術前瞻

話題10:對于ES作為NoSQL資料庫替代方案的看法

ES現在有一個逐漸興起的應用方向，作為NoSQL資料庫來使用。針對那些關系型資料庫跑起來比較費力的複雜條件組合，而且不太需要事務性要求的場景，傳統的做法是使用關系型資料庫，為了解決海量資料查詢慢的問題，往往會分表分庫，并配合Redis緩存，整個架構上比較複雜，可靠性也會存在挑戰。現在利用Elasticsearch的反向索引和數值過濾，可以靈活實作複雜的條件組合查詢，查詢速度也非常快。而且ES内部不同類型的cache效率很高，一定程度上減少了對其他外部cache的依賴。是以，ES未來可能成為一種非常優秀的NoSQL資料庫。

但在這之前，ES有三個問題需要去解決：

第一個問題是資料可靠性問題。雖然我知道官方有文檔去追蹤資料一緻性方面的問題，随着ES版本的疊代，以我自己實踐經驗來看，已經很少出現丢資料的問題。但是從理論上來說依然存在資料一緻性問題，它畢竟不像mysql是多年理論和實踐驗證下來的非常可靠的資料庫。ES需要在特别極端的情況下，如某些節點丢失，恢複的過程中，驗證它的資料可靠性。

第二個需要解決的問題，作為NoSQL資料庫，ES的資料插入性能相對比較弱，這是和它底層實作是基于Lucene這樣的搜尋引擎有關系，資料寫入的時候，要做非常多的索引結構。

第三個問題在于資料更新，與傳統NoSQL資料庫的資料更新較小的開銷相比，ES的更新是先把原始資料讀出來，改好後再寫回去，對于比較大的文檔，ES的開銷是非常大的。

這幾點都會是阻礙ES成為一款高性能NoSQL資料庫的因素，不過随着官方功能疊代，ES在某些場景會成為NoSQL資料庫的一種替代選擇。

話題11:ES在監控運維領域的發展趨勢

我覺得Elasticsearch未來可能成為整個監控運維領域的事實标準。在監控領域，一般包含三類資料的收集和分析：性能資料（Metrics）、日志資料（Logs）、應用調用鍊資料（Trace）。以往，大家在這三個方面都是使用不同産品去做的。比如性能名額資料，傳統行業使用Zabbix比較多，網際網路使用新興的Prometheus、OpenFalon等。而日志方面，又自成一體，大家有不同的方案，比如商業産品Splunk、開源ELK。APM工具更是百花齊放。這三個工具一般情況下割裂開來的，而實際上，我們線上運維通常希望這幾個工具是結合起來使用的。

Elastic有個比較好的思路，借助ECS（Elastic Common Schema）等規範化工具，将性能資料（Metrics）、日志資料（Logs）、應用調用鍊資料（Trace）三類資料标準化，整合到一起，成為一體化的工具。在問題排查的過程中，運維工程師可以非常自然地在不同資料之間進行跳轉和關聯分析。目前Elastic已經陸續推出了Metrics、APM等方案，但他可能要解決的主要問題還是底層存儲的成本問題，對于海量metric和trace資料，存儲代價還是很高的。當然Elastic也作出了努力，比如針對metrics推出了rollup功能，類似準實時的流式計算，當資料進來的時候可以通過制定規則，删除實時把資料做聚合後再存儲，以減少存儲開銷。當未來Elastic能夠較好地解決資料存儲成本問題後，可能成為一款優秀的一體化監控運維産品。另外，Elastic引入了機器學習，對監控資料做智能化的異常檢測和預測，順應了監控報警系統AI化的趨勢。

加入我們

釘釘掃碼，加入“Elasticsearch技術交流群”，與更多開發者技術交流；

微信關注公衆号“Elasticsearch技術”，随時了解最新資訊；

!

往期好文

【最佳實踐】這樣運用阿裡雲Elasticsearch，讓你的資料庫馬上擁有強大的資料分析和搜尋能力。 從業務需求到能力擴充 | 阿裡雲Elasticsearch向量檢索能力的創變 【技術幹貨】想要高效采集資料到阿裡雲Elasticsearch，這些方法你知道嗎？