導讀： 隨著業(yè)務量快速增長，數(shù)據(jù)規(guī)模的不斷擴大，杭銀消金早期的大數(shù)據(jù)平臺在應對實時性更強、復雜度更高的的業(yè)務需求時存在瓶頸。為了更好的應對未來的數(shù)據(jù)規(guī)模增長，杭銀消金于 2022 年 10 月正式引入 Apache Doris 1.2 對現(xiàn)有的風控數(shù)據(jù)集市進行了升級改造，利用 Multi Catalog 功能統(tǒng)一了 ES、Hive、GP 等數(shù)據(jù)源出口，實現(xiàn)了聯(lián)邦查詢，為未來統(tǒng)一數(shù)據(jù)查詢網(wǎng)關奠定了基礎；同時，基于 Apache Doris 高性能、簡單易用、部署成本低等諸多優(yōu)勢，也使得各大業(yè)務場景的查詢分析響應實現(xiàn)了從分鐘級到秒級的跨越。

杭銀消費金融股份有限公司，成立于 2015 年 12 月，是杭州銀行牽頭組建的浙江省首家持牌消費金融公司，經(jīng)過這幾年的發(fā)展，在 2022 年底資產(chǎn)規(guī)模突破 400 億，服務客戶數(shù)超千萬。公司秉承“數(shù)字普惠金融”初心，堅持服務傳統(tǒng)金融覆蓋不充分的、具有消費信貸需求的客戶群體，以“數(shù)據(jù)、場景、風控、技術”為核心，依托大數(shù)據(jù)、人工智能、云計算等互聯(lián)網(wǎng)科技，為全國消費者提供專業(yè)、高效、便捷、可信賴的金融服務。

業(yè)務需求

杭銀消金業(yè)務模式是線上業(yè)務結(jié)合線下業(yè)務的雙引擎驅(qū)動模式。為更好的服務用戶，運用數(shù)據(jù)驅(qū)動實現(xiàn)精細化管理，基于當前業(yè)務模式衍生出了四大類的業(yè)務數(shù)據(jù)需求：

• 預警類：實現(xiàn)業(yè)務流量監(jiān)控，主要是對信貸流程的用戶數(shù)量與金額進行實時監(jiān)控，出現(xiàn)問題自動告警。
• 分析類：支持查詢統(tǒng)計與臨時取數(shù)，對信貸各環(huán)節(jié)進行分析，對審批、授信、支用等環(huán)節(jié)的用戶數(shù)量與額度情況查詢分析。
• 看板類：打造業(yè)務實時駕駛艙與 T+1 業(yè)務看板，提供內(nèi)部管理層與運營部門使用，更好輔助管理進行決策。
• 建模類：支持多維模型變量的建模，通過算法模型回溯用戶的金融表現(xiàn)，提升審批、授信、支用等環(huán)節(jié)的模型能力。

數(shù)據(jù)架構(gòu) 1.0

為滿足以上需求，我們采用 Greenplum + CDH 融合的架構(gòu)體系創(chuàng)建了大數(shù)據(jù)平臺 1.0 ，如下圖所示，大數(shù)據(jù)平臺的數(shù)據(jù)源均來自于業(yè)務系統(tǒng)，我們可以從數(shù)據(jù)源的 3 個流向出發(fā)，了解大數(shù)據(jù)平臺的組成及分工：

• 業(yè)務系統(tǒng)的核心系統(tǒng)數(shù)據(jù)通過 CloudCanal 實時同步進入 Greenplum 數(shù)倉進行數(shù)據(jù)實時分析，為 BI 報表，數(shù)據(jù)大屏等應用提供服務，部分數(shù)據(jù)進入風控集市 Hive 中，提供查詢分析和建模服務。
• 業(yè)務系統(tǒng)的實時數(shù)據(jù)推送到 Kafka 消息隊列，經(jīng) Flink 實時消費寫入 ES，通過風控變量提供數(shù)據(jù)服務，而 ES 中的部分數(shù)據(jù)也可以流入 Hive 中，進行相關分析處理。
• 業(yè)務系統(tǒng)的風控數(shù)據(jù)會落在 MongoDB，經(jīng)過離線同步進入風控集市 Hive，Hive 數(shù)倉支撐了查詢平臺和建模平臺，提供風控分析和建模服務。

