分享嘉賓：于伯偉 58同城 高級架構(gòu)師

編輯整理：陳樹昌

內(nèi)容來源：DataFunTalk

導讀：Elasticsearch是一個分布式的搜索和分析引擎，可以用于全文檢索、結(jié)構(gòu)化檢索和分析，并能將這三者結(jié)合起來。Elasticsearch基于Lucene開發(fā)，現(xiàn)在是使用最廣的開源搜索引擎之一。Elasticsearch可以應用于在/離線日志流水、用戶標簽畫像、數(shù)據(jù)庫二級緩存、安全風控行為數(shù)據(jù)、圖數(shù)據(jù)庫索引、監(jiān)控數(shù)據(jù)、Wiki文檔檢索等應用場景。58同城有自己的主搜，而一些內(nèi)部創(chuàng)新搜索業(yè)務和大規(guī)模的數(shù)據(jù)實時OLAP ( On-Line Analytical Processing，聯(lián)機分析處理 ) 則是使用Elasticsearch。

本次分享的主題為58同城Elasticsearch應用及平臺建設實踐。主要內(nèi)容包括：

• 集群優(yōu)化治理

• 典型應用實踐

• 自動化平臺建設

• 后續(xù)規(guī)劃

01

集群優(yōu)化治理

1. 背景

早期Elasticsearch分布在58內(nèi)的各個業(yè)務部門自主維護，但是隨著Elasticsearch自身的功能加強，各業(yè)務團隊使用Elasticsearch的數(shù)量越來越多、使用的業(yè)務場景越來越重要，于是由數(shù)據(jù)庫部門對整個公司的Elasticsearch使用進行了收斂管理，在這個過程中數(shù)據(jù)庫部門同學遇到了很多問題和挑戰(zhàn)，具體如下：業(yè)務使用場景復雜多樣；Elasticsearch版本不統(tǒng)一；應用與Elasticsearch數(shù)據(jù)服務混合部署；缺乏有效監(jiān)控；服務器硬件型號多樣；索引接入無管控，找不到負責人；接入規(guī)范不統(tǒng)一，接入溝通成本高；無平臺管理，手動excel維護集群信息。

除了上面這些問題，接管Elasticsearch后，還面臨著服務性能方面的挑戰(zhàn)：索引變紅 ( 集群健康狀態(tài) )、索引寫不進去、查詢超時、內(nèi)存OOM、Master不響應等。

在做分享之前，DataFun的小伙伴給反饋了很多問題，這些問題很大一部分是與Elasticsearch集群的規(guī)劃相關，這有很多和我們之前遇到的問題也是一樣的。下面針對兩個處理比較多的問題來分享。

2. 典型問題之一：Elasticsearch集群的磁盤被打爆

造成磁盤被打爆有以下幾種原因：

• 索引泛濫，索引接入無流程管控

• 索引無生命周期管理

• 索引分片數(shù)量不合理，單分片過大

• 日志類索引未按天等細粒度劃分，單索引過大

• 多集群復用同一服務器節(jié)點

• 磁盤容量大小不一

這些問題比較基礎，其實也反映出早期在使用Elasticsearch時沒有很好的規(guī)劃。針對上面的各種問題，總結(jié)了如下幾點實踐經(jīng)驗：

• 集群管控收斂賬號權限，限制每個賬號操作索引的范圍。避免各個部門或業(yè)務隨意復用集群，比如不通過系統(tǒng)申請直接將其它各種日志或業(yè)務數(shù)據(jù)直接Load進Elasticsearch，造成索引泛濫無法治理。

• 索引生命周期管理。不管線上數(shù)據(jù)還是離線數(shù)據(jù)，應該有個消亡的過程。比如梳理過程甚至發(fā)現(xiàn)3年前的數(shù)據(jù)還存在，這極大的浪費了磁盤空間。

• 合理的分片數(shù)量規(guī)劃。分片數(shù)量的規(guī)劃其實和我們的數(shù)據(jù)量有很密切的關系的。比如節(jié)點的個數(shù)是多少、磁盤的空間是多少，我們建議盡量控制單個分片數(shù)量在100G以內(nèi)，避免單分片過大在均衡時將磁盤打爆。

