導(dǎo)讀： 隨著業(yè)務(wù)量快速增長(zhǎng)，數(shù)據(jù)規(guī)模的不斷擴(kuò)大，杭銀消金早期的大數(shù)據(jù)平臺(tái)在應(yīng)對(duì)實(shí)時(shí)性更強(qiáng)、復(fù)雜度更高的的業(yè)務(wù)需求時(shí)存在瓶頸。為了更好的應(yīng)對(duì)未來(lái)的數(shù)據(jù)規(guī)模增長(zhǎng)，杭銀消金于 2022 年 10 月正式引入 Apache Doris 1.2 對(duì)現(xiàn)有的風(fēng)控?cái)?shù)據(jù)集市進(jìn)行了升級(jí)改造，利用 Multi Catalog 功能統(tǒng)一了 ES、Hive、GP 等數(shù)據(jù)源出口，實(shí)現(xiàn)了聯(lián)邦查詢，為未來(lái)統(tǒng)一數(shù)據(jù)查詢網(wǎng)關(guān)奠定了基礎(chǔ)；同時(shí)，基于 Apache Doris 高性能、簡(jiǎn)單易用、部署成本低等諸多優(yōu)勢(shì)，也使得各大業(yè)務(wù)場(chǎng)景的查詢分析響應(yīng)實(shí)現(xiàn)了從分鐘級(jí)到秒級(jí)的跨越。
杭銀消費(fèi)金融股份有限公司，成立于 2015 年 12 月，是杭州銀行牽頭組建的浙江省首家持牌消費(fèi)金融公司，經(jīng)過這幾年的發(fā)展，在 2022 年底資產(chǎn)規(guī)模突破 400 億，服務(wù)客戶數(shù)超千萬(wàn)。公司秉承“數(shù)字普惠金融”初心，堅(jiān)持服務(wù)傳統(tǒng)金融覆蓋不充分的、具有消費(fèi)信貸需求的客戶群體，以“數(shù)據(jù)、場(chǎng)景、風(fēng)控、技術(shù)”為核心，依托大數(shù)據(jù)、人工智能、云計(jì)算等互聯(lián)網(wǎng)科技，為全國(guó)消費(fèi)者提供專業(yè)、高效、便捷、可信賴的金融服務(wù)。
業(yè)務(wù)需求
杭銀消金業(yè)務(wù)模式是線上業(yè)務(wù)結(jié)合線下業(yè)務(wù)的雙引擎驅(qū)動(dòng)模式。為更好的服務(wù)用戶，運(yùn)用數(shù)據(jù)驅(qū)動(dòng)實(shí)現(xiàn)精細(xì)化管理，基于當(dāng)前業(yè)務(wù)模式衍生出了四大類的業(yè)務(wù)數(shù)據(jù)需求：
- 預(yù)警類：實(shí)現(xiàn)業(yè)務(wù)流量監(jiān)控，主要是對(duì)信貸流程的用戶數(shù)量與金額進(jìn)行實(shí)時(shí)監(jiān)控，出現(xiàn)問題自動(dòng)告警。
- 分析類：支持查詢統(tǒng)計(jì)與臨時(shí)取數(shù)，對(duì)信貸各環(huán)節(jié)進(jìn)行分析，對(duì)審批、授信、支用等環(huán)節(jié)的用戶數(shù)量與額度情況查詢分析。
- 看板類：打造業(yè)務(wù)實(shí)時(shí)駕駛艙與 T+1 業(yè)務(wù)看板，提供內(nèi)部管理層與運(yùn)營(yíng)部門使用，更好輔助管理進(jìn)行決策。
- 建模類：支持多維模型變量的建模，通過算法模型回溯用戶的金融表現(xiàn)，提升審批、授信、支用等環(huán)節(jié)的模型能力。
數(shù)據(jù)架構(gòu) 1.0
為滿足以上需求，我們采用 Greenplum + CDH 融合的架構(gòu)體系創(chuàng)建了大數(shù)據(jù)平臺(tái) 1.0 ，如下圖所示，大數(shù)據(jù)平臺(tái)的數(shù)據(jù)源均來(lái)自于業(yè)務(wù)系統(tǒng)，我們可以從數(shù)據(jù)源的 3 個(gè)流向出發(fā)，了解大數(shù)據(jù)平臺(tái)的組成及分工：
- 業(yè)務(wù)系統(tǒng)的核心系統(tǒng)數(shù)據(jù)通過 CloudCanal 實(shí)時(shí)同步進(jìn)入 Greenplum 數(shù)倉(cāng)進(jìn)行數(shù)據(jù)實(shí)時(shí)分析，為 BI 報(bào)表，數(shù)據(jù)大屏等應(yīng)用提供服務(wù)，部分?jǐn)?shù)據(jù)進(jìn)入風(fēng)控集市 Hive 中，提供查詢分析和建模服務(wù)。
- 業(yè)務(wù)系統(tǒng)的實(shí)時(shí)數(shù)據(jù)推送到 Kafka 消息隊(duì)列，經(jīng) Flink 實(shí)時(shí)消費(fèi)寫入 ES，通過風(fēng)控變量提供數(shù)據(jù)服務(wù)，而 ES 中的部分?jǐn)?shù)據(jù)也可以流入 Hive 中，進(jìn)行相關(guān)分析處理。
- 業(yè)務(wù)系統(tǒng)的風(fēng)控?cái)?shù)據(jù)會(huì)落在 MongoDB，經(jīng)過離線同步進(jìn)入風(fēng)控集市 Hive，Hive 數(shù)倉(cāng)支撐了查詢平臺(tái)和建模平臺(tái)，提供風(fēng)控分析和建模服務(wù)。
我們將 ES 和 Hive 共同組成了風(fēng)控?cái)?shù)據(jù)集市，從上述介紹也可知，四大類的業(yè)務(wù)需求基本都是由風(fēng)控?cái)?shù)據(jù)集市來(lái)滿足的，因此我們后續(xù)的改造升級(jí)主要基于風(fēng)控?cái)?shù)據(jù)集市來(lái)進(jìn)行。在這之前，我們先了解一下風(fēng)控?cái)?shù)據(jù)集市 1.0 是如何來(lái)運(yùn)轉(zhuǎn)的。
風(fēng)控?cái)?shù)據(jù)集市 1.0
風(fēng)控?cái)?shù)據(jù)集市原有架構(gòu)是基于 CDH 搭建的，由實(shí)時(shí)寫入和離線統(tǒng)計(jì)分析兩部分組成，整個(gè)架構(gòu)包含了 ES、Hive、Greenplum 等核心組件，風(fēng)控?cái)?shù)據(jù)集市的數(shù)據(jù)源主要有三種：通過 Greenplum 數(shù)倉(cāng)同步的業(yè)務(wù)系統(tǒng)數(shù)據(jù)、通過 MongoDB 同步的風(fēng)控決策數(shù)據(jù)，以及通過 ES 寫入的實(shí)時(shí)風(fēng)控變量數(shù)據(jù)。
實(shí)時(shí)流數(shù)據(jù)： 采用了 Kafka + Flink + ES 的實(shí)時(shí)流處理方式，利用 Flink 對(duì) Kafka 的實(shí)時(shí)數(shù)據(jù)進(jìn)行清洗，實(shí)時(shí)寫入ES，并對(duì)部分結(jié)果進(jìn)行匯總計(jì)算，通過接口提供給風(fēng)控決策使用。
離線風(fēng)控?cái)?shù)據(jù)： 采用基于 CDH 的方案實(shí)現(xiàn)，通過 Sqoop 離線同步核心數(shù)倉(cāng) GP 上的數(shù)據(jù)，結(jié)合實(shí)時(shí)數(shù)據(jù)與落在 MongoDB 上的三方數(shù)據(jù)，經(jīng)數(shù)據(jù)清洗后統(tǒng)一匯總到 Hive 數(shù)倉(cāng)進(jìn)行日常的跑批與查詢分析。
需求滿足情況：
在大數(shù)據(jù)平臺(tái) 1.0 的的支持下，我們的業(yè)務(wù)需求得到了初步的實(shí)現(xiàn)：
- 預(yù)警類：基于 ES + Hive 的外表查詢，實(shí)現(xiàn)了實(shí)時(shí)業(yè)務(wù)流量監(jiān)控；
- 分析類：基于 Hive 實(shí)現(xiàn)數(shù)據(jù)查詢分析和臨時(shí)取數(shù)；
- 看板類：基于 Tableau +Hive 搭建了業(yè)務(wù)管理駕駛艙以及T+1 業(yè)務(wù)看板；
- 建模類：基于 Spark+Hive 實(shí)現(xiàn)了多維模型變量的建模分析；
受限于 Hive 的執(zhí)行效率，以上需求均在分鐘級(jí)別返回結(jié)果，僅可以滿足我們最基本的訴求，而面對(duì)秒級(jí)甚至毫秒級(jí)的分析場(chǎng)景，Hive 則稍顯吃力。
存在的問題：
- 單表寬度過大，影響查詢性能。風(fēng)控?cái)?shù)據(jù)集市的下游業(yè)務(wù)主要以規(guī)則引擎與實(shí)時(shí)風(fēng)控服務(wù)為主，因規(guī)則引擎的特殊性，公司在數(shù)據(jù)變量衍生方面資源投入較多，某些維度上的衍生變量會(huì)達(dá)到幾千甚至上萬(wàn)的規(guī)模，這將導(dǎo)致 Hive 中存儲(chǔ)的數(shù)據(jù)表字段非常多，部分經(jīng)常使用的大寬表字段數(shù)量甚至超過上千，過寬的大寬表非常影響實(shí)際使用中查詢性能。
- 數(shù)據(jù)規(guī)模龐大，維護(hù)成本高。 目前 Hive 上的風(fēng)控?cái)?shù)據(jù)集市已經(jīng)有存量數(shù)據(jù)在百 T 以上，面對(duì)如此龐大的數(shù)據(jù)規(guī)模，使用外表的方式進(jìn)行維護(hù)成本非常高，數(shù)據(jù)的接入也成為一大難題。
- 接口服務(wù)不穩(wěn)定。 由風(fēng)控?cái)?shù)據(jù)集市離線跑批產(chǎn)生的變量指標(biāo)還兼顧為其他業(yè)務(wù)應(yīng)用提供數(shù)據(jù)服務(wù)的職責(zé)，目前 Hive 離線跑批后的結(jié)果會(huì)定時(shí)推送到 ES 集群（每天更新的數(shù)據(jù)集比較龐大，接口調(diào)用具有時(shí)效性），推送時(shí)會(huì)因?yàn)?IO 過高觸發(fā) ES 集群的 GC 抖動(dòng)，導(dǎo)致接口服務(wù)不穩(wěn)定。
除此之外，風(fēng)控分析師與建模人員一般通過 Hive & Spark 方式進(jìn)行數(shù)據(jù)分析建模，這導(dǎo)致隨著業(yè)務(wù)規(guī)模的進(jìn)一步增大，T+1 跑批與日常分析的效率越來(lái)越低，風(fēng)控?cái)?shù)據(jù)集市改造升級(jí)的需求越發(fā)強(qiáng)烈。
技術(shù)選型
基于業(yè)務(wù)對(duì)架構(gòu)提出的更高要求，我們期望引入一款強(qiáng)勁的 OLAP 引擎來(lái)改善架構(gòu)，因此我們于 2022 年 9 月份對(duì) ClickHouse 和 Apache Doris 進(jìn)行了調(diào)研，調(diào)研中發(fā)現(xiàn) Apache Doris 具有高性能、簡(jiǎn)單易用、實(shí)現(xiàn)成本低等諸多優(yōu)勢(shì)，而且 Apache Doris 1.2 版本非常符合我們的訴求，原因如下：
寬表查詢性能優(yōu)異：從官方公布的測(cè)試結(jié)果來(lái)看，1.2 Preview 版本在 SSB-Flat 寬表場(chǎng)景上相對(duì) 1.1.3 版本整體性能提升了近 4 倍、相對(duì)于 0.15.0 版本性能提升了近 10 倍，在 TPC-H 多表關(guān)聯(lián)場(chǎng)景上較 1.1.3 版本上有近 3 倍的提升、較 0.15.0 版本性能提升了 11 倍以上，多個(gè)場(chǎng)景性能得到飛躍性提升。
便捷的數(shù)據(jù)接入框架以及聯(lián)邦數(shù)據(jù)分析能力： Apache Doris 1.2 版本推出的 Multi Catalog 功能可以構(gòu)建完善可擴(kuò)展的數(shù)據(jù)源連接框架，便于快速接入多類數(shù)據(jù)源，提供基于各種異構(gòu)數(shù)據(jù)源的聯(lián)邦查詢和寫入能力。 目前 Multi-Catalog 已經(jīng)支持了 Hive、Iceberg、Hudi 等數(shù)據(jù)湖以及 MySQL、Elasticsearch、Greenplum 等數(shù)據(jù)庫(kù)，全面覆蓋了我們現(xiàn)有的組件棧，基于此能力有希望通過 Apache Doris 來(lái)打造統(tǒng)一數(shù)據(jù)查詢網(wǎng)關(guān)。
生態(tài)豐富： 支持 Spark Doris Connector、Flink Doris Connector，方便離線與實(shí)時(shí)數(shù)據(jù)的處理，縮短了數(shù)據(jù)處理鏈路耗費(fèi)的時(shí)間。
社區(qū)活躍： Apache Doris 社區(qū)非常活躍，響應(yīng)迅速，并且 SelectDB 為社區(qū)提供了一支專職的工程師團(tuán)隊(duì)，為用戶提供技術(shù)支持服務(wù)。
數(shù)據(jù)架構(gòu) 2.0
風(fēng)控?cái)?shù)據(jù)集市 2.0
基于對(duì) Apache Doris 的初步的了解與驗(yàn)證，22 年 10 月在社區(qū)的支持下我們正式引入 Apache Doris 1.2.0 Preview 版本作為風(fēng)控?cái)?shù)據(jù)集市的核心組件，Apache Doris 的 Multi Catalog 功能助力大數(shù)據(jù)平臺(tái)統(tǒng)一了 ES、Hive、Greenplum 等數(shù)據(jù)源出口，通過 Hive Catalog 和 ES Catalog 實(shí)現(xiàn)了對(duì) Hive & ES 等多數(shù)據(jù)源的聯(lián)邦查詢，并且支持 Spark-Doris-Connector，可以實(shí)現(xiàn)數(shù)據(jù) Hive 與 Doris 的雙向流動(dòng)，與現(xiàn)有建模分析體系完美集成，在短期內(nèi)實(shí)現(xiàn)了性能的快速提升。
大數(shù)據(jù)平臺(tái) 2.0
風(fēng)控?cái)?shù)據(jù)集市調(diào)整優(yōu)化之后，大數(shù)據(jù)平臺(tái)架構(gòu)也相應(yīng)的發(fā)生了變化，如下圖所示，僅通過 Doris 一個(gè)組件即可為數(shù)據(jù)服務(wù)、分析平臺(tái)、建模平臺(tái)提供數(shù)據(jù)服務(wù)。
在最初進(jìn)行聯(lián)調(diào)適配的時(shí)候，Doris 社區(qū)和 SelectDB 支持團(tuán)隊(duì)針對(duì)我們提出的問題和疑惑一直保持高效的反饋效率，給于積極的幫助和支持，快速幫助我們解決在生產(chǎn)上遇到的問題。
需求實(shí)現(xiàn)情況：
在大數(shù)據(jù)平臺(tái) 2.0 的加持下，業(yè)務(wù)需求實(shí)現(xiàn)的方式也發(fā)生了變更，主要變化如下所示
- 預(yù)警類：基于 ES Catalog+ Doris 實(shí)現(xiàn)了對(duì)實(shí)時(shí)數(shù)據(jù)的查詢分析。在架構(gòu) 1.0 中，實(shí)時(shí)數(shù)據(jù)落在 ES 集群上，通過 Hive 外表進(jìn)行查詢分析，查詢結(jié)果以分鐘級(jí)別返回；而在 Doris 1.2 集成之后， 使用 ES Catalog 訪問 ES，可以實(shí)現(xiàn)對(duì) ES 數(shù)據(jù)秒級(jí)統(tǒng)計(jì)分析。
- 分析類：基于 Hive Catalog + Doris 實(shí)現(xiàn)了對(duì)現(xiàn)有風(fēng)控?cái)?shù)據(jù)集市的快速查詢。目前 Hive 數(shù)據(jù)集市存量表在兩萬(wàn)張左右，如果通過直接創(chuàng)建 Hive 外部表的方式，表結(jié)構(gòu)映射關(guān)系的維護(hù)難度與數(shù)據(jù)同步成本使這一方式幾乎不可能實(shí)現(xiàn)。而 Doris 1.2 的 Multi Catalog 功能則完美解決了這個(gè)問題，只需要?jiǎng)?chuàng)建一個(gè) Hive Catalog，就能對(duì)現(xiàn)有風(fēng)控?cái)?shù)據(jù)集市進(jìn)行查詢分析，既能提升查詢性能，還減少了日常查詢分析對(duì)跑批任務(wù)的資源影響。
- 看板類：基于 Tableau + Doris 聚合展示業(yè)務(wù)實(shí)時(shí)駕駛艙和 T+1 業(yè)務(wù)看板，最初使用 Hive 時(shí)，報(bào)表查詢需要幾分鐘才能返回結(jié)果，而 Apache Doris 則是秒級(jí)甚至是毫秒級(jí)的響應(yīng)速度。
- 建模類：基于 Spark+Doris 進(jìn)行聚合建模。利用 Doris1.2 的 Spark-Doris-Connector功 能，實(shí)現(xiàn)了 Hive 與 Doris 數(shù)據(jù)雙向同步，滿足了 Spark 建模平臺(tái)的功能復(fù)用。同時(shí)增加了 Doris 數(shù)據(jù)源，基礎(chǔ)數(shù)據(jù)查詢分析的效率得到了明顯提升，建模分析能力的也得到了增強(qiáng)。
在 Apache Doris 引入之后，以上四個(gè)業(yè)務(wù)場(chǎng)景的查詢耗時(shí)基本都實(shí)現(xiàn)了從分鐘級(jí)到秒級(jí)響應(yīng)的跨越，性能提升十分巨大。
生產(chǎn)環(huán)境集群監(jiān)控
為了快速驗(yàn)證新版本的效果，我們?cè)谏a(chǎn)環(huán)境上搭建了兩個(gè)集群，目前生產(chǎn)集群的配置是 4 個(gè) FE + 8個(gè) BE，單個(gè)節(jié)點(diǎn)是配置為 64 核+ 256G+4T，備用集群為 4 個(gè) FE + 4 個(gè) BE 的配置，單個(gè)節(jié)點(diǎn)配置保持一致。
集群監(jiān)控如下圖所示：
可以看出，Apache Doris 1.2 的查詢效率非常高，原計(jì)劃至少要上 10 個(gè)節(jié)點(diǎn)，而在實(shí)際使用下來(lái)，我們發(fā)現(xiàn)當(dāng)前主要使用的場(chǎng)景均是以 Catalog 的方式查詢，因此集群規(guī)模可以相對(duì)較小就可以快速上線，也不會(huì)破壞當(dāng)前的系統(tǒng)架構(gòu)，兼容性非常好。
01 數(shù)據(jù)集成方案
前段時(shí)間，Apache Doris 1.2.2 版本已經(jīng)發(fā)布，為了更好的支撐應(yīng)用服務(wù)，我們使用 Apache Doris 1.2.2 與 DolphinScheduler 3.1.4 調(diào)度器、SeaTunnel 2.1.3 數(shù)據(jù)同步平臺(tái)等開源軟件實(shí)現(xiàn)了集成，以便于數(shù)據(jù)定時(shí)從 Hive 抽取到 Doris 中。整體的數(shù)據(jù)集成方案如下：
在當(dāng)前的硬件配置下，數(shù)據(jù)同步采用的是 DolphinScheduler 的 Shell 腳本模式，定時(shí)調(diào)起 SeaTunnel 的腳本，數(shù)據(jù)同步任務(wù)的配置文件如下：
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"
}
}
該方案成功實(shí)施后，資源占用、計(jì)算內(nèi)存占用有了明顯的降低，查詢性能、導(dǎo)入性能有了大幅提升：
- 存儲(chǔ)成本降低
使用前：Hive 原始表包含 500 個(gè)字段，單個(gè)分區(qū)數(shù)據(jù)量為 1.5 億/天，在 HDFS 上占用約 810G 的空間。
使用后：我們通過 SeaTunnel 調(diào)起 Spark on YARN 的方式進(jìn)行數(shù)據(jù)同步，可以在 40 分鐘左右完成數(shù)據(jù)同步，同步后數(shù)據(jù)占用 270G 空間，存儲(chǔ)資源僅占之前的 1/3。
- 計(jì)算內(nèi)存占用降低，性能提升顯著
使用前：上述表在 Hive 上進(jìn)行 Group By 時(shí)，占用 YARN 資源 720 核 1.44T 內(nèi)存，需要 162 秒才可返回結(jié)果；
使用后：
- 通過 Doris 調(diào)用 Hive Catalog 進(jìn)行聚合查詢，在設(shè)置
set exec_mem_limit=16G情況下用時(shí) 58.531 秒，查詢耗時(shí)較之前減少了近 2/3； - 在同等條件下，在 Doris 中執(zhí)行相同的的操作可以在 0.828 秒就能返回查詢結(jié)果，性能增幅巨大。
具體效果如下：
（1）Hive 查詢語(yǔ)句，用時(shí) 162 秒。
select count(*),product_no FROM ods.demo_tbl where dt='2023-03-09'
group by product_no;
（2）Doris 上 Hive Catalog 查詢語(yǔ)句，用時(shí) 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 上本地表查詢語(yǔ)句，僅用時(shí)0.828秒。
select count(*),product_no FROM ods.demo_tbl where dt='2023-03-09'
group by product_no;
- 導(dǎo)入性能提升
使用前：Hive 原始表包含 40 個(gè)字段，單個(gè)分區(qū)數(shù)據(jù)量 11 億/天，在 HDFS 上占用約 806G 的空間
使用后：通過 SeaTunnel 調(diào)起 Spark on YARN 方式進(jìn)行數(shù)據(jù)同步，可以在 11 分鐘左右完成數(shù)據(jù)同步，即 1 分鐘同步約一億條數(shù)據(jù)，同步后占用 378G 空間。
可以看出，在數(shù)據(jù)導(dǎo)入性能的提升的同時(shí)，資源也有了較大的節(jié)省，主要得益于對(duì)以下幾個(gè)參數(shù)進(jìn)行了調(diào)整：
push_write_mbytes_per_sec：BE 磁盤寫入限速，300M
push_worker_count_high_priority: 同時(shí)執(zhí)行的 push 任務(wù)個(gè)數(shù)，15
push_worker_count_normal_priority: 同時(shí)執(zhí)行的 push 任務(wù)個(gè)數(shù)，15
02 架構(gòu)收益
（1）統(tǒng)一數(shù)據(jù)源出口，查詢效率顯著提升
風(fēng)控?cái)?shù)據(jù)集市采用的是異構(gòu)存儲(chǔ)的方式來(lái)存儲(chǔ)數(shù)據(jù)，Apache Doris 的 Multi Catalog 功能成功統(tǒng)一了 ES、Hive、GP 等數(shù)據(jù)源出口，實(shí)現(xiàn)了聯(lián)邦查詢。 同時(shí)，Doris 本身具有存儲(chǔ)能力，可支持其他數(shù)據(jù)源中的數(shù)據(jù)通過外表插入內(nèi)容的方式快速進(jìn)行數(shù)據(jù)同步，真正實(shí)現(xiàn)了數(shù)據(jù)門戶。此外，Apache Doris 可支持聚合查詢，在向量化引擎的加持下，查詢效率得到顯著提升。
（2） Hive 任務(wù)拆分，提升集群資源利用率
我們將原有的 Hive 跑批任務(wù)跟日常的查詢統(tǒng)計(jì)進(jìn)行了隔離，以提升集群資源的利用效率。目前 YARN 集群上的任務(wù)數(shù)量是幾千的規(guī)模，跑批任務(wù)占比約 60%，臨時(shí)查詢分析占比 40%，由于資源限制導(dǎo)致日常跑批任務(wù)經(jīng)常會(huì)因?yàn)橘Y源等待而延誤，臨時(shí)分析也因資源未及時(shí)分配而導(dǎo)致任務(wù)無(wú)法完成。當(dāng)部署了 Doris 1.2 之后，對(duì)資源進(jìn)行了劃分，完全擺脫 YARN 集群的資源限制，跑批與日常的查詢統(tǒng)計(jì)均有了明顯的改善，基本可以在秒級(jí)得到分析結(jié)果，同時(shí)也減輕了數(shù)據(jù)分析師的工作壓力，提升了用戶對(duì)平臺(tái)的滿意度。
（3）提升了數(shù)據(jù)接口的穩(wěn)定性，數(shù)據(jù)寫入性能大幅提升
之前數(shù)據(jù)接口是基于 ES 集群的，當(dāng)進(jìn)行大批量離線數(shù)據(jù)推送時(shí)會(huì)導(dǎo)致 ES 集群的 GC 抖動(dòng)，影響了接口穩(wěn)定性，經(jīng)過調(diào)整之后，我們將接口服務(wù)的數(shù)據(jù)集存儲(chǔ)在 Doris 上，Doris 節(jié)點(diǎn)并未出現(xiàn)抖動(dòng)，實(shí)現(xiàn)數(shù)據(jù)快速寫入，成功提升了接口的穩(wěn)定性，同時(shí) Doris 查詢?cè)跀?shù)據(jù)寫入時(shí)影響較小，數(shù)據(jù)寫入性能較之前也有了非常大的提升，千萬(wàn)級(jí)別的數(shù)據(jù)可在十分鐘內(nèi)推送成功。
（4）Doris 生態(tài)豐富，遷移方便成本較低。
Spark-Doris-Connector 在過渡期為我們減輕了不少的壓力，當(dāng)數(shù)據(jù)在 Hive 與 Doris 共存時(shí)，部分 Doris 分析結(jié)果通過 Spark 回寫到 Hive 非常方便，當(dāng) Spark 調(diào)用 Doris 時(shí)只需要進(jìn)行簡(jiǎn)單改造就能完成原有腳本的復(fù)用，遷移方便、成本較低。
（5）支持橫向熱部署，集群擴(kuò)容、運(yùn)維簡(jiǎn)單。
Apache Doris 支持橫向熱部署，集群擴(kuò)容方便，節(jié)點(diǎn)重啟可以在在秒級(jí)實(shí)現(xiàn)，可實(shí)現(xiàn)無(wú)縫對(duì)接，減少了該過程對(duì)業(yè)務(wù)的影響； 在架構(gòu) 1.0 中，當(dāng) Hive 集群與 GP 集群需要擴(kuò)容更新時(shí)，配置修改后一般需要較長(zhǎng)時(shí)間集群才可恢復(fù)，用戶感知比較明顯。而 Doris 很好的解決了這個(gè)問題，實(shí)現(xiàn)用戶無(wú)感知擴(kuò)容，也降低了集群運(yùn)維的投入。
未來(lái)與展望
當(dāng)前在架構(gòu) 2.0 中的 Doris 集群在大數(shù)據(jù)平臺(tái)中的角色更傾向于查詢優(yōu)化，大部分?jǐn)?shù)據(jù)還集中維護(hù)在 Hive 集群上，未來(lái)我們計(jì)劃在升級(jí)架構(gòu) 3.0 的時(shí)候，完成以下改造：
- 實(shí)時(shí)全量數(shù)據(jù)接入：利用 Flink 將所有的實(shí)時(shí)數(shù)據(jù)直接接入 Doris，不再經(jīng)過 ES 存儲(chǔ)；
- 數(shù)據(jù)集數(shù)據(jù)完整性：利用 Doris 構(gòu)建實(shí)時(shí)數(shù)據(jù)集市的原始層，利用 FlinkCDC 等同步工具將業(yè)務(wù)庫(kù) MySQL與決策過程中產(chǎn)生的 MongoDB 數(shù)據(jù)實(shí)時(shí)同步到 Doris，最大限度將現(xiàn)有數(shù)據(jù)都接入 Doris 的統(tǒng)一平臺(tái)，保證數(shù)據(jù)集數(shù)據(jù)完整性。
- 離線跑批任務(wù)遷移：將現(xiàn)有 Hive&Spark 中大部分跑批任務(wù)遷移至 Doris，提升跑批效率；
- 統(tǒng)一查詢分析出口：將所有的查詢分析統(tǒng)一集中到 Doris，完全統(tǒng)一數(shù)據(jù)出口，實(shí)現(xiàn)統(tǒng)一數(shù)據(jù)查詢網(wǎng)關(guān)，使數(shù)據(jù)的管理更加規(guī)范化；
- 強(qiáng)化集群穩(wěn)定擴(kuò)容：引入可視化運(yùn)維管理工具對(duì)集群進(jìn)行維護(hù)和管理，使 Doris 集群能夠更加穩(wěn)定支撐業(yè)務(wù)擴(kuò)展。
總結(jié)與致謝
Apache Doris 1.2 是社區(qū)在版本迭代中的重大升級(jí)，借助 Multi Catalog 等優(yōu)異功能能讓 Doris 在 Hadoop 相關(guān)的大數(shù)據(jù)體系中快速落地，實(shí)現(xiàn)聯(lián)邦查詢；同時(shí)可以將日常跑批與統(tǒng)計(jì)分析進(jìn)行解耦，有效提升大數(shù)據(jù)平臺(tái)的的查詢性能。
作為第一批 Apache Doris1.2 的用戶，我們深感榮幸，同時(shí)也十分感謝 Doris 團(tuán)隊(duì)的全力配合和付出，可以讓 Apache Doris 快速落地、上線生產(chǎn)，并為后續(xù)的迭代優(yōu)化提供了可能。
Apache Doris 1.2 值得大力推薦，希望大家都能從中受益，祝愿 Apache Doris 生態(tài)越來(lái)越繁榮，越來(lái)越好！
作者｜杭銀消金大數(shù)據(jù)團(tuán)隊(duì) 周其進(jìn)，唐海定， 姚錦權(quán)
