利益相关: RQAlpha 作者我没有完整看过 zipline 的源码，所以回答中对于 zipline 的评价未必准确，如有纰漏，请指出。RQAlpha 和 Zipline 都是 Event-Driven Algorithmic Trading Library, 都源于在线算法回测网站(Quantopian, Ricequant), 都发展为可以进行实盘交易的算法引擎。有人说国内在线算法交易网站没有一个是原创，全部是改了zipline 的源码，然后套了个网站的皮，在这点我并不认同的，虽然是两个很相似的引擎，但底层实现、核心特点还是有很大区别的。接下来我谈一下几个核心问题的看法:[h1]API[/h1]Ricequant 最初基于以下原因在 API 设计上和 Quantopian 保持一致:- Quantopian API 设计优良(至少当时是这么觉得的，实际并不是...)
- Quantopian API 已经得到了很多用户的反馈和优化
- Ricequant 有做美股及吸引海外用户的打算，保持 API 的一致性，可以降低用户学习和转化成本
基于以上原因，在通用性的部分比如 `init`, `handle_bar`, `context.portfolio` 等内容上采取了和 Quantopian 一致的 API。但是，熟悉 Ricequant 的朋友应该知道，当初 Ricequant 是同时支持 Java 和 Python 两种回测的，实际上第一代回测引擎是使用 java 编写的，而 java 程序的 API 与 Quantopian 并不相同。而对应的 python 回测是在 java 引擎上面包装了一层用来支持 Python 代码运行的。虽然 Java 回测引擎速度非常快，但通过 Python 这一层转换，回测速度并不理想，甚至还没有直接通过 Python 回测速度要快，因此才有了后来的 RQAlpha 项目，而 RQAlpha 为了保证向前兼容，也沿用了原本 API 定义。然而，在 RQAlpha 的发展过程中，API 也是不断变化的，从而导致现在和 Zipline 的 API 形似神离，差异已经很大了。感兴趣的话可以看一下之前写的关于 API 和底层逻辑变更的 Issue:[h1]数据存储格式[/h1]均使用 bcolz 作为底层回测数据存储格式。这个没什么好说的，bcolz 压缩率高，性能好，本身就是列式存储容器，大家都爱用。[h1]性能[/h1]事件驱动的算法引擎，回测速度都不会太快，每一个 bar 要触发一堆的事件，并且各种模块要响应事件，并完成具体的业务逻辑，这个时间消耗相对于直接基于时间序列做计算或者做信号来说，肯定差异是巨大的，至少差一两个数量级。所以在这点上，RQAlpha 和 Zipline 速度在回测框架中并不算是很快的。相比之下，Zipline 对于数据读取、处理做了不少 Cython 优化，RQAlpha 逻辑较之复杂些，功能更多一些，虽然我没有测试，但是应该回测速度 Zipline 应该更快一些。但其实功能不同，直接进行速度的比较并没有太大的意义。RQAlpha 速度上还是有挺大提升空间的，只不过目前可能有其它更重要的事情去做。不过未来我可能会做一套基于 C 的 CEP 并兼容当前 RQAlpha 的 Mod，从而真正满足对于速度、延迟更高标准的要求。[h1]架构[/h1]RQAlpha 经历过多次的重构，目前形成了以事件为触发机制，通过 Mod 来实现具体业务逻辑的组织结构，比 Zipline 扩展性和灵活性要强得多，可以非常容易的支持各种扩展。这里有一个2.2.x 版本的结构图(最新版本还没来得及更新)传送门: RQAlpha_structure | 思维导图（新） | ProcessOn![]()
目前已经拥有了很多的扩展 Mod。比如对接期货实盘的扩展: ricequant/rqalpha-mod-ctp比如对接富途港股的扩展: FutunnOpen/OpenQuant内部对接财务数据、分钟数据、tick数据回测的扩展甚至客户端应用的扩展: RQPro--专业级本地量化终端 - 论坛专栏RQAlpha 的架构另一特点就是真正支持多品种交易，也就是说一个策略里可以同时交易股票、期货，也可以交易你扩展的任意交易类型。其实说来说去，可能也没有解答提问者的疑惑，那么直接说结论吧....如果做国内交易，首选 RQAlpha (你去看看期货的计算逻辑就明白了，全世界独一家的复杂)如果做国外交易，首选 Zipline如果是编程、量化新手，两个都不要选，先打好基础，这些过于复杂。如果是想要做扩展，首选 RQAlpha，你可以再不改 RQAlpha 代码的情况下根据你自己的业务场景进行任意扩展，无论你是想交易比特币，还是想做策略收益分析，还是想增加风控模块等 |
转播