• 日志類的索引，避免單個過大，按照天劃分是比較好的解決方案。如果按照天劃分索引仍然很大，這個時候就需要按小時更小粒度的劃分規(guī)則。

• 不同集群復用相同的服務器分區(qū)。由于Elasticsearch有自己的警戒水位線，之間會互相影響，很容易導致磁盤空間觸發(fā)達到上限問題。

3. 典型問題之二：Elasticsearch集群寫入變慢

Elasticsearch集群寫入變慢需要考慮以下幾個問題：

• 索引梳理，是否所有信息都要寫入？

• 分片數(shù)量是否合理？

• 業(yè)務需求是否需要多副本？

• Refresh時間是否可以更大？

• Logstash處理吞吐是否達到瓶頸？

• Translog刷新策略是否要優(yōu)化？

• 磁盤硬件IO是否太差？

針對上面這幾個問題我們的實踐經(jīng)驗是：

• 減少不必要的寫入。例如減少沒有必要的大文本類的寫入，因為這些大文本會耗更多的IO。

• 合理設置分片數(shù)量。分片數(shù)量不是越多越好，分片越多會導致寫入變慢。

• 多副本會極大的影響寫入吞吐。在Elasticsearch的寫入機制里，Primary要等待所有Replica寫完之后才能返回給客戶端。

• 對于日志類的索引沒有必要秒級刷新。大家可能都使用了默認配置刷新時間，其實調(diào)整為5秒、10秒也是可以接受的。目前很多日志類的我們設置為60秒。

• Logstash有吞吐瓶頸。之前測評在某一場景下，它的吞吐量也就1-2萬左右。業(yè)內(nèi)還有一些開源的工具替代Logstash，包括一些自研的程序，可以極大的提高寫入的吞吐。

• 明確服務器用的是SSD還是普通的SATA機械盤。ssd的讀寫速度會比普通的SATA機械盤快。目前針對一些業(yè)務數(shù)據(jù)我們采用冷熱分離策略，新數(shù)據(jù)庫寫入SSD磁盤，早期的數(shù)據(jù)會自動均衡到SATA機械盤。

4. 開發(fā)規(guī)范

針對這些影響業(yè)務穩(wěn)定性的問題，我們內(nèi)部制定了相應的規(guī)范約束：

日志類應用：

• 提供容量與吞吐量預估

  注：在新業(yè)務接入時，我們要求業(yè)務方提供當前業(yè)務的容量和吞吐量的預估值 ( 例如：每天的增量數(shù)據(jù)有多少條、保留的時間是多少 )。

• 提供靜態(tài)mapping結(jié)構(gòu)

  注：包括對日志類的業(yè)務，我們也強烈建議使用靜態(tài)mapping。

• 統(tǒng)一接入大數(shù)據(jù)部門Kafka集群，并提供topic和ClientId

• 提供Logstash filter過濾規(guī)則配置

• 索引配置，默認5分片1副本 ( 可調(diào)整 )

• 數(shù)據(jù)保留策略，建議不超過30天

• 索引按天劃分，命名規(guī)則建議為：前綴+日期時間戳，如xxx-2020-02-01

  注：這里還是強烈建議日志類索引按照天劃分。

• 禁止私自接入新索引，接入賬號權限限制匹配特定索引前綴

非日志類應用：

這類多是數(shù)據(jù)檢索類的服務。

• 提供容量與吞吐量預估

• 提供業(yè)務類型評估，線上一級核心業(yè)務優(yōu)先接入公司主搜服務

• 注：因為這會涉及公司的商業(yè)搜索策略。

• 重要業(yè)務獨享集群，非核心業(yè)務復用公共集群

• 注：重要的業(yè)務要保證業(yè)務的可靠性、穩(wěn)定性。

• 提供靜態(tài)mapping結(jié)構(gòu)

• 索引配置，默認5分片2副本

• 注：根據(jù)實際業(yè)務進行動態(tài)調(diào)整。

• 禁止私自接入新索引，接入賬號權限限制匹配特定索引前綴

5. Elasticsearch服務架構(gòu)

在整合所有Elasticsearch之后，我們統(tǒng)一了Elasticsearch的服務架構(gòu)：

該架構(gòu)有以下幾個特點：

