云数据采集中心及大数据计算平台建设方案.docx

云数据采集中心及大数据计算平台建设方案.docx

《云数据采集中心及大数据计算平台建设方案.docx》由会员分享，可在线阅读，更多相关《云数据采集中心及大数据计算平台建设方案.docx（74页珍藏版）》请在冰点文库上搜索。

云数据采集中心及大数据计算平台建设方案

云数据采集中心及大数据计算平台

建设方案

1引言

1.1项目背景

根据CC智能战略的规划：

做强终端、云平台建设、大数据商业模式，CC正迈向大数据时代，当前正面向所有智能终端提供优质的服务，同时通过终端传感器或数据采集服务能够获取海量的数据，并且数据量会以TB级剧增。

因此CC迫切需要建设一套高性能、高安全性、高可靠性，可扩展性的云数据采集中心，并搭建一个数据中心支撑平台，以满足当今高速增长的数据存储、管理、计算的需求，同时便于将来拓展和进一步的改造。

目前CC数据中心是主要基于CC黑电、白电、浏览器等产品终端传感器采集的海量文本、图片数据以及用户数据，为CC后续其他数据分析挖掘项目提供数据支撑的信息平台。

对应方针——终端内容服务、云服务支撑与数据挖掘、个性化数据价值探索。

建立统一有效的云数据采集中心有利于CC大数据的管理，符合CC新的发展战略，CC黑电和白电产品终端传感器采集的数据有用户行为的文本数据（log）、台标等图片数据以及自建的影视知识库的结构化数据、电商平台的海量镜像数据。

当CC的用户量和采集的数据量与日俱增的时候，数据中心必须能通过添加更多服务节点来扩展性能和负载能力，保证高可扩展性和高可用性从而满足CC业务发展的需要。

1.2项目目标

●搭建分布式存储平台（能够存储海量非结构化数据和结构化数据）、分布式并行计算平台等等，满足海量数据的采集、存储、计算的需要，平

台必须具备高可用性，高扩展性，高可靠性要求。

●为CC后面的产品（收视率统计，智能推荐系统,拍立购，开放平台等等）的应用和实施打下坚实的基础，为集团CC的大数据提供运营支撑。

●云中心初期建立至少保证可以正常运营1~2年，硬件选型，软件开始要考虑到今后大规模扩容的要求。

●技术平台要有能力支持数据量最高1000W终端数量的数据存储、数据计算、信息推荐等的能力。

1.3建设原则

基于本项目的建设要求，本项目将遵循以下建设原则：

●前瞻性和高标准整个项目要按照企业对大数据应用的需要的高要求和高标准建设，参考行业标杆应用，建立满足需求，面向未来的目标，整个项目具有一定前瞻性。

●经济性和实用性整个项目以现有需求为基础，充分考虑未来发展的需要来确定系统的架构，既要降低系统的初期投入，又能满足服务对象的需求，同时系统设计应充分考虑对已有投资的保护，对已建立的数据中心、基础平台、应用软件应提供完备的整合方案。

●先进性和成熟性为了确保项目具有较长的生命周期，应充分考虑到管理创新、技术发展需要，按照先进的建设理念，选择先进的技术架构和成熟技术，满足业

务需求。

●高性能和安全性规范地进行系统建设和开发，提供合理且经济有效的应急方案，确保系统的稳定，向各类服务对象提供可靠的服务。

具有安全性，在系统遭到攻击或崩溃时能快速恢复，确保重要数据的机密性和完整性。

1.4参考规范

●GB9361-88计算站场地安全要求

●GB50173-93电子计算机机房设计规范

●GB2887-89计算站场地技术条件

●GB50174-2008电子信息系统机房设计规范

●GB50462-2008电子信息系统机房施工及验收规范

●GB50311-2007综合布线工程设计规范

●GB50312-2007综合布线系统工程验收规范

●GB50395-2007视频安防监控系统设计规范

●GB50263-2007气体灭火系统施工及验收规范

●GB50394-2007入侵报警系统工程设计规范

●GB/T20269-2006信息安全技术—信息系统安全管理要求

●GB/T20984-2007信息安全技术—信息安全风险评估规范

●GB/T22239-2008信息安全技术—信息系统安全等级保护基本要求

●GB/T22240-2008信息安全技术—信息系统安全等级保护定级指南

●GA/T388-2002B计算机信息系统安全等级保护管理要求

●GB/T8567-1988计算机软件产品开发文件编制指

●GB/T11457-1995软件工程术语

