資料庫StarRocks在信也科技的應用實踐，打造統一銷售數據平臺
2025-05-03 21:09:25
信也科技是在紐交所上市的金融科技集團，致力於通過大數據、人工智慧、區塊鏈等技術實現「科技，讓金融更美好」的使命，推動金融服務從可獲得進一步向可負擔、可信任和可享受進化，成為受用戶歡迎、受夥伴信任的金融科技品牌。信也科技旗下包括金融科技業務、國際業務、科技生態孵化業務三大板塊，具體涵蓋消費金融、科技輸出、孵化器和投資等業務，堅持以創新技術服務大眾、賦能機構，助力實體經濟發展。
一、業務背景
公司銷售業務快速發展，用戶對多維數據分析的實時性要求越來越高，場景也變化多樣，業務的複雜性和多樣性給公司研發和運維成本帶來很大的挑戰。與此同時開源數據分析引擎也是百花齊放，日新月異。信也科技實時數據團隊致力於研發效率最大化，選擇一款合適高效的存儲引擎就尤為重要。信也科技通過引入新一代性能彪悍的MPP架構資料庫StarRocks來構建實時數倉平臺，進行實時數據分析，提供統一的數據服務；降低業務使用複雜度，提升用戶體驗，實現生產效率最大化。
二、原有架構及痛點
銷售數據平臺初期分四個子項目：
銷售APP系統：實時消費業務庫Binlog數據，通過Flink實時消費清洗，計算不同維度下的銷售訂單和業績等指標，按時、按天、按月等時間維度進行實時計算，數據落到MySQL/MongoDB。
銷售智能地圖系統：為了更好的分析銷售行為和跟蹤銷售軌跡，關註銷售的訂單，業績等指標，數據經過流轉和清洗完之後，除了發一份數據到MySQL之外，最後還要推送一份數據到Elasticsearch中，引入Elasticsearch的原因一是用到地圖GEO函數，二是靈活地支持多種維度查詢。
銷售實時大盤：清洗完的數據（訂單、業績等）發送到消息中間件，然後落到Redis、MySQL等存儲系統中供前端使用。
銷售消息推送系統：數據（訂單、業績）經過清洗之後，會發一份數據到ClickHouse中，最後實時推送數據，以滿足不同的場景。
為了快速響應業務需求，滿足不同的業務場景，團隊選擇不同技術方案來快速滿足業務需求，項目的初期很好的滿足了業務需求，隨著時間的推移，數據量和業務功能變的越來越複雜，同時業務口徑變更和新需求的不斷提出，項目的維護成本和痛點就越來越明顯：
同一份數據存儲多份，浪費存儲資源。
新需求或需求變更所涉及的團隊和數據存儲，數據服務比較多，溝通成本和研發成本相應增加。
多層級組織架構下進行計算和統計分析業績、訂單、標的等指標，這些指標在不斷變化的維度和不同的計算口徑下給系統帶來很大的挑戰，很難快速響應業務需求。
多種存儲引擎和多套數據服務帶來巨大的運維成本和整體系統的不穩定性因素和隱患也相應增加。
三、OLAP引擎選擇
根據目前的業務痛點和業務本身對數據多維分析查詢的要求，以及能適應公司未來在線實時查詢需要，我們選擇一款OLAP引擎要有幾點要求：
·低延遲的毫秒級響應，數據秒級寫入。
·運維簡單，易用性強。
·複雜的場景查詢。
·明細數據查詢。
·多表關聯查詢性能好。
·支持高並發。
·對地圖函數有支持。
·要有物化視圖的能力。
StarRocks
優勢：
·支持標準SQL，兼容MySQL協議以及分布式Join。
·水平擴展，不依賴外部組件，方便縮擴容。
·支持多種聚合算子，物化視圖。
·MPP架構，分片分桶的複合存儲模型。
·支持高並發查詢，QPS可達千、萬量級。
·支持寬表和多表Join查詢，數據查詢秒級/毫秒級。
·支持地圖GEO函數。
·運維簡單，易用性強。
·複雜的場景查詢。
劣勢：
·缺乏單列數據更新能力。
·周邊生態還不是很完善。
ClickHouse
優勢：
·數據壓縮，多核並行處理，單表性能極佳。
·向量引擎，稀疏索引，適合在線查詢。
·支持數據複製和數據完整性。
·支持地圖GEO函數。
劣勢：
·沒有完整的事務支持以及多表Join不友好。
·對修改或刪除數據的能力支持不夠，MergeTree合併不完全。
·並發能力不高。
·依賴Zookeeper，在集群擴大時ZK會成為性能瓶頸。
TiDB/TiFlash
優勢：
·數據壓縮，多核並行處理，單表性能極佳。
·支持標準SQL，兼容MySQL協議以及分布式Join。
·TiFlash預處理加速OLAP分析。
·TiDB計算、存儲分離，高可用模式，運維依賴於自動化運維工具，易操作。
·支持高並發查詢。
劣勢：
·強依賴SSD，硬體成本比較高。
·OLAP場景下查詢性能相對弱一些。
·不支持實時預聚合。
·不支持地圖GEO函數。
早期應用的OLAP引擎各自有一些功能局限，無法滿足我們的需求。如Presto、Impala無法提供低延遲亞秒級響應，Druid不提供明細查詢，Kylin無法基於明細提供毫秒級查詢，更多場景是預計算，運維成本也比較高。這次通過對比StarRocks、TiDB/TiFlash、ClickHouse這些當下性能卓越的開源引擎，我們基本上鎖定了StarRocks作為我們新一代的MPP架構的OLAP引擎。
四、銷售平臺現有架構
引入StarRocks後，架構如下圖所示：
數據採集
線上關係型業務庫數據通過Canal實時採集MySQL Binlog到Kafka，離線數據通過Sqoop/DataX工具導入到HDFS中，埋點數據通過自定義Kafka的Log Appender，數據會實時寫入Kafka，供下遊消費。
數據中轉
Kafka作為業務庫實時數據的中轉站，保留一定時間的數據，作為實時數倉的ODS，為下遊計算準備數據，HDFS作為業務庫歷史數據中轉站，是一次性的數據，保留一段時間後可以刪除，節省成本。
數據處理
實時數據:根據需求，我們通過Flink實時消費Kafka數據進行數據清洗、關聯、處理等操作，然後通過Flink-StarRocks Connector把數據落到StarRocks中。
離線數據：通過HDFS調度平臺對離線數據進行清洗、處理，然後通過StarRocks導入工具把數據一次性落入到StarRocks中。另外，我們的業務數據也會更新變化，比如訂單狀態等，我們選擇更新模型來滿足需求。
實時數倉
實時數倉層的數據根據數據倉庫典型邏輯分層劃分為ODS、DWD、DWS、DIM等層，不同分層的數據，可以通過Flink實時計算直接落庫，也可以通過離線調度平臺進行分鐘級或小時級的調度計算，當然也可以利用StarRocks本身的物化視圖，這個要根據不同場景進行選擇。總體來說我們會利用StarRocks極速的OLAP查詢能力（分區分桶，向量化計算，列式存儲，MPP架構）和不同的數據模型（明細模型、聚合模型和更新模型）來滿足不同場景的數據分析需求。
數據服務
目前這套架構通過兩種方式對外提供服務，一是提供數據服務接口供各個應用方使用，二是把數據發送到消息中間層（公司自研消息中間件）供下遊使用。目前數據主要面向管理層、運營人員、B端用戶，數據查詢要求低延遲，需求變化快，而StarRocks通過極速的性能、高並發低延遲的特性以及靈活的建模方式很好滿足了這些用戶的數據需求。
銷售應用
基於目前銷售數據我們在上層構建了各種應用，比如APP後端系統、實時大盤、哨兵系統、智能地圖、運營推薦系統等，來滿足業務方的需求。
可以看到，引入StarRocks之後，新架構具有如下的優點：
·統一數據存儲計算引擎，有助於打破數據壁壘，實現數據價值最大化。
·統一數據管理，降低管理複雜度，提升數據安全性。
·統一數據服務計算，復用已有接口，研發效率最大化。
·靈活多變的維度組合查詢，快速響應業務需求。
五、StarRocks運維
基於Prometheus+Grafana進行監控
除了StarRocks本身提供的Manager管理功能，StarRocks也提供了基於Prometheus+Grafana的可視化監控方案。Prometheus通過Pull方式訪問FE/BE的Metric接口，將監控數據存入時序資料庫，然後通過Grafana配置Prometheus為數據源，自定義繪製Dashboard。通過這套方案，我們初步搭建了StarRocks運維監控體系來保障線上服務。
基於日誌的審計監控
SQL慢查詢，響應時間長，不規範的SQL會給整個平臺帶來不穩定的因素，另外還有些大批數據導入可能會帶來短時間的CPU、IO等壓力，這些操作我們都需要監控到，避免帶來不必要的麻煩，目前我們是通過FileBeat去採集FE上審計日誌信息，然後插入ClickHouse，然後在Grafana上展示出來，對這些SQL進行分析和監控，以便可以更好的進行優化。
六、未來規劃
StarRocks作為新一代極速全場景MPP資料庫，引入了StarRocks之後，實現了統一存儲，統一服務，並且在多種場景下表現出色，幫我們實現了產出價值最大化。未來我們對StarRocks也進行了一定的規劃：
根據業務場景不同，對響應時間要求不同，搭建多套StarRocks集群，進行物理資源隔離。
將更多的在線實時任意多維度分析業務遷移到StarRocks，打造統一的實時數倉平臺。
數倉體系升級加速，提升用戶極速體驗，探索使用StarRocks打造實時數倉和離線數倉融合和一體化建設。
打通數據接入平臺和數據開發平臺，完善運維監控體系，保證大數據基礎服務的穩定性。（作者：餘榮幸，信也科技大數據資深專家）
