騰訊面試：介紹一下 Doris 問題排查思路，有沒有總結(jié)過相關(guān)文檔？
Apache Doris 作為一款高性能的 MPP 分析型數(shù)據(jù)庫，在數(shù)據(jù)處理和分析領(lǐng)域得到了廣泛應(yīng)用。然而，在使用過程中難免會遇到各種問題，如查詢性能問題、數(shù)據(jù)導(dǎo)入問題、數(shù)據(jù)副本異常等。
本方案旨在詳細(xì)介紹 Doris 常見問題的排查方法和解決方案，幫助用戶快速定位和解決問題，確保 Doris 系統(tǒng)的穩(wěn)定運(yùn)行。
一、常見問題分類及排查方法
1. 查詢性能問題
(1) 表現(xiàn)及原因
在 Doris 執(zhí)行查詢時(shí)，可能會遇到查詢性能未達(dá)預(yù)期的情況，如查詢速度慢、資源不足導(dǎo)致查詢失敗等。可能的原因包括 SQL 任務(wù)過大、數(shù)據(jù)分布不均、系統(tǒng)資源配置不足、索引未正確使用等。
(2) 排查步驟
- 獲取 Profile：通過 Profile 可以查看查詢的執(zhí)行情況，找出可以優(yōu)化的地方。在不同環(huán)境下獲取 Profile 的方法如下：
- Doris 集群能夠正常訪問：使用請求方式 HTTP://FE_IP:HTTP_PORT GET /API/Profile。開啟 Profile 上報(bào)參數(shù) enable_profile，此參數(shù)為 session 變量，不建議全局開啟。
-- 開啟變量
mysql >set enable_profile =true;
-- 確認(rèn)變量是否正常開啟
mysql >show variables like'%profile%';- 分析 SQL 任務(wù)：檢查 SQL 任務(wù)是否可以進(jìn)行拆分，對于包含大表計(jì)算的任務(wù)，分析是否有分區(qū)設(shè)計(jì)，以更好地利用分區(qū)裁剪能力。
- 檢查數(shù)據(jù)分布：使用 EXPLAIN 語句查看查詢執(zhí)行計(jì)劃，確認(rèn)索引是否被使用。如果數(shù)據(jù)在集群中分布不均，某些節(jié)點(diǎn)可能承擔(dān)過多的計(jì)算任務(wù)，導(dǎo)致整體性能下降。可以重新設(shè)計(jì)分片鍵或調(diào)整數(shù)據(jù)分區(qū)策略。
EXPLAINSELECT*FROM table_name WHERE indexed_column ='value';- 檢查系統(tǒng)資源配置：查看系統(tǒng)的 CPU、內(nèi)存、磁盤 I/O 和網(wǎng)絡(luò)帶寬等資源是否緊張。可以使用系統(tǒng)監(jiān)控工具（如 top、iostat 等）來檢查這些資源的使用情況。
- 調(diào)整查詢參數(shù)：適當(dāng)調(diào)整 Doris 的查詢參數(shù)，例如調(diào)整分片數(shù)或優(yōu)化 Join 操作。
SET query_mem_limit ='8G';
ALTERTABLE table_name SET("num_buckets"=16);2. 數(shù)據(jù)導(dǎo)入問題
(1) 表現(xiàn)及原因
數(shù)據(jù)導(dǎo)入問題包括導(dǎo)入失敗、導(dǎo)入速度慢等。可能的原因有分區(qū)字段問題、數(shù)據(jù)類型不匹配、網(wǎng)絡(luò)問題、資源瓶頸、配置錯(cuò)誤等。
(2) 排查步驟
① Stream Load 導(dǎo)入慢
- 監(jiān)控資源使用情況：確保 BE 的 CPU、內(nèi)存、IO 等資源充足。
- 查看日志：根據(jù) Load ID 和 Txn ID 在 BE.INFO 日志中搜索慢請求，重點(diǎn)查看進(jìn)行輸送的 Coordinator BE。
- 檢查網(wǎng)絡(luò)連通情況：檢查客戶端到 BE 的網(wǎng)絡(luò)連通情況，如實(shí)時(shí) ping 延遲和網(wǎng)絡(luò)帶寬。
- 檢查并發(fā)數(shù)：確認(rèn)導(dǎo)入對應(yīng)的并發(fā)數(shù)是否過高，如果并發(fā)數(shù)超過 HTTP Server 線程數(shù)（默認(rèn)為 48），可能導(dǎo)致接收客戶端數(shù)據(jù)慢。
- 檢查是否觸發(fā)內(nèi)存下刷：通過搜索 BE.INFO 中的 reducing 日志確認(rèn)。
- 檢查是否導(dǎo)入 Mow 表：因 Mow 表需要計(jì)算 delete bitmap，并分析計(jì)算時(shí)間。
② Routine Load 消費(fèi)慢
- 檢查配置：確認(rèn) Routine Load 配置正確。
- 查看任務(wù)狀態(tài)：使用 SHOW ROUTINE LOAD 查看 abortedTaskNum，如果很多表明 Task 一直失敗，需要在 FE 日志中根據(jù) Job ID 查詳細(xì)失敗原因。
- 檢查資源瓶頸：如果配置沒有問題，且 Task 沒有失敗，檢查是否存在資源瓶頸。
- 分析 Kafka 是否慢：可在 BE 日志中搜索 blocking get time(us)，如有顯著高值，表明 Kafka 慢了。
③ Insert Into Select 導(dǎo)入慢
- 確認(rèn)是否為查詢慢導(dǎo)致：利用 SET dry_run_query = true 先運(yùn)行查詢。
- 啟用新最優(yōu)化器：如果是 Doris 2.0 到 2.1.3 之間的版本，設(shè)置 enable_nereids_dml = true，2.1.3 之后默認(rèn)開啟。
- 測試非前移對導(dǎo)入的影響：2.1 以上版本設(shè)置 enable_memtable_on_sink_node = false 進(jìn)行測試。
- 測試關(guān) shuffle 對導(dǎo)入的影響：2.1 以上版本設(shè)置 enable_strict_consistency_dml = false 進(jìn)行測試。
- 調(diào)整并發(fā)數(shù)：Pipeline 模式調(diào)大 parallel_pipeline_task_num 增大并發(fā)；非 Pipeline 模式調(diào)大 parallel_fragment_exec_instance_num 增大并發(fā)。
3. 數(shù)據(jù)副本問題
(1) 表現(xiàn)及原因
查詢時(shí)可能會出現(xiàn)報(bào)錯(cuò)，如 Failed to initialize storage reader, tablet = {tablet_id}. xxx. xxx，原因可能是遷移副本過程丟 version、數(shù)據(jù)導(dǎo)入過程中 be 宕機(jī)等。
(2) 排查步驟
① 問題定位
- 獲取異常 tablet 的詳細(xì)信息：使用 show tablet {tablet_id} 拿到 detail cmd。
show tablet 606202;- 執(zhí)行 detail cmd：找出該 BE 所在的副本(compact status url 中包含有該 BE 的 ip)。
SHOWPROC'/dbs/10113/591325/partitions/606195/591326/606202';- 執(zhí)行 curl 請求：查看該副本的 rowset 和 missing_rowset，重點(diǎn)看 rowset 的最大版本和 missing_rowsets。
curl http://10.xxx:8040/api/compaction/show?tablet_id =606202② 問題處理
確認(rèn)是否自動修復(fù)：由于 Doris 內(nèi)部會自動做數(shù)據(jù)均衡和修復(fù)，先確認(rèn)異常數(shù)據(jù)副本能否自動修復(fù)。如果是多副本，查看是否存在健康副本，將查詢報(bào)錯(cuò)的副本 set bad。
ADMIN SET REPLICA STATUS PROPERTIES ("tablet_id"="7552021","backend_id"="10003","status"="bad");- 重新導(dǎo)數(shù)手動修復(fù)：如果是多個(gè)副本都損壞，并且是分區(qū)表的情況下，可以刪除這個(gè)分區(qū)，然后手動重建這個(gè)分區(qū)，重新導(dǎo)入數(shù)據(jù);如果是非分區(qū)表的情況下，只能刪除這個(gè)表重新導(dǎo)入數(shù)據(jù)。
- 填充空副本進(jìn)行修復(fù)：使用一個(gè)空的 rowset 填充損壞的副本，缺多少個(gè) rowset，就調(diào)用多少次修補(bǔ)的方法。
curl -XPOST"http://10.151.2.29:8040/api/pad_rowset?tablet_id=606202&start_version=35&end_version=35"4. 數(shù)據(jù)均衡問題
(1) 表現(xiàn)及原因
可能出現(xiàn) BE 節(jié)點(diǎn)之間的數(shù)據(jù)不均、單個(gè) BE 節(jié)點(diǎn)上的多個(gè)磁盤之間的數(shù)據(jù)不均、BE 節(jié)點(diǎn)的上線和下線進(jìn)度卡死等情況。原因可能是參數(shù)配置不當(dāng)、長事務(wù)阻塞、副本遷移超時(shí)、版本 BUG 等。
(2) 排查步驟
① 確認(rèn) FE 參數(shù)：使用 admin show frontend config like '%xxxx%' 檢查 FE 的以下參數(shù)是否正確：
- disable_balance = false
- disable_disk_balance = false
- disable_colocate_balance = false
- disable_tablet_scheduler = false
當(dāng) Doris 版本為 2.0.4 之后，對于單副本的數(shù)據(jù)，需要將 enable_disk_balance_for_single_replica 改成 true。
admin set frontend config("enable_disk_balance_for_single_replica"="true");② 均衡狀態(tài)檢查
- 查看當(dāng)前正在執(zhí)行的調(diào)度：如果 running 任務(wù)正常，但是磁盤空間不下降，可能是均衡調(diào)度任務(wù)正常，需要清理下 trash，執(zhí)行 admin clean trash；也可能是均衡調(diào)度異常，查看均衡調(diào)度的歷史信息，查看是否有報(bào)錯(cuò)。
- 查看均衡的歷史記錄信息：根據(jù) Finished 進(jìn)行排序，看是否有大量的 CANCELLED 狀態(tài)。如果有，可以看最左邊的 ErrMsg 日志，或者通過搜索 Master FE 的日志 grep "tablet schedule|TableSch" fe.log|grep tablet_id。
- 均衡權(quán)重檢查：可以通過 FE 的 8030 端口對應(yīng)的 web 界面（點(diǎn)擊 System=>cluster_balance）或 SQL 語句 show proc '/cluster_balance/cluster_load_stat/location_default/HDD' 查看。當(dāng) Class 均為 MID 時(shí)，代表當(dāng)前集群的 BE 之間和單個(gè) BE 的磁盤之間數(shù)據(jù)已均衡。
- 均衡任務(wù)執(zhí)行情況檢查
③ 均衡參數(shù)調(diào)優(yōu)
- 數(shù)據(jù)不夠均衡：適當(dāng)調(diào)小 balance_load_score_threshold 參數(shù)，觸發(fā)均衡調(diào)度執(zhí)行；調(diào)整 backend_load_capacity_coeficient 參數(shù)，決定讓磁盤使用率更均衡，還是讓 tablet 數(shù)目更加均衡。
admin set frontend config("balance_load_score_threshold"="xx");
admin set frontend config("backend_load_capacity_coeficient"="xx");- 均衡速度慢：檢查 BE 的 IO 是否很高，通過 `iostat -x 1` 查看讀寫的 IO 延時(shí);調(diào)整均衡的線程數(shù)，如 `be.conf` 中的 `storage_medium_migrate_count` 和 `clone_worker_count`。
5. Compaction 問題
(1) 表現(xiàn)及原因
可能出現(xiàn) compaction score 高、Compaction 失敗等問題，原因包括 compaction 持續(xù)失敗、用戶使用不當(dāng)（如 bucket 數(shù)量設(shè)置不合適）、compaction 策略問題、導(dǎo)入速度超過 compaction 速度等。
(2) 排查步驟
① compaction score 高
- 判斷是否為 compaction 持續(xù)失敗導(dǎo)致：使用 grep ${tablet_id} be.INFO | grep compaction 查看是否有持續(xù)失敗的日志，使用 curl ip:port/api/compaction/show?tablet_id=${tablet_id} 查看 compaction status。
- 檢查用戶使用情況：確認(rèn)建表時(shí) bucket 數(shù)量設(shè)置是否合適。
- 檢查 compaction 策略：通過 curl ip:port/api/compaction/show?tablet_id=${tablet_id} 查看 tablet compaction 上一次執(zhí)行的時(shí)間，使用 grep ${tablet_id} be.INFO | grep compaction 查看該 tablet compaction 執(zhí)行的歷史。如果是策略問題，可手動觸發(fā) compaction。
curl -XPOSThttp://be_host:webserver_port/api/compaction/run?tablet_id = xxxx&compact_type = cumulative- 判斷是否為導(dǎo)入速度超過 compaction 速度：查看 compaction 一段時(shí)間內(nèi)的平均并發(fā)數(shù)，計(jì)算統(tǒng)計(jì)的 clock time，比較實(shí)際并發(fā)和設(shè)置的并發(fā)限制。如果 CPU 負(fù)載不高，可調(diào)整 compaction 并發(fā)配置;如果 CPU 負(fù)載比較高，可考慮攢批導(dǎo)入或擴(kuò)容。
② Compaction 失敗：通過 grep compaction be.INFO | grep {tablet_id} 查看 compaction 失敗的具體原因。
二、日志分析
Doris 提供了豐富的日志信息，幫助用戶定位和解決問題。主要日志文件包括：
- FE 日志（fe.log）：記錄前端節(jié)點(diǎn)的運(yùn)行信息和錯(cuò)誤，可用于排查 FE 相關(guān)的問題，如查詢計(jì)劃生成、元數(shù)據(jù)管理等。
- BE 日志（be.INFO）：記錄后端節(jié)點(diǎn)的運(yùn)行信息和錯(cuò)誤，可用于排查 BE 相關(guān)的問題，如數(shù)據(jù)存儲、計(jì)算、導(dǎo)入等。
- Audit 日志：記錄用戶的操作日志，可用于審計(jì)和追蹤用戶的操作。
通過分析日志文件，用戶可以了解集群的運(yùn)行狀態(tài)，發(fā)現(xiàn)異常情況，并采取相應(yīng)的措施解決問題。例如，在排查查詢性能問題時(shí)，可以查看 FE 日志中是否有查詢超時(shí)、資源不足等信息；在排查數(shù)據(jù)導(dǎo)入問題時(shí)，可以查看 BE 日志中是否有導(dǎo)入失敗、寫入錯(cuò)誤等信息。
三、監(jiān)控與預(yù)警
1. 監(jiān)控指標(biāo)
- 系統(tǒng)指標(biāo)：如集群負(fù)載、CPU 使用率、內(nèi)存使用率、磁盤 IO 等。
- 查詢指標(biāo)：如查詢數(shù)量、查詢延遲、查詢錯(cuò)誤等。
- 存儲指標(biāo)：如數(shù)據(jù)大小、數(shù)據(jù)壓縮率、數(shù)據(jù)分布等。
2. 監(jiān)控工具
Doris 監(jiān)控系統(tǒng)：Doris 數(shù)據(jù)庫內(nèi)置了完善的監(jiān)控系統(tǒng)，提供豐富的監(jiān)控指標(biāo)和圖表，幫助用戶實(shí)時(shí)了解集群的運(yùn)行狀態(tài)和性能表現(xiàn)。
第三方監(jiān)控工具：如 Prometheus、Grafana 等，可提供更豐富的監(jiān)控指標(biāo)和可視化功能，幫助用戶深入分析集群性能。
3. 預(yù)警設(shè)置
根據(jù)監(jiān)控指標(biāo)設(shè)置合理的預(yù)警閾值，當(dāng)指標(biāo)超過閾值時(shí)及時(shí)發(fā)出預(yù)警，以便用戶及時(shí)處理問題。例如，設(shè)置 CPU 使用率超過 80% 時(shí)發(fā)出預(yù)警，提醒用戶檢查系統(tǒng)資源使用情況。
Doris 問題排查需要綜合考慮多個(gè)方面，包括查詢性能、數(shù)據(jù)導(dǎo)入、數(shù)據(jù)副本、數(shù)據(jù)均衡、連接等問題。