●GB/T11457-2006信息技术软件工程术语

●GB/T16260.1-2006软件工程产品质量第1部分:

质量模型

●GB/T16260.2-2006软件工程产品质量第2部分:

外部度量

●GB/T16260.3-2006软件工程产品质量第3部分:

内部度量

●GB/T16260.4-2006软件工程产品质量第4部分:

使用质量的度量

●GB/T14394-2008计算机软件可靠性和可维护性管理

●GB/T17544-1998信息技术软件包质量要求和测试

●GB/T18221-2000信息技术程序设计语言、环境与系统软件借口独立于语言的数据类型

●GB/T18491.1-2001信息技术软件测量功能规模测量第1部分：

概念定义

●GB/T18492-2001信息技术系统及软件完整性级别

●GB/Z18493-2001信息技术软件生存周期过程指南

●GB/T20157-2006信息技术软件维护

●GB/T20272-2006信息安全技术操作系统安全技术要求

●GB/T20008-2005信息安全技术操作系统安全评估准则

●GB/T20009-2005信息安全技术数据库管理系统安全评估准则

●GB/T20918-2007信息技术软件生存周期过程风险管理

●GB/T8566-2007信息技术软件生存周期过程

●SJ/T10367-1993计算机过程控制软件开发规程

●SJ/T11234-2001软件过程能力评估模型

●SDO（ServiceDataObject）forJavaSpecificationV2.1

●SCA（ServiceComponentArchitecture）JavaEEIntegrationSpecificationV1.00

●Java2Platform,EnterpriseEdition

●CapabilityMaturityModel®Integration（CMMISM）,Version1.1

●ExtensibleMarkupLanguage（XML）1.0（FifthEdition）

●WebServicesBusinessProcessExecutionLanguagev2.0

1.5名词解释

●S2DFS：

简单存储分布式文件系统（SimpleStorageDistributedFileSystem）

●D2B:

分布式数据库（DistributedDatabase）

●JSS：

作业调度服务（JobSchedulerService）

●DCS：

数据计算服务（DataComputerService）

●MPS：

消息处理服务（MessageProcessService）

●SDS：

流数据处理服务（StreamDataService）

●DMQ：

分布式消息队列（DistributedMessageQueue）

●JGS：

作业生成服务（JobGenerationService）

●ACS：

自动清理服务进程（AutomaticCleaningServices）

●HTTP：

超文本传输协定（HyperTextTransferProtocol）

●SMB：

服务器信息块协议（ServerMessageBlock）

2云数据采集中心

2.1需求概述

根据CC的阶段规划，第一期云数据采集中心的建立至少满足1至2年内的数据存储和计算规模，需要满足200万台各种智能终端的数据存储和计算规模。

今后整个云数据采集中心的技术平台和架构需要轻松扩展到支持1000万台规模的各种智能终端的数据存储和计算规模。

以下的数据为预估数据（基于小范围的实验数据为依据）：

数据类别

文件（记录）大小1

文件（记录）数量1

文件（记录）大小2

文件（记录）数量2

台标数据（原始数据，

1天周期）

约16KB/台/天

（由200Kb/台/天而得）

约36个文件/台/天

约32GB/200万台/天

约7200万个/200万台/天

行为数据（原始数据，

1天周期）

约60KB/台/天（记录）

（由400Kb/台/天而得,加上了10KB的索引记录）约50KB/台/天（文件）

（由400Kb/台/天而得）

（平均估值）

约100条记录/台/天（记录）

约100个文件/台/天（文件）

（平均估值）

约120GB/200万台/天（记录）

约100GB/200万台/天（文件）

（平均估值）

约2亿条/200万台/天（记录）

约2亿个/200万台/天（文件）

（平均估值）

行为数据（原始数据，

永久保存，压缩处理）

约60KB/台/天（记录）

（由400Kb/台/天而得,加上了10KB的索引记录）约50KB/台/天（文件）

（由400Kb/台/天而得）

（平均估值）

约100条记录/台/天

约100个文件/台/天

（平均估值）

约45TB/200万台/1年（文件，加上元数据描述文件）

（平均估值）注：

记录的大小约为10GB

约35万条/200万台/1年（记录）

约35万个/200万台/1年（文件）

（平均估值）注：

128MB/1个文件

行为分析/收视率统计

/推荐/电商索引等记录

约10KB/1条（记录）

（平均估值）

约10TB/1年（记录）

（平均估值）

约10-15亿条记录/1年（记录）

（平均估值）

