引言

在轉(zhuǎn)轉(zhuǎn)業(yè)務(wù)快速發(fā)展的過程中，業(yè)財系統(tǒng)作為連接業(yè)務(wù)與財務(wù)的核心樞紐，其重要性日益凸顯。早期我們基于微服務(wù)架構(gòu)構(gòu)建了“金字塔”系統(tǒng)，通過統(tǒng)一收集上下游業(yè)務(wù)數(shù)據(jù)并加工財務(wù)指標(biāo)，支撐了公司初期的財務(wù)分析需求。然而，隨著業(yè)務(wù)復(fù)雜度提升和數(shù)據(jù)量激增，這套架構(gòu)逐漸暴露出諸多問題：指標(biāo)差異難以溯源、數(shù)據(jù)處理效率低下、系統(tǒng)穩(wěn)定性不足等。本文將詳細(xì)分享我們?nèi)绾瓮ㄟ^架構(gòu)演進(jìn)，最終構(gòu)建出高效可靠的敏捷財報系統(tǒng)。

第一階段：微服務(wù)架構(gòu)的困境分析

1.1 初始架構(gòu)設(shè)計

產(chǎn)品架構(gòu)

數(shù)據(jù)分層加工

1.2 存儲設(shè)計

業(yè)務(wù)特點分析：
   特點1：各業(yè)務(wù)數(shù)據(jù)字段基本不相同，幾乎沒有可抽取出的統(tǒng)一字段，如果想統(tǒng)一存儲，只能以JSON字符串的形式；
   特點2：需要對加工后的財務(wù)數(shù)據(jù)實時可查，若以JSON存儲，不方便結(jié)構(gòu)化查詢；
   特點3：如果不統(tǒng)一存儲，來一個業(yè)務(wù)新建一些表，維護(hù)成本很高，萬一數(shù)據(jù)量大，還涉及到分庫分表問題；
   特點4：源數(shù)據(jù)來源方式不相同，有用接口的，有用云窗的，有人工后臺錄入的；

由于早期數(shù)據(jù)量并不大，基于以上業(yè)務(wù)特點，采用了如下的存儲方式。

image

引入 ES 用于支撐多維數(shù)據(jù)查詢，采用監(jiān)聽 binlog 同步 ES 的方式進(jìn)行數(shù)據(jù)同步。

各模塊源數(shù)據(jù)統(tǒng)一組裝成 JSON 字符串，存儲在金字塔項目的一張表（JSON 表，以下簡稱source_data表）中，源數(shù)據(jù)的每個模塊都有自己的唯一Code，binlog處理程序根據(jù)Code統(tǒng)一將 JSON 表數(shù)據(jù)按照每個模塊解析到 ES 對應(yīng)索引中，這樣可以支持?jǐn)?shù)據(jù)實時結(jié)構(gòu)化查詢，以及后續(xù)新增模塊接入的話，不需要再開發(fā)同步ES的代碼。在 MySQL 庫中source_data表的數(shù)據(jù)量達(dá)到一定量級后，只針對source_data表分表即可。

1.3 調(diào)度模型設(shè)計

由于需要離線處理多個模塊的指標(biāo)數(shù)據(jù)，采用離線定時任務(wù)的方式進(jìn)行處理，這里使用了分布式調(diào)度任務(wù)框架xxl-job。

調(diào)度流程

調(diào)度模型可以簡化為上圖流程所示。

可能這里有同學(xué)會想，為啥不采用xxl-job的分片廣播的形式進(jìn)行處理, 而采用mq廣播消費的方式。

• 一方面主要是考慮到執(zhí)行DWD任務(wù)種類很多，涉及物流費、支付手續(xù)費等任務(wù)。并且每個模塊處理的參數(shù)比較個性化。這里主要是做任務(wù)分發(fā)，針對一個模塊的任務(wù)只能一臺機器獲?。ê喕幚砟Ｐ停?，然后內(nèi)部多線程處理這個模塊。而一臺機器可以爭搶0~N個模塊的任務(wù)。而xxl-job分片任務(wù)的初衷是多臺機器共同處理同一模塊的分片數(shù)據(jù)。
• 另一方面是想在業(yè)務(wù)層面判斷某些模塊任務(wù)是否執(zhí)行完成，做一些更精細(xì)化的控制。這里xxl-job框架層面不支持。

1.4 處理模型設(shè)計

任務(wù)處理

