作者：360 數(shù)科 中間件團(tuán)隊

編輯整理：SelectDB

作為以人工智能驅(qū)動的金融科技平臺基茵，360 數(shù)科攜手金融合作伙伴椿访，為尚未享受到普惠金融服務(wù)的優(yōu)質(zhì)用戶提供個性化的互聯(lián)網(wǎng)消費(fèi)金融產(chǎn)品漓拾，致力于成為連接用戶與金融合作伙伴的科技平臺什湘。360 數(shù)科旗下產(chǎn)品主要有 360 借條长赞、360 小微貸、360 分期等闽撤，截止目前得哆，已累計幫助 141 家金融機(jī)構(gòu)為 4300 萬用戶提供授信服務(wù)、為2630萬用戶提供借款服務(wù)哟旗、單季促成交易金額1106.75億元贩据。同時作為國內(nèi)領(lǐng)先的信貸科技服務(wù)品牌，360數(shù)科在三季度累計注冊用戶數(shù)首次突破 2 億闸餐。

業(yè)務(wù)需求

隨著金融科技業(yè)務(wù)的不斷發(fā)展饱亮，對數(shù)據(jù)的安全性、準(zhǔn)確性舍沙、實時性提出了更嚴(yán)格的要求近上，早期 Clickhouse 集群用于分析、標(biāo)簽業(yè)務(wù)場景拂铡，但是存在穩(wěn)定性較低壹无、運(yùn)維復(fù)雜和表關(guān)聯(lián)查詢較慢等問題，除此之外感帅，我們業(yè)務(wù)中有部分報表數(shù)據(jù)分散存儲在各類 DB 中斗锭，這也導(dǎo)致維護(hù)管理復(fù)雜度較高，亟需做出優(yōu)化和重構(gòu)失球。

系統(tǒng)選型及對比

基于以上需求及痛點(diǎn)岖是，我們對實時數(shù)倉的選型目標(biāo)提出了明確的需求，我們希望新的 MPP 數(shù)據(jù)庫具有以下幾個特點(diǎn)：

數(shù)據(jù)寫入性能高实苞，查詢秒級

兼容標(biāo)準(zhǔn)的 SQL 協(xié)議

表關(guān)聯(lián)查詢性能優(yōu)秀

豐富的數(shù)據(jù)模型

運(yùn)維復(fù)雜度低

社區(qū)活躍

對商業(yè)友好豺撑，無法律風(fēng)險

2022年3月開始，我們對符合以上特點(diǎn)的數(shù)據(jù)庫 Apache Doris 展開了為期兩個月的調(diào)研測試黔牵。以下是? Apache Doris 1.1.2 在各個方面的滿足情況前硫。

基于上述情況，我們決定采用 Apache Doris荧止，除了可以滿足上文提到的幾個特點(diǎn)，我們還考慮以下幾個方面：

Clickhouse 由于 Join 查詢限制阶剑、函數(shù)局限性跃巡、數(shù)據(jù)模型局限性（只插入，不更新）牧愁、以及可維護(hù)性較差等原因素邪，更適合日志存儲以及保留當(dāng)前存量業(yè)務(wù)，不滿足我們當(dāng)前的業(yè)務(wù)需求猪半。

目前Apache Doris 社區(qū)活躍兔朦、技術(shù)交流更多偷线，SelelctDB SelectDB 針對社區(qū)有專職的技術(shù)支持團(tuán)隊，在使用過程中遇到問題均能快速得到響應(yīng)解決沽甥。

Apache Doris 風(fēng)險更小声邦，對商業(yè)友好，無法律風(fēng)險摆舟。大數(shù)據(jù)領(lǐng)域 Apache 基金會項目構(gòu)成了事實標(biāo)準(zhǔn)亥曹，在 360 數(shù)科內(nèi)部已有廣泛應(yīng)用，且Apache 開源協(xié)議對商業(yè)友好媳瞪、無法律風(fēng)險，不會有協(xié)議上的顧慮蛇受。

實踐應(yīng)用

總體方案

