一、背景和挑戰(zhàn)

1、背景

首先來簡單介紹一下貨拉拉。

貨拉拉于2013年成立于粵港澳大灣區(qū)，是一家從事同城跨城貨運、企業(yè)版物流、搬家、零擔及汽車銷售的互聯(lián)網(wǎng)物流商城。截至2022年12月，貨拉拉業(yè)務范圍已覆蓋360座國內城市，月活司機達68萬，月活用戶數(shù)達950萬，并處于一個快速增長的階段。

接下來對貨拉拉當前的大數(shù)據(jù)體系做一個簡要介紹。

自下而上來看,首先是基礎層和數(shù)據(jù)接入層，主要提供的是數(shù)據(jù)計算、存儲以及集群管理。往上是數(shù)據(jù)研發(fā)和數(shù)據(jù)倉庫，主要提供數(shù)據(jù)研發(fā)能力。接著是具備業(yè)務屬性的應用層和服務層。整個體系，自下而上相互支撐，最終實現(xiàn)支撐業(yè)務和賦能業(yè)務。

上圖展示了整個數(shù)據(jù)流的典型場景，分為數(shù)據(jù)采集、數(shù)據(jù)存儲和計算，以及數(shù)據(jù)服務幾個階段。

數(shù)據(jù)采集分為實時采集和離線采集。實時采集的數(shù)據(jù)主要來源于用戶埋點數(shù)據(jù)，從用戶端采集之后，流入實時鏈路進行計算。離線采集主要來源于業(yè)務訂單數(shù)據(jù)，按照小時和天采集到大數(shù)據(jù)存儲桶以供使用。

數(shù)據(jù)存儲和計算階段，將數(shù)據(jù)進行ETL處理，再推送到上層應用進行分析。

2、Doris業(yè)務介紹

我們從2022年初開始使用Doris，在這一年半的時間里，Doris還是相對穩(wěn)定的，同時提供了高性能的查詢。上圖右側是Doris的整體架構圖。Doris的數(shù)據(jù)源來自IOT、埋點和數(shù)據(jù)庫，通過實時數(shù)倉和離線數(shù)倉兩個方式寫入。以Doris作為主引擎構建了大數(shù)據(jù)OLAP平臺，服務于上層應用。

目前賦能的業(yè)務包括，ABtest，主要是關聯(lián)海量埋點數(shù)據(jù)，進行靈活的多維度分析；用戶畫像，主要是做人群圈選；羅盤，是增長分析決策平臺，提供漏斗分析和歸因診斷的功能；云臺，是數(shù)據(jù)可視化平臺，提供自助報表分析的能力。

3、穩(wěn)定性挑戰(zhàn)

穩(wěn)定性方面，當前面臨著兩大挑戰(zhàn)。

首先，業(yè)務對Doris服務穩(wěn)定性要求高。Doris已經接入公司多個核心業(yè)務，已經成為大數(shù)據(jù)的核心基礎組件，因此對穩(wěn)定性的要求是非常高的。

另外，開源軟件基本能力和生產需求的差距大。Doris內核能力較為完善，但外圍平臺能力不足，例如監(jiān)控告警、運維管控。Doris內核演進速度快，相應的Issue也較多，穩(wěn)定性問題可能會接踵而來。

Doris穩(wěn)定性保障的目標為：

•  少出事，核心鏈路數(shù)據(jù)，全年準確率達到99.45%以上；
• 快發(fā)現(xiàn)，核心鏈路問題主動發(fā)現(xiàn)的時間小于5分鐘；
• 快恢復，P0核心鏈路恢復時間小于5分鐘，P1級（埋點相關指標，容忍度較高）鏈路恢復時間小于10分鐘。

二、穩(wěn)定性能力保障

接下來將通過我們遇到的一些穩(wěn)定性相關案例，來梳理一下Doris的穩(wěn)定性保障能力。

1、案例