在內(nèi)存中通過RPC進(jìn)行維度關(guān)聯(lián)并進(jìn)行指標(biāo)計算，計算完的結(jié)果存入dwd_financial，之后分別根據(jù)各個指標(biāo)的要求匯總統(tǒng)計存入dws_financial表中，后續(xù)定時將指標(biāo)數(shù)據(jù)同步到Hive中供分析部門使用。

第二階段：架構(gòu)演進(jìn)的考量

2.1 核心問題分析

問題1：數(shù)據(jù)完整性難以保證

微服務(wù)架構(gòu)下，數(shù)據(jù)分散在各個微服務(wù)所對應(yīng)的數(shù)據(jù)庫中，數(shù)據(jù)形成孤島。財務(wù)計算需要跨多個服務(wù)獲取維度和度量數(shù)據(jù)：

// 訂單金額計算需要調(diào)用多個服務(wù)
public BigDecimal calculateOrderAmount(Long orderId) {
    Order order = orderService.getOrder(orderId);        // 1. 獲取基礎(chǔ)訂單
    User user = userService.getUser(order.getUserId());  // 2. 獲取用戶等級
    Coupon coupon = couponService.getCoupon(...);        // 3. 獲取優(yōu)惠信息
    // ...更多服務(wù)調(diào)用
}

• RPC調(diào)用不穩(wěn)定，難以保證維度不缺失，即使重試也不一定能100%成功，維度缺失率高達(dá)10%。
• 如果某條數(shù)據(jù)處理失敗后，簡單重試幾次還失敗，那就整體失敗了，對后續(xù)的處理鏈路會存在阻斷。如果不阻斷，計算的數(shù)據(jù)維度缺失，最終統(tǒng)計的結(jié)果也不準(zhǔn)。兩者之間存在博弈。

問題2：任務(wù)調(diào)度與數(shù)據(jù)同步的不可靠性

• ES同步狀態(tài)不可見，只能預(yù)留大致時間緩沖，容易出現(xiàn)ES沒同步完成，就開始計算指標(biāo)數(shù)據(jù)了，造成差異。
• xxl-job任務(wù)調(diào)度與云窗（58大數(shù)據(jù)平臺）數(shù)據(jù)抽取不能聯(lián)動，可能存在xxl-job還沒執(zhí)行完，就開始了數(shù)據(jù)抽取任務(wù)，導(dǎo)致數(shù)據(jù)不準(zhǔn)確。

問題3：擴展性瓶頸

隨著數(shù)據(jù)量增長：

• 單機處理能力達(dá)到上限（最高延遲6小時）。
• 新增指標(biāo)需要修改代碼并重新部署。
• 資源無法彈性擴展。

2.2 解決思路

1. 盡量規(guī)避RPC調(diào)用：

• 如果還采用微服務(wù)架構(gòu)，則需要成功將維度數(shù)據(jù)預(yù)加載到本地緩存，但維度之多，以及非維度的數(shù)據(jù)也可能需要RPC才能獲取到，所以不能完全解決。
• 不用RPC來關(guān)聯(lián)各微服務(wù)的數(shù)據(jù)，而采用數(shù)據(jù)中心的思想，將多個微服務(wù)的數(shù)據(jù)庫同步到數(shù)據(jù)中心進(jìn)行統(tǒng)一處理。

2. 解耦分析場景：將分析型負(fù)載從交易系統(tǒng)中剝離。 例如將多個微服務(wù)數(shù)據(jù)關(guān)聯(lián)后分類匯總的功能，從微服務(wù)中拆分出來，微服務(wù)只做OLTP相關(guān)功能。

3. 采用統(tǒng)一的調(diào)度生態(tài)：如可以采用云窗統(tǒng)一的信號調(diào)度。不過整體架構(gòu)得跟著改造，不能再用微服務(wù)處理。

4. 多機器并行處理：可以采用分布式計算框架Spark進(jìn)行并行處理，優(yōu)化單機處理瓶頸。

2.3 下一步如何抉擇

我們評估了三種可能的演進(jìn)方向：

最終決策因素：

• 業(yè)務(wù)數(shù)據(jù)量已超過單機處理能力。
• 每月需要離線處理千萬級、億級別數(shù)據(jù)。
• 財務(wù)分析需求日益復(fù)雜（需要支持多維分析）。
• 團隊有3個月窗口期進(jìn)行技術(shù)轉(zhuǎn)型。

