《基于Storm利用空闲资源构建实时计算平台-肖康.pptx》由会员分享，可在线阅读，更多相关《基于Storm利用空闲资源构建实时计算平台-肖康.pptx（32页珍藏版）》请在三一文库上搜索。
1、基于Storm利用空闲资源 构建实时计算平台 肖康 主要内容 背景 挑战 storm问题与改进 storm应用可用性保证 为什么要构建另一个分布式计算平台 MapReduce为批处理设计，但时效性不好 不能方便的支持多阶段处理，如m-r1-r2-r3 业务有时效性需求 需要实时流式处理能力 往往需要多个逻辑串起来 背景 为什么要选择storm storm是一个实时、流式计算系统 天然支持DAG计算模型 为什么要利用空闲资源 大量云存储服务器主要使用磁盘资源 而CPU、网络资源比较空闲 背景 storm在360的发展历程 背景 1个4节点 专用集群 测试 日志 报警应用 2012.092012
2、.12 复用一个云 存储集群 云盘缩 略图 应用 2013.01 大量复用云 存储集群 日志实时 分 析等应用 走向平台化管理 随着云存储扩 容 广泛应用: 网页 、图片、安全. 2013.06 探索实时 、可靠性 要求更高的业务 （如实时计费 ） 2014.07 机器数 60多个集群，15000多台物理机 利用云存储空闲资源，每台机器贡献1-2核、1-2G内存 应用 170多个业务 实时日志统计、网页分析、图片处理 、人脸识别. 每天处理数据量约几百TB、几百亿条 背景 典型应用：网络相册缩略图 背景 典型应用：时效性网页收录 背景 典型应用：搜索热词推荐 背景 典型应用：在线验证码识别 背
3、景 背景 典型应用：实时网络入侵检测 scribe MQ 输入 spout 异常行为 检测bolt 特征匹配 bolt 统计bolt 输出 拦截 模块 光纤旁路 拦截 如何做到不影响已有业务的运行 机器复用必然带来资源竞争 如何保证storm平台的稳定性 遇到哪些storm已知问题、如何解决 怎么提前发现、防范未知问题 如何保证实时业务 的可用性 (准)实时业务对可用性要求更高 空闲资源的资源可靠性更低 挑战战 如何做到不影响已有业务的运行 利用cgroup做单机资源隔离 包括CPU、内存、网络 killall模式防止进程残留 避免本地磁盘IO storm数据本身不写磁盘 日志也不写磁盘，直接
4、走scribe传到HDFS 挑战战 数据模型 storm架构 数据源 （MQ/DRPC/Data API ） 主要模块 storm架构 storm问题 稳定性 Storm程序资源占用过多导致系统不稳定 流量大时storm程序不稳定 Storm各个组件的异常 调度不均匀 易用性 写非java程序不方便 上传大的程序jar包慢 查看storm程序日志不方便 storm问题与改进 - 1 问题：storm程序资源（如内存）占用过多导致系 统不稳定 改进 supervisor启动worker时用cgroup限制worker的CPU、 内存、网络资源 一个cgroup有多个进程时，默认情况下资源超限只k
5、ill了 最耗资源的进程 定制了一个killall模式，kill掉cgroup中的所有进程，防止 进程遗留 storm问题与改进 - 2 问题：流量大时storm程序出现OOM等问题 原因：内存队列没有大小限制 改进：在多个storm模块增加队列长度限制 DRPC/MQ：限制排队长度，超限时拒绝请求 patch: https:/ Spout 根据处理能力设置timeout和topology.max.spout.pending 对于每个请求处理时间差别较大的应用，使用DirectGrouping控 制下游bolt的pending数据 ShellBolt：限制还没有ack的缓存队列长度 patch
6、: https:/ storm问题与改进 - 3 问题：worker超时不好控制 默认超时30秒，对于有些业务太长 调成很小超时（如5秒），容易在IO高时造成超时误判 ，因为supervisor通过worker本地心跳文件检测超时 改进： supervisor直接检查worker的进程是否存在（/proc/pid） ，不存在就立即重启 本地心跳超时后再检查一次zk心跳，都超时才认为超时 storm问题与改进 - 4 问题：worker间通信的组件ZMQ使用了JNI，异常 时导致JVM直接退出，且无日志可查 改进：增加JVM的stdout stderr日志，发现解决两 类问题 问题1：向已关闭的
7、ZMQ socket发送数据导致JVM退出 日志” java: Socket.cpp：501：void* get_socket(JNIEnv*, _jobject*, int): 断言“s”失败。” 解决：worker没有正确清除已关闭的ZMQ socket，0.8.2版本已 经修复 问题2：ZMQ socket send因为sendbuf满抛出异常退出 日志” assertion failed: new_sndbuf old_sndbuf (mailbox.cpp:183)” 解决：适当调大socket sendbuf，参考 http:/comments.gmane.org/work.zer
8、omq.devel/9887 storm问题与改进 - 5 问题：supervisor的slot调度不均匀 倾向于调度满一台再调度下一台 改进：均匀调度 先调度free slot较多的supervisor https:/ storm问题与改进 - 6 问题：在storm上写非java程序不方便 原因：ShellBolt采用JSON格式做数据交换，多个程 序用管道串起来时都需要组装、解析JSON 改进：更简单的多语言编程接口StreamingBolt stdin Id t data stdout Id t emit t data Id t ack t data Stderr log storm问
9、题与改进 - 7 问题：上传大的程序jar包，通过nimbus单机分发 很慢 改进 把程序的jar包和其他文件分离 对比md5，只分发md5有变化的文件 clientnimbus supervisorsupervisor upload app.jar(100M) clientnimbus supervisorsupervisor upload app.jar(1M) download app.jar(1M) ignore dict.tar.gz(99M) download app.jar(1M) download app.jar(100M) download app.jar(100M) sto
10、rm问题与改进 - 8 问题：查看storm程序的日志不方便，需要登录到 机器上找日志文件 改进：类似hadoop的查看日志webui patch: https:/ storm应用可用性风险分析 storm平台bug storm平台升级 依赖环境（如网络、电源）异常 应用程序bug 应用程序升级 storm应应用可用性保证证 storm应用可用性保证方案 集群内通过改进升级流程 支持不停服务升级应用程序 集群间提供冗余机制 一个集群故障时快速把应用迁移到其他集群 及时发现问题 并处理 用storm分析storm的日志，实时聚合报警 storm应应用可用性保证证 storm应用可用性保证 - 集
11、群内 问题：更新storm程序导致业务中断 原因：更新storm程序需要kill topology后重新提交 一个 改进：storm程序不kill topology自动逐步更新 patch: https:/ storm应用可用性保证 - 集群内 nimbusclient supervisor1 worker1 zk supervisor2supervisor3 worker2worker3 1.upload file 2.update topo 3.set version 5.down load file & set restart time 4.check version missmatch
12、 6.restart worker 8.restart worker7.restart worker storm应用可用性保证 - 集群间 问题：整个storm集群不可用（如网络调整、掉电 ）时，业务受影响 改进：通过多集群管理平台监控storm程序在各个 集群的运行情况并自动处理 storm应用可用性保证 - 集群间 Zookeeper get new clusters 负载 调度模块 Topology 调度模块 StormClusterAStormClusterBStormClusterC 数据发送 topology xtopology xtopology x send error storm应用可用性保证 - 及时发现问题 通过一个storm topology处理storm产生的日志 实时分析 对触发条件及时报警 大量相同的报警自动聚合 报出具体的集群和业务 监控各个业务topology的流量、超时比例 谢谢谢谢 Page 23