主题：金融投资讨论
问题：对于一个开源 Python 量化交易平台项目的建议有哪些？
回答：多谢大家的回答，一些问题的交流就发在我的这个回答里了。特别感谢何波、董可人、Mr Mistake、LIKE首先，为什么用python？目前本人所在的公司一共有三款平台，分别基于C++， C#和python。其中C#和python平台都是由交易员开发；C++平台则是由专职IT团队作为一个通用平台开发，内部组件进行了封装（交易员不可见），对外提供行情、交易的API用于策略开发（除了C++ 外也包括C#和python可用的API）。理论上这款C++平台应该是最为稳定和强大的，由专业人士设计，同时采用封装核心，暴露API，支持组件模块开发，linux服务器运行的形式。但是在实际运用中，交易团队表达了一个强烈的观点：这个平台实在是太难用了！1. 
 由IT团队设计的API功能非常强大，但是也太过繁琐，导致学习曲线极为陡峭2. 
 为了追求速度，没有设计原生GUI（本来就为了在Linux服务器上跑），但是今天绝大多数的非超高频（追求微秒级延迟的那种）交易策略，几乎都需要有人实时监控，你总不能让交易员盯着个linux shell上不断print出来的内容或者盘中去翻日志吧，这个运维风险就扛不起。尽管可以作为插件的形式开发GUI，但C++本身的GUI开发还是较为复杂的，非专业IT很难搞的定。3. 
 交易员团队的需求变化很快，通常等不及IT去排班开发，最好是今天收盘有个点子，明天开盘就能开始接实盘数据验证，没问题后天就能上实盘。比如去年四季度的分级基金套利机会就是稍纵即逝，那段时间如果能快速开发完成一套专门的监控套利系统，抓住的利润绝对会比用excel接wind数据来的多不少。4. 
 某些业务逻辑确实太过复杂，交易员想解释让IT明白，无奈IT并不是太擅长某些金融领域（比如期权高频套利的整个业务框架），交流成本太高。用web开发来做比较的话，C++实现的量化交易平台像是java在网络开发领域的地位，强大（几乎无所不能）、稳定（无数大公司的支持），但是也很臃肿（你一两个人开发试试）。以上的原因促成了我坚持使用python开发一个交易平台，这款平台的定位好比于node.js为前端工程师（用户体验的直接缔造者）提供了一个简洁又不失强大的后端平台，主要的目标用户群是中小型量化团队（根据我的经验，绝大部分的券商自营、期货资管和基金量化部门都不大）、专业的交易员团队（可以雇得起少量专职IT）以及一部分打算从互联网领域转行来的程序猿们（python在互联网公司用的不少）。总结下python在量化平台开发方面的优缺点（欢迎补充）。优点：1. 
 动态语言的快速开发特性，封接口有boost.python，写GUI有PyQt，时间序列有numpy，等等，几乎你想干的事都有现成的库可以用，这里吐槽下公司大牛自己写C++里的简单移动平均（SMA）算法，确实比常规实现快不少，但似乎对pnl没什么直接帮助。2. 
 学习成本低，这点算是个共识了吧？3. 
 真需要低延迟的时候，胶水语言很容易通过其他语言拓展：cython, ctypes, boost.python等等。4. 
 运行速度足够快，也许和C++比起来确实慢了不少，但是就我的经验来看，这点速度延迟对90%的策略pnl毫无影响。缺点：1. 
 GIL，该死的全局锁导致python无法有效利用多核CPU的性能，尽管可以通过拓展绕过去，但还是没有其他语言原生多线程利用多核的方案来的简便。2. 
 没有静态类型检查，重构的时候确实有点痛苦，不过一个良好的编程范式可以有效解决这个问题。3. 
 不适合用来搞超高频策略（追求微秒级延迟的差异），得承认这点python确实搞不过C++。常规基于TICK级数据的策略没问题。协议方面打算设计的尽可能宽松一些，代码可以随便修改、使用、分发、做成商业产品拿出去卖，都免费。交易亏钱了别来找我。开源平台的内容目前计划包括：1. 
 一个C++ API的封装框架，国内绝大部分交易API都是C++的，手动写python封装非常繁琐（不难），github上有个pyctp项目尽管已经存在了很久，但人气不高，个人认为和代码复杂度有关（目前据说是使用cython自动生成，没有详细的使用说明）。初期将会封装一个华宝证券LTS的API，一来ETF期权上市我目前也在做，二来和CTP的API几乎通用，金仕达、恒生也都提供通用接口。2. 
 一个事件驱动引擎，这东西不复杂，但是没见过的人第一次确实不好理解，身边大量朋友的经验。3. 
 基于封装API，事件驱动引擎，PyQt的一个桌面交易程序，将会实现LTS柜台上的绝大部分功能。4. 
 一个策略运行接口和策略模板，用于降低从金字塔、TB等软件上转移过来的用户的入门难度。发布平台打算用GitHub，不过今天刚看到海风的AT平台发布在了开源中国上，不知道有什么深意不？关于Quantopian这个确实是欧美在python量化交易领域的先行者，zipline库闻名已久，自己没用过。不过和我这个项目的方向略有不同，一来它接的是IB的API，二来它主要还是为自己的这个web应用服务（在服务器运行）。我的项目将会服务于中国用户，同时希望用户在自己的本地跑，不要受到第三方任何服务器的约束（谁都不想被偷策略）。另外目前在quantopian上并没有看到过特别好的策略，也许好东西不会免费放出来，but who knows.2015/2/26更新董可人的一些评论：1. 
 这个平台的定位处于TB、MC之类的低端量化软件和大型量化团队自己开发的复杂量化平台（Java、C++）之间，目标就是快速上手、开放源代码可以随便改、真要性能不足了容易上拓展（cython等等）。2. 
 Python缺乏静态检测确实是个不小的问题，比较容易出bug，解决方案是：a) 
 平台采取非常简单的核心架构，用户容易掌握所有源代码细节b) 
 测试，其实静态语言写出来的东西也还是得测试，python写测试还快些3. 
 框架本身不包含图形界面，我写上去的一个界面属于简化示例。从python角度上，可以将底层逻辑和GUI分到两个进程中，然后跨进程通讯，但这个方案对于快速开发的需求来说麻烦了点，可以作为业务需求稳定后改进的方向（其实就是我偷懒想交给开源社区来开发，不过确实我自己目前没这块需求）.4. 
 国内的交易API通常是C++的，网络数据收发在C++环境中完成。在API封装中我做了个队列作为缓冲区向python中推数据，防止由于C++ API的回调函数被阻塞导致程序崩溃（这个坑没自己遇到过很难想到会有）。GUI端的更新我在期权做市过程中大概是每秒更新上千个表格中的单元格同时同步刷新大概40多条波动率曲线，耗时也就是几十毫秒而已，要知道国内的数据量和欧美不在一个数量级，所以并不是特别大问题，当然也调整了算法和GUI在事件驱动中的运行顺序后保证算法的优先响应，。5. 
 Esper那玩意太复杂了。我这个事件引擎就是实现不同组件向引擎注册对某个事件的监听，然后事件来了分发通知，懂编程的大神必然觉得是个小case，但对于大部分交易员而言这是个神奇的东西。6. 
 Trader被逼写代码这种事在国内已经成为一个必然趋势了，光是期权做市和套利平台，目前上海这里大量的欧美海龟期权交易员在寻找解决方案，希望这个框架能降低一些进入门槛吧。Mr Mistake的一些评论:1. 
 目前我的整个平台（框架+业务模块）加起来已经上万行代码，设计方面使用了不少OO，确实偶尔我也希望python能报编译错误。。。2. 
 用python的目标就是容易，真要性能我也直接去在公司那个C++平台上写得了。3. 
 Python的GIL就是个大坑，希望目前dropbox那个pyston项目能成功。4. 
 这种快速开发的工作通常是交易员自己负责的，策略不见得是那种长期运行的非常稳定的全自动策略，可能是某种需要程序辅助的半自动交易策略，比如同时监控市场上3000只股票的某些技术特征，然后盘中监控提示，辅助快速下单，用C++当然能写，但等写好估计交易员的需求已经变了。5. 
 国内交易所只提供标准的通信协议，然后由各家柜台公司接入后，对外提供柜台交易接口，通常是C++，期望能试着推动改变这个情况（每个接口都要封也太累了）。2015/3/2 更新项目在Github的地址 vnpy/vnpy · GitHub开发环境说明：windows 7 专业版visual studio 2013 expressboost 1.57.0python环境Anaconda 1.9.2（32位）刚完成了LTS API的封装和行情API的测试脚本，先上传了，接下来的工作顺序是：1. 交易API测试脚本2. 事件驱动引擎3. API的封装方面的教程4. 事件驱动引擎使用方面的教程5. 基于API和引擎开发的LTS交易客户平台（因为华宝没有提供官方的LTS交易软件）6. 策略引擎接口2015/3/3 更新完成了API的封装，上传了交易API的测试脚本。目前玩过boost.python的大神可以通过vnltsmd和vnltstd目录下的C++源代码编译出API，每个目录下的test文件夹里包含了编译好的API，使用方法参见测试脚本。争取明天放出事件驱动引擎后开始制作教程。2015/3/3 二次更新工作效率不错，已经放出了事件驱动引擎，有兴趣的可以看下了。项目的主页发布在http://vnpy.github.io，回头教程会放在这个上面。