我們將 ES 和 Hive 共同組成了風控數(shù)據(jù)集市，從上述介紹也可知，四大類的業(yè)務需求基本都是由風控數(shù)據(jù)集市來滿足的，因此我們后續(xù)的改造升級主要基于風控數(shù)據(jù)集市來進行。在這之前，我們先了解一下風控數(shù)據(jù)集市 1.0 是如何來運轉(zhuǎn)的。

風控數(shù)據(jù)集市 1.0

風控數(shù)據(jù)集市原有架構(gòu)是基于 CDH 搭建的，由實時寫入和離線統(tǒng)計分析兩部分組成，整個架構(gòu)包含了 ES、Hive、Greenplum 等核心組件，風控數(shù)據(jù)集市的數(shù)據(jù)源主要有三種：通過 Greenplum 數(shù)倉同步的業(yè)務系統(tǒng)數(shù)據(jù)、通過 MongoDB 同步的風控決策數(shù)據(jù)，以及通過 ES 寫入的實時風控變量數(shù)據(jù)。

實時流數(shù)據(jù)： 采用了 Kafka + Flink + ES 的實時流處理方式，利用 Flink 對 Kafka 的實時數(shù)據(jù)進行清洗，實時寫入ES，并對部分結(jié)果進行匯總計算，通過接口提供給風控決策使用。

離線風控數(shù)據(jù)： 采用基于 CDH 的方案實現(xiàn)，通過 Sqoop 離線同步核心數(shù)倉 GP 上的數(shù)據(jù)，結(jié)合實時數(shù)據(jù)與落在 MongoDB 上的三方數(shù)據(jù)，經(jīng)數(shù)據(jù)清洗后統(tǒng)一匯總到 Hive 數(shù)倉進行日常的跑批與查詢分析。

需求滿足情況：

在大數(shù)據(jù)平臺 1.0 的的支持下，我們的業(yè)務需求得到了初步的實現(xiàn)：

• 預警類：基于 ES + Hive 的外表查詢，實現(xiàn)了實時業(yè)務流量監(jiān)控；
• 分析類：基于 Hive 實現(xiàn)數(shù)據(jù)查詢分析和臨時取數(shù)；
• 看板類：基于 Tableau +Hive 搭建了業(yè)務管理駕駛艙以及T+1 業(yè)務看板；
• 建模類：基于 Spark+Hive 實現(xiàn)了多維模型變量的建模分析；

受限于 Hive 的執(zhí)行效率，以上需求均在分鐘級別返回結(jié)果，僅可以滿足我們最基本的訴求，而面對秒級甚至毫秒級的分析場景，Hive 則稍顯吃力。

存在的問題：

• 單表寬度過大，影響查詢性能。風控數(shù)據(jù)集市的下游業(yè)務主要以規(guī)則引擎與實時風控服務為主，因規(guī)則引擎的特殊性，公司在數(shù)據(jù)變量衍生方面資源投入較多，某些維度上的衍生變量會達到幾千甚至上萬的規(guī)模，這將導致 Hive 中存儲的數(shù)據(jù)表字段非常多，部分經(jīng)常使用的大寬表字段數(shù)量甚至超過上千，過寬的大寬表非常影響實際使用中查詢性能。
• 數(shù)據(jù)規(guī)模龐大，維護成本高。 目前 Hive 上的風控數(shù)據(jù)集市已經(jīng)有存量數(shù)據(jù)在百 T 以上，面對如此龐大的數(shù)據(jù)規(guī)模，使用外表的方式進行維護成本非常高，數(shù)據(jù)的接入也成為一大難題。
• 接口服務不穩(wěn)定。 由風控數(shù)據(jù)集市離線跑批產(chǎn)生的變量指標還兼顧為其他業(yè)務應用提供數(shù)據(jù)服務的職責，目前 Hive 離線跑批后的結(jié)果會定時推送到 ES 集群（每天更新的數(shù)據(jù)集比較龐大，接口調(diào)用具有時效性），推送時會因為 IO 過高觸發(fā) ES 集群的 GC 抖動，導致接口服務不穩(wěn)定。

除此之外，風控分析師與建模人員一般通過 Hive & Spark 方式進行數(shù)據(jù)分析建模，這導致隨著業(yè)務規(guī)模的進一步增大，T+1 跑批與日常分析的效率越來越低，風控數(shù)據(jù)集市改造升級的需求越發(fā)強烈。

