1. 前言

對(duì)賬是企業(yè)為了核實(shí)財(cái)務(wù)交易準(zhǔn)確性、管理庫(kù)存和了解業(yè)務(wù)績(jī)效而進(jìn)行的核對(duì)和調(diào)解過(guò)程。

因?yàn)閷?duì)賬涉及到支付系統(tǒng)、訂單系統(tǒng)、財(cái)務(wù)系統(tǒng)、結(jié)算系統(tǒng)和權(quán)益系統(tǒng)等多個(gè)系統(tǒng)，需要確保這些系統(tǒng)的數(shù)據(jù)能夠有效地對(duì)應(yīng)和匹配，需要一種高效可靠的方式以解決跨系統(tǒng)的數(shù)據(jù)匹配。

2. 支付閉環(huán)

2.1支付背后隱藏的細(xì)節(jié)。

一筆訂單的完結(jié)，C端用戶(hù)看到的僅僅是下單、支付簡(jiǎn)單的流程，實(shí)際上背后有一套更復(fù)雜的流程實(shí)現(xiàn)支付的閉環(huán)。比如支付成功通知、訂單結(jié)算分賬、結(jié)算成功通知、賬務(wù)處理與報(bào)表生成等，以下是一個(gè)簡(jiǎn)化的支付閉環(huán)流程：

圖片

3. 支付對(duì)賬架構(gòu)的演進(jìn)

3.1對(duì)賬1.0，All in MySql

圖片

基于Mysql數(shù)據(jù)庫(kù)完成對(duì)賬，將涉及到的分布在不同服務(wù)器上的業(yè)務(wù)庫(kù)同步到一個(gè)大磁盤(pán)服務(wù)器上的Mysql實(shí)例下，在此實(shí)例下完成跨庫(kù)查詢(xún)、數(shù)據(jù)的匹配。

此方案雖然解決了跨庫(kù)查詢(xún)的問(wèn)題，但是因?yàn)橛行┍頂?shù)據(jù)量達(dá)到億級(jí)別，導(dǎo)致sql查詢(xún)緩慢，對(duì)賬效率低下，比如月度退款對(duì)賬sql查詢(xún)需要3個(gè)小時(shí)。

3.2對(duì)賬2.0，利用大數(shù)據(jù)技術(shù)提速

圖片

使用 ETL（Extract, Transform, Load）方法來(lái)實(shí)現(xiàn)數(shù)據(jù)的提取、轉(zhuǎn)換、加載，將對(duì)賬需要的不同業(yè)務(wù)系統(tǒng)的表數(shù)據(jù)同步到數(shù)倉(cāng)，在數(shù)倉(cāng)完成跨庫(kù)跨表的關(guān)聯(lián)，以便進(jìn)行有效的對(duì)賬分析。

3.3對(duì)賬2.0的缺陷

這種方式雖然比[對(duì)賬1.0]方案效率有所提升，但是對(duì)賬場(chǎng)景中有調(diào)賬、補(bǔ)賬的操作，這部分修改、新增的數(shù)據(jù)目前只能T+1同步到數(shù)倉(cāng)，導(dǎo)致部分對(duì)賬場(chǎng)景不適用，需要按照【對(duì)賬1.0】方案處理。

4. 對(duì)賬3.0，Starrock極速提效

4.1引入StarRocks的背景

但隨著數(shù)據(jù)累積和數(shù)據(jù)量的增長(zhǎng)，加之業(yè)務(wù)線和財(cái)務(wù)精細(xì)化的支付賬單需求，當(dāng)前架構(gòu)日漸吃力，業(yè)務(wù)上呈現(xiàn)出以下痛點(diǎn):

人力成本高，每次對(duì)賬都需要4人/日，出現(xiàn)問(wèn)題每次都需要財(cái)務(wù)人員找開(kāi)發(fā)人員查詢(xún)，重復(fù)的工作浪費(fèi)人力。

 時(shí)效性低，基于大數(shù)據(jù)Hive的查詢(xún)，雖然解決了大數(shù)據(jù)量多表關(guān)聯(lián)的問(wèn)題，但是執(zhí)行速度的問(wèn)題沒(méi)解決。

機(jī)器成本高，部分場(chǎng)景仍然需要基于Mysql，需要將多個(gè)mySql主庫(kù)同步到一臺(tái)高配的機(jī)器上的MySql服務(wù)上來(lái)支持跨表跨庫(kù)查詢(xún)。

為了給業(yè)務(wù)增長(zhǎng)提供更強(qiáng)的助力，我們開(kāi)始尋找一款可以支持更靈活的數(shù)據(jù)模型、具有高效的并發(fā)查詢(xún)性能、運(yùn)維可以支持的實(shí)時(shí)性 OLAP 數(shù)據(jù)庫(kù)產(chǎn)品。

圖片

圖片

通過(guò)以上產(chǎn)品能力上的初步對(duì)比和查詢(xún)性能的對(duì)比，我們已經(jīng)比較傾向于選擇 StarRocks。支持億級(jí)的大表關(guān)聯(lián)、秒級(jí)查詢(xún)，同時(shí)支持實(shí)時(shí)寫(xiě)入，兼容Mysql協(xié)議等特性，符合我們支付對(duì)賬場(chǎng)景的業(yè)務(wù)需求。

4.2基于StarRocks的對(duì)賬3.0架構(gòu)

圖片

