導讀: 隨著業(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)存占用有了明顯的降低,查詢性能、導入性能有了大幅提升:
- 存儲成本降低
使用前: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。
- 計算內(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;
- 導入性能提升
使用前: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)
