跨境支付平臺 XTransfer 的實時數(shù)倉之路：深度參與開源才能不被淘汰

　　作者 | 羅燕珊

　　近兩年新冠肺炎疫情對各行各業(yè)造成重大沖擊，但對于跨境電商行業(yè)來說則是機大于危，跨境支付賽道也因此備受關(guān)注。其中，受疫情影響，大量 B2B 外貿(mào)交易轉(zhuǎn)到線上，相比起 B2C，B2B 跨境交易支付場景更為復雜，因為其業(yè)務(wù)場景也往往更為復雜、周期長、貿(mào)易參與角色眾多。

　　另一方面，支付業(yè)務(wù)天然地對風險識別的及時性和準確性要求非常高，因此數(shù)據(jù)的采集、加工、計算就需要前置在每個業(yè)務(wù)節(jié)點、前瞻性地做好數(shù)據(jù)資產(chǎn)的維護工作。實時數(shù)倉和實時模型引擎，就是當前解決上述問題最合適的基礎(chǔ)設(shè)施。近日，InfoQ 有幸接觸到面向中小微外貿(mào)企業(yè)提供 B2B 跨境支付和風控服務(wù)的平臺 XTransfer(上海奪暢網(wǎng)絡(luò)技術(shù)有限公司)，并通過采訪得以了解其自行搭建實時數(shù)倉的實踐過程和背后的思考，以及深度參與開源的方式。

　　采訪嘉賓：

　　劉艷芳，XTransfer 聯(lián)合創(chuàng)始人兼 CTO

　　康偉，XTransfer 技術(shù)專家

　　技術(shù)發(fā)展三階段

　　XTransfer 于 2017 年創(chuàng)立，聚焦于 B2B 跨境支付，為從事跨境電商 B2B 出口的中小微企業(yè)提供外貿(mào)收款服務(wù)，以及風控服務(wù)，解決貿(mào)易風險問題。

　　從創(chuàng)立至今，XTransfer 的技術(shù)發(fā)展歷程可大致分為三個階段：

　　第一階段(2017 年 7 月 -2018 年 10 月)：創(chuàng)業(yè)初期，需要先打造出基礎(chǔ)平臺，并把業(yè)務(wù)鏈路跑通，確�；�礎(chǔ)平臺能夠支撐業(yè)務(wù)的發(fā)展。在這個過程中，公司完成了整個基礎(chǔ)平臺體系的搭建。

　　  第二階段(2018 年 6 月 -2021 年 7 月)：提效，利用大數(shù)據(jù)等技術(shù)提升效率。例如在公司內(nèi)部通過算法模型去提升風險審核的效率，降低人工工單審核的比例。此外，運用 OCR(光學字符識別)等機器學習技術(shù)幫助客戶做一些數(shù)據(jù)處理工作。在這個階段，公司開始推出新的產(chǎn)品。

　　  第三階段(2021 年 7 月至今)：平臺縱深發(fā)展，從單點的金融服務(wù)平臺往更智能化、數(shù)字化的方向發(fā)展。比如，今年新推出外貿(mào) CRM，總結(jié)出一套新的產(chǎn)品模式，幫助中小微外貿(mào)企業(yè)數(shù)字化轉(zhuǎn)型。該階段的重點在于如何將公司內(nèi)部所沉淀積累的能力輸出給中小微企業(yè)。

　　XTransfer 的技術(shù)平臺和眾多服務(wù)都是基于云基礎(chǔ)設(shè)施來打造的，目前主要用的是阿里云，但包括華為云、騰訊云和百度云在內(nèi)的云服務(wù)也都有在用。“企業(yè)發(fā)展到一定階段，無論是出于成本還是穩(wěn)定性的考慮，肯定要做多云方案。我們現(xiàn)階段最大的考量點不是成本，而是打造更優(yōu)質(zhì)的產(chǎn)品和業(yè)務(wù)。”劉艷芳表示。

