第二章：量化数据仓库架构设计
聊到量化数据仓库的架构设计，我脑子里第一个蹦出来的词就是「分层」。
为什么？因为不分层的数据仓库，我见过太多惨案了。数据一多，逻辑一乱，查个指标要跑半天，改个字段要改一堆脚本。说白了，分层就是为了让数据「各归其位」，让每一层只干自己该干的事。
2.1 分层架构设计
量化数据仓库的分层，我习惯分成四层：ODS、DWD、DWS、ADS。每一层都有自己的使命。
核心原则：每一层只做一件事，做好一件事。
2.1.1 ODS 层（操作数据存储层）
ODS 层，说白了就是「数据原样落地」的地方。交易所的行情数据、订单数据、成交数据，进来是什么样，存进去就是什么样。
我在项目中遇到过一个问题：有人把 ODS 层当成了「数据清洗层」，直接在 ODS 里做过滤、去重。结果呢？数据回溯时发现原始数据丢了，根本找不回来。嗯，这是个坑。
- 数据来源：CTP、XTP、LTS 等柜台系统
- 存储方式：按日期分区，保留原始格式
- 生命周期：建议保留 3-6 个月，太久了成本高
我曾经踩过的坑：ODS 层不要做任何数据清洗！保留原始数据是底线。你永远不知道哪天需要回溯原始数据来排查问题。
2.1.2 DWD 层（明细数据层）
DWD 层，我称之为「清洗后的明细」。这一层做的事情很纯粹：数据清洗、格式统一、字段标准化。
举个例子，不同交易所的订单状态码不一样。上期所用 0 表示「已报」，中金所用 1 表示「已报」。在 DWD 层，我会统一映射成「ORDER_STATUS_SUBMITTED」这样的枚举值。
- 清洗规则：去重、空值处理、异常值过滤
- 字段标准化：统一时间格式、货币单位、状态码
- 数据粒度：保持与 ODS 一致，不聚合
2.1.3 DWS 层（汇总数据层）
DWS 层，说白了就是「预计算」。量化分析里，很多指标是高频使用的，比如每分钟的成交量、每小时的波动率。每次都从头算一遍？太慢了。
我习惯在 DWS 层按时间维度做预聚合。比如按分钟、小时、天来汇总。这样查询时直接拿结果，不用再跑全量数据。
- 常见维度：时间（分钟/小时/天）、品种、合约
- 常见指标：成交量、成交额、均价、波动率
- 存储策略：按时间分区，定期合并
2.1.4 ADS 层（应用数据层）
ADS 层，就是给业务用的。风控系统、策略回测、报表展示，都从这一层拿数据。
这一层的数据，我建议按业务场景来组织。比如风控需要实时监控，那就建一张「风控指标表」；策略回测需要历史数据，那就建一张「回测数据宽表」。
- 数据来源：DWS 层 + 部分 DWD 层
- 存储方式：宽表为主，减少关联查询
- 更新频率：按业务需求，分钟级或小时级
2.2 数据流向设计
数据流向，说白了就是「数据怎么从源头流到应用」。我画了一张图，你看一眼就明白了。
数据流向其实很简单：从左到右，从上到下。数据源 -> ODS -> DWD -> DWS -> ADS -> 应用。每一层之间通过 ETL 任务连接。
我的个人习惯：每一层的数据都保留一份「血缘关系」记录。这样出了问题，能快速定位到是哪一层、哪个任务出的问题。
2.3 技术选型：OLAP vs OLTP
这个问题，我经常被问到。量化数据仓库，到底用 OLAP 还是 OLTP？
我的回答是：看场景。
| 特性 | OLTP | OLAP |
|---|---|---|
| 典型场景 | 订单写入、账户更新 | 历史分析、聚合查询 |
| 数据模型 | 行式存储 | 列式存储 |
| 查询特点 | 小范围、频繁更新 | 大范围、批量扫描 |
| 典型产品 | MySQL、PostgreSQL | ClickHouse、Doris |
说白了，OLTP 适合「写多读少」的场景，比如实时订单入库。OLAP 适合「读多写少」的场景，比如历史行情分析。
我在项目中，ODS 层会用 OLTP 来承接高频写入，DWD 层以上则用 OLAP 来加速查询。你想想看，如果拿 ClickHouse 去接实时订单流，那写入性能会很难看。
2.4 存储与计算引擎选择
存储和计算引擎的选择，我总结了一个「三看」原则：看数据量、看查询模式、看实时性要求。
2.4.1 存储引擎
- HDFS：适合海量历史数据存储，成本低。我一般用来存超过一年的原始行情数据。
- ClickHouse：列式存储，聚合查询极快。DWS 层的预聚合数据，我首选它。
- Redis：内存数据库，适合实时指标缓存。比如当前持仓、实时盈亏。
2.4.2 计算引擎
- Spark：适合大规模批处理。我用来做每日的 DWD 层清洗任务。
- Flink：适合实时流处理。比如实时行情接入、实时风控计算。
- Doris：适合即席查询。分析师想查什么，直接写 SQL 就行。
我的经验：不要追求「大而全」。量化团队通常不大，选 2-3 个核心组件就够了。我现在的团队，就是 ClickHouse + Spark + Flink 三件套，覆盖了 90% 的场景。
2.5 避坑指南
最后，分享几个我踩过的坑。
我曾经犯过的错：一开始把所有数据都放在 ClickHouse 里，结果发现实时写入性能跟不上。后来才把 ODS 层拆出来用 MySQL 承接写入，ClickHouse 只做查询。嗯，这个教训花了我两周时间。
另一个坑是「过度分层」。有人把数据仓库分了七八层，结果数据流转链路太长，延迟高得离谱。我的建议是：四层就够了，别整太复杂。
好了，这一章的内容就到这里。分层架构、数据流向、技术选型，这三块是量化数据仓库的骨架。骨架搭好了，后面填肉就轻松了。
公众号:蓝海资料掘金营，微信deep3321