穩(wěn)定性案例分為查詢、導數(shù)、數(shù)據(jù)質量、版本升級、以及業(yè)務變更這五類問題。

案例一：查詢性能問題

場景是云臺查詢Doris間歇性報錯。我們定位的原因是用戶提交了大量的查詢，以及一些大查詢，導致fragment的rpc處理線程池滿。目前的處理辦法是加大緩存容量，增加緩存命中率。另外，將查詢時間下調，同時增加大查詢的攔截能力。

案例二：導數(shù)性能問題

在一個準實時場景下，5分鐘調度任務因多個任務執(zhí)行超時，導致報表數(shù)據(jù)更新延遲并跌0。原因是業(yè)務方提交了其他任務存在嚴重亂序，導致集群的整體寫入吞吐變得很慢，影響了準實時場景。我們的解決方法是，將Doris任務及導入?yún)?shù)進行了優(yōu)化。同時，加強了Doris變更規(guī)范管控與審批流程，并正在實現(xiàn)業(yè)務多租戶的隔離。

案例三：數(shù)據(jù)質量問題

業(yè)務使用Sparkload導入Unique模型表，查詢結果不穩(wěn)定，導入的數(shù)據(jù)和查詢的結果不一樣。原因為Unique模型表使用Sparkload導數(shù)時存在異常。目前是采取規(guī)避的方法去解決，首先是將Unique模型改為Duplicate模型重建表，并進行任務的重寫；另外，將Unique模型使用注意事項加入準入規(guī)范及最佳實踐進行宣講。

案例四：版本升級問題

從1.1升級到1.2，在任務高峰期內存出現(xiàn)OOM被kill，導致任務報錯。原因是升級后的bitmap向量化沒有進行謂詞下推，也就是過濾條件沒有提前執(zhí)行，導致內存上漲。目前的解決辦法是業(yè)務對SQL謂詞下推進行了優(yōu)化，如and和or的條件合并。后續(xù)會考慮集群HA方案。

案例五：業(yè)務變更問題

業(yè)務側自行對Doris表新增字段，導致分區(qū)無法查詢。原因定位為觸發(fā)了Doris版本1.0的bug，導致部分segment損害，無法修復。針對這一問題，我們沉淀了一個通過Sparkload快速恢復數(shù)據(jù)的應急預案。并對用戶宣導，遵守使用規(guī)范、任務上線規(guī)范和發(fā)布變更規(guī)范，避免類似問題的再次發(fā)生。

2、穩(wěn)定性建設思路

針對上述案例，我們從少出事、快發(fā)現(xiàn)、快恢復三個維度，總結了一些穩(wěn)定性相關的能力。例如發(fā)現(xiàn)能力、容量規(guī)劃、自動化能力等等。接下來將對其中部分能力進行具體的介紹。

3、發(fā)現(xiàn)能力

當前Doris監(jiān)控告警系統(tǒng)以Zabbix作為底座，對Doris服務進行監(jiān)控和告警。

發(fā)現(xiàn)能力主要包含三個維度：

• 表級監(jiān)控，主要是監(jiān)控表容量和狀態(tài)；
• 任務監(jiān)控，針對導數(shù)任務狀態(tài)進行監(jiān)控；
• 組件監(jiān)控，針對服務指標（如查詢、導數(shù)）、進程和機器指標進行監(jiān)控。

我們對指標也進行了分級，一級指標表示服務不可用，用于發(fā)現(xiàn)和定位問題；二級指標和三級指標用于日常定位問題和分析問題。

上圖是指標監(jiān)控的畫面。

4、容量規(guī)劃

（1）容量梳理

容量梳理包含業(yè)務需求、數(shù)據(jù)量、硬件資源和集群規(guī)模幾大部分。

