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

分布式实时（流）计算框架系统部（SE）--贺先智2014-01-152数据分析系统整体架构3引入实时计算的背景Hadoop的高吞吐，海量数据处理的能力使得人们可以方便地处理海量数据。但是，Hadoop的缺点也和它的优点同样鲜明-----延迟大，响应缓慢，运维复杂。hadoop主要的使用场景在于离线系统，现实生活中，一些场景是不允许那么长时间的延迟时间，都需要实时数据展示的，显而易见，hadoop是无法满足这种场景下的要求的。Storm是实时计算（流）计算的典型代表，2011年，Twitter开源了Storm，为上述问题提供了良好的解决方案。Storm关注的是数据多次处理一次写入，而hadoop关注的是数据一次写入，多次处理使用（查询）。Storm系统运行起来后是持续不断的，而hadoop往往只是在业务需要时调用数据。两者关注及应用的方向不一样。4Storm架构及组件Topology：storm中运行的一个实时应用程序.Nimbus：负责资源分配和任务调度.Supervisor：负责接受nimbus分配的任务,启动和停止属于自己管理的worker进程.Worker：运行具体处理组件逻辑的进程.Task：worker中每一个spout/bolt的线程称为一个task.Spout：在一个topology中产生源数据流的组件.Bolt：在一个topology中接受数据然后执行处理的组件.Tuple：一次消息传递的基本单元.Streamgrouping：消息的分组方法5Storm和Hadoop角色对比6Storm和Hadoop角色对比Storm集群和Hadoop集群表面上看很类似。但是Hadoop上运行的是MapReducejobs，而在Storm上运行的是拓扑（topology），这两者之间是非常不一样的。一个关键的区别是：一个MapReducejob最终会结束，而一个topology永远会运行（除非你手动kill掉）。在Storm的集群里面有两种节点：控制节点（masternode）和工作节点（workernode）。控制节点上面运行一个叫Nimbus后台程序，它的作用类似Hadoop里面的JobTracker。Nimbus负责在集群里面分发代码，分配计算任务给机器，并且监控状态。每一个工作节点上面运行一个叫做Supervisor的节点。Supervisor会监听分配给它那台机器的工作，根据需要启动/关闭工作进程。每一个工作进程执行一个topology的一个子集；一个运行的topology由运行在很多机器上的很多工作进程组成。7Storm实时计算系统架构整个数据处理流程包括四部分:第一部分是数据接入层，该部分从前端业务系统获取数据；第二部分是最重要的storm实时处理部分，数据从接入层接入，经过实时处理后传入数据落地层；第三部分为数据落地层，该部分指定了数据的落地方式；第四部分元数据管理器。RDMS8Storm实时计算业务接口将用户的业务层需求转换为实时处理的具体模式。例如模仿Hive提供一个类Sql的业务接口，我们将一类数据在元数据管理器中描述是一个表，不同字段是表中不同字段select----固定数据查询（异常或者脏数据处理），max/min/avg----最大最小值count/sum----求和或次数统计（比如pv等）count(distinct)----去重计数（典型的如UV）orderby----排序（取近访问的用户）groupby----聚类函数orderby----聚类后排序（如访问次数最多的topN商品）这只是简单类比，我们可以将实时处理的业务需求转化为Sql相关语句，上层执行类Sql语句，底层将其翻译成具体Topology组成及节点参数等。9Storm实时计算具体业务需求(1)条件过滤这是Storm最基本的处理方式，对符合条件的数据进行实时过滤，将符合条件的数据保存下来，这种实时查询的业务需求在实际应用中是很常见的。(2)中间计算我们需要改变数据中某一个字段（例如是数值），我们需要利用一个中间值经过计算（值比较、求和、求平均等等）后改变该值，然后将数据重新输出。(3)求TopN相信大家对TopN类的业务需求也是比较熟悉的，在规定时间窗口内，统计数据出现的TopN，该类处理在购物及电商业务需求中，比较常见。(4)推荐系统正如我架构图中画的那样，有时候在实时处理时会从mysql及hadoop中获取数据库中的信息，例如在电影推荐系统中，传入数据为用户当前点播电影信息，从数据库中获取的是该用户之前的一些点播电影信息统计，例如点播最多的电影类型、最近点播的电影类型，及其社交关系中点播信息，结合本次点击及从数据库中获取的信息，生成一条推荐数据，推荐给该用户。并且该次点击记录将会更新其数据库中的参考信息，这样就是实现了简单的智能推荐。10Storm实时计算具体业务需求(5)分布式RPCStorm有对RPC进行专门的设计，分布式RPC用于对Storm上大量的函数调用进行并行计算，最后将结果返回给客户端。（这部分我也不是很懂）(6)批处理所谓批处理就是数据攒积到一定触发条件，就批量输出，所谓的触发条件类似时间窗口到了，统计数量够了及检测到某种数据传入等等。(7)热度统计热度统计实现依赖于TimeCacheMap数据结构，该结构能够在内存中保存近期活跃的对象。我们可以使用它来实现例如论坛中的热帖排行计算等。Storm只是实时计算的解决方案之一，后面我们介绍一款与实时计算相关的产品，并且NotOnly实时计算，那就是MediationZone。11MediationZone系统架构配置层包括每个服务供应商的具体要求相关的所有配置。应用层提供的所有功能，可用于工作流配置。这包括关闭的，现成的代理商，以及自定义应用程序和使用的开发工具包开发的插件。控制区包含所有的核心服务，为工作流提供运行时环境。开发工具包，包括一套标准化的API，可用于扩展平台。MZ100%在Java下环境下开发和Java运行时环境的要求。MZ可以部署在两个数据库架构，Oracle标准版或嵌入式替代。MZ可以部署在广泛的硬件平台和操作系统，从高端服务器架构到一般商品硬件。12MediationZone--集中控制，分布执行MZ采用集中控制逻辑和分布式执行，这样可以解决垂直（硬件插槽有限）和水平架构（数据一致性）的两个主要问题领域所带来的问题。13MediationZone--实时在线，主/备部署当用户协议支持失效备援时，可以一起部署平均恢复时间和客户设备失效备援时间一致对用户体验的影响取决于传输层的处理能力14MediationZone--集中控制，分布执行通过负载均衡网络硬件，或者大数据采集清分平台的代理工作流方式实现负载均衡15MediationZone—批处理工作流MZ工作流有三种不同的类型：批处理工作流程，实时工作流程，任务工作流程。批处理工作流程是用来收集处理和分发基于文件的数据，也被称为离线模式。这些工作流程可配置为多线程执行先进先出的处理顺序和严格的交易边界基于每个批处理16MediationZone—实时工作流实时工作流使请求/回答与其他系统的在线处理。这些工作流程，能独立执行路径，同时利用多线程执行模型大量的执行。17MediationZone—任务工作流任务工作流用来执行一般的活动，如清理（ETL）或维护任务。一些系统的任务是预先在MZ中，可补充任何用户定义的活动。shell脚本和SQL脚本可以通过工作流执行计划和任务。18MediationZone—工作流开发管理工作流开发简单快捷，采用手工拖拽设计流程，二次开发基于JAVA、SQL、Shell等环境。支持全流程的工作流管理、监控及维护。同时支持工作流分组管理，根据时间模型设计出多个协同高效工种的工种流组。19MZ案例介01—KPI计算从海量基站文件中，找出覆盖高铁的所有基站只对“高铁小区”的记录进行处理，按照省、市、小区id的方式进行汇总汇总完毕后计算KPI现有解决办法，各省分别处理，然后将结果传到总部再进行处理使用MZ之后，直接放到总部进行处理，效率提高非常大20MZ案例介02—GN平台采集从2个GN平台采集Gn原始数据，将原始数据的文档合并，上限为50个文档。每个文档的大小约为200MB，合并后的文档上限为10GB。合并后的文档上传至HDFS平台。上传的HDFS目录分别是/tmp/gn/1和/tmp/gn/2，再根据上传的时间点建立新的目录.用户利用MZ采集到HDFS上的数据库进行准实时数据分析21MZ案例介03—统计边界漫游小区用户需求：从大量的话单记录中，统计出在边界漫游小区使用的IMSI，为决策分析提供依据。数据量：每月处理一次，每次21亿条记录（7000万/天*30天）处理速度要求：每月10之前完成处理，对机器负载要求不能太高，处理时间可以长一点。硬件配置：SunE4900，CPU：8核，内存：32G1.每月1日，操作员手工将字典表数据以csv格式导出，存放在IF1指定的目录中；2.每月1日，操作员手工将原始数据从informix数据库中以csv格式导出，存放在IF1接口指定的目录中；3.每月2日，工作流1自动启动，将字典表数据插入到一个临时的Oracle数据库中。然后再将Oracle数据库读入到内存，生成一个内存数据库。同时将字典表原始数据保存在磁盘上（IF4接口）；4.工作流1完成之后，工作流流2自动启动，读取原始输入数据，从内存数据库中查询，最后生成结果；5.最后结果从存放在IF3指定的目录中，同时原始数据将通过IF4压缩保存在磁盘上；6.字典表数据和原始输入数据压缩并按照时间7.操作员手工将其导入正式的informix数据库（注：定期删除IF4接口指定文件夹下的备份文件）22MZ案例介04—GPRS数据采集、汇总分析用户需求23MZ案例介04—GPRS数据处理MZ环境24MZ案例介04—GPRS数据处理GPRS文件解析划分流程每秒处理的数据量156,000157,000158,000159,000160,000161,000162,000163,000164,000165,000166,000167,0003个并发流程6个并发流程9个并发流程25MZ案例介04—GPRS数据处理GPRS和IMEI数据关联汇总处理流程每秒处理的数据量-1,0002,0003,0004,0005,0006,0007,0008,0003个并发流程6个并发流程9个并发流程26MZ案例介04—GPRS数据处理MediationZone處理解析增加並發流程可提高數據處理性能GPRS文檔解析可達至每秒處理大約16萬條數據的性能GPRS和IMEI數據關聯，匯總處理可達至每秒處理大約7千條數據的性能無需高性能硬件(eg.IBMx3755M3)，普通硬件也可達到高性能GPRS文檔解析GPRS和IMEI數據關聯，匯總處理VMware-1路4核-16GB每小時處理5.7億數據每小時處理2520萬數據IBMx3755M3-2.1GHz4路12核-128GB每小時處理19億數據每小時處理3600萬數據27MZ案例介04—GPRS数据处理28MZ案例介04—GPRS数据处理29MZ案例介04—GPRS数据处理30MZ案例介04—GPRS数据处理负荷解析•使用4核CPU，每个CPU的负荷量大致平均•3个Java处理进程+1个Java核心进程共耗内存13GB（虚拟机Vmware内存为16GB）•GPRS文档解析处理的主要负荷在CPU•GPRS和IMEI数据关联，汇总处理主要负荷在内存31MZ其他案例介MiddleEastAfricaEuropeAsiaPacificAmericas32MZ与Storm的比较MZ为商业产品（需要购买）而后者为开源产品（完全免费）我们不能对MZ自身产品进行bug修复及新功能的开发，只能由原厂商进行；而Storm可以根据自身需要进行进行bug修复及新功能的开发。MZ集成电信设备厂商协议（支持Interfac