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

《基于Lambda架构的股票市场事件处理引擎实践》要点：
本文介绍了基于Lambda架构的股票市场事件处理引擎实践，希望对您有用。如果有疑问，可以联系我们。

CEP(Complex Event Processing)是证券行业很多业务应用的重要支撑技术.CEP的概念本身并不新鲜,相关技术已经被运用超过15年以上,但是证券界肯定是运用CEP技术最为充分、最为前沿的行业之一,从算法交易(algorithmic trading)、风险管理(risk management)、关键时刻管理(Moment of Truth – MOT)、委托与流动性分析(order and liquidity analysis)到量化交易(quantitative trading)乃至向投资者推送投资信号(signal generation)等等,不一而足.

CEP技术通常与Time-series Database(时序数据库)结合,最理想的解决方案是CEP技术平台向应用提供一个历史序列(historical time-series)与实时序列(real-time series)无差异融合的数据流连续体(continuum)- 对于证券类应用而言,昨天、上周、上个月的数据不过是当下此刻数据的延续,而处理算法却是无边际的 – 只要开发者能构想出场景与模型.

广发证券的IT研发团队,一直关注Storm、Spark、Flink等流式计算的开源技术,也经历了传统Lambda架构的技术演进,在Kappa架构的技术尚未成熟之际,团队针对证券行业的技术现状与特点,采用改良的Lambda架构实现了一个CEP引擎,本文介绍了此引擎的架构并分享了一些股票业务较为有趣的应用场景,以飨同好.

随着移动互联和物联网的到来,大数据迎来了高速和蓬勃发展时期.一方面,移动互联和物联网产生的大量数据为孕育大数据技术提供了肥沃的土壤；一方面,各个公司为了应对大数据量的挑战,也急切的需要大数据技术解决生产实践中的问题.短时间内各种技术层出不穷,在这个过程中Hadoop脱颖而出,并营造了一个丰富的生态圈.虽然大数据一提起Hadoop,好像有点老生常谈,甚至觉得这个技术已经过时了,但是不能否认的是Hadoop的出现确实有非凡的意义.不管是它分布式处理数据的理念,还是高可用、容错的处理都值得好好借鉴和学习.

刚开始,大家可能都被各种分布式技术、思想所吸引,一头栽进去,掉进了技术的漩涡,不能自拔.一方面大数据处理技术和系统确实复杂、繁琐；另一方面大数据生态不断的推陈出新,新技术和新理念层出不穷,确实让人目不暇接.如果想要把生态圈中各个组件玩精通确实不是件容易的事情.本人一开始也是深陷其中,皓首穷经不能自拔.但腾出时间,整理心绪,回头反顾,突然有种释然之感.大数据并没有大家想象的那么神秘莫测与复杂,从技术角度看无非是解决大数据量的采集、计算、展示的问题.

因此本文参考Lambda/Kappa架构理念,提出了一种有行业针对性的实现方法.尽量让系统层面更简单,技术更同构,初衷在让大家聚焦在大数据业务应用上来,从而真正让大数据发挥它应有的价值.

Lambda架构是由Storm的作者Nathan Marz 在BackType和Twitter多年进行分布式大数据系统的经验总结提炼而成,用数学表达式可以表示如下：

batch view = function(all data)
realtime view = function(realtime view,new data)
query = function(batch view .realtime view)

逻辑架构图如下：

从图上可以看出,Lambda架构主要分为三层：批处理层,加速层和服务层.它整合了离线计算和实时计算,融合了不可变性(immutable),读写分离和复杂性隔离等一系列架构原则设计而成,是一个满足大数据系统关键特性的架构.Nathan Marz认为大数据系统应该具有以下八个特性,Lambda都具备它们分别是：

• Robustness and fault tolerance(鲁棒性和容错性)
• Low latency reads and updates(读和更新低延时)
• Scalability(可伸缩)
• Generalization(通用性)
• Extensibility(可扩展)
• Ad hoc queries(可即席查询)
• Minimal maintenance(易运维)
• Debuggability(可调试)

由于Lambda架构的数据是不可变的(immutable),因此带来的好处也是显而易见的：

• Human-fault tolerance(对人为的容错性)：数据流水被按时序记录下来,而且数据只写一次,不做更改,而不像RDBMS只是保留最后的状态.因此不会丢失数据信息.即使平台升级或者计算程序中不小心出现Bug,修复Bug后重新计算就好.强调了数据的重新计算问题,这个特性对一个生产的数据平台来说是十分重要的.
• Simplicity(简易性)：可变的数据模型一般要求数据能必须被索引,以便于数据可被再次被检索到和可以被更新.但是不变的数据模型相对来说就很简单了,只是一味的追加新数据即可.大大简化了系统的复杂度.

但是Lambda也有自身的局限性,举个例子：在大数据量的情况下,要即席查询过去24小时某个网站的pv数.根据前面的数学表达式,Lambda架构需要实现三部分程序,一部分程序是批处理程序,比如可能用Hive或者MapReduce批量计算最近23.5个小时pv数,一部分程序是Storm或Spark Streaming流式计算程序,计算0.5个小时内的pv数,然后还需要一个服务程序将这两部分结果进行合并,返回最终结果.因此Lambda架构包含固有的开发和运维的复杂性.

因为以上的缺陷,Linkedin的Jay Kreps在2014年7月2日在O’reilly《Questioning the Lambda Architecture》提出了Kappa架构,如下图：

Kappa在Lambda做的最大的改进是用同一套实时计算框架代替了Lambda的批处理层,这样做的好处是一套代码或者一套技术栈可以解决一个问题.它的做法是这样的：

1. 用Kafka做持久层,根据需求需要,用Kafka保留需要重新计算的历史数据长度,比如计算的时候可能用30天的数据,那就配置Kafka的值,让它保留最近30天的数据.
2. 当你程序因为升级或者修复了缺陷,需要重新计算的时候,就再启一个流式计算程序,从你所需的Offset开始计算,并将结果输入到一个新的表里.
3. 当这个流式计算程序追平第一个程序的时候,将应用切换到第二个程序的输出上.
4. 停止第一个程序,删除第一个程序的输出结果表.

（编辑：PHP编程网 - 黄冈站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!