至少6大电商的镜像数

据

约30KB/1个（文件）

（平均估值）

约10亿个/1年（文件）

（平均估值）

约30TB/1年（文件）

（平均估值）

以1年为计算周期（数据整合、压缩、清洗后），初步预估：

1、数据记录：

约为10-15亿条；

2、文件个数：

约为10-12亿个；

3、记录总大小：

约为10TB；（双份副本：

需要约20TB存储空间）

4、文件总大小：

约为75TB；（双份副本：

需要约150TB存储空间）

5、总容量大小：

约为85TB；（双份副本：

需要约170TB存储空间）

为了数据的高可靠性，为每份（文件/记录）建立镜像副本，所以总容量初步可以规划约为170TB。

2.2总体设计

整个云数据采集中心分为四部分：

硬件资源层、软件平台层、软件应用层、智能终端层。

硬件资源层主要指实体硬件设备，包括用来存储数据的光纤阵列柜和存储服务器，用来作统计、分析以及搜索用的计算服务器，用来部署分布式消息（DMQ）

/WEB/APP软件的WEB及消息服务器，用来部署用PostgreSQL关系数据库软件的应用数据库服务器，用来部署作业调度服务进程（JSS）的作业调度服务器。

作为数据通信用的全千兆三层交换机等等。

其中光纤阵列柜主要用来存储统计分析后的粗颗粒度数据。

存储服务器用来部署分布式文件系统和分布式数据库，同时存储非结构化和结构化（台标图片，电商图片等等）和结构化数据（行为数据，索引数据，log数据，清理后的细颗粒度数据等等）。

计算服务器主要用来完成数据的清理、统计、搜索等计算任务。

为了节省成本和减少通信代价，建议存储服

务器和计算服务器合二为一，所以该服务器同时具有计算和存储数据的功能，前期也可以考虑把作业调度服务进程（JSS）进程部署在存储/计算服务器上。

由于云数据采集中心需要面对多种宽带用户（电信、移动、联通），所以，数据中心的对外的网络需要直连上电信、移动、联通三家公司的网络，保证以上三家公司间的通信性能高速和可靠。

软件平台层是云数据采集中心的核心支撑层，也是我们这次方案设计和实施的主体部分，在核心技术章节会对“分布式文件系统（S2DFS）”、“分布式数据库（D2B）”、“分布式消息服务（DMQ）”“作业调度服务进程（JSS）、数据计算服务进程（DCS）”主要部分加以详细的描述。

软件平台层的所有服务器

都统一部署的64位操作系统CentOS6.5（也可以选择RHEL6.5x64）；其核心软件或者进程有：

分布式文件系统（S2DFS）、分布式数据库（D2B）、作业调度服务进程（JSS）、数据计算服务进程（DCS）、作业生成服务进程（JGS）、消息处理服务进程（MPS）、流数据处理进程（SDS）等等。

WEB及应用服务器软件Apache&Tomcat，消息队列软件分布式消息（DMQ）。

还要实现整个云数据采集中心的资源管理及监控管理系统。

软件应用层是云数据采集中心的功能实现及UI表达层，功能实现需要基于软件平台层的支撑，后期设计和实施的主体。

该层的主要功能应用有：

数据采集应用、收视率统计应用、智能推荐应用、拍立购应用，云数据采集中心的资源监控及调度，通过提供标准API，在CC的云平台上集成第三方APP应用，使我们的云平台成为一个开放的平台，围绕CC的各种智能终端或者第三方的终端，都纳入到平台上来，建立一个完备而丰富的运营生态圈，使CC在互联网时代的竞

争中占得先机。

过公共数据网（电信、联通、移动）和HTTP协议，把终端传感器采集的海量文本、图片数据以及用户行为数据存储在云数据采集中心里，以供后期分析计算用。

第一期是单向交互，主要是终端提供数据，云数据采集中心负责计算，并作推荐。

第二期会引入终端与云数据采集中心的实时双向交互功能。

云数据采集中心网络结构图

17

2.3核心技术及功能

2.3.1分布式文件存储技术

（1）传统存储技术面临的问题：

⏹构建成本高：

大容量及高网络带宽的高端存储系统架构昂贵。

⏹文件系统功能和性能差强人意：

难以实现全局命名空间的文件共享、文件系统难以扩展，容易形成瓶颈。

⏹扩展性困难：

技术存在瓶颈（Scale-up架构决定的）、扩展成本无法控制。

⏹可用性问题：

潜在的单点故障,数据恢复困难，代价高。

