📚 课程目录第2章金融数据工程基础

2. 金融数据工程基础

在进入 Spark 与 Iceberg 的批处理工程实战之前，必须先建立对金融数据本身的系统认知。金融行业的数据具有高价值、强时效、强合规、强关联等特征，如果工程师只关注计算引擎和存储格式，而忽略数据分类、处理模式与建模方式，往往会在后期遇到口径混乱、回溯困难、成本失控等问题。本节从金融数据分类出发，逐步梳理批处理与流处理的边界、数据仓库与数据湖的定位差异，以及常见的金融数据模型，为后续工程实现打下概念地基。

一、金融数据分类：先分清数据，再谈处理

金融数据可以从多个维度分类，工程上最常用的是按“业务来源与时效”划分。理解分类的意义在于：不同类别的数据，其采集频率、存储周期、计算模式、质量要求完全不同，不能套用同一套处理链路。

交易类数据：如成交、委托、转账、支付流水。特点是量大、实时性强、不可篡改，通常要求精确一次处理与严格对账。
行情类数据：如股票、期货、外汇的报价与K线。特点是高频、时序性强、允许少量丢包但要求低延迟。
账户与客户数据：如客户信息、账户余额、持仓。特点是更新频繁、强一致性要求高，涉及隐私合规。
风控与合规数据：如黑名单、反洗钱规则命中记录。特点是规则驱动、需要可追溯、审计留痕。
衍生与统计指标：如收益率、波动率、风险敞口。特点是二次加工产物，依赖上游数据质量。

从工程视角看，交易类与行情类偏向流处理，账户类与统计类偏向批处理，风控类则常常批流结合。分类不是学术标签，而是决定技术选型的第一道判断。

二、批处理与流处理：不是替代，而是分工

批处理与流处理的核心差异在于“数据边界”和“时间语义”。批处理面对的是有界数据集，可以等待数据全部到达后再计算，适合全量重算、复杂关联、历史回溯。流处理面对的是无界数据流，数据持续到达，必须在有限窗口内产出结果，适合实时监控、即时告警、低延迟指标。

对比维度	批处理	流处理
数据边界	有界，按批次读取	无界，持续到达
延迟	分钟到小时级	毫秒到秒级
典型引擎	Spark SQL、Hive、MapReduce	Spark Structured Streaming、Flink
计算特点	全量扫描、复杂 Join、重算方便	增量计算、窗口聚合、状态管理
金融场景	日终清算、T+1 报表、历史回溯	实时风控、行情监控、异常交易告警

需要强调的是，批处理与流处理并非互斥。现代金融数据平台常采用 Lambda 或 Kappa 架构，用流处理做实时链路，用批处理做修正与对账，两者共享同一份存储底座。Iceberg 的价值之一，正是让批与流可以写入同一张表，并通过快照机制保证一致性。

判断该用批还是流，先问三个问题：数据是否有界？业务能容忍多大延迟？是否需要全量重算？三个答案基本就能确定技术路线。

三、数据仓库与数据湖：定位不同，协同演进

数据仓库强调“先建模、后写入”，数据在进入仓库前需要经过清洗、转换、维度建模，Schema 严格，查询性能好，适合 BI 报表与固定口径指标。数据湖强调“先存储、后使用”，原始数据以低成本对象存储保留，Schema 在读时定义，适合探索性分析、机器学习与多源数据汇聚。

金融行业过去以仓库为主，因为监管报表要求口径稳定、可审计。但随着数据量增长和数据源多样化，单纯仓库成本高、扩展慢，数据湖开始承担原始数据沉淀与灵活分析的角色。Iceberg 这类湖仓一体表格式，正是在数据湖之上补足了事务、Schema 演进、时间旅行等仓库能力，使“湖上建仓”成为现实。

四、常见金融数据模型：从范式到维度

金融数据模型决定了数据如何组织、关联与查询。常见模型包括：

范式化模型（3NF）：减少冗余，保证一致性，适合账户、客户等核心实体，常见于核心银行系统。
维度模型（星型/雪花）：以事实表加维度表组织，适合交易分析、报表统计，查询性能好，是数据仓库主流。
Data Vault 模型：由 Hub、Link、Satellite 组成，强调可审计与可扩展，适合多源整合与历史追踪。
时序模型：按时间戳组织行情与指标，强调分区、压缩与时间窗口查询。
宽表模型：将常用维度冗余到一张大表，适合即席查询与特征工程，但需控制更新成本。

在 Iceberg 上落地时，维度模型通常按业务日期分区，事实表按事件时间分区，维度表使用 Merge-on-Read 或 Copy-on-Write 处理缓慢变化维。下面是一个典型的建表示例：

CREATE TABLE iceberg.finance.fact_trade (
  trade_id      STRING,
  account_id    STRING,
  symbol        STRING,
  trade_time    TIMESTAMP,
  amount        DECIMAL(18,2),
  direction     STRING
)
USING iceberg
PARTITIONED BY (days(trade_time))
TBLPROPERTIES (
  'write.format.default' = 'parquet',
  'write.merge.mode' = 'copy-on-write'
);

常见误区：把数据湖当成“不需要建模的垃圾桶”。金融数据若缺乏模型约束，后期对账、审计与指标口径统一将付出极高代价。湖可以灵活，但核心事实与维度仍需明确建模。

五、复盘：基础概念如何影响工程决策

回到工程实践，本节的概念会直接映射为技术决策：数据分类决定采集链路与存储周期；批流边界决定 Spark 作业是批任务还是 Structured Streaming；仓库与数据湖的定位决定 Iceberg 表是面向报表还是面向原始沉淀；数据模型决定分区策略、合并模式与查询性能。把这些基础打牢，后续在 Spark 中读写 Iceberg、做增量合并与时间旅行时，才能清楚每一步“为什么这样做”。