• Elasticsearch的每一個節(jié)點角色都是獨立的。我們的Master節(jié)點和Data節(jié)點不會復用，對于大規(guī)模集群也會額外增加client節(jié)點。

• Elasticsearch的版本統(tǒng)一升級到6.8以上。因為Elasticsearch在6.8版本開始提供基于角色的安全認證，這對我們的索引治理和管控來說是非常重要的，而之前我們有不少Elasticsearch是在裸奔，沒有任何的安全限制。

• 公共的IK插件?，F(xiàn)在的分詞插件目前還是使用的默認的IK插件。

• 冷熱數(shù)據(jù)分離。我們根據(jù)索引的業(yè)務場景，配置不同類型的數(shù)據(jù)節(jié)點，配合我們的索引管理策略，在低負載的時候 ( 晚上或某個時間點 )，自動調(diào)整索引的配置，讓它進行自動遷移。

02

典型應用實踐

1. ELKB簡介

在介紹我們典型的應用實踐之前，我們先再介紹ELKB。

ELKB是一套日志管理方案，它是Elasticsearch、Logstash、Kibana、Beats服務的簡稱。Elasticsearch用于存儲數(shù)據(jù)，并提供搜索和分析；Logstash用于數(shù)據(jù)收集及轉(zhuǎn)換管道，可擴展的插件；Kibana用于對存儲在Elasticsearch中的數(shù)據(jù)進行可視化展示；Beats用于多類型數(shù)據(jù)采集器。

ELKB的架構(gòu)分為三層：數(shù)據(jù)提取層、數(shù)據(jù)的存儲層、數(shù)據(jù)展示層。ELKB將數(shù)據(jù)的提取、存儲、展示做成套件，這是它比較優(yōu)勢的地方。

2. 應用實踐之一：58實時日志平臺

早期階段：

58內(nèi)部有好多套技術方案實踐，該架構(gòu)是5年前系統(tǒng)運維部同學維護的一套日志收集平臺，有兩條業(yè)務線在使用。這個版本當時比較低，它通過Logstash抓取日志，但是Logstash這塊非常消耗資源，經(jīng)常出現(xiàn)一些穩(wěn)定性的問題。

現(xiàn)在階段：

目前我們在公司主流的日志平臺主要是這種：

工作流程：

• 收集：日志收集使用大數(shù)據(jù)部門的Flume進行抓取

• 存儲：數(shù)據(jù)收集完后會存儲到公司統(tǒng)一的Kafka集群；

• 展示：我們做了日志管理平臺-飛流。另外因為Kafka存儲的數(shù)據(jù)時間有限制，我們將Kafka的數(shù)據(jù)寫入到線下的KV存儲系統(tǒng)或者一些檢索系統(tǒng)中。監(jiān)控報警系統(tǒng)可以提供一定的監(jiān)控。

改進階段：

接著也就演變到了下面這種新的日志平臺：

• 收集：在數(shù)據(jù)抓取層除了使用Flume之外，我們增加了Filebeat等套件。

• 緩存：抓取的數(shù)據(jù)仍通過公司的Kafka集群進行緩存

• 過濾轉(zhuǎn)換訂閱消費：通過Kafka之后的下游消費我們使用Logstash，因為Logstash的單節(jié)點的吞吐量有性能瓶頸，我們通過部署多套，并讓多個Logstash節(jié)點進行消費。另外一種就是hangout。hangout是攜程一個開源的類似Logstash的Kafka消費組件，它在部分場景下的吞吐量不錯

• 存儲檢索：使用Elasticsearch

• 展示：我們還自研了一些應用程序，通過Kibana直接給數(shù)據(jù)分析師、用研員提供服務。另外部分業(yè)務也依靠Elasticsearch做趨勢或者預警方面的功能監(jiān)控報警平臺，以及一些日志管理系統(tǒng)，用于滿足自己的業(yè)務需求。

3. 應用實踐之二：MySQL實時慢日志

早期業(yè)內(nèi)大家做MySQL的慢日志系統(tǒng)大都是獲取上一整天的慢日志，進行統(tǒng)一分析，然后生成上一天的慢日志報表。這種方式有一定的滯后性，如果業(yè)務調(diào)整SQL或者新發(fā)布了一個功能想看實時的性能狀況，這種需求是滿足不了的。開發(fā)人員需要看到數(shù)據(jù)庫實時的慢日志，以方便更快的進行性能診斷。我們使用ELKB技術棧來實現(xiàn)：

