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

編輯整理：SelectDB

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

業(yè)務需求

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

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

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

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

兼容標準的 SQL 協(xié)議

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

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

運維復雜度低

社區(qū)活躍

對商業(yè)友好，無法律風險

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

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

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

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

Apache Doris 風險更小，對商業(yè)友好，無法律風險。大數(shù)據(jù)領域 Apache 基金會項目構(gòu)成了事實標準，在 360 數(shù)科內(nèi)部已有廣泛應用，且Apache 開源協(xié)議對商業(yè)友好、無法律風險，不會有協(xié)議上的顧慮。

實踐應用

總體方案

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

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

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

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

Doris 支持原生 MySql 協(xié)議，對標準 SQL 支持良好，使得 Doris 可以和一些 BI 工具（帆軟、觀遠等）無縫結(jié)合，因此單獨搭建了一個 Doris 報表分析集群作為 BI 工具數(shù)據(jù)源。

應用實踐

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

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

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

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

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

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

查詢的表是否已在 Doris 同步

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

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

如果以上要求均被滿足，則會將該查詢路由到 Doris，否則會依次按照 Presto、Spark、Hive 的順序進行路由查詢，當查詢出現(xiàn)異常時，也會按照該順序依次進行故障轉(zhuǎn)移。

慢查詢慢導入分析

對于慢查詢和慢導入，Doris 提供了完善的 Profile 機制，在了解相關(guān)技術(shù)細節(jié)后，我們在線上集群開啟了 Profile 收集，通過調(diào)度任務定時收集慢查詢、慢導入的 Profile 信息并落庫。

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

建表規(guī)范

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

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

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

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

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

由于當前 Doris 集群中所有的表都是基于 Hive 數(shù)倉中各層級的表同步而來，因此目前僅使用了 Duplcate 模型和 Unique 模型，對于 pda、pdi 和 a 表，為了降低 Doris 表的分區(qū)數(shù)，減輕 FE 元數(shù)據(jù)管理壓力，我們在建 Doris 表時均啟用了根據(jù)日期劃分的動態(tài)分區(qū)特性，較久遠的歷史數(shù)據(jù)我們按年、月的維度分區(qū)歸檔，近期的數(shù)據(jù)按日、小時分區(qū)，未來我們計劃通過程序自動識別完成歷史分區(qū)的歸檔合并。

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

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

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

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

監(jiān)控體系

當前 Doris 集群監(jiān)控體系分為主機指標監(jiān)控告警、日志告警和集群指標監(jiān)控告警，總體監(jiān)控體系如下。

主機指標監(jiān)控是基于 Open-Falcon 開發(fā)的監(jiān)控告警平臺，主要采集 Doris 集群節(jié)點的 CPU、IO、內(nèi)存、磁盤等相關(guān)指標并進行監(jiān)控告警。

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

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

問題排查和審計日志

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

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

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

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

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

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

優(yōu)化實踐

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

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

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

在 Broker Load 導入時遇到的問題：

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

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

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

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

因 Hive 表字段變更導致 Broker Load 導入失敗：

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

detailMessage: ParseError : Invalid column selected xxx

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

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

遇到空 ORC 文件時 Broker Load 導入失?。?/p>

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

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

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

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

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

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

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

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

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

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

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

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

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

首先可以通過適當調(diào)高 FE 的max_broker_concurrency去提高 Scan HDFS 文件階段的并發(fā)度（最高調(diào)高至 BE 節(jié)點數(shù)），而對于 Table Sink 階段，可通過調(diào)高 FE 的default_load_parallelism（設置fe.conf，可調(diào)整到 BE 節(jié)點數(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 各階段導入的并發(fā)度，相關(guān)報表的同步時效顯著提升，這里我們選取 5 張典型表為例，優(yōu)化前后的同步時效表現(xiàn)如下：

雙機房容災建設

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

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

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

效果總結(jié)

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

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

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

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

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

未來規(guī)劃

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

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