普通公司对账系统的现实困境与解决方案

前言

作为一个普通公司的后端，最近在负责 SaaS 的对账系统重构。理想很丰满，现实很骨感。今天想聊聊小公司做对账系统时，可能会遇到的一些真实问题。

一、理想与现实的差距

1.1 理想中的数据分层架构

按照数仓建设的最佳实践，一个完善的对账数据体系应该是这样的：

ODS (Operational Data Store) - 操作数据层
  ↓
DWD (Data Warehouse Detail) - 明细数据层
  ↓
DWS (Data Warehouse Service) - 汇总数据层
  ↓
ADS (Application Data Service) - 应用数据层

每一层都有明确的职责：

• ODS 层：存储原始业务数据，保持与源系统一致
• DWD 层：对数据进行清洗、规范化，建立一致性维度
• DWS 层：按主题进行汇总统计，构建各类指标
• ADS 层：面向具体应用场景的数据集市

1.2 小公司的现实情况

但现实是什么样的呢？

ODS
  ↓
基础汇总表 (日统计数据)
  ↓
后端代码硬算 (WHERE + GROUP BY + SUM)

为什么会这样？

1. 人力资源不足：小团队可能只有 1-2 个人负责数据相关工作
2. 排期压力大：业务需求排期紧张，DWS 层建设"没有那个排期"
3. 优先级问题：对账功能能用就行，而且需求也不会整理得特别详细

所以最终只能：

• 基于源数据构建一个 ODS 层
• 从 ODS 清洗出一份基础的日统计数据
• 剩下的统计查询，后端代码自己算，这样子就能灵活适用任何场景

二、核心痛点

这种"能跑就行"的架构，会带来两个核心问题。

2.1 痛点一：数据查询性能压力

由于缺少汇总层（DWS），所有的多维度查询都需要在基础数据表上进行实时计算。

典型场景：

-- 查询最近7天的对账汇总数据
SELECT
    DATE(order_time) as stat_date,
    channel_id,
    SUM(amount) as total_amount,
    SUM(refund_amount) as total_refund,
    COUNT(*) as order_count
FROM reconciliation_daily_base
WHERE stat_date BETWEEN '2025-11-01' AND '2025-11-07'
  AND merchant_id = 12345
GROUP BY DATE(order_time), channel_id;

性能瓶颈：

• 即使建了索引 (merchant_id, stat_date)，但 GROUP BY 和 SUM 仍需要大量计算
• 查询时间段越长，扫描的数据量越大
• 多个维度的组合查询（如按渠道、门店、支付方式等多维度统计），性能急剧下降
• 并发查询时，数据库压力倍增

实际体验：

2.1.2 为什么索引也救不了？

-- 索引能优化 WHERE 条件的过滤
-- 但 GROUP BY 和聚合函数需要读取并处理大量数据行
EXPLAIN SELECT
    channel_id,
    SUM(amount)
FROM reconciliation_daily_base
WHERE merchant_id = 12345
  AND stat_date >= '2025-10-01'
GROUP BY channel_id;

-- 执行计划可能显示:
-- Using index condition (索引有效)
-- Using temporary; Using filesort (需要临时表和排序，性能杀手)

2.2 痛点二：数据质量问题

2.2.1 问题根源

由于是重构，元数据来自老旧的业务表，这些表往往：

• 经历过多次迭代和重构
• 字段语义不清晰
• 存在历史遗留的脏数据
• 业务逻辑复杂且文档缺失
• 往往这类的任务，要求的时间也紧急

2.2.2 典型数据质量问题

测试覆盖不完备

支付场景比较多：

对账数据偏差示例：

-- 业务数据统计: 应退款金额 5000元
SELECT SUM(refund_amount) FROM orders WHERE refund_status = 'REFUNDED';
-- 结果: 5000

-- 第三方对账单: 实际退款 4500元
SELECT SUM(refund_amount) FROM wechat_reconciliation WHERE type = 'REFUND';
-- 结果: 4500

-- 差异: 500元 (现金退款部分未记录)

2 数据一致性问题

-- 场景: 订单主表 vs 支付流水表
-- 主表显示: 订单已支付
SELECT * FROM t_order WHERE order_no = 'OD123' AND pay_status = 1;

-- 支付表: 找不到支付记录
SELECT * FROM t_payment WHERE order_no = 'OD123';
-- 结果: 空

-- 原因可能:
-- 1. 主表状态手工修改
-- 2. 支付回调失败但业务补偿了
-- 3. 历史数据迁移时丢失

三、我们如何尽量预防

既然资源有限，就要用有限的资源解决核心问题。

3.1 方案一：性能问题的优化思路

核心策略

1. 限制查询范围

   • 提前跟业务方沟通，限制查询时间范围
   • 别想着花那么多时间精力去维护多维度的汇总统计，这件事吃力不讨好
   • 限制时间范围能解决大部分问题

2. 异步导出长时间查询

   • 如果业务方真的有需求，提供异步导出的功能
   • 避免长时间查询阻塞接口