技術選型

基于業(yè)務對架構(gòu)提出的更高要求，我們期望引入一款強勁的 OLAP 引擎來改善架構(gòu)，因此我們于 2022 年 9 月份對 ClickHouse 和 Apache Doris 進行了調(diào)研，調(diào)研中發(fā)現(xiàn) Apache Doris 具有高性能、簡單易用、實現(xiàn)成本低等諸多優(yōu)勢，而且 Apache Doris 1.2 版本非常符合我們的訴求，原因如下：

寬表查詢性能優(yōu)異：從官方公布的測試結(jié)果來看，1.2 Preview 版本在 SSB-Flat 寬表場景上相對 1.1.3 版本整體性能提升了近 4 倍、相對于 0.15.0 版本性能提升了近 10 倍，在 TPC-H 多表關聯(lián)場景上較 1.1.3 版本上有近 3 倍的提升、較 0.15.0 版本性能提升了 11 倍以上，多個場景性能得到飛躍性提升。

便捷的數(shù)據(jù)接入框架以及聯(lián)邦數(shù)據(jù)分析能力： Apache Doris 1.2 版本推出的 Multi Catalog 功能可以構(gòu)建完善可擴展的數(shù)據(jù)源連接框架，便于快速接入多類數(shù)據(jù)源，提供基于各種異構(gòu)數(shù)據(jù)源的聯(lián)邦查詢和寫入能力。 目前 Multi-Catalog 已經(jīng)支持了 Hive、Iceberg、Hudi 等數(shù)據(jù)湖以及 MySQL、Elasticsearch、Greenplum 等數(shù)據(jù)庫，全面覆蓋了我們現(xiàn)有的組件棧，基于此能力有希望通過 Apache Doris 來打造統(tǒng)一數(shù)據(jù)查詢網(wǎng)關。

生態(tài)豐富： 支持 Spark Doris Connector、Flink Doris Connector，方便離線與實時數(shù)據(jù)的處理，縮短了數(shù)據(jù)處理鏈路耗費的時間。

社區(qū)活躍： Apache Doris 社區(qū)非?；钴S，響應迅速，并且 SelectDB 為社區(qū)提供了一支專職的工程師團隊，為用戶提供技術支持服務。

數(shù)據(jù)架構(gòu) 2.0

風控數(shù)據(jù)集市 2.0

基于對 Apache Doris 的初步的了解與驗證，22 年 10 月在社區(qū)的支持下我們正式引入 Apache Doris 1.2.0 Preview 版本作為風控數(shù)據(jù)集市的核心組件，Apache Doris 的 Multi Catalog 功能助力大數(shù)據(jù)平臺統(tǒng)一了 ES、Hive、Greenplum 等數(shù)據(jù)源出口，通過 Hive Catalog 和 ES Catalog 實現(xiàn)了對 Hive & ES 等多數(shù)據(jù)源的聯(lián)邦查詢，并且支持 Spark-Doris-Connector，可以實現(xiàn)數(shù)據(jù) Hive 與 Doris 的雙向流動，與現(xiàn)有建模分析體系完美集成，在短期內(nèi)實現(xiàn)了性能的快速提升。

大數(shù)據(jù)平臺 2.0

風控數(shù)據(jù)集市調(diào)整優(yōu)化之后，大數(shù)據(jù)平臺架構(gòu)也相應的發(fā)生了變化，如下圖所示，僅通過 Doris 一個組件即可為數(shù)據(jù)服務、分析平臺、建模平臺提供數(shù)據(jù)服務。

在最初進行聯(lián)調(diào)適配的時候，Doris 社區(qū)和 SelectDB 支持團隊針對我們提出的問題和疑惑一直保持高效的反饋效率，給于積極的幫助和支持，快速幫助我們解決在生產(chǎn)上遇到的問題。

需求實現(xiàn)情況：

在大數(shù)據(jù)平臺 2.0 的加持下，業(yè)務需求實現(xiàn)的方式也發(fā)生了變更，主要變化如下所示