　　目前，公司研發(fā)團隊大致分為兩部分，一部分是業(yè)務(wù)職能團隊，包括前端、后端、測試、運維等，另一部分是大數(shù)據(jù)和算法團隊。無論是業(yè)務(wù)平臺還是數(shù)據(jù)平臺的開發(fā)，都是先做開源框架選型，再以自研工作為主。技術(shù)選型方面，以穩(wěn)定性為第一出發(fā)點，并確保平臺的穩(wěn)定性、安全性和數(shù)據(jù)精確性。

　　實時數(shù)倉建設(shè)實踐

　　自建方案更靈活

　　相較于 ToC 的場景，ToB 業(yè)務(wù)的數(shù)據(jù)量相對要少很多。劉艷芳指出，目前市場上流行的方案大多數(shù)能夠有效解決大數(shù)據(jù)量計算和處理的問題，但是在安全性、穩(wěn)定性和準確性上并沒有達到金融級別的要求。

　　跨境支付 +B 類支付結(jié)算場景所涉及的業(yè)務(wù)鏈路非常長，從詢盤到最終成交，當中涉及物流條款、支付條款，需要在每個節(jié)點上做風險管控�？缇迟Y金交易監(jiān)管愈發(fā)嚴格。外貿(mào)企業(yè)進行收款和資金周轉(zhuǎn)，這一過程受到金融機構(gòu)及監(jiān)管嚴格的反洗錢風險管理。以上種種因素對 XTransfer 的數(shù)據(jù)處理安全性和準確性都提出了更高的要求。

　　XTransfer 所打造的大數(shù)據(jù)風控基礎(chǔ)設(shè)施架構(gòu)圖

　　據(jù)了解，XTransfer 在全球部署了 3 個數(shù)據(jù)中心，搭建了自己的實時數(shù)據(jù)倉庫，能夠有效地保障在跨境 B2B 業(yè)務(wù)全鏈路上，數(shù)據(jù)可以被有效采集、加工和計算，并滿足高安全、低延時、高精度等需求。

　　對于初創(chuàng)型(用戶量在百萬以下)企業(yè)來說，對實時數(shù)倉的需求往往是部署和運維成本低、易開發(fā)、架構(gòu)靈活簡單、開箱即用，僅投入較少的人力和時間成本就能滿足業(yè)務(wù)需求。

　　雖然市面上不少廠商都在推各種各樣的實時數(shù)倉解決方案，但劉艷芳認為目前市場上所推出的實時數(shù)倉解決方案，多數(shù)針對 2C 營銷類的場景，不能完全支撐 2B 跨境支付的復雜場景以及滿足個性化需求。而自建的方案更靈活，能整合更多的框架和技術(shù)，去滿足特定的業(yè)務(wù)場景。

　　因此，XTransfer 根據(jù)自身的 OLAP 場景需求，在自建數(shù)倉的基礎(chǔ)上，支持靈活連接多種 OLAP 數(shù)據(jù)庫，例如 Clickhouse、Doris 等，以滿足不同需求。

　　設(shè)計思路

　　XTransfer 建設(shè)實時數(shù)據(jù)倉庫的設(shè)計思路是以開源項目為基礎(chǔ)，疊加二次開發(fā)。目前數(shù)據(jù)平臺采用了 Lambda 架構(gòu)，同時構(gòu)建了流處理和批處理兩種架構(gòu)進行數(shù)據(jù)處理，并正在向流批一體數(shù)倉的方向演進：

