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