目前绝大部分海友接触到的平台都是集成式的平台,包括QD。集成式的结构其实不是一个理想的企业级应用环境。我认为到了对冲基金这个组织阶段,就要考虑分布式和进程组件化的平台体系了。在这个方面,marketcetera的设计框架:中心数据库+服务代理+消息队列总线+多样化应用前端的设计是正确的,也同金融业务的基本特征吻合。 开发和实施效率上,采用JAVA这样通用语言而不是又一种脚本语言能够满足快速建模和部署的要求。在linux环境下,速度也不是问题(何况还有realtime linux)。 在接口上,除非一定需要特殊设计的高速行情接口,如lime(也是JAVA的),否则FIX是一种更好的业务描述语言。对于专业投资机构来说,我不认为还应该考虑其他的方案(来写基于行情事件的策略)。THINKING IN FIX IS MUCH MORE IMPORTANT THAN COMMUNICATION IN FIX。
分布式的管理在wj提起之前实际上我也有想法。尤其在得知数据库技术的革新和Fix之后。 不过,在接口方面我的确存在开发困难。 另外还有个更关键的问题,不同的市场和策略,实际上需要的平台不尽相同,这样一来我担心另一个层面的效率问题。所以采取了变形虫的解决方法,来优化效率,目前效果不错。 而如果是单一平台不同客户端,那么服务器如果出现堵塞和多队列排序造成的延迟,以及服务器端瘫痪的话,就没办法。因此而产生的监督成本实在太高。而如果是独立个体,则能保持总体占优。不知这方面有何想法? 但是总体来讲,实际上我还是倾向于中心数据库+服务代理+消息队列总线+多样化应用前端的设计的。这种平台似乎美国有好几个公司都在卖和设计吧,我遇到过几个推销的。只不过国内市场的支持很不好。
QD构架里也可以是分布式平台的,并不一定是集成式的平台。而且qd本身的那个datacenter和cats设计构架不错的。 qd的构架本身就可以是一个中心数据库+服务代理+消息队列总线+多样化应用前端的设计。
新文章,比较Activequant, Marketcetera, etc http://ulrich.activequant.com/mba/2...es-and-competive-position-of-activequant.html
这个,好像是在用IT来套金融,而不是用金融来套IT了。 作为IT人,over-engineering无可厚非。但是实施时间,实施成本和最终效率都不会太理想。 据我所知,有些HF的系统就是一个KDB+和8页的Q代码,that's all!
我Faint了。。。用XML Scehma来描述order还情有可缘,毕竟用来做集成很方便。用来描述strategy绝对过了 pros: native MQ support easier to integrate within firm cons: bad performance twist logical longer go-live time (at least double??) thanks any way for sharing the knowledge of FIX_ATDL
可能不会,该公司的人已经透露了下一个版本2.1.0是商业版,不过似乎还在开会讨论中。 另外,虽然现在公司主页发布的是1.5.0版,但实际上你可以下载到1.6.0版的源代码,链接在这里: http://code.marketcetera.org/root/tags/