• 預警類：基于 ES Catalog+ Doris 實現(xiàn)了對實時數(shù)據(jù)的查詢分析。在架構(gòu) 1.0 中，實時數(shù)據(jù)落在 ES 集群上，通過 Hive 外表進行查詢分析，查詢結(jié)果以分鐘級別返回；而在 Doris 1.2 集成之后， 使用 ES Catalog 訪問 ES，可以實現(xiàn)對 ES 數(shù)據(jù)秒級統(tǒng)計分析。
• 分析類：基于 Hive Catalog + Doris 實現(xiàn)了對現(xiàn)有風控數(shù)據(jù)集市的快速查詢。目前 Hive 數(shù)據(jù)集市存量表在兩萬張左右，如果通過直接創(chuàng)建 Hive 外部表的方式，表結(jié)構(gòu)映射關系的維護難度與數(shù)據(jù)同步成本使這一方式幾乎不可能實現(xiàn)。而 Doris 1.2 的 Multi Catalog 功能則完美解決了這個問題，只需要創(chuàng)建一個 Hive Catalog，就能對現(xiàn)有風控數(shù)據(jù)集市進行查詢分析，既能提升查詢性能，還減少了日常查詢分析對跑批任務的資源影響。
• 看板類：基于 Tableau + Doris 聚合展示業(yè)務實時駕駛艙和 T+1 業(yè)務看板，最初使用 Hive 時，報表查詢需要幾分鐘才能返回結(jié)果，而 Apache Doris 則是秒級甚至是毫秒級的響應速度。
• 建模類：基于 Spark+Doris 進行聚合建模。利用 Doris1.2 的 Spark-Doris-Connector功 能，實現(xiàn)了 Hive 與 Doris 數(shù)據(jù)雙向同步，滿足了 Spark 建模平臺的功能復用。同時增加了 Doris 數(shù)據(jù)源，基礎數(shù)據(jù)查詢分析的效率得到了明顯提升，建模分析能力的也得到了增強。

在 Apache Doris 引入之后，以上四個業(yè)務場景的查詢耗時基本都實現(xiàn)了從分鐘級到秒級響應的跨越，性能提升十分巨大。

生產(chǎn)環(huán)境集群監(jiān)控

為了快速驗證新版本的效果，我們在生產(chǎn)環(huán)境上搭建了兩個集群，目前生產(chǎn)集群的配置是 4 個 FE + 8個 BE，單個節(jié)點是配置為 64 核+ 256G+4T，備用集群為 4 個 FE + 4 個 BE 的配置，單個節(jié)點配置保持一致。

集群監(jiān)控如下圖所示：

可以看出，Apache Doris 1.2 的查詢效率非常高，原計劃至少要上 10 個節(jié)點，而在實際使用下來，我們發(fā)現(xiàn)當前主要使用的場景均是以 Catalog 的方式查詢，因此集群規(guī)?？梢韵鄬^小就可以快速上線，也不會破壞當前的系統(tǒng)架構(gòu)，兼容性非常好。

01 數(shù)據(jù)集成方案

前段時間，Apache Doris 1.2.2 版本已經(jīng)發(fā)布，為了更好的支撐應用服務，我們使用 Apache Doris 1.2.2 與 DolphinScheduler 3.1.4 調(diào)度器、SeaTunnel 2.1.3 數(shù)據(jù)同步平臺等開源軟件實現(xiàn)了集成，以便于數(shù)據(jù)定時從 Hive 抽取到 Doris 中。整體的數(shù)據(jù)集成方案如下：

在當前的硬件配置下，數(shù)據(jù)同步采用的是 DolphinScheduler 的 Shell 腳本模式，定時調(diào)起 SeaTunnel 的腳本，數(shù)據(jù)同步任務的配置文件如下：

 env{
  spark.app.name = "hive2doris-template"
  spark.executor.instances = 10
  spark.executor.cores = 5
  spark.executor.memory = "20g"
}
spark {
  spark.sql.catalogImplementation = "hive"
}
source {
  hive {
    pre_sql = "select * from ods.demo_tbl where dt='2023-03-09'"
    result_table_name = "ods_demo_tbl"
  }
}
 
transform {
}
 
sink {
  doris {
      fenodes = "192.168.0.10:8030,192.168.0.11:8030,192.168.0.12:8030,192.168.0.13:8030"
      user = root
      password = "XXX"
      database = ods
      table = ods_demo_tbl
      batch_size = 500000
      max_retries = 1
      interval = 10000
      doris.column_separator = "\t"
    }
}

該方案成功實施后，資源占用、計算內(nèi)存占用有了明顯的降低，查詢性能、導入性能有了大幅提升：

1. 存儲成本降低

