slide1 n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
基于 zookeeper 和 storm 的车载流式计算 框架 PowerPoint Presentation
Download Presentation
基于 zookeeper 和 storm 的车载流式计算 框架

Loading in 2 Seconds...

play fullscreen
1 / 41

基于 zookeeper 和 storm 的车载流式计算 框架 - PowerPoint PPT Presentation


  • 420 Views
  • Uploaded on

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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about '基于 zookeeper 和 storm 的车载流式计算 框架' - hertz


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
slide1

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

邵贤军

开发工程师 南京富士通南大软件技术有限公司

slide2

案例背景

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

摘要

slide3

案例背景1——业务背景

  • 业务场景
    • 物流公司
    • 校车安全
    • 油气公司
  • 主要功能
    • 运行数据记录
    • 监视驾驶
    • 违规警告
    • 绩效考评
    • 报表输出
    • 危险地带
    • 实时监控

日本市场占有率第一,积极拓展国内业务

slide4

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

slide5

一 数据量剧增+吞吐量剧增

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

slide6

二 连接数剧增+客户剧增

■通信服务器与各个业务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

slide7

三 分析计算程序任务不均匀+实时性不够

Analysis Process

Analysis Process

Analysis Process

Analysis Process

  • 现状
    • 同一公司的车辆数据分布在同一数据库
    • 分析计算进程与DB一对一地分析数据

DB1

  • 问题
    • 若一个公司有很多辆车,那么一个分析计算进程应付不过来,无法分散计算
    • 若一个公司车辆很少,那么该公司对应的分析进程将没有任务,浪费服务器资源
    • 因为分析进程的缓慢执行,车辆的实时运行数据无法反映到客户端

DB2

DB3

DBn

slide10

数据存储平台——MongoDB

MongoDB是一个介于关系数据库和非关系数据库之间的产品,是非关系数据库当中功能最丰富,最像关系数据库的。他支持的数据结构非常松散,是类似json的bjson格式,因此可以存储比较复杂的数据类型。Mongo最大的特点是他支持的查询语言非常强大,其语法有点类似于面向对象的查询语言,几乎可以实现类似关系数据库单表查询的绝大部分功能,而且还支持对数据建立索引。

它的特点是高性能、易部署、易使用,存储数据非常方便。主要功能特性有:

  • 面向集合存储,易存储对象类型的数据
  • 模式自由
  • 支持动态查询
  • 支持完全索引,包含内部对象
  • 支持查询
  • 支持复制和故障恢复
  • 使用高效的二进制数据存储,包括大型对象(如视频等)
  • 自动处理分片,以支持云计算层次的扩展性
  • 支持RUBY,PYTHON,JAVA,C++,PHP等多种语言。
  • 文件存储格式为BSON(一种JSON的扩展)
  • 可通过网络访问
slide11

数据量剧增和连接数剧增的解决办法

  • 高频读写表抽出
  • 1公司:1DB模式→N公司:1DB

DB1

DB1

DB2

DB1

DB2

DB3

DB3

DBn

DBn

slide12

选择MongoDB的原因

  • 增删改查操作最接近SQL,迁移容易,并可为其他业务使用
  • 支持数据的自动和手动分片,横向扩展容易
  • 性能测试结果接近预期,够用即可,不用追求完美
  • 支持数据复制、故障转移、横向扩展,基本符合RAS需求

CAP定理

性能

2个mongos,3个分片,非安全插入:

单独执行时:

→写线程10个并发时,每秒37000次写入

→读线程4个并发时,每秒43000次读取

同时执行时:

→写线程10个并发时,每秒达25000次写入

→读线程4个并发时,每秒达36000次读取

关系不大

※:CPU 3.2GHz MEM 16G 千兆网卡

slide13

逻辑部署和物理部署

  • 存储结构设计
  • 定期数据清除

MongoDB最佳实践

slide14

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

slide15

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

slide16

存储数据结构设计

{

“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}}}}

slide17

定期数据清除

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

实时计算平台——Storm

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

