數(shù)據(jù)庫StarRocks在信也科技的應(yīng)用實踐，打造統(tǒng)一銷售數(shù)據(jù)平臺

信也科技是在紐交所上市的金融科技集團，致力于通過大數(shù)據(jù)、人工智能、區(qū)塊鏈等技術(shù)實現(xiàn)“科技，讓金融更美好”的使命，推動金融服務(wù)從可獲得進一步向可負擔(dān)、可信任和可享受進化，成為受用戶歡迎、受伙伴信任的金融科技品牌。信也科技旗下包括金融科技業(yè)務(wù)、國際業(yè)務(wù)、科技生態(tài)孵化業(yè)務(wù)三大板塊，具體涵蓋消費金融、科技輸出、孵化器和投資等業(yè)務(wù)，堅持以創(chuàng)新技術(shù)服務(wù)大眾、賦能機構(gòu)，助力實體經(jīng)濟發(fā)展。

一、業(yè)務(wù)背景

公司銷售業(yè)務(wù)快速發(fā)展，用戶對多維數(shù)據(jù)分析的實時性要求越來越高，場景也變化多樣，業(yè)務(wù)的復(fù)雜性和多樣性給公司研發(fā)和運維成本帶來很大的挑戰(zhàn)。與此同時開源數(shù)據(jù)分析引擎也是百花齊放，日新月異。信也科技實時數(shù)據(jù)團隊致力于研發(fā)效率最大化，選擇一款合適高效的存儲引擎就尤為重要。信也科技通過引入新一代性能彪悍的MPP架構(gòu)數(shù)據(jù)庫StarRocks來構(gòu)建實時數(shù)倉平臺，進行實時數(shù)據(jù)分析，提供統(tǒng)一的數(shù)據(jù)服務(wù);降低業(yè)務(wù)使用復(fù)雜度，提升用戶體驗，實現(xiàn)生產(chǎn)效率最大化。

二、原有架構(gòu)及痛點

銷售數(shù)據(jù)平臺初期分四個子項目：

銷售APP系統(tǒng)：實時消費業(yè)務(wù)庫Binlog數(shù)據(jù)，通過Flink實時消費清洗，計算不同維度下的銷售訂單和業(yè)績等指標，按時、按天、按月等時間維度進行實時計算，數(shù)據(jù)落到MySQL/MongoDB。

銷售智能地圖系統(tǒng)：為了更好的分析銷售行為和跟蹤銷售軌跡，關(guān)注銷售的訂單，業(yè)績等指標，數(shù)據(jù)經(jīng)過流轉(zhuǎn)和清洗完之后，除了發(fā)一份數(shù)據(jù)到MySQL之外，最后還要推送一份數(shù)據(jù)到Elasticsearch中，引入Elasticsearch的原因一是用到地圖GEO函數(shù)，二是靈活地支持多種維度查詢。

銷售實時大盤：清洗完的數(shù)據(jù)(訂單、業(yè)績等)發(fā)送到消息中間件，然后落到Redis、MySQL等存儲系統(tǒng)中供前端使用。

銷售消息推送系統(tǒng)：數(shù)據(jù)(訂單、業(yè)績)經(jīng)過清洗之后，會發(fā)一份數(shù)據(jù)到ClickHouse中，最后實時推送數(shù)據(jù)，以滿足不同的場景。

為了快速響應(yīng)業(yè)務(wù)需求，滿足不同的業(yè)務(wù)場景，團隊選擇不同技術(shù)方案來快速滿足業(yè)務(wù)需求，項目的初期很好的滿足了業(yè)務(wù)需求，隨著時間的推移，數(shù)據(jù)量和業(yè)務(wù)功能變的越來越復(fù)雜，同時業(yè)務(wù)口徑變更和新需求的不斷提出，項目的維護成本和痛點就越來越明顯：

同一份數(shù)據(jù)存儲多份，浪費存儲資源。

新需求或需求變更所涉及的團隊和數(shù)據(jù)存儲，數(shù)據(jù)服務(wù)比較多，溝通成本和研發(fā)成本相應(yīng)增加。

多層級組織架構(gòu)下進行計算和統(tǒng)計分析業(yè)績、訂單、標的等指標，這些指標在不斷變化的維度和不同的計算口徑下給系統(tǒng)帶來很大的挑戰(zhàn)，很難快速響應(yīng)業(yè)務(wù)需求。

多種存儲引擎和多套數(shù)據(jù)服務(wù)帶來巨大的運維成本和整體系統(tǒng)的不穩(wěn)定性因素和隱患也相應(yīng)增加。

三、OLAP引擎選擇