經(jīng)過對比，嘗試引入大數(shù)據(jù)技術(shù)棧來解決目前的痛點。

2.4 數(shù)據(jù)處理的本質(zhì)差異

1. 微服務(wù)實時調(diào)用 vs 大數(shù)據(jù)批處理

微服務(wù)RPC 需實時調(diào)用多個服務(wù)獲取維度及度量，網(wǎng)絡(luò)延遲、服務(wù)故障會導(dǎo)致調(diào)用鏈斷裂（如超時率高達(dá)5%），且分布式事務(wù)難以保證一致性。

大數(shù)據(jù)技術(shù)（如Spark/Hadoop）采用批處理模式，通過ETL流程將數(shù)據(jù)集中處理，所有維度關(guān)聯(lián)在計算前已完成，避免運行時依賴外部服務(wù)。

2. 計算向數(shù)據(jù)移動的思想大數(shù)據(jù)框架（如MapReduce）將計算任務(wù)分發(fā)到數(shù)據(jù)存儲節(jié)點執(zhí)行，減少網(wǎng)絡(luò)傳輸；而微服務(wù)RPC需跨網(wǎng)絡(luò)頻繁傳輸數(shù)據(jù)，增加不可靠性。

第三階段：新架構(gòu)設(shè)計

3.1 數(shù)據(jù)模型設(shè)計

3.1.1 分層設(shè)計（核心基礎(chǔ)）：

數(shù)據(jù)流向

• ODS層（Operational Data Store)：操作數(shù)據(jù)存儲層，存儲原始數(shù)據(jù)鏡像。
• DW層（Data Warehouse）：數(shù)據(jù)倉庫層，存儲經(jīng)過標(biāo)準(zhǔn)規(guī)范化處理（即數(shù)據(jù)清洗）后的運營數(shù)據(jù)，是基礎(chǔ)事實數(shù)據(jù)明細(xì)層。如：收入成本明細(xì)數(shù)據(jù)、mysql各業(yè)務(wù)數(shù)據(jù)經(jīng)過ETL處理后的表。
• DIM層： 維度數(shù)據(jù)層，主要包含一些字典表、維度數(shù)據(jù)。如：品類字典表、城市字典表、渠道字典表、終端類型表、支付狀態(tài)表等。
• DM層（Data Market）：數(shù)據(jù)集市層，按部門按專題進(jìn)行劃分，支持OLAP分析、數(shù)據(jù)分發(fā)等。如：日活用戶業(yè)務(wù)分析表，商業(yè)廣告多維分析報表，銷售回收明細(xì)寬表。
• ADS（Aplication Data Store）層：直接面向應(yīng)用的數(shù)據(jù)服務(wù)層。

3.1.2 維度建模：

選擇業(yè)務(wù)過程 --> 聲明粒度 --> 確定維度 --> 設(shè)計事實表

星型模型示例

基于事實和維度描述業(yè)務(wù)場景，構(gòu)建星型模型。

-- 共享維度表
CREATE TABLE dim_time (
    date_key INT PRIMARY KEY,
    full_date DATE,
    day_of_week TINYINT,
    month TINYINT,
    quarter TINYINT,
    year SMALLINT
);

-- 訂單事實表
CREATE TABLE fact_orders (
    order_id BIGINT,
    date_key INT REFERENCES dim_time,
    -- 其他字段...
);

-- 庫存事實表
CREATE TABLE fact_inventory (
    sku_id BIGINT,
    date_key INT REFERENCES dim_time,
    -- 其他字段...
);

建模后的好處：

• 方便一致性維度的復(fù)用和管理。多個事實可以關(guān)聯(lián)相同維度。
• 擴展靈活性高：維度變化不影響現(xiàn)有事實，各自獨立更新。
• ETL開發(fā)高效，方便擴充不同的分析主題。

3.1.3 調(diào)度系統(tǒng)：

• 統(tǒng)一采用云窗任務(wù)依賴的方式，實現(xiàn)父子任務(wù)管理，統(tǒng)一調(diào)度模型。
• 關(guān)鍵路徑監(jiān)控和自動重試。

3.2 大數(shù)據(jù)技術(shù)選型

核心組件對比：

計算引擎對比：

OLAP引擎對比：

• 單表性能：ClickHouse > StarRocks > Doris
• 多表關(guān)聯(lián)：StarRocks > Doris > ClickHouse
• 實時性：StarRocks ≈ Doris > ClickHouse
• 高并發(fā)場景：StarRocks > Doris > ClickHouse

