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

1、背景

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

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

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

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

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

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

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

2、Doris業(yè)務(wù)介紹

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

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

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

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

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

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

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

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

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

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

1、案例

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

案例一：查詢性能問題

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

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

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

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

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

案例四：版本升級問題

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

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

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

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

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

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

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

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

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

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

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

4、容量規(guī)劃

（1）容量梳理

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

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

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

通過對機(jī)器級別的一些指標(biāo)，例如磁盤容量、CPU、內(nèi)存，以及服務(wù)指標(biāo)，例如任務(wù)隊(duì)列，分為一級指標(biāo)和二級指標(biāo)，設(shè)定一些閾值，評估當(dāng)前集群是否處于一個健康水位，從而判斷集群是否需要擴(kuò)容。

5、高可用能力

（1）服務(wù)高可用

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

（2）鏈路高可用

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

6、自動化能力

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

7、其他保障能力

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

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

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

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

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

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

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

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

1、Doris業(yè)務(wù)準(zhǔn)入規(guī)范

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

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

2、Doris使用規(guī)范

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

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

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

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

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

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

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

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

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

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

四、總結(jié)與規(guī)劃

1、總結(jié)

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

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

2、規(guī)劃

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

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

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