一、量化回测数据仓库概述
1.1 什么是量化回测数据仓库
先说说我的理解。量化回测数据仓库，说白了就是为策略回测量身定做的一套数据基础设施。
它不是一个简单的数据库。它是一整套体系——从数据采集、清洗、存储，到查询优化、版本管理，再到数据血缘追踪。我做了这么多年量化系统，见过太多团队在数据上栽跟头。嗯，数据仓库就是用来解决这些问题的。
举个例子。你写了一个简单的均线策略，想回测过去5年的数据。如果没有数据仓库，你可能得手动下载日线数据，存成CSV文件，然后写一堆脚本去处理除权、复权、停牌这些乱七八糟的事情。我刚开始做量化时就这么干过，结果有一次因为复权数据没处理好，策略回测收益差了30%。
数据仓库把这些问题都封装好了。你只需要告诉它：「我要沪深300成分股2018年到2023年的日线数据」，它就能给你一份干净、一致、可复现的数据集。
1.2 核心价值
我总结了一下，数据仓库的核心价值就四点：
- 数据一致性：同一个策略，今天跑和明天跑，结果必须一样。这个看似简单，但我在项目中遇到过，因为数据源更新导致回测结果对不上的情况。数据仓库通过版本控制解决了这个问题。
- 查询效率：回测时经常需要跨品种、跨时间维度查询。没有数据仓库，一个简单的查询可能要跑几分钟。优化后，几秒钟就能出结果。
- 数据质量：脏数据是回测的头号杀手。数据仓库内置了清洗、校验、异常检测机制。我曾经因为一个股票代码的停牌标记没处理好，导致策略在回测中「穿越」了停牌期，收益虚高。数据仓库能帮你避免这种尴尬。
- 可复现性：这是最容易被忽视的一点。你回测了一个策略，半年后想复现当时的回测结果，却发现数据已经变了。数据仓库通过快照和版本管理，确保你能回到任何一个时间点。
一句话总结：数据仓库不是让你「跑得更快」，而是让你「跑得对、跑得稳、跑得可追溯」。
1.3 与传统数据仓库的区别
很多人问我：「这不就是传统数仓那一套吗？」
还真不是。我列个表，你一看就明白了。
| 维度 | 传统数据仓库 | 量化回测数据仓库 |
|---|---|---|
| 数据模型 | 星型/雪花型，面向业务主题 | 时间序列+事件驱动，面向策略 |
| 数据粒度 | 通常为日、周、月 | 支持tick级、分钟级、日级 |
| 更新频率 | 批量更新，T+1为主 | 实时/准实时，支持盘后批量 |
| 查询模式 | OLAP，多维分析 | 时间窗口切片+跨品种关联 |
| 数据版本 | 很少需要版本管理 | 必须支持快照和回滚 |
| 数据质量 | 容忍一定误差 | 零容忍，毫厘之差影响策略 |
你看，区别还是挺明显的。传统数仓关注的是「发生了什么」，量化数仓关注的是「如果当时这么做会怎样」。这个「如果」两个字，对数据的要求就完全不一样了。
一个小技巧：我建议你在设计量化数据仓库时，把「时间旅行」作为核心能力来设计。也就是说，要能回到任意一个历史时间点，看到当时能获取到的全部数据。这个能力在回测中太重要了。
1.4 适用场景
不是所有量化团队都需要数据仓库。我见过一些小型团队，几个人、几台机器，用CSV文件也能跑。但如果你遇到以下场景，数据仓库就是刚需：
- 多策略并行回测：同时跑几十个策略，每个策略需要不同的数据切片。没有数据仓库，数据管理会变成噩梦。
- 高频交易研究：tick级数据量巨大，传统方式根本扛不住。我做过一个项目，每天处理上亿条tick数据，没有数据仓库的话，光IO就能把机器拖死。
- 团队协作：多人同时开发策略，需要共享数据源。数据仓库提供了统一的数据视图，避免各搞一套。
- 合规审计：监管要求回测结果可追溯。数据仓库的版本管理和审计日志正好满足这个需求。
- 因子研究：需要大量历史数据来验证因子有效性。数据仓库的快速查询能力能大幅提升研究效率。
注意：数据仓库不是银弹。如果你的策略只有几条均线，数据量也不大，用CSV文件反而更灵活。别为了用数据仓库而用数据仓库，工具要服务于业务。
1.5 知识体系总览
说了这么多，我画了一张图，把量化回测数据仓库的核心知识体系串起来。你看完应该能有个整体印象。
这张图把量化回测数据仓库拆成了六个模块。每个模块之间都有依赖关系，但核心还是围绕「数据一致性」和「可复现性」这两个目标。我建议你先把这六个模块的关系理清楚，后面再逐个深入。
我的经验：刚开始做数据仓库时，别想着一步到位。先搭一个最小可用版本，把数据采集、存储、查询这三个核心模块跑通。数据治理和运维监控可以后面慢慢补。我曾经见过一个团队，花了大半年设计完美的数据治理方案，结果业务等不及，项目黄了。先跑起来，再优化。
好了，这一章就到这里。量化回测数据仓库的概念、价值、区别和适用场景，你应该有个基本认识了。后面我们会一步步深入每个模块的具体实现。