1. 课程导入
金融历史行情数据是量化研究、风控回溯、监管报送与智能投研的共同底座。它看起来只是“时间+价格+成交量”，但真正进入生产环境后，数据量、更新频率、乱序程度、复权口径与合规要求会迅速放大复杂度。本课程以“湖仓数据生命周期”为主线，带你从数据接入、存储、计算、服务到归档与销毁，建立一套可落地、可治理、可审计的工程方法。第1章先建立全局认知：行情数据到底特殊在哪里，湖仓架构为什么适合它，以及生命周期管理应该如何分阶段推进。
一、金融历史行情数据的五个特点
理解行情数据的特点，是后续所有架构决策的起点。它不同于一般互联网日志，也不同于传统数仓中的交易流水，核心差异体现在以下方面。
- 时间序列强有序、强分区：行情天然按交易所、品种、交易日、时间片组织。查询常带时间范围与标的过滤，分区设计直接决定扫描成本。
- 多频率并存：从日线、分钟线、Tick到逐笔委托与逐笔成交，频率越高，数据量呈指数级增长，对写入吞吐和存储成本提出不同要求。
- 乱序与延迟到达：不同交易所、不同行情源、不同采集链路会导致数据迟到、重复、乱序，必须依靠事件时间与水位线机制处理。
- 口径复杂且易变：复权方式、停牌标记、涨跌停价格、集合竞价阶段、指数成分调整等，都会影响同一标的在不同时点的可比性。
- 合规与审计要求高：历史行情常涉及授权范围、留存期限、访问权限与脱敏要求，数据不能“只进不出”，也不能“随意删除”。
这些特点决定了：行情数据平台不能只追求“存得下”，还要解决“查得快、算得准、管得住、删得掉”。
二、湖仓架构对行情数据的价值
传统做法中，数据湖擅长低成本存储原始数据，但缺少事务、Schema演进与高效更新；数据仓库擅长治理与查询，但扩展成本和半结构化数据处理能力有限。湖仓一体在对象存储之上引入表格式与元数据层，使行情数据可以同时获得湖的弹性与仓的治理能力。
对金融行情场景而言，湖仓的价值主要体现在四点：
- 一份存储、多种计算：原始Tick、清洗后分钟线、复权因子、衍生指标可共享同一份底层数据，避免多套副本导致口径漂移。
- 支持增量与幂等写入：通过事务表格式实现按分区覆盖、按主键合并，解决行情补数、重跑与重复到达问题。
- Schema演进与时间旅行：当交易所字段调整或业务新增指标时，可平滑演进；回溯研究可读取历史快照，保证结果可复现。
- 分层治理与成本控制：热数据用高性能格式服务在线查询，冷数据转列式压缩并下沉至低成本存储，生命周期策略可自动执行。
核心判断：湖仓不是简单把Hive换成Iceberg或Delta Lake，而是用“表格式+元数据+生命周期策略”把数据从一次性ETL产物，变成可管理、可追溯、可演进的资产。
三、数据生命周期管理的整体框架
生命周期管理可以理解为一条从“产生”到“消亡”的链路。对行情数据，我们将其划分为六个阶段：接入、存储、加工、服务、归档、销毁。每个阶段都有明确的目标、关键动作与治理指标。
| 阶段 | 核心目标 | 关键动作 | 典型指标 |
|---|---|---|---|
| 接入 | 完整、低延迟、可追溯 | 采集、缓冲、去重、打标 | 端到端延迟、丢包率 |
| 存储 | 低成本、高可靠、易扫描 | 分区、压缩、表格式选型 | 单位存储成本、扫描字节数 |
| 加工 | 口径统一、结果可复现 | 清洗、复权、聚合、回填 | 任务成功率、数据质量分 |
| 服务 | 查询快、权限清、SLA稳 | 物化视图、缓存、API网关 | P95查询延迟、并发能力 |
| 归档 | 合规留存、成本可控 | 冷热分层、格式转换、校验 | 归档完整率、恢复时长 |
| 销毁 | 合规删除、不可恢复 | 策略审批、级联删除、审计 | 删除执行率、审计通过率 |
这六个阶段不是线性瀑布，而是持续循环。例如服务层发现某指标异常，会触发加工层回填；归档策略变化，也会反向影响存储分区设计。因此，生命周期管理必须与元数据、血缘、权限和监控联动。
四、案例场景：一次分钟线回填暴露的问题
某团队在月初发现，部分标的的分钟线在除权日前后出现价格断层。排查后发现：原始Tick已正确接入，但复权因子表在除权日当天未及时更新，导致加工层使用了旧因子；同时，回填任务按自然日分区覆盖，误删了同日其他批次的数据。最终通过三件事修复：
- 在接入层增加复权因子变更事件监听，因子更新后自动触发下游重算；
- 将回填策略从“按分区覆盖”改为“按主键合并+版本标记”，保留多批次可追溯；
- 在服务层增加除权日前后价格连续性校验，异常时阻断对外发布。
这个案例说明：生命周期管理不是单点工具，而是接入、加工、服务与治理的联动。任何一个环节缺少版本意识或质量门禁，都会在最终查询结果中放大为业务风险。
实践建议：在项目初期就定义好“数据版本”和“口径版本”。行情数据的可复现性，往往比查询速度更影响研究结论的可信度。
五、常见误区与复盘要点
初学者在构建行情湖仓时，容易陷入以下误区：
- 只按日期分区：高频行情下，单日数据量可能极大，需结合交易所、品种或时间片二级分区，避免全分区扫描。
- 忽视乱序与重复：没有事件时间与去重主键，补数或重跑会产生重复记录，导致聚合结果虚高。
- 把湖仓当“万能仓库”：所有查询都直连原始Tick，既慢又贵。应按服务场景建设物化视图或聚合层。
- 归档即删除：归档前必须校验完整性、可恢复性与合规留存期限，不能简单转移后删除源数据。
- 缺少审计闭环：销毁阶段没有审批与审计记录，一旦监管检查将无法证明删除的合法性与执行范围。
复盘提醒：生命周期策略必须可配置、可观测、可回滚。任何自动删除或自动归档动作，都应先经过灰度验证与人工审批，再进入生产执行。
六、学习路径：从认知到落地
本课程后续将沿着“接入—存储—加工—服务—归档—销毁”的主线展开，每一阶段都会结合真实行情场景、表格式选型、分区策略、质量规则与治理工具进行讲解。建议你带着三个问题学习：
- 这份数据在生命周期中处于哪个阶段？它的SLA和成本目标是什么？
- 如果发生补数、重跑或口径变更，我的设计能否保证幂等与可追溯？
- 当合规要求删除某段历史数据时，我能否快速定位、级联清理并留下审计证据？
把这三个问题贯穿始终，你就能从“会写ETL”进阶为“能设计行情数据资产”的工程师。下一阶段，我们将进入数据接入与原始层设计，看看Tick与快照数据如何被稳定、低延迟地纳入湖仓体系。