📚 课程目录第3章金融ETL场景分析

3. 金融ETL场景分析

在金融行业落地Airflow之前，必须先回答一个比“怎么写DAG”更根本的问题：我们面对的是什么样的数据场景？金融ETL与互联网日志ETL最大的区别在于：数据源异构且强契约、批流并存且口径必须一致、质量缺陷可能直接触发监管报送错误、每一次重试都必须留下可审计的证据链。本节从四个维度拆解金融ETL场景，为后续DAG编排与重试策略提供设计依据。

一、核心原理：金融ETL的四维约束模型

金融ETL的复杂度并非来自数据量，而是来自四类约束的叠加：数据源契约约束、时效模式约束、质量门禁约束、合规审计约束。这四者共同决定了DAG的调度粒度、任务切分方式、重试边界和日志留存策略。理解它们之间的张力，是设计可靠DAG的前提。

二、方法流程：从场景识别到DAG设计决策

面对一个金融ETL需求，建议按以下流程完成场景分析与设计映射：

识别数据源契约：确认Schema是否稳定、是否有主键、是否支持增量抽取、到达时间是否可预测。对于外部文件，需设计“文件到达检测”任务而非固定时间触发。
判定时效模式：区分T+1批、准实时微批、流式。Airflow擅长批与微批编排，流式通常交给Flink/Spark Streaming，Airflow负责启停与监控。
定义质量门禁：在DAG中插入check任务，校验记录数、金额合计、主键唯一性。质量不通过时阻断下游，而非静默继续。
设计重试边界：区分“可重试”与“不可重试”任务。网络抖动、临时锁可重试；数据质量失败、业务规则冲突不可盲目重试。
落实审计留痕：每个任务输出结构化日志，记录批次号、源文件、记录数、操作人。Airflow的task_instance历史本身就是审计线索。

在金融场景中，建议为每个DAG定义统一的batch_id（如20240612_FIN_LEDGER），贯穿抽取、校验、加载、报送全链路，便于对账与问题追溯。

三、案例场景：日终总账ETL的批处理设计

某银行日终总账ETL，数据源为核心系统Oracle总账表与外部汇率文件。业务要求T+1上午8点前完成报送，且借贷必须平衡。其DAG关键配置如下：

default_args = {
    "owner": "finance_etl",
    "retries": 3,
    "retry_delay": timedelta(minutes=5),
    "retry_exponential_backoff": True,
    "email_on_failure": True,
    "sla": timedelta(hours=4),
}

with DAG(
    dag_id="fin_ledger_daily",
    schedule_interval="0 1 * * *",
    start_date=datetime(2024, 1, 1),
    catchup=False,
    max_active_runs=1,
    default_args=default_args,
    tags=["finance", "ledger", "t1"],
) as dag:
    extract_ledger = OracleOperator(task_id="extract_ledger", ...)
    wait_fx_file = FileSensor(task_id="wait_fx_file", ...)
    check_balance = PythonOperator(task_id="check_balance", ...)
    load_dw = PythonOperator(task_id="load_dw", ...)
    report = PythonOperator(task_id="report_regulatory", ...)

    [extract_ledger, wait_fx_file] >> check_balance >> load_dw >> report

该DAG体现了三个金融场景特征：文件到达检测（FileSensor）、质量门禁（check_balance阻断下游）、幂等重试（load_dw按batch_id先删后插）。若check_balance失败，不应自动重试，而应告警人工介入，因为借贷不平衡通常是源数据问题，重试无法解决。

四、误区与复盘：重试不是万能药

初学者常犯的错误是给所有任务配置相同的重试策略。在金融场景中，这可能导致严重后果：

误区	后果	正确做法
对加载任务无脑重试	重复入账、金额翻倍	按batch_id幂等写入，先删后插或使用merge
质量校验失败也重试	掩盖源数据问题，延误人工排查	质量任务设置`retries=0`，失败即告警
忽略SLA与审计日志	监管检查时无法提供操作证据	开启SLA miss告警，日志留存至少180天
批流口径不一致	同一指标两个数，对账失败	统一指标定义，批流共用同一套校验规则

金融ETL的重试必须满足幂等性。在配置retries之前，先问自己：这个任务执行两次，结果是否与执行一次相同？如果答案是否定的，必须先改造任务逻辑，再开启重试。

复盘一个真实故障：某支付公司对账DAG中，加载任务因网络超时重试三次，由于未做幂等，导致当日交易流水重复入账，次日对账发现差额。根因不是Airflow重试机制，而是任务本身不具备幂等性。修复方案是在加载前按batch_id删除目标分区，再执行插入，使重试天然安全。

综上，金融ETL场景分析的核心结论是：数据源决定抽取方式，时效决定调度模式，质量决定门禁位置，合规决定重试边界与日志策略。只有把这四维约束翻译成Airflow的具体参数与任务结构，DAG才真正具备生产可用性。