360 數(shù)科大數(shù)據(jù)平臺（毓數(shù)）提供一站式大數(shù)據(jù)管理厕鹃、開發(fā)、分析服務(wù)熊响，覆蓋大數(shù)據(jù)資產(chǎn)管理、數(shù)據(jù)開發(fā)及任務(wù)調(diào)度秸弛、自助分析及可視化、統(tǒng)一指標(biāo)管理等多個數(shù)據(jù)生命周期流程递览。在整個 OLAP 中瞳腌，目前 Apache Doris 主要運(yùn)用離線數(shù)倉分析加速绞铃、自助 BI 報表等業(yè)務(wù)場景。

在引入 Doris 后嫂侍，考慮已有數(shù)據(jù)分析業(yè)務(wù)以及數(shù)據(jù)規(guī)模儿捧，Doris 集群將先同步部分業(yè)務(wù)上優(yōu)先級更高的數(shù)據(jù)。通過上述架構(gòu)圖可以看到挑宠，依托 Doris 強(qiáng)大的查詢性能菲盾，我們將把 Doris 架設(shè)在 Hive 數(shù)倉的上層，為特定場景進(jìn)行查詢加速各淀，這樣的架構(gòu)建設(shè)起來成本很低懒鉴，只需要完成數(shù)據(jù)從 Hive 數(shù)倉到 Doris 集群的導(dǎo)入適配，因為 Doris 集群并沒有產(chǎn)生任何新表，可以直接復(fù)用已經(jīng)建設(shè)好的數(shù)據(jù)血緣關(guān)系临谱。

數(shù)據(jù)導(dǎo)入方案璃俗，我們在調(diào)研了 Stream Load 和 Broker Load 之后，從導(dǎo)入性能悉默、開發(fā)成本上進(jìn)行了評估城豁，在導(dǎo)入性能上，Broker Load 要比 Stream Load 略勝一籌麦牺，而在開發(fā)成本上兩種方式并沒有明顯的差異钮蛛。而且對于大表的同步，Broker Load 的導(dǎo)入方式可以做到單表一次導(dǎo)入一個事務(wù)剖膳，而 Stream Load 在單表數(shù)據(jù)量超 10G 時則需要拆分后進(jìn)行數(shù)據(jù)導(dǎo)入魏颓。因此數(shù)據(jù)導(dǎo)入選擇使用 Broker Load 來進(jìn)行。

數(shù)倉即席查詢方案吱晒，我們自行開發(fā)的查詢引擎支持多查詢引擎動態(tài)切換的機(jī)制甸饱，通過識別查詢數(shù)據(jù)的元信息對本次查詢做自動的查詢引擎（Doris/Presto/Spark/Hive）路由和故障切換。

Doris 支持原生 MySql 協(xié)議仑濒，對標(biāo)準(zhǔn) SQL 支持良好，使得 Doris 可以和一些 BI 工具（帆軟驼壶、觀遠(yuǎn)等）無縫結(jié)合热凹，因此單獨(dú)搭建了一個 Doris 報表分析集群作為 BI 工具數(shù)據(jù)源般妙。

應(yīng)用實踐

Doris 對 Hive 數(shù)倉的查詢加速方案

在即席查詢場景中碟渺，傳統(tǒng)的查詢引擎（Hive/Spark/Presto）越來越滿足不了數(shù)據(jù)開發(fā)者苫拍、數(shù)據(jù)分析師對查詢響應(yīng)性能提出的高要求旺隙，動輒幾十秒甚者分鐘級的查詢耗時極大的限制了相關(guān)場景的開發(fā)效率催束。

為提高查詢性能抠刺，我們通過架設(shè)的 Doris 數(shù)倉加速層來縮短查詢耗時速妖，目前我們在不開啟 Doris 緩存、不開啟用物化視圖等優(yōu)化策略的情況下备恤，命中 Doris 即席查詢平均耗時即可從幾分鐘縮短至 5 秒內(nèi)露泊。

