基于Lambda架构的股票市场事件处理引擎实践(3)

左侧数据ETL的过程是完全由Airflow来进行驱动调度的,而且每次处理完就将状态cache到Redis中,以便下次增量处理.在上图的右侧则是与用户强相关的业务逻辑,将用户配置的信息与实时资讯信息进行撮合匹配,根据用户设置的偏好来产生推送事件.

此处用Kafka来做数据间的解耦,好处是不言而喻的.首先是保证了消息之间的灵活性,因为左侧部分产生的事件是一个基础公共事件,而右侧才是一个与业务紧密耦合的逻辑事件.基础公共事件只有事件的基础属性,是可以被很多业务同时订阅使用的.

其次从技术角度讲左侧是一个类似批处理的过程,而右侧是一个流处理的过程,中间通过Kafka做一个转换与对接.这个应用其实是很具有代表性的,因为在大部分情况下,数据源并不是以流的形式存在,更新的频率也并不是那么实时,所以大多数情况下都会涉及到batch layer与speed layer之间的转换对接.

3)资金流选股策略

上面两个应用相对来说处理流程比较简单,以下这个case是一个业务
稍微繁琐的CEP应用-资金流策略交易模型,该模型使用资金流流向来判断股票在未来一段时间的涨跌情况.它基于这样一个假设,如果是资金流入的股票,则股价在未来一段时间上涨是大概率事件；如果是资金流出的股票,则股价在未来一段时间下跌是大概率事件.那么我们可以基于这个假设来构建我们的策略交易模型.如下图所示,这个模型主要分为三部分：

1)个股资金流指标的实时计算

由于涉及到一些业务术语,这里先做一个简单的介绍.

资金流是一种反映股票供求关系的指标,它的定义如下：证券价格在约定的时间段中处于上升状态时产生的成交额是推动指数上涨的力量,这部分成交额被定义为资金流入；证券价格在约定的时间段中下跌时的成交额是推动指数下跌的力量,这部分成交额被定义为资金流出；若证券价格在约定的时间段前后没有发生变化,则这段时间中的成交额不计入资金流量.当天资金流入和流出的差额可以认为是该证券当天买卖两种力量相抵之后,推动价格变化的净作用量,被定义为当天资金净流量.数量化定义如下：

其中,Volume为成交量,为i时刻收盘价,为上一时刻收盘价.

严格意义上讲,每一个买单必须有一个相应的卖单,因此真实的资金流入无法准确的计算,只能通过其他替代方法来区分资金的流入和流出,通过高频数据,将每笔交易按照驱动股价上涨和下跌的差异,确定为资金的流入或流出,最终汇聚成一天的资金流净额数据.根据业界开发的CMSMF指标,采用高频实时数据进行资金流测算,主要出于以下两方面考虑：一是采用高频数据进行测算,可以尽可能反映真实的市场信息；二是采取报价(最近买价、卖价)作为比较基准,成交价大于等于上期最优卖价视为流入,成交价小于等于上期最优买价视为流出.

除了资金的流入、流出、净额,还有一系列衍生指标,比如根据流通股本数多少衍生出的大、中、小单流入、流出、净额,及资金流信息含量(IC)、资金流强度(MFP),资金流杠杆倍数(MFP),在这里就不一一介绍.

从技术角度讲,第一部分我们通过订阅实时行情信息,开始计算当天从开市到各个时刻点的资金流入、流出的累计值,及衍生指标,并将这些指标计算完成后重新写回到Kafka进行存储,方便下游消费.因此第一部分完全是一个大数据量的实时流处理应用,属于Lambda的speed layer.

2)买卖信号量的产生及交易

第二部分在业务上属于模型层,即根据当前实时资金流指标信息,构建自己的策略模型,输出买卖信号.比如以一个简单的策略模型为例,如果同时满足以下三个条件产生买的信号.反之,产生卖的信号：

• (大单资金流入-大单资金流出>0) && (中单资金流入-中单资金流出>0)
• 大单的资金流信息含量>50%
• 大单的资金流强度>20%

在技术上,这个应用也属于Lambda的 speed layer,通过订阅Kafka中的资金流指标,根据上面简单的模型,不断的判断是否要买或者卖,并调用接口发起买卖委托指令,最后根据回报结果操作持仓表或者成交表.(注意此处在业务上只是以简单的模型举例,没有涉及到更多的细节)

3)持仓盈亏实时追踪及交易

第三部分在业务上主要是准实时的盈亏计算.在技术层面,属于Lambda 的batch layer.通过订阅实时行情和加载持仓表/成交表,实时计算用户的盈亏情况.当然此处还有一些简单的止损策略,也可以根据盈利情况,发起卖委托指令,并操作持仓表和成交表.最后将盈利情况报给服务层,进行展示或者提供回调接口.详细的处理流程如下图所示：

正如文章前面强调的一样,写这篇文章的初衷是希望大家从大数据丰富的生态中解放出来,与业务深度的跨界融合,从而开发出更多具有价值的大数据应用,真正发挥大数据应有的价值.这和Lambda架构的作者Nathan Marz的理念也是十分吻合的,记得他还在BackType工作的时候,他们的团队才五个人,却开发了一个社会化媒体分析产品——在100TB的数据上提供各种丰富的实时分析,同时这个小的团队还负责上百台机器的集群的部署、运维和监控.

当他向别人展示产品的时候,很多人都很震惊他们只有五个人.经常有人问他：“How can so few people do so much?”.他的回答是：“It’s not what we’re doing,but what we’re not doing.”通过使用Lambda架构,他们避免了传统大数据架构的复杂性,从而产出变得非常显著.

在五花八门的大数据技术层出不穷的当下,Marz的理念更加重要.我们一方面需要与时俱进关注最新的技术进步 – 因为新技术的出现可能反过来让以前没有考虑过或者不敢想的应用场景变成可能,但另一方面更重要的是,大数据技术的合理运用需要建立在对行业领域知识深刻理解的基础上.大数据是金融科技的核心支撑技术之一,我们将持续关注最前沿的大数据技术与架构理念,持续优化最符合金融行业特点的解决方案,构建能放飞业务专家专业创新能力的技术平台.

邓昌甫,毕业于中山大学,广发证券IT研发工程师,一直从事大数据平台的架构、及大数据应用的开发、运维和敏捷相关工具的引入和最佳实践的推广(Git/Jenkins/Gerrit/Zenoss).

文章出处：聊聊架构(订阅号ID:archtime)

（编辑：ASP站长网）