基於 StarRocks 的風控即時特征探索和實踐

背景

金融風控特征是在金融領域中用於評估和管理風險的關鍵指標。 它們幫助金融機構辨識潛在風險，降低損失，並采取措施規避風險。 例如，使用者最後一次授信送出時間就是一個重要的金融風控特征。

金融風控即時特征場景是一個典型的大數據即時業務場景。為了應對這一挑戰，風控團隊采用了業界常用的 Lambda 架構和 Kappa 架構。對於7天內的即時特征，使用 Kappa 架構；而對於超過7天的特征，則采用 Lambda 架構。

即時特征的 Lambda 架構

在 Lambda 架構中，所有原始數據都來自同一個資料來源（如日誌、業務 Binlog等），然後分為兩條鏈路進行處理。第一條是即時鏈路，透過流計算處理，將數據寫入即時儲存系統。第二條是離線鏈路，將數據處理並歸檔至 Hive。最後，在查詢層根據特定邏輯合並離線數據和即時數據，然後將結果輸出給套用方。為了提高吞吐量和並行效能，通常會在中間加入一層緩存。

然而，Lambda 架構也存在一些問題。首先，由於數據需要在多個系統中儲存，因此會增加冗余儲存的成本。其次，計算邏輯需要在流處理和批次處理兩個框架中分別實作和執行，導致開發成本較高。最後，由於計算邏輯分布在不同的框架中，因此在進行偵錯和問題排查時可能會比較復雜，從而增加了維護成本。

即時特征的 Kappa 架 構

Kappa 架構可以被視為Lambda架構的簡化版本，它去除了 Lambda 架構中的批次處理部份。在 Kappa 架構中，訊息佇列被用作一種儲存機制。當需要對數據進行修改或重新處理歷史數據時，只需從訊息佇列中重新讀取數據即可。這使得開發者只需維護一套流計算邏輯，從而降低了開發和運維成本。

然而，Kappa 架構也存在一些明顯的問題。首先，其能夠回溯的數據量受到訊息佇列儲存能力的限制。其次，流處理的重新計算吞吐量較低，可能導致回溯時間過長，特別是當需要回溯的數據量較大時。

在金融風控部門，離線和即時特征的開發由兩個不同的團隊負責。這進一步放大了 Lambda 架構存在的問題。對於同時包含即時和離線特征的需求，業務人員需要向兩個團隊提出需求，這不僅增加了溝通成本，而且更難保證邏輯的一致性。特征產出的時間取決於兩個團隊中最後一個完成任務的時間，如果其中一個團隊的任務出現延遲，那麽整個特征產出的時間也會相應延長，即使所需的邏輯非常簡單。在金融業務快速發展的背景下，這是一個亟待解決的問題。

盡管 Kappa 架構為解決這一問題提供了一種可能的解決方案，但由於其受到訊息佇列儲存能力和數據回溯時間長度的限制，它僅適用於短期狀態的場景。

Lambda 架構所引發問題的根本原因在於即時（流）和離線（批）處理是分開進行的。目前，業界普遍認為將流處理和批次處理合並為一種統一的處理方式是解決問題的有效方法，即所謂的「流批一體」。因此，我們的研究目標是 以盡可能低的成本找到實作流批一體的方案，以提高在即時和離線場景下特征開發的效率。

調研過程

在流批一體的研究方面，各大公司都有各自的探索方向。這些研究方向主要可以分為兩類：計算統一和儲存統一。計算統一旨在解決計算口徑的統一問題，希望透過一套邏輯既能執行批次處理又能執行流處理。而儲存統一則旨在解決數據孤島問題，防止同一份數據被分散儲存在不同的儲存引擎中。

計算統一方案

數據開發平台計算統一核心設計思路

上圖展示了公司數據開發平台以計算統一實作流批一體的核心設計思路。該平台利用 Flink 同時支持流處理和批次處理的能力，並與數夢平台的離線排程和即時運維相結合，使得一套 Flink SQL 既可以執行周期性的批次處理任務，也可以持續地進行即時計算。