使用前：Hive 原始表包含 500 個字段，單個分區(qū)數(shù)據(jù)量為 1.5 億/天，在 HDFS 上占用約 810G 的空間。

使用后：我們通過 SeaTunnel 調(diào)起 Spark on YARN 的方式進行數(shù)據(jù)同步，可以在 40 分鐘左右完成數(shù)據(jù)同步，同步后數(shù)據(jù)占用 270G 空間，存儲資源僅占之前的 1/3。

2. 計算內(nèi)存占用降低，性能提升顯著

使用前：上述表在 Hive 上進行 Group By 時，占用 YARN 資源 720 核 1.44T 內(nèi)存，需要 162 秒才可返回結(jié)果；

使用后：

• 通過 Doris 調(diào)用 Hive Catalog 進行聚合查詢，在設置 set exec_mem_limit=16G 情況下用時 58.531 秒，查詢耗時較之前減少了近 2/3；
• 在同等條件下，在 Doris 中執(zhí)行相同的的操作可以在 0.828 秒就能返回查詢結(jié)果，性能增幅巨大。

具體效果如下：

（1）Hive 查詢語句，用時 162 秒。

select count(*),product_no   FROM ods.demo_tbl where dt='2023-03-09'
group by product_no;

（2）Doris 上 Hive Catalog 查詢語句，用時 58.531 秒。

set exec_mem_limit=16G；
select count(*),product_no   FROM hive.ods.demo_tbl where dt='2023-03-09'
group by product_no;

（3）Doris 上本地表查詢語句，僅用時0.828秒。

select count(*),product_no   FROM ods.demo_tbl where dt='2023-03-09'
group by product_no;

3. 導入性能提升

使用前：Hive 原始表包含 40 個字段，單個分區(qū)數(shù)據(jù)量 11 億/天，在 HDFS 上占用約 806G 的空間

使用后：通過 SeaTunnel 調(diào)起 Spark on YARN 方式進行數(shù)據(jù)同步，可以在 11 分鐘左右完成數(shù)據(jù)同步，即 1 分鐘同步約一億條數(shù)據(jù)，同步后占用 378G 空間。

可以看出，在數(shù)據(jù)導入性能的提升的同時，資源也有了較大的節(jié)省，主要得益于對以下幾個參數(shù)進行了調(diào)整：

push_write_mbytes_per_sec：BE 磁盤寫入限速，300M

push_worker_count_high_priority: 同時執(zhí)行的 push 任務個數(shù)，15

push_worker_count_normal_priority: 同時執(zhí)行的 push 任務個數(shù)，15

02 架構(gòu)收益

（1）統(tǒng)一數(shù)據(jù)源出口，查詢效率顯著提升

風控數(shù)據(jù)集市采用的是異構(gòu)存儲的方式來存儲數(shù)據(jù)，Apache Doris 的 Multi Catalog 功能成功統(tǒng)一了 ES、Hive、GP 等數(shù)據(jù)源出口，實現(xiàn)了聯(lián)邦查詢。 同時，Doris 本身具有存儲能力，可支持其他數(shù)據(jù)源中的數(shù)據(jù)通過外表插入內(nèi)容的方式快速進行數(shù)據(jù)同步，真正實現(xiàn)了數(shù)據(jù)門戶。此外，Apache Doris 可支持聚合查詢，在向量化引擎的加持下，查詢效率得到顯著提升。

（2） Hive 任務拆分，提升集群資源利用率

我們將原有的 Hive 跑批任務跟日常的查詢統(tǒng)計進行了隔離，以提升集群資源的利用效率。目前 YARN 集群上的任務數(shù)量是幾千的規(guī)模，跑批任務占比約 60%，臨時查詢分析占比 40%，由于資源限制導致日常跑批任務經(jīng)常會因為資源等待而延誤，臨時分析也因資源未及時分配而導致任務無法完成。當部署了 Doris 1.2 之后，對資源進行了劃分，完全擺脫 YARN 集群的資源限制，跑批與日常的查詢統(tǒng)計均有了明顯的改善，基本可以在秒級得到分析結(jié)果，同時也減輕了數(shù)據(jù)分析師的工作壓力，提升了用戶對平臺的滿意度。

（3）提升了數(shù)據(jù)接口的穩(wěn)定性，數(shù)據(jù)寫入性能大幅提升

