第1章：因子平台技术栈选型

做因子平台这些年，我最大的感触就是——技术栈选型这事儿，真不是拍脑袋决定的。你想想看，一套平台少说跑两三年，选错了后面全是坑。今天我就把我在实战中踩过的雷、总结的经验，掰开了揉碎了讲给你听。

1.1 编程语言选择：Python vs C++

先说结论：核心计算用C++，策略研发用Python。这不是和稀泥，是血泪教训换来的。

我在项目中遇到过一件事：某团队用纯Python做全市场因子计算，3000只股票、100个因子，跑一次要40分钟。后来我把核心循环用C++重写，时间直接降到3分钟。嗯，这就是差距。

Python的优势：

• 生态丰富：pandas、numpy、scikit-learn随便用
• 开发速度快：写策略原型，一天能迭代三个版本
• 社区活跃：遇到问题StackOverflow上基本都有答案

C++的优势：

• 执行效率高：同样的逻辑，C++比Python快10-50倍
• 内存控制精细：大数据场景下，内存就是钱
• 适合高频场景：微秒级的延迟差异，可能就是盈亏分界线

1.2 数据处理框架：Pandas vs Spark

这个问题其实很简单：数据量决定框架。

场景	推荐框架	原因
单机数据量 < 10GB	Pandas	轻量、灵活、上手快
单机数据量 10GB-100GB	Pandas + 分块处理	内存不够？分块来凑
数据量 > 100GB	Spark	分布式计算，不解释
实时流处理	Spark Streaming	低延迟、高吞吐

我个人习惯是：能用Pandas绝不用Spark。为什么？因为Spark的调试成本太高了。你写个groupby，在Pandas里一行搞定，在Spark里要调半天分区、shuffle、内存配置。

但话说回来，当你的数据量真的上去了，Pandas就扛不住了。我记得有一次处理全市场Tick数据，单日数据量就超过50GB。Pandas直接OOM，换成Spark后，虽然慢了点，但至少能跑完。

1.3 消息队列：Kafka vs RabbitMQ

消息队列的选择，说白了就是吞吐量 vs 灵活性的权衡。

Kafka：

• 设计目标：高吞吐、持久化、分布式
• 适合场景：日志收集、流式处理、数据管道
• 缺点：配置复杂、运维成本高

RabbitMQ：

• 设计目标：灵活路由、可靠投递、易用性
• 适合场景：任务调度、异步处理、微服务通信
• 缺点：吞吐量有限、消息堆积能力弱

我在项目中遇到过这样的选择：因子平台需要实时接收行情数据，然后分发给多个策略引擎。行情数据的特点是量大（每秒几万条）、但每条数据很小。这时候Kafka就是天然的选择——它的分区机制能保证数据顺序，高吞吐能扛住行情峰值。

但如果是策略信号的传递，比如A策略算出一个信号，要通知B策略执行交易，这时候RabbitMQ更合适。因为它的路由灵活，可以精确控制谁收到什么消息。

1.4 数据库选型：ClickHouse vs MySQL vs Redis

数据库选型是因子平台最关键的决策之一。我见过太多团队，用MySQL存时序数据，结果查询慢到怀疑人生。

ClickHouse：

• 列式存储，适合OLAP场景
• 压缩比高，存储成本低
• 查询速度快，特别是聚合查询
• 缺点：不支持事务，不适合频繁更新

MySQL：

• 行式存储，适合OLTP场景
• 支持事务，数据一致性有保障
• 生态成熟，工具丰富
• 缺点：大数据量查询慢，扩展性差

Redis：

• 内存数据库，速度极快
• 支持多种数据结构
• 适合缓存、计数器、实时排行榜
• 缺点：数据量受内存限制，持久化能力弱

我个人习惯的搭配是：

• 因子数据存储：ClickHouse。日频数据、分钟数据、Tick数据，全往里面塞。查询速度快，压缩比高，存储成本低。
• 元数据管理：MySQL。因子定义、策略配置、用户信息，这些需要事务保证的数据，交给MySQL。
• 缓存层：Redis。热点数据、计算结果、临时信号，放Redis里，毫秒级响应。

知识体系总览

最后说一句：技术栈选型没有标准答案。我给你的建议是基于我的经验，但你的场景可能完全不同。关键是要理解每个工具的优缺点，然后根据你的数据量、性能要求、团队能力来做选择。