來源：之家技術

1. 前言

對賬是企業為了核實財務交易準確性、管理庫存和了解業務績效而進行的核對和調解過程。

因為對賬涉及到支付系統、訂單系統、財務系統、結算系統和權益系統等多個系統，需要確保這些系統的資料能夠有效地對應和匹配，需要一種高效可靠的方式以解決跨系統的資料匹配。

2. 支付閉環

2.1

支付背後隱藏的細節。

一筆訂單的完結，C端使用者看到的僅僅是下單、支付簡單的流程，實際上背後有一套更復雜的流程實現支付的閉環。比如支付成功通知、訂單結算分賬、結算成功通知、賬務處理與報表生成等，以下是一個簡化的支付閉環流程：

3. 支付對賬架構的演進

3.1

對賬1.0，All in MySql

基於Mysql資料庫完成對賬，將涉及到的分佈在不同伺服器上的業務庫同步到一個大磁碟伺服器上的Mysql例項下，在此例項下完成跨庫查詢、資料的匹配。

此方案雖然解決了跨庫查詢的問題，但是因為有些表資料量達到億級別，導致sql查詢緩慢，對賬效率低下，比如月度退款對賬sql查詢需要3個小時。

3.2

對賬2.0，利用大資料技術提速

使用 ETL（Extract, Transform, Load）方法來實現資料的提取、轉換、載入，將對賬需要的不同業務系統的表資料同步到數倉，在數倉完成跨庫跨表的關聯，以便進行有效的對賬分析。

3.3

對賬2.0的缺陷

這種方式雖然比[對賬1.0]方案效率有所提升，但是對賬場景中有調賬、補賬的操作，這部分修改、新增的資料目前只能T+1同步到數倉，導致部分對賬場景不適用，需要按照【對賬1.0】方案處理。

4. 對賬3.0，Starrock極速提效

4.1

引入StarRocks的背景

但隨著資料累積和資料量的增長，加之業務線和財務精細化的支付賬單需求，當前架構日漸吃力，業務上呈現出以下痛點:

人力成本高，每次對賬都需要4人/日，出現問題每次都需要財務人員找開發人員查詢，重複的工作浪費人力。
時效性低，基於大資料Hive的查詢，雖然解決了大資料量多表關聯的問題，但是執行速度的問題沒解決。
機器成本高，部分場景仍然需要基於Mysql，需要將多個mySql主庫同步到一臺高配的機器上的MySql服務上來支援跨表跨庫查詢。

為了給業務增長提供更強的助力，我們開始尋找一款可以支援更靈活的資料模型、具有高效的併發查詢效能、運維可以支援的實時性 OLAP 資料庫產品。

透過以上產品能力上的初步對比和查詢效能的對比，我們已經比較傾向於選擇 StarRocks。支援億級的大表關聯、秒級查詢，同時支援實時寫入，相容Mysql協議等特性，符合我們支付對賬場景的業務需求。

4.2

基於StarRocks的對賬3.0架構

和2.0對賬方案比整體架構上變化不大，StarRocks替代了Hive，基於StarRocks的高效能查詢特性補充了若干定時任務，並且將原來基於Hive語法的語句調整為SQL語句，基於MySQL語法的語句需要很小的變動（雖然官方相容MySQL協議，但也發現有些SQL語法不相容）。

對賬任務平臺中的任務，主要基於SQL和Python開發，遷移、新增自動化任務也完全基於熟悉的技術棧，學習成本很低。另外為了防止MySQL主庫和Starrock庫中的資料不一致，新增了資料校驗任務，一旦發現存在差異會報警，並觸發DataX資料補償機制。

4.3

對賬模型的選擇

剛開始就是因為錯用了更新模型，產生存在主鍵重複的資料存在，導致對賬資料異常，所以要結合業務資料特性從明細模型、聚合模型、更新模型、主鍵模型中選擇符合業務場景的模型。

4.4

Flink實時資料同步

資料同步工具和中介軟體，考慮到公司現有的技術支援和業界成熟度，最終選擇DataX同步存量資料，DataX的資料同步可以透過頁面操作的方式同步，Flink監控binlog同步增量資料，雖然StarRocks 提供了用於和Flink整合的connector，但還是相對複雜一點。

同時要注意，Flink不支援char型別、timestamp型別，要替換成對應的varchar和datetime。下面是實現同步的一些關鍵步驟：

1. 建StarRocks表db1_flink_table1

2. 定義Flink表（對應StarRocks表）xxxxtable

3. 建立Flink SQL任務，向StarRocks寫入資料

如果有些需求無法使用Flink SQL實現，需要Flink 自定義任務向StarRocks寫入資料，然後自行編碼實現。

4.6

SQL語法的適配

對賬有18個場景，每個場景下的SQL都需要適配StarRocks,但因為Starrocks相容SQL語法，適配成本很低，一天的時間完成了所有的SQL適配。

下面是語法的對比，左側是MySQL，右側是Starrocks，基本一直，如果select 欄位包含子查詢的時候StarRocks不支援，需要調整。

4.5

落地效果

綜合比較，相比於之前的架構，現在的架構查詢效能方面提升明顯。最複雜的一條對賬Sql執行時間從1小時縮短到50秒，主鍵模型下查詢，關聯查詢相較於此前基於 MySQL 的架構，基於 StarRocks 的架構效能平均可以提升50-70倍以上。儲存成本相比於 MySQL+Druid，降低2倍以上。由此帶來的人力成本也由以前的3人/日縮減到1人/日釋放更多人力去完成更有挑戰性的工作。

5. 總結

當前，對賬工作中涉及多個場景的資料合併仍依賴人工操作，這種方法不僅效率低下，而且容易產生錯誤。因此，我們計劃將這一過程升級為程式定時自動對賬、生產報表。此外，利用StarRocks的最新特性，特別是物化檢視，能夠進一步提高查詢的效率，持續提升對賬效能。

StarRocks在支付對賬領域的應用

相關文章