通過對比可知，在計算引擎采用SparkSQL支持大規(guī)模的ETL且結(jié)合目前58云窗大數(shù)據(jù)平臺的現(xiàn)有功能支持，實現(xiàn)成本和上手成本較低，也為后面數(shù)據(jù)增長預(yù)留支撐，所以選擇SparkSQL。

在OLAP引擎方面，StarRocks/Doris在多表關(guān)聯(lián)的查詢性能及并發(fā)能力顯著優(yōu)于ClickHouse。從多表關(guān)聯(lián)查詢能力以及后期擴展性上我們考慮使用StarRocks。

3.3 數(shù)倉體系架構(gòu)圖

基于上述選型，以及結(jié)合轉(zhuǎn)轉(zhuǎn)數(shù)倉規(guī)范，構(gòu)建了如下架構(gòu)。

轉(zhuǎn)轉(zhuǎn)數(shù)倉架構(gòu)體系

財報整體架構(gòu)圖

3.4 數(shù)據(jù)處理示例

在數(shù)據(jù)倉庫環(huán)境中，使用SparkSQL替代Java服務(wù)調(diào)用的計算邏輯，可以通過以下方式實現(xiàn)：

基礎(chǔ)訂單金額計算（單表）

-- 直接基于訂單事實表計算
SELECT 
  order_id,
  original_amount,
  shipping_fee,
  original_amount + shipping_fee AS total_amount
FROM dwd_order_detail
WHERE dt = '${biz_date}'

多維度關(guān)聯(lián)計算（替代Java服務(wù)調(diào)用）

-- 替代原Java的多服務(wù)調(diào)用邏輯
SELECT
  o.order_id,
  o.original_amount,
-- 用戶維度關(guān)聯(lián)計算
CASE
    WHEN u.vip_level = 'PLATINUM' THEN o.original_amount * 0.9
    ELSE o.original_amount 
END AS vip_adjusted_amount,
-- 優(yōu)惠券維度關(guān)聯(lián)計算
COALESCE(c.coupon_amount, 0) AS coupon_deduction,
-- 最終實付金額
  (o.original_amount + o.shipping_fee - COALESCE(c.coupon_amount, 0)) AS final_amount
FROM dwd_order_detail o
LEFT JOIN dim_user u ON o.user_id = u.user_id AND u.dt = '${biz_date}'
LEFT JOIN dim_coupon c ON o.coupon_id = c.coupon_id AND c.dt = '${biz_date}'
WHERE o.dt = '${biz_date}'

高級分析場景（窗口函數(shù)等）

-- 計算用戶最近3單平均金額（替代Java內(nèi)存計算）
SELECT
  order_id,
  user_id,
  amount,
AVG(amount) OVER (
    PARTITION BY user_id 
    ORDER BY create_time 
    ROWS BETWEEN 2 PRECEDING AND CURRENT ROW
  ) AS moving_avg_amount
FROM dwd_order_detail
WHERE dt BETWEEN date_sub('${biz_date}', 30) AND '${biz_date}'

使用UDF封裝復(fù)雜邏輯

-- 注冊UDF
spark.udf.register("calculate_tax", (amount DECIMAL) -> {...});

-- SQL調(diào)用
SELECT order_id, calculate_tax(amount) FROM orders

關(guān)鍵轉(zhuǎn)換邏輯對比：

3.5 過程中遇到的一些問題

1. 數(shù)據(jù)一致性問題

例如某次財報分析發(fā)現(xiàn)：銷售部門的GMV數(shù)據(jù)與財務(wù)系統(tǒng)存在部分差異，追溯發(fā)現(xiàn)：

• 銷售部門使用訂單創(chuàng)建時間統(tǒng)計。
• 財務(wù)系統(tǒng)使用支付成功時間統(tǒng)計（凌晨創(chuàng)建的訂單若在次日支付，會導(dǎo)致日期差異）。

解決方案

• 統(tǒng)一統(tǒng)計口徑：協(xié)調(diào)各部門拉齊統(tǒng)計口徑。
• 校驗機制：每日跑批對比關(guān)鍵指標(biāo)差異率。

2. 數(shù)據(jù)傾斜問題

大促期間，某個爆款的標(biāo)品（例如SKU=888，充電器）的出庫單量占總量比例比較大，屬于熱點數(shù)據(jù)。導(dǎo)致Spark任務(wù)卡在最后一個Reducer，拖慢了整體進(jìn)度。

