大数据平台产品竞争力调研报告.doc

广州日滨科技发展有限公司 产品竞争力分析报告 项目名称：分布式大数据通信和存储框架调研 编 制： 江荣钿 校 对： 标准化： 审 核： 批 准： 二〇一五年五月八日 目 录 1 调研概述 2 1.1调研范围及目的 2 1.1.1 通信需求 3 1.1.2 存储需求 3 1.1.3 数据挖掘需求 5 1.2调研情况 10 2 竞争环境分析 10 3 产品分析 11 3.1通信平台分析 11 3.1.1 ActiveMQ 11 3.1.2 RabbitMQ 13 3.1.3 RocketMQ 17 3.2数据处理、存储技术分析 19 3.2.1 Storm 19 3.2.2 Hadoop 21 3.2.3 MongoDB 23 3.2.4 Ms Sqlserver 24 4 产品竞争力分析 25 4.1应用分析 25 4.2特性对比 26 4.2.1 通信框架对比 26 4.2.2 处理和存储框架特性 28 5 总结及建议 29 5.1 总结 29 5.1.1 分布式通信系统 29 5.1.2 分布式实时数据处理存储及和通信系统整合 31 5.2建议 32 5.2.1 选用服务器和平台 32 5.2.2 开发计划 33 6 附件 34 调研概述 1.1调研范围及目的 公司目前的软件产品包括GPS车载信息和电梯遥监平台，随着业务量的增长，终端数量和用户数量快速增加，而用户的业务需求也在不断扩展。大容量的数据和高并发的请求给系统带来了严峻的性能考验。为了突破性能瓶颈，公司领导提出了搭建大数据处理平台的构想，通过主流的大数据技术应用和框架，以分布式计算、存储为技术方向，研讨在公司软件平台实施分布式数据处理的可行性。 本调研以电梯遥监和GPS车载平台为方案对象： 电梯遥监平台：目前终端数量6万多台，近期设计目标20万台，远期设计目标为50万台，目前常在线数量不到3000台，峰值数据传输数为每秒20万包； GPS车载平台目前终端数量超过1万台，常在线比例30%，在线终端发包频率是10秒钟，远期目标是达到10万台终端。 根据实际的项目情况，研究目前最流行的分布式技术，通过研究和对比得到最合适的方案设计。 1.1.1 通信需求 根据收集各项目组在现有项目中以及对未来可能产生的对通信模块的需求，整理列示如下： 可靠性：消息服务器或终端在故障重启后继续传输消息，不会造成消息的丢失。 消息分发：可以将某一条或某一类消息分发到多台终端中。 条件过滤：可以为消息设定接收条件，只有符合条件的终端才能接收消息。 粘包处理：对于数据包中的粘包，可以正确地分割消息。 日志记录：可选择将收发的消息记录在日志中。 空闲下线：终端在一定时间内无消息收发，则自动下线。 消息优先级：多条消息通道，处理不同紧急程度的消息。 可扩展：支持分布式部署，在终端增加时可以通过横向扩展增加服务的容量。 高可用：支持故障转移，在单机故障时可转移到另一台服务器继续运行。 安全性：消息在传输过程中安全 跨平台：可支持在多种平台下使用，支持多种开发语言进行开发 大文件传送：支持音/视频等大文件的传送。 可控性：可以对终端进行命令下发，支持RPC操作。 可维护性：方便地对系统进行管理。 1.1.2 存储需求 电梯的数据需求： 序号 配置等级 通信（MB/月/台） 存储（MB/年/台） 备注 1 标准配置 23.57 72.74 2 高端配置 299.6 8475.82 考虑每天10h的状态数据 根据表计算结果，标准配置的数据的存储容量要求为72.74MB/台*年,按系统内运维20万台计算，每年新增数据容量约为14TB。高端配置的数据的存储容量要求为8.5GB/台*年,按系统内运维500 台计算,每年新增数据容量约为4.25TB（未考虑视频、音频数据），本方案采用分布式的数据库系统HBase对数据保存，HBase的数据保存于Hdfs的文件之上，默认每个文件在整个集群中保留3份副本，并保持磁盘30%的剩余空间用于存储临时信息； 另外，由于HBase需要存储记录的Rowkey和Timestamp，每条记录会产生20Kb的长度（附表3.2得到每天的存储记录数量约1100条/台，高端配置是约180000条/台）， 而上行的数据经过解析加工后，由于关联字段的冗余，记录存储的长度会增长2~5倍。每年的数据容量需求为： 原始数据的容量：（14+4.25）*3=54.75 TB/年/20万 Rowkey及Timestamp长度： 1100*20*365*200000+180000*20*365*500=2.3TB/年/20万 关联字段冗余长度（按3倍计算）： 55.5*(3-1)= 109.5 TB/年/20万 即所有电梯每年的数据总长度是