建站
咨詢
售后
建站咨詢
新聞中心
創(chuàng)新互聯(lián)專業(yè)網(wǎng)站建設(shè)、做網(wǎng)站，集網(wǎng)站策劃、網(wǎng)站設(shè)計、網(wǎng)站制作于一體，網(wǎng)站seo、網(wǎng)站優(yōu)化、網(wǎng)站營銷、軟文發(fā)稿等專業(yè)人才根據(jù)搜索規(guī)律編程設(shè)計，讓網(wǎng)站在運行后，在搜索中有好的表現(xiàn)，專業(yè)設(shè)計制作為您帶來效益的網(wǎng)站！讓網(wǎng)站建設(shè)為您創(chuàng)造效益。
1. 前言
對賬是企業(yè)為了核實財務(wù)交易準(zhǔn)確性、管理庫存和了解業(yè)務(wù)績效而進行的核對和調(diào)解過程。
因為對賬涉及到支付系統(tǒng)、訂單系統(tǒng)、財務(wù)系統(tǒng)、結(jié)算系統(tǒng)和權(quán)益系統(tǒng)等多個系統(tǒng)，需要確保這些系統(tǒng)的數(shù)據(jù)能夠有效地對應(yīng)和匹配，需要一種高效可靠的方式以解決跨系統(tǒng)的數(shù)據(jù)匹配。
2. 支付閉環(huán)
2.1支付背后隱藏的細節(jié)。
一筆訂單的完結(jié)，C端用戶看到的僅僅是下單、支付簡單的流程，實際上背后有一套更復(fù)雜的流程實現(xiàn)支付的閉環(huán)。比如支付成功通知、訂單結(jié)算分賬、結(jié)算成功通知、賬務(wù)處理與報表生成等，以下是一個簡化的支付閉環(huán)流程：
圖片
3. 支付對賬架構(gòu)的演進
3.1對賬1.0，All in MySql
圖片
基于Mysql數(shù)據(jù)庫完成對賬，將涉及到的分布在不同服務(wù)器上的業(yè)務(wù)庫同步到一個大磁盤服務(wù)器上的Mysql實例下，在此實例下完成跨庫查詢、數(shù)據(jù)的匹配。
此方案雖然解決了跨庫查詢的問題，但是因為有些表數(shù)據(jù)量達到億級別，導(dǎo)致sql查詢緩慢，對賬效率低下，比如月度退款對賬sql查詢需要3個小時。
3.2對賬2.0，利用大數(shù)據(jù)技術(shù)提速
圖片
使用 ETL（Extract, Transform, Load）方法來實現(xiàn)數(shù)據(jù)的提取、轉(zhuǎn)換、加載，將對賬需要的不同業(yè)務(wù)系統(tǒng)的表數(shù)據(jù)同步到數(shù)倉，在數(shù)倉完成跨庫跨表的關(guān)聯(lián)，以便進行有效的對賬分析。
3.3對賬2.0的缺陷
這種方式雖然比[對賬1.0]方案效率有所提升，但是對賬場景中有調(diào)賬、補賬的操作，這部分修改、新增的數(shù)據(jù)目前只能T+1同步到數(shù)倉，導(dǎo)致部分對賬場景不適用，需要按照【對賬1.0】方案處理。
4. 對賬3.0，Starrock極速提效
4.1引入StarRocks的背景
但隨著數(shù)據(jù)累積和數(shù)據(jù)量的增長，加之業(yè)務(wù)線和財務(wù)精細化的支付賬單需求，當(dāng)前架構(gòu)日漸吃力，業(yè)務(wù)上呈現(xiàn)出以下痛點:
人力成本高，每次對賬都需要4人/日，出現(xiàn)問題每次都需要財務(wù)人員找開發(fā)人員查詢，重復(fù)的工作浪費人力。
時效性低，基于大數(shù)據(jù)Hive的查詢，雖然解決了大數(shù)據(jù)量多表關(guān)聯(lián)的問題，但是執(zhí)行速度的問題沒解決。
機器成本高，部分場景仍然需要基于Mysql，需要將多個mySql主庫同步到一臺高配的機器上的MySql服務(wù)上來支持跨表跨庫查詢。
為了給業(yè)務(wù)增長提供更強的助力，我們開始尋找一款可以支持更靈活的數(shù)據(jù)模型、具有高效的并發(fā)查詢性能、運維可以支持的實時性 OLAP 數(shù)據(jù)庫產(chǎn)品。
圖片
圖片
通過以上產(chǎn)品能力上的初步對比和查詢性能的對比，我們已經(jīng)比較傾向于選擇 StarRocks。支持億級的大表關(guān)聯(lián)、秒級查詢，同時支持實時寫入，兼容Mysql協(xié)議等特性，符合我們支付對賬場景的業(yè)務(wù)需求。
4.2基于StarRocks的對賬3.0架構(gòu)
圖片
和2.0對賬方案比整體架構(gòu)上變化不大，StarRocks替代了Hive，基于StarRocks的高性能查詢特性補充了若干定時任務(wù)，并且將原來基于Hive語法的語句調(diào)整為SQL語句，基于MySQL語法的語句需要很小的變動（雖然官方兼容MySQL協(xié)議，但也發(fā)現(xiàn)有些SQL語法不兼容）。
對賬任務(wù)平臺中的任務(wù)，主要基于SQL和Python開發(fā)，遷移、新增自動化任務(wù)也完全基于熟悉的技術(shù)棧，學(xué)習(xí)成本很低。另外為了防止MySQL主庫和Starrock庫中的數(shù)據(jù)不一致，新增了數(shù)據(jù)校驗任務(wù)，一旦發(fā)現(xiàn)存在差異會報警，并觸發(fā)DataX數(shù)據(jù)補償機制。
4.3對賬模型的選擇
剛開始就是因為錯用了更新模型，產(chǎn)生存在主鍵重復(fù)的數(shù)據(jù)存在，導(dǎo)致對賬數(shù)據(jù)異常，所以要結(jié)合業(yè)務(wù)數(shù)據(jù)特性從明細模型、聚合模型、更新模型、主鍵模型中選擇符合業(yè)務(wù)場景的模型。
圖片
4.4Flink實時數(shù)據(jù)同步
數(shù)據(jù)同步工具和中間件，考慮到公司現(xiàn)有的技術(shù)支持和業(yè)界成熟度，最終選擇DataX同步存量數(shù)據(jù)，DataX的數(shù)據(jù)同步可以通過頁面操作的方式同步，F(xiàn)link監(jiān)控binlog同步增量數(shù)據(jù)，雖然StarRocks 提供了用于和Flink集成的connector，但還是相對復(fù)雜一點。
同時要注意，F(xiàn)link不支持char類型、timestamp類型，要替換成對應(yīng)的varchar和datetime。下面是實現(xiàn)同步的一些關(guān)鍵步驟：
- 建StarRocks表db1_flink_table1
圖片
- 定義Flink表（對應(yīng)StarRocks表）xxxxtable
圖片
- 創(chuàng)建Flink SQL任務(wù)，向StarRocks寫入數(shù)據(jù)
圖片
如果有些需求無法使用Flink SQL實現(xiàn)，需要Flink 自定義任務(wù)向StarRocks寫入數(shù)據(jù)，然后自行編碼實現(xiàn)。
4.6SQL語法的適配
對賬有18個場景，每個場景下的SQL都需要適配StarRocks,但因為Starrocks兼容SQL語法，適配成本很低，一天的時間完成了所有的SQL適配。
下面是語法的對比，左側(cè)是MySQL，右側(cè)是Starrocks，基本一直，如果select 字段包含子查詢的時候StarRocks不支持，需要調(diào)整。
圖片
圖片
4.5落地效果
綜合比較，相比于之前的架構(gòu)，現(xiàn)在的架構(gòu)查詢性能方面提升明顯。最復(fù)雜的一條對賬Sql執(zhí)行時間從1小時縮短到50秒，主鍵模型下查詢，關(guān)聯(lián)查詢相較于此前基于 MySQL 的架構(gòu)，基于 StarRocks 的架構(gòu)性能平均可以提升50-70倍以上。存儲成本相比于 MySQL+Druid，降低2倍以上。由此帶來的人力成本也由以前的3人/日縮減到1人/日釋放更多人力去完成更有挑戰(zhàn)性的工作。
圖片
5. 總結(jié)
當(dāng)前，對賬工作中涉及多個場景的數(shù)據(jù)合并仍依賴人工操作，這種方法不僅效率低下，而且容易產(chǎn)生錯誤。因此，我們計劃將這一過程升級為程序定時自動對賬、生產(chǎn)報表。此外，利用StarRocks的最新特性，特別是物化視圖，能夠進一步提高查詢的效率，持續(xù)提升對賬效能。
作者簡介
馮現(xiàn)寬服務(wù)端研發(fā)部-服務(wù)端買用技術(shù)團隊
2016年加入汽車之家，目前任職于服務(wù)端研發(fā)部-服務(wù)端買用技術(shù)團隊，主要負責(zé)保險、支付和結(jié)算相關(guān)業(yè)務(wù)。
本文名稱：StarRocks在支付對賬領(lǐng)域的應(yīng)用
網(wǎng)頁URL：http://www.dlmjj.cn/article/dpjsdsi.html