2.1 原始SQL（存在傾斜）

-- 直接Join導(dǎo)致sku=888的數(shù)據(jù)全部進(jìn)入同一個Reducer
SELECT 
    a.order_id,
    b.sku_name,
    SUM(a.quantity) AS total_qty
FROM fact_orders a
JOIN dim_sku b ON a.sku_id = b.sku_id
GROUP BY a.order_id, b.sku_name;

解決方案
2.2 優(yōu)化后SQL（解決傾斜）

步驟1：對傾斜鍵添加隨機后綴

-- 對事實表中的傾斜sku添加隨機后綴（0-99）
WITH skewed_data AS (
    SELECT
        order_id,
        CASE
            WHEN sku_id = '888' THEN
                CONCAT(sku_id, '_', CAST(FLOOR(RAND() * 100) AS INT)
            ELSE
                sku_id 
        END AS skewed_sku_id,
        quantity
    FROM fact_orders
),

-- 維度表復(fù)制多份（與后綴范圍匹配）
expanded_dim AS (
    SELECT
        sku_id,
        sku_name,
        pos
    FROM dim_sku
    LATERAL VIEW EXPLODE(ARRAY_RANGE(0, 100)) t AS pos
    WHERE sku_id = '888'
    
    UNION ALL
    
    SELECT
        sku_id,
        sku_name,
        NULL AS pos
    FROM dim_sku
    WHERE sku_id != '888'
)

步驟2：關(guān)聯(lián)計算

-- 關(guān)聯(lián)時匹配后綴
SELECT
    a.order_id,
    COALESCE(b.sku_name, c.sku_name) AS sku_name,
    SUM(a.quantity) AS total_qty
FROM skewed_data a
LEFT JOIN expanded_dim b 
    ON a.skewed_sku_id = CONCAT(b.sku_id, '_', b.pos)
    AND b.sku_id = '888'
LEFT JOIN dim_sku c 
    ON a.skewed_sku_id = c.sku_id
    AND c.sku_id != '888'
GROUP BY a.order_id, COALESCE(b.sku_name, c.sku_name);

2.3 執(zhí)行過程對比

通過這種優(yōu)化，我們在實際生產(chǎn)中成功將作業(yè)任務(wù)從 3小時 縮短到 25分鐘，關(guān)鍵點在于：將傾斜數(shù)據(jù)的計算壓力分散到多個節(jié)點，最后合并結(jié)果。

3.6 架構(gòu)對比成果

未來展望

當(dāng)前的離線數(shù)倉架構(gòu)很好地解決了T+1場景下的財報需求，但隨著業(yè)務(wù)發(fā)展，我們對實時財報也提出了更高要求。下一步計劃：

1. Lambda架構(gòu)：批流結(jié)合，在保持離線處理可靠性的同時增加實時處理能力。
2. 技術(shù)棧升級：引入Flink實現(xiàn)流式計算，Kudu提供實時分析能力。
3. 服務(wù)質(zhì)量保障：借鑒微服務(wù)架構(gòu)中的熔斷降級理念，如Sentinel提供的“錯誤率監(jiān)控+人工干預(yù)+主動告警”機制，確保實時管道的穩(wěn)定性。
4. 擴充財報數(shù)據(jù)接入范圍: 結(jié)合數(shù)據(jù)中臺的理念，囊括整個集團財務(wù)毛利、費用相關(guān)財務(wù)指標(biāo)。為后續(xù)做預(yù)測分析打好基礎(chǔ)，提升整體項目價值。

結(jié)語

轉(zhuǎn)轉(zhuǎn)敏捷財報架構(gòu)演進(jìn)過程印證了一個核心理念：沒有最好的架構(gòu)，只有最適合的架構(gòu)。從微服務(wù)到大數(shù)據(jù)的轉(zhuǎn)型不是簡單的技術(shù)替換，而是根據(jù)業(yè)務(wù)發(fā)展階段做出的理性選擇。希望我們的實踐經(jīng)驗?zāi)転槊媾R類似挑戰(zhàn)的團隊提供參考。

最后，在這里想起蘇格拉底說過的一句話:我唯一知道的就是我一無所知。 學(xué)得越多，越能察覺過去的局限，從而以更成熟的視角輕松解決曾困擾自己的問題。

關(guān)于作者：廖儒豪。轉(zhuǎn)轉(zhuǎn)交易中臺研發(fā)工程師