IT软件架构
那么对于软件架构，是否也是如此简化呢。按照我粗浅的经验，基本如此。这里提前声明，我指的软件架构并非指单个软件中各个组件是如何整合在一起的架构。我指的是基金在日常的运作中使用的那些应用系统的总和。它们之间是否耦合，如何耦合，我见得太少，所以也不会写。我所做的是从功能上划分不同的应用系统。
首先是数据下载和整理系统。这个应用系统负责的是
- 更新每日实时行情（tick级别，分钟级别和日级别）
- 下载基本面数据和市场交易数据
- 清洗数据，去除无意义项和不需要的项目，并写入数据库
- 为交易相关系统提供所需数据
- 记录根据原始数据产生的二次数据
从数据源来看， 目前提供实时行情的有通联数据，路透，Wind,通达信，国泰安等。历史行情也可以向这些数据提供商购买。由于历史行情数据在TB级别，因此系统所使用的数据库必须根据日期，交易品种和频率等等进行分表存储。可能有的系统使用了Mongo等NoSQL数据库。不过目前的数据源还是以二维表的结构化数据存储方式为主，因此传统的MySQL数据库会更为合适。不同的数据来源定义的数据格式会有许多细微差别，应用系统应该识别这些差别，并将其转化为统一的格式。
从系统资源看，每日的更新必须做到实时，对于IO的要求很高。这就要求网络带宽，内存和硬盘的读写速率都要很高。历史行情则由于数据量大，可以考虑使用磁盘阵列存储。比较好的搭配是万兆以太网，128GB 内存和SSD固态硬盘阵列。
从系统实现上，使用Python和R脚本，结合MySQL数据库会比较合适。首先因为Python和R都提供了数据框变量类型，直接对应关系式数据库的表。其次这三样都不需要费用。如果是的话，Python+MySQL比起R要更为合适。原因是R Studio在多进程运行时会莫名崩溃，且基于Python的金融交易开源社区要好于R，方便快速诊断问题。
接着是策略回测系统。这个系统的功能就是让研究人员简单快速地测试策略的胜率，赔率，回撤等指标。一个可以使用的策略会回测系统应该具有如下功能：
- 提供策略所需要的所有下单，行情和数据引用等API
- 提供一个通用框架，量化研究员可以使用包装好的函数与类，高效实现策略，而不是重复造轮子。
- 定制策略回测指标，记录详细的报告。
- 允许同一策略内引用多市场多品种数据。这点特别适用于统计套利策略和对冲策略。
- 允许多进程运行。这点特别适用于多人共享一套测试环境，也适用于使用脚本批量化测试策略。
- 直接获取新的tick进行回测，不需要反复的数据导入工作。
不过商业软件缺点是收费高昂，对于交易频繁的基金并不合适。其次基金研究人员被绑定在固定平台上，使用平台专用语言开发策略和交易，灵活性欠缺，也不利于策略的转移。软件的更新可能导致策略的失效。另外在涉及tick级别的交易时，这些系统在速度不能满足基金的需求。后，这些软件多是运行在资源耗费较大的windows系统上，比起资源节省，运行稳定的linux系统，速度和成本上都不占优势。顺便提一下，有的基金会很担心商业软件将自己的策略复制，因此不相信商业软件平台。对于个人，这样的担心是没有必要的；对于动辄上十亿的对冲基金，则是很有必要的担心。
因此成熟的私募基金会开发自己的回测平台进行内部策略回测。自主开发的好处是根据自己的要求定制化，成本基本固定，不会根据交易数量上升。语言也可以使用通用的编程语言和大量第三方开发的包辅助开发。但是这么做也有不利之处：从头开始的开发和移植配置成本较大，实时数据的获取和清洗成本较大。在语言上，策略语言多采用Matlab，R, Python。国内目前主流的是Matlab（可能和金融数学专业在学校内就使用Matlab有关）。但是Matlab存在许可昂贵，不支持数据框，函数包支持缓慢的缺点。R语言用来建模快速方便，第三方包也丰富。但是由于设计之初并不考虑效率和并发性，终究不适合工业使用，而在学术界应用更为广泛。Python语言作为后起之秀，已经广泛应用在开源回测平台中，具有更新速度快，函数包丰富，面向对象开发和开源免费等特点
自主开发起始处处陷阱，商业软件又费用高昂，并且不太安全。私募基金可以考虑第三条路，使用网络上的开源回测平台，加以定制化。目前国内基于Python的回测框架几乎都是Zipline 开源项目的国内翻版。Zipline是Quantopian 量化社区平台的专用回测引擎。国内优矿和ricequant就对其开源架构进行了定制化，适应于国内的证券和期货交易回测。ricequant将其改造过的zipline项目也开源在github上。如果是做国内股票日级别交易的回测，不妨使用ricequant改造过的引擎，并在上进行定制化。这样既可以节省开发人力，同时也充分利用了开源社区的人力一起寻找错误。当然，国外还有其他的回测开源项目。如果是做国外证券交易，也可以考虑定制化他们的项目。附一张ricequant开源项目的地址。
https://github.com/ricequant/rqalpha
接下来，我介绍一下为核心的交易系统。交易系统既可以指一种编程实现的交易策略，也可以指交易平台，还可以指某个交易软件。这里，我指的是一种可以执行策略进行下单的交易软件。
交易系统是个筐，实际上常用的交易系统可以按照来源分成券商提供，第三方商业软件，自主开发和开源软件四类。由于国内股票市场的程序化接口被严格监管，因此股票交易多使用券商提供的交易系统或者券商和第三方合作的交易系统。在国内期货市场上，上期所开发的CTP软件接口则向公众免费开放。因此期货端既可以使用期货公司提供的交易软件，也可以自主开发或者使用第三方商业，开源平台，选择是非常的广泛。下面我以券商软件，第三方软件，自主开发和开源软件的顺序开始介绍。涉及的软件都是我使用过或者研究过的。
券商提供的交易软件通常可以统一提供股票，期货的买卖。在架构上，券商架设了软件的服务器端，执行下单和风控功能；基金使用券商的客户端进行下单。笔者接触到的券商可能为了节省成本，多会采用定制化多套商业软件的方式。因此常用的交易软件来源有金证，通达信，讯投，快期和恒生。虽然名目繁多，不过这些软件也有一些共性：
- 客户端运行在windows 上 ，没有Linux版本。究其原因，可能是因为用户界面友好
- 提供常见的下单和查询功能，特别是股票策略需要批量下单功能
- 部分软件提供了TWAP 和VWAP下单，但是股灾后有些券商为避讳程序化交易，终止了此功能。
- 基本不提供给客户二次开发
- 交易的排错主要在券商，本地只有原始的日志记录功能。
- 针对期货的功能较为完备，提供了CTP登录方式
- 不提供行情实时记录功能，但是通达信允许盘后下载数据
- 丰富的报表功能，可以看到指令执行，交易所反馈，资金变动的详细报表，但是数字会有差错，需要和自己的计算结果交叉比对
券商多习惯称呼自己的客户端为PB，大概是Primary Broker的意思。实际使用中，股票交易差强人意。若是期货交易，除了快期，其他都较为繁琐，基本也不提供止损单，预埋单服务。这些软件的面向对象是频率较低，买卖品种和数量不多的主动交易者。举例来说，批量下单功能允许对几百只股票同时发送订单，但是批量下单的输入必须手工执行，程序无法自动进行下单和补单，这对于需要根据实时行情下达大批量订单的交易者是很麻烦的事。虽然可以通过程序自动生成输入文件，但是订单输出和交易控制依然需要手工。
第三方商业软件，多提供给券商定制化后，冠以券商名义公布。也有独立的第三方商业软件，例如QFII会使用根网系统，万德之前也收购了一家叫做宏汇的软件厂商。国外也有一些交易软件支持国内A股市场和期货市场。这些软件的开发思路和特色都源自于其交易业务特点。例如根网系统为QFII使用，其客户端更多的是账务和风控功能；宏汇软件的股票交易和行情显示较为完备。不过这些软件也有各自的问题。根网软件登录偏于繁琐，且容易停止响应。宏汇虽然方便，不过现在已经不再对外提供服务。下面我以一家国外做市商和基金使用的交易软件为例，介绍一下该软件的特点：
- 运行在Linux 上，稳定性好，执行效率高
- 使用Oracle数据库，管理员可以直接访问后台交易数据库
- 提供了进程级别的管理和跟踪，避免程序整体崩溃
- 下单指令极为丰富，适应于国内外不同交易市场
- 支持品种丰富，从期货，现货到衍生品，并且提供了实时风控
- 实现基于组合，金额，交易合约以及其他参数的风险控制
- 内置了套利功能，通过简单的参数即可实现不同交易市场的不同合约之间的任意套利
- 提供了图灵完备的开发语言和IDE, 用户可以直接在交易软件上进行策略编写和运行
- 提供了进程级别日志和日志存档功能，通过debug, info等诊断级别，用户可以获取任意一个组件任意时刻的日志，例如任意一笔交易的报文交互
但是该软件也有一些水土不服的特点，例如：对国内期货夜盘支持不足；文档缺乏，没有足够多的开发文档和使用文档，需要通过软件商支持网站获取帮助； 国内用户缺乏；客户密钥不支持多点登陆，因此券商无法用管理员用户在异地登陆，进行交易前和交易中监控；交易所API支持有限；股票下单通道支持很少，期货也只支持CTP
其中券商难以接受的是，券商无法做到事前风控。只能每天日终时计算交易盈亏。对于监管要求严格的证券投资业，这无疑容易留下监管漏洞。
自主开发软件，由于每家公司都不同，也没法说明。自主开发的交易系统多专门为某一类策略设计。例如有的系统是ETF和期货之间的统计套利，有的系统则为了日内回转交易等等。期货交易系统由于CTP和飞马系统API的公开，多采用自主开发和程序化交易的方法。
后一种是基于开源项目的交易系统。这里推荐的是基于Python的vnpy开源项目。详细请看
GitHub - vnpy/vnpy: 基于python的开源交易平台开发框架
接着是风控系统和交易后清算系统。这两个系统不如交易系统那么闪烁瞩目，涉及的工作也基本是难以创造价值。对于quant来说，这大概就是扫到桌角下的垃圾工作吧。然而，对于投资人来说，一个没有丰富风险控制手段的交易系统就如同没有刹车的跑车；一个清算总是出问题的交易系统等于竹篮打水一场空。
风控系统由于其专业性，我也只是一知半解，所以在此说明的仅仅是抛砖引玉。我工作时需要和券商对接IT系统，对方常问的一个问题是你们支持事前和事中风控么？我说啊，事前和事中有什么区别么？后来查了规定，才知道事前风控指的是交易下订单前对于仓位，敞口，交易涉及的合约等等的核查。事中风控则是指交易过程中对于交易的控制，例如紧急停止交易，紧急平仓等。后是券商很不喜欢的事后风控，就是每天根据交易情况计算风险敞口和交易数量，看是否违反了预定的风控规则。
风控对执行速度要求比较高的是事前风控。想象一下，每条指令发送到市场前必须经过风控规则审核。如果每条指令风控审核需要1秒，那么对于流动性极好的期货市场，1秒已经足够发生好几个小单位的滑点变化了。这些滑点假设是不利于交易方向，那么就是风控造成的损失。假设有100条指令在1s内发送，风控审核需要排队审核，那么后一条指令岂不是得等上一分钟才能发送到市场。当然，这是一个很简单化的例子，就像在真空农场饲养球形鸡一样，没有人会真的这么做。真正的风控系统必然会将事前审核控制在ms级别。
那么风控系统通常会支持哪些限制呢？由于券商的风控都是在服务器端，没有机会得见。就以曾经接触过的一个第三方交易软件举例。比如一条风控规则可以表示为：
当天-用户a-对中金所-期货IF品种-合约1612-买入-数量不超过3-违反则警告
这里每个短线连接的都是一个限定条件，这么写规则的好处是，可以直接使用关系式数据库存储规则。例如可以设计一个规则表，表的字段如下：
时间|用户|组合|交易所|交易品种|合约名|交易方向|数量限制内容|违反处理
这样管理人员就可以针对具体的交易内容实施精细的而监控。当然实际实施时，规则的制定必须考虑到规则之间的互不冲突和相互重叠等问题。如果需要制定一个产品的风控规则，那么需要基金经理根据产品特点，交易所监管，策略回测结果和基金产品的投资限制等作出综合考虑。规则必须能够记录下来作为内部文件，而不是随心所欲地限制或者解除限制。
对于单市场的合约，如上的风控规则已经可以足够。但是对于一些组合产品，则需要仔细和资管方沟通。例如常见的股票用期货对冲的基金产品，股票持有多头，期货持有空头。整个组合的净敞口可能只有1%，但是单独的股票或者期货拿出来就是的多头敞口或者空头敞口。有的资管方设置风控规则时，会单独将股票和期货分离计算。这样很容易就超过合同中规定的敞口比例。
清算系统的主要功能就是日终后计算产品的盈亏和头寸，为下一个交易日的交易做好准备。期货和券商会将清算后的信息在1个工作日内发送给交易方。那么为什么基金还需要单独建立清算系统呢？ 首先因为当券商或者交易所发生差错时，你需要个发现并且提出证据。其次内部的清算可以方便计算出交易部门的绩效；再次下一个交易日的交易内容需要参考现在的敞口和风险值，如果等着券商延迟了几个小时后的通知，那么很多交易程序就没法跑了。
一个好的清算程序应该能够在交易结束的一个小时内得到所有正确的信息。实践中，由于券商的PB客户端给出的交易记录可能并不正确，清算系统往往需要运行两次才能得到终结果。我见过离谱的是有的基金被券商通知违规开仓，结果是券商自己搞错了，呵呵。
比起风控系统，清算系统实现就简单多了。输入是券商提供的csv文件，只要用R/Python脚本处理一下数据就可以得到excel版本的结果文件。实践中比较繁琐的要求是是股票的收盘价格得准确，多个产品的数据格式必须统一，必须确认券商是否因为某种监管需要扣除了一部分费用却没有告知，处理网络故障，系统崩溃带来的延迟等等。当然为头大的是，资管方，通道和券商之间的清算数据交接错误，每一方都在推诿。反正，清算我觉得是后台工作量大的职位了。
安全
- 网络-VPN网络, 内外网隔离
- 系统-模拟和生产隔离,流程控制
- 操作-步骤监控，屏幕记录，基于角色的权限控制
- 数据-下载和外部发送控制，邮箱存档
- 用户-管理员权限和应用权限分离
备份与存档：
- 底层硬件的冗余
- 数据库定时备份
- 内部文档定时备份
- 脚本和系统配置文件更新时备份
- 备份数据定时存档到数据存放点
- 备份时间覆盖7*24小时
- 商业主流备份软件以veritas 为主，覆盖全架构，但是较贵，可以使用国内的一些备份软件，实现备份自动化。同时在系统上部署用脚本语言编写的备份脚本，避免备份软件失败
互联网网站和OA
互联网网站用于展示公司形象，此部分可以使用外包给软件公司需要注意的是互联网系统和公司系统分离，前者好放置于云服务器端，避免对网站的攻击影响到交易和内部运作
OA系统可以外包给软件公司，此部分软件极为成熟。由于OA系统需要同时调用内部数据，并且和外部存在密切沟通，因此在网络安全设置上需慎重，不可赋予数据库及内部其他系统的直接访问，而是将所需数据实时传输到一台中介服务器上，OA系统对中介服务器进行数据访问。
软件架构介绍结束
相关文章