• 收集：采集層使用公司的agent來管理每個 MySQL 服務器節(jié)點上的Filebeat，比如實現(xiàn)對每個MySQL節(jié)點配置Filebeat，并進行初始化、啟停等管控。

• 緩存：數(shù)據(jù)收集完成后，上報匯總到公司的Kafka集群。

• 過濾：配置Logstash過濾分析節(jié)點，因為MySQL慢日志格式還是比較復雜，這里面要做一些分析過濾、切割轉(zhuǎn)換等相關操作。

• 存儲：最終統(tǒng)一存入到Elasticsearch中

• 展示：目前我們支持在58云DB平臺【內(nèi)部的私有云數(shù)據(jù)庫平臺】上直接查看。我們也可以通過Kibana提供的統(tǒng)計工具進行趨勢分析、運維報警等。

目前給開發(fā)人員提供的用戶端，通過頁面可以實時看到自己的MySQL，從收集到MySQL到展示，目前可以做到5秒以內(nèi)展示。

4. 總結(jié)

上面介紹的是58同城內(nèi)部兩個主要的應用實踐，目前數(shù)據(jù)庫團隊已經(jīng)收斂了整個公司30+套各種業(yè)務的Elasticsearch集群、300多個節(jié)點，服務器接近200臺，我們的管理維護還有不少的工作要做。

03

平臺化建設

從去年開始，我們啟動了Elasticsearch平臺化建設，一是面向用戶端提高開發(fā)接入Elasticsearch的效率，另外就是面向DBA管理端，可以對Elasticsearch集群進行高效運維及索引治理等。

58云DB平臺Elasticsearch功能架構(gòu)圖如下：

1. 用戶端

針對用戶端，我們把Elasticsearch開放給開發(fā)人員、數(shù)據(jù)運營、數(shù)據(jù)分析師等，使他們能夠?qū)lasticsearch的數(shù)據(jù)進行基本的查詢，包括數(shù)據(jù)統(tǒng)計、分析報表、 查看Elasticsearch的狀態(tài)等。

• 集群負責人可以從管理界面上看到自己名下的集群列表、Kibana地址、集群容量、操作申請等。

• 這個界面是索引申請界面。所有接入者通過標準化的方式、規(guī)范化的流程來完成需求提交。每一個索引的接入必須包括數(shù)據(jù)的保留策略、mapping、數(shù)據(jù)寫入方式等。

2. 管理端

在管理端，我們實現(xiàn)了一鍵部署Elasticsearch集群。由于Elasticsearch是分布式的，部署的線路是比較長的，它需要多節(jié)點、不同的角色，包括監(jiān)控、Logstash、Filebeat等相關的管理都是支持的。

• 從管理界面上可以看到哪個ip地址上運行著哪個集群、它的角色是什么。

• 一鍵自動化部署。

3. 索引治理

索引治理后續(xù)會做一些索引的生命周期管理，現(xiàn)在的管理我們最多的還是依賴腳本，后面索引的工作，我們希望都放到平臺上來，都要有相關的操作記錄。

• 索引的監(jiān)控

對于服務端目前使用的是 Zabbix+ Grafana的方式。我們開發(fā)了一套程序。將所有集群的監(jiān)控指標打入到其中一套Elasticsearch集群中去，然后Grafana基于Elasticsearch做了圖表的展示，再通過Zabbix進行一些系統(tǒng)的報警。

用戶端，可以通過Kibana可以看到索引index的速度、延遲等信息。

04

后續(xù)規(guī)劃

1. 版本升級

Elasticsearch 7.X，在Elasticsearch 7.X版本在性能優(yōu)化上做了很多東西，包括：查詢的相關性、對內(nèi)存的管控方面。但是它同樣存在一個問題，Elasticsearch版本不向下兼容，比如6.x版本升級到7.x版本，它的變化會比較大。

2. 集群智能診斷