通過業(yè)務需求，確定當前的場景是實時還是離線，數(shù)據(jù)寫入速度，分區(qū)情況，以及查詢、存儲的要求等等。同時根據(jù)當前的業(yè)務需求需要的數(shù)據(jù)量，擬定當前的硬件資源，以及集群規(guī)模。生產環(huán)境集群資源配置，F(xiàn)E(云盤)和BE(本地) CPU和內存比是1:4的機型這種機型使用。這種在當前環(huán)境有較高的資源利用率。在需要較高的吞吐情況下，使用本地IO高吞吐的磁盤。

（2）容量監(jiān)控

通過對機器級別的一些指標，例如磁盤容量、CPU、內存，以及服務指標，例如任務隊列，分為一級指標和二級指標，設定一些閾值，評估當前集群是否處于一個健康水位，從而判斷集群是否需要擴容。

5、高可用能力

（1）服務高可用

服務高可用，主要依賴Doris自身的能力，F(xiàn)E用三臺部署高可用架構。BE數(shù)據(jù)用三臺副本，四臺及以上的節(jié)點，避免一臺宕機導致服務數(shù)據(jù)不可寫。另外，引入負載均衡綁定后端，實現(xiàn)連接數(shù)的均衡，以及讀寫高可用。

（2）鏈路高可用

分為離線/準實時鏈路和實時導數(shù)鏈路。離線/準實時鏈路，支持異常重試和電話告警，數(shù)據(jù)支持冪等操作。實時導數(shù)鏈路，和離線一樣，通過自研的調度平臺進行調度。

6、自動化能力

通過大數(shù)據(jù)自動化運維平臺構建了大數(shù)據(jù)自動化能力，底座基于Conductor和Ansible進行開發(fā)。目前已集成了Doris部署、擴容、升級等工作流編排能力。提高了Doris組件服務運維的穩(wěn)定性，提升了運維人效。

7、其他保障能力

查詢攔截能力：設置用戶級別攔截規(guī)則，根據(jù)實際數(shù)據(jù)量級、查詢規(guī)模設置攔截規(guī)則。制定了快速對異常query進行kill的能力，防止對集群整體產生更大的影響。

故障快恢復能力：包括分區(qū)數(shù)據(jù)的快速恢復能力，以及tablet狀態(tài)恢復能力。

業(yè)務隔離：根據(jù)業(yè)務重要程度、數(shù)據(jù)類型屬于實時還是離線，進行集群隔離、多租戶。

用戶權限管控：通過使用Doris自帶的RBAC（Role-Based Access Control）能力，對用戶/角色賦予相關權限。

三、穩(wěn)定性流程規(guī)范

穩(wěn)定性流程規(guī)范最重要的作用是提升系統(tǒng)能力下限，在穩(wěn)定性保障中是非常重要的一環(huán)。我們圍繞著Doris流程的三個階段制定了相應的規(guī)范：

•  Doris業(yè)務準入規(guī)范：快速評估業(yè)務需求，判斷Doris是否適合該業(yè)務場景。
•  Doris使用規(guī)范：提供Doris的最佳使用實踐，規(guī)避已知風險，避免重復犯錯。
•  Doris業(yè)務變更規(guī)范：進行發(fā)布流程管控，減少因發(fā)布造成的故障和影響。

接下來將具體展開介紹這三個規(guī)范。

1、Doris業(yè)務準入規(guī)范

當我們接收到一個新的需求時，首先要進行需求評估，判斷是否適合Doris。我們會按照業(yè)務穩(wěn)定性要求、導數(shù)、存儲等多個維度進行綜合考量。導數(shù)部分，通過Flink和streamload的方式將數(shù)據(jù)寫入Doris，為了提升性能，會將數(shù)據(jù)累計到150M做批次導入，寫入延遲通常在秒級。對寫入延遲比較高的場景，要求在毫秒級的，不太適用。目前的版本是存算一體的架構，存儲成本相對較高，對于大容量的業(yè)務，出于成本的考慮也并不適用。數(shù)據(jù)量比較小的場景，推薦直接使用MySQL。查詢QPS方面，對于端上的查詢QPS要求幾千或者上萬，不推薦使用Doris。對于風控的業(yè)務，對查詢的響應要求非常高，也不適合Doris，會推薦使用HBase。