根據(jù)目前的業(yè)務(wù)痛點和業(yè)務(wù)本身對數(shù)據(jù)多維分析查詢的要求，以及能適應(yīng)公司未來在線實時查詢需要，我們選擇一款OLAP引擎要有幾點要求：

·低延遲的毫秒級響應(yīng)，數(shù)據(jù)秒級寫入。

·運維簡單，易用性強。

·復(fù)雜的場景查詢。

·明細數(shù)據(jù)查詢。

·多表關(guān)聯(lián)查詢性能好。

·支持高并發(fā)。

·對地圖函數(shù)有支持。

·要有物化視圖的能力。

StarRocks

優(yōu)勢：

·支持標準SQL，兼容MySQL協(xié)議以及分布式Join。

·水平擴展，不依賴外部組件，方便縮擴容。

·支持多種聚合算子，物化視圖。

·MPP架構(gòu)，分片分桶的復(fù)合存儲模型。

·支持高并發(fā)查詢，QPS可達千、萬量級。

·支持寬表和多表Join查詢，數(shù)據(jù)查詢秒級/毫秒級。

·支持地圖GEO函數(shù)。

·運維簡單，易用性強。

·復(fù)雜的場景查詢。

劣勢：

·缺乏單列數(shù)據(jù)更新能力。

·周邊生態(tài)還不是很完善。

ClickHouse

優(yōu)勢：

·數(shù)據(jù)壓縮，多核并行處理，單表性能極佳。

·向量引擎，稀疏索引，適合在線查詢。

·支持數(shù)據(jù)復(fù)制和數(shù)據(jù)完整性。

·支持地圖GEO函數(shù)。

劣勢：

·沒有完整的事務(wù)支持以及多表Join不友好。

·對修改或刪除數(shù)據(jù)的能力支持不夠，MergeTree合并不完全。

·并發(fā)能力不高。

·依賴Zookeeper，在集群擴大時ZK會成為性能瓶頸。

TiDB/TiFlash

優(yōu)勢：

·數(shù)據(jù)壓縮，多核并行處理，單表性能極佳。

·支持標準SQL，兼容MySQL協(xié)議以及分布式Join。

·TiFlash預(yù)處理加速OLAP分析。

·TiDB計算、存儲分離，高可用模式，運維依賴于自動化運維工具，易操作。

·支持高并發(fā)查詢。

劣勢：

·強依賴SSD，硬件成本比較高。

·OLAP場景下查詢性能相對弱一些。

·不支持實時預(yù)聚合。

·不支持地圖GEO函數(shù)。

早期應(yīng)用的OLAP引擎各自有一些功能局限，無法滿足我們的需求。如Presto、Impala無法提供低延遲亞秒級響應(yīng)，Druid不提供明細查詢，Kylin無法基于明細提供毫秒級查詢，更多場景是預(yù)計算，運維成本也比較高。這次通過對比StarRocks、TiDB/TiFlash、ClickHouse這些當下性能卓越的開源引擎，我們基本上鎖定了StarRocks作為我們新一代的MPP架構(gòu)的OLAP引擎。

四、銷售平臺現(xiàn)有架構(gòu)

引入StarRocks后，架構(gòu)如下圖所示：

數(shù)據(jù)采集

線上關(guān)系型業(yè)務(wù)庫數(shù)據(jù)通過Canal實時采集MySQL Binlog到Kafka，離線數(shù)據(jù)通過Sqoop/DataX工具導(dǎo)入到HDFS中，埋點數(shù)據(jù)通過自定義Kafka的Log Appender，數(shù)據(jù)會實時寫入Kafka，供下游消費。

數(shù)據(jù)中轉(zhuǎn)

Kafka作為業(yè)務(wù)庫實時數(shù)據(jù)的中轉(zhuǎn)站，保留一定時間的數(shù)據(jù)，作為實時數(shù)倉的ODS，為下游計算準備數(shù)據(jù)，HDFS作為業(yè)務(wù)庫歷史數(shù)據(jù)中轉(zhuǎn)站，是一次性的數(shù)據(jù)，保留一段時間后可以刪除，節(jié)省成本。

數(shù)據(jù)處理

實時數(shù)據(jù):根據(jù)需求，我們通過Flink實時消費Kafka數(shù)據(jù)進行數(shù)據(jù)清洗、關(guān)聯(lián)、處理等操作，然后通過Flink-StarRocks Connector把數(shù)據(jù)落到StarRocks中。

離線數(shù)據(jù)：通過HDFS調(diào)度平臺對離線數(shù)據(jù)進行清洗、處理，然后通過StarRocks導(dǎo)入工具把數(shù)據(jù)一次性落入到StarRocks中。另外，我們的業(yè)務(wù)數(shù)據(jù)也會更新變化，比如訂單狀態(tài)等，我們選擇更新模型來滿足需求。

實時數(shù)倉