⏹应用目标差异：

主要面临运营商、金融行业的OLTP应用、很少针对海量的流数据，或者非结构化数据进行设计和优化。

⏹异构设备繁杂：

不同时期、不同公司、不同操作系统的异构设备纷繁复杂，无法整合，资源利用率极低。

分布式文件系统主要为解决以上问题而出现的一种新型大规模数据存储技术架构。

主要为非结构化数据（视频/文件/文档/图像/音频等非结构化数据）提供海量的存储平台，以集群的方式提供线性横向扩展能力。

分布式文件系统是一种构建于通用x86部件之上的高可用、高可靠、高可扩展的新型分布式文件系统。

应用分布式文件系统，用户可以采用廉价可靠的通用服务器、SATA/SAS硬盘以及以太网络来构建媲美企业级存储产品的存储系统。

（2）分布式文件系统应对的数据特性和访问特性：

⏹数据量巨大，数百TB或PB级，增长迅速；

⏹类型多样化，包括图像、文本、语音、视频等文件数据；

⏹按时间有序生成，数据均带有时间标志；

⏹前端数据写入速度很高，每秒钟写入数据可达几万甚至几十万条记录或者上GB量数据；

⏹更新操作极少：

追加方式写入，一旦写入，几乎没有数据修改，查询涉及大量的磁盘读操作，查询处理产生大量的临时结果，不同类型的数据存在联合分析查询；

分布式文件系统的基本原理是采用集群方式来整合物理上独立的多个存储资源，以软件方式提供单一的名字空间；采用多副本的方式保证数据的高可用性，任意单一节点失效均不会导致数据丢失和数据服务的正常运行；同时，分布式文件系统通过良好设计的系统结构和数据分布策略，可保证系统性能的高可扩展性，并支持存储容量/性能的在线扩展。

相比较于DAS（直连存储）、SAN（存储区域网络）和NAS（网络存储），应用分布式文件系统构建的网络存储系统更像是一个NAS，提供类似于传统NAS的文件级访问接口（SAN和DAS都是块设备级别的访问接口）。

（3）分布式文件系统与传统NAS/SAN设备的比较：

比较项

高端NAS

FC-SAN

分布式文件系统

性能

一般双端口，性能受机头

影响，难以扩展，出口带宽是瓶颈

一般双端口，性能受

机头影响，难以扩展，IOPS较好

性能随节点数的增加成线

性增长

扩展能力

性能及容量无法扩展，或

者有限扩展

能较好扩展，但成本

高昂

性能及容量按需扩展，动

态均衡

可用性

RAID方式保护，双机保

护，停机RAIDRebuid，耗时

RAID方式保护，双机

保护，停机RAIDRebuid，耗时

基于灵活的多副本机制，

自动检测，自动故障恢复，无需停机

数据管理

企业级功能需要单独购买

企业级功能需要单独

购买（还需要单独的

内嵌多种企业级应用：

快

照、镜像、回收站

文件系统，100多万一

套）

成本

专有的硬件平台，软件拥

有成本高，扩展成本高

专有的硬件平台，软

件拥有成本高，扩展成本高

开发通用的硬件平台，一

体化的软件，成本低，扩展成本低

可维护性

专门的技术支持服务，需

要培训

结构异常复杂，需要

大量培训，厂商服务昂贵

内嵌多种自动化的故障检

测和恢复功能，国内开发，技术支持快速

用户使用分布式文件系统如同使用本地文件系统。

所不同的是，传统NAS通常以单一节点的方式实现，容量和性能的扩展能力有限，易于成为性能瓶颈和单一故障点。

而分布式文件系统则有多个节点集合地提供服务，由于其结构特征，分布式文件系统的性能和容量均可在线线性扩展，并且系统内不存在单一故障点。

对比参看下面两幅示意图：

传统存储架构图

分布式文件系统架构图分布式文件系统的设计应用特别适合海量非结构化数据存储，大量客户端并

发的I/O密集型应用。

目前，分布式文件系统已经被应用于政府、医疗影像、勘查数据计算、视频服务以及动画制作等领域。

这些领域的数据访问特征均为：

数据量巨大，I/O吞吐率高，数据增长迅速以及数据可用性要求高。

经过长时间的实际生产环境使用，分布式文件系统已被证明是该类型应用的有效解决方案。

分布式文件系统架构图分布式文件系统的服务器端程序运行于Linuxx64系统之上，支持多种Linux

64位发行版，包括Redhat、CentOS等。