未來我們將通過分析相關(guān)查詢的特征惭笑，通過開啟緩存沉噩、創(chuàng)建相關(guān)物化視圖等策略來進(jìn)一步優(yōu)化 Doris 的查詢性能川蒙。

實現(xiàn) Doris 加速的核心是支持查詢引擎動態(tài)切換长已，查詢引擎動態(tài)切換的工作機(jī)制如下：

查詢引擎會及時收集 Hive 和 Doris 的元信息痰哨，包括庫斤斧、表撬讽、表字段游昼、表行數(shù)等信息烘豌，在用戶提交即席查詢請求時，首先會解析出用戶查詢的表靖榕，并按照如下順序判斷：

查詢的表是否已在 Doris 同步

Doris 表和 Hive 表結(jié)構(gòu)是否相同

Doris 表和 Hive 表表行數(shù)是否一致

如果以上要求均被滿足茁计，則會將該查詢路由到 Doris星压，否則會依次按照 Presto娜膘、Spark劲绪、Hive 的順序進(jìn)行路由查詢贾富，當(dāng)查詢出現(xiàn)異常時颤枪，也會按照該順序依次進(jìn)行故障轉(zhuǎn)移畏纲。

慢查詢慢導(dǎo)入分析

對于慢查詢和慢導(dǎo)入盗胀，Doris 提供了完善的 Profile 機(jī)制票灰，在了解相關(guān)技術(shù)細(xì)節(jié)后屑迂，我們在線上集群開啟了 Profile 收集惹盼，通過調(diào)度任務(wù)定時收集慢查詢手报、慢導(dǎo)入的 Profile 信息并落庫。

Doris 提供的 Profile 信息非常詳細(xì)晓淀，例如 OLAP_SCAN_NODE 提供了原始的掃描行數(shù)，各個索引的過濾行數(shù)蜈亩，每個 Instance 的 EXCHANGE_NODE 提供了接收的數(shù)據(jù)總行數(shù)和接收的數(shù)據(jù)量大小稚配。這些信息為查詢調(diào)優(yōu)提供了詳細(xì)的依據(jù)道川，我們在使用過程中針對快速定位查詢性能的瓶頸進(jìn)行了優(yōu)化冒萄，取得了良好的效果尊流。

建表規(guī)范

在我們的使用場景中崖技，有下列類型的表：

pda表：每日全量更新迎献，即每日分區(qū)存儲全量快照數(shù)據(jù)

pdi表： 每日增量更新吁恍，即每日分區(qū)存儲增量數(shù)據(jù)

a表：全量不分區(qū)表

s表：靜態(tài)非每日更新數(shù)據(jù)

由于當(dāng)前 Doris 集群中所有的表都是基于 Hive 數(shù)倉中各層級的表同步而來践盼，因此目前僅使用了 Duplcate 模型和 Unique 模型咕幻，對于 pda肄程、pdi 和 a 表蓝厌，為了降低 Doris 表的分區(qū)數(shù)拓提，減輕 FE 元數(shù)據(jù)管理壓力代态，我們在建 Doris 表時均啟用了根據(jù)日期劃分的動態(tài)分區(qū)特性蹦疑，較久遠(yuǎn)的歷史數(shù)據(jù)我們按年歉摧、月的維度分區(qū)歸檔叁温，近期的數(shù)據(jù)按日膝但、小時分區(qū)锰镀，未來我們計劃通過程序自動識別完成歷史分區(qū)的歸檔合并泳炉。

對于 pda 表使用場景花鹅，pda 表需要每日同步全量數(shù)據(jù)，我們采用了 Duplicate 模型古拴，不考慮使用 Unique 模型數(shù)據(jù)去重的原因是 Doris 的導(dǎo)入模型本身就提供了基于任務(wù) Label 的數(shù)據(jù)一致性保證真友，同步時一次調(diào)度周期的 pda 表的一個分區(qū)的導(dǎo)入任務(wù)能產(chǎn)生唯一且不變的 Label盔然，因此我們可以保證即使錯誤執(zhí)行了多次，該分區(qū)的數(shù)據(jù)仍然不會重復(fù)挺尾。另外遭铺，因為 Duplicate 模型相比于 Unique 模型魂挂，在導(dǎo)入和查詢階段均不會做預(yù)聚合去重锰蓬，所以可以一定程度上加速導(dǎo)入和查詢的性能芹扭。

