分布式实时(流)计算框架课件.ppt

努力奋斗 努力奋斗 努力奋斗 努力奋斗 努力奋斗 努力奋斗 努力奋斗 努力奋斗 分布式实时（流）计算框架 系统部（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中获取数据库中的信息，例如在电影推荐系统中，传入数据为用户当前点播电影信息，从数据库中获取的是该用户之前的一些点播电影信息统计