分布式文件系统客户端则支持Linux和Windows，同时分布式文件系统还可以通过第三方软件输出CIFS和NFS接口，可以兼容大多数应用。

（4）分布式文件系统的核心技术及特征：

⏹扩展性和高性能：

分布式文件系统利用双重特性来提供几TB至数PB的高扩展存储解决方案。

Scale-Out架构允许通过简单地增加资源来提高存储容量和性能，磁盘、计算和I/O资源都可以独立增加，支持10GbE和InfiniBand等高速网络互联。

分布式文件系统弹性哈希（ElasticHash）解除了分布式文件系统对元数据服务器的需求，消除了单点故障和性能瓶颈，真正实现了并行化数据访问。

⏹高可用性：

分布式文件系统可以对文件进行自动复制，如镜像或多次复制，从而确保数据总是可以访问，甚至是在硬件故障的情况下也能正常访问。

自我修复功能能够把数据恢复到正确的状态，而且修复是以增量的方式在后台执行，几乎不会产生性能负载。

分布式文件系统没有设计自己的私有数据文件格式，而是采用操作系统中主流标准的磁盘文件系统（如XFS/EXT4/ZFS）来存储文件，因此数据可以使用各种标准工具进行复制和访问。

⏹全局统一命名空间：

全局统一命名空间将磁盘和内存资源聚集成一个单一的虚拟存储池，对上层用户和应用屏蔽了底层的物理硬件。

存储资源可以根据需要在虚拟存储池中进行弹性扩展，比如扩容或收缩。

当存储虚拟机映像时，存储的虚拟映像文件没有数量限制，成千虚拟机均通过单一挂载点进行数据共享。

虚拟机I/O可在命名空间内的所有服务器上自动进行负载均衡，消除了SAN环境中经常发生的访问热点和性能瓶颈问题。

⏹弹性哈希算法：

分布式文件系统采用弹性哈希算法在存储池中定位数据，而不是采用集中式或分布式元数据服务器索引。

在其他的Scale-Out存储系统中，元数据服务器通常会导致I/O性能瓶颈和单点故障问题。

分布式文件系统中，所有在Scale-Out存储配置中的存储系统都可以智能地定位任意数据分片，不需要查看索引或者向其他服务器查询。

这种设计机制完全并行化了数据访问，实现了真正的线性性能扩展。

⏹弹性卷管理：

数据储存在逻辑卷中，逻辑卷可以从虚拟化的物理存

除，不会导致应用中断。

逻辑卷可以在所有配置服务器中增长和缩减，可以在不同服务器迁移进行容量均衡，或者增加和移除系统，这些操作都可在线进行。

文件系统配置更改也可以实时在线进行并应用，从而可以适应工作负载条件变化或在线性能调优。

⏹完全软件实现（SoftwareOnly）：

分布式文件系统认为存储是软件问题，不能够把用户局限于使用特定的供应商或硬件配置来解决。

分布式文件系统采用开放式设计，广泛支持工业标准的存储、网络和计算机设备，而非与定制化的专用硬件设备捆绑。

对于商业客户，分布式文件系统可以以虚拟装置的形式交付，也可以与虚拟机容器打包，或者是公有云中部署的映像。

开源社区中，分布式文件系统被大量部署在基于廉价闲置硬件的各种操作系统上，构成集中统一的虚拟存储资源池。

简而言之，分布式文件系统是开放的全软件实现，完全独立于硬件和操作系统。

⏹完整的存储操作系统栈（CompleteStorageOperatingSystemStack：

分布式文件系统不仅提供了一个分布式文件系统，而且还提供了许多其他重要的分布式功能，比如分布式内存管理、I/O调度、软RAID和自我修复等。

分布式文件系统汲取了微内核架构的经验教训，借鉴了GNU/Hurd操作系统的设计思想，在用户空间实现了完整的存储操作系统栈。

⏹用户空间实现（UserSpace）：

与传统的文件系统不同，分布式文件系统在用户空间实现，这使得其安装和升级特别简便。

另外，这也极

通用的C程序设计技能，而不需要特别的内核编程经验。

⏹模块化堆栈式架构（ModularStackableArchitecture）：

分布式文件系统采用模块化、堆栈式的架构，可通过灵活的配置支持高度定制化的应用环境，比如大文件存储、海量小文件存储、分布式文件系统、多传输协议应用等。

每个功能以模块形式实现，然后以积木方式进行简单的组合，即可实现复杂的功能。

比如，Replicate模块可实现RAID1，Stripe