集群功能越來越多，目前集群出了問題還是依賴運維人員手動發(fā)現(xiàn)。我們希望通過規(guī)則或者自動分析等手段，實現(xiàn)故障的自動化處理。

3. 私有云探索

接到Elasticsearch業(yè)務需求，我們首先要分析它的業(yè)務模型：是搜索的還是日志流水的？不同的用途對硬件的消耗差別是很大的，而服務器并不是高度的契合業(yè)務配置。在這個方面是有非常多的資源浪費，我們希望通過云模式，能夠減少資源浪費，提高資源的利用率。

05

問答環(huán)節(jié)

1. Elasticsearch數(shù)據(jù)如何與hadoop大數(shù)據(jù)平臺數(shù)據(jù)倉庫同步？

答：Hadoop或hive數(shù)據(jù)可以通過官方的相關組件，也可以通過自己寫程序進行同步。

2. Elasticsearch日志應用中，怎么定義日志格式，有些后臺日志情況復雜，比如except崩潰的，怎么處理這種后臺日志問題？

答：關于日志格式可以看下Filebeat，F(xiàn)ilebeat在收集日志的時候有多行合并功能，從Kafka到Logstash可以定義自己的過濾規(guī)則，這樣可以很容易的把問題解決掉。

3. MySQL數(shù)據(jù)如何導入到Elasticsearch，并保持實時同步？

這是一個比價大的主題，從MySQL到Elasticsearch這里考慮的規(guī)則還是比較多的。如：單表導入到單索引、多表導入到一個Elasticsearch索引、單表導入多個索引，這些都是不一樣的。業(yè)內(nèi)做MySQL到Elasticsearch的同步的方案比較多，主流的有如下幾種：

• 簡單粗暴的由業(yè)務層雙寫，即寫完MySQL之后直接寫Elasticsearch，當然這樣雙寫可能無法保證數(shù)據(jù)的一致性，有些公司對異常有補償機制：如果寫入ES失敗，先把寫失敗的數(shù)據(jù)記錄下來，通過獨立后端程序進行異常的數(shù)據(jù)修復。

• 一些開源的工具。比如阿里開源的多數(shù)據(jù)源dataX，它的設計原理是直接到MySQL中查詢數(shù)據(jù)，它高度依賴一條記錄的過期時間，大于過期時間就將數(shù)據(jù)取出來寫到Elasticsearch中去，這個實時性依賴于程序多久刷新一次，但是如果數(shù)據(jù)刪除了，是無法感知到的。

• 直接解析MySQL的binlog。阿里也有這樣的開源工具canal。它的實現(xiàn)原理就是模擬一個MySQL的從庫，它訂閱所有主庫的變更，當MySQL數(shù)據(jù)變化時，它將解析的變更可以放到Kafka中去，Kafka下游可以消費后寫入Elasticsearch，也可以不經(jīng)過Kafka直接解析出來寫入Elasticsearch。但canal也有個問題。它單節(jié)點處理能力受限。當MySQL主庫寫入稍微多一些的情況下，這時候canal解析速度跟不上，導致大量延遲，如果主庫的持續(xù)的寫入量大，canal會一直延遲，而且延遲越來越大，同時會出現(xiàn)很多問題。

4. Elasticsearch如何實現(xiàn)高效的二級索引？

答：類似于MySQL的回表查詢模式，先將所有待查詢的數(shù)據(jù)同步到Elasticsearch中，同步時帶上相關的記錄id，在Elasticsearch完成查詢后，再用這些id去相關的MySQL或HBASE進行查詢返回完整數(shù)據(jù)。

今天的分享就到這里了，謝謝大家！

嘉賓介紹：

于伯偉

58同城 | 高級架構(gòu)師

58同城數(shù)據(jù)庫部門負責人，負責為公司各業(yè)務提供高可靠、高性能的一站式數(shù)據(jù)庫服務，主要數(shù)據(jù)庫類型包括MySQL、Redis、MongoDB、TiDB和Elasticsearch等，助力與賦能業(yè)務發(fā)展，提高效率。

特別推薦一個分享架構(gòu)+算法的優(yōu)質(zhì)內(nèi)容，還沒關注的小伙伴，可以長按關注一下：

長按訂閱更多精彩▼
如有收獲，點個在看，誠摯感謝