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

这样相当于用同一套计算框架和代码解决了Lambda架构中开发和运维比较复杂的问题.当然如果数据量很大的情况下,可以增加流式计算程序的并发度来解决速度的问题.

由于金融行业在业务上受限于T+1交易,在技术上严重依赖关系型数据库(特别是Oracle).在很多场景下,数据并不是以流的形式存在的,而且数据的更新频率也并不是很实时.比如为了做技术面分析的行情数据,大多数只是使用收盘价和历史收盘价(快照数据)作为输入,来计算各类指标,产生买卖点信号.

因此这是一个典型的批处理的场景.另一方面,比如量化交易场景,很多实时的信号又是稍纵即逝,只有够实时才存在套利的空间,而且回测和实盘模拟又是典型的流处理.鉴于以上金融行业特有的场景,我们实现了我们自己的架构(GF-Lambda),它介于Lambda和Kappa之间.一方面能够满足我们处理数据的需求；一方面又可以达到技术上的同构,减少开发运维成本.根据对数据实时性要求,将整个计算部分分为三类：

• Spark SQL：代替MapReduce或者Hive的功能,实现数据的批量预处理；
• Spark Streaming：近实时高吞吐的mini batching数据处理功能；
• Storm：完成实时的流式数据处理；

GF-Lambda的优势如下：

• 在PipeLine的驱动方面,采用Airbnb开源的Airflow,Airflow使用脚本语言来实现整个PipeLine的定义,而且任务实例也是动态生成的；相比Oozie和Azkaban采用标记语言来完成PipeLine的定义,Airflow的优势是显而易见的,例如：

  整个data flow采用脚本编写,便于配置管理和升级.而Oozie只能使用XML定义,升级迁移成本较大.

  触发方式灵活,整个PipeLine可以动态生成,切实的做到了“analytics as a service”或者 “analysis automation”.

• 另外一个与Lambda或者Kappa最大的不同之处是我们采用了Redis作为缓存来存储各个计算服务的状态；虽然Spark和Storm都有Checkpoint机制,但是CheckPoint会影响到程序复杂度和性能,并且以上两种技术的CheckPoint机制并不是很完善.通过Redis和Kafka的Offset机制,不仅可以做到无状态的计算服务,而且即使升级或者系统故障,数据的可用性也不会受到影响.
• 整个batch layer采用Spark SQL,使用Spark SQL的好处是能做到密集计算的后移.由于历史原因,券商Oracle等关系型数据库使用比较多,而且在开市期间数据库压力也比较大,此处的Spark SQL只是不断的从Oracle批量加载数据(除了Filter基本在Oracle上做任何计算)或者主动的通过Oracle日志旁录数据,对数据库压力较小,同时又能达到数据准实时性的要求；另外所有的计算都后置到Yarn集群上进行,不仅利于程序的运维,也利于资源的有效管控和伸缩.架构实现如下图所示：

CEP在证券市场的应用的有非常多,为了读者更好的理解上述技术架构的设计,在此介绍几个典型应用场景.

1)自选股到价和涨跌幅提醒

自选股到价和涨跌幅提醒是股票交易软件的一个基础服务器,目的在于方便用户简单、及时的盯盘.其中我们使用MongoDB来存储用户的个性化设置信息,以便各类应用可以灵活的定制自身的Schema.在功能上主要包括以下几种：

• 股价高于设定值提醒.
• 股价低于设定值提醒.
• 涨幅高于设定值提醒.
• 一分钟、五分钟涨幅高于设定值提醒.
• 跌幅高于设定值提醒.
• 一分钟、五分钟跌幅高于设定值提醒.

主要的挑战在于大数据量的实时计算,而采用GF-Lambda可以轻松解决这个问题.数据处理流程如下：

首先从Kafka订阅实时行情数据并进行解析,转化成RDD对象,然后再衍生出Key(market+stockCode),同时从Mongo增量加载用户自选股预警设置数据,然后将这两份数据进行一个Join,再分片对同一个Key的两个对象做一个Filter,产生出预警信息,并进行各个终端渠道推送.

2)自选股实时资讯

实时资讯对各类交易用户来说是非常重要的,特别是和自身严重相关的自选股实时资讯.一个公告、重大事项或者关键新闻的出现可能会影响到用户的投资回报,因此这类事件越实时,对用户来说价值就越大.

在GF-Lambda平台上,自选股实时资讯主要分为两部分：实时资讯的采集及预处理(适配)、资讯信息与用户信息的撮合.整个处理流程如下图所示：

在上图分割线左侧是实时资讯的预处理部分,首先使用Spark JDBC接口从Oracle数据库加载数据到Spark,形成DataFrame,再使用Spark SQL的高级API做数据的预处理(此处主要做表之间的关联和过滤),最后将每个Partition上的数据转化成协议要求的格式,写入Kafka中等待下游消费.

（编辑：ASP站长网）