|
这样相当于用同一套计算框架和代码解决了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可以轻松解决这个问题.数据处理流程如下：
（编辑：网站开发网_盐城站长网 ）
【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!
|
