隨著業(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)槲⒎占軜嫛Ｌ貏e是隨著容器, Serverless等技術的廣泛應用，它將龐大的單體應用拆分成多個子系統(tǒng)和公共的組件單元。這一理念帶來了許多好處：復雜系統(tǒng)的拆分簡化與隔離、公共模塊的重用性提升與更合理的資源分配、大大提升了系統(tǒng)變更迭代的速度以及可擴展性。但反之，業(yè)務架構也隨之變的越來越復雜，一個看似簡單的業(yè)務后臺可能有幾百甚至幾千個服務在支撐，當接口出現問題時，開發(fā)人員很難及時從錯綜復雜的服務調用中找到問題的根源，從而錯失了止損的黃金時機，排查問題的過程也需要耗費大量的時間和人力成本。為了應對這一問題，業(yè)界誕生了許多優(yōu)秀的面向Devops的診斷分析系統(tǒng)，包括Logging、Metric、Tracing。三者關系如圖所示：
此圖來源自網絡
(相關資料圖)
三者互相重疊，又各自專注于自己的領域，將三者結合起來就可以快速定位問題。而已知的業(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)化措施和效果做總結思考，從而形成自己的方法論。
關鍵詞：