3. 不要缓存！不要缓存！

   • 对账是一件很精细的事情
   • 如果有问题也需要我们及时调整，去重新维护数据
   • 增加缓存就是增加一致性处理的工作量

3.2 方案二：数据质量的保障措施（重点）

由于时间紧迫，业务逻辑复杂，所以监控是重中之重。能提前发现对账差异，方便我们及时维护。

3.2.1 建立对账差异预警机制

核心思路：使用定时任务对比业务数据和对账数据，发现差异及时告警

@Slf4j
@Component
@JobHandler("dailyTransactionAmountValidationHandler")
public class DailyTransactionAmountValidationHandler extends IJobHandler {

    @Resource
    private ExtraOrderDAO extraOrderDAO;

    @Resource
    private ExtraFsOrderSummaryDayDAO extraFsOrderSummaryDayDAO;

    @Override
    public ReturnT execute(String param) throws Exception {
        log.info("校验近三日总交易额任务开始执行");

        try {
            List summaries = new ArrayList<>();

            // 获取近三天的数据进行对账
            for (int i = 1; i <= 3; i++) {
                Date targetDate = DateUtil.offsetDay(new Date(), -i);
                String dateStr = DateUtil.format(targetDate, "yyyy-MM-dd");

                // 1. 获取业务数据 - 每个商户的实际销售额
                List> merchantSummaryList = extraOrderDAO
                    .selectRealMoneySumByMerchantWithPayTime(/* 时间范围参数 */);

                // 2. 获取对账库数据 - 对账系统的商户销售额
                Integer tradeDay = Integer.parseInt(DateUtil.format(targetDate, "yyyyMMdd"));
                List> reconcileMerchantList = extraFsOrderSummaryDayDAO
                    .selectUserMoneySumByTradeDayAndBelong(tradeDay, 2);

                // 3. 计算并校验差异
                DailyTransactionSummary summary = calculateAndValidateDailySummary(
                    merchantSummaryList, reconcileMerchantList, dateStr);
                summaries.add(summary);
            }

            // 4. 发送汇总告警通知
            sendMultiDayValidationAlert(summaries);

            return ReturnT.SUCCESS;
        } catch (Exception e) {
            log.error("对账任务执行异常", e);
            return new ReturnT<>(ReturnT.FAIL_CODE, "任务执行异常: " + e.getMessage());
        }
    }

    /**
     * 计算并校验差异
     */
    private DailyTransactionSummary calculateAndValidateDailySummary(
            List> merchantSummaryList,
            List> reconcileMerchantList,
            String date) {

        DailyTransactionSummary summary = new DailyTransactionSummary();
        summary.date = date;

        // 将业务数据和对账数据转为 Map 便于比对
        Map merchantDataMap = merchantSummaryList.stream()
            .collect(Collectors.toMap(
                map -> map.get("uid").toString(),
                map -> (BigDecimal) map.get("realMoneySum")
            ));

        Map reconcileDataMap = reconcileMerchantList.stream()
            .collect(Collectors.toMap(
                map -> map.get("uid").toString(),
                map -> (BigDecimal) map.get("realMoneySum")
            ));

        // 遍历对账库数据，与业务数据进行比较
        for (Map.Entry entry : reconcileDataMap.entrySet()) {
            String uid = entry.getKey();
            BigDecimal reconcileAmount = entry.getValue();
            BigDecimal orderAmount = merchantDataMap.getOrDefault(uid, BigDecimal.ZERO);

            // 金额不一致，记录差异
            if (orderAmount.compareTo(reconcileAmount) != 0) {
                MerchantDataDiff diff = new MerchantDataDiff();
                diff.uid = uid;
                diff.orderAmount = orderAmount;
                diff.reconcileAmount = reconcileAmount;
                diff.difference = orderAmount.subtract(reconcileAmount);

                if (diff.difference.compareTo(BigDecimal.ZERO) != 0) {
                    summary.dataDiffList.add(diff);
                    log.warn("商户 {} 数据不一致 - 订单: {}, 对账: {}, 差异: {}",
                        uid, orderAmount, reconcileAmount, diff.difference);
                }
            }
        }

        // 检查业务数据中有而对账库中没有的商户
        for (String uid : merchantDataMap.keySet()) {
            if (!reconcileDataMap.containsKey(uid)) {
                BigDecimal orderAmount = merchantDataMap.get(uid);
                if (orderAmount.compareTo(BigDecimal.ZERO) != 0) {
                    MerchantDataDiff diff = new MerchantDataDiff();
                    diff.uid = uid;
                    diff.orderAmount = orderAmount;
                    diff.reconcileAmount = BigDecimal.ZERO;
                    diff.difference = orderAmount;
                    summary.dataDiffList.add(diff);
                    log.warn("对账库中未找到商户 {} 的数据，订单交易额: {}", uid, orderAmount);
                }
            }
        }

        return summary;
    }

