導(dǎo)語|騰訊云Elasticsearch在騰訊會議中有哪些應(yīng)用？在大規(guī)模海量應(yīng)用場景下，騰訊云Elasticsearch在高可用和性能方面做了哪些優(yōu)化？在低成本解決方案中又有哪些獨到之處？本文是對騰訊云專家工程師張彬老師在云+社區(qū)沙龍online的分享整理，希望與大家一同交流。
一、騰訊云ES在騰訊會議中的應(yīng)用
1.騰訊會議質(zhì)量分析系統(tǒng)
騰訊會議于2019年12月底上線，兩個月內(nèi)日活突破1000萬，被廣泛應(yīng)用于疫情防控會議、遠(yuǎn)程辦公、師生遠(yuǎn)程授課等場景，為疫情期間的復(fù)工復(fù)產(chǎn)提供了重要的遠(yuǎn)程溝通工具。極速增長的會議需求，讓騰訊會議服務(wù)質(zhì)量分析系統(tǒng)經(jīng)受著巨大的考驗。
在會議中偶然會存在會議實時音視頻卡頓、音視頻不同步等會議質(zhì)量問題，造成上述問題的可能因素比較多，當(dāng)前運行的網(wǎng)絡(luò)有丟包或連接不穩(wěn)定的情況就是其中一種。
為了幫助會議質(zhì)量團(tuán)隊快速精準(zhǔn)地定位分析問題，需要大量運行時的會議質(zhì)量數(shù)據(jù)支撐，如網(wǎng)絡(luò)相關(guān)的入網(wǎng)類型、碼率、丟包率、網(wǎng)絡(luò)切換、ip切換等數(shù)據(jù)，以及客戶端相關(guān)的CPU使用率、內(nèi)存使用率、操作系統(tǒng)版本、產(chǎn)品版本等數(shù)據(jù)信息。
除了數(shù)據(jù)的實時上報，另一方面，借助多維分析，我們還可以在實時數(shù)據(jù)中挖掘出異常情況。如某個地區(qū)大面積的卡頓，某個版本出現(xiàn)特定的問題等。通過dashboard或數(shù)據(jù)報表的形式，幫助會議質(zhì)量團(tuán)隊及時掌控全局情況，快速發(fā)現(xiàn)潛在問題。
2.痛點挑戰(zhàn)
隨著疫情爆發(fā)，騰訊會議快速增長，在100天內(nèi)迭代了20多個版本，在8天內(nèi)主機數(shù)擴(kuò)容到了10w臺，這樣的急劇增長量讓騰訊會議服務(wù)質(zhì)量分析系統(tǒng)經(jīng)受高壓力，給運營團(tuán)隊及時排查用戶問題帶來了巨大的挑戰(zhàn)。
深究根本原因，是因為服務(wù)質(zhì)量分析系統(tǒng)在如此高壓力、高吞吐的場景下，寫入性能嚴(yán)重不足導(dǎo)致。騰訊會議和質(zhì)量分析系統(tǒng)研發(fā)團(tuán)隊也一起對問題做了梳理。主要表現(xiàn)在以下四個方面：
下圖展示了整個系統(tǒng)的架構(gòu)圖，紅線上面部分是原先使用的質(zhì)量分析系統(tǒng)。騰訊會議的質(zhì)量數(shù)據(jù)，由上報接口機采集后到我們自研的接入服務(wù)，做數(shù)據(jù)清洗或轉(zhuǎn)換的ETL過程，最后把數(shù)據(jù)寫入到自研的lucene數(shù)據(jù)存儲引擎里，提供數(shù)據(jù)查詢和分析能力。
系統(tǒng)架構(gòu)圖
（1）可用性
原來的系統(tǒng)可能會遇到很多問題，首先在可用性方面，原來自研的lucene引擎是用Java寫的，內(nèi)存使用過多就會OOM，導(dǎo)致節(jié)點掛掉，進(jìn)而造成集群的雪崩。這樣SLA就難以保障，達(dá)不到4個9的要求，質(zhì)量團(tuán)隊經(jīng)常面臨系統(tǒng)崩潰之后用戶問題得不到及時跟進(jìn)和解決的困擾。
（2）性能
第二個問題在于性能。疫情爆發(fā)之后，峰值系統(tǒng)寫入量接近300w/s，這個量是非常大的。由此造成了系統(tǒng)數(shù)據(jù)同步延遲比較高，大量數(shù)據(jù)堆積在里面長時間得不到消費。比如我們在前端查詢用戶的一些實時質(zhì)量問題的時候，發(fā)現(xiàn)時延經(jīng)常在半小時以上，這肯定無法達(dá)到我們的質(zhì)量要求。
（3）拓展性
在出現(xiàn)如上問題的時候，大家通常做法可能就是去擴(kuò)容。由于系統(tǒng)最關(guān)鍵的部分，是一個基于lucene自研的搜索引擎，擴(kuò)容能力比較差，依賴于研發(fā)團(tuán)隊針對業(yè)務(wù)的優(yōu)化。在數(shù)據(jù)量暴漲的背景下，不能進(jìn)行快速擴(kuò)容以滿足需求。
（4）易用性
另外，在新系統(tǒng)選型切換的過程中，我們也要考慮易用性。用戶數(shù)暴增，留給系統(tǒng)驗證切換的時間非常短，這要求我們必須使用一種簡單快速的解決方案。需要在一周之內(nèi)輸出適用方案，并進(jìn)行線上數(shù)據(jù)的切換。
由于時間緊迫，新的方案需要盡量保留原有架構(gòu)的大部分基礎(chǔ)設(shè)施，并做盡量少的代碼開發(fā)改動。
經(jīng)過討論，最終決定把原來這套架構(gòu)切換成Elasticsearch比較經(jīng)典的ELK架構(gòu)。通過logstash的易用性和強大的生態(tài)插件，可以快速替代原有的自研數(shù)據(jù)接入組件，進(jìn)行數(shù)據(jù)的清洗轉(zhuǎn)換等ETL過程。如原有架構(gòu)中使用的kafka，在logstash中就已經(jīng)包含了相應(yīng)的input插件。并且有大量數(shù)據(jù)格式的解析插件支持，對于數(shù)據(jù)的一些解析、過濾、清洗等操作可以直接在logstash的pipeline中進(jìn)行簡單的配置即可，基本上是0開發(fā)量。
豐富的各語言SDK，方便快速的對服務(wù)質(zhì)量分析平臺前后臺進(jìn)行快速切換，實際從代碼修改到上線完成只用了一天的時間。
二、高可用及性能方向的優(yōu)化
1.高并發(fā)請求
騰訊會議服務(wù)質(zhì)量分析系統(tǒng)，從2月份進(jìn)行ES架構(gòu)的方案切換開始，寫入吞吐從5w/s不斷攀升，現(xiàn)已達(dá)到100w+/s。
業(yè)務(wù)的突發(fā)增長有時候來的很突然，并不能在前期做有效的評估。社區(qū)中的很多用戶也遇到過類似的問題，由于沒有預(yù)估到業(yè)務(wù)突發(fā)的增長，并且在業(yè)務(wù)層沒有做好服務(wù)降級等機制，導(dǎo)致突發(fā)的寫入查詢流量打崩了整個集群。
例如早期我們內(nèi)部一個日志集群，寫入量一天突增5倍，集群多個節(jié)點Old GC卡住脫離集群，集群RED，寫入停止，給我們帶來了不小的麻煩。
我們對掛掉的節(jié)點做了內(nèi)存分析，發(fā)現(xiàn)大部分內(nèi)存是被反序列化前后的寫入請求占用。我們對
掛掉集群的內(nèi)存鏡像做了一些梳理，發(fā)現(xiàn)大量的寫入請求其實都是用在反序列化這里，耗內(nèi)存比較多。
上圖展示了ES high level的寫入流程，用戶的寫入請求先到達(dá)其中一個數(shù)據(jù)節(jié)點，我們稱之為數(shù)據(jù)節(jié)點。然后由該協(xié)調(diào)節(jié)點將請求轉(zhuǎn)發(fā)給主分片所在節(jié)點進(jìn)行寫入，主分片寫入完畢再由主分片轉(zhuǎn)發(fā)給從分片寫入，最后返回給客戶端寫入結(jié)果。
右邊是更細(xì)節(jié)的寫入流程，而我們從堆棧中看到的寫入請求堆積的位置就是在紅色框中的接入層，節(jié)點掛掉的根因是協(xié)調(diào)節(jié)點的接入層內(nèi)存被打爆。
針對這種高并發(fā)場景，我們的優(yōu)化方案是服務(wù)限流。除了要能控制并發(fā)請求數(shù)量，還要能精準(zhǔn)地控制內(nèi)存資源，因為內(nèi)存資源不足是主要的矛盾。另外通用性要強，能作用于各個層級實現(xiàn)全鏈限流。
在很多數(shù)據(jù)庫使用場景，會采用從業(yè)務(wù)端或者獨立的proxy層配置相關(guān)的業(yè)務(wù)規(guī)則的限流方案，通過資源預(yù)估等方式進(jìn)行限流。這種方式適應(yīng)能力弱，運維成本高，而且業(yè)務(wù)端很難準(zhǔn)確預(yù)估資源消耗。
ES原生版本本身有限流策略，是基于請求數(shù)的漏桶策略，通過隊列加線程池的方式實現(xiàn)。線程池大小決定了處理并發(fā)度，處理不完放到隊列，隊列放不下則拒絕請求。但是單純地基于請求數(shù)的限流不能控制資源使用量，而且只作用于分片級子請求的傳輸層，對于我們前面分析的接入層無法起到有效的保護(hù)作用。原生版本也有內(nèi)存熔斷策略，但是在協(xié)調(diào)節(jié)點接入層并沒有做限制。
我們的優(yōu)化方案是基于內(nèi)存資源的漏桶策略。我們將節(jié)點JVM內(nèi)存作為漏桶的資源，當(dāng)內(nèi)存資源足夠的時候，請求可以正常處理；當(dāng)內(nèi)存使用量到達(dá)一定閾值的時候分區(qū)間階梯式平滑限流。例如上圖中淺黃色的區(qū)間限制寫入，深黃色的區(qū)間限制查詢，底部紅色部分作為預(yù)留buffer，預(yù)留給處理中的請求、merge等操作，以保證節(jié)點內(nèi)存的安全性。
2.大聚合查詢
對于大聚合的場景，因為系統(tǒng)收攏進(jìn)來的數(shù)據(jù)也是有價值的，我們也會經(jīng)常在上面做一些分析和查詢，比如做騰訊會議在全世界各個地區(qū)會議質(zhì)量情況的展示等。在這樣聚合的過程當(dāng)中，有的指標(biāo)它的分桶數(shù)量是比較多的，可能出現(xiàn)上萬甚至十萬、百萬級別。
結(jié)合整個查詢流程會發(fā)現(xiàn)，在協(xié)調(diào)節(jié)點內(nèi)會把數(shù)據(jù)節(jié)點匯聚到的分析數(shù)據(jù)再做一次二次匯聚，對分桶分析過濾，包括做一些排序等，在分桶數(shù)量比較多的情況下，協(xié)調(diào)節(jié)點的內(nèi)存使用壓力是比較大的，當(dāng)一個比較大的查詢過來時，這個節(jié)點可能就會掛掉。
原生ES對查詢方面的限制也是比較死的，限制最大返回結(jié)果桶數(shù)，默認(rèn)是一萬，如果超過這個限制則直接拒絕。但分析場景結(jié)果桶數(shù)十萬、百萬是常態(tài)，默認(rèn)1萬是不夠的。另外這個值也是很難精確設(shè)置的，調(diào)整不靈活，大了內(nèi)存會崩掉，小了滿足不了業(yè)務(wù)需求，所以我們也要對它進(jìn)行優(yōu)化。
第一階段我們根據(jù)當(dāng)前JVM的內(nèi)存使用情況做查詢的預(yù)估，通過內(nèi)存膨脹系數(shù)預(yù)估在反序列過程當(dāng)中所要消耗的內(nèi)存數(shù)量，一旦超過閾值則直接熔斷。
第二階段，reduce過程中流式檢查桶數(shù)，每增加固定數(shù)量的桶就檢查一次內(nèi)存，如果發(fā)現(xiàn)超限則直接熔斷。比如總量一萬桶，每新增1024個桶就需要再檢查一次內(nèi)存，如果超過限制，就直接把這個比較大的聚合查詢殺掉。
雖然殺掉當(dāng)前這個大查詢可能會犧牲一定的用戶體驗，但卻能保證整個集群的穩(wěn)定性。我們的這項優(yōu)化也已經(jīng)提交給ES官方社區(qū)，并且已經(jīng)在7.7.0這個版本發(fā)布了。
3.多可用區(qū)部署
在更基礎(chǔ)的場景下，比如我們的機器、集群，甚至整個機房掛掉，這種情況下的可用性光靠優(yōu)化是難以徹底解決的。所以為了達(dá)到某些客戶，比如電商或者金融客戶對關(guān)鍵業(yè)務(wù)的可用性要求，騰訊云ES提供了集群的多可用區(qū)部署方案。
一個集群可以選擇在兩個或三個可用區(qū)上部署，這樣的話每個節(jié)點都能被標(biāo)記可用性屬性，當(dāng)我們開啟分片分配可用區(qū)的感知之后，一個索引多個分片的副本可以平均分配到各可用區(qū)，這樣就能保證一個可用區(qū)掛掉以后不影響整個集群的數(shù)據(jù)完整性，可以穩(wěn)定給業(yè)務(wù)提供寫入讀取的能力。并且切換是透明的，業(yè)務(wù)方面無感知。
4.合并策略
在性能方面的優(yōu)化，首先在數(shù)據(jù)合并方面。ES的底層Lucene基于LSM Tree的數(shù)據(jù)文件。合并策略業(yè)內(nèi)有幾種典型方案，比如按時間序進(jìn)行合并，比如把當(dāng)前一小時內(nèi)的數(shù)據(jù)進(jìn)行合并，典型產(chǎn)品有Cassandra、HBase等。但是它只適合時序場景，而且因為每個小時數(shù)據(jù)寫入量不太一樣，導(dǎo)致文件合并的大小不太一致，會影響合并的效率。
另外一些產(chǎn)品如LevenIDB、RocksDB選擇的是分層合并，優(yōu)點是查詢高效，但是寫放大較嚴(yán)重，影響TPS。
所以我們在原生方案基礎(chǔ)上，同時調(diào)研了大量開源社區(qū)的方案做了新的優(yōu)化。因為文件之間按創(chuàng)建時間來看是有序的，這里可以取個巧，并不需要真的關(guān)注文件的創(chuàng)建時間，而只需要關(guān)注這個文件的時間序就行。
在L0層我們會通過文件的創(chuàng)建時間對文件進(jìn)行排序。在分層合并的時候，再按目標(biāo)文件大小進(jìn)行合并，比如在L1層設(shè)置文件大小是20M，每攢20個小文件就做一次合并，這樣既保證了數(shù)據(jù)的連續(xù)性，又將文件數(shù)量得到了收斂，最終提升了寫入場景查詢性能。
我們根據(jù)目標(biāo)文件大小這個維度進(jìn)行合并，可能會漏掉一些比較小的文件。不過沒關(guān)系，因為我們后面還做了一個冷分片的持續(xù)合并，有一些小的分片因為長期沒有寫入，始終達(dá)不到合并目標(biāo)的要求，這時會有一個冷分片的持續(xù)合并策略，發(fā)現(xiàn)有一些小的分片超過五分鐘沒有被更新，就會強制觸發(fā)它向上合并。
5.大吞吐寫入
第二個性能方面的優(yōu)化是在大吞吐寫入方面，以騰訊某金融業(yè)務(wù)的人群畫像分析系統(tǒng)為例，這個系統(tǒng)每天晚上執(zhí)行一次全鏈導(dǎo)入任務(wù)，在白天只有小批量的更新。對于一些體量比較大的客戶，每天晚上全量導(dǎo)入數(shù)據(jù)量是非常大的，甚至高達(dá)十幾億，并且需要在夜間那幾個小時導(dǎo)入完成，因為第二天就會對這些數(shù)據(jù)進(jìn)行量化分析了。
在使用過程中，業(yè)務(wù)部門經(jīng)常會發(fā)現(xiàn)寫入性能不高，且CPU使用率不穩(wěn)定的問題，資源利用率嚴(yán)重不足。
騰訊云ES內(nèi)核團(tuán)隊對類似的高壓力寫入場景進(jìn)行了追蹤及分析，并在同樣的場景下進(jìn)行了多個方案的壓力測試，發(fā)現(xiàn)ES單節(jié)點的壓力寫入測試與lucene基準(zhǔn)的寫壓力測試有較大的差距：如果這個數(shù)據(jù)不通過ES而是直接通過Lucene寫入，性能會提升一倍。
所以我們就對騰訊云ES的各種寫入流程做了一個分析，發(fā)現(xiàn)Lucene寫入就是單純地寫入數(shù)據(jù)，但ES是一個分布式的系統(tǒng)，為了防止內(nèi)存里面的數(shù)據(jù)沒有及時刷盤，我們會寫一個translog，對應(yīng)數(shù)據(jù)庫里面的binlog機制。
因為不可能在一個文件上面一直持續(xù)寫，就需要對大量的文件做管理，因為很多已經(jīng)刷盤的數(shù)據(jù)是不需要保留的，所以會有一些輪轉(zhuǎn)的機制。我們會不斷地去生成新的文件，然后不斷地淘汰小的文件。
在這里面就出現(xiàn)了一個問題：因為ES一個節(jié)點的寫入是并發(fā)的，可能有很多寫入的限制都在持續(xù)地對同一個數(shù)據(jù)文件做寫入，但是當(dāng)前文件只允許一個線程進(jìn)入臨界區(qū)，所以這個鎖的同步效率是非常低的，因為不管有多少個寫入限制，一旦到了切換的時候這個鎖會把所有的寫入限制都鎖住。
所以這里我們也做了兩套優(yōu)化的方案。第一種方案，我們首先想到了把rollGeneration做成異步的，兩個流程互相不影響，但是改造量是比較大的。通過社區(qū)討論，我們最終確立了一個非常精簡的方案，就是每次rollGeneration前做一次刷盤，后面每次寫入的時候不需要都去做這個鎖的同步。這個方案對流程的改造最輕量優(yōu)雅，且優(yōu)化后的寫入性能提高了20%以上。
這部分優(yōu)化的代碼經(jīng)騰訊內(nèi)部的業(yè)務(wù)驗證后，最終整理提交回饋給了社區(qū)。由于這個優(yōu)化在ES寫入的所有場景下均適用，且對性能的提升非常顯著，Elastic的創(chuàng)始人對該PR高度贊揚，并給騰訊云總裁發(fā)來了公開感謝信。
騰訊云ES在社區(qū)開源的內(nèi)核之上，根據(jù)云上的內(nèi)外部業(yè)務(wù)的場景案例積累，做了大量的內(nèi)核優(yōu)化。除了上面介紹的translog的優(yōu)化，還有帶“_id”的寫入操作剪枝優(yōu)化、查詢計劃優(yōu)化等等，滿足了客戶在性能方面的需要，并積極將一些通用的優(yōu)化提交至社區(qū)，截至目前為止，騰訊云提交的pr約有50+被合并到了主干。
三、低成本解決方案上的優(yōu)化
1.存儲成本優(yōu)化
騰訊云自身的監(jiān)控系統(tǒng)也是基于ES來做的，特別對于一些大的地域的集群，它的寫入速度甚至達(dá)到了千萬級每秒。面對這樣的吞吐量，并且數(shù)據(jù)量至少要保留半年時間的可空查詢，預(yù)估整個集群大概需要能承載14PB的數(shù)據(jù)，按照我們內(nèi)部用的物理機磁盤的規(guī)格，需要1500臺物理機，遠(yuǎn)遠(yuǎn)超出成本預(yù)算。
我們對監(jiān)控系統(tǒng)的業(yè)務(wù)日志做了分析，發(fā)現(xiàn)這類數(shù)據(jù)都是有時序性的，隨著時間的推移它的訪問頻率越來越低。
（1）冷熱分離
所以我們首先給用戶推出的解決方案就是冷熱分離，在一個集群里我們會給用戶提供兩種不同屬性的機型，用戶新寫入的數(shù)據(jù)，或者近期頻繁訪問的數(shù)據(jù)可以寫入到高配置、高IO的機型，比如64核甚至更高核數(shù)，帶云盤或者本地盤的機型，可以保證一天之內(nèi)或者幾個小時之內(nèi)這種熱數(shù)據(jù)的寫入性能。
對于一天以后甚至一周以后才訪問的冷數(shù)據(jù)，可以寫入到低配置的機型，比如12核甚至4核的機型以降低成本。
（2）生命周期管理
原生ES提供了生命周期管理功能，把數(shù)據(jù)分為3個階段：Hot phrase、Warm phrase、Cold phrase，在每個階段都可以對數(shù)據(jù)做管理，比如熱階段可以按天、小時或者我們自己設(shè)置的大小來分索引。
大多數(shù)查詢或者分析都是按小時、天，而在Warm階段我們可以按秒級采集數(shù)據(jù)，通過降低數(shù)據(jù)的精度，極大減少數(shù)據(jù)的總量，并且提升數(shù)據(jù)查詢的效率。
在冷階段很多數(shù)據(jù)可能是作為備份，幾乎很少被查詢，我們可以關(guān)閉一些索引，或者做一些數(shù)據(jù)的備份，甚至如果數(shù)據(jù)沒有必要還可以刪掉。
（3）多盤策略
在存儲方面，現(xiàn)在包括騰訊云在內(nèi)的很多云廠商為用戶提供的主要還是CBS云盤，但是CBS云盤在單盤IO能力上有限制，最大不超過260M/S，所以我們?yōu)榭蛻籼峁┝硕啾P策略。
原來一個節(jié)點只能帶一塊硬盤，現(xiàn)在一個節(jié)點可以掛多塊盤，這樣的話一方面能突破CBS IO能力限制，原來單盤的260MB/S，通過掛4~5塊盤將能力擴(kuò)充數(shù)倍。另外單節(jié)點的IO提升之后我們就不需要那么多的節(jié)點，能夠節(jié)約大量成本。
（4）COS冷備
ES的索引數(shù)據(jù)每個上面其實分了很多的小文件，所以我們做了一個COS上傳下載的插件，可以在控制臺自動觸發(fā)或者在ILM配置觸發(fā)，把這些底層數(shù)據(jù)文件直接備份到成本非常低的COS上。如果真的某一天系統(tǒng)數(shù)據(jù)出現(xiàn)了問題，也可以很方便恢復(fù)過來。
以上就是我們在存儲成本上的優(yōu)化，騰訊云監(jiān)控的集群優(yōu)化之后只需要兩三百臺機器就可以扛住原來1500臺機器做的事情，極大降低了我們的成本。
2.計算成本優(yōu)化
其次是計算成本上的優(yōu)化，主要是在內(nèi)存使用率方面。其實我們磁盤使用率并不高，只有30%~40%，但是我們的堆內(nèi)存使用率長期處于70%-80%，甚至有時候達(dá)到90%這一比較危險的狀態(tài)。
原因主要在于索引里面的FST占用了大量內(nèi)存，基本維持在50%-70%，而且需要常駐內(nèi)存不能釋放。計算發(fā)現(xiàn)，大概每10TP的磁盤就需要10G-15G來存FST緩存。
ES社區(qū)對于這個問題也有一些優(yōu)化方案，比如因為FST對內(nèi)存占用比較多，類似很多這種大數(shù)據(jù)的組件就把它移到堆外，這里的優(yōu)化方案其實很簡單，就是通過系統(tǒng)MMmap的方式，通過linux操作系統(tǒng)數(shù)據(jù)頁的淘汰，如果長時間沒有訪問就淘汰出去。
這種方案優(yōu)點是實現(xiàn)簡單，但是這種淘汰策略比較粗糙，對于一些海量數(shù)據(jù)場景，可能一個查詢過來，原來那些在Cache里面的數(shù)據(jù)就被淘汰掉了，又要重新?lián)Q一批，而實際上淘汰的那批數(shù)據(jù)可能是經(jīng)常要使用的。
所以，我們也對原生方案做了一些優(yōu)化，做了兩層的Cache，借助堆外內(nèi)存，釋放堆內(nèi)存。在GC之前不會過快的釋放，在堆外我們也不推薦通過操作系統(tǒng)方式進(jìn)行管理，因為畢竟控制的粒度比較粗，我們會通過一些LRU或者LFU的策略，加上通過Cache的訪問頻次進(jìn)行一些淘汰。
四、未來展望
未來在可用性方面，我們會加強智能診斷的功能，因為ES在很多方面都需要用戶來操心。比如索引設(shè)置不太好，可能會導(dǎo)致并發(fā)性能不高等等。對于ES使用不是特別熟的用戶可能會有這樣的苦惱，感覺集群經(jīng)常莫名其妙會出現(xiàn)一些問題，當(dāng)然也可能是自己使用上沒有注意。
通過智能診斷功能，它能持續(xù)不斷幫助用戶去做使用方面的監(jiān)控，比如索引方面分配的策略等，給客戶做一些預(yù)先的提醒和預(yù)警，在業(yè)務(wù)受到影響之前，把這個問題扼殺在萌芽之中。
另外我們也會提供節(jié)點自愈的能力。在性能方面我們會著重于擴(kuò)展多維分析的能力，因為現(xiàn)在多維分析的場景在ES里應(yīng)用也比較多，包括前文提到的騰訊會議質(zhì)量數(shù)據(jù)的這種多維分析，騰訊云一些金融業(yè)務(wù)的畫像分析等等。
成本方面，基于前文提到的備份策略，我們原來備份到COS上面的數(shù)據(jù)其實就是一份冷數(shù)據(jù)，寫入不了也查詢不了，萬一哪天我們真的有這樣的查詢需求，還需要把它重新恢復(fù)到集群上面，比較麻煩。
所以我們后面會和社區(qū)一起完善推出一種可搜索的備份，我們可以容忍這種搜索的延時，比如一分鐘甚至五分鐘才把結(jié)果返回，但是數(shù)據(jù)仍是可以放到COS上，從而節(jié)省大量的成本開支。
我們會比較快推出存儲資源分配的功能，相當(dāng)于節(jié)點是可以無限擴(kuò)充，這樣對于某一些經(jīng)常做活動的用戶，活動期間流量非常大，需要瞬間擴(kuò)容節(jié)點來扛住這樣比較大的查詢請求。當(dāng)做完活動之后很多節(jié)點沒有用了，可以把它縮掉，但是數(shù)據(jù)仍然保留，所以這種存儲計算分離的成本優(yōu)化對于這一類用戶是非常需要的。
另外我們會完善數(shù)據(jù)集成的通道，會支持很多導(dǎo)入導(dǎo)出、數(shù)據(jù)遷徙的插件，我們計劃在Q3把它引入到騰訊云，作為一個子產(chǎn)品提供給用戶這個功能。在2020年Q4我們也會結(jié)合騰訊云數(shù)據(jù)庫DBS、Kafka組件做這種數(shù)據(jù)通道，讓用戶通過控制臺的簡單配置就可以把數(shù)據(jù)接入進(jìn)來。其實ES和大數(shù)據(jù)的組件是可以做一些天然融合的，后面我們也會更多的在大數(shù)據(jù)平臺上做一些融合化的研究和演進(jìn)。
Q&A;
Q：1000 w/s的索引有幾個節(jié)點？
A：上文提到的騰訊云監(jiān)控系統(tǒng)，會有千萬級每秒的高壓力寫入場景。經(jīng)過優(yōu)化了之后，只需要兩三百個節(jié)點左右就能扛住壓力。
Q：ILM可以針對索引么？
A：ILM是索引生命周期管理，其實就是針對索引的。前文提到成本優(yōu)化的時候，我們發(fā)現(xiàn)數(shù)據(jù)有時間上冷熱的屬性，在數(shù)據(jù)熱階段我們可以通過ILM做索引的切分管理，比如一天切一個索引，或者按數(shù)據(jù)量1G切一個索引等等，其它如溫場景、冷場景也可以針對索引維度做逐級的數(shù)據(jù)壓縮、刪除、備份等操作。
Q：COS冷備份能再詳細(xì)展開嗎？
A：關(guān)于這一塊，我推薦大家去閱讀騰訊云ES官網(wǎng)上的文檔，上面有比較詳細(xì)的解釋，包括API在ES里面的COS冷備，API怎么使用，倉庫怎么建立等等。會有ES相關(guān)文檔給出比較詳細(xì)的介紹，大家可以通過我們提供的免費集群實際操作一下。它的成本是比較低的，效率也比較高，使用起來也方便，大概兩三條API就可以搞定。另外前文提到的ILM功能也支持COS冷備，直接可以在ILM上進(jìn)行設(shè)置。
Q：一個ES集群最大節(jié)點數(shù)能到多少，會有瓶頸么？
A：目前不推薦用戶超過一千個節(jié)點。在一個集群中存在過多的節(jié)點，因每個節(jié)點都會需要和其他節(jié)點進(jìn)行通信及保持心跳，節(jié)點規(guī)模持續(xù)的擴(kuò)大會造成很多問題，建議利用業(yè)務(wù)做拆分
Q：第三方ES如何遷移至騰訊云ES?
A：有很多方案，比較簡單可以通過COS，COS不僅可以做冷備，也可以做數(shù)據(jù)遷移。因為我們的COS插件是開源，可以下載一個到自建的ES系統(tǒng)上，把你的數(shù)據(jù)全量或者增量備份到COS上面，再把它恢復(fù)到騰訊云ES上是比較快的。另外在架構(gòu)設(shè)計層面也會有一些不停服遷移方案，也可以咨詢一下你的架構(gòu)師。
Q：堆外內(nèi)存是怎么用MMmap方式做的，騰訊云這里是直接改了Lucene了嗎？
A：我們在內(nèi)核方面做了大量的修改，有一部分是對ES的修改，另外大量的底層數(shù)據(jù)存儲設(shè)計更多是對Lucene的修改，這些修改基本上都已經(jīng)回饋給社區(qū)。
Q：ELK日志延遲過大，是如何追平的？
A：前文提到的騰訊會議延遲過大主要就在于寫入性能比較慢，所以一直追不上。我們?nèi)胧值狞c也是提升集群的寫入能力，一方面我們做了一些擴(kuò)容類的工作，另外在拷貝方面也做了大量寫入查詢優(yōu)化，最后推薦大家盡量使用最新版本，比如騰訊云支持的7.5.1版本，或者官方的7.7版本，最新版本有大量的寫入查詢優(yōu)化。
Q：集群的服務(wù)器參數(shù)，是要定制化調(diào)試么，有成型的解決方案么？
A：這個問題很好，對于服務(wù)器我們需要做很多操作系統(tǒng)上的調(diào)節(jié)，我們的ES服務(wù)器上也做了大量偏向于ES應(yīng)用的調(diào)用，我們云+社區(qū)專欄也有一篇文章叫做ES調(diào)用實踐，感興趣的同學(xué)可以搜索了解一下。對這些參數(shù)的調(diào)試?yán)斫馄饋砜赡軙幸恍┘夹g(shù)難度，并且在運維起來如果有一些參數(shù)忘了就會對性能產(chǎn)生影響，所以如果有興趣可以去云+社區(qū)的ES專欄或者去社區(qū)看相關(guān)的一些文章。另外如果不想調(diào)試的話可以直接使用一些成熟的云產(chǎn)品。
騰訊云
專欄
閩公網(wǎng)安備 35010202001226號