對于 pdi 表使用場景舱卡，因在實際使用中 pdi 表存在少數(shù)對歷史數(shù)據(jù)的部分更新場景（絕大部分是數(shù)據(jù)更新場景轮锥，基本沒有數(shù)據(jù)刪除場景）舍杜，考慮到 Doris 數(shù)據(jù)表的分區(qū)可用性既绩，我們采用了 Unique 模型饲握，這樣在更新歷史分區(qū)的數(shù)據(jù)時不必做重建分區(qū)操作救欧。

對于 a 表使用場景笆怠，因業(yè)務(wù)上可以接受短時間數(shù)據(jù)不可用情況骑疆，我們啟用了動態(tài)分區(qū)箍铭，在做數(shù)據(jù)導(dǎo)入時，每次導(dǎo)入都會先刪除歷史分區(qū)兽赁，然后將全量數(shù)據(jù)導(dǎo)入今天的分區(qū)內(nèi)刀崖，這樣做的考慮是杜絕重建表操作，且實施成本相對比較低充活，因此我們沒有采取動態(tài)更新視圖綁定當(dāng)日分區(qū)的方案混卵。

在 Doris 之前的版本中幕随，尚未實現(xiàn) Hive 元數(shù)據(jù)變更同步和管理功能赘淮，為了提高效率開發(fā)了 Doris 建表工具梢卸，我們通過選擇和配置數(shù)倉集群、Hive 表名速梗、數(shù)據(jù)模型姻锁、Bucket 數(shù)量等參數(shù)位隶，自動關(guān)聯(lián) Hive 表篮昧，解析表字段并生成對應(yīng)的建表語句笋妥。經(jīng)過與社區(qū)溝通得知酵颁，最近即將發(fā)布的 1.2 新版本中已經(jīng)實現(xiàn) Multi Catalog躏惋，支持 Hive 元數(shù)據(jù)的對接和 Schema 的自動同步簿姨，可以極大程度上減少這一部分的工作扁位。

監(jiān)控體系

當(dāng)前 Doris 集群監(jiān)控體系分為主機(jī)指標(biāo)監(jiān)控告警、日志告警和集群指標(biāo)監(jiān)控告警则酝，總體監(jiān)控體系如下。

主機(jī)指標(biāo)監(jiān)控是基于 Open-Falcon 開發(fā)的監(jiān)控告警平臺爽雄，主要采集 Doris 集群節(jié)點(diǎn)的 CPU挚瘟、IO乘盖、內(nèi)存订框、磁盤等相關(guān)指標(biāo)并進(jìn)行監(jiān)控告警穿扳。

集群指標(biāo)監(jiān)控參考了 Doris 官方文檔提供的基于?Prometheus?和?Grafana?和集群指標(biāo)監(jiān)控方案矛物。

日志告警仍然是基于我們的監(jiān)控告警平臺泽谨，主要用于監(jiān)控 Doris 服務(wù)日志中容易識別但其他監(jiān)控方式成本較高的監(jiān)控骨杂、告警場景搓蚪，是其他兩種監(jiān)控的補(bǔ)充。通過日志監(jiān)控告警丁鹉，我們能夠準(zhǔn)確識別數(shù)據(jù)導(dǎo)入任務(wù)的失敗原因并能進(jìn)行及時的推送通知妒潭。

問題排查和審計日志

為了及時排查一些極端的集群問題，上述針對 Doris 的監(jiān)控體系建設(shè)仍然是不夠的揣钦。為了在集群 BE 出現(xiàn)異常宕機(jī)時快速定位堆棧雳灾，需要在所有的 BE 節(jié)點(diǎn)開啟 Core Dump。除此之外冯凹，審計日志在集群的日常運(yùn)維中也發(fā)揮了重要作用谎亩。