    /**
     * 发送钉钉告警
     */
    private void sendMultiDayValidationAlert(List summaries) {
        // 检查是否所有日期都没有差异
        boolean hasAnyDiff = summaries.stream()
            .anyMatch(summary -> !summary.dataDiffList.isEmpty());

        if (!hasAnyDiff) {
            log.info("所有日期均无数据差异，不发送告警");
            return;
        }

        StringBuilder message = new StringBuilder();
        message.append("**近三日商户数据差异汇总报告**nn");
        message.append("**报告时间**: ")
            .append(DateUtil.format(new Date(), "yyyy-MM-dd HH:mm:ss")).append("nn");

        for (DailyTransactionSummary summary : summaries) {
            if (summary.dataDiffList.isEmpty()) {
                message.append("**").append(summary.date).append("**: 无差异n");
            } else {
                message.append("**").append(summary.date).append("**: 差异")
                    .append(summary.dataDiffList.size()).append("个商户n");

                // 统计差异类型
                long orderOnlyCount = summary.dataDiffList.stream()
                    .filter(diff -> diff.reconcileAmount.compareTo(BigDecimal.ZERO) == 0)
                    .count();
                long reconcileOnlyCount = summary.dataDiffList.stream()
                    .filter(diff -> diff.orderAmount.compareTo(BigDecimal.ZERO) == 0)
                    .count();
                long amountMismatchCount = summary.dataDiffList.size()
                    - orderOnlyCount - reconcileOnlyCount;

                if (orderOnlyCount > 0) {
                    message.append("  - 订单独有(对账库缺失): ").append(orderOnlyCount).append("个n");
                }
                if (reconcileOnlyCount > 0) {
                    message.append("  - 对账库独有(订单缺失): ").append(reconcileOnlyCount).append("个n");
                }
                if (amountMismatchCount > 0) {
                    message.append("  - 金额不一致: ").append(amountMismatchCount).append("个n");
                }

                // 按差异金额从大到小排序，显示详情
                List sortedDiffs = summary.dataDiffList.stream()
                    .sorted((a, b) -> b.difference.abs().compareTo(a.difference.abs()))
                    .collect(Collectors.toList());

                message.append("  - 差异商户详情:n");
                for (int i = 0; i < sortedDiffs.size(); i++) {
                    MerchantDataDiff diff = sortedDiffs.get(i);
                    message.append("    ").append(i + 1).append(". 商户").append(diff.uid)
                           .append(" - 订单:¥").append(diff.orderAmount)
                           .append(" | 对账:¥").append(diff.reconcileAmount)
                           .append(" | 差异:¥").append(diff.difference).append("n");
                }
            }
            message.append("n");
        }

        // 发送钉钉告警
        DingDingRobotAlertUtil.alert(message.toString());
        log.info("差异告警发送完成");
    }

    // 内部类
    private static class DailyTransactionSummary {
        String date;
        List dataDiffList = new ArrayList<>();
    }

    private static class MerchantDataDiff {
        String uid;                     // 商户ID
        BigDecimal orderAmount;         // 订单交易额
        BigDecimal reconcileAmount;     // 对账库交易额
        BigDecimal difference;          // 差异金额
    }
}

关键实现点：

3.2.2 数据清洗规则显性化

把容易出问题的业务规则，通过配置或代码明确出来：

@Configuration
public class ReconciliationRuleConfig {

    /**
     * 跨渠道退款规则
     */
    @Bean
    public ReconciliationRule crossChannelRefundRule() {
        return ReconciliationRule.builder()
            .ruleName("跨渠道退款检测")
            .ruleType(RuleType.VALIDATION)
            .condition(order ->
                !order.getPayChannel().equals(order.getRefundChannel()))
            .action(order -> {
                // 记录差异
                logDifference(order, "跨渠道退款",
                    String.format("支付渠道:%s, 退款渠道:%s",
                        order.getPayChannel(),
                        order.getRefundChannel()));

                // 只在支付渠道统计支付，不统计退款
                // 退款金额单独记录到调整项
                return ReconciliationAdjustment.builder()
                    .type("CROSS_CHANNEL_REFUND")
                    .amount(order.getRefundAmount())
                    .build();
            })
            .build();
    }

    /**
     * 隔日退款规则
     */
    @Bean
    public ReconciliationRule crossDayRefundRule() {
        return ReconciliationRule.builder()
            .ruleName("隔日退款处理")
            .ruleType(RuleType.MAPPING)
            .condition(order ->
                !order.getPayDate().equals(order.getRefundDate()))
            .action(order -> {
                // 退款金额计入退款发生日，而非支付日
                return ReconciliationMapping.builder()
                    .statDate(order.getRefundDate())
                    .type("REFUND")
                    .amount(order.getRefundAmount())
                    .build();
            })
            .build();
    }
}

四、总结

小公司做对账系统，不是技术能力不行，而是资源有限的现实约束。

性能问题的本质

• 不是没有 DWS 层就一定慢
• 而是要在有限资源下，找到性价比最高的优化点
• 限制查询范围 + 异步导出，已经能解决 80% 的问题

数据质量的本质

• 不是测试覆盖率 100% 就没问题
• 而是要建立发现问题、解决问题的机制
• 差异预警 + 核心场景回归 + 人工复核，形成闭环

最重要的