　　在業(yè)務(wù)起步的早期，團隊采用了批處理架構(gòu)，數(shù)據(jù)倉庫處理時效是 T+1(即：今天產(chǎn)生的數(shù)據(jù)分析結(jié)果明天才能看到)。隨著業(yè)務(wù)的發(fā)展，通過更頻繁的任務(wù)調(diào)度，提升批處理的時效，可以達到小時級。當業(yè)務(wù)進入快速發(fā)展階段，對數(shù)據(jù)的實時性要求越來越高，團隊開始采用流處理架構(gòu)，數(shù)據(jù)處理時效達到秒級。對大數(shù)據(jù)量的離線數(shù)倉數(shù)據(jù)同步，采用 CDC(Change Data Capture) + Merge 的技術(shù)方案將數(shù)據(jù)同步至離線數(shù)倉 ODS 層，整體流程：進行一次性快照制作，將存量數(shù)據(jù)同步至 ODS;每天基于存量數(shù)據(jù)和當日的增量變更進行 Merge 還原。

　　技術(shù)選型

　　在數(shù)據(jù)倉庫的維度建模中，XTransfer 選擇了星型模型，使用分層設(shè)計方案來建設(shè)實時數(shù)倉，分層架構(gòu)如下圖所示：

　　在做技術(shù)選型的過程中，往往會出現(xiàn)兩種聲音，一種是希望能從 0 到 1 建設(shè)，另一種是希望直接選用成熟的方案。XTransfer 也不例外，在這種情況下，解決方法是把各團隊集結(jié)到一起去做深入探討和研究，把關(guān)鍵路徑分析出來，確定哪些需要自己去做、哪些是可以引用的、哪些是可以自己去做補充和完善的。

　　具體的技術(shù)選型方面，XTransfer 在實時數(shù)倉計算引擎上選擇了開源流處理框架 Flink，因為它具備高吞吐、低延遲、高性能等優(yōu)點，且技術(shù)成熟、社區(qū)活躍。做風控需要對全量數(shù)據(jù)進行捕捉，CDC(Change Data Capture，用于捕捉數(shù)據(jù)庫表的增刪改查操作) 是內(nèi)部比較傾向的方案，因此最終使用了 Flink CDC Connectors，這是 Flink 的一組 Source 連接器，是 Flink CDC 的核心組件，這些連接器負責從 MySQL、PostgreSQL、Oracle、MongoDB 等數(shù)據(jù)庫讀取存量歷史數(shù)據(jù)和增量變更數(shù)據(jù)。

　　實時數(shù)倉存儲方面選擇了 Kafka，使用 Kafka compacted topic 存儲數(shù)倉 ODS、DWD、DWS 層的數(shù)據(jù)。使用 upsert-kafka 連接器以 upsert 方式從 Kafka topic 中讀取數(shù)據(jù)并將數(shù)據(jù)寫入 Kafka topic。作為 source，upsert-kafka 連接器生產(chǎn) changelog 流，其中每條數(shù)據(jù)記錄代表一個更新或刪除事件。作為 sink，upsert-kafka 連接器可以消費 changelog 流。它會將 INSERT/UPDATE 數(shù)據(jù)作為正常的 Kafka 消息寫入，并將 DELETE 數(shù)據(jù)以 value 為空的 Kafka 消息寫入，表示對應(yīng) key 的消息被刪除。

　　在 OLAP 引擎的選型上，團隊結(jié)合 XTransfer 的研發(fā)資源情況、業(yè)務(wù)需求以及使用場景，選擇了 Apache Doris，具體有以下幾點考慮：選擇 ROLAP 模式，模型簡化，模型復用率高，開發(fā)效率高，低冗余，省空間;同時支持離線批量導入和實時數(shù)據(jù)導入，支持事務(wù)和冪等性導入;采取分區(qū)分桶的機制，支持多種索引技術(shù)，滿足 PB 級的存儲和分析能力;使用列式存儲和壓縮技術(shù)，提升查詢性能;兼容 MySQL 訪問協(xié)議，簡單、易用;運維更簡單，內(nèi)置分布式協(xié)議，支持集群的在線動態(tài)擴縮容，故障節(jié)點自動恢復;一站式的分析解決方案，只需少量投入研發(fā)資源，開箱即用。

　　深度參與開源