對于 Doris 集群的審計日志收集一般可以通過 2 種方式：

第一種方式是通過日志收集組件、收集各個 FE 節(jié)點(diǎn)上的 fe.audit.log

第二種方式是通過安裝 Doris 提供的 Auditloader 插件（下載 Doris 源碼，該插件在 doris/fe_plugins/auditloader阱持，具體使用文檔可參考官方文檔：審計日志插件）兵罢。

考慮到第二種方式操作更簡單，因此采用此方式進(jìn)行日志采集。不過在使用 Auditloader 插件的過程中东囚，陸續(xù)發(fā)現(xiàn)和修復(fù)了一些插件問題份帐，并向社區(qū)提交了 PR，與此同時，我們定制開發(fā)了內(nèi)部控制臺驮宴，便于查看集群的同步任務(wù)情況落恼，數(shù)據(jù)分布情況以及進(jìn)行審計日志的檢索滋戳。

審計日志為集群 BE 崩潰時具體 SQL 定位娄涩、客戶端訪問統(tǒng)計球恤、查詢 SQL 耗時統(tǒng)計、訪問 SQL 特征分析等提供了詳細(xì)的信息。例如，數(shù)據(jù)開發(fā)曾經(jīng)反饋查詢 Doris SQL 失敗碑诉，檢索日志出現(xiàn)了大量連接數(shù)超限的異常快毛，我們通過審計日志襟衰，迅速定位到了問題原因是由于上游導(dǎo)入工作流 Bug 在短時間內(nèi)創(chuàng)建較多的數(shù)據(jù)庫連接苔悦。另外，對于曾經(jīng)使用的低版本 Doris 出現(xiàn)數(shù)次 BE 異常宕機(jī)問題蜈七，我們通過 gdb 調(diào)試工具定位到崩潰時 SQL 的 query_id 后，配合審計日志也能快速的定位到導(dǎo)致崩潰的具體 SQL。

優(yōu)化實踐

數(shù)據(jù)導(dǎo)入實踐和調(diào)優(yōu)

初期數(shù)據(jù)源主要來自 Hive 數(shù)倉，因此大部分?jǐn)?shù)據(jù)導(dǎo)入以 Broker Load 方式為主。大數(shù)據(jù)平臺自助導(dǎo)入任務(wù)工作流適配了 Doris Broker Load 導(dǎo)入方式，數(shù)據(jù)開發(fā)零代碼——通過簡單的勾選配置即可完成自助的 Doris 數(shù)據(jù)導(dǎo)入工作流創(chuàng)建假夺。

而在 Broker Load 的使用過程中柿扣，我們也陸續(xù)遇到了一些問題，這里拿出幾個典型的問題和一些調(diào)優(yōu)經(jīng)驗來分享埋虹。

在 Broker Load 導(dǎo)入時遇到的問題：

因表分桶數(shù)設(shè)置過少造成 Broker Load 導(dǎo)入失敗，具體表現(xiàn)為導(dǎo)入任務(wù)失敗且異常信息為：

tablet writer write failed, tablet_id=xxx, txn_id=xxx, err=-238

我們推測造成 -238 錯誤的原因可能是分桶設(shè)置太少却桶，接著我們通過 BE 節(jié)點(diǎn)的掛載數(shù)據(jù)來查看單個 Tablet 下的文件大小，我們發(fā)現(xiàn)單個 Tablet 的文件占用空間遠(yuǎn)大于官方推薦的 10GB 上限范圍，這也證明了我們的推測正確蒋院，因此我們通過適當(dāng)提高 Doris 表的分桶數(shù)震肮，使得這個問題有了較大的緩解沦偎。

順便說一下糯耍，如果出現(xiàn) -235（舊版本是-215）異常系任，一般是由于 Compaction 過慢導(dǎo)致 Tablet 版本堆積超過限制挂据，這個時候通過 Grafana 看到 BE Compaction Score 在導(dǎo)入前后有明顯的波動巴柿，而且絕對值很高篷牌。如果遇到此問題可以參閱 ApacheDoris 公眾號文章：Doris 最佳實踐-Compaction調(diào)優(yōu)(3) 對Compaction過程進(jìn)行調(diào)優(yōu)。