然而，這種方案實際上仍然依賴於流批分離的基礎架構。雖然我們的流邏輯也是基於 Flink 實作的，但我們並沒有使用 Flink 的內建視窗邏輯，而是實作了一個與管理系統緊密整合的更為靈活的視窗架構。此外，我們的批次處理任務是基於 Spark 執行的。考慮到這種方案的修改成本較高，可能不適合解決當前風控面臨的問題，因此我們最終沒有選擇使用這種方案。

儲存統一方案

數據湖

數據湖方案

我們采集的數據會被統一儲存在一個數據湖中，並以增量的形式進行儲存。無論是使用 Hive、Spark 還是 Flink 進行查詢，都可以根據業務需求選擇一個合適的產品來進行操作，這樣既可以直接查詢即時數據，也可以直接查詢離線數據。

然而，數據湖也有一些缺點。首先，數據的增量寫入方式無法滿足即時性的要求。即使是開源的即時寫入方式，也只是以微批增量的形式進行，還無法完全滿足即時性的要求。其次，數據湖的查詢效能較低。由於整個方案本質上都是離線計算引擎，因此只能支持較低的並行，並且單次查詢的響應時間較長。

對於風控即時特征來說，通常對數據的延遲要求是秒級的，而對並行 QPS 的要求則是千級的。由於數據湖的數據寫入及時性和查詢效能都無法滿足風控即時特征場景的要求，因此我們放棄了這種方案。不過，這仍然可以作為初期的一種解決思路。

Hologres

Hologres 搭建即時數倉套用場景

Hologres 是阿裏巴巴自主研發的一站式即時數倉引擎，它能夠支持海量數據的即時寫入、即時更新、即時加工和實分時析。此外，它還支持標準的 SQL 語言（相容 PostgreSQL 協定和語法，支持大部份 PostgreSQL 函式），可以進行PB級數據的多維分析和即席分析，並提供高並行低延遲的線上數據服務。Hologres還支持多種負載的細粒度隔離和企業級安全能力，並與 MaxCompute、Flink、DataWorks 等產品深度融合，為企業提供了離線上一體化的全棧數倉解決方案。

在我們對 Hologres 的調研中，特別關註的是其官方定義中提到的「支持海量數據的即時寫入、即時加工、實分時析，且支持高並行低延遲的線上數據服務」。我們認為 Hologres 非常適合風控業務的場景，而且已經有公司將其作為實作即時數倉和解決流批一體問題的方案。

不過 Hologres 並未開源，我們公司內部也尚未引入這項技術。因此，使用 Hologres 作為我們的解決方案的可行性較低。

StarRocks OR ClickHouse

受 Hologres 即時數倉架構的啟發，結合風控的實際業務場景，我們發現我們更需要的是一個高效能的 OLAP 引擎。除了基本的運維效能外，該引擎還需要具備即時寫入、即時更新、實分時析、高並行和低延遲等特性，最好是我們公司大數據生態圈內的產品。經過篩選，我們最終在 StarRocks 和 ClickHouse 之間做出選擇，並在下面的表格中對它們的關鍵功能進行了對比。

StarRocks 是一款高效能的分析型資料倉儲，它使用了向量化、MPP架構、CBO、智慧物化檢視和可即時更新的列式儲存引擎等技術，實作了多維、即時和高並行的數據分析。StarRocks 既支持從各種即時和離線的資料來源高效匯入數據，也支持直接分析數據湖上各種格式的數據。StarRocks 相容 MySQL 協定，可以使用 MySQL 客戶端和常用的BI工具進行連線。同時，StarRocks 還具有水平擴充套件、高可用、高可靠和易運維等特性。它廣泛套用於即時數倉、OLAP報表和數據湖分析等場景。

在上表中，我們根據風控業務場景，對 StarRocks 和 ClickHouse 的關註功能進行了對比，基於各個維度的綜合考量，我們最終決定使用 StarRocks 作為我們的落地驗證選項。