Storm为什么号称实时计算系统?

  • 计算基于内存,较之磁盘有数量级之差
  • 使用消息队列做数据传输,速度比数据库快很多
  • 使用流式计算思想,数据可以源源不断的被处理
  • 任何一个节点都可以将中间计算结果反馈给用户

为什么选择Storm?

  • 无需维护消息队列(Topic、LB、Broker),专注Producer&Consumer
  • 满足业务需求,适合业务场景
  • 社区活跃,版本更新快
  • 性能卓越,易扩展
slide20

Storm里的核心概念

  • Tuple&Stream

Tuple

Tuple

Stream

  • Topology&Spout&Bolt

Spout

Bolt

Bolt

Bolt

Bolt

Bolt

slide21

Storm里的核心概念

  • Nimbus&Supervisor&Worker&Task

Cluster

Supervisor

运行业务拓扑

ZooKeeper

Supervisor

Nimbus

ZooKeeper

Supervisor

ZooKeeper

提交代码,分配任务,监视Supervisor

Supervisor

Supervisor

进程

线程

Worker

Task:Bolt

Task:Spout

Task:Bolt

slide22

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

slide24

Storm里的核心概念

  • Stream Grouping

BoltA

BoltA

BoltA

BoltA

BoltB

BoltB

BoltB

BoltB

Shuffle

All

Fields

Global

slide25

计算拓扑设计

  • 数据顺序性保证
  • 基于统计的Worker和Task数值设置

Storm最佳实践

slide26

数据输入 FetchSpout

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

计算拓扑设计

slide27

计算拓扑设计

StasticBolt

DataPreBolt

AnalysisBolt

FetchSpout

DBWBolt

AnalysisBolt

FetchSpout

FetchSpout

DBWBolt

AnalysisBolt

DataPreBolt

StasticBolt

MongoDB

DBMLayer

Company 1

Company 2

Company 3

Company 4

slide28

计算拓扑设计

顺序性如何保证

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。

slide29

Storm Cluster Number: 8

最佳参数设置

通过反复的测试,得到一个接近能够处理完数据的比例设置,这里是2:10.

按照一个最佳数值设置建议:Worker个数是机器的整数倍,Task是Worker的整数倍。我们有7台机器作为Supervisor,所以Worker数设置为7,Task数值为14,于是得到FetchSpout个数为2,AnalysisBolt个数为12.

以上设置后,计算延时降低到1.3s左右

最大效率化——基于统计的计算量均匀化

slide30

ZooKeeper是什么

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

Zookeeper简介

slide31

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

Zookeeper核心概念——节点类型

/root

  • ├/dataNode1
  • ├/dataNode2
  • ├/dataNode3
  • ├/dataNode4
  • └/dataNode5
  • ├/subDataNode1
  • ├/subDataNode2
  • └/subDataNode1
slide33

Zookeeper的应用场景

  • 统一命名服务(Name Service)
  • 配置管理(Configuration Management)
  • 集群管理(Group Membership)
  • 共享锁(Locks)
  • 队列管理 (Queue Management)
slide34

协调数据清理(MonDC)

  • 协调任务分配(TaskDistribute)
  • 协调Spout对MongoDB的数据访问
  • 集群节点监控

ZooKeeper的使用

slide35

开始

轮询

警戒

清理

mongostat

MongoDB

/shardProcTime

  • ├/shard1:2013000912
  • ├/shard2:2013000523
  • ├/shard3:2013000943
  • ├/shard4:2013000125
  • └/shard5:2013000229

数据清理程序(MonDC)

slide36

订阅

获取新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)

slide37

首次运行

获取任务表

获取时间戳

取数据

发送数据

设置时间戳

├ 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放置时间戳

slide38

通信转发服务器状态监控

  • 数据库服务器状态监控
  • 应用服务器状态监控

集群节点监控

slide39

MongoDB造成延时

  • 对MongoDB和Storm的监控不够
  • Topology必须停止才能升级
  • 弹性不够

架构不足点

slide40

多参与社区的讨论

  • 给设计人员制定目标
  • 为架构培养人才队伍
  • 反复的测试

经验分享