Tim ShenApache Doris 4.x 在量化交易中的完整应用实践
这两年量化交易的战场越来越卷，从最初靠几台 MySQL 加 Python 脚本就能跑的 MVP 策略，到如今 tick 级行情、高频因子、实时信号推送成为标配，数据架构的迭代速度几乎决定了策略团队的迭代速度。今年上半年我们把核心数据底座从一套“MySQL + ClickHouse”的混合架构整体迁移到了 Apache Doris 4.x，到现在已经稳定运行了接近半年。这期间踩过的坑、优化过的模型、处理过的线上事故，不少经验在官方文档里根本找不到现成答案，干脆整理出来，希望能给正在做同类选型或者已经入坑 Doris 的同行一些参考。
这篇文章不是什么架构推广大赛的 PPT 文案，就是一套真实跑在量化交易环境里的 Doris 应用实践。适合三类人看：一是正在做量化数据架构选型的技术负责人，二是已经在用 Doris 但想优化行情存储和因子计算性能的开发者，三是想搞明白量化交易数据链路到底长什么样子的后端工程师。文中涉及的表结构、写入链路、查询优化、故障排查都是我们线上环境的真实操作记录，参数和思路可以直接抄作业，但在抄之前最好先理解后面的设计逻辑，因为量化数据有一个和其他行业很不一样的特点——它同时要求高吞吐写入、极低延迟点查、复杂分析计算，这三者放在一起，对任何数据库都是地狱级考验。
1. 量化交易场景下数据架构的痛点分析
1.1 量化交易对数据系统的四类核心诉求
如果只用一个词概括量化交易对数据系统的要求，那就是“全都要”。传统业务数据库通常只需要把某一类诉求做到极致，比如 MySQL 擅长事务、ClickHouse 擅长分析，但量化策略的整个生命周期横跨数据接入、因子计算、策略回测、实盘交易、绩效归因五个阶段，每个阶段对数据库的诉求完全不一样，这就是大多数团队最终被迫混合部署多套存储系统的根本原因。
具体拆开来看，量化环境一般有四个逃不掉的核心诉求。第一是实时写入能力，行情数据是典型的流式数据，A 股每分钟约产生数万条逐笔成交，美股全市场 tick 级行情一天的原始数据量动辄几十 GB，这意味着数据库必须支持持续不断的高吞吐写入，而且写入峰值出现在开盘瞬间，属于典型的脉冲式流量。第二是低延迟点查能力，实盘交易系统里，下单前需要查持仓、查最新价格、查账户资金，这些点查操作的 p99 延迟如果超过 50 毫秒，高频策略基本就废了。第三是复杂分析能力，因子计算和回测本质上就是把几年甚至十几年的历史行情拉出来做窗口计算、聚合统计、回归分析，这要求数据库具备强大的 SQL 分析能力，最好能支持窗口函数、自定义聚合、数组处理这些高级特性。第四是存储成本可控，行情数据是典型的时序型数据，价值随时间递减，但策略回测又需要长期历史数据，所以存储方案必须在热数据性能和冷数据成本之间找到平衡。
这四类诉求放在一起，就导致了一个很有意思的现象：量化团队的数据架构往往比一般互联网业务复杂得多，因为我们不是在选一个“最好的数据库”，而是在找一套能同时兼顾这些极端诉求的“最小可行组合”。
1.2 传统组合方案：“MySQL + ClickHouse”的拆东墙补西墙
我们团队在迁移到 Doris 之前，用的是一套非常流行的组合：MySQL 负责交易系统的事务数据和实时点查，ClickHouse 负责历史行情存储和因子计算。这套架构在最早期策略还没那么多时跑得挺顺畅，毕竟每个组件都只需要做好一件事。但到了策略数量增加到几十个、因子数量超过上千个之后，问题就一个接一个地暴露出来。
MySQL 这边首先扛不住的是行情写入。开盘期间每分钟数万条的写入请求，加上事务主从同步的延迟，经常导致从库查询延迟达到秒级，而量化策略对数据新鲜度极其敏感——如果你算出来的因子用的还是 3 秒前的数据，在高频场景下这个信号已经失效了。更难受的是 MySQL 对大查询的支持非常弱，一个稍微复杂一点的多表 join 加上窗口函数，就能把实例的 CPU 打满，影响线上交易系统的稳定性。ClickHouse 这边虽然分析能力强，但它的主键更新机制和点查能力实在不行，每次做持仓查询或者按标的精确拉取最新行情，响应时间都让人抓狂。
还有存储层的割裂问题。行情数据放在 ClickHouse，交易数据放在 MySQL，因子结果又放在 Redis 或者文件里，三套系统之间的数据同步靠一堆定时脚本串起来。某一天某个同步脚本出了问题，因子结果和行情数据对不上，策略跑出了完全错误的信号——这种事故我们至少出过三次。最终让我们下定决心整体迁移的导火索，是有一个日内策略需要同时关联 tick 行情、分钟线、订单流和持仓数据做实时计算，每次要跨三套系统取数，查询逻辑复杂到几乎没法维护。那时候我意识到，我们缺的不是更强性能的数据库，而是一套能统一承载这些数据的架构。
1.3 为什么最终选择了 Apache Doris 4.x
说实话，市面上具备“实时数仓”概念的数据库产品不少，StarRocks、Doris、ClickHouse、甚至 TiDB 我都认真测过。最终选择 Apache Doris 4.x，不是因为它某个单项性能最强，而是它在量化场景的综合匹配度最好。这几个理由我可以直接摆出来。
第一，Doris 天然支持高并发点查和复杂分析两种模式，这得益于它的 MPP 架构和智能物化视图机制。实测下来，在百万级分区的行情表上做“按标的加时间范围”的点查，p99 能稳定在 20 毫秒左右，这已经能满足绝大多数中频策略的实时取数需求。第二，Doris 的 Unique 模型支持主键更新且性能不错，这对持仓表、订单表这类需要频繁变更状态的交易数据来说极其关键。第三，Doris 的 Stream Load 和 Routine Load 对高吞吐流式写入支持非常好，单批次百万行写入只需要秒级完成，还支持原子生效，不需要像 ClickHouse 那样做复杂的 partition 替换。第四，Doris 4.x 对标准 SQL 的支持广度已经非常完善，窗口函数、CASE WHEN、高阶聚合、甚至 array 函数和 bitmap 函数都有，这意味着大量因子计算可以直接用 SQL 完成，无需把数据拉到 Python 层再算。
当然还有一层考虑是社区生态。Apache Doris 的社区活跃度这几年有目共睹，中文文档完善，遇到问题基本能找到解决方案，这对我们这种技术团队规模不大、又不希望被商业产品绑死的团队来说，是很实在的安全感。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. Doris 4.x 关键特性在量化场景的落地
2.1 写入性能：从 Kafka 到 Doris 的实时管道
量化数据的写入链路标配是 Kafka 接行情源，然后通过消费端写入数据库。Doris 提供三种常见的接入方式：Stream Load（主动推）、Routine Load（消费 Kafka）、Insert Into（批量写入）。我们在实践中最终形成了两套链路：一套是实时行情通过 Routine Load 直接消费 Kafka 写入明细表；另一套是离线批量计算的因子结果通过 Stream Load 批量导入。
Routine Load 的使用有几个关键参数值得注意。第一个是 max_batch_interval，这个参数控制每次写入的最大时间间隔，默认是 10 秒，如果对数据新鲜度要求高，可以适当调小到 3 到 5 秒。第二个是 max_batch_rows，控制单批次最大行数，默认 10 万行。对于 A 股全市场逐笔成交这种数据量，我们设置的是 5 万行一批，因为行情数据每秒产生的量级已经足够大，不需要靠累积时间凑批次。第三个是 max_error_number，这个参数很容易被忽略，它控制的是容忍的最大解析错误行数。行情数据源偶尔会出现脏数据，如果不设置这个参数，默认容忍 0 错误，任何一个坏消息进来都会让整个消费任务暂停，而这个暂停是不可自动恢复的——我们最开始就是没注意这个参数，导致凌晨行情波动时消费任务挂了，第二天早上开盘才发现数据断档。
Stream Load 我们主要用于批量写入计算结果和回测数据。它的一个非常实用的特性是支持 CSV 和 JSON 两种格式，而且可以通过 -H "columns: col1,col2,temp=now()" 这样的方式在导入时做简单的列变换。比如我们在导入因子数据时，原始文件里只有日期和因子值，目标表里需要额外的 create_time 字段，直接在 Stream Load 里用表达式加一列就行，完全不需要写临时 Python 脚本做预处理。
2.2 查询性能：让策略实时取数成为可能
性能调优是 Doris 用得顺不顺手的核心，特别是点查和聚合分析这两个场景。Doris 的查询性能受到分区裁剪、分桶裁剪、前缀索引三个层面的影响，这个机制我必须展开讲，因为它决定了表结构设计的上限。
分区裁剪是最外层的过滤，查询时如果指定了时间范围，Doris 会只扫描命中的分区，所以行情表按时间分区的收益是立竿见影的。分桶裁剪发生在分区内部，Doris 的分桶键本质上决定了数据在 BE 节点间的物理分布，如果查询条件里带上了分桶键的等值条件，Doris 可以直接定位到指定的桶而无需全扫描。前缀索引则是 Doris 特有的短键索引机制，它会在每个分桶内部维护一个稀疏索引，默认最多 36 个字节，前缀匹配查询可以做到类似 MySQL 聚簇索引的效果。
在真实场景里，我们遇到的最经典问题是分桶键选错导致查询退化为全表扫描。举个具体例子：行情明细表如果按日期分区、按股票代码分桶，那么查询某个股票某天的行情时，Doris 能快速定位到对应的分区和分桶，性能极佳；但如果你按股票代码分区、按日期分桶，查询条件里只有股票代码时，Doris 需要扫描该股票所有日期分桶内的所有数据，虽然分区裁剪能帮你排除掉其他股票，但分桶裁剪完全失效，性能差距可以达到几十倍。这个经验后来被我们写进了团队的表结构设计规范：分区键和分桶键的选择必须与最常见的查询模式强对齐。
2.3 数据模型选型：Duplicate 还是 Unique 还是 Aggregate
Doris 的数据模型是表设计时最重要的决策之一，三种模型有完全不同的适用场景，选错代价极大。我见过不少团队因为贪图 Aggregate 模型的计算简便，把明细数据也设计成 Aggregate 模型，结果导致同一标的同一时间点的多笔交易被预聚合，彻底丢掉了逐笔明细，后面的因子回测根本没法做。这是必须规避的经典错误。
我的建议非常明确：行情明细数据一律用 Duplicate 模型，因为行情天然是追加式的流水数据，不存在更新覆盖的需求，使用 Duplicate 模型可以保留最完整的原始信息，写入性能也最好。持仓、订单、账户这类需要频繁状态变更的数据用 Unique 模型，Doris 4.x 的 Unique 模型支持 Merge-On-Write（写时合并）语义，查询时能拿到实时的最新状态，无需做任何手动合并操作。而因子结果表、K 线聚合表这类数据用 Aggregate 模型最合适，比如你只需要每天每只股票的最高价、最低价、成交量总和，用 Aggregate 模型可以在写入时直接完成预聚合，查询时几乎零计算成本。但前提是你必须完全确定后续不会再需要更细粒度的数据，因为预聚合是不可逆的。
3. 行情、交易、因子三大类表结构实践
3.1 行情表：tick 明细、分钟线、日线的分层设计
行情数据是量化分析的原料，表结构设计直接影响后续所有计算链路的效率和准确性。我们的实践是把行情数据拆成三层，分别对应 tick 明细、分钟线和日线。三个层级的数据量级差异巨大，查询模式差异也巨大，放在同一张表里用物化视图实现并不是不行，但后续维护成本很高，尤其是建物化视图的时间要随着数据量增长而增长，反而会拖累写入链路。所以我们的结论很简单——直接拆表。
先看 tick 明细表的建表语句，这是我们最核心的表之一：
sql复制CREATE TABLE tick_data (
symbol VARCHAR(20) COMMENT '股票代码',
trade_time DATETIME(3) COMMENT '交易时间，精确到毫秒',
price DECIMAL(12, 4) COMMENT '成交价格',
volume INT COMMENT '成交量（股）',
amount DECIMAL(20, 4) COMMENT '成交金额',
bid_price DECIMAL(12, 4) COMMENT '买一价',
ask_price DECIMAL(12, 4) COMMENT '卖一价',
trade_type TINYINT COMMENT '成交类型：0=主动买 1=主动卖 2=中性'
)
DUPLICATE KEY(symbol, trade_time)
PARTITION BY RANGE(trade_time) ()
DISTRIBUTED BY HASH(symbol) BUCKETS 48
PROPERTIES (
"replication_num" = "3",
"dynamic_partition.enable" = "true",
"dynamic_partition.time_unit" = "DAY",
"dynamic_partition.start" = "-30",
"dynamic_partition.end" = "3",
"dynamic_partition.prefix" = "p",
"dynamic_partition.buckets" = "48"
);
这里有几个设计细节值得解释。第一，trade_time 使用 DATETIME(3) 类型，保留毫秒精度，因为 A 股逐笔成交本身就有毫秒级排序，如果只保留到秒，同一秒内多笔交易的先后顺序就无法判断，后续做订单流重构时会出问题。第二，用 Duplicate 模型保留全部明细，不做任何预聚合，因为逐笔数据是最高保真度的原料，未来你永远不知道策略会需要哪种粒度的数据，可以从明细推导聚合，但反过来不行。第三，分区采用动态分区，保留最近 30 天加未来 3 天，这样既控制了存储成本又保证了热数据查询效率；历史数据如果需要长期保留，可以定期通过 Backup 任务或 INSERT INTO 冷热分离表来归档。
分钟线表的设计建议直接在 tick 表上按分钟做间隔计算后写入，而不是通过 Doris 的物化视图自动聚合。原因有两个：一是 tick 表物化视图的构建会消耗大量 BE 资源，尤其在数百万行级 tick 数据上构建分钟线视图，容易出现资源竞争；二是分钟线数据本身需要做一些清洗操作，比如剔除集合竞价阶段的异常单，这在物化视图里实现非常别扭。用定时任务在 Doris 内完成“读取 tick -> 聚合分钟线 -> 写入分钟表”的全流程，逻辑清晰且可控。
3.2 交易数据表：Unique 模型下的事务状态管理
持仓和订单表是量化系统里最需要保证数据一致性的部分，我们用 Unique 模型来实现。
sql复制CREATE TABLE positions (
strategy_id VARCHAR(32) COMMENT '策略ID',
symbol VARCHAR(20) COMMENT '股票代码',
position_date DATE COMMENT '日期',
direction TINYINT COMMENT '方向：0=多头 1=空头',
volume INT COMMENT '持仓数量',
avg_cost DECIMAL(12, 4) COMMENT '持仓成本',
update_time DATETIME COMMENT '更新时间'
)
UNIQUE KEY(strategy_id, symbol, position_date, direction)
PARTITION BY RANGE(position_date) ()
DISTRIBUTED BY HASH(strategy_id) BUCKETS 16
PROPERTIES (
"replication_num" = "3",
"dynamic_partition.enable" = "true",
"dynamic_partition.time_unit" = "DAY",
"dynamic_partition.start" = "-90",
"dynamic_partition.end" = "7",
"dynamic_partition.buckets" = "16"
);
持仓表在实盘交易系统中的使用频率极高，任何一次查询都要求拿到当前最新状态。Unique 模型在 Doris 4.x 版本中默认使用 Merge-On-Write 机制，这意味着查询时不需要做合并操作，直接读取最新的数据行即可。相比此前的 Merge-On-Read 模型，MOR 模型在查询性能上有了数量级提升，但也带来了额外的写入开销，所以在写入链路中我们一般通过批量提交来降低这种开销。
一个很容易踩的坑是：Unique 模型的排序键中包含 position_date，会导致同一策略同一股票同一方向的持仓会按日期生成多行记录，而我们需要的是“当日最新持仓”的概念。所以我们在查询时一律用这样的写法：
sql复制SELECT * FROM (
SELECT *, ROW_NUMBER() OVER (PARTITION BY strategy_id, symbol, direction ORDER BY position_date DESC) AS rn
FROM positions
WHERE position_date <= '2024-06-30'
) t WHERE t.rn = 1;
虽然 Unique 模型本身已经保证了主键的唯一性，但因为你把日期放进了主键，主键的粒度就不是“自然主键”而是“每日快照”，所以需要窗口函数来取最新快照。如果你不想每次查询都写窗口函数，可以在写入侧做一步预处理，把当日的全量持仓快照覆盖写入一张“最新持仓表”，逻辑更清晰，性能也更优。
3.3 因子数据表：为策略研发提供高速特征查询
因子数据是量化团队的智力资产，一个量化平台通常会维护几百到几千个因子。因子数据表的设计直接影响到策略研发的效率——研究员在平台上做因子分析时，最常用的操作就是按日期区间拉取某因子的全量截面值，然后和未来收益做相关性分析。这个场景特别适合用 Doris 的列式存储和批量聚合能力。
sql复制CREATE TABLE factor_daily (
factor_name VARCHAR(64) COMMENT '因子名称',
trade_date DATE COMMENT '日期',
symbol VARCHAR(20) COMMENT '股票代码',
factor_value DECIMAL(20, 8) COMMENT '因子值'
)
DUPLICATE KEY(factor_name, trade_date, symbol)
PARTITION BY RANGE(trade_date) ()
DISTRIBUTED BY HASH(factor_name) BUCKETS 24
PROPERTIES (
"replication_num" = "3",
"dynamic_partition.enable" = "true",
"dynamic_partition.time_unit" = "MONTH",
"dynamic_partition.start" = "-36",
"dynamic_partition.end" = "1",
"dynamic_partition.buckets" = "24"
);
因子表的查询模式非常清晰：按因子名 + 日期区间拉数据，这时 factor_name 作为分桶键就非常合适，查询时等值条件可以直接命中分桶裁剪。但如果你经常做全市场截面分析，即一次拉取所有股票在某一日的因子值，这里的分桶键反而成了阻力，因为因子名如果不固定，查询时会扫描所有的桶。这种场景我在实践中的处理方式是：单独为截面分析建一张行列转换后的表，或者用 Doris 的并行 bucketed scan 能力，让查询引擎并行扫描多个桶，实测下来性能也能接受。
关于 DECIMAL 类型的选择，必须多说一句。因子值的精度千差万别，有些收益率因子可能需要 8 位小数，有些量价因子 4 位就够了。统一使用 DECIMAL(20, 8) 虽然会多占一些存储空间，但能避免后续因为精度不足导致的数据回算问题。我们刚上线时就因为一个因子表用了 DECIMAL(12, 4)，导致某个日收益率因子回算时出现精度溢出，结果多花了一周时间重新跑历史数据，得不偿失。
4. 实时行情接入与 Doris 写入链路实战
4.1 从行情源到 Kafka 再到 Doris 的整体链路设计
量化数据接入的链路在行业里已经形成了相对标准化的范式：行情源（交易所/数据商）→ 行情解析服务 → Kafka → Doris。这个链路设计看起来简单，但细节魔鬼全在中间环节。
我们用的行情源是某数据商的实时行情流，通过行情解析服务把二进制协议解析成 JSON 格式，写入 Kafka 的 tick_data topic。然后 Doris 的 Routine Load 任务负责消费这个 topic。链路设计上有一个重要的取舍：行情解析服务和 Doris 之间要不要加一层 Flink 做流式处理？
我们的答案是：不加。原因是在大多数量化场景下，行情的清洗和加工逻辑相对简单，用 Flink 会引入额外的运维复杂度和故障点。Flink 的 Checkpoint、状态管理、反压监控这些都是需要投入人力维护的，而我们团队只有三个后端工程师。直接用 Doris 的 Routine Load + SQL 可以覆盖 90% 的加工需求。只有在做复杂的实时因子计算、需要跨时间窗口做状态聚合时，才值得引入 Flink。
Routine Load 任务的创建方式如下：
sql复制CREATE ROUTINE LOAD load_tick ON tick_data
COLUMNS(symbol, trade_time, price, volume, amount, bid_price, ask_price, trade_type)
PROPERTIES (
"desired_concurrent_number" = "3",
"max_batch_interval" = "5",
"max_batch_rows" = "50000",
"max_error_number" = "100"
) FROM KAFKA (
"kafka_broker_list" = "192.168.1.10:9092,192.168.1.11:9092",
"kafka_topic" = "tick_data",
"property.group.id" = "doris_tick_group",
"property.client.id" = "doris_tick_consumer",
"property.kafka_default_offsets" = "OFFSET_END"
);
这段 SQL 用起来非常顺手。值得注意几个参数：desired_concurrent_number 控制并发消费数，这里设置为 3，对应 Kafka topic 的 3 个分区，是最大收益组合；property.kafka_default_offsets 设置为 OFFSET_END，意味着任务启动时只消费新数据，这适用于常规启动场景；如果你需要回补历史数据，应该先设置为 OFFSET_BEGINNING，消费完成后再改回来，或者用 Stream Load 直接从 Kafka 回放历史消息到临时表。
4.2 数据一致性：如何保证不丢数、不重复
量化系统对数据准确性的要求极端严苛，一条 tick 数据的缺失或者重复，都可能导致策略计算出错误信号，从而引发错误的交易决策。在 Dos 的数据写入过程中，数据一致性主要靠三个机制保障。
第一个是 Kafka 的 offset 管理机制。Routine Load 会定期将消费位点提交给 Kafka，任务重启后可以从上次的位点继续消费。但这里有个经典的坑：如果任务处理速度跟不上生产速度，出现消费延迟，位点提交和数据处理之间就可能出现间隙，导致部分数据重复消费。Doris 的 Unique 模型能在一定程度上解决重复问题——重复写入相同主键的数据会被覆盖，但 tick 表是 Duplicate 模型，没有主键去重机制，所以重复数据是真实存在的。
我们的解决办法是在表设计层面加入一个客户端生成的唯一 ID 字段，比如 msg_id，用 symbol + trade_time + seq_no 拼接而成。这样即使 Kafka 重复投递，后续查询时也可以依据 DISTINCT msg_id 做去重。虽然会增加一些存储成本，但对后期数据质量稽核和修正提供了极大的便利。
第二个是 Doris 的导入事务机制。Stream Load 是原子生效的，一批数据要么全部导入成功，要么全部失败，不会出现部分写入的情况。这就是为什么批量回补历史数据时我们优先选择 Stream Load 而不是 Insert Into——Insert Into 是逐行提交的，中途失败很难清理半成品数据。
第三个是数据校验机制。我们每天会跑一个定时脚本，分别对比 Kafka topic 的累计消息数和 Doris 中对应日期的记录数，两者差异超过阈值就报警。这个脚本不复杂，但价值极高，它能在第一时间发现数据管道中的异常，比事后人工去核对可靠太多了。
4.3 高吞吐写入的调优策略
开盘时段是行情写入的高峰，Doris 需要同时承受几路高吞吐写入，性能调优如果不到位，经常出现导入延迟、BE 节点内存溢出等问题。以下是我们实践下来最有效的四组调优手段，全部有实测数据支撑。
第一，调整 BE 的 streaming_load_max_mb 参数。这个参数控制 Stream Load 单次导入的最大数据量，默认是 10GB。看起来很大，但实际使用中如果导入文件很大，BE 需要先把数据缓冲在内存中，过大的阈值可能导致内存使用率飙升。我们设置的是 2GB，配合业务侧的分批导入，既能保证吞吐量又不会撑爆内存。
第二，调整 Routine Load 的 max_batch_interval 和 max_batch_rows 协同生效。前面提到过，这两个参数共同决定单批次的写入策略。如果 max_batch_interval 设置得过短，比如 2 秒，而 max_batch_rows 又很大，那么批次会因为时间阈值先触发，导致小批次写入过于频繁。反之，如果时间太长，数据新鲜度又会受影响。需要根据行情数据的实际速率精密调校。我们最终把 max_batch_interval 定为 5 秒，max_batch_rows 定为 5 万行，实测写入延迟平均在 2 到 3 秒之间，数据新鲜度完全满足中频策略的要求。
第三，控制 BE 的写入并发。Doris 有 routine_load_thread_count 参数，控制 Routine Load 的心跳和调度线程数，默认是 10。多 topic 并发消费时，这个参数需要调大。我们遇到过因为线程数不足导致消费任务互相阻塞的情况，把参数调整到 30 后问题消失。
第四，合理设置表的副本数。replication_num 参数控制每个分区的副本数量，生产环境默认是 3。如果集群只有 3 台 BE 节点，3 副本是合理的，因为 Doris 的副本分布策略要求副本数不能超过 BE 节点数。副本数太高会显著增加写入时的网络开销，因为每次写入都需要同步到多个副本。如果你的集群规模不大，可以降低到 2，同时开启跨机架感知策略来保证高可用。
5. 因子计算与回测系统实践
5.1 用SQL直算常用技术指标
因子计算通常被认为是 Python 的专属领域，很多团队从传统 SQL 数仓转过来的人会本能地把数据拉到 Python 里，用 pandas 循环计算几十个因子，再写回数据库。在数据量小的时候这种方式没毛病，但一旦因子库扩展到几百上千个、历史数据覆盖到几年的行情，循环计算的时间成本就会变得完全不可接受。Doris 4.x 的 SQL 函数集已经完全可以撑起常用技术指标的计算，很多场景下用 SQL 直算，速度比 Python + pandas 快一到两个数量级。
以最常用的 5 日移动平均线（MA5）为例：
sql复制SELECT
symbol,
trade_date,
close_price,
AVG(close_price) OVER (
PARTITION BY symbol
ORDER BY trade_date
ROWS BETWEEN 4 PRECEDING AND CURRENT ROW
) AS ma5
FROM daily_bars;
再比如计算动量因子（12 日收益率减去 26 日收益率）：
sql复制SELECT
symbol,
trade_date,
close_price,
(close_price / LAG(close_price, 12) OVER (PARTITION BY symbol ORDER BY trade_date) - 1) * 100 -
(close_price / LAG(close_price, 26) OVER (PARTITION BY symbol ORDER BY trade_date) - 1) * 100 AS momentum_factor
FROM daily_bars;
这两个例子展示了窗口函数在因子计算中的威力，Doris 的窗口函数支持度已经非常完整，包括 ROWS BETWEEN、RANGE BETWEEN、LAG/LEAD、FIRST_VALUE/LAST_VALUE、NTILE 等，基本可以覆盖市面上 80% 的时序因子计算场景。更复杂的因子比如布林带、RSI、MACD，也可以通过 SQL 嵌套子查询一步步实现。
在实践中有几个注意事项。第一，窗口函数虽然强大，但非常消耗内存，在几百 GB 的大表上做窗口计算前，建议先通过 WHERE 条件把数据范围缩窄到必要的日期区间，否则 BE 的 Sort 和 Hash 操作容易把内存打爆。第二，涉及多个窗口函数的复杂计算，建议拆成多个子查询逐步计算，再在外部 join 合并结果，这样既能控制每一层的计算复杂度，也更容易定位问题。第三，如果你确实需要把因子结果导出到 Python 做进一步分析，用 SELECT ... INTO OUTFILE 导出 CSV，或者直接通过 mysql 连接器拉取，比从外部读文件再解析要高效得多。
5.2 回测系统如何依托 Doris 实现高性能数据访问
回测系统的核心需求可以用一句话概括：在最短时间内拉出一段历史行情，供策略模型反复迭代计算。我们自研的回测引擎基于 Python + pandas，通过 SQL 访问 Doris 获取数据。回测性能的关键在于数据拉取速度，而不仅仅是计算速度。
优化取数效率的第一个策略是分区裁剪。回测大多数场景是按日期区间拉数据，例如“拉取 2021 年到 2023 年的分钟线数据”。如果分钟线表是按日期分区的，Doris 能直接裁剪出对应的分区，扫描的数据量将远小于全表扫描。这要求我们在设计表时，必须保证所有可能用到的时间过滤条件都能命中分区键。
第二个策略是使用异步查询。一开始我们用的是同步 SQL 查询，一次拉取一年分钟线数据可能需要十几秒，策略研究员等待响应时要干等着。后来改成异步方式——将查询请求提交到 Doris，定期轮询查询状态，结果就绪后一次性拉取。实测下来，在同样的数据量下，异步查询能节省约 30% 的整体响应时间，因为客户端不需要一直占用连接等待。
第三个策略是数据缓存。Doris 4.x 支持查询结果缓存，对重复执行的查询有很好的加速效果。在回测场景中，同一区间同一标的的行情数据经常被多个策略同时加载，如果在 Doris 层开启缓存，第二次拉取可以直接命中缓存，速度能提升一个数量级。这里要注意的是缓存失效策略，一旦有新数据写入，缓存需要及时失效或手工刷新，我们用的方案是在写入侧完成数据更新后主动调用一次 TRUNCATE TABLE 不现实，而是通过定期刷新缓存或让缓存带上版本号来保证数据一致。
5.3 与 Python 策略代码的联动模式
无论 SQL 能力多强，策略研究员的工作流始终以 Python 为主，因此 Doris 与 Python 的联动模式直接决定了平台的易用性。我们的方案是走 MySQL 协议，Python 端使用 pymysql 或 mysql-connector-python 库连接 Doris，通过 pandas 的 read_sql 函数直接读取 DataFrame。
python复制import pymysql
import pandas as pd
conn = pymysql.connect(
host='doris-fe.example.com',
port=9030,
user='quant_user',
password='******',
database='quant_db'
)
df = pd.read_sql("""
SELECT symbol, trade_date, close_price
FROM daily_bars
WHERE trade_date BETWEEN '2023-01-01' AND '2023-12-31'
AND symbol IN ('000001', '600000')
""", conn)
这套联动的核心价值在于，研究员不需要感知底层存储引擎和数据管道的存在，他们只需要在 Python 环境中写 SQL、拿 DataFrame、跑策略，剩下的都交给了 Doris。当某个查询慢的时候，我们就去分析 SQL 的执行计划，看是分区裁剪没生效还是分桶键不匹配，再针对性地调优表结构或查询语句。
实践中还有一个很实用的小技巧：利用 Doris 的 HTAP 能力，直接在 SQL 里完成一些简单的因子预处理，再把结果导入 pandas 做机器学习的部分。比如先用 SQL 计算好特征和标签，生成一个只包含特征列和标签列的数据集，Python 端拿到的就是可以直接输入模型的数据。这样既发挥了 Doris 并行计算的优势，又避免了 Python 端重复加载大量原始数据的开销。
6. 常见问题与排查技巧实录
6.1 慢查询排查：看懂 Profile 才能定位问题
Doris 的查询执行计划可以通过 EXPLAIN 查看，但如果查询已经跑得特别慢，建议先开启 Profile 功能再执行一次查询，拿到详细的执行统计信息。Profile 是 Doris 排查性能问题最重要的工具，它能显示每个执行阶段的耗时、扫描行数、内存占用等关键指标。
实际排查中我最常遇到的问题是分区裁剪失效。明明表按日期做了分区，查询时也带了日期过滤条件，但 Profile 显示扫描的分区数是全部分区数。这种问题多半是查询语句里的日期字段类型没对上——比如表里 trade_date 是 DATE 类型，但查询条件写成 WHERE trade_date >= '2024-06-01 00:00:00'，这个字符串会被隐式转换成 DATETIME 类型，导致索引无法匹配。解决方法是把过滤条件改为 WHERE trade_date >= '2024-06-01'，问题立刻消失。
另一个高频问题是大表 JOIN 时的数据倾斜。如果 join key 的分布极不均匀，比如某些热门股票的行情数据量远大于其他股票，join 时这些热点数据会集中在某个 BE 节点上执行，导致该节点成为瓶颈。Doris 4.x 对数据倾斜没有自动处理机制，但可以通过修改 join 策略（比如 USE_HASH_JOIN）或者将热点 key 单独拆分处理来缓解。实操上我们会把 join 条件里的时间范围尽量缩小，从源头减少热点数据量。
6.2 数据倾斜与写入热点处理
数据倾斜问题在量化场景中非常典型，因为股票的热度分布极不均匀，像贵州茅台、宁德时代这种龙头股一天成交几百万笔，而大量小盘股一天只成交几千笔。如果分桶键选择不当，某些桶的数据量可能比其他桶大上百倍。这会导致查询时 BE 节点之间的负载严重不均衡，整个查询的耗时被最慢的桶拖住。
我们处理这个问题的经验是分桶键不要直接用股票代码本身，而是加一层哈希分散。比如可以把分桶键改为 hash(symbol) % 128 或者 crc32(symbol) 这样的计算值，这样能相对均匀地把各只股票的数据分散到不同桶中。但副作用是查询时如果只按 symbol 过滤，分桶裁剪策略可能不再生效，所以需要根据实际查询模式权衡。更稳妥的做法是：如果查询模式既要按 symbol 又要按时间，就在分桶键设计时加入多列（比如 symbol, trade_date），让组合查询能够命中裁剪。
另一个写入热点的常见来源是 Routine Load 的消费并发度不够。如果你有 100 个 Kafka 分区，但 Routine Load 只有 10 个并发，那 10 个并发分配 100 个分区的 offset 时就会出现严重的背压。这个问题的解决方案是增加 Routine Load 的 desired_concurrent_number，或者让 Kafka topic 的 partition 数与 Routine Load 的并发数尽量匹配。
6.3 BE 内存溢出与参数调优
Doris BE 的内存管理是很多初学者的噩梦，一旦哪个查询用内存太凶，整个集群的查询都会受影响。Doris 内存相关的核心参数是 mem_limit（BE 进程最大内存百分比，默认 90%）和 exec_mem_limit（单个查询的最大内存，默认 2GB）。在量化场景中，涉及大范围窗口函数和 JOIN 的查询非常容易超过默认的单个查询内存限制。
调优的第一步是把 exec_mem_limit 提高到 8GB 或 16GB，前提是 BE 节点内存足够大。但这不是终点，更重要的优化方向是减少不必要的排序和哈希操作。比如窗口函数里的 ORDER BY 如果不需要，就不要写；COUNT(DISTINCT) 等聚合操作可以考虑改用 APPROX_COUNT_DISTINCT 来降低内存消耗。还有一招是开启 BE 的磁盘 spill 功能，Doris 4.x 支持查询结果溢写到磁盘，虽然会增加 I/O 开销，但至少不会因为内存不够导致查询失败。
遇到过一种比较隐蔽的情况：BE 的内存使用率始终维持在高位，但所有查询看起来都正常。排查后发现问题出在 Routine Load 的内存缓冲区上，因为 max_batch_rows 设置得过大，批次数据在内存中堆积。后来把 max_batch_rows 调小，并调整 stream_load_buffer_size 后，内存水位就回落了。
6.4 小文件与 Compaction 问题
Doris 采用类似 LSM-Tree 的存储结构，数据写入后会产生不可变的 rowset 文件。如果频繁导入大量小批次数据，会积累大量小文件，影响查询和 Compaction 性能。量化场景最容易触发这个问题，因为行情数据是持续流式写入的，如果每 5 秒就生成一个批次，一天下来会产生很多小时文件。
解决思路有两个方向。一是从源头控制：让导入侧尽量批量写入，比如把 max_batch_interval 适当调大，降低写入批次的频率。二是从存储侧优化：调整 BE 的 Compaction 策略参数，如 compaction_policy 和 size_based_compaction，让 Compaction 更积极地把小文件合并成大文件。Doris 4.x 提供了一些自动化的 Compaction 调优参数，可以根据集群实际的数据增长速率来设定 Compaction 的触发阈值。
如果实在有历史数据的小文件问题积压严重，还可以通过 ALTER TABLE ... COMPACT 手动触发一次 Compaction，把当前分区内的文件合并。这个方法在紧急情况下很管用，但不要频繁使用，因为它会占用 BE 的 I/O 资源，可能影响正在运行的查询。
7. 架构演进的后续规划与个人实践心得
把整套系统迁到 Doris 4.x 之后，最直观的感受是日常运维的复杂度大幅下降。原先需要维护 MySQL、ClickHouse、Redis 三条数据通道加一堆同步脚本，现在统一收敛到 Doris 一个引擎上，不管是接入新数据源还是调整数据模型，都只需要和一套系统打交道。数据一致性问题也因为 Doris 的单引擎架构自然解决了——写入一份数据、查询一份数据，不再有跨系统同步的对账问题。
后续在架构上我们还有几个方向在推进。第一个是把更多实时因子计算下沉到 Doris，利用它的窗口函数和聚合能力，让部分原先依赖 Flink 的实时计算也统一到 Doris 上，减少流式处理层的复杂度。第二个是探索 Doris 4.x 的存算分离方案，把冷数据分层到对象存储，进一步节省热数据存储成本。第三个是完善数据质量监控体系，把前面提到的数据一致性对账、分区完整性检查和主键冲突检测做成可视化看板，让数据管道的健康状态一目了然。
最后再分享一个在实际运维中反复证明有效的小技巧：无论你对 Doris 的机制理解得多深，上生产环境前一定要在高仿真数据量和查询模式上做压力测试。我们曾经在测试环境用十分之一的数据量验证过表结构和查询性能，结果上线后因为 BE 节点数量不同、数据分布倾斜程度不同，性能表现和测试环境差了近五倍。所以，量化系统的数据架构没有“测试通过就等于上线 OK”的说法，一定要在接近生产环境的数据规模和并发条件下反复验证，才敢把真金白银的策略压上去。