本文主要从一下几个方面来介绍流计算处理流程:
- 概述
- 数据实时采集
- 数据实时计算
- 实时查询服务
概述
传统的数据处理流程,需要先采集数据并存储在关系数据库等数据管理系统中,之后由用户通过查询操作和数据管理系统进行交互,如下图所示:
传统的数据处理流程隐含了两个前提:
- 存储的数据是旧的。存储的静态数据是过去某一时刻的快照,这些数据在查询时可能已不具备时效性了;
- 需要用户主动发出查询来获取结果。
流计算的处理流程一般包含三个阶段:
- 数据实时采集
- 数据实时计算
- 实时查询服务
数据实时采集
- 数据实时采集阶段通常采集多个数据源的海量数据,需要保证实时性、低延迟与稳定可靠
- 以日志数据为例,由于分布式集群的广泛应用,数据分散存储在不同的机器上,因此需要实时汇总来自不同机器上的日志数据
目前有许多互联网公司发布的开源分布式日志采集系统均可满足每秒数百MB的数据采集和传输需求,如:
- Facebook的Scribe
- LinkedIn的Kafka
- 淘宝的Time Tunnel
- 基于Hadoop的Chukwa和Flume
实时数据计算
- 数据实时计算阶段对采集的数据进行实时的分析和计算,并反馈实时结果;
- 经流处理系统处理后的数据,可视情况进行存储,以便之后再进行分析计算。在时效性要求较高的场景中,处理之后的数据也可以直接丢弃。
实时数据查询
- 实时查询服务:经由流计算框架得出的结果可供用户进行实时查询、展示或储存;
- 传统的数据处理流程,用户需要主动发出查询才能获得想要的结果。而在流处理流程中,实时查询服务可以不断更新结果,并将用户所需的结果实时推送给用户;
- 虽然通过对传统的数据处理系统进行定时查询,也可以实现不断地更新结果和结果推送,但通过这样的方式获取的结果,仍然是根据过去某一时刻的数据得到的结果,与实时结果有着本质的区别。
应用场景
伴随着信息科技日新月异的发展,信息呈现出爆发式的膨胀,人们获取信息的途径也更加多样、更加便捷,同时对于信息的时效性要求也越来越高。
举个搜索场景中的例子,当一个卖家发布了一条宝贝信息时,他希望的当然是这个宝贝马上就可以被卖家搜索出来、点击、购买啦,相反,如果这个宝贝要等到第二天或者更久才可以被搜出来,估计这个大哥就要骂娘了,所以卖家发的宝贝需要实时同步到搜索引擎。
再举一个推荐的例子,如果用户昨天在淘宝上买了一双袜子,今天想买一副泳镜去游泳,但是却发现系统在不遗余力地给他推荐袜子、鞋子,根本对他今天寻找泳镜的行为视而不见,估计这哥们心里就会想推荐你妹呀。
其实稍微了解点背景知识的码农们都知道,这是因为后台系统做的是每天一次的全量处理,而且大多是在夜深人静之时做的,那么你今天白天做的事情当然要明天才能反映出来啦。
案例
一淘-实时分析系统
一淘-实时分析系统:实时分析用户的属性,并反馈给搜索引擎。最初,用户属性分析是通过每天在云梯上定时运行的MR job来完成的。为了满足实时性的要求,希望能够实时分析用户的行为日志,将最新的用户属性反馈给搜索引擎,能够为用户展现最贴近其当前需求的结果。
携程-网站性能监控
携程-网站性能监控:实时分析系统监控携程网的网站性能。利用HTML5获得可用的指标,并记录日志。Storm集群实时分析日志和入库。使用DRPC聚合成报表,通过历史数据对比等判断规则,触发预警事件。
游戏实时运营
一个游戏新版本上线,有一个实时分析系统,收集游戏中的数据,运营或者开发者可以在上线后几秒钟得到持续不断更新的游戏监控报告和分析结果,然后马上针对游戏的参数 和平衡性进行调整。这样就能够大大缩短游戏迭代周期,加强游戏的生命力。
实时计算在腾讯的运用
实时计算在腾讯的运用:精准推荐(广点通广告推荐、新闻推荐、视频推荐、游戏道具推荐);实时分析(微信运营数据门户、效果统计、订单画像分析);实时监控(实时监控平台、游戏内接口调用)。
实时计算在阿里的运用
为了更加精准投放广告,阿里妈妈后台计算引擎需要维护每个用户的兴趣点(理想状态是,你对什么感兴趣,就向你投放哪类广告)。用户兴趣主要基于用户的历史行为、用户的实时查询、用户的实时点击、用户的地理信息而得,其中实时查询、实时点击等用户行为都是实时数据。考虑到系统的实时性,阿里妈妈使用Storm维护用户兴趣数据,并在此基础上进行受众定向的广告投放。
总结
可见,流处理系统与传统的数据处理系统有如下不同:
- 流处理系统处理的是实时的数据,而传统的数据处理系统处理的是预先存储好的静态数据;
- 用户通过流处理系统获取的是实时结果,而通过传统的数据处理系统,获取的是过去某一时刻的结果;
- 流处理系统无需用户主动发出查询,实时查询服务可以主动将实时结果推送给用户。