　　從開源中受益，并力所能及地反哺社區(qū)，是 XTransfer 技術(shù)團隊所遵循的原則。前面提到他們使用了 Flink CDC Connectors，這也是一個獨立的開源項目。日前，F(xiàn)link 社區(qū)已經(jīng)正式發(fā)布 Flink CDC 2.1 版本，重點提升 MySQL CDC 連接器的性能和生產(chǎn)穩(wěn)定性，并新增了 Oracle CDC 連接器和 MongoDB CDC 連接器，其中，XTransfer 技術(shù)專家孫家寶貢獻了 MongoDB CDC 連接器。

　　MongoDB CDC 連接器支持從 MongoDB 數(shù)據(jù)庫獲取全量歷史數(shù)據(jù)和增量變更數(shù)據(jù)。借助 Flink 的集成能力，用戶可以非常方便地將 MongoDB 中的數(shù)據(jù)實時同步到 Flink 支持的所有下游存儲。

　　在數(shù)據(jù)捕獲的整個過程中，用戶不需要學習 MongoDB 的副本機制和原理，大大簡化了流程，降低了使用門檻。MongoDB CDC 也支持兩種啟動模式：默認的 initial 模式是先同步表中的存量的數(shù)據(jù)，然后同步表中的增量數(shù)據(jù);latest-offset 模式則是從當前時間點開始只同步表中增量數(shù)據(jù)。

　　此外，MongoDB CDC 還提供了豐富的配置和優(yōu)化參數(shù)，對于生產(chǎn)環(huán)境來說，這些配置和參數(shù)能夠極大地提升實時鏈路的性能和穩(wěn)定性。

　　康偉表示，XTransfer 大數(shù)據(jù)團隊目前也在關(guān)注 Flink Connector、Flink Table API、Flink + Iceberg 等領(lǐng)域的建設(shè)。接下來，XTransfer 會持續(xù)優(yōu)化 MongoDB CDC，比如提升并行度，優(yōu)化對大表同步的支撐等。在與社區(qū)其他開發(fā)者的交流中，團隊發(fā)現(xiàn)大家對于 MongoDB 在 Sink Connector 方面也有很大的需求，因此也正在做這部分開發(fā)。

　　目前，XTransfer 團隊已經(jīng)向社區(qū)提報并解決的相關(guān) issue：

　　FLINK-6573 Flink MongoDB Connector FLINK-21172 “canal-json format include es field” FLINK-21949 Support collect to array aggregate function DBZ-3966 JsonTableChangeSerializer support serialization for defaultValue

　　正在關(guān)注跟進的 issue：

　　FLINK-22793 HybridSource Table Implementation ICEBERG-1639 Flink: write the CDC records into apache iceberg tables

　　寫在最后

　　在交流中，InfoQ 了解到 XTransfer 選擇自行搭建實時數(shù)倉的原因也和公司所堅持的“長期有耐心”的理念息息相關(guān)——“必須要做長期的解決方案，不做不斷推倒重來的事。”對此，劉艷芳進一步解釋道，“目前我們的方案能針對性解決我們遇到的問題，同時我們也能充分掌握里面的核心技術(shù)，并且它也是符合未來社區(qū)發(fā)展趨勢的解決方案，而我們從社區(qū)的發(fā)展中獲益之余也能夠貢獻給社區(qū)，這也能保證我們不被淘汰。”

　　至于“不被淘汰”的衡量標準，則跟社區(qū)貢獻有關(guān)。劉艷芳對團隊有兩點要求，一要跟上社區(qū)的變化;二是“能給社區(qū)貢獻”，能貢獻就說明被社區(qū)接納，自己是處于和社區(qū)同步發(fā)展的軌道。

　　總的來說，XTransfer 正試圖用一種更務(wù)實的方式去深度參與社區(qū)，并緊跟社區(qū)的腳步。“當下，我們可能沒有那么大的力量，不像大廠能一下子貢獻一整個模塊，但我們也有能力去貢獻差異化的產(chǎn)出。未來，我們會持續(xù)探索，創(chuàng)造更多可能性。