StarRocks 驗證

為了驗證 StarRocks 在即時特征方面的可行性，我們遵循最小試錯成本的原則，從流程可行性、查詢效能可行性和數據寫入效能可行性等方面進行了驗證。

在這次驗證中，我們選擇了具有最多即時和離線特征的授信表作為資料來源，其數據量達到了億級，大小超過了20GB。

數據匯入

批次數據匯入 S tarRocks 流程

效果

即時數據匯入 S tarRocks 流程

效果

查詢效率

因為 StarRocks 支持 MySQL 協定，所以可以直接使用 MySQL 客戶端進行連線查詢。

下表為各個場景下客戶端單查效率：

並行效能

為盡快獲得 StarRocks 的壓測結果，我們利用了公司數鏈平台已經支持的查詢 StarRocks 服務功能，從而在不開發伺服端的情況下對 StarRocks 進行壓測。

我們的 StarRocks 集群配置是國內測試集群（3FE+5BE），測試場景是命中字首索引。

當壓力測試達 到 1500 QPS 時，數鏈服務承受了較大的壓力，因此我們不得不停止測試，未能獲得二級索引和未命中索引場景的測試數據。 我們統計了當月13天的即時和離線特征的最大 QPS 為 1109。

透過對數據匯入、查詢效能和並行效能等方面的驗證，我們對 StarRocks 的效能有了初步認識，並且驗證結果可達到服務即時特征的標準。因此，我們最終決定使用 StarRocks 實作流批一體，以解決風控即時特征流批分離的問題。

落地實作

架構設計

基於 StarRocks 新特征架構

在本次新增的模組中，數據層被劃分為兩個部份：全量部份（Batch）和增量部份（Stream）。全量部份將業務的存量數據一次性匯入到 StarRocks 中，而增量部份則即時地將業務的變更數據匯入到 StarRocks 的同一表中。

代理層和服務層是現有技術架構中的模組。在服務層中，我們添加了支持對 StarRocks 服務查詢的功能，這樣就可以透過一個 SQL 邏輯來查詢業務表相關的即時特征，從而達到預期的目標。這一變化對上層套用方是無感知的。

初步驗證之後，我們在服務層中實作了對 StarRock s查詢特征的支持，並申請了一個獨立的 StarRocks 集群（包括3個前端節點和5個後端節點）。

表設計

構建映像表

從資料來源維度可將數據區分為日誌類數據和業務類數據兩種。

StarRocks 本質上是一個結構化的資料庫，其中的主鍵模型設計實作很適用於數據即時和頻繁更新的場景，因此非常適合用作業務表的映像表。這樣一來，我們就可以在一個儲存引擎上處 理業務表的全量數據，實作流批一體的效果。使用映像表的另一個優點是，業務人員提供的業務表 SQL 邏輯可以直接套用於特征開發，無需進行任何邏輯轉換，從而降低了邏輯失真的風險。

然而，StarRocks 映像表的設計方案目前只能解決以業務資料庫為資料來源的特征實作問題。由於日誌類數據是非結構化和半結構化的，且具有時間維度增量等特性，我們尚未找到一種使用 StarRocks 實作的高效靈活的解決方案。

不過目前所有的即時和離線特征中，以業務數據為資料來源的特征占比高達86%，StarRocks 映像表方案依舊有很大的實際套用價值。

分桶欄位設計

為提高查詢效率，StarRocks 采用了分區、分桶、算子向量化、CBO 最佳化器、 MPP 架構和 Pipeline 等設計。此外，其主鍵模型透過 delete-and-insert 更新方式提高了更新的即時性。為了使 StarRocks 發揮更好的效能，我們針對風控特征業務場景客製設計了 StarRocks 表。

在風控特征查詢場景中，大部份是高並行點查場景，特征的查詢參數相對統一，通常是uid（使用者ID）或bizId（訂單號）等。例如，使用者最後一次授信送出時間特征，是透過uid在授信業務表中查詢使用者對應的授信資訊來獲取最近一次授信時間。