因 Hive 表字段變更導(dǎo)致 Broker Load 導(dǎo)入失敾吹俊：

Hive 表在使用過程中會有一些 DDL 的執(zhí)行损痰，從而導(dǎo)致表字段新增显拜，我們數(shù)倉的 Hive 表均使用 ORC 格式存儲爹袁，那么就會導(dǎo)致 Hive 表中部分歷史分區(qū)的 ORC 文件中字段信息缺失（缺失新增字段）守伸，而新分區(qū)的 ORC 文件中字段是正常的，這個時候如果對歷史數(shù)據(jù)重新導(dǎo)入和二，就會有下面的異常信息：

detailMessage: ParseError : Invalid column selected xxx

在閱讀了 Broker Load 相關(guān)代碼后確認(rèn)了問題原因：在一次 Broker Load 導(dǎo)入過程中钳宪，導(dǎo)入任務(wù)的字段解析器會讀取一個 ORC 文件頭解析字段信息，但解析器只會解析一次冒嫡，如果一次導(dǎo)入過程中同時有新拇勃、歷史分區(qū)的 ORC 文件，那么就可能導(dǎo)致任務(wù)失敗孝凌。

修復(fù)的方法也很簡單方咆，只需針對每個 ORC 文件重新解析一次文件頭的字段信息即可。在了解問題原因及分析解決思路后胎许，我們也和社區(qū)的同學(xué)一起修復(fù)了這個問題并提交了相關(guān) PR峻呛。

遇到空 ORC 文件時 Broker Load 導(dǎo)入失斅奘邸：

這個問題的錯誤表現(xiàn)和問題 2 比較類似辜窑，具體原因是 Broker Load 導(dǎo)入過程沒有對 ORC 文件做判空，遇到空 ORC 文件仍會嘗試解析 ORC 文件字段信息導(dǎo)致報錯寨躁，我們把這個問題反饋給社區(qū)后穆碎，社區(qū)的同學(xué)很快修復(fù)了該問題。

Broker Load 導(dǎo)入任務(wù)出現(xiàn) Broker list path exception. path=hdfs:xxx

創(chuàng)建 Broker Load 任務(wù)职恳，使用 Kerberos 認(rèn)證訪問 HDFS 的 Hive 文件導(dǎo)入數(shù)據(jù)所禀，Hive 文件路徑中分區(qū)和下一級目錄使用通配符 *，訪問所有分區(qū)所有文件放钦，任務(wù)提交后隔 40 多秒出現(xiàn)如下的錯誤：

type:ETL_RUN_FAIL; msg:errCode = 2, detailMessage = Broker list path exception. path=hdfs:xxx

在閱讀了 Broker Load 的訪問 HDFS 相關(guān)代碼后確認(rèn)了問題原因色徘，Broker Load 調(diào)用 HDFS 的 LS、DU 方法時會獲取文件目錄信息操禀，由于路徑下的文件過多導(dǎo)致耗時會超過 45 秒褂策，而 Thrift 設(shè)置的 Socket 請求超時默認(rèn)小于 40 秒，所以出現(xiàn)了上述的 RPC 異常颓屑，問題反饋社區(qū)后斤寂，對 FE 增加了配置參數(shù)broker_timeout_ms，設(shè)置為 90 秒后解決問題揪惦。

關(guān)于 Broker Load 的導(dǎo)入性能調(diào)優(yōu)策略

我們針對 Broker Load 導(dǎo)入調(diào)優(yōu)的主要方向在確保 Doris 集群不承壓的情況下盡可能提高導(dǎo)入并發(fā)度遍搞，下面根據(jù) 2 個典型的案例來說明：

部分 pdi/pda 表因為數(shù)據(jù)規(guī)模太大導(dǎo)致全量導(dǎo)入耗時過長（導(dǎo)入數(shù)據(jù)源是 Hive 分區(qū)表）

