近年來，在證券服務(wù)逐漸互聯(lián)網(wǎng)化，以及券商牌照紅利逐漸消退的行業(yè)背景下，中信建投不斷加大對數(shù)字化的投入，尤其重視數(shù)據(jù)基礎(chǔ)設(shè)施的建設(shè)，期望在客戶服務(wù)、經(jīng)營管理等多方面由經(jīng)驗(yàn)依賴向數(shù)據(jù)驅(qū)動轉(zhuǎn)變，從而提高服務(wù)水平和決策效率。

因此，在公司總部和各分支機(jī)構(gòu)，包括經(jīng)紀(jì)、資管、投行等業(yè)務(wù)部門，以及稽核、審計(jì)、財(cái)務(wù)、法務(wù)等職能部門，對自助分析、多維分析、固定報(bào)表和 API 數(shù)據(jù)服務(wù)等形式的用數(shù)需求一直在不斷增長。

#01

需求背景

為了推動整體數(shù)字化建設(shè)和數(shù)據(jù)治理工作，中信建投已經(jīng)在2019年搭建了基于 Apache Hadoop (以下簡稱 Hadoop）體系的數(shù)據(jù)湖，將大量歷史數(shù)據(jù)遷移到 Hadoop 上，用 Apache Hive (以下簡稱 Hive）對數(shù)據(jù)進(jìn)行加工處理，所有的查詢計(jì)算都通過 Presto 執(zhí)行。但是，該方案在最近兩年數(shù)據(jù)量快速增長、業(yè)務(wù)場景多樣化發(fā)展的趨勢下逐漸無法適用。具體而言，中信建投目前在數(shù)據(jù)查詢分析中主要存在以下痛點(diǎn)和需求：

1）數(shù)據(jù)加工鏈路復(fù)雜

在數(shù)據(jù)分析的流程上，數(shù)據(jù)部門通常是首先用 Presto 做即席查詢，再通過 Hive 進(jìn)行數(shù)據(jù)加工，最后將加工過后的數(shù)據(jù)下發(fā)到各部門的 Oracle 或 MySQL 事務(wù)型數(shù)據(jù)庫，業(yè)務(wù)人員在事務(wù)數(shù)據(jù)庫里對下發(fā)數(shù)據(jù)進(jìn)行查詢和分析。整個(gè)過程需要在三套系統(tǒng)之間進(jìn)行數(shù)據(jù)交換，且三套系統(tǒng)使用的 SQL 語法也不一致，需要不同人員進(jìn)行開發(fā)維護(hù)，從而產(chǎn)生了多種問題：

• 數(shù)據(jù)開發(fā)和維護(hù)成本高

• 數(shù)據(jù)口徑可能不一致，導(dǎo)致數(shù)據(jù)應(yīng)用結(jié)果不準(zhǔn)確

• 用數(shù)需求難以得到及時(shí)滿足，通常要“T+1”才能給到數(shù)據(jù)報(bào)表

2）大數(shù)據(jù)量下性能不足，查詢響應(yīng)慢

中信建投目前大部分的數(shù)據(jù)都存儲在 Hive 中，業(yè)務(wù)部門在進(jìn)行自助分析時(shí)通常涉及的相關(guān)數(shù)據(jù)量較大，而 Presto 在大數(shù)據(jù)量、多表關(guān)聯(lián)查詢時(shí)會出現(xiàn)響應(yīng)比較慢，甚至無法獲得查詢結(jié)果的問題，無法滿足單表及多表復(fù)雜查詢場景下響應(yīng)的及時(shí)性。此外， Presto 因?yàn)橘Y源隔離不足會出現(xiàn)應(yīng)用搶占資源的情況，不能很好支持高并發(fā)的查詢請求。

3）大量實(shí)時(shí)數(shù)據(jù)分散在各個(gè)業(yè)務(wù)系統(tǒng)，無法進(jìn)行聯(lián)合分析

由于中信建投內(nèi)部存在非常多的業(yè)務(wù)系統(tǒng)，各業(yè)務(wù)系統(tǒng)相互獨(dú)立且數(shù)據(jù)會不斷更新，而這些實(shí)時(shí)數(shù)據(jù)無法更新到 Hive 中，導(dǎo)致業(yè)務(wù)數(shù)據(jù)之間不能及時(shí)打通進(jìn)行聯(lián)合分析。

4）缺少預(yù)計(jì)算能力加速固定查詢

固定報(bào)表和 API 數(shù)據(jù)服務(wù)為各業(yè)務(wù)提供包括數(shù)據(jù)匯總結(jié)果、明細(xì)查詢、數(shù)據(jù)接口在內(nèi)的多項(xiàng)能力，而基于固定數(shù)據(jù)查詢的可視化報(bào)表通常數(shù)據(jù)查詢量大、計(jì)算維度較多，一個(gè)看板頁面涉及大約一兩百個(gè) SQL 語句，整體運(yùn)算效率低下。針對這種情況，中信建投希望通過預(yù)計(jì)算實(shí)現(xiàn)查詢加速，并且要求開發(fā)工作輕量化且資源消耗較低。

#02

引入 StarRocks 構(gòu)建統(tǒng)一查詢服務(wù)平臺

通過綜合對比數(shù)據(jù)庫即席查詢、實(shí)時(shí)分析性能、預(yù)計(jì)算能力、數(shù)據(jù)聯(lián)邦技術(shù)，并且結(jié)合中信建投已經(jīng)在 Hadoop 體系中有大量投入，不希望做大規(guī)模數(shù)據(jù)搬遷的具體情況，將 Hive 外表查詢支持、SQL 語法及函數(shù)的兼容性等方面納入選型考慮，中信建投最終選擇引入 StarRocks 來構(gòu)建統(tǒng)一的查詢服務(wù)平臺，滿足各部門的用數(shù)需求。

作為一款高性能全場景的分析型數(shù)據(jù)庫，StarRocks 使用 MPP 架構(gòu)、可實(shí)時(shí)更新的列式存儲引擎等技術(shù)實(shí)現(xiàn)多維、實(shí)時(shí)、高并發(fā)的數(shù)據(jù)分析。StarRocks 既支持從各類實(shí)時(shí)和離線的外部數(shù)據(jù)源高效導(dǎo)入數(shù)據(jù)，也支持不做數(shù)據(jù)轉(zhuǎn)儲，便可直接通過外表形式分析查詢數(shù)據(jù)湖的數(shù)據(jù)，統(tǒng)一的 SQL 交互將數(shù)據(jù)分析結(jié)果或物化視圖預(yù)計(jì)算結(jié)果分發(fā)到各個(gè)數(shù)據(jù)應(yīng)用，為中信建投實(shí)現(xiàn)了三套系統(tǒng)使用功能的整合以及數(shù)據(jù)應(yīng)用流程的簡化。

具體而言，針對中信建投的痛點(diǎn)問題，StarRocks具備如下優(yōu)勢：

1）在性能方面

針對大規(guī)模數(shù)據(jù)下自助 BI 敏捷高效的需求，StarRocks 向量化執(zhí)行引擎，全面實(shí)現(xiàn)了 SIMD 指令，保證查詢和向量化導(dǎo)入可以充分利用單機(jī)單核 CPU 的處理能力；StarRocks 自研的 Pipeline 執(zhí)行引擎，使得 StarRocks 可以應(yīng)對更高的并發(fā)查詢，充分利用單機(jī)多核 CPU 的處理能力，與此同時(shí)可以更優(yōu)雅的進(jìn)行 CPU 時(shí)間分片調(diào)度從而實(shí)現(xiàn)資源隔離的功能；StarRocks 采用大規(guī)模并行處理（MPP）架構(gòu)，可以充分利用多機(jī)多核的集群資源，保證查詢性能可以線性擴(kuò)展；并用基于成本的優(yōu)化器 CBO、Runtime Filter、延遲物化、全局低基數(shù)字典等多種?段實(shí)現(xiàn)極致查詢性能。

2）在外部表聯(lián)邦查詢方面

StarRocks 可通過創(chuàng)建外部表的?式，在 StarRocks 讀取其他數(shù)據(jù)源，如 MySQL, Elasticsearch , Apache Hive 等外部表中的數(shù)據(jù)，從?打破數(shù)據(jù)的隔離。

以 Hive 外表功能為例，中信建投可以將其 Hive 中的離線數(shù)據(jù)導(dǎo)? StarRocks 中進(jìn)??性能分析查詢。同時(shí)，StarRocks 也可以支撐湖倉一體聯(lián)邦分析，將離線數(shù)據(jù)與實(shí)時(shí)數(shù)據(jù)進(jìn)?關(guān)聯(lián)，打通不同數(shù)據(jù)存儲間的壁壘，從??撐業(yè)務(wù)分析時(shí)在數(shù)據(jù)湖中進(jìn)?數(shù)據(jù)探查和極致分析的需求。

3）在預(yù)計(jì)算方面

為了實(shí)現(xiàn)固定報(bào)表的加速，StarRocks 引入預(yù)計(jì)算的手段，通過創(chuàng)建單表物化視圖，在保證明細(xì)查詢的同時(shí)可以加速聚合指標(biāo)查詢；通過多表物化視圖、外表物化視圖等方式，提供更靈活的按需建模能力，復(fù)用常見查詢有效優(yōu)化了復(fù)雜 SQL 計(jì)算效率，滿足用戶對固定維度聚合分析以及原始明細(xì)數(shù)據(jù)任意維度分析的多樣需求。

#03

落地后的效果與價(jià)值

1）大數(shù)據(jù)查詢性能得到顯著提升

采用 StarRocks 內(nèi)部表加速明細(xì)數(shù)據(jù)關(guān)聯(lián)查詢，實(shí)現(xiàn)了上億級別數(shù)據(jù)量大表關(guān)聯(lián)秒級響應(yīng)，內(nèi)表查詢效率提升10倍以上，外表查詢效率提升1倍以上，完全滿足大數(shù)據(jù)量下查詢分析及時(shí)響應(yīng)的需求；

2）預(yù)計(jì)算能力降低了固定報(bào)表加工成本

采用 StarRocks 預(yù)計(jì)算能力可以將固定報(bào)表和 API 數(shù)據(jù)服務(wù)響應(yīng)速度提升1倍以上。多表物化視圖、外表物化視圖、Query Rewrite 等高階功能，可以有效降低數(shù)據(jù)建模成本，使得“直面分析，按需加速”成為可能。

3）降低數(shù)據(jù)遷移成本，提升數(shù)據(jù)管理和使用效率

StarRocks 基于 Hive 外表做查詢，減少了底層數(shù)據(jù)的遷移成本，并實(shí)現(xiàn)了實(shí)時(shí)數(shù)據(jù)聯(lián)通分析。同時(shí)，以 StarRocks 為統(tǒng)一數(shù)據(jù)服務(wù)入口，降低了整體數(shù)據(jù)查詢和加工的復(fù)雜度，提升了數(shù)據(jù)管理和使用效率。

#04

項(xiàng)目經(jīng)驗(yàn)總結(jié)

中信建投進(jìn)行數(shù)字化轉(zhuǎn)型過程中已經(jīng)部署了大部分的數(shù)據(jù)基礎(chǔ)設(shè)施，但是已有的基于 Hadoop 構(gòu)建數(shù)據(jù)湖的體系在近兩年來暴露出眾多問題，已經(jīng)無法匹配業(yè)務(wù)的發(fā)展速度。中信建投基于自身業(yè)務(wù)需求和已有技術(shù)架構(gòu)情況選擇以 StarRocks 構(gòu)建統(tǒng)一數(shù)據(jù)服務(wù)入口的實(shí)踐，為同類型券商企業(yè)提供了以下經(jīng)驗(yàn)建議：

1）分析型數(shù)據(jù)庫的選型需要充分考慮企業(yè)自身的用數(shù)需求，以及現(xiàn)有數(shù)據(jù)平臺的技術(shù)架構(gòu)，選擇符合自身實(shí)際情況的數(shù)據(jù)庫是獲得較好的落地效果的關(guān)鍵。例如，中信建投大部分的數(shù)據(jù)都存儲在 Hive 中，StarRocks 提供的類 Presto 的外表查詢功能可以避免數(shù)據(jù)遷移增加的額外成本，同時(shí)也很好地滿足了公司的用數(shù)需求。

2）隨著企業(yè)數(shù)據(jù)庫規(guī)模不斷增長，以及分析場景更加復(fù)雜，分析型數(shù)據(jù)庫需要不斷提升數(shù)據(jù)查詢分析的性能，以及針對固定報(bào)表、自助 BI 等各種應(yīng)用場景，提供場景化解決方案、生態(tài)工具，才能滿足用戶在數(shù)據(jù)查詢分析方面功能和性能的復(fù)雜需求。

-關(guān)于StarRocks

StarRocks 是數(shù)據(jù)分析新范式的開創(chuàng)者、新標(biāo)準(zhǔn)的領(lǐng)導(dǎo)者。面世三年來，StarRocks 一直專注打造世界頂級的新一代極速全場景 MPP 數(shù)據(jù)庫，幫助企業(yè)建立“極速統(tǒng)一”的湖倉新范式，是實(shí)現(xiàn)數(shù)字化轉(zhuǎn)型和降本增效的關(guān)鍵基礎(chǔ)設(shè)施。

StarRocks 持續(xù)突破既有框架，以技術(shù)創(chuàng)新全面驅(qū)動用戶業(yè)務(wù)發(fā)展。當(dāng)前全球超過 200 家市值 70 億元以上的頭部企業(yè)都在基于 StarRocks 構(gòu)建新一代數(shù)據(jù)分析能力，包括騰訊、攜程、平安銀行、中原銀行、中信建投、招商證券、眾安保險(xiǎn)、大潤發(fā)、百草味、順豐、京東物流、TCL、OPPO 等，并與全球云計(jì)算領(lǐng)導(dǎo)者亞馬遜云、阿里云、騰訊云等達(dá)成戰(zhàn)略合作伙伴。

擁抱開源，StarRocks 全球開源社區(qū)飛速成長。截至 2022 年底，已有超過 200 位貢獻(xiàn)者，社群用戶近萬人，吸引幾十家國內(nèi)外行業(yè)頭部企業(yè)參與共建。項(xiàng)目在 GitHub 星數(shù)已超 3800 個(gè)，成為年度開源熱力值增速第一的項(xiàng)目，市場滲透率躋身中國前十名。