和2.0對(duì)賬方案比整體架構(gòu)上變化不大，StarRocks替代了Hive，基于StarRocks的高性能查詢(xún)特性補(bǔ)充了若干定時(shí)任務(wù)，并且將原來(lái)基于Hive語(yǔ)法的語(yǔ)句調(diào)整為SQL語(yǔ)句，基于MySQL語(yǔ)法的語(yǔ)句需要很小的變動(dòng)（雖然官方兼容MySQL協(xié)議，但也發(fā)現(xiàn)有些SQL語(yǔ)法不兼容）。

對(duì)賬任務(wù)平臺(tái)中的任務(wù)，主要基于SQL和Python開(kāi)發(fā)，遷移、新增自動(dòng)化任務(wù)也完全基于熟悉的技術(shù)棧，學(xué)習(xí)成本很低。另外為了防止MySQL主庫(kù)和Starrock庫(kù)中的數(shù)據(jù)不一致，新增了數(shù)據(jù)校驗(yàn)任務(wù)，一旦發(fā)現(xiàn)存在差異會(huì)報(bào)警，并觸發(fā)DataX數(shù)據(jù)補(bǔ)償機(jī)制。

4.3對(duì)賬模型的選擇

剛開(kāi)始就是因?yàn)殄e(cuò)用了更新模型，產(chǎn)生存在主鍵重復(fù)的數(shù)據(jù)存在，導(dǎo)致對(duì)賬數(shù)據(jù)異常，所以要結(jié)合業(yè)務(wù)數(shù)據(jù)特性從明細(xì)模型、聚合模型、更新模型、主鍵模型中選擇符合業(yè)務(wù)場(chǎng)景的模型。

圖片

4.4Flink實(shí)時(shí)數(shù)據(jù)同步

數(shù)據(jù)同步工具和中間件，考慮到公司現(xiàn)有的技術(shù)支持和業(yè)界成熟度，最終選擇DataX同步存量數(shù)據(jù)，DataX的數(shù)據(jù)同步可以通過(guò)頁(yè)面操作的方式同步，F(xiàn)link監(jiān)控binlog同步增量數(shù)據(jù)，雖然StarRocks 提供了用于和Flink集成的connector，但還是相對(duì)復(fù)雜一點(diǎn)。

同時(shí)要注意，F(xiàn)link不支持char類(lèi)型、timestamp類(lèi)型，要替換成對(duì)應(yīng)的varchar和datetime。下面是實(shí)現(xiàn)同步的一些關(guān)鍵步驟：

• 建StarRocks表db1_flink_table1

圖片

• 定義Flink表（對(duì)應(yīng)StarRocks表）xxxxtable

圖片

•  創(chuàng)建Flink SQL任務(wù)，向StarRocks寫(xiě)入數(shù)據(jù)

圖片

如果有些需求無(wú)法使用Flink SQL實(shí)現(xiàn)，需要Flink 自定義任務(wù)向StarRocks寫(xiě)入數(shù)據(jù)，然后自行編碼實(shí)現(xiàn)。

4.6SQL語(yǔ)法的適配

對(duì)賬有18個(gè)場(chǎng)景，每個(gè)場(chǎng)景下的SQL都需要適配StarRocks,但因?yàn)镾tarrocks兼容SQL語(yǔ)法，適配成本很低，一天的時(shí)間完成了所有的SQL適配。

下面是語(yǔ)法的對(duì)比，左側(cè)是MySQL，右側(cè)是Starrocks，基本一直，如果select 字段包含子查詢(xún)的時(shí)候StarRocks不支持，需要調(diào)整。

圖片

圖片

4.5落地效果

綜合比較，相比于之前的架構(gòu)，現(xiàn)在的架構(gòu)查詢(xún)性能方面提升明顯。最復(fù)雜的一條對(duì)賬Sql執(zhí)行時(shí)間從1小時(shí)縮短到50秒，主鍵模型下查詢(xún)，關(guān)聯(lián)查詢(xún)相較于此前基于 MySQL 的架構(gòu)，基于 StarRocks 的架構(gòu)性能平均可以提升50-70倍以上。存儲(chǔ)成本相比于 MySQL+Druid，降低2倍以上。由此帶來(lái)的人力成本也由以前的3人/日縮減到1人/日釋放更多人力去完成更有挑戰(zhàn)性的工作。

圖片

5. 總結(jié)

當(dāng)前，對(duì)賬工作中涉及多個(gè)場(chǎng)景的數(shù)據(jù)合并仍依賴(lài)人工操作，這種方法不僅效率低下，而且容易產(chǎn)生錯(cuò)誤。因此，我們計(jì)劃將這一過(guò)程升級(jí)為程序定時(shí)自動(dòng)對(duì)賬、生產(chǎn)報(bào)表。此外，利用StarRocks的最新特性，特別是物化視圖，能夠進(jìn)一步提高查詢(xún)的效率，持續(xù)提升對(duì)賬效能。

作者簡(jiǎn)介

馮現(xiàn)寬服務(wù)端研發(fā)部-服務(wù)端買(mǎi)用技術(shù)團(tuán)隊(duì)

2016年加入汽車(chē)之家，目前任職于服務(wù)端研發(fā)部-服務(wù)端買(mǎi)用技術(shù)團(tuán)隊(duì)，主要負(fù)責(zé)保險(xiǎn)、支付和結(jié)算相關(guān)業(yè)務(wù)。