部分 pdi/pda 表數(shù)據(jù)規(guī)模在 T 級別，在進(jìn)行全量導(dǎo)入時器腋，如果只提交一個 Broker Load Job 溪猿，將因為導(dǎo)入任務(wù)的并發(fā)不夠，導(dǎo)致導(dǎo)入耗時達(dá)到 5-6 小時纫塌。針對此問題再愈，我們可以對導(dǎo)入任務(wù)進(jìn)行 Job 拆分，在大數(shù)據(jù)平臺也適配這種場景护戳，支持任務(wù)的自動拆分和重試機(jī)制翎冲，具體的拆分方式如下圖：

不過要注意的是，拆分后可能會對集群有較高的寫入壓力媳荒，要及時監(jiān)控導(dǎo)入任務(wù)和集群的狀態(tài)抗悍，特別針對 -235 的情況可能需要進(jìn)行 Compaction 調(diào)優(yōu)驹饺。

部分 ads 表因為數(shù)據(jù)規(guī)模太大導(dǎo)致全量導(dǎo)入耗時過長（導(dǎo)入數(shù)據(jù)源是Hive非分區(qū)表）

數(shù)據(jù)開發(fā)對部分報表的同步時效提出了很高的要求，我們在針對性的優(yōu)化表同步時效時缴渊，發(fā)現(xiàn)一些表導(dǎo)入耗時較長赏壹，但通過集群監(jiān)控體系發(fā)現(xiàn)相關(guān)表同步期間，BE衔沼、FE 節(jié)點(diǎn)的 CPU蝌借、內(nèi)存、磁盤 IO 指蚁、網(wǎng)卡 IO 并沒有達(dá)到瓶頸菩佑，集群的 Compaction Score 在此期間也一直穩(wěn)定在低位，且整個同步過程同步任務(wù)均未出現(xiàn)-235凝化、-238等相關(guān)的錯誤稍坯，我們推測瓶頸可能還是在導(dǎo)入任務(wù)的并發(fā)程度上。

因為有些表在 Hive 數(shù)倉是非分區(qū)的表搓劫，所以第 1 種通過劃分分區(qū)范圍拆分多個導(dǎo)入 Job 的方式就行不通了瞧哟，理論上仍然可以通過劃分不同的 HDFS 文件來拆分 Job，但是這種方式在毓數(shù)大數(shù)據(jù)平臺還需要進(jìn)一步去適配枪向，所以我們還是優(yōu)先考慮通過調(diào)整集群配置的方式徹底解決此問題：

首先可以通過適當(dāng)調(diào)高 FE 的max_broker_concurrency去提高 Scan HDFS 文件階段的并發(fā)度（最高調(diào)高至 BE 節(jié)點(diǎn)數(shù)）勤揩，而對于 Table Sink 階段，可通過調(diào)高 FE 的default_load_parallelism（設(shè)置fe.conf秘蛔，可調(diào)整到 BE 節(jié)點(diǎn)數(shù)）和 send_batch_parallelism參數(shù)（ SQL Session 執(zhí)行set global send_batch_parallelism=5或在提交 Broker Load 中的 PROPERTIES 中指定陨亡，最高調(diào)整到 5，如果超過此值缠犀，需要同步調(diào)整 be.conf 的 max_send_batch_parallelism_per_job 參數(shù)）数苫，提高該階段并發(fā)度。通過提高 Broker Load Job 各階段導(dǎo)入的并發(fā)度辨液，相關(guān)報表的同步時效顯著提升虐急，這里我們選取 5 張典型表為例，優(yōu)化前后的同步時效表現(xiàn)如下：

雙機(jī)房容災(zāi)建設(shè)

為了保障 Doris 集群的可用性滔迈，我們需要為 Doris 集群提供雙機(jī)房容災(zāi)能力止吁。Doris 目前雖然可以通過不同的 Tag 將 BE 分組部署在多個機(jī)房，但是無法解決機(jī)房出現(xiàn)問題時的 FE 可用性問題燎悍。經(jīng)過方案調(diào)研分析敬惦，我們決定通過自行開發(fā) Replicator 主從同步插件去實施雙機(jī)房容災(zāi)建設(shè)，具體的架構(gòu)如下：