一般引擎會透過建立索引來提高查詢效率。傳統資料庫索引設計的目的是盡快定位到數據，但在大數據場景下，索引的主要目的是如何在大量數據中盡可能排除無關數據，然後在少量數據中定位到要查詢的數據。

StarRocks 的分桶設計就是為實作這個目的。在表設計中，我們將 uid 或 bizId 等作為查詢參數的欄位進行哈希分桶，因為這些欄位的基數都很大，不會出現數據傾斜現象。假設分桶數為N，當查詢參數中包含分桶鍵欄位時，每次查詢可以排除掉N-1/N的數據量，從而提高查詢效率。

雖然分桶可以提高查詢效率，但過多的分桶會導致後設資料壓力較大，數據匯入匯出也會受到影響。我們根據官網推薦的「每個分桶的大小建議在100M-1G之間」（2.3版本）來設定分桶數，為了適應數據增長，通常會偏向下線一點。

如果將多個欄位作為分桶鍵，每次查詢必須帶上所有的分桶鍵才能利用分桶的優勢，這將降低靈活性和分桶利用率。所以，在表的分桶設計中，我們只使用一個欄位進行分桶，這也更適合特征的點查場景。

服務表現

常規表現

按照已有即時+離線特征配置了同邏輯的34個 StarRocks 特征用於空跑驗證。

壓測表現

從伺服端壓力測試結果來看，在高並行環境下，StarRocks 在處理分桶索引和索引連線表的場景時表現良好，但在處理二級索引和非索引場景時則表現欠佳。

由於特征查詢通常涉及高並行，因此在使用 StarRocks 提供特征服務時，我們主要依賴其能夠高效處理分桶索引和索引連線表的能力。幸運的是，在特征業務中，一個業務表產生的特征查詢參數相對統一，通常是 uid 或 bizId。這意味著每個業務表可以作為分桶鍵的欄位是相對固定的。然而，如果確實出現了同一業務表的不同特征查詢參數不一致的情況，我們可以采用「以空間換時間」的策略，即建立一個新的表，該表與原有表的結構相同，但分桶鍵不同。

為了確保使用者僅能配置命中分桶鍵的特征，我們在特征管理頁面上將 StarRocks 表與其分桶鍵進行繫結。當使用者選擇某個 StarRocks 表後，查詢參數中的分桶鍵欄位將成為必選項。

更新及時

制作一個特征 「select now() - max(update_time)」， 透過獲取當前時間和表中最大可查數據更新時間的差值來統計 StarRocks 的更新及時性。

收益分析

效率提升

上述表格展示了兩個真實的即時和離線需求排期耗時。使用 StarRocks 特征配置可以將效率提高80%以上。

在原有的開發模式下，即時和離線特征的離線部份通常需要等待資源排期，等待時間在2天到7天之間，因此需求的平均交付周期約為5天。而采用 StarRocks 開發，由於不再依賴離線排期，極大地縮短了開發周期。

能力提升

1、數據準確性變高

2、即時特征能力增強

3、特征加工難度降低

4、特征所需資源可控

未來規劃

StarRocks 支持 MySQL 協定並支持即席查詢，這降低了特征配置的學習成本，提高了系統的容錯性。我們將鼓勵業務人員自主配置和驗證特征，以進一步提高工作效率，更快速地支持業務發展。

雖然 StarRocks 的特征功能已經上線，但目前我們只有一個獨立的集群提供特征服務，其容災能力還有待提高。未來，我們將增加備用集群或對集群進行分級特征管理，以提高服務的穩定性。

此外，我們使用 StarRocks 的設計主要解決了以業務表作為資料來源的流批一體實作問題。然而，對於以日誌或埋點作為資料來源的場景，由於數據結構不穩定且數據量巨大等因素，我們尚未找到比 Lambda 架構更好的替代方案。面對這一挑戰，我們將持續探索新的解決方案。