實時數(shù)倉層的數(shù)據(jù)根據(jù)數(shù)據(jù)倉庫典型邏輯分層劃分為ODS、DWD、DWS、DIM等層，不同分層的數(shù)據(jù)，可以通過Flink實時計算直接落庫，也可以通過離線調(diào)度平臺進行分鐘級或小時級的調(diào)度計算，當然也可以利用StarRocks本身的物化視圖，這個要根據(jù)不同場景進行選擇。總體來說我們會利用StarRocks極速的OLAP查詢能力(分區(qū)分桶，向量化計算，列式存儲，MPP架構(gòu))和不同的數(shù)據(jù)模型(明細模型、聚合模型和更新模型)來滿足不同場景的數(shù)據(jù)分析需求。

數(shù)據(jù)服務(wù)

目前這套架構(gòu)通過兩種方式對外提供服務(wù)，一是提供數(shù)據(jù)服務(wù)接口供各個應(yīng)用方使用，二是把數(shù)據(jù)發(fā)送到消息中間層(公司自研消息中間件)供下游使用。目前數(shù)據(jù)主要面向管理層、運營人員、B端用戶，數(shù)據(jù)查詢要求低延遲，需求變化快，而StarRocks通過極速的性能、高并發(fā)低延遲的特性以及靈活的建模方式很好滿足了這些用戶的數(shù)據(jù)需求。

銷售應(yīng)用

基于目前銷售數(shù)據(jù)我們在上層構(gòu)建了各種應(yīng)用，比如APP后端系統(tǒng)、實時大盤、哨兵系統(tǒng)、智能地圖、運營推薦系統(tǒng)等，來滿足業(yè)務(wù)方的需求。

可以看到，引入StarRocks之后，新架構(gòu)具有如下的優(yōu)點：

·統(tǒng)一數(shù)據(jù)存儲計算引擎，有助于打破數(shù)據(jù)壁壘，實現(xiàn)數(shù)據(jù)價值最大化。

·統(tǒng)一數(shù)據(jù)管理，降低管理復(fù)雜度，提升數(shù)據(jù)安全性。

·統(tǒng)一數(shù)據(jù)服務(wù)計算，復(fù)用已有接口，研發(fā)效率最大化。

·靈活多變的維度組合查詢，快速響應(yīng)業(yè)務(wù)需求。

五、StarRocks運維

基于Prometheus+Grafana進行監(jiān)控

除了StarRocks本身提供的Manager管理功能，StarRocks也提供了基于Prometheus+Grafana的可視化監(jiān)控方案。Prometheus通過Pull方式訪問FE/BE的Metric接口，將監(jiān)控數(shù)據(jù)存入時序數(shù)據(jù)庫，然后通過Grafana配置Prometheus為數(shù)據(jù)源，自定義繪制Dashboard。通過這套方案，我們初步搭建了StarRocks運維監(jiān)控體系來保障線上服務(wù)。

基于日志的審計監(jiān)控

SQL慢查詢，響應(yīng)時間長，不規(guī)范的SQL會給整個平臺帶來不穩(wěn)定的因素，另外還有些大批數(shù)據(jù)導(dǎo)入可能會帶來短時間的CPU、IO等壓力，這些操作我們都需要監(jiān)控到，避免帶來不必要的麻煩，目前我們是通過FileBeat去采集FE上審計日志信息，然后插入ClickHouse，然后在Grafana上展示出來，對這些SQL進行分析和監(jiān)控，以便可以更好的進行優(yōu)化。

六、未來規(guī)劃

StarRocks作為新一代極速全場景MPP數(shù)據(jù)庫，引入了StarRocks之后，實現(xiàn)了統(tǒng)一存儲，統(tǒng)一服務(wù)，并且在多種場景下表現(xiàn)出色，幫我們實現(xiàn)了產(chǎn)出價值最大化。未來我們對StarRocks也進行了一定的規(guī)劃：

根據(jù)業(yè)務(wù)場景不同，對響應(yīng)時間要求不同，搭建多套StarRocks集群，進行物理資源隔離。

將更多的在線實時任意多維度分析業(yè)務(wù)遷移到StarRocks，打造統(tǒng)一的實時數(shù)倉平臺。

數(shù)倉體系升級加速，提升用戶極速體驗，探索使用StarRocks打造實時數(shù)倉和離線數(shù)倉融合和一體化建設(shè)。

打通數(shù)據(jù)接入平臺和數(shù)據(jù)開發(fā)平臺，完善運維監(jiān)控體系，保證大數(shù)據(jù)基礎(chǔ)服務(wù)的穩(wěn)定性。(作者：余榮幸，信也科技大數(shù)據(jù)資深專家)

來源：中國資訊報道網(wǎng)