通過在主集群安裝 Replicator 插件谈山，Replicator 插件會攔截并解析主集群執(zhí)行的全量 SQL俄删，然后經(jīng)過過濾操作，篩選涉及庫、表結(jié)構(gòu)變更和數(shù)據(jù)增畴椰、刪臊诊、改相關(guān)的 SQL，并將相關(guān) SQL（部分 SQL 需要改寫）發(fā)送到備集群進(jìn)行重放斜脂。除此之外抓艳，我們在 Doris 控制臺開發(fā)了 Validator 數(shù)據(jù)校驗程序，定期校驗主備集群間的數(shù)據(jù)結(jié)構(gòu)差異和數(shù)據(jù)差異并上報帚戳，在主集群因各種問題導(dǎo)致不可用時玷或，直接通過切換 DNS 解析地址到備集群 LVS 地址完成主備集群的切換。

總結(jié)規(guī)劃

效果總結(jié)

從 2022 年3月份開始進(jìn)行對實時數(shù)倉溝通進(jìn)行調(diào)研片任，7月份正式上線生產(chǎn)偏友，集群數(shù)據(jù)規(guī)模快速增長蚂踊。目前约谈，生產(chǎn)環(huán)境共有 2 個集群笔宿，數(shù)百張表犁钟，幾十 TB 數(shù)據(jù)，每日有數(shù)百個同步工作流在運(yùn)行泼橘，幾十億規(guī)模的數(shù)據(jù)新增/更新涝动。在此規(guī)模下，Doris 對業(yè)務(wù)支持良好炬灭，穩(wěn)定運(yùn)行醋粟。

1. Doris 集群架構(gòu)清晰簡單，不依賴其他組件重归，數(shù)據(jù)模型簡單米愿，數(shù)據(jù)導(dǎo)入方式多樣化且適配成本很低，使得我們可以快速完成前期的調(diào)研測試并在短時間內(nèi)上線實施鼻吮。

2. Doris 集群作為目前公司 BI 工具的重要數(shù)據(jù)源育苟，承載了相當(dāng)一部分的報表分析業(yè)務(wù)，極大加速了報表分析的時效性椎木。Doris 上線 3+月的時間违柏，已經(jīng)承載了小部分即席查詢場景，大大縮短了相關(guān)查詢的耗時香椎。

3. Doris? 具有完善的監(jiān)控機(jī)制和審計機(jī)制漱竖，極大的降低了我們的運(yùn)維工作

4. Doris 社區(qū)十分活躍，在我們使用 Doris 過程中遇到的一些疑難問題畜伐，官方也可以及時進(jìn)行響應(yīng)馍惹、處理。

未來規(guī)劃

在近期的規(guī)劃中，我們希望 Doris 能支撐更多的業(yè)務(wù)場景万矾、發(fā)揮更大價值肥照，例如基于 Doris 建立實時數(shù)倉、基于 Doris 重構(gòu)用戶行為畫像勤众、Doris HIVE 外表特性等舆绎。同時我們計劃通過分析用戶的查詢 SQL 特征，結(jié)合 Doris 的查詢緩存和物化視圖特性们颜，進(jìn)一步提升查詢效率吕朵。通過開發(fā)集群探查工具，實時探測集群數(shù)據(jù)表的數(shù)據(jù)分布情況窥突，比如 Tablet 有沒有過大努溃，Tablet 數(shù)據(jù)分布是否均勻等，綜合探查集群的運(yùn)行情況并自動給出優(yōu)化建議阻问。

目前我們使用了 Doris 有大半年時間梧税，在這半年期間一直保持和社區(qū)同學(xué)進(jìn)行交流（提交 Issues 和 PRs），非常感謝 SelectDB 團(tuán)隊一直以來對我們的技術(shù)支持称近。最后祝 Apache Doris 越來越好第队，為基礎(chǔ)軟件建設(shè)添磚加瓦。