Storm应用实践：实时事务处理之策略
2020-03-19 14:59:59 0 举报AI智能生成
Storm应用实践：实时事务处理之策略
作者其他创作
大纲/内容
Storm应用实践：实时事务处理之策略
6 对Storm进行调优
6.1 问题定义：Daily Deals！重生版
6.1.1 创建概念性解决方案
6.1.2 将方案转换为Storm设计
6.2 初始化实施
6.2.1 spout：读取自一个数据源
6.2.2 bolt：查找推荐商品
6.2.3 bolt：为每个商品查询详细信息
6.2.4 bolt：保存推荐的商品详情
6.3 调优：我想为它提速
6.3.1 Storm UI：调优的定位工具
6.3.2 为性能值建立一个基线集
6.3.3 判断瓶颈
6.3.4 spout：控制数据流入拓扑的速率
6.4 延迟率：当外部系统依然能正常工作时
6.4.1 在拓扑中模拟延迟
6.4.2 延迟的外因和内因
6.5 Storm的指标统计API
6.5.1 使用Storm的内建CountMetric
6.5.2 设置一个指标接收器
6.5.3 创建一个自定义的SuccessRateMetric
6.5.4 创建一个自定义的MultiSuccessRateMetric
6.6 小结
7 资源冲突
7.1 调整一个工作结点上运行的工作进程数量
7.1.1 问题
7.1.2 解决方案
7.1.3 讨论
7.2 修改工作进程（JVM）上的内存分配
7.2.1 问题
7.2.2 解决方案
7.2.3 讨论
7.3 定位拓扑上运行的工作结点/进程
7.3.1 问题
7.3.2 解决方案
7.3.3 讨论
7.4 在一个Storm集群中的工作进程冲突
7.4.1 问题
7.4.2 解决方案
7.4.3 讨论
7.5 在一个工作进程（JVM）中的内存冲突
7.5.1 问题
7.5.2 解决方案
7.5.3 讨论
7.6 在一个工作结点上的内存冲突
7.6.1 问题
7.6.2 解决方案
7.6.3 讨论
7.7 工作结点的CPU资源冲突
7.7.1 问题
7.7.2 解决方案
7.7.3 讨论
7.8 工作结点的I/O冲突
7.8.1 网络/Socket层面的I/O冲突
7.8.2 磁盘I/O冲突
7.9 小结
8 Storm内核
8.1 重新考虑提交数的拓扑设计
8.1.1 回顾拓扑的设计
8.1.2 假设该拓扑运行在远程Storm集群上
8.1.3 数据是如何在集群的spout和bolt之间传输的
8.2 探究执行器的细节
8.2.1 监听提交数数据源spout的执行器细节
8.2.2 在同一个JVM中两个执行器之间传输元组
8.2.3 提取email bolt的执行器细节
8.2.4 在不同JVM上的两个执行器之间传输元组
8.2.5 email计数bolt的执行器细节
8.3 路由和任务
8.4 当Storm的内部队列出现溢出时
8.4.1 内部队列的类型和可能出现溢出的情况
8.4.2 使用Storm的debug日志来诊断缓冲区溢出
8.5 处理Storm内部缓冲区溢出问题
8.5.1 调整生产与消耗的比例
8.5.2 提升所有拓扑的缓冲区大小
8.5.3 提升指定拓扑的缓冲区大小
8.5.4 spout的最大待定数
8.6 调整缓冲区大小来提升性能
8.7 小结
9 Trident
9.1 什么是Trident
9.1.1 Trident中不同的操作方法
9.1.2 将Trident数据流看作批数据
9.2 Kafka及其在Trident中的角色
9.2.1 解构Kafka的设计
9.2.2 Kafka与Trident的匹配度
9.3 问题定义：网络电台应用
9.3.1 定义数据点
9.3.2 将问题进行步骤划分
9.4 基于一个Trident拓扑来实现网络电台的设计
9.4.1 实现一个Trident的Kafka spout
9.4.2 对播放日志做反序列化操作，并分别创建每个字段的独立数据流
9.4.3 将艺术家、歌曲名和标签进行统计计数和持久化操作
9.5 借助DRPC访问持久化的统计结果
9.5.1 创建一个DRPC流
9.5.2 向流中应用一个DRPC状态查询
9.5.3 借助DRPC客户端发起一个DRPC调用
9.6 将Trident的操作符映射至Storm的原语
9.7 扩展一个Trident拓扑
9.7.1 实现并行性的分区
9.7.2 Trident数据流中的分区
9.8 小结
编后记
关于原书封面插图
1 Storm简介
1.1 什么是大数据
1.1.1 大数据的四大特性
1.1.2 大数据工具
1.2 Storm如何应用于大数据应用场景
1.3 为什么你希望使用Storm
1.4 小结
2 Storm核心概念
2.1 问题定义：GitHub提交数监控看板
2.1.1 数据：起点和终点
2.1.2 分解问题
2.2 Storm基础概念
2.2.1 拓扑
2.2.2 元组
2.2.3 流
2.2.4 spout
2.2.5 bolt
2.2.6 流分组
2.3 在Storm中实现GitHub提交数监控看板
2.3.1 建立一个Storm工程
2.3.2 实现spout
2.3.3 实现bolt
2.3.4 集成各个部分组成拓扑
2.4 小结
3 拓扑设计
3.1 拓扑设计方法
3.2 问题定义：一个社交热力图
3.3 将解决方案映射至Storm的逻辑
3.3.1 考虑数据流本身施加的要求
3.3.2 将数据点表示为元组
3.3.3 确定拓扑组成的步骤
3.4 设计的初步实现
3.4.1 spout：从数据源读取数据
3.4.2 bolt：连接至外部服务
3.4.3 bolt：将数据寄放在内存里
3.4.4 bolt：持久化存储到数据库
3.4.5 定义组件间的流分组策略
3.4.6 在本地集群模式中构建一个拓扑
3.5 扩展拓扑
3.5.1 理解Storm中的并行机制
3.5.2 调整拓扑配置来解决设计中遗留的瓶颈
3.5.3 调整拓扑以解决数据流中固有的瓶颈
3.6 拓扑的设计范式
3.6.1 分解为功能组件的设计方法
3.6.2 基于重分配来分解组件的设计方法
3.6.3 最简单的功能组件与最少的重分配次数
3.7 小结
4 设计健壮的拓扑
4.1 对可靠性的要求
4.2 问题定义：一个信用卡授权系统
4.2.1 有重试特性的概念性解决方案
4.2.2 定义数据点
4.2.3 在Storm上实现带有重试特性的方案
4.3 bolt基础实现
4.3.1 AuthorizeCreditCard的实现
4.3.2 ProcessedOrderNotification的实现
4.4 消息处理保障
4.4.1 元组状态：处理完成或失败
4.4.2 bolt中的锚定、应答和容错
4.4.3 spout在消息处理保障中的角色
4.5 回放语义
4.5.1 Storm中可靠性的级别
4.5.2 在Storm拓扑中检查仅一次处理
4.5.3 检查拓扑中的可靠性保障
4.6 小结
5 拓扑由本地到远程的实施
5.1 Storm集群
5.1.1 解析工作结点
5.1.2 基于信用卡授权拓扑的上下文来理解工作结点
5.2 Storm集群容错中的快速失败机制
5.3 安装Storm集群
5.3.1 配置Zookeeper集群
5.3.2 在Storm的主结点和工作结点上安装依赖组件
5.3.3 安装Storm到主结点和工作结点
5.3.4 通过storm.yaml配置主结点和工作结点
5.3.5 在监督机制下启动Nimbus和Supervisor
5.4 在Storm集群上运行拓扑
5.4.1 重新考虑如何将拓扑组件组合在一起
5.4.2 在本地模式下运行拓扑
5.4.3 在一个远程Storm集群上运行拓扑
5.4.4 在一个远程Storm集群上部署拓扑
5.5 Storm UI及其在集群中的角色
5.5.1 Storm UI：Storm集群概要
5.5.2 Storm UI：独立拓扑概要
5.5.3 Storm UI：独立spout/bolt概要
5.6 小结
0 条评论
回复 删除
下一页
