凌晨?jī)牲c(diǎn)我盯著屏幕上那行“Column order_id cannot be resolved”的報(bào)錯(cuò)Presto集群的元數(shù)據(jù)緩存又沒跟上。那一刻我決定下一套報(bào)表平臺(tái)直接搭在Doris上。如果你也在Presto和Doris之間舉棋不定或者正準(zhǔn)備做Doris安裝部署和集群部署這篇內(nèi)容可以幫你少走不少彎路。我會(huì)從單機(jī)跑起來開始一直講到生產(chǎn)集群的規(guī)劃、遷移SQL時(shí)遇到的“missing”問題以及運(yùn)行半年后沉淀下來的調(diào)優(yōu)清單。1. 先從一次“missing”報(bào)錯(cuò)說起為什么我不再讓Presto跑核心報(bào)表1.1 一次凌晨報(bào)表任務(wù)的完整排查鏈路那是一個(gè)常規(guī)的日?qǐng)?bào)任務(wù)凌晨?jī)牲c(diǎn)由Presto集群調(diào)度執(zhí)行。SQL本身不復(fù)雜從一張訂單明細(xì)表里按城市分組統(tǒng)計(jì)GMV關(guān)聯(lián)一張用戶維度表取注冊(cè)時(shí)間。問題出在關(guān)聯(lián)之后Presto報(bào)了一個(gè)讓我當(dāng)時(shí)很頭疼的錯(cuò)誤——Column order_id cannot be resolved。我當(dāng)時(shí)的排查鏈路是這樣的第一步檢查SQL文本。SELECT里確實(shí)沒有引用order_id誤寫不成立。第二步單獨(dú)查字段。SELECT order_id FROM 訂單表 LIMIT 1能跑通說明底層表結(jié)構(gòu)里有這一列。第三步懷疑是表結(jié)構(gòu)變更。去查元數(shù)據(jù)管理服務(wù)發(fā)現(xiàn)這張表在凌晨一點(diǎn)多剛做過一次schema更新新增了一個(gè)字段而Presto連接器緩存的元數(shù)據(jù)沒有及時(shí)刷新。第四步在Presto端刷新元數(shù)據(jù)緩存重新執(zhí)行任務(wù)恢復(fù)。整個(gè)過程花了大概四十分鐘。問題本身不復(fù)雜但這類“元數(shù)據(jù)不同步導(dǎo)致的missing”在Presto聯(lián)邦查詢架構(gòu)里非常折磨人查詢引擎、元數(shù)據(jù)服務(wù)、底層存儲(chǔ)是三個(gè)獨(dú)立的系統(tǒng)任何一個(gè)環(huán)節(jié)緩存滯后你都會(huì)看到莫名其妙的列或表解析失敗。后來我把同一套報(bào)表遷到了Doris上。同樣的SQL在Doris里直接跑通不會(huì)再出現(xiàn)“某個(gè)列突然消失”的情況。因?yàn)镈oris是存儲(chǔ)與計(jì)算一體的OLAP數(shù)據(jù)庫元數(shù)據(jù)和數(shù)據(jù)在同一個(gè)集群里建表、刪列、查詢走的是同一套MySQL協(xié)議入口不存在連接器緩存漂移的問題。1.2 Doris的定位它和Presto、ClickHouse的關(guān)鍵差異很多人把Doris和Presto放在同一個(gè)籃子里比較其實(shí)它們是兩種不同的東西。Presto是一個(gè)分布式SQL查詢引擎本身不存數(shù)據(jù)。它通過連接器去讀Hive、HDFS、S3、MySQL等各種數(shù)據(jù)源優(yōu)勢(shì)是靈活適合做聯(lián)邦查詢、數(shù)據(jù)湖分析。劣勢(shì)也很明顯沒有自己的存儲(chǔ)查詢性能取決于下游數(shù)據(jù)源的組織方式元數(shù)據(jù)鏈路長(zhǎng)容易出現(xiàn)前面說的“missing”類問題。Doris則是完整的MPP分析型數(shù)據(jù)庫。它有自己的列式存儲(chǔ)引擎、向量化執(zhí)行引擎、CBO優(yōu)化器同時(shí)兼容MySQL協(xié)議。數(shù)據(jù)導(dǎo)入之后查詢直接在Doris內(nèi)部完成不需要跨系統(tǒng)拉數(shù)據(jù)。ClickHouse是另一個(gè)常被拿來對(duì)比的列存數(shù)據(jù)庫。ClickHouse單機(jī)查詢性能非常強(qiáng)但在集群運(yùn)維、join能力、精確去重這些方面團(tuán)隊(duì)需要付出的精力更多。Doris在分布式j(luò)oin、高并發(fā)點(diǎn)查、多表關(guān)聯(lián)這些場(chǎng)景上更均衡一些而且建表、導(dǎo)入、權(quán)限管理都做得比較完善。我用一張表把三者的差異理順維度PrestoDorisClickHouse是否自帶存儲(chǔ)否依賴外部數(shù)據(jù)源是列式存儲(chǔ)是列式存儲(chǔ)元數(shù)據(jù)一致性多系統(tǒng)協(xié)同易緩存延遲存儲(chǔ)計(jì)算一體一致性高存儲(chǔ)計(jì)算一體一致性較高SQL兼容ANSI SQL但分?jǐn)?shù)據(jù)源方言MySQL協(xié)議習(xí)慣成本低SQL方言較特殊適用場(chǎng)景數(shù)據(jù)湖、聯(lián)邦查詢BI報(bào)表、多維分析、明細(xì)查詢單機(jī)超高性能查詢、寬表聚合集群運(yùn)維復(fù)雜度中中低中高尤其副本和分布式DDL一句話總結(jié)如果你需要的是“一個(gè)能穩(wěn)定跑報(bào)表、少出幺蛾子的分析型數(shù)據(jù)庫”Doris是很順手的選擇。1.3 我在什么場(chǎng)景下會(huì)堅(jiān)定選DorisDoris官方定位是“面向分析的高性能分布式數(shù)據(jù)庫”我用了半年之后把它適用場(chǎng)景歸納為三類BI報(bào)表與看板。MySQL協(xié)議對(duì)數(shù)據(jù)部門和后端工程師太友好了任何語言連MySQL的方式都能直接連Doris不用額外寫驅(qū)動(dòng)。明細(xì)查詢與聚合混合負(fù)載。既能用主鍵查單條記錄也能跑大范圍聚合不需要搭兩套系統(tǒng)。需要精確去重和多表join的統(tǒng)計(jì)場(chǎng)景。比如UV統(tǒng)計(jì)、GMV匯總、漏斗分析Doris在這類場(chǎng)景的穩(wěn)定性和性能都比Presto更可控。另外值得一提的是Doris的導(dǎo)入生態(tài)支持Stream Load、Broker Load、Routine Load、Insert Into等多種方式和Kafka、HDFS、Flink、Spark的集成都比較成熟。對(duì)于中小團(tuán)隊(duì)來說一套Doris集群可以替代“Presto Hive 一套OLAP庫”的組合架構(gòu)簡(jiǎn)單很多維護(hù)成本也低很多。2. 單機(jī)版先跑起來Doris安裝部署從下載到建表2.1 下載與版本選擇LTS優(yōu)先別追新我第一次部署時(shí)直接選了當(dāng)時(shí)最新的版本結(jié)果被一些小問題折騰得夠嗆。后來學(xué)乖了優(yōu)先選LTS版本或已發(fā)布較久的stable版本不建議拿剛發(fā)的小版本直接上生產(chǎn)。從Doris官網(wǎng)下載二進(jìn)制安裝包時(shí)注意確認(rèn)操作系統(tǒng)和CPU架構(gòu)。官方提供x64和ARM的包選錯(cuò)了解壓?jiǎn)?dòng)后會(huì)遇到非法指令這類問題。我用的版本文件類似apache-doris-2.1.x-bin-x64.tar.gz里面已經(jīng)包含了FE、BE、Broker等組件不需要自己編譯。非特殊情況不要自己去從源碼編譯費(fèi)時(shí)費(fèi)力不說還容易缺依賴。下載到服務(wù)器后解壓到統(tǒng)一目錄比如/opt/apache-doris/然后分別進(jìn)到fe和be子目錄做配置和啟動(dòng)。2.2 部署前的系統(tǒng)環(huán)境準(zhǔn)備這幾項(xiàng)不做后面全是坑Doris對(duì)系統(tǒng)環(huán)境的要求不算苛刻但有幾項(xiàng)必須提前處理否則啟動(dòng)過程會(huì)非常痛苦。JDK版本FE依賴Java運(yùn)行環(huán)境建議JDK 8或JDK 11。BE是C實(shí)現(xiàn)不需要Java。文件句柄數(shù)BE需要打開大量文件默認(rèn)的ulimit -n往往不夠。建議設(shè)置成65535以上順便把max user processes也調(diào)大。swap策略建議關(guān)閉或盡量降低swap使用。分析型查詢對(duì)延遲敏感一旦發(fā)生內(nèi)存換頁查詢耗時(shí)可能瞬間翻倍。時(shí)鐘同步集群內(nèi)所有節(jié)點(diǎn)要保持時(shí)間同步建議部署NTP服務(wù)。時(shí)間偏移會(huì)導(dǎo)致BE心跳異常、元數(shù)據(jù)判斷出錯(cuò)。我部署時(shí)的經(jīng)驗(yàn)是先把這些系統(tǒng)參數(shù)寫入/etc/security/limits.conf再重啟服務(wù)器或者至少重啟登錄會(huì)話確保生效。別省這一步否則后面排查“BE狀態(tài)異?！睍?huì)花掉幾個(gè)小時(shí)。2.3 啟動(dòng)FE與BE偽分布式跑通只需幾分鐘單機(jī)部署時(shí)FE和BE可以放在同一臺(tái)機(jī)器上。雖然生產(chǎn)環(huán)境不推薦這樣但用于學(xué)習(xí)、功能驗(yàn)證、給團(tuán)隊(duì)做Demo完全夠用。啟動(dòng)FEcd /opt/apache-doris/fe ./bin/start_fe.sh --daemonFE默認(rèn)端口是8030HTTP、9030MySQL協(xié)議、9010edit log、9020Thrift RPC。這一步如果用默認(rèn)端口不用改配置就能直接啟動(dòng)成功。接著用MySQL客戶端連接FEmysql -h127.0.0.1 -P9030 -uroot看到Welcome to the MySQL monitor說明FE已經(jīng)起來了。接下來啟動(dòng)BEcd /opt/apache-doris/be ./bin/start_be.sh --daemonBE啟動(dòng)后不會(huì)自動(dòng)注冊(cè)到FE需要手動(dòng)添加一次。在MySQL客戶端里執(zhí)行ALTER SYSTEM ADD BACKEND 127.0.0.1:9050;然后看一下BE狀態(tài)SHOW PROC /backends;重點(diǎn)看最后一列的Alive字段如果顯示true單機(jī)版就已經(jīng)跑通了。提示BE的9050是心跳端口不是數(shù)據(jù)端口。添加BE時(shí)填的IP和端口必須和BE節(jié)點(diǎn)自己上報(bào)的地址一致否則會(huì)報(bào)“backend not found”之類的錯(cuò)誤。2.4 建表與導(dǎo)入第一份數(shù)據(jù)先跑通一個(gè)完整流程單機(jī)版跑起來之后我建議立刻建一張表、導(dǎo)一份數(shù)據(jù)進(jìn)去把整個(gè)鏈路走一遍。這一步能幫你快速驗(yàn)證部署是否正常也能讓你直觀感受到Doris的SQL習(xí)慣。建庫建表CREATE DATABASE test_db; CREATE TABLE test_db.orders ( order_id BIGINT NOT NULL, user_id BIGINT NOT NULL, city VARCHAR(32), amount DECIMAL(12, 2), status TINYINT, order_time DATETIME ) DUPLICATE KEY(order_id) PARTITION BY RANGE(order_time) () DISTRIBUTED BY HASH(user_id) BUCKETS 12 PROPERTIES ( replication_num 1 );先說明一下這個(gè)建表語句里幾個(gè)關(guān)鍵詞的含義DUPLICATE KEY表示明細(xì)模型適合保存原始訂單數(shù)據(jù)PARTITION BY RANGE按時(shí)間分區(qū)方便后續(xù)按日期裁剪DISTRIBUTED BY HASH按用戶ID分桶確保同一個(gè)用戶的數(shù)據(jù)落到同一個(gè)分桶里join和聚合時(shí)可以減少跨節(jié)點(diǎn)數(shù)據(jù)移動(dòng)。單機(jī)版replication_num設(shè)為1即可生產(chǎn)環(huán)境通常設(shè)為2或3。導(dǎo)入數(shù)據(jù)使用Stream Load方式這是Doris最常用的本地導(dǎo)入方式curl --location-trusted -u root: \ -H label:test_order_001 \ -H column_separator:, \ -H format:csv_with_names \ -H max_filter_ratio:0.05 \ -T /data/orders.csv \ http://127.0.0.1:8030/api/test_db/orders/_stream_loadlabel是導(dǎo)入事務(wù)的唯一標(biāo)識(shí)同一張表里不能重復(fù)。max_filter_ratio允許一定比例的錯(cuò)誤數(shù)據(jù)通過避免因?yàn)閭€(gè)別臟數(shù)據(jù)導(dǎo)致整個(gè)文件導(dǎo)入失敗。2.5 單機(jī)環(huán)境必須驗(yàn)證的幾個(gè)點(diǎn)部署完成不等于萬事大吉。我每次搭完環(huán)境都會(huì)做一組“自檢清單”大概十幾分鐘能省掉后面很多排查時(shí)間看FE和BE日志。FE日志在fe/log/fe.logBE日志在be/log/be.INFO啟動(dòng)報(bào)錯(cuò)基本都會(huì)留在這里。執(zhí)行SHOW PROC /backends確認(rèn)所有BE都是Alive狀態(tài)。執(zhí)行SHOW TABLET FROM test_db.orders查看副本狀態(tài)正常應(yīng)該是health為true。跑一條簡(jiǎn)單查詢SELECT city, SUM(amount) FROM test_db.orders GROUP BY city確認(rèn)向量化執(zhí)行沒有報(bào)錯(cuò)。用EXPLAIN SELECT ...看一眼執(zhí)行計(jì)劃確認(rèn)分區(qū)裁剪和分桶裁剪生效而不是全表掃描。這套自檢流程我后來在每一套集群上線前都會(huì)執(zhí)行一遍比直接跑業(yè)務(wù)SQL更容易暴露底層問題。3. 上生產(chǎn)前的集群規(guī)劃FE與BE的角色分工和部署細(xì)節(jié)3.1 先想清楚要多少臺(tái)機(jī)器很多人部署Doris集群時(shí)第一個(gè)問題就是“要幾臺(tái)機(jī)器”。我給一個(gè)比較務(wù)實(shí)的估算方式。首先要明白FE和BE的定位FE是大腦負(fù)責(zé)元數(shù)據(jù)管理、查詢解析、生成執(zhí)行計(jì)劃BE是肌肉負(fù)責(zé)數(shù)據(jù)存儲(chǔ)和真正的計(jì)算。BE的負(fù)載遠(yuǎn)高于FE所以機(jī)器資源要向BE傾斜。我常用的規(guī)劃思路是數(shù)據(jù)總量在幾十TB以內(nèi)3臺(tái)BE起步每臺(tái)配16核64G或32核128G。FE建議至少3個(gè)節(jié)點(diǎn)組成高可用組。如果只是開發(fā)和測(cè)試環(huán)境用3臺(tái)機(jī)器每臺(tái)上面跑一個(gè)FE加一個(gè)BE勉強(qiáng)能支撐。但生產(chǎn)環(huán)境我不建議把FE和BE混部特別是BE負(fù)載高的場(chǎng)景會(huì)互相影響。磁盤方面BE的數(shù)據(jù)目錄建議使用SSD。Doris的列式存儲(chǔ)和點(diǎn)查場(chǎng)景對(duì)隨機(jī)IO有要求SSD和機(jī)械盤的查詢時(shí)延差距非常明顯。同時(shí)要為BE預(yù)留至少20%的空余磁盤否則compaction和導(dǎo)入會(huì)撐不住。3.2 FE集群Follower、Observer與元數(shù)據(jù)一致性FE有兩種角色Follower和Observer。Follower參與元數(shù)據(jù)選舉Observer只提供查詢服務(wù)不參與選舉。生產(chǎn)中通常部署1個(gè)Follower作為主節(jié)點(diǎn)再加2個(gè)Follower組成高可用如果讀壓力大再加Observer擴(kuò)展。在已啟動(dòng)的Master FE上執(zhí)行ALTER SYSTEM ADD FOLLOWER fe2_host:9010; ALTER SYSTEM ADD OBSERVER fe3_host:9010;然后在新節(jié)點(diǎn)的fe/conf/fe.conf里保證meta_dir配置一致執(zhí)行啟動(dòng)命令時(shí)帶上Master的地址cd /opt/apache-doris/fe ./bin/start_fe.sh --helper master_host:9010 --daemon這里有個(gè)關(guān)鍵點(diǎn)FE的元數(shù)據(jù)是極其重要的資產(chǎn)。整個(gè)集群的庫表結(jié)構(gòu)、分區(qū)分桶、副本分布都記錄在meta_dir里建議把meta目錄放到獨(dú)立磁盤上并定期備份。我第一次升級(jí)集群時(shí)因?yàn)槭韬鯢E元數(shù)據(jù)所在磁盤滿掉導(dǎo)致整個(gè)集群短暫不可用從那之后我把meta目錄的磁盤監(jiān)控提到了最高優(yōu)先級(jí)。3.3 BE的擴(kuò)容與副本重新平衡往集群里加BE很簡(jiǎn)單ALTER SYSTEM ADD BACKEND be2_host:9050;加完之后Doris會(huì)自動(dòng)進(jìn)行tablet的負(fù)載均衡把一部分?jǐn)?shù)據(jù)從舊的BE挪到新的BE上。觀察進(jìn)度可以用SHOW PROC /cluster_balance;這個(gè)表里能看到tablet在BE之間的移動(dòng)狀態(tài)。剛掛上新的BE時(shí)你會(huì)發(fā)現(xiàn)集群性能沒有立刻提升反而可能因?yàn)閿?shù)據(jù)搬遷占用IO而輕微下降這是正?，F(xiàn)象等均衡完成后才會(huì)整體變好。我踩過的一個(gè)坑是擴(kuò)容前沒有注意磁盤容量差異。BE節(jié)點(diǎn)之間磁盤大小不一樣時(shí)Doris按容量做均衡的效果會(huì)打折扣容易出現(xiàn)某個(gè)大磁盤的BE還是偏空閑小磁盤的BE已經(jīng)快滿了。所以規(guī)劃BE機(jī)器時(shí)盡量保持磁盤規(guī)格一致。3.4 端口清單與網(wǎng)絡(luò)配置的避坑指南多節(jié)點(diǎn)部署時(shí)網(wǎng)絡(luò)端口放通是第一步。我以默認(rèn)配置為例列一下需要放通的端口組件端口用途FE8030FE HTTP服務(wù)用于頁面和導(dǎo)入FE9030MySQL協(xié)議連接端口FE9010FE節(jié)點(diǎn)間edit log通信FE9020FE Thrift RPCBE9050BE心跳上報(bào)BE9060BE Thrift RPCBE8040BE HTTP服務(wù)BE8060BRPC服務(wù)具體端口可能隨版本微調(diào)部署前以官方文檔對(duì)應(yīng)版本的參數(shù)說明為準(zhǔn)。但要注意FE與FE之間、FE與BE之間、BE與BE之間的網(wǎng)絡(luò)必須全通不能只放通客戶端到FE的端口。否則你會(huì)遇到“BE狀態(tài)正常但查詢報(bào)錯(cuò)”這種非常隱晦的問題。3.5 部署過程中最容易踩到的三個(gè)坑我在多次集群部署里踩過的坑大致可以歸成三類分享出來希望大家繞開。第一內(nèi)存參數(shù)沒有顯式設(shè)置。BE默認(rèn)的mem_limit可能高達(dá)機(jī)器物理內(nèi)存的90%這個(gè)值在生產(chǎn)環(huán)境偏大。操作系統(tǒng)需要留內(nèi)存給page cacheBE和其他進(jìn)程也需要呼吸空間。我一般顯式設(shè)置成物理內(nèi)存的70%-80%再根據(jù)負(fù)載微調(diào)。第二FE和BE混布導(dǎo)致資源爭(zhēng)搶。單機(jī)測(cè)試沒問題但生產(chǎn)環(huán)境如果BE在跑大查詢FE的響應(yīng)會(huì)明顯變慢元數(shù)據(jù)操作都跟著受影響。有條件的話FE用獨(dú)立機(jī)器哪怕配置低一點(diǎn)也沒關(guān)系。第三BE磁盤寫滿導(dǎo)致節(jié)點(diǎn)自動(dòng)下線。Doris檢測(cè)到BE數(shù)據(jù)目錄不可寫或剩余空間不足時(shí)可能主動(dòng)把BE標(biāo)記為不可用。我見過太多因?yàn)槿罩緵]有清理、數(shù)據(jù)目錄被灌滿導(dǎo)致的“集群突然掛掉”事件。上線前務(wù)必給BE的數(shù)據(jù)目錄和日志目錄配好監(jiān)控告警。4. 遷移SQL到Doris被Presto慣壞之后我踩過的“missing”坑4.1 先說結(jié)論P(yáng)resto里報(bào)“missing”到底是怎么回事“presto doris錯(cuò)誤的missing”這個(gè)關(guān)鍵詞不是第一次出現(xiàn)在我的視野里。用Presto讀Doris的場(chǎng)景最常見的報(bào)錯(cuò)有兩種Column xxx cannot be resolved和Table xxx not found。我和團(tuán)隊(duì)排查過多個(gè)這樣的問題根因基本集中在下面三類。第一類是元數(shù)據(jù)緩存不一致。Presto通過連接器訪問Doris時(shí)會(huì)把表的schema緩存到連接器側(cè)。如果Doris集群里這張表后續(xù)加了列、刪了列或改了類型而Presto側(cè)沒有刷新緩存就會(huì)報(bào)“列無法解析”。這和我們凌晨那次故障屬于同一類和Doris自身沒關(guān)系純粹是聯(lián)邦查詢架構(gòu)的固有缺陷。第二類是大小寫問題。Presto默認(rèn)會(huì)把SQL里未加引號(hào)的標(biāo)識(shí)符轉(zhuǎn)成小寫而Doris雖然兼容MySQL協(xié)議但如果你建庫建表時(shí)用了大寫字母兩邊對(duì)不上就會(huì)查不到。解決方案是統(tǒng)一建表規(guī)范要么全部小寫要么在SQL里用反引號(hào)強(qiáng)制大小寫。第三類是驅(qū)動(dòng)和字段類型映射問題。老版本的Doris JDBC驅(qū)動(dòng)對(duì)部分新數(shù)據(jù)類型支持不全或者Presto的Doris連接器對(duì)DECIMAL、DATETIME這類類型的映射不完整結(jié)果表現(xiàn)在查詢時(shí)就變成“某列不存在”。升級(jí)驅(qū)動(dòng)版本通常能解決。我還想強(qiáng)調(diào)一個(gè)很多人忽略的點(diǎn)Presto里報(bào)missing的SQL直接拿到Doris執(zhí)行往往根本不會(huì)報(bào)錯(cuò)。因?yàn)镈oris是自己存數(shù)據(jù)的查詢時(shí)能直接看到真實(shí)的行列結(jié)構(gòu)。所以這類問題最適合的解法就是把這套報(bào)表的查詢從Presto遷到Doris來跑而不是在連接器的糾錯(cuò)上繞圈子。4.2 Doris的SQL寫法與Presto的差異對(duì)照把SQL從Presto遷到Doris語法層面整體平滑但還是有幾個(gè)需要手工調(diào)整的地方。我整理了一份常用對(duì)照表功能Presto寫法Doris寫法時(shí)間截?cái)郿ate_trunc(month, ts)date_trunc(ts, month)2.1版本兩種皆可字符串聚合array_join(array_agg(x), ,)或string_agggroup_concat(x, ,)模糊匹配LIKE同MySQL支持LIKE近似去重approx_distinct(x)approx_count_distinct(x)精確去重用COUNT(DISTINCT x)JSON數(shù)組展開cross join unnest(json_array)LATERAL VIEW explode_json_array(...)列名轉(zhuǎn)義雙引號(hào)反引號(hào)比較常見的坑是date_trunc的參數(shù)順序。Presto習(xí)慣把時(shí)間單位放前面Doris習(xí)慣把時(shí)間字段放前面。兩種都寫錯(cuò)過后來我的做法是統(tǒng)一在Doris里使用DATE_TRUNC(ts, month)這種順序并在SQL注釋里標(biāo)記清楚。另外Doris對(duì)反引號(hào)的支持更接近MySQL。如果字段名恰好是保留字比如rank、status、desc記得加反引號(hào)否則查詢可能直接執(zhí)行失敗。4.3 遷移前必做的三件事把大批SQL從Presto遷到Doris之前我強(qiáng)烈建議先做三件事別急著直接切流。第一用真實(shí)的統(tǒng)計(jì)SQL跑POC。從業(yè)務(wù)方拿最近一個(gè)月的核心查詢SQL在Doris上跑一遍對(duì)比行數(shù)和指標(biāo)值。哪怕語法沒問題也要確認(rèn)指標(biāo)口徑一致尤其是去重計(jì)數(shù)、金額保留位數(shù)這些容易產(chǎn)生細(xì)微偏差的地方。第二執(zhí)行計(jì)劃校驗(yàn)。對(duì)每個(gè)核心查詢用EXPLAIN看執(zhí)行計(jì)劃確認(rèn)關(guān)聯(lián)順序、分區(qū)裁剪、分桶裁剪都符合預(yù)期。如果發(fā)現(xiàn)某個(gè)大表沒有走分區(qū)裁剪即使查詢能跑通性能和穩(wěn)定性也堪憂。第三壓力測(cè)試。模擬幾個(gè)并發(fā)用戶同時(shí)查報(bào)表場(chǎng)景觀察BE的內(nèi)存占用和查詢耗時(shí)的波動(dòng)。很多遷移后的問題不是單查詢跑不動(dòng)而是并發(fā)上來之后內(nèi)存被打滿觸發(fā)查詢失敗。4.4 遷移后的性能變化一個(gè)報(bào)表任務(wù)從15分鐘到5分鐘說一個(gè)具體的案例。我們有一張20多億行的用戶行為明細(xì)表之前用Presto做UV統(tǒng)計(jì)和漏斗分析。Presto需要掃描整張表并跨節(jié)點(diǎn)shuffle數(shù)據(jù)一個(gè)復(fù)雜的漏斗SQL要跑15分鐘左右而且經(jīng)常遇到資源競(jìng)爭(zhēng)。遷移到Doris后我把表按事件時(shí)間做了分區(qū)把需要高頻聚合的維度建了物化視圖。同樣的SQL在Doris里跑只需要5分鐘左右如果是命中物化視圖的固定指標(biāo)查詢甚至可以壓到10秒以內(nèi)。提速主要來自三方面列式存儲(chǔ)減少無效IO、分區(qū)裁剪縮小掃描范圍、預(yù)聚合避免重復(fù)計(jì)算。當(dāng)然也要客觀說一句Doris不是萬能的。如果你的查詢模式是超大數(shù)據(jù)量上的即席探索性分析或者需要經(jīng)常關(guān)聯(lián)數(shù)據(jù)湖里的非結(jié)構(gòu)化文件Presto的靈活性仍然有優(yōu)勢(shì)。遷移前先想清楚業(yè)務(wù)的核心訴求是“快”還是“靈活”。5. 運(yùn)行半年之后我保留下來的Doris調(diào)優(yōu)清單5.1 表模型選錯(cuò)后面全是被動(dòng)Doris有三種表模型Duplicate、Unique、Aggregate。很多人剛開始建表時(shí)不重視結(jié)果查詢性能差、數(shù)據(jù)更新邏輯不對(duì)回來改表結(jié)構(gòu)成本非常高。我現(xiàn)在的選型邏輯很簡(jiǎn)單保留明細(xì)數(shù)據(jù)且要原始記錄用Duplicate模型。訂單流水、日志明細(xì)這類。有更新需求比如維表、用戶狀態(tài)、訂單狀態(tài)用Unique模型。2.0之后的版本默認(rèn)是Merge-on-Write實(shí)現(xiàn)查詢性能比以前的Merge-on-Read好很多。只關(guān)心聚合結(jié)果用Aggregate模型。比如每天匯總的計(jì)數(shù)、求和。舉個(gè)例子賬單流水表我一開始建成了Unique模型以為按訂單號(hào)更新更安全。后來發(fā)現(xiàn)實(shí)際上沒有更新需求而Unique模型的寫入開銷比Duplicate大查詢也稍慢白白犧牲了性能。改成Duplicate之后同樣規(guī)模的查詢快了不少。5.2 分區(qū)分桶設(shè)計(jì)先按時(shí)間分區(qū)再按維度分桶分區(qū)分桶是Doris調(diào)優(yōu)最值得花時(shí)間的地方。我的通用做法是先按時(shí)間字段做RANGE分區(qū)通常是天或小時(shí)再用業(yè)務(wù)維度做HASH分桶確保同一個(gè)用戶的記錄集中在一個(gè)分桶內(nèi)。分桶數(shù)量的設(shè)置我是按“每個(gè)分桶的數(shù)據(jù)量控制在幾百M(fèi)B左右”來倒推的。分桶太小會(huì)產(chǎn)生大量小文件元數(shù)據(jù)和調(diào)度開銷大分桶太大會(huì)導(dǎo)致單個(gè)桶掃描時(shí)間過長(zhǎng)并行度不夠。一個(gè)大概的經(jīng)驗(yàn)是初期按集群BE數(shù)量的2-4倍設(shè)置分桶數(shù)后續(xù)根據(jù)實(shí)際查詢?cè)僬{(diào)整。如果表有持續(xù)寫入建議開啟動(dòng)態(tài)分區(qū)避免每天手動(dòng)加分區(qū)PROPERTIES ( dynamic_partition.enable true, dynamic_partition.time_unit DAY, dynamic_partition.start -7, dynamic_partition.end 1, dynamic_partition.buckets 12 )start和end控制保留最近多少天的分區(qū)既能滿足報(bào)表查詢又不會(huì)讓分區(qū)數(shù)量無限膨脹。5.3 慢查詢排錯(cuò)EXPLAIN和Profile的配合使用遇到慢查詢我先用EXPLAIN看執(zhí)行計(jì)劃判斷掃描范圍和join策略是否合理。如果處理不了再開啟Profile看更細(xì)粒度的執(zhí)行信息SET is_report_success true;執(zhí)行查詢后在FE的HTTP頁面或者通過API拉取Profile信息。我重點(diǎn)看三個(gè)指標(biāo)ScanBytes掃描了多少數(shù)據(jù)。如果很大說明分區(qū)裁剪或分桶裁剪沒生效。PeakMemory查詢峰值內(nèi)存。如果打滿說明join或聚合在某個(gè)BE上做了大量shuffle。ExchangeBytes節(jié)點(diǎn)間數(shù)據(jù)傳輸量。這個(gè)值越大查詢?cè)铰３Ｒ娫蚴莏oin鍵選擇不當(dāng)導(dǎo)致大量數(shù)據(jù)被shuffle到不同BE。我遇到過最典型的一個(gè)問題大表關(guān)聯(lián)維表維表只有幾十萬行但執(zhí)行計(jì)劃里沒有用Broadcast Join而是走了Shuffle Join結(jié)果每次查詢都要在BE之間傳一大堆數(shù)據(jù)。后來在SQL里加上/* BROADCAST */提示耗時(shí)直接降了一個(gè)數(shù)量級(jí)。5.4 寫入側(cè)Stream Load批量導(dǎo)入和常見報(bào)錯(cuò)Doris的導(dǎo)入能力很強(qiáng)但用不好也會(huì)讓集群難受。Stream Load是我用得最多的導(dǎo)入方式幾個(gè)實(shí)操要點(diǎn)label一定要設(shè)計(jì)好規(guī)則比如源文件日期加批次號(hào)。重復(fù)的label會(huì)直接導(dǎo)入失敗這其實(shí)是保護(hù)機(jī)制不是bug。大批量文件建議拆分單個(gè)文件超過幾GB時(shí)拆成多個(gè)文件并行導(dǎo)入不要硬灌一個(gè)超大的Stream Load任務(wù)。設(shè)置合理的max_filter_ratio。數(shù)據(jù)質(zhì)量沒把握時(shí)允許1%-5%的錯(cuò)誤比例避免整個(gè)批次失敗。但別調(diào)得過大否則臟數(shù)據(jù)混進(jìn)去會(huì)影響統(tǒng)計(jì)結(jié)果。常見的導(dǎo)入錯(cuò)誤里ETL_RUN_FAIL多半是數(shù)據(jù)類型轉(zhuǎn)換不匹配比如字符串字段里混入了非數(shù)字內(nèi)容。COMMIT_FAIL則可能是因?yàn)锽E在提交階段宕機(jī)或網(wǎng)絡(luò)抖動(dòng)重試時(shí)換一個(gè)新label即可。5.5 物化視圖在什么時(shí)候它真的值得建Doris的物化視圖是我最喜歡的特性之一。它本質(zhì)上是讓Doris自動(dòng)維護(hù)一張預(yù)聚合的表查詢時(shí)如果命中物化視圖就直接讀聚合好的數(shù)據(jù)不用重新掃明細(xì)。我建物化視圖的原則是固定的高頻聚合查詢才會(huì)建不確定的探索性查詢不要建。比如“按天統(tǒng)計(jì)各渠道的收入和訂單數(shù)”這種寫死在報(bào)表里的指標(biāo)就非常適合CREATE MATERIALIZED VIEW mv_channel_daily AS SELECT dt, channel, SUM(amount), COUNT(order_id) FROM orders GROUP BY dt, channel;建完之后不需要手動(dòng)管Doris會(huì)在導(dǎo)入時(shí)自動(dòng)更新。查詢時(shí)如果SQL能自動(dòng)匹配到這個(gè)物化視圖執(zhí)行計(jì)劃里會(huì)顯示讀取的是物化視圖而不是原始表。需要注意的是物化視圖會(huì)消耗額外的存儲(chǔ)和導(dǎo)入計(jì)算資源不要建太多每一張都要有明確的業(yè)務(wù)目標(biāo)。5.6 我最后悔沒早點(diǎn)知道的三件事最后分享三條經(jīng)歷半年集群運(yùn)維后最希望第一天就知道的經(jīng)驗(yàn)。第一compaction參數(shù)不要頻繁亂調(diào)。新用戶看到Doris里compaction相關(guān)配置容易手癢我一開始也調(diào)過結(jié)果因?yàn)閏umulative compaction策略改得不合理導(dǎo)入后數(shù)據(jù)遲遲沒有合并查詢變慢?，F(xiàn)在我只保留默認(rèn)策略只在出現(xiàn)大量小文件時(shí)介入。第二BE之間的網(wǎng)絡(luò)質(zhì)量直接影響查詢穩(wěn)定性。Doris跑高并發(fā)查詢時(shí)BE節(jié)點(diǎn)之間會(huì)有大量shuffle數(shù)據(jù)流。如果某個(gè)BE的網(wǎng)卡有丟包或延遲抖動(dòng)查詢可能整個(gè)失敗。生產(chǎn)環(huán)境盡量讓BE在同一個(gè)機(jī)架或至少同一個(gè)可用區(qū)內(nèi)。第三滾動(dòng)升級(jí)前一定看官方Release Notes。Doris的小版本升級(jí)通?？梢詽L動(dòng)進(jìn)行一個(gè)個(gè)替換BE再更新FE但我遇到過某個(gè)中間版本的行為變化沒有提前看文檔導(dǎo)致升級(jí)后SQL執(zhí)行計(jì)劃變了。升級(jí)前花半小時(shí)讀Release Notes比升級(jí)后排查半天問題有價(jià)值得多。我現(xiàn)在這套生產(chǎn)環(huán)境的BE已經(jīng)跑了快一年沒有重啟FE經(jīng)歷過兩次滾動(dòng)升級(jí)元數(shù)據(jù)沒有出過問題。如果你也在Presto和Doris之間糾結(jié)我的建議很直接不要看評(píng)測(cè)文章拿最近的真實(shí)SQL和真實(shí)數(shù)據(jù)在Doris上做一次完整的POC行不行它自己會(huì)告訴你。