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

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

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

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

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

一数据量剧增+吞吐量剧增 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, 但是固定时间点车载机会同时向云端发送运行数据

二连接数剧增+客户剧增 ■通信服务器与各个业务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

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

案例技术方案概览

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

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

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

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

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

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

存储数据结构设计 { “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}}}}

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

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

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

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

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

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呢？

Storm里的核心概念 • Stream Grouping

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

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

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

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

计算拓扑设计 顺序性如何保证 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。

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

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

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节点看，树视图都一样

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

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

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

否开始轮询警戒清理是 mongostat MongoDB /shardProcTime • ├/shard1：2013000912 • ├/shard2：2013000523 • ├/shard3：2013000943 • ├/shard4：2013000125 • └/shard5：2013000229 数据清理程序（MonDC）

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

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

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

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