之前數(shù)據(jù)接口是基于 ES 集群的，當進行大批量離線數(shù)據(jù)推送時會導致 ES 集群的 GC 抖動，影響了接口穩(wěn)定性，經(jīng)過調(diào)整之后，我們將接口服務的數(shù)據(jù)集存儲在 Doris 上，Doris 節(jié)點并未出現(xiàn)抖動，實現(xiàn)數(shù)據(jù)快速寫入，成功提升了接口的穩(wěn)定性，同時 Doris 查詢在數(shù)據(jù)寫入時影響較小，數(shù)據(jù)寫入性能較之前也有了非常大的提升，千萬級別的數(shù)據(jù)可在十分鐘內(nèi)推送成功。

（4）Doris 生態(tài)豐富，遷移方便成本較低。

Spark-Doris-Connector 在過渡期為我們減輕了不少的壓力，當數(shù)據(jù)在 Hive 與 Doris 共存時，部分 Doris 分析結(jié)果通過 Spark 回寫到 Hive 非常方便，當 Spark 調(diào)用 Doris 時只需要進行簡單改造就能完成原有腳本的復用，遷移方便、成本較低。

（5）支持橫向熱部署，集群擴容、運維簡單。

Apache Doris 支持橫向熱部署，集群擴容方便，節(jié)點重啟可以在在秒級實現(xiàn)，可實現(xiàn)無縫對接，減少了該過程對業(yè)務的影響； 在架構(gòu) 1.0 中，當 Hive 集群與 GP 集群需要擴容更新時，配置修改后一般需要較長時間集群才可恢復，用戶感知比較明顯。而 Doris 很好的解決了這個問題，實現(xiàn)用戶無感知擴容，也降低了集群運維的投入。

未來與展望

當前在架構(gòu) 2.0 中的 Doris 集群在大數(shù)據(jù)平臺中的角色更傾向于查詢優(yōu)化，大部分數(shù)據(jù)還集中維護在 Hive 集群上，未來我們計劃在升級架構(gòu) 3.0 的時候，完成以下改造：

• 實時全量數(shù)據(jù)接入：利用 Flink 將所有的實時數(shù)據(jù)直接接入 Doris，不再經(jīng)過 ES 存儲；
• 數(shù)據(jù)集數(shù)據(jù)完整性：利用 Doris 構(gòu)建實時數(shù)據(jù)集市的原始層，利用 FlinkCDC 等同步工具將業(yè)務庫 MySQL與決策過程中產(chǎn)生的 MongoDB 數(shù)據(jù)實時同步到 Doris，最大限度將現(xiàn)有數(shù)據(jù)都接入 Doris 的統(tǒng)一平臺，保證數(shù)據(jù)集數(shù)據(jù)完整性。
• 離線跑批任務遷移：將現(xiàn)有 Hive&Spark 中大部分跑批任務遷移至 Doris，提升跑批效率；
• 統(tǒng)一查詢分析出口：將所有的查詢分析統(tǒng)一集中到 Doris，完全統(tǒng)一數(shù)據(jù)出口，實現(xiàn)統(tǒng)一數(shù)據(jù)查詢網(wǎng)關，使數(shù)據(jù)的管理更加規(guī)范化；
• 強化集群穩(wěn)定擴容：引入可視化運維管理工具對集群進行維護和管理，使 Doris 集群能夠更加穩(wěn)定支撐業(yè)務擴展。

總結(jié)與致謝

Apache Doris 1.2 是社區(qū)在版本迭代中的重大升級，借助 Multi Catalog 等優(yōu)異功能能讓 Doris 在 Hadoop 相關的大數(shù)據(jù)體系中快速落地，實現(xiàn)聯(lián)邦查詢；同時可以將日常跑批與統(tǒng)計分析進行解耦，有效提升大數(shù)據(jù)平臺的的查詢性能。

作為第一批 Apache Doris1.2 的用戶，我們深感榮幸，同時也十分感謝 Doris 團隊的全力配合和付出，可以讓 Apache Doris 快速落地、上線生產(chǎn)，并為后續(xù)的迭代優(yōu)化提供了可能。

Apache Doris 1.2 值得大力推薦，希望大家都能從中受益，祝愿 Apache Doris 生態(tài)越來越繁榮，越來越好！

作者｜杭銀消金大數(shù)據(jù)團隊 周其進，唐海定， 姚錦權(quán)