后續(xù)參加需求準入的評審，主要評估業(yè)務的價值，綜合評價投入產出比。

2、Doris使用規(guī)范

在業(yè)務接入Doris之前，我們會提供一個測試集群，并提供Doris使用規(guī)范，和一些反例。從建表、增刪改查等多個方面引導用戶更好地使用Doris。

使用不規(guī)范案例，例如在建表環(huán)節(jié)，分桶設置很小，隨著業(yè)務的不斷積累，單個table達到30G，后續(xù)執(zhí)行compaction就會很慢，尤其是base compaction會非常慢。會影響到集群的吞吐和穩(wěn)定性。在數(shù)據(jù)寫入方面，用Flink實時寫入，強制要求使用平臺提供的API。曾經有業(yè)務使用自己的jar包，沒有控制并發(fā)寫入的量，使集群吞吐變慢。嚴格保證用戶的寫入沒有亂序。用戶通過insert into的方式寫入，Doris的insert into 語句是異步的，還需要異步地等待版本發(fā)布之后數(shù)據(jù)才可見。刪除階段，在業(yè)務的高峰期不推薦頻繁使用刪除操作，這樣會導致集群的base compaction操作很頻繁，導致集群吞吐變慢。對于查詢，嚴禁不帶任何參數(shù)的全表查詢，容易打爆CPU和內存。同時也對大查詢根據(jù)規(guī)則進行攔截。

在明確了使用規(guī)范，并對業(yè)務部分進行宣講后，大大提升了Doris的穩(wěn)定性。

3、Doris業(yè)務變更規(guī)范

Doris變更規(guī)范，主要涉及的操作包括：Doris集群本身的變更，比如集群配置的修改、集群重啟、集群版本升級等；還有一些業(yè)務側的變更，比如新建表、新添加導出鏈路、表和字段的修改等等。

變更規(guī)范主要包括四大部分：

首先是業(yè)務變更的時間窗口，通常會選擇在業(yè)務低峰期進行變更。當然緊急的變更需求也可以走緊急變更流程。

第二是發(fā)布內容和發(fā)布通知，對發(fā)布背景和執(zhí)行操作要進行清楚地描述，同時要充分地通知到業(yè)務方和執(zhí)行方，保證次日Oncall。

第三是由方向負責人和組負責人進行審核，遵循Doris使用規(guī)范。

最后，驗收階段，分為服務功能性驗收和服務穩(wěn)定性驗收，針對異常能夠做到快速回滾。

四、總結與規(guī)劃

1、總結

首先要明確穩(wěn)定性目標，并將目標量化，確定一些指標項。對于日常的案例，包括穩(wěn)定性冒煙、穩(wěn)定性故障，要做到對每次冒煙和故障都有記錄，并且定期總結和復盤，找到與穩(wěn)定性目標之間的差距，用于持續(xù)構建保障性能力。制定流程規(guī)范，并嚴格遵守規(guī)范，不斷向穩(wěn)定性目標靠近。

穩(wěn)定性的建設是持續(xù)的、成體系的，而非靠運氣。穩(wěn)定性目標的實現(xiàn)需要業(yè)務方的支持，而非單點的突破，比如流程規(guī)范、HA能力等等都需要業(yè)務方的支持和遵守。

2、規(guī)劃

在穩(wěn)定性方面，我們正在探索多集群HA，這樣一個集群出現(xiàn)問題時可以快速回滾到備用集群。對于大的集群，做多租戶隔離，防止業(yè)務之間相互影響。出于成本，還會考慮冷熱存儲。

易用方面，繼續(xù)提升OLAP平臺化的能力。

高效方面，緊跟Doris社區(qū)，嘗試更多的應用場景，比如2.0版本提供的高并發(fā)點差的能力，以及文本搜索代替ES和聯(lián)邦查詢的能力。