分布式实时(流)计算框架..pptx

分布式实时(流)计算框架
系统部(SE)--贺先智
2014-01-15
数据分析系统整体架构
引入实时计算的背景
Hadoop的高吞吐,海量数据处理的能力使得人们可以方便地处理海量数据。但是,Hadoop的缺点也和它的优点同样鲜明-----延迟大,响应缓慢,运维复杂。hadoop主要的使用场景在于离线系统,现实生活中,一些场景是不允许那么长时间的延迟时间,都需要实时数据展示的,显而易见,hadoop是无法满足这种场景下的要求的。
Storm是实时计算(流)计算的典型代表,2011年,Twitter开源了Storm,为上述问题提供了良好的解决方案。
Storm关注的是数据多次处理一次写入,而hadoop关注的是数据一次写入,多次处理使用(查询)。Storm系统运行起来后是持续不断的,而hadoop往往只是在业务需要时调用数据。
两者关注及应用的方向不一样。
Storm架构及组件
Topology:storm中运行的一个实时应用程序.
Nimbus:负责资源分配和任务调度.
Supervisor:负责接受nimbus分配的任务,启动和停止属于自己管理的worker进程.
Worker:运行具体处理组件逻辑的进程.
Task:worker中每一个spout/bolt的线程称为一个task.
Spout:在一个topology中产生源数据流的组件.
Bolt:在一个topology中接受数据然后执行处理的组件.
Tuple:一次消息传递的基本单元.
Stream grouping:消息的分组方法
Storm和Hadoop角色对比
Storm和Hadoop角色对比
Storm集群和Hadoop集群表面上看很类似。但是Hadoop上运行的是MapReduce jobs,而在Storm上运行的是拓扑(topology),这两者之间是非常不一样的。一个关键的区别是: 一个MapReduce job最终会结束, 而一个topology永远会运行(除非你手动kill掉)。
在Storm的集群里面有两种节点: 控制节点(master node)和工作节点(worker node)。控制节点上面运行一个叫Nimbus后台程序,它的作用类似Hadoop里面的JobTracker。Nimbus负责在集群里面分发代码,分配计算任务给机器, 并且监控状态。
每一个工作节点上面运行一个叫做Supervisor的节点。Supervisor会监听分配给它那台机器的工作,根据需要启动/关闭工作进程。每一个工作进程执行一个topology的一个子集;一个运行的topology由运行在很多机器上的很多工作进程组成。
Storm实时计算系统架构
整个数据处理流程包括四部分:
第一部分是数据接入层,该部分从前端业务系统获取数据;
第二部分是最重要的storm实时处理部分,数据从接入层接入,经过实时处理后传入数据落地层;
第三部分为数据落地层,该部分指定了数据的落地方式;
第四部分元数据管理器。
RDMS
Storm实时计算业务接口
将用户的业务层需求转换为实时处理的具体模式。例如模仿Hive提供一个类Sql的业务接口,我们将一类数据在元数据管理器中描述是一个表,不同字段是表中不同字段
select ----固定数据查询(异常或者脏数据处理),
max/min/avg----最大最小值
count/sum----求和或次数统计(比如pv等)
count(distinct)----去重计数(典型的如UV)
order by----排序(取近访问的用户)
group by----聚类函数
order by----聚类后排序(如访问次数最多的topN商品)
这只是简单类比,我们可以将实时处理的业务需求转化为Sql相关语句,上层执行类Sql语句,底层将其翻译成具体Topology组成及节点参数等。
Storm实时计算具体业务需求
(1) 条件过滤
这是Storm最基本的处理方式,对符合条件的数据进行实时过滤,将符合条件的数据保存下来,这种实时查询的业务需求在实际应用中是很常见的。
(2) 中间计算
我们需要改变数据中某一个字段(例如是数值),我们需要利用一个中间值经过计算(值比较、求和、求平均等等)后改变该值,然后将数据重新输出。
(3) 求TopN
相信大家对TopN类的业务需求也是比较熟悉的,在规定时间窗口内,统计数据出现的TopN,该类处理在购物及电商业务需求中,比较常见。
(4) 推荐系统
正如我架构图中画的那样,有时候在实时处理时会从mysql及hadoop中获取数据库中的信息,例如在电影推荐系统中,传入数据为用户当前点播电影信息,从数据库中获取的是该用户之前的一些点播电影信息统计,例如点播最多的电影类型、最近点播的电影类型,及其社