廊坊新聞網-主流媒體,廊坊城市門戶

    每日快看:[萬字長文]天機閣1.0百億級實時計算系統(tǒng)性能優(yōu)化

    2023-03-17 04:17:32 來源:騰訊云

    隨著業(yè)務的發(fā)展,系統(tǒng)日益復雜,功能愈發(fā)強大,用戶數量級不斷增多,設備cpu、io、帶寬、成本逐漸增加,當發(fā)展到某個量級時,這些因素會導致系統(tǒng)變得臃腫不堪,服務質量難以保障,系統(tǒng)穩(wěn)定性變差,耗費相當的人力成本和服務器資源。這就要求我們:要有勇氣和自信重構服務,提供更先進更優(yōu)秀的系統(tǒng)。--導讀

    前言

    自今年三月份以來天機閣用戶數快速上漲,業(yè)務總體接入數達到1000+,數據進入量更是迎來了爆發(fā)式上漲,日均處理量上漲了一個數量級:Trace數據峰值處理量達到340億/日條,Log日志數據峰值處理量級達到140億/日條。面對海量數據,老的實時計算系統(tǒng)處理壓力逐漸增加,底層存儲系統(tǒng)無論在磁盤、IO、CPU、還是索引上都面臨巨大的壓力,計算集群資源利用率不高,系統(tǒng)的調整優(yōu)化迫在眉睫。

    業(yè)務接入量:同比日均處理量級:

    1.什么是天機閣

    在傳統(tǒng)單機系統(tǒng)的使用過程中,如果某個請求響應過慢或是出錯,開發(fā)人員可以通過查看日志快速定位到具體服務。而隨著業(yè)務的越來越復雜,架構由單體逐漸演變?yōu)槲⒎占軜嫛L貏e是隨著容器, Serverless等技術的廣泛應用,它將龐大的單體應用拆分成多個子系統(tǒng)和公共的組件單元。這一理念帶來了許多好處:復雜系統(tǒng)的拆分簡化與隔離、公共模塊的重用性提升與更合理的資源分配、大大提升了系統(tǒng)變更迭代的速度以及可擴展性。但反之,業(yè)務架構也隨之變的越來越復雜,一個看似簡單的業(yè)務后臺可能有幾百甚至幾千個服務在支撐,當接口出現問題時,開發(fā)人員很難及時從錯綜復雜的服務調用中找到問題的根源,從而錯失了止損的黃金時機,排查問題的過程也需要耗費大量的時間和人力成本。為了應對這一問題,業(yè)界誕生了許多優(yōu)秀的面向Devops的診斷分析系統(tǒng),包括Logging、Metric、Tracing。三者關系如圖所示:

    此圖來源自網絡


    (相關資料圖)

    Tracing:一系列span組成的樹狀結構。每個span包含一次rpc請求的所有信息。從用戶發(fā)出請求到收到回包,就是通過trace來串聯(lián)整條鏈路。Metric:指標數據。是對可觀測性指標的一種度量,例如請求數、qps峰值、函數調用次數、成功率、異常率、接口返回碼分布等信息,可用作統(tǒng)計聚合。Logging:業(yè)務日志。

    三者互相重疊,又各自專注于自己的領域,將三者結合起來就可以快速定位問題。而已知的業(yè)界優(yōu)秀開源組件有諸如:

    Metric: Zabbix、Nagios、Prometheus、InfluxDB、OpenCenusLogging: ELK、Splunk、Loki、LogglyTreace: jeager、Zipkin、SkyWalking、OpenTracing

    隨著時間的推移可能會集成更多的功能,但同時也不斷地集成其他領域的特性到系統(tǒng)中來。而天機閣正是集三位于一體的分布式鏈路追蹤系統(tǒng),提供了海量服務下的鏈路追蹤、故障定位、架構梳理、容量評等能力。

    2 系統(tǒng)架構

    從數據流轉角度來看,天機閣整體可以分為數據生產與消費鏈路,其中數據生產鏈路主要包括數據接入層、數據處理層、數據存儲層。整體如下圖所示。

    數據接入層:主要負責數據采集工作,天機閣支持Http+Json、Http+Proto、Grpc等多種數據上報方式,業(yè)務可以采用對應語言的SDK進行數據上報。根據業(yè)務上報環(huán)境,可選擇Kafka、蟲洞等多種數據接入方式,為減少數據傳輸耗時,提升系統(tǒng)的容錯能力,天機閣提供了上海、廣州、深圳等多個不同區(qū)域的接入通道,數據接入時會根據Idc機器所在區(qū)域自動進行“就近接入”。數據處理層:基于Flink構建的天機閣流式計算平臺。主要處理三部分數據:第一部分是Metric模調數據的計算工作,結果同步至Druid。第二部分是日志數據,基于DataStream模式對數據進行實時消費,同步至ES日志集群。第三部分是Trace數據,基于KeyedStream的分組轉換模式,根據業(yè)務Traceid進行數據分區(qū),將一條Stream流劃分為邏輯上不相交的分組,把相同Traceid的數據實時匯聚到同一個窗口,再對數據進行統(tǒng)計聚合,生成拓撲圖、調用鏈、調用樹等數據模型,結果同步至Hbase與ES。數據存儲層:ES主要用于用于建立熱門Trace的倒排索引以及存儲日志數據,Harbo/Druid系統(tǒng)用于存儲模調數,Hbase用于存儲調用鏈,拓撲圖,關系鏈等數據。

    3 問題回顧

    在海量流量的沖擊下,日志集群與Metric集群一直比較穩(wěn)定,處理耗時基本在秒級。影響較大的是Trace集群,Trace集群主要通過滾動窗口接收一個Trace請求的所有RPC 的Span信息。由于業(yè)務接入量的上漲以及不少業(yè)務的放量,Trace集群的日均處理量由3月份的40億/day爆發(fā)式上漲到340億/day,且集群還要經常面臨業(yè)務熱點push、錯誤埋點等場景的挑戰(zhàn)。這些問題直接導致數據實時性開始下降,期間經常收到用戶反饋數據延時大數據丟失的問題。而系統(tǒng)層面,則頻繁出現集群抖動、延時飆升、Checkpoint失敗等現象。同時存儲也面臨巨大的寫入壓力:Hbase與ES均出現寫入延時上漲、毛刺的現象,而這些因素最終導致計算集群的處理性能變弱,穩(wěn)定性下降。產生消費滯后,數據堆積的問題。具體有如下四個表象:

    集群抖動:集群毛刺、抖動情況增多,系統(tǒng)處理性能變弱,上游Kafka通道出現大量數據堆積情況,系統(tǒng)處理延時上升資源傾斜:Flink算子反壓嚴重,部分節(jié)點出現CPU過載的情況,且各算子的Checkpoint時間變長頻繁失敗存儲抖動:Hbase寫入延時上漲,高峰期寫入延時上漲到1300ms左右,寫ES平均延時上漲到2000ms,早上8~10點出現大面積寫入ES被拒絕的現象,最終會導致上游集群掛掉系統(tǒng)異常:某些時間點出現系統(tǒng)異常,同時集群處理延時飆升

    本著先抗住再優(yōu)化的思想,當出現上述問題時,為保證系統(tǒng)的可用性,我們會采取各種快速恢復策略,諸如計算資源擴容、數據降級、關閉數據可靠性等策略來提升集群的處理性能,達到快速恢復的目的。但這些策略都治標不治本,性能問題周而復始的出現。這不但浪費了大量計算集群資源,集群處理性能,吞吐,穩(wěn)定性都沒有實質上的提升。

    4 問題分析

    針對上述四種現象,結合業(yè)務分別從接入層、存儲層、計算層對系統(tǒng)進行了全面分析,找出了目前Trace系統(tǒng)存在的問題以及瓶頸,并制定了對應的優(yōu)化方案

    圖4.1: Trace系統(tǒng)架構圖

    如上圖所示,一次RPC的請求和回包最終會合并成一個Span,而每個Span包含Traceid、Spanid,以及本次RPC調用涉及的主被調服務信息。在接入層進行數據采樣上報時,會將相同Traceid的Span集合路由的到同一個數據通道中,而計算層會對不同通道的數據做隔離,不同通道采用不同的計算任務對數據進行處理。大致流程如下:首先根據Traceid高位字節(jié)進行Reducekeby,確保同一個RPC請求的數據能路由到同一個窗口,再通過窗口函數對同一個請求的數據集合進行聚合計算,實時生成拓撲圖,調用鏈等數據模型,批量寫入ES和Hbase等列式存儲。在業(yè)務量少,集群相對穩(wěn)定的情況下,Trace集群平均處理時長在20-40s左右,即從一次Trace數據的上報到可展示的過程大概要經過半分鐘。當系統(tǒng)不穩(wěn)定或者處理性能下降時,數據延時會上漲至小時甚至級別,而主要導致系統(tǒng)不穩(wěn)定的因素有兩種:一是數據量的上漲給存儲系統(tǒng)帶來了較大的攝入壓力,底層數據的刷盤時間越來越長。二是系統(tǒng)經常要面臨業(yè)務方錯誤埋點或熱點Push產生的熱key、臟數據等場景的考驗。具體表現為:

    底層存儲數據攝入能力下降: Hbase寫入耗時達到1300ms ES寫入耗時達到2000ms。熱key造成集群資源傾斜導致集群產生毛刺、吞吐量下降等問題 。臟數據、代碼bug造成服務異常,導致集群毛刺增多。集群缺乏容錯能力,過載保護能力 。

    天機閣既是一個寫密集型系統(tǒng),也是一個時延敏感型系統(tǒng),對數據的實時性有比較高的要求。系統(tǒng)的不穩(wěn)定會導致消息通道大量數據堆積,數據實時性下降,最終影響用戶體驗,這是不能被容忍的。所以針對上述問題,我們需要對原系統(tǒng)進行全面的優(yōu)化升級。

    5 整體優(yōu)化思路

    6 ES優(yōu)化篇

    Elasticsearch 是一個實時的、Restful 風格的分布式搜索數據分析引擎,內部使用lucene做索引與搜索,能夠解決常規(guī)和各種類型數據的存儲及檢索需求,此外ES還提供了大量的聚合功能可以對數據進行分析,統(tǒng)計,生成指標數據等。典型的應用場景有:數據分析,站內搜索,ELK,電商等,主要特點為:

    高性能搜索,靈活的檢索、多元化的排序策略,準實時索引。集群分布式,易擴展,平行擴縮容。數據分片主備機制,系統(tǒng)安全高可用。豐富的生態(tài)Kibana可視化界面。

    6.1 業(yè)務背景

    天機閣使用騰訊云的ES組件,專門用于建立熱門Trace倒排索引,用戶在使用天機閣進行鏈路追蹤查詢時,首先可以指定Tag或者染色Key查詢到任意時刻上報的Trace元數據,天機閣會根據查詢到的Trace數據繪制出完整的服務調用過程。同時在UI上可以支持瀑布、調用樹的多種樣式的數據展示。如下圖所示:

    6.2 存在的問題

    隨著進入量的上漲,ES集群內部寫入峰值達到80w/s,日均文檔總量達到280億,索引占用總量達到 67T,每天新增索引量達到1000+,而每日文檔新增存儲總量達到10T。機器配置采用為:64個4C 16g的數據節(jié)點,平均CPU使用率在45-50%之間;最大CPU使用率在80%左右;內存使用率60%左右,而磁盤平均使用率達到了53%。數據寫入整體流程為:

    天機閣是基于業(yè)務Appid維度按天索引的策略,而伴隨業(yè)務量的極速上漲主要暴露出來的問題為:

    集群內部分片過多。

    分片過多的缺點主要有以下三個方面: 第一,ES每個索引的分片都是一個Lucene索引,它會占用消耗CPU、內存、文件句柄。第二:分片過多,可能導致一個節(jié)點聚集大量分片,產生資源競爭。第三:ES在計算相關度詞頻統(tǒng)計信息的時候也是基于分片維度的,如果分片過多,也會導致數據過少相關度計算過低。

    2.分片大小不均勻。部分索引的分片容量超過50g,側面反應了這些索引分片策略的不合理,最終會導致索引的查詢性能變慢。

    3.寫入耗時過大,部分索引查詢性能慢。ES寫入耗時達到(1500ms-2000ms),此外分片過大也直接影響到索引的查詢性能。

    索引創(chuàng)建過慢(1分鐘),大量寫入被拒絕。集群沒有設置主節(jié)點,導致創(chuàng)建索引時,數據節(jié)點要充當臨時主節(jié)點的角色,寫入量較小的時候,影響不大,當寫入壓力過大時,會加劇數據節(jié)點的負載,影響索引的創(chuàng)建速度。當出現密集型索引創(chuàng)建時,這個問題被無限放大,索引創(chuàng)建同時也會伴隨大量的元數據移動,更加劇了節(jié)點負載,從而導致大量數據寫入被拒絕現象。而寫入被拒絕最終會導致上游Flink集群劇烈抖動(寫入失敗拋出大量異常),以致于索引創(chuàng)建高峰期經常出現2-3小時的集群不可用狀態(tài)。

    5.系統(tǒng)出現大量異常日志.ES服務器異常,主要分為兩類,一類是:數據解析異常,另一類是:Fields_limit異常。

    索引的容量管理與維護困難。主要是解決大規(guī)模以及日益增長數據場景下,集群的自動化容量管理與生命周期管理的問題。

    6.3 優(yōu)化一期

    優(yōu)化點1:優(yōu)化集群內部分片過多、分片不合理、節(jié)點負載不均等問題。

    其中主要涉及了二個問題:

    如何確定索引單個分片大小?-> 小于40G如何確定集群中分片數量? -> 節(jié)點堆內存*節(jié)點數*200 = 2萬左右

    上述問題可以閱讀ES官方文檔和騰訊云ES文檔得到全面的答案,這里不再贅述,總而言之,查詢和寫入的性能與索引的大小是正相關的,要保證高性能,一定要限制索引的大小,而索引的大小取決于分片與段的大小,分片過小,可能導致段過小,進而導致開銷增加,分片過大可能導致分片頻繁Merge,產生大量IO操作,影響寫入性能。通過閱讀相關文檔,我提煉了以下三條原則:

    分片大小控制50G以內,最好是20-40G,以均衡查詢和寫入性能。每個節(jié)點可以存儲的分片數量與可用堆內存成正比,一條很好的經驗法則:“確保每個節(jié)點配置的每G堆內存,分片數在20個以下”。分片數為節(jié)點數整數倍,確保分片能在節(jié)點之間均衡分布。

    當然最好的方法是根據自身業(yè)務場景來確定分片大小,看業(yè)務是注重讀還是注重寫以及對數據實時性、可靠性的要求。天機閣的索引設計模式是非常靈活的,屬于典型的時序類型用例索引,以時間為軸,按天索引,數據只增加,不更新。在這種場景下,搜索都不是第一要素,查詢的QPS很低。原先的分片針對策略針對容量過低的索引統(tǒng)一采用5個分片都默認配置,少數超過500g的大索引才會重新調整分片策略,而隨著近期接入業(yè)務的不斷增多以及索引進入量的暴漲,集群內部出現了許多容量大小不一,且分布范圍較廣的索引。老的配置方式顯然已經不太合理,既會導致分片數急劇增長,也影響索引的讀寫性能。所以結合業(yè)務重新評估了集群中各個索引的容量大小,采用分級索引模版的分片控制策略,根據接入業(yè)務每天的容量變化,實現業(yè)務定制化的自適應分片。

    索引模版

    容量范圍

    分片策略

    索引占用量

    template-01

    0-40G

    單分片

    55%

    template-02

    40-100G

    4分片

    20%

    template-03

    100-200G

    8分片

    15%

    template-04

    200-400G

    12

    8%

    template-n

    ...

    ...

    ...

    一般而言:當用戶遇到性能問題時,原因通常都可回溯至數據的索引方式以及集群中的分片數量。對于涉及多租戶和用到時序型索引的用例,這一點尤為突出。

    優(yōu)化點2:優(yōu)化寫入性能。

    減少集群副本分片數,過多副本導致ES內部寫擴大。ES集群主用于構建熱門Trace索引用于定位問題,業(yè)務特性是寫入量大而數據敏感度不高。所以我們可以采用經濟實惠的配置,去掉過多副本,維護單副本保證數據冗余已經足夠,另外對于部分超大索引,我們也會采用0副本的策略。索引設計方面,id自動生成(舍棄冪等),去掉打分機制,去掉DocValues策略,嵌套對象類型調整為Object對象類型。此處優(yōu)化的目的是通過減少索引字段,降低Indexing Thread線程的IO壓力 == 經過多次調整選擇了最佳參數。根據ES官方提供的優(yōu)化手段進行調整,包括Refresh,Flush時間,Index_buffer_size等。

    上述優(yōu)化,其實是對ES集群一種性能的取舍,犧牲數據可靠性以及搜索實時性來換取極致的寫入性能,但其實ES只是存儲熱門數據,天機閣有專門的Hbase集群對全量數據進行備份,詳細記錄上報日志流水,保證數據的可靠性

    客戶端API升級,將之前ES原生的批量API升級為Transport API,策略為當數據緩存到5M(靈活調整)大小時,進行批量寫入(經過性能測試)。

    優(yōu)化點3:優(yōu)化索引創(chuàng)建方式

    觸發(fā)試創(chuàng)建索引改為預創(chuàng)建索引模式。申請專用主節(jié)點用于索引創(chuàng)建工作。

    優(yōu)化點4:優(yōu)化ES服務器異常

    調整字段映射模式,Dynamic-Mapping動態(tài)映射可能導致字段映射出現問題,這里修改為手動映射。調整Limit Feild限制,修改ES索引字段上限。業(yè)務層加入數據清洗算子,過濾臟數據以及埋點錯誤導致Tag過多的Span,保護存儲。

    6.4 一期優(yōu)化展示

    1.cpu使用率:CPU使用率45% => 23%,內部寫入量從60萬/s => 40萬/s。

    2.磁盤使用率53%=>40%。

    3.寫入拒絕率:索引寫入拒絕率降為0。

    4.集群宕機問題被修復:

    5.查詢耗時:大索引跨天級別查詢在500ms左右。

    6.分片數量7萬 => 3萬,減少了50%,同時索引存儲量優(yōu)化了20%

    7.寫入耗時:從2000ms =>900ms左右。

    6.5 優(yōu)化二期

    經過一期的優(yōu)化ES寫入性能有了明顯提升,但還存在一些痛點,包括:

    寫入延時還是過大,沒有達到預期效果分片3萬+還是過多,同時索引創(chuàng)建時間仍然過長(1分鐘索引容量管理以及生命周期管理困難。

    6.6 優(yōu)化方案

    升級硬件配置,4C16g升級為16C 32g, 節(jié)點總數由64降為48,開啟專用主節(jié)點。默認情況下集群中的任何一個節(jié)點都有可能被選為主節(jié)點,為了確保一個集群的穩(wěn)定,當節(jié)點數比較多時,最好是對生產環(huán)境中的節(jié)點進行職責劃分,分離出主節(jié)點和數據節(jié)點。天機閣采用3(防止腦裂)臺低配置的節(jié)點作為專用主節(jié)點,負責索引的創(chuàng)建、刪除、分片分配等工作,數據節(jié)點專門用來做數據的索引、查詢、更新、聚合等工作。ES集群分通道部署。目前天機閣只有一個公共集群,所有業(yè)務都在同一個集群中創(chuàng)建索引,這種方式雖然具備了一定的可擴展性。但是隨著業(yè)務量的進一步增長,集群規(guī)模也會琢漸變的巨大,從而容易達到系統(tǒng)的性能瓶頸,無法滿足擴展性需要,且當大集群中有索引出現問題時,容易影響到其他業(yè)務。所以我們從業(yè)務維度對公共集群進行解耦,按通道做set化部署,將不同通道業(yè)務,就近路由到不同集群,各集群可按需靈活擴展。基于ILM + Rollover + 別名實現索引自動化生命周期管理與容量管理。天機閣是典型的日志型時序索引,根據應用Appid按天定時生成索引,索引的生命周期默認為7天,其中當天的數據會被頻繁寫入與查詢,第二,三天的數據偶爾被查詢,后面幾天的數據只有少數重度業(yè)務使用者才會查詢到。這樣的特性會衍生出來幾個問題:ES索引分片數一旦創(chuàng)建便無法更改,這種機制無法應對業(yè)務忽然放量導致的索引容量激增的問題,通常只能通過手動Reindex來解決,而Reindex過程也會影響到業(yè)務寫入性能。根據日志索引存儲具備的特點,不同時間階段可以重新對分片數、副本數、Segment進行針對性調整,對冷數據進行歸檔處理,從而更好的利用機器資源。需要創(chuàng)建額外的定時任務來刪除索引,特別是當集群中索引過多時,密集型的索引刪除操作,短時間內也會造成集群的波動。

    我們希望構建一個優(yōu)雅的索引自動化運維管理系統(tǒng),而這個系統(tǒng)主要解決兩個問題:

    自動化索引生命周期管理:創(chuàng)建索引生命周期管理,并定義不同階段的索引策略,以此來實現ES索引自動化優(yōu)化與生命周期管理而不需要引入第三方服務。自動化索引容量管理:當集群索引超過設定容量大小時,可以自動進行滾動,生成新的索引,而上游業(yè)務不需要感知。

    6.7 業(yè)界最佳實踐

    ES在索引管理這一塊一直在進行迭代優(yōu)化,諸如Rollover、日期索引、Curator等都是對索引管理的一種策略,但是這些方式都不夠自動化,直到ES6.7以后,官方推出了ILM(index lifestyle management)索引生命周期管理策略,能同控制多個索引的生命流轉,配合索引模板、別名、Rollover能實現自動化索引生命周期與容量的管理閉環(huán)。

    ILM策略主要有四個階段:

    Hot階段:可讀,可寫,索引會被頻繁查詢。Warm: 可讀,不可寫,此時可對數據進行歸檔,采用Shrink與Forcemerge,減少索引副本與主分片數,并強制進行Segment合 并,能夠減少數據內存與磁盤的使用。Cold:不可寫入,很久沒被更新,查詢慢。可對索引進行凍結操作,此時集群將對索引進行落盤操作,業(yè)務需要指定特定的參數才能查詢到數據。Delete:刪除操作。將觸發(fā)索引刪除事件。

    6.8 天機閣索引管理實踐

    天機閣使用ILM 策略配合分級索引模板可以比較優(yōu)雅的實現索引的自動化管理過程。ILM 策略主要分為四個階段:熱、溫、冷和刪除。對于定義好的各個階段的相應策略,ILM 會始終會順序執(zhí)行。我們只需要根據索引每個階段的數據特性定義合適的管理方式,諸如:索引滾動更新用于管理每個索引的大小;強制合并操作可用于優(yōu)化索引;凍結操作可用于減少集群的存儲壓力。

    天機閣通過Flink Stream讀取Kafka數據實時寫入ES,峰值QPS接近35w,每天新增索引超過1000+。在這么大數據量上進行操作是一件很麻煩的事。我們希望ES能夠自動化對分片超過100g的索引進行滾動更新,超過3天后的索引進行自動歸檔,并自動刪除7天前的索引,同時對外以提供索引別名方式進行讀寫操作。這個場景可以通過ILM配置來實現,具體策略是:對于一些小于40G的索引,在Warm階段執(zhí)行Shrink策略壓縮成單分片,并設定寫入低峰期執(zhí)行Forcemerge操作合并集群中小的段,Cold階段可以執(zhí)行Allocate操作來減少副本數,而針對集群內部1%的大索引,可以執(zhí)行Freeze操作來釋放部分存儲空間。具體策略如下表所示:

    ILM可以高效的進行索引生命周期與容量自動化管理,使用起來也很簡單。但是還是有不少要注意的地方。

    切換策略后索引不會馬上生效,舊數據仍然寫入舊索引,只有觸發(fā)Rollover生成新索引,新策略才會生效。每個階段的生效時間是以Hot階段觸發(fā)Rollover為起始時間的基礎上再加業(yè)務配置時間。如果不想使用Rollover,可以直接進行關閉,也可以實現只對索引進行生命周期的管理操作。騰訊云ES最好采用 白金版 + 6.8以上版本。

    后續(xù)優(yōu)化:ILM + 冷熱架構,ILM 可支持為時序索引實現熱溫冷架構從而節(jié)約一些成本。

    6.9 最終優(yōu)化效果

    1.寫入耗時:2500萬/min寫入量 2000ms- >320ms。

    分片數量:7.2萬 -> 2萬 分片數量減少 70%。

    3.索引存儲總量:67T -> 48T 節(jié)約存儲 30%。

    4.創(chuàng)建索引速度:分鐘級 -> 秒級。

    7 hbase優(yōu)化篇

    HBase是一種構建在HDFS之上面向列的分布式數據庫,能支持海量數據的存儲。主要具備如下特點:

    高可靠、高可用、可伸縮。基于Zookeper的協(xié)調服務保證系統(tǒng)高可用性,基于Wal與Replication機制,保證數據的可靠性。海量存儲:保證讀性能的前提下,單表可支持百億級別行、百萬級別列。面向列:數據按照列來構建索引聚,數據即索引,只訪問查詢涉及的列時,可以大量降低系統(tǒng)的I/O。高性能:底層索引設計基于LSM數據結構,使得HBase具備非常高的寫入性能。同時緩存機制使得HBase具備一定的隨機讀寫性能。

    7.1 業(yè)務背景

    天機閣主要采用公司內部的Hbase組件,主要用于存儲Trace元數據、關系鏈、拓撲圖等數據模型,其中Trace元數據的存儲以Traceid作為Rowkey、調用樹以(時間戳_appid_svr_ifc)做為rowkey、關系鏈以(時間戳_appid, 時間戳_svr) 作為rowkey。通過Hbase 客戶端的批量 API并發(fā)寫入同一張表中,寫入流程如下圖所示:

    7.2 存在的問題

    目前天機閣Hbase寫入峰值在30w/s,機器配置為16臺 Ts60,每天數據寫入總量在15-20t左右,單機寫入峰值在2萬/s 。我們分別從CPU、磁盤、IO、內存等角度查看了各個機器使用狀況,主要歸納為以下三個問題:

    1.調用鏈容易產生超級Trace,造成大Key、熱Key等問題:通過對線上數據的監(jiān)控,一般Rowkey寫入的ValueKey平均大小在300-700字節(jié)左右,但是部分業(yè)務存在熱點Push或者框架埋點錯誤等問題,會產生1M-2M的超級Trace ,這種case對Hbase的影響是巨大的,會頻繁觸發(fā)Hbase Memstore Flush、Hlog文件寫入切換以及底層Storefile文件的Compaction等操作,從而造成寫入性能急劇下降,同時也會影響到表中其他業(yè)務的吞吐量。

    2.關系鏈、調用樹存在寫熱點問題:熱點問題會造成節(jié)點請求不均衡,導致部分節(jié)點負載過高。Hbase表是以Rowkey進行排序,再把Key拆分成若干個Region,分散到不同機器上,如果拆分合理,各個機器Region分布均勻,那負載就是均衡的,如果拆分不合理,就會造成寫入過于集中,部分機器負載過高。

    圖7.4: 熱點請求路由到同一臺機器上

    3.表設計耦合過重:關系鏈、拓撲圖、調用鏈等數據都存儲在同一張表中產生了大表問題, 同時調用鏈容易產生大Key問題,大key的寫入會造成該表所在的節(jié)點吞吐量大大降低,從而影響到了表中的其他業(yè)務,諸如拓撲圖數據的寫入性能。

    7.3 優(yōu)化方案

    1.預分區(qū) + Hash散列+ 分桶:Hbase本身是熱點存儲.在創(chuàng)建表時只會存在一個沒有Start-key End-key邊界的Region,當數據寫入時,Region會不斷增加,Split成2個Region,產生Midkey。在此過程中,數據只往一個Region上寫,會有寫熱點問題,而大量數據寫入導致的頻繁Split也會消耗IO資源。針對這個問題,業(yè)界通用的解決方案是對數據進行預分區(qū),同時合理設計Rowkey來保證數據均勻到各個Region。天機閣Key的設計考慮了隨機數、時間戳、機器IP、Tid等多個因子來保證Rowkey生成的隨機性,再根據Rowkey的特點以及數據容量增長預期,合理劃分了整個分區(qū)的范圍,保證數據能均勻到各個分區(qū)。此外,也采用分桶的方式來緩解單個Region的壓力,基本策略是在Rowkey前面加隨機數,將相同Rowkey數據散列到若干桶里,在查詢時候再進行并發(fā)讀取,這種策略可以非常有效的處理關系鏈數據形成的熱點問題。

    隨機散列與預分區(qū)二者結合起來,是業(yè)界比較常規(guī)做法。預分區(qū)一開始就預建好了一部分Region,這些Region都維護著自己的Start-End Keys,再配合上隨機散列,基本能保證請求能均勻命中這些預建的Region,從而大大提高性能。

    圖7.6 RS 上Region數基本均勻

    事實上Hbase的熱點問題一直是比較棘手的,而天機閣的熱點數據是比較頻繁的。上述一些方案雖然能緩解熱點問題,但是確增加了業(yè)務復雜度。并沒有徹底根治這個問題,期待后續(xù)Hbase的迭代。

    2.對重要業(yè)務進行分表,計算層進行邏輯隔離,存儲層進行資源隔離。大表會存在很多問題,諸如Region過多、查詢性能差、數據導出遷移困難等。所以需要對天機閣拓撲圖、關系鏈、調用鏈的等業(yè)務存儲進行分表,同時底層存儲在物理層面進行資源隔離,將幾部分數據解耦出來,不同數據路由到不同表中,寫入互不影響,以此提升各個業(yè)務的寫入性能。

    3.業(yè)務上避免大Key寫入:對超過300個Trace的數據進行降級處理。

    4.采用批量異步提交API,根據需要動態(tài)修改HWal、Memstore flush等參數。

    7.4 優(yōu)化效果

    1. 解決了大量寫入毛刺的問題,當天寫入延時1800ms -> 150ms

    2. 寫關系鏈邏輯被獨立出來,寫入延時優(yōu)化至5-15ms以內。

    3. 大key過濾量。

    8 flink優(yōu)化篇

    Flink優(yōu)化篇后面會進行文章整理并進行講解,這里暫時先簡單介紹一下背景、存在的問題以及優(yōu)化后的效果。

    8.1 業(yè)務背景

    首先由Flink定義的Source算子對數據通道進行實時消費, 經過FilterFunction與FlatMapFuntion算子完成對數據的清洗與格式轉換工作,再根據TraceId進行ReduceKeyby,將同一個Traceid的數據路由到同一個窗口進行實時聚合計算,生成調用鏈與拓撲圖等數據模型,寫入存儲。

    8.2 存在的問題

    1. 數據反壓:

    圖8.2: Flink反壓監(jiān)控面板

    生產環(huán)境中造成反壓的情況有很多:1. 底層Sink算子攝入速度慢,會導致上游算子出現反壓。2. 窗口邏輯過重,處理性能慢,也會導致上游Source算子出現反壓。3. 代碼有bug或者有比較耗時的操作也會造成反壓現象。

    反壓不一定直接影響集群的可用性,但是說明集群一直處于一種亞健康的狀態(tài),有潛在的性能瓶頸優(yōu)化前天機閣所有Trace任務都是處于這樣一種亞健康狀態(tài)。如下圖紅線框所示。

    2. 數據傾斜,集群資源利用率低:由于受到拓撲圖邏輯的影響,同一個Trace的所有Span會路由到同一個窗口(節(jié)點)用于還原拓撲圖。而當業(yè)務存在熱點問題時,產生的大量超級Trace也都會路由到同一個節(jié)點,從而產生該節(jié)點過載,節(jié)點窗口處理速度減慢等問題。而大量的數據傾斜會導致集群資源無法得到充分利用,最終造成集群吞吐量下降,處理延時上升

    3. 窗口函數性能差,內存溢出:由于集群一直受到反壓問題的困擾,且采用了全局窗口來處理大量的計算邏輯,導致當窗口聚合的數據量較大時,容易發(fā)生內存溢出的問題,特別是當開啟Checkpoint機制時,內存溢出問題更加頻繁。Chekcpoint是保證數據一致性的關鍵,而反壓會影響到Checkpoint 時長和 State 大小,當數據處理被阻塞時,Checkpoint Barrier 流經整個數據管道的時間會變長,其中State 過大會直接導致OOM,而Checkpoint時間變長超過設定時間,最終會導致Chekpoing的失敗。

    8.3 優(yōu)化方案

    1. 輕重分離:在問題分析一節(jié)中有提到過Trace系統(tǒng)很多突發(fā)流量不可預測,而系統(tǒng)需要在流量不可控的時候,實現影響面的可控,當遇上業(yè)務放量,熱點Push等場景造成的流量洪峰時,能夠讓影響僅僅局限在局部系統(tǒng),不擴散影響到整個系統(tǒng)。所以我們在系統(tǒng)設計時要考慮輕重分離。天機閣采用了一些常規(guī)的分離方法,例如接入層,計算層都是按通道分離,后續(xù)又加入了存儲分離。原天機閣實時計算系統(tǒng)耦合了調用鏈與拓撲圖兩部分邏輯,而天機閣大部分用戶對調用鏈系統(tǒng)的使用場景比較多,業(yè)務依賴性比較強。所以在這個基礎上我們繼續(xù)對內容進行細分,對計算邏輯進行解耦,將原系統(tǒng)獨立拆分成拓撲圖子系統(tǒng)調用鏈子系統(tǒng)兩部分,對邏輯較輕的調用鏈子系統(tǒng)進行重新建設,而對邏輯較重的拓撲圖系統(tǒng)進行單獨優(yōu)化。其中分離出來的調用鏈子系統(tǒng)如圖所示。

    圖8.5: 天機閣拓撲圖子系統(tǒng)

    其中主要涉及兩個點的改變:

    (1).修改Flink Stream模式,去調Keyby,并將KeyedStream修改為Union Stream模式,可以同時讀取多個不同Kafka通道數據,合并為同一個流,這里優(yōu)化的本質是修改算子的路由策略,將Hash修改為Rebanlance,通過再平衡來減輕數據傾斜的問題。

    圖8.6: Flink數據路由策略

    (2).修改算子流程,將GlobalWindows窗口優(yōu)化為增量窗口 + HbaseSinkFunction + EsSinkFunction的模式。 (3).調整各個算子并行度,采用Operators-Chain模式。盡可能的將Operator的Subtask鏈接一起形成Task,從而讓每個Task在一個線程中執(zhí)行。這樣可以大量減少線程之間的切換以及數據在緩沖之間的交換,提高整體吞吐量。

    2. 窗口算子優(yōu)化:Flink 窗口是無限數據流處理的核心,將一個無限流的Stream拆分成有限大小的“Buckets”桶,業(yè)務可以在這些桶上做計算操作。天機閣使用KeyedStream + Globalwindow + ProcessFunction 模式來處理業(yè)務,這種模式提供了一定靈活性,可以將窗口中的所有元素緩存起來,從而獲得全量數據的迭代能力,但這確帶來了性能成本與資源的損耗,會占用更多的內存以及窗口耗時,也意味著無法進行增量迭代操作。所以這里直接對窗口邏輯進行解耦,簡化窗口函數的邏輯同時采用中間狀態(tài)更小的增量窗口函數算子,整體基于TimeWindow + ReduceFunction/AggregateFunction +SinkFuntion模式代替原先的全局窗口模式。

    3. 存儲優(yōu)化:Flink是優(yōu)化的最后一部,事實上在優(yōu)化完存儲后,反壓現象明顯減輕了許多。

    4. 拓撲圖子系統(tǒng)優(yōu)化:拓撲圖優(yōu)化會借鑒Zipkin-Depencency,Jeager Analytics 兩階段預聚合的思路來進行優(yōu)化,,后面會有專門文章詳細介紹

    8.4 優(yōu)化效果

    1. 算子反壓,資源傾斜問題得到解決。

    2. 蟲洞集群平均處理延時由30-60s 下降到1s,由分鐘級優(yōu)化到秒級,且集群更加穩(wěn)定。

    3. 集群資源利用率顯著提高,目前只灰度了一個任務,節(jié)約了120VCores,預計全量后可以節(jié)約35%(300VCores)左右的資源。

    9 總結

    目前新系統(tǒng)已經在生產環(huán)境,穩(wěn)定運行1個月左右,數據延時也從之前分鐘縮短到10s內,數據實時性大大提高,同時資源利用率的提升也節(jié)省了大量的計算資源

    Flink實時計算系統(tǒng)是天機閣鏈路追蹤平臺的重要組成部分,而日益增長的數據量給計算集群帶來了很大的挑戰(zhàn)。面對這些問題,我們重新梳理了整個鏈路架構,找到系統(tǒng)的瓶頸所在,并展開了一系列有效的優(yōu)化措施。而在未來,我們會繼續(xù)在大數據領域的探索研究工作,更進一步的打磨系統(tǒng)數據處理能力,提供更好的服務。

    整體從計算層、存儲層、架構、服務質量等幾個維度對系統(tǒng)進行了優(yōu)化,同時也加強了系統(tǒng)的容災能力

    自定義計數器實現熱Key自動發(fā)現與降級。存儲過載保護,當QPS超過壓測閾值時,觸發(fā)降級邏輯通過druid 預聚合方式完善對業(yè)務的多維監(jiān)控。

    9.1 優(yōu)化后架構圖

    9.2 優(yōu)化后效果圖

    9.3 思考

    性能是用戶體驗的基石,而性能優(yōu)化的最終目標是優(yōu)化用戶體驗,俗話說:“天下武功,唯快不破”,這句話放到性能優(yōu)化上也是適用的,我們優(yōu)化存儲攝入速度,優(yōu)化Flink的處理速度以及接入層的數據采集能力,都是為了保證數據的“快”。而優(yōu)化的過程則需要我們做好打持久戰(zhàn)的準備,既不能過早優(yōu)化,也不能過度優(yōu)化。最好的方式是深入理解業(yè)務,了解系統(tǒng)瓶頸所在,建立精細化的的監(jiān)控平臺,當系統(tǒng)出現問題時,我們就可以做到有條不紊,從應用,架構,運維等層面進行優(yōu)化分析,設定一些期望的性能指標,并對每次優(yōu)化措施和效果做總結思考,從而形成自己的方法論。

    關鍵詞:

    毛茸茸bbw亚洲人| 一本色道久久88亚洲精品综合| 亚洲午夜电影一区二区三区| 图图资源网亚洲综合网站| 亚洲无人区一区二区三区| 国产成人99久久亚洲综合精品| 亚洲福利精品一区二区三区| 亚洲AV噜噜一区二区三区| 日韩国产精品亚洲а∨天堂免| 亚洲国产精品久久久久秋霞小| 亚洲欧美第一成人网站7777 | 亚洲国产成人九九综合| 亚洲视频免费在线看| 亚洲手机中文字幕| 亚洲av永久无码精品三区在线4| 亚洲一级高清在线中文字幕| 亚洲一区二区三区亚瑟| 香蕉大伊亚洲人在线观看| 亚洲人成无码网站在线观看| 亚洲另类无码专区首页| 久久水蜜桃亚洲AV无码精品| 在线a亚洲v天堂网2018| 亚洲午夜激情视频| 亚洲欧洲日产国码av系列天堂| 亚洲AV无码一区二区二三区软件| 久久亚洲精品成人综合| 亚洲视频在线观看地址| 亚洲欧洲另类春色校园网站| 亚洲熟妇AV一区二区三区宅男| jizzjizz亚洲日本少妇| 亚洲国产专区一区| 亚洲精品乱码久久久久久久久久久久| 亚洲国产精品成人精品无码区| 亚洲天天做日日做天天看| 亚洲国产美女精品久久久久| 亚洲 欧洲 视频 伦小说| 亚洲AV无码一区二区三区鸳鸯影院| 亚洲精品久久久www| 久久久久久久综合日本亚洲| 久久精品亚洲一区二区三区浴池| 亚洲一级高清在线中文字幕|