大饼量化的性能考虑

babyquant babyquant量化研究 2024-01-20 03:07

一般做大饼量化可以很丰富，目前大概有300多个品种，其实做法可以非常多，比如永续跟现货之间的套利，不同交易所的套利，不同合约之间的套利，永续和交割之间的套利等等。另外像趋势、对冲其实也是可以的。应该说，大饼的业务，其实是非常适合量化的。毕竟基本面因素不是很强。品种之间线性关系比较强，容易形成对冲，当热缺点是不容易分散风险。

如果是个人来做，反而不大需要考虑性能方面的问题。比如主流交易所，可以支持300个websocket连接，其实自己也交易不了这么多，另外留一些连接来收私有数据，说不定几个账户呢？但如果是一个量化团队来做，则很不一样。

有人说人多力量大，为什么人多了反而不行呢？因为一般来说，不大可能每个人配置一台服务器，可能会存在共用服务器的情况。这个时候，如果每人几百个websocket，那么总量肯定超，然后交易所会有限频，情节较轻的警告，严重的封锁IP地址，有的交易所几个小时恢复，有的几天。如果遭遇到封锁IP，那么对业务将是毁灭性的打击。如果一个团队10个人，由于某个人的程序原因被封IP，可能会遭到其他同事的白眼，甚至是排挤。

因此，一些公司会使用一些共用后台或者中台的概念。阿里之前提出过中台计划，据说效果不是特别好。原因非常多，比如前台不配合，跟后台界限模糊，中台有自己的KPI，不想沦为前台的附庸。当然了，正如《年会不能停》里面说的，“问题的关键就是关键的问题，你们想清楚了再跟我说，我没有那么多时间”，其实这种领导也挺好当的。类似国内最顶级的经济学家曾经说过，“美国发生金融危机的根本原因在于，这些金融机构，没有做好危机管理。所以，我们要吸取教训，在开展业务的时候，时刻注意风险管理，才能有效地避免危机的发生”。

如果是交易清算，账户申请，资金划转等，这些属于后台业务，估计没什么异议。至于对接不同交易所的接口，申请服务器，网络流量监控，服务器内存、CPU监控，这些也属于后台业务，技术性较强的后台，这个应该也没什么异议。只是更进一步，比如弄一个服务，专门接收各个交易所的数据，缓存在一些内存数据库，比如Redis，供大家使用；对不同交易所统一接口；不同交易所的数据乘数、格式进行转换，提取共同部分等等；这个不大像前台（毕竟这些东西并不直接跟盈亏挂钩），但也不是很后台，因此可以算作中台。还有就是对业务风险指标的管理，可能也属于中台。

比如各个交易所的book ticker、order book、market trade数据，可能大家都要用的，那么就自己用独立的服务缓存起来。当然，可能还是会有一些问题。比如这相当于做了一个websocket或实时数据转发的工作，但事先并不知道别人想用哪个，有可能一个程序订阅了某个数据，就把内存中所有数据都推了过去，这样反而会增加单个程序的内存。这又需要人们用多进程、多线程的方式，一个程序同时交易很多个品种，这样数据只用拿一次，否则要复制很多份。甚至很多编程语言，多进程的本质就是复制数据到不同的进程，本质上还是存在数据冗余，占用大量内存。如果跟别人共用服务器，又会产生一些新的矛盾。

还有共用账号产生的问题。比如每个账号都有限频，大家一起用，总量就容易超，然后大家都没得用。所以很多时候，团队运作未必能产生1+1>2的效果，这需要管理得当。能共享的资源尽量共享，比如公共数据；不能共享的，比如私有信息，其实分开账号反而比较好。各个交易所对私有信息的管理也是分帐号进行。

对于数字货币这种7*24交易的品种，收取行情和交易策略分开来其实比较好，这样不至于程序启动才收行情，容易丢失。因此，可以用单独的程序一直收行情，一直计算指标，保存起来，交易程序启动时，直接读取就行。对中低频尤为关键，高频不需要太多历史数据反而好一些。

当然了，这些跟策略能否赚钱没有太直接的关系，但如果处理得好，可以提高研究和交易的效率。如果处理不好，可能也会带来额外的风险。