一、背景和挑戰

1、背景

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

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

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

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

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

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

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

2、Doris業務介紹

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

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

3、穩定性挑戰

穩定性方面，當前面臨著兩大挑戰。

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

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

Doris穩定性保障的目標為：

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

二、穩定性能力保障

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

1、案例

穩定性案例分為查詢、導數、數據質量、版本升級、以及業務變更這五類問題。

案例一：查詢性能問題

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

案例二：導數性能問題

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

案例三：數據質量問題

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

案例四：版本升級問題

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

案例五：業務變更問題

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

2、穩定性建設思路

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

3、發現能力

當前Doris監控告警系統以Zabbix作為底座，對Doris服務進行監控和告警。

發現能力主要包含三個維度：

• 表級監控，主要是監控表容量和狀態；
• 任務監控，針對導數任務狀態進行監控；
• 組件監控，針對服務指標（如查詢、導數）、進程和機器指標進行監控。

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

上圖是指標監控的畫面。

4、容量規劃

（1）容量梳理

容量梳理包含業務需求、數據量、硬件資源和集群規模幾大部分。

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

（2）容量監控

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

5、高可用能力

（1）服務高可用

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

（2）鏈路高可用

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

6、自動化能力

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

7、其他保障能力

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

故障快恢復能力：包括分區數據的快速恢復能力，以及tablet狀態恢復能力。

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

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

三、穩定性流程規范

穩定性流程規范最重要的作用是提升系統能力下限，在穩定性保障中是非常重要的一環。我們圍繞著Doris流程的三個階段制定了相應的規范：

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

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

1、Doris業務準入規范

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

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

2、Doris使用規范

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

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

在明確了使用規范，并對業務部分進行宣講后，大大提升了Doris的穩定性。

3、Doris業務變更規范

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

變更規范主要包括四大部分：

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

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

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

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

四、總結與規劃

1、總結

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

穩定性的建設是持續的、成體系的，而非靠運氣。穩定性目標的實現需要業務方的支持，而非單點的突破，比如流程規范、HA能力等等都需要業務方的支持和遵守。

2、規劃

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

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

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