1 / 41

基于 zookeeper 和 storm 的车载流式计算 框架

基于 zookeeper 和 storm 的车载流式计算 框架. 邵贤军 开发 工程师 南京富士通南大软件技术有限公司. 案例背景 日本第一车载 SAAS 平台 案例需求 数据 量剧增,吞吐量剧增 车载机数量 剧增 + 数据库连接 数 剧增 任务分布不均导致实时性无法满足 案例技术方案 案例技术方案概览 数据存储平台 —— MongoDB 实时计算平台 ——Storm 集群协调 —— ZooKeeper 最佳实践 MongoDB 介绍及最佳实践 Storm 介绍及最佳实践 ZooKeeper 介绍及最佳实践 架构不足及经验分享. 摘要.

hertz
Download Presentation

基于 zookeeper 和 storm 的车载流式计算 框架

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. 基于zookeeper和storm的车载流式计算框架 邵贤军 开发工程师 南京富士通南大软件技术有限公司

  2. 案例背景 • 日本第一车载SAAS平台 • 案例需求 • 数据量剧增,吞吐量剧增 • 车载机数量剧增+数据库连接数剧增 • 任务分布不均导致实时性无法满足 • 案例技术方案 • 案例技术方案概览 • 数据存储平台——MongoDB • 实时计算平台——Storm • 集群协调——ZooKeeper • 最佳实践 • MongoDB介绍及最佳实践 • Storm介绍及最佳实践 • ZooKeeper介绍及最佳实践 • 架构不足及经验分享 摘要

  3. 案例背景1——业务背景 • 业务场景 • 物流公司 • 校车安全 • 油气公司 • 主要功能 • 运行数据记录 • 监视驾驶 • 违规警告 • 绩效考评 • 报表输出 • 危险地带 • 实时监控 日本市场占有率第一,积极拓展国内业务

  4. WebAPP 硬件层 中间件层 案例背景2——技术背景 Web Server 通信层 分析计算层1 分析计算层2 メンテ Write Polling Read Read Write Write Write RMDB RMDB RMDB 基本データ Bs_WorkSheet Bs_TimeChart Bs_FreqData Bs_DigiData 基本データ Bs_WorkSheet Bs_TimeChart Bs_FreqData Bs_DigiData 基本データ Bs_WorkSheet Bs_TimeChart Bs_FreqData Bs_DigiData PrimitiveLog PrimitiveLog PrimitiveLog 集計データ 集計データ 集計データ 動態管理 動態管理 動態管理 Master Master Master 設定データ 設定データ 設定データ 市场竞争激烈,维持第一的保证——PAAS

  5. 一 数据量剧增+吞吐量剧增 2013年 车辆数:10000台 数据量:3000w/天 吞吐量:80M/S (※) 2015年 车辆数:100000台 数据量:30000w/天 吞吐量:800M/S 数据特性  ・Heavy Write  ・ Heavy Read  ・ Past Useless (※) 此表抽出 ※:车载机发送数据最高频率2次/秒,每次发送4KB数据。10000台车载机的峰值为10000*2*4KB =80000KB=80M/S ※:从这个数据可以算出实际平均吞吐量是62340*4KB/60 = 4M/s, 但是固定时间点车载机会同时向云端发送运行数据

  6. 二 连接数剧增+客户剧增 ■通信服务器与各个业务DB建立长连接 ■ 目前的SAAS平台已经有600租户 ■ 每个通信服务器要与600个DB建立数据库连接 通信中间件 分析集计中间件 DB 10W车辆时: 1.需要17台通信服务器 2.峰值:10W*8KB/S=800MB/S数据量 车载机数据 写原始日志表 设置信息 长尾来袭 现在有600个客户公司,未来?? DB1 bs_primitiveLog DB2 bs_WorkSheet bs_TimeChart bs_FreqData bs_DegitachoData DB3 归一化迫在眉睫 NoSQL … DBn

  7. 三 分析计算程序任务不均匀+实时性不够 Analysis Process Analysis Process Analysis Process Analysis Process • 现状 • 同一公司的车辆数据分布在同一数据库 • 分析计算进程与DB一对一地分析数据 DB1 • 问题 • 若一个公司有很多辆车,那么一个分析计算进程应付不过来,无法分散计算 • 若一个公司车辆很少,那么该公司对应的分析进程将没有任务,浪费服务器资源 • 因为分析进程的缓慢执行,车辆的实时运行数据无法反映到客户端 DB2 DB3 … DBn

  8. 案例技术方案概览

  9. 案例技术方案概览

  10. 数据存储平台——MongoDB MongoDB是一个介于关系数据库和非关系数据库之间的产品,是非关系数据库当中功能最丰富,最像关系数据库的。他支持的数据结构非常松散,是类似json的bjson格式,因此可以存储比较复杂的数据类型。Mongo最大的特点是他支持的查询语言非常强大,其语法有点类似于面向对象的查询语言,几乎可以实现类似关系数据库单表查询的绝大部分功能,而且还支持对数据建立索引。 它的特点是高性能、易部署、易使用,存储数据非常方便。主要功能特性有: • 面向集合存储,易存储对象类型的数据 • 模式自由 • 支持动态查询 • 支持完全索引,包含内部对象 • 支持查询 • 支持复制和故障恢复 • 使用高效的二进制数据存储,包括大型对象(如视频等) • 自动处理分片,以支持云计算层次的扩展性 • 支持RUBY,PYTHON,JAVA,C++,PHP等多种语言。 • 文件存储格式为BSON(一种JSON的扩展) • 可通过网络访问

  11. 数据量剧增和连接数剧增的解决办法 • 高频读写表抽出 • 1公司:1DB模式→N公司:1DB DB1 DB1 DB2 DB1 DB2 DB3 DB3 … DBn DBn

  12. 选择MongoDB的原因 • 增删改查操作最接近SQL,迁移容易,并可为其他业务使用 • 支持数据的自动和手动分片,横向扩展容易 • 性能测试结果接近预期,够用即可,不用追求完美 • 支持数据复制、故障转移、横向扩展,基本符合RAS需求 CAP定理 性能 2个mongos,3个分片,非安全插入: 单独执行时: →写线程10个并发时,每秒37000次写入 →读线程4个并发时,每秒43000次读取 同时执行时: →写线程10个并发时,每秒达25000次写入 →读线程4个并发时,每秒达36000次读取 关系不大 ※:CPU 3.2GHz MEM 16G 千兆网卡

  13. 逻辑部署和物理部署 • 存储结构设计 • 定期数据清除 MongoDB最佳实践

  14. MongoDB的部署逻辑架构 Replica sets mongod mongod mongod mongod mongod mongod mongod mongod Shards mongod mongod mongod mongod Config server C1 mongod mongos mongos mongos C 2mongod C3 mongod Load Balance client client

  15. MongoDB部署物理架构 Shard1:192.168.0.2,192.168.0.5,192.168.0.4,192.168.0.3,192.168.0.6(arbiter) Shard2:192.168.0.3,192.168.0.5,192.168.0.2,192.168.0.4,192.168.0.6(arbiter) Shard3:192.168.0.4,192.168.0.5,192.168.0.3,192.168.0.2,192.168.0.6(arbiter) Config Server1:192.168.0.2 Config Server2:192.168.0.3 Mongos:192.168.0.4,192.168.0.5,192.168.0.6

  16. 存储数据结构设计 { “v”: “DTS19982221” “r”: [ { “t” : "2013-11-14T08:17:00.016Z" “d” : ”xxxxxxxxxxxxxxxxxx” “o” : “yyyyyyyyyyyyyyyyyy” }, { “t” : "2013-11-14T08:19:38.342Z“ “d” : ”xxxxxxxxxxxxxxxxxx” “o” : “yyyyyyyyyyyyyyyyyy” } ] “s”: “zzzzz” … } 名字段要短 db.vehicle.save({“v”:” DTS19982221 ”, “r": {“t": 201399988772, “d”:”xxxxxxxxxxxxxxxx”,”o”:”yyyyyyyyyyy”}}} db.vehicle.find({“v”:” DTS19982221 ”, “r": {"$elemMatch": {“t":{"$gte": 201309898876251728}}}}

  17. 定期数据清除 • 清理程序(MonDC)运行在ZooKeeper集群上,自身无状态 • 清理程序(MonDC)监视MongoDB内存使用量 • 清理程序(MonDC)检测删除过期数据

  18. 实时计算平台——Storm • 与Hadoop类似,Storm为分布式实时计算提供了一组通用原语。可被用于“流处理”之中,实时处理消息并更新数据库。这是管理队列及工作者集群的另一种方式。Storm也可被用于“连续计算”, 对数据流做连续查询,在计算时就将结果以流的形式输出给用户。它还可被用于“分布式RPC”,以并行的方式运行昂贵的运算。 • Storm的主工程师Nathan Marz表示:Storm可以方便地在一个计算机集群中编写与扩展复杂的实时计算,Storm之于实时处理,就好比Hadoop之于批处理。Storm保证每个消息都会得到处理,而且它很快——在一个小集群中,每秒可以处理数以百万计的消息。更棒的是你可以使用任意编程语言来做开发。 • Storm的主要特点如下: • 简单的编程模型 • 可以使用各种编程语言 • 容错性 • 水平扩展 • 可靠的消息处理 • 快速

  19. Storm为什么号称实时计算系统? • 计算基于内存,较之磁盘有数量级之差 • 使用消息队列做数据传输,速度比数据库快很多 • 使用流式计算思想,数据可以源源不断的被处理 • 任何一个节点都可以将中间计算结果反馈给用户 为什么选择Storm? • 无需维护消息队列(Topic、LB、Broker),专注Producer&Consumer • 满足业务需求,适合业务场景 • 社区活跃,版本更新快 • 性能卓越,易扩展

  20. Storm里的核心概念 • Tuple&Stream Tuple … Tuple … Stream • Topology&Spout&Bolt Spout Bolt Bolt Bolt Bolt Bolt

  21. Storm里的核心概念 • Nimbus&Supervisor&Worker&Task Cluster Supervisor 运行业务拓扑 ZooKeeper Supervisor Nimbus ZooKeeper Supervisor ZooKeeper 提交代码,分配任务,监视Supervisor Supervisor Supervisor 进程 线程 Worker Task:Bolt Task:Spout Task:Bolt

  22. Storm里的核心概念 • Stream Grouping I Spout BoltA I:1 Bolt I know who am I I:1 know Know:1 I who BoltB Bolt am:1 am who:1 BoltC NOT PASS 问题:如何保证tuple按照予定的路径发送到指定Bolt呢?

  23. Storm里的核心概念 • Stream Grouping

  24. Storm里的核心概念 • Stream Grouping BoltA BoltA BoltA BoltA BoltB BoltB BoltB BoltB Shuffle All Fields Global

  25. 计算拓扑设计 • 数据顺序性保证 • 基于统计的Worker和Task数值设置 Storm最佳实践

  26. 数据输入 FetchSpout • MongoDB中读取车辆运行数据 • 分析处理 AnalysisBolt • 解码运行数据,如经纬度、违反等 • 数据准备DataPreBolt • 为集计所需要的数据作准备,会与数据库交互 • 集计处理 StasticBolt • 统计一段时间或一天的运行数据 • 数据库写 DBWBolt • 所有涉及写数据库的操作由此BOLT完成 计算拓扑设计

  27. 计算拓扑设计 StasticBolt DataPreBolt AnalysisBolt FetchSpout DBWBolt AnalysisBolt FetchSpout FetchSpout DBWBolt AnalysisBolt DataPreBolt StasticBolt MongoDB DBMLayer Company 1 Company 2 Company 3 Company 4

  28. 计算拓扑设计 顺序性如何保证 Fileds Grouping Fileds Grouping Fileds Grouping DataCollBolt AnalysisBolt StasticBolt [DTS0001, YYYYY] [DTS0001, ZZZZZZZ] [DTS0001, XXXXXX] Spout [DTS0002, XXXXXX] AnalysisBolt StasticBolt [DTS0002, YYYYY] [DTS0002, ZZZZZZZ] DataCollBolt Fields Grouping 按字段分组, 比如按VehicleId的模n结果来分组, 具有同样VehicleId的tuple会被分到相同的Bolts, 而不同的userid则会被分配到不同的Bolts。

  29. Storm Cluster Number: 8 最佳参数设置 通过反复的测试,得到一个接近能够处理完数据的比例设置,这里是2:10. 按照一个最佳数值设置建议:Worker个数是机器的整数倍,Task是Worker的整数倍。我们有7台机器作为Supervisor,所以Worker数设置为7,Task数值为14,于是得到FetchSpout个数为2,AnalysisBolt个数为12. 以上设置后,计算延时降低到1.3s左右 最大效率化——基于统计的计算量均匀化

  30. ZooKeeper是什么 • Zookeeper是Google的Chubby一个开源实现,是高有效和可靠的协同工作系统。 • Zookeeper能够用来leader选举,配置信息维护等,在一个分布式的环境中,需要一个Master实例或存储一些配置信息,确保文件写入的一致性等。 • ZooKeeper是一个分布式的,开放源码的分布式应用程序协调服务,包含一个简单的原语集,是Hadoop和Hbase的重要组件。 • 目前提供Java和C的接口。 • 谁在用ZooKeeper Zookeeper简介

  31. Zookeeper核心概念——数据结构 /root • ├/dataNode1 • ├/dataNode2 • ├/dataNode3 • ├/dataNode4 • └/dataNode5 • ├/subDataNode1 • ├/subDataNode2 • └/subDataNode1 /root • ├/dataNode1 • ├/dataNode2 • ├/dataNode3 • ├/dataNode4 • └/dataNode5 • ├/subDataNode1 • ├/subDataNode2 • └/subDataNode1 /root • ├/dataNode1 • ├/dataNode2 • ├/dataNode3 • ├/dataNode4 • └/dataNode5 • ├/subDataNode1 • ├/subDataNode2 • └/subDataNode1 /root • ├/dataNode1 • ├/dataNode2 • ├/dataNode3 • ├/dataNode4 • └/dataNode5 • ├/subDataNode1 • ├/subDataNode2 • └/subDataNode1 /root • ├/dataNode1 • ├/dataNode2 • ├/dataNode3 • ├/dataNode4 • └/dataNode5 • ├/subDataNode1 • ├/subDataNode2 • └/subDataNode1 /root • ├/dataNode1 • ├/dataNode2 • ├/dataNode3 • ├/dataNode4 • └/dataNode5 • ├/subDataNode1 • ├/subDataNode2 • └/subDataNode1 • ZooKeeper软件维护的是一个树形的数据结构 • ZooKeeper集群维护的是一个树形的数据结构 /root • ├/dataNode1 • ├/dataNode2 • ├/dataNode3 • ├/dataNode4 • └/dataNode5 • └/subDataNode1 写操作 • ZooKeeper各节点之间的数据结构是同步的 • 从任一个ZooKeeper节点看,树视图都一样

  32. Zookeeper核心概念——节点类型 /root • ├/dataNode1 • ├/dataNode2 • ├/dataNode3 • ├/dataNode4 • └/dataNode5 • ├/subDataNode1 • ├/subDataNode2 • └/subDataNode1

  33. Zookeeper的应用场景 • 统一命名服务(Name Service) • 配置管理(Configuration Management) • 集群管理(Group Membership) • 共享锁(Locks) • 队列管理 (Queue Management)

  34. 协调数据清理(MonDC) • 协调任务分配(TaskDistribute) • 协调Spout对MongoDB的数据访问 • 集群节点监控 ZooKeeper的使用

  35. 开始 轮询 警戒 清理 是 mongostat MongoDB /shardProcTime • ├/shard1:2013000912 • ├/shard2:2013000523 • ├/shard3:2013000943 • ├/shard4:2013000125 • └/shard5:2013000229 数据清理程序(MonDC)

  36. 订阅 获取新Task 迁移任务 ├ spoutTasks | ├ TASK365B33D23BC | ├ TASK945C3DB33CD | └ TASK76C46D1267B ├ shards | ├ shard001 | ├ shard002 | └ shard003 └spout_shard ├ shard001 : TASK365B33D23BC ├ shard002 : TASK945C3DB33CD └ shard003 : TASK76C46D1267B ├ spoutTasks | ├ TASK365B33D23BC | ├ TASK875E3FB5361 | └ TASK76C46D1267B ├ shards | ├ shard001 | ├ shard002 | └ shard003 └spout_shard ├ shard001 : TASK365B33D23BC ├ shard002 : TASK875E3FB5361 └ shard003 : TASK76C46D1267B 任务分配程序(TaskDistribute)

  37. 首次运行 获取任务表 获取时间戳 取数据 发送数据 设置时间戳 ├ spoutTasks | ├ TASK365B33D23BC | ├ TASK945C3DB33CD | └ TASK76C46D1267B ├ shards | ├ shard001 | ├ shard002 | └ shard003 └ shardsTime ├ shard001:2013-11-14T08:16:05.197Z ├ shard002:2013-11-14T08:17:22.699Z └ shard003:2013-11-14T08:19:33.293Z MongoDB Spout放置时间戳

  38. 通信转发服务器状态监控 • 数据库服务器状态监控 • 应用服务器状态监控 集群节点监控

  39. MongoDB造成延时 • 对MongoDB和Storm的监控不够 • Topology必须停止才能升级 • 弹性不够 架构不足点

  40. 多参与社区的讨论 • 给设计人员制定目标 • 为架构培养人才队伍 • 反复的测试 经验分享

More Related