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


CC 云数据采集中心及大数据计算平台 建设方案 成都中蓝信息技术有限责任公司 联系 QQ:1280986324,欢迎探讨! 目 录 1 引言 ............................................................................................................................. 5 1.1 项目背景 ............................................................................................................... 5 1.2 项目目标 ............................................................................................................... 5 1.3 建设原则 ............................................................................................................... 6 1.4 参考规范 ............................................................................................................... 7 1.5 名词解释 ............................................................................................................... 9 2 云数据采集中心 ........................................................................................................ 10 2.1 需求概述 ............................................................................................................. 10 2.2 总体设计 ............................................................................................................. 13 2.3 核心技术及功能 .................................................................................................. 18 2.3.1 分布式文件存储技术..................................................................................... 18 2.3.2 分布式并行计算技术..................................................................................... 27 2.3.3 分布式数据库技术 ........................................................................................ 31 2.3.4 负载均衡 ....................................................................................................... 34 2.3.5 数据采集 ....................................................................................................... 39 2.3.6 开放平台 ....................................................................................................... 45 2.4 部署方案 ............................................................................................................. 48 2.5 实施计划 ............................................................................................................. 50 联系 QQ:1280986324,欢迎探讨! 3 大数据计算平台 ........................................................................................................ 52 3.1 需求概述 ............................................................................................................. 52 3.2 总体设计 ............................................................................................................. 52 3.3 应用建设 ............................................................................................................. 57 3.3.1 收视率统计 .................................................................................................... 57 3.3.2 智能推荐 ........................................................................................................ 60 3.3.3 拍立购............................................................................................................ 63 3.4 部署方案 ............................................................................................................. 69 3.5 实施计划 ............................................................................................................. 72 4 性能及成本分析 ........................................................................................................ 73 4.1 运营商网络性能分析 ............................................................................................ 73 4.2 服务器网卡性能分析 ............................................................................................ 73 4.2 服务器内存性能分析 ............................................................................................ 73 4.3 服务器硬盘性能分析 ............................................................................................ 74 4.4 服务器 RAID 模式分析 ........................................................................................ 74 4.5D2B 性能分析 ....................................................................................................... 75 4.4DMQ 平台性能分析 .............................................................................................. 75 5 存储空间规划表 ........................................................................................................ 76 6 机房选型 ................................................................................................................... 77 联系 QQ:1280986324,欢迎探讨! 7 安全设计 ................................................................................................................... 78 8 风险分析 ................................................................................................................... 81 5 1 引言 1.1 项目背景 根据 CC 智能战略的规划:做强终端、云平台建设、大数据商业模式,CC 正 迈向大数据时代,当前正面向所有智能终端提供优质的服务,同时通过终端传感 器或数据采集服务能够获取海量的数据,并且数据量会以 TB 级剧增。因此 CC 迫切需要建设一套高性能、高安全性、高可靠性,可扩展性的云数据采集中心, 并搭建一个数据中心支撑平台,以满足当今高速增长的数据存储、管理、计算的 需求,同时便于将来拓展和进一步的改造。 目前 CC 数据中心是主要基于 CC 黑电、白电、浏览器等产品终端传感器采 集的海量文本、图片数据以及用户数据,为 CC 后续其他数据分析挖掘项目提供 数据支撑的信息平台。对应方针——终端内容服务、云服务支撑与数据挖掘、个 性化数据价值探索。 建立统一有效的云数据采集中心有利于 CC 大数据的管理,符合 CC 新的发 展战略,CC 黑电和白电产品终端传感器采集的数据有用户行为的文本数据(log)、 台标等图片数据以及自建的影视知识库的结构化数据、电商平台的海量镜像数据。 当 CC 的用户量和采集的数据量与日俱增的时候,数据中心必须能通过添加更多 服务节点来扩展性能和负载能力,保证高可扩展性和高可用性从而满足 CC 业务 发展的需要。 1.2 项目目标  搭建分布式存储平台(能够存储海量非结构化数据和结构化数据)、分 布式并行计算平台等等,满足海量数据的采集、存储、计算的需要,平 6 台必须具备高可用性,高扩展性,高可靠性要求。  为 CC 后面的产品(收视率统计,智能推荐系统,拍立购,开放平台等等) 的应用和实施打下坚实的基础,为集团 CC 的大数据提供运营支撑。  云中心初期建立至少保证可以正常运营 1~2 年,硬件选型,软件开始要 考虑到今后大规模扩容的要求。  技术平台要有能力支持数据量最高 1000W 终端数量的数据存储、数据计 算、信息推荐等的能力。 1.3 建设原则 基于本项目的建设要求,本项目将遵循以下建设原则:  前瞻性和高标准 整个项目要按照企业对大数据应用的需要的高要求和高标准建设,参考 行业标杆应用,建立满足需求,面向未来的目标,整个项目具有一定前 瞻性。  经济性和实用性 整个项目以现有需求为基础,充分考虑未来发展的需要来确定系统的架 构,既要降低系统的初期投入,又能满足服务对象的需求,同时系统设 计应充分考虑对已有投资的保护,对已建立的数据中心、基础平台、应 用软件应提供完备的整合方案。  先进性和成熟性 为了确保项目具有较长的生命周期,应充分考虑到管理创新、技术发展 需要,按照先进的建设理念,选择先进的技术架构和成熟技术,满足业 务需求。 7  高性能和安全性 规范地进行系统建设和开发,提供合理且经济有效的应急方案,确保系 统的稳定,向各类服务对象提供可靠的服务。具有安全性,在系统遭到 攻击或崩溃时能快速恢复,确保重要数据的机密性和完整性。 1.4 参考规范  GB 9361-88 计算站场地安全要求  GB 50173-93 电子计算机机房设计规范  GB 2887-89 计算站场地技术条件  GB 50174-2008 电子信息系统机房设计规范  GB 50462-2008 电子信息系统机房施工及验收规范  GB 50311-2007 综合布线工程设计规范  GB 50312-2007 综合布线系统工程验收规范  GB 50395-2007 视频安防监控系统设计规范  GB 50263-2007 气体灭火系统施工及验收规范  GB 50394-2007 入侵报警系统工程设计规范  GB/T 20269-2006 信息安全技术—信息系统安全管理要求  GB/T 20984-2007 信息安全技术—信息安全风险评估规范  GB/T 22239-2008 信息安全技术—信息系统安全等级保护基本要求  GB/T 22240-2008 信息安全技术—信息系统安全等级保护定级指南  GA/T 388-2002B 计算机信息系统安全等级保护管理要求  GB/T 8567 -1988 计算机软件产品开发文件编制指  GB/T 11457-1995 软件工程术语 8  GB/T 11457-2006 信息技术 软件工程术语  GB/T 16260.1-2006 软件工程 产品质量 第 1 部分:质量模型  GB/T 16260.2-2006 软件工程 产品质量 第 2 部分:外部度量  GB/T 16260.3-2006 软件工程 产品质量 第 3 部分:内部度量  GB/T 16260.4-2006 软件工程 产品质量 第 4 部分:使用质量的度量  GB/T 14394-2008 计算机软件可靠性和可维护性管理  GB/T 17544-1998 信息技术 软件包 质量要求和测试  GB/T 18221-2000 信息技术 程序设计语言、环境与系统软件借口 独立 于语言的数据类型  GB/T 18491.1-2001 信息技术 软件测量 功能规模测量 第 1 部分:概念 定义  GB/T 18492-2001 信息技术 系统及软件完整性级别  GB/Z 18493-2001 信息技术 软件生存周期过程指南  GB/T 20157-2006 信息技术 软件维护  GB/T 20272-2006 信息安全技术 操作系统安全技术要求  GB/T 20008-2005 信息安全技术 操作系统安全评估准则  GB/T 20009-2005 信息安全技术 数据库管理系统安全评估准则  GB/T 20918-2007 信息技术 软件生存周期过程 风险管理  GB/T 8566-2007 信息技术 软件生存周期过程  SJ/T 10367-1993 计算机过程控制软件开发规程  SJ/T 11234-2001 软件过程能力评估模型  SDO (Service Data Object) for Java Specification V2.1 9  SCA (Service Component Architecture)Java EE Integration Specification V1.00  Java 2 Platform, Enterprise Edition  Capability Maturity Model® Integration (CMMISM), Version 1.1  Extensible Markup Language (XML) 1.0 (Fifth Edition)  Web Services Business Process Execution Language v2.0 1.5 名词解释  S2DFS:简单存储分布式文件系统(Simple Storage Distributed File System)  D2B:分布式数据库(Distributed Database)  JSS:作业调度服务(Job Scheduler Service)  DCS:数据计算服务(Data Computer Service)  MPS:消息处理服务(Message Process Service)  SDS:流数据处理服务(Stream Data Service)  DMQ:分布式消息队列(Distributed Message Queue)  JGS:作业生成服务(Job Generation Service)  ACS:自动清理服务进程(Automatic Cleaning Services)  HTTP:超文本传输协定(HyperText Transfer Protocol)  SMB:服务器信息块协议(Server Message Block) 10 2 云数据采集中心 2.1 需求概述 根据 CC 的阶段规划,第一期云数据采集中心的建立至少满足 1 至 2 年内的 数据存储和计算规模,需要满足 200 万台各种智能终端的数据存储和计算规模。 今后整个云数据采集中心的技术平台和架构需要轻松扩展到支持 1000 万台规模 的各种智能终端的数据存储和计算规模。 11 以下的数据为预估数据(基于小范围的实验数据为依据): 数据类别 文件(记录)大小 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 年(记录) (平均估值) 12 至少 6大电商的镜像数 据 约 30KB/1 个(文件) (平均估值) 约 10 亿个/1 年(文件) (平均估值) 约 30TB/1 年(文件) (平均估值) 13 以 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 数据,清理后的细颗粒度数据等等)。计算服务器主要用来完成数 据的清理、统计、搜索等计算任务。为了节省成本和减少通信代价,建议存储服 14 务器和计算服务器合二为一,所以该服务器同时具有计算和存储数据的功能,前 期也可以考虑把作业调度服务进程(JSS)进程部署在存储/计算服务器上。由于 云数据采集中心需要面对多种宽带用户(电信、移动、联通),所以,数据中心 的对外的网络需要直连上电信、移动、联通三家公司的网络,保证以上三家公司 间的通信性能高速和可靠。 软件平台层是云数据采集中心的核心支撑层,也是我们这次方案设计和实施 的主体部分,在核心技术章节会对“分布式文件系统(S2DFS)”、“分布式数 据库(D2B)”、“分布式消息服务(DMQ)”“作业调度服务进程(JSS)、数 据计算服务进程(DCS)”主要部分加以详细的描述。软件平台层的所有服务器 都统一部署的 64 位操作系统 CentOS 6.5(也可以选择 RHEL 6.5 x64);其核心软 件或者进程有:分布式文件系统(S2DFS)、分布式数据库(D2B)、作业调度服 务进程(JSS)、数据计算服务进程(DCS)、作业生成服务进程(JGS)、消息处 理服务进程(MPS)、流数据处理进程(SDS)等等。WEB 及应用服务器软件 Apache&Tomcat,消息队列软件分布式消息(DMQ)。还要实现整个云数据采集 中心的资源管理及监控管理系统。 软件应用层是云数据采集中心的功能实现及 UI 表达层,功能实现需要基于 软件平台层的支撑,后期设计和实施的主体。该层的主要功能应用有:数据采集 应用、收视率统计应用、智能推荐应用、拍立购应用,云数据采集中心的资源监 控及调度,通过提供标准 API,在 CC 的云平台上集成第三方 APP 应用,使我们 的云平台成为一个开放的平台,围绕 CC 的各种智能终端或者第三方的终端,都 纳入到平台上来,建立一个完备而丰富的运营生态圈,使 CC 在互联网时代的竞 争中占得先机。 15 智能终端层主要包括 CC 黑电、白电、浏览器等产品设备,这些终端设备通 过公共数据网(电信、联通、移动)和 HTTP 协议,把终端传感器采集的海量文 本、图片数据以及用户行为数据存储在云数据采集中心里,以供后期分析计算用。 第一期是单向交互,主要是终端提供数据,云数据采集中心负责计算,并作推荐。 第二期会引入终端与云数据采集中心的实时双向交互功能。 存储设备 网络设备 服务器设备 S2DFS D2B PostgreSQL Nginx CentOS 6.5 x64 Apache Tomcat DMQ JSS DCSJGSMPS SDS 收视率统计应用 智能推荐应用 拍立购应用 开放 平台 云中心监控 第三方应用 API 16 云数据采集中心整体架构图 17 智能终端 智能终端 智能终端 …… 数据公共网 联通/电信/移动 骨 干 网 防火墙 存储/计算服务器 存储/计算服务器 存储/计算服务器 WEB及消息服务器 WEB及消息服务器 WEB及消息服务器 …… 作业调度 服务器(主) 作业调度 服务器(备) 资源及监控管理 资源及权限管理 …… 负载均衡服务器 负载均衡服务器 …… 分布式数据库 服务器 分布式数据库 服务器分布式数据库 服务器 …… 云数据采集中心网络结构图 18 2.3 核心技术及功能 2.3.1 分布式文件存储技术 (1) 传统存储技术面临的问题:  构建成本高:大容量及高网络带宽的高端存储系统架构昂贵。  文件系统功能和性能差强人意:难以实现全局命名空间的文件共享、 文件系统难以扩展,容易形成瓶颈。  扩展性困难:技术存在瓶颈(Scale-up 架构决定的)、扩展成本无法 控制。  可用性问题:潜在的单点故障,数据恢复困难,代价高。  应用目标差异:主要面临运营商、金融行业的 OLTP 应用、很少针 对海量的流数据,或者非结构化数据进行设计和优化。  异构设备繁杂:不同时期、不同公司、不同操作系统的异构设备纷 繁复杂,无法整合,资源利用率极低。 分布式文件系统主要为解决以上问题而出现的一种新型大规模数据存储技 术架构。主要为非结构化数据(视频/文件/文档/图像/音频等非结构化数据)提 供海量的存储平台,以集群的方式提供线性横向扩展能力。 分布式文件系统是一种构建于通用 x86 部件之上的高可用、高可靠、高可扩 展的新型分布式文件系统。应用分布式文件系统,用户可以采用廉价可靠的通用 服务器、SATA/SAS 硬盘以及以太网络来构建媲美企业级存储产品的存储系统。 (2) 分布式文件系统应对的数据特性和访问特性:  数据量巨大,数百 TB 或 PB 级,增长迅速; 19  类型多样化,包括图像、文本、语音、视频等文件数据;  按时间有序生成,数据均带有时间标志 ;  前端数据写入速度很高,每秒钟写入数据可达几万甚至几十万条记 录或者上 GB 量数据 ;  更新操作极少:追加方式写入,一旦写入,几乎没有数据修改,查 询涉及大量的磁盘读操作,查询处理产生大量的临时结果,不同类 型的数据存在联合分析查询; 分布式文件系统的基本原理是采用集群方式来整合物理上独立的多个存储 资源,以软件方式提供单一的名字空间;采用多副本的方式保证数据的高可用性, 任意单一节点失效均不会导致数据丢失和数据服务的正常运行;同时,分布式文 件系统通过良好设计的系统结构和数据分布策略,可保证系统性能的高可扩展性, 并支持存储容量/性能的在线扩展。 相比较于 DAS(直连存储)、SAN(存储区域网络)和 NAS(网络存储), 应用分布式文件系统构建的网络存储系统更像是一个NAS,提供类似于传统NAS 的文件级访问接口(SAN 和 DAS 都是块设备级别的访问接口)。 (3) 分布式文件系统与传统 NAS/SAN 设备的比较: 比较项 高端 NAS FC-SAN 分布式文件系统 性能 一般双端口,性能受机头 影响,难以扩展,出口带 宽是瓶颈 一般双端口,性能受 机头影响,难以扩展, IOPS 较好 性能随节点数的增加成线 性增长 扩展能力 性能及容量无法扩展,或 者有限扩展 能较好扩展,但成本 高昂 性能及容量按需扩展,动 态均衡 可用性 RAID 方式保护,双机保 护,停机 RAID Rebuid,耗 时 RAID 方式保护,双机 保护,停机 RAID Rebuid,耗时 基于灵活的多副本机制, 自动检测,自动故障恢复, 无需停机 数据管理 企业级功能需要单独购买 企业级功能需要单独 购买(还需要单独的 内嵌多种企业级应用:快 照、镜像、回收站 20 文件系统,100 多万一 套) 成本 专有的硬件平台,软件拥 有成本高,扩展成本高 专有的硬件平台,软 件拥有成本高,扩展 成本高 开发通用的硬件平台,一 体化的软件,成本低,扩 展成本低 可维护性 专门的技术支持服务,需 要培训 结构异常复杂,需要 大量培训,厂商服务 昂贵 内嵌多种自动化的故障检 测和恢复功能,国内开发, 技术支持快速 用户使用分布式文件系统如同使用本地文件系统。所不同的是,传统 NAS 通常以单一节点的方式实现,容量和性能的扩展能力有限,易于成为性能瓶颈和 单一故障点。而分布式文件系统则有多个节点集合地提供服务,由于其结构特征, 分布式文件系统的性能和容量均可在线线性扩展,并且系统内不存在单一故障点。 对比参看下面两幅示意图: 传统存储架构图 21 分布式文件系统架构图 分布式文件系统的设计应用特别适合海量非结构化数据存储,大量客户端并 发的 I/O 密集型应用。目前,分布式文件系统已经被应用于政府、医疗影像、 勘查数据计算、视频服务以及动画制作等领域。这些领域的数据访问特征均为: 数据量巨大,I/O 吞吐率高,数据增长迅速以及数据可用性要求高。经过长时间 的实际生产环境使用,分布式文件系统已被证明是该类型应用的有效解决方案。 22 分布式文件系统逻辑卷 设备卷 设备卷 设备卷 设备卷 分布式文件系统客户端 卷管理 I/O调度 分布式文件系统网关 NFS/Samba 分布式文件系统客户端 分布式文件系统客户端 卷管理 I/O调度 设备卷 分布式文件系统 Server 端 分布式文件系统 Client 端 分布式文件系统架构图 分布式文件系统的服务器端程序运行于 Linux x64 系统之上,支持多种 Linux 64 位发行版,包括 Redhat、CentOS 等。分布式文件系统客户端则支持 Linux 和 Windows,同时分布式文件系统还可以通过第三方软件输出 CIFS 和 NFS 接口, 可以兼容大多数应用。 (4) 分布式文件系统的核心技术及特征:  扩展性和高性能:分布式文件系统利用双重特性来提供几 TB 至数 PB 的高扩展存储解决方案。Scale-Out 架构允许通过简单地增加资源 来提高存储容量和性能,磁盘、计算和 I/O 资源都可以独立增加, 支持 10GbE 和 InfiniBand 等高速网络互联。分布式文件系统弹性哈 希(Elastic Hash)解除了分布式文件系统对元数据服务器的需求, 消除了单点故障和性能瓶颈,真正实现了并行化数据访问。 23  高可用性:分布式文件系统可以对文件进行自动复制,如镜像或多 次复制,从而确保数据总是可以访问,甚至是在硬件故障的情况下 也能正常访问。自我修复功能能够把数据恢复到正确的状态,而且 修复是以增量的方式在后台执行,几乎不会产生性能负载。分布式 文件系统没有设计自己的私有数据文件格式,而是采用操作系统中 主流标准的磁盘文件系统(如 XFS/EXT4/ZFS)来存储文件,因此 数据可以使用各种标准工具进行复制和访问。  全局统一命名空间:全局统一命名空间将磁盘和内存资源聚集成一 个单一的虚拟存储池,对上层用户和应用屏蔽了底层的物理硬件。 存储资源可以根据需要在虚拟存储池中进行弹性扩展,比如扩容或 收缩。当存储虚拟机映像时,存储的虚拟映像文件没有数量限制, 成千虚拟机均通过单一挂载点进行数据共享。虚拟机 I/O 可在命名 空间内的所有服务器上自动进行负载均衡,消除了 SAN 环境中经常 发生的访问热点和性能瓶颈问题。  弹性哈希算法:分布式文件系统采用弹性哈希算法在存储池中定位 数据,而不是采用集中式或分布式元数据服务器索引。在其他的 Scale-Out 存储系统中,元数据服务器通常会导致 I/O 性能瓶颈和单 点故障问题。分布式文件系统中,所有在 Scale-Out 存储配置中的存 储系统都可以智能地定位任意数据分片,不需要查看索引或者向其 他服务器查询。这种设计机制完全并行化了数据访问,实现了真正 的线性性能扩展。  弹性卷管理:数据储存在逻辑卷中,逻辑卷可以从虚拟化的物理存 24 储池进行独立逻辑划分而得到。存储服务器可以在线进行增加和移 除,不会导致应用中断。逻辑卷可以在所有配置服务器中增长和缩 减,可以在不同服务器迁移进行容量均衡,或者增加和移除系统, 这些操作都可在线进行。文件系统配置更改也可以实时在线进行并 应用,从而可以适应工作负载条件变化或在线性能调优。  完全软件实现(Software Only):分布式文件系统认为存储是软件问 题,不能够把用户局限于使用特定的供应商或硬件配置来解决。分 布式文件系统采用开放式设计,广泛支持工业标准的存储、网络和 计算机设备,而非与定制化的专用硬件设备捆绑。对于商业客户, 分布式文件系统可以以虚拟装置的形式交付,也可以与虚拟机容器 打包,或者是公有云中部署的映像。开源社区中,分布式文件系统 被大量部署在基于廉价闲置硬件的各种操作系统上,构成集中统一 的虚拟存储资源池。简而言之,分布式文件系统是开放的全软件实 现,完全独立于硬件和操作系统。  完整的存储操作系统栈(Complete Storage Operating System Stack:分 布式文件系统不仅提供了一个分布式文件系统,而且还提供了许多 其他重要的分布式功能,比如分布式内存管理、I/O 调度、软 RAID 和自我修复等。分布式文件系统汲取了微内核架构的经验教训,借 鉴了 GNU/Hurd 操作系统的设计思想,在用户空间实现了完整的存 储操作系统栈。  用户空间实现(User Space):与传统的文件系统不同,分布式文件系 统在用户空间实现,这使得其安装和升级特别简便。另外,这也极 25 大降低了普通用户基于源码修改分布式文件系统的门槛,仅仅需要 通用的 C 程序设计技能,而不需要特别的内核编程经验。  模块化堆栈式架构(Modular Stackable Architecture):分布式文件系统 采用模块化、堆栈式的架构,可通过灵活的配置支持高度定制化的 应用环境,比如大文件存储、海量小文件存储、分布式文件系统、 多传输协议应用等。每个功能以模块形式实现,然后以积木方式进 行简单的组合,即可实现复杂的功能。比如,Replicate 模块可实现 RAID1,Stripe 模块可实现 RAID0,通过两者的组合可实现 RAID10 和 RAID01,同时获得高性能和高可靠性。  原始数据格式存储(Data Stored in Native Formats):分布式文件系统 以原始数据格式(如 EXT3、EXT4、XFS、ZFS)储存数据,并实现 多种数据自动修复机制。因此,系统极具弹性,即使离线情形下文 件也可以通过其他标准工具进行访问。如果用户需要从分布式文件 系统中迁移数据,不需要作任何修改仍然可以完全使用这些数据。  无元数据服务设计(No Metadata with the Elastic Hash Algorithm):对 Scale-Out 存储系统而言,最大的挑战之一就是记录数据逻辑与物理 位置的映像关系,即数据元数据,可能还包括诸如属性和访问权限 等信息。传统分布式存储系统使用集中式或分布式元数据服务来维 护元数据,集中式元数据服务会导致单点故障和性能瓶颈问题,而 分布式元数据服务存在性能负载和元数据同步一致性问题。特别是 对于海量小文件的应用,元数据问题是个非常大的挑战。分布式文 件系统独特地采用无元数据服务的设计,取而代之使用算法来定位 26 文件,元数据和数据没有分离而是一起存储。集群中的所有存储系 统服务器都可以智能地对文件数据分片进行定位,仅仅根据文件名 和路径并运用算法即可,而不需要查询索引或者其他服务器。这使 得数据访问完全并行化,从而实现真正的线性性能扩展。无元数据 服务器极大提高了分布式文件系统的性能、可靠性和稳定性。  基于标准协议:分布式文件系统存储服务支持 NFS, CIFS, HTTP, FTP 以及分布式文件系统原生协议,完全与 POSIX 标准兼容。 (5) 分布式文件系统技术及性能指标:  支持设备数量:最大百万台以上  支持存储容量:最大 1024PB 以上  客户端的数量:最大支持上亿并发  网络支持:以太网:1Gbps、10Gbps/INFINIBAND:10Gbps、40Gbps  文件副本数量:任意(缺省 1 份)  协议: NFS/CIFS/HTTP/FTP/WEB DAV,及原生协议,兼容 POSIX 标准  支持文件数量:最大上亿个文件  最大单个文件:16TB (6) S2DFS 与 HDFS 的比较 对比项 HDFS(GFS) S2DFS 架构类型 带元数据库中心架构 (瓶颈及故障易发生点) 全分布式去中心架构 存在方式 分布式文件系统软件,基于 x86 平台 使用方式 CLI/REST API NATIVE CLIENT/CIFS/NFS 标准 协议 27 (应用代码与平台无关性,便于移 植和维护) 系统可用性 低 高 数据可用性 复制 类 RAID 数据定位方式 INode Hash 同步方式 异步 同步 负载均衡 自动 自动 支持网络 千兆以太网 千兆/万兆以太网,IB 网 网络写:读(万兆/单流) 约 100MB/s:160MB/s 约 800MB/s:1000MB/s 读(1*20GB)(万兆) 约 125s 约 25s 写(1*20GB)(万兆) 约 200s 约 20s 读/写(千兆) 差距不大 2.3.2 分布式并行计算技术 (1) 概述 并行计算技术真正将传统运算转化为并行运算,从而更加充分的利用广泛部 署的普通计算资源实现大规模的运算和应用的目的,在此基础上为第三方开发者 提供通用平台,为客户提供并行服务。这里主要为门户网站提供作业调度平台, 实现日志分析,性能优化,全文检索,视频处理,用为分析等等的支撑平台。 用户通过统一计算平台把任务分派给系统内的多个节点,调度节点资源执行 任务,发挥多核并行处理优势,提升运算效率,充分运用网络内的计算资源达到 解决大规模计算问题的目的。 28 (2) 分布式并行计算架构图 分布式并行计算架构图 (3) 作业调度及计算过程 (4) 分布式并行计算技术特点  池化资源管理 利用池化技术,任何一台联在互联网上的普通 PC 机从硬件到软件, 29 可通过池化技术加入服务器池中,等待任务分配,系统能充分利用现 有服务器资源,将所有运算子任务分配给节点服务器,有效避免计 算资源闲置现象的发生。  无中心系统架构 在平台管理下的单节点能力一致,使节点在部署上和使用上具备无 差别性,任一节点功能可由其他节点替代或强化,可以最大程度确 保平台资源使用的灵活性以及在灾备环境下的可靠性系统架构。 30  通道式工作机制 平台为用户提供一个并行任务处理通道,处理过程对用户来说完全 透明,由平台自动进行负载均衡、资源匹配、任务传输等,使用户 专注于自身任务管理,将执行过程交由平台完成。 31 2.3.3 分布式数据库技术 D2B 是一个具有高性能的高性能,可扩展,无模式,面向文档 (document-oriented)的数据库,其内存储的是一种 JSON-like 结构化数据的分布式 数据库软件,尤其具有高扩展性和高可靠性,支持大表水平折分,以及分区镜像。 提供内存缓存数据,所以数据存取速度非常快,主要是由于它处理写入的方式: 它们存储在内存中,然后通过后台线程写入磁盘。 该软件支持的数据结构非常松散,是类似 json 的 bjson 格式,因此可以存储 比较复杂的数据类型。D2B 另外的最大的特点是他支持的查询语言非常强大,其 语法有点类似于面向对象的查询语言,几乎可以实现类似关系数据库单表查询的 绝大部分功能,而且还支持对数据建立索引。它的特点是高性能、易部署、易使 用,存储数据非常方便。 主要功能特性:  面向集合存储,易存储对象类型的数据 “面向集合”(Collenction-Oriented),意思是数据被分组存储在数据集 中,被称为一个集合(Collenction)。每个 集合在数据库中都有一个唯一 的标识名,并且可以包含无限数目的文档。集合的概念类似关系型数据 库( RDBMS)里的表(table),不同的是它不需要定义任何模式(schema)。  模式自由 模式自由(schema-free),意味着对于存储在 D2B 数据库中的文件,我们 不需要知道它的任何结构定义。如果需要的话,你完全可以把不同结构 的文件存储在同一个数据库里。 32  自动分片以支持云级别的伸缩性:自动分片功能支持水平的数据库集群, 可动态添加额外的机器。  支持动态查询  支持完全索引,包含内部对象。  自动处理碎片,以支持云计算层次的扩展性。  可通过网络访问  可用于 Windows®、Mac OS X、Linux® 和 Solaris 的官方二进制版本。  可用于 C、C#、C++、Haskell、Java™、JavaScript、Perl、PHP、Python、 Ruby 和 Scala 的官方驱动程序,以及广泛可用于其他语言的社区支持 的驱动程序。  Ad-hoc JavaScript 查询让您能够使用基于任何文档属性的任何条件来查 找数据。这些查询对应于 SQL 查询的功能,使 SQL 开发人员能够很 直观地编写 D2B 查询。  支持查询中的正则表达式。  D2B 查询结果存储在提供过滤、聚合和排序等一系列功能的游标中,包 括 limit()、skip()、 sort()、count()、 distinct() 和 group()等等高级特性。  高级聚合的 map/reduce 实现。  类似于 RDBMS 的属性索引支持,可以直接在文档的选定属性上创建索 引。  使用提示、解释计划和分析的查询优化特性。  类似于 MySQL 的主/从复制,支持复制和故障恢复。  基于集合的对象存储,在需要规范化数据时允许参考查询。 33  通过自动分片功能水平扩展。  高性能无争用并发机制的即时更新。 D2B 服务端可运行在 Linux、Windows 或 OS X 平台,支持 32 位和 64 位应 用。推荐运行在 64 位平台,因为 D2B 在 32 位模式运行时支持的最大文件尺寸 为 2GB。 分布式数据库(D2B) 集群示例图 D2B 与关系型数据库的逻辑结构对比: D2B 关系型数据库 34 数据库(database) 数据库(database) 集合(collection) 表(table) 文档(document) 行(row) D2B 的性能指标: 10 亿 约 600GB 以上(与每条记录大小有关系,这 里的数据:1Kb/条) 写(1 亿,无索引) 约 15000-20000 条/s 写(1 亿,有索引) 约 10000 条/s 写(1 亿:Replica Sets + Sharding 模式) 约 6000-8000 条/s 读(1 亿) 约 80MB-120MB/s 读(1 亿) 8000-10000 个查询/s 统计一个值(10 亿) <3s(复杂查询) 最大节点数量 >1024(理论上) 测试环境的硬件配置:Intel Xeon E7-8837 2 路 16 核心,256GB 内存,15k SAS 16*600GB 硬盘,RAID50;总共 12 台设备;D2B 的架构模式:Replica Sets + Sharding。 2.3.4 负载均衡 这里选择的国产设备是北京太一星晨信息技术有限公司的设备作为参考对 比设备。(http://t1networks.com) 1) 国产硬件与 F5 对比 35 对比项 国产 F5 主要功能 负载均衡算法 支持 8 种 支持 12 种 是 会话保持算法 支持 6 种 支持 8 种 是 健康检查算法 支持 14 种 支持 28 种 是 内容交换 支持最常用 4 种 支持(特性丰富) 是 高速缓存、内容压缩 支持 支持(通过增加 license) 否 TCP 复用 支持 支持 是 TCP 单边加速 是 是 否 可编程脚本扩展 支持(基本) 支持(特性丰富) 否 智能 DNS 支持(授权控制) 支持(购买 GTM 授权) 是 ISP 路由 支持 支持(通过 Irules 实现) 是 动态就近性 支持 否 是 全局负载 是 是 否 WEB 安全 支持 7 层防火墙 支持 WEB 应用安全(需购买额外模块) 否 IPv6 是 是 否 组网 主主、主备、旁路、三角传输 主主、主备、旁路、三角传输 是 价格 服务器负载、链路负载、全局负载、SSL 卸载、HTTP 压缩、 内容缓存、安全。所有功能都可以在一台设备中实现,少部 分高级功能通过授权控制。用户购买 T-Force3600 链路负载+ 服务器负载+三年基本服务=20W(T-Torce1600:9 万) 服务器负载、链路负载(单独设备)、全局负载(单独设备)、 SSL 卸载、HTTP 压缩、内容缓存、安全。所有功能可以在一 台设备中实现。大部分功能需要授权控制。但链路负载、全 局负载是单独设备。对于链路负载常用的“智能 DNS”功能, 必须购买全局负载才包含。如果所有功能一起使用,价格非 常昂贵。用户购买 F5 BIG-IP4000S 服务器负载+链路负载+三 年基本服务=90W 2) 国产硬件与 F5 性能比较 36 产品型号 L4 新建 吞吐 接口 备注 BIG-IP2200S BIG-IP4000S 150K 5Gbps(L4/L7) 10Gbps(L4/L7) 8 电(可选光口),可扩展 2 万兆 3000 系列,L4 新建 300K,L4 吞吐 18Gbps, L7 吞吐 10Gbps,高于同档次 F5,接口规格、 性能优势明显 T-Force3600 T-Force3950 300K 默认 5Gbps(L4/L7) L4 最高扩展 18Gbps L7 最高扩展 10Gbps 8 电(具备一个扩展槽,可扩展 8 电、8 光、 4 光 4 电、2 万兆、4 万兆) 3) 硬件与软件负载均衡比较 基于硬件的方式 优点 能够直接通过智能交换机实现,处理能力更强,而且与系统无关,负载性能强更适用于一大堆 设备、大访问量、简单应用 缺点 成本高,除设备价格高昂,而且配置冗余.很难想象后面服务器做一个集群,但最关键的负 载均衡服务器却是单点配置;无法有效掌握服务器及应用状态. 硬件负载均衡,一般都不管实际系统与应用的状态,而只是从网络层来判断,所以有时候系 统处理能力已经不行了,但网络可能还来 得及反应(这种情况非常典型,比如应用服务器后 面内存已经占用很多,但还没有彻底不行,如果网络传输量不大就未必在网络层能反映出来) 基于软件的方式(Nginx/HAProxy) 优点 基于系统与应用的负载均衡,能够更好地根据系统与应用的状况来分配负载。这对于复杂应 用是很重要的性价比高,实际上如果几台服务器,用F5之类的硬件产品显得有些浪费,而用 软件就要合算得多,因为服务器同时还可以跑应用做集群等。 缺点 负载能力受服务器本身性能的影响,性能越好,负载能力越大。 37 综述 1) 基于硬件的负载均衡在电信、金融行业用的非常多,而基于软件的负载均衡在互联网行业用的非常多,比如3大门户网站,6 大电商网站。 2) 由于负载均衡器本身不需要对数据进行处理,性能瓶颈更多的是在于后台服务器,通常采用软负载均衡器已非常够用,且其商 业友好的软件源码授权使得我们可以非常灵活的设计,无逢的和我们管理系统平台相结合。 3) LVS/HAProxy/Nginx每秒钟的吞吐量一般在为1万-3万之间,选择软件的构建方式:需要2台高性能设备作主备集群,费用在6 万人民币左右。 所以,CC 云数据采集中心的中前期,我们建议采用 Nginx(或者 HAproxy)作为负载均衡的支撑软件,或者与国产负载均衡硬件 设备混合使用。 38 4) 开源负载均衡(反向代理)软件对比 LVS Nginx HAProxy LVS(Linux Virtual Server)可以实 现Linux平台下的负载均衡, 提供 了含有三种IP负载均衡技术的IP 虚拟服务器软件IPVS、基于内容请 求分发的内核Layer-7交换机 KTCPVS和集群等功能 Nginx是一款轻量级、高可用性的 Web服务软件及反向代理软件,基 于HTTP(第七层)应用代理服务 器。在国内大型的互联网公司都有 使用。 HAProxy是一款提供高可用性的 基于TCP(第四层)和HTTP(第 七层)应用的代理软件。在国内大 型的互联网公司都有使用。 1、抗负载能力强、是工作在网络4 层之上仅作分发之用,没有流量的 产生,这个特点也决定了它在负载 均衡软件里的性能最强的; 2、配置性比较低,这是一个缺点 也是一个优点,因为没有可太多配 置的东西,所以并不需要太多接 触,大大减少了人为出错的几率; 3、工作稳定,自身有完整的双机 热备方案,如LVS+Keepalived和 LVS+Heartbeat; 4、无流量,保证了均衡器IO的性 能不会收到大流量的影响; 5、软件本身不支持正则处理,不 能做动静分离; 1、工作在网络的7层之上,可以针 对http应用做一些分流的策略,比 如针对域名、目录结构,它的正则 规则比HAProxy更为强大和灵活; 2、Nginx对网络的依赖非常小,理 论上能ping通就就能进行负载功 能; 3、Nginx安装、配置、维护比较简 单; 4、可以承担高的负载压力且稳定, 一般能支撑超过几万次的并发量; 5、Nginx可以通过端口检测到服务 器内部的故障,不支持url来检测; 6、Nginx也可作为Web反向加速缓 存器; 1、能够补充Nginx的一些缺点比如 Session的保持,Cookie的引导等工 作; 2、HAProxy对网络的依赖非常小, 理论上能ping通就就能进行负载 功能; 3、它跟LVS一样,本身仅仅就只 是一款负载均衡软件;单纯从效率 上来讲HAProxy更会比Nginx有更 出色,在并发处理上也是优于 Nginx; 4、HAProxy安装、配置、维护比 较简单; 5、可以承担高的负载压力且稳定, 一般能支撑超过几万次的并发量; 建议用 Nginx(或者 HAProxy)作为负载均衡(反向代理)软件配合硬件负 载均衡使用。究竟选择 Nginx 还是 HAProxy 要看团队对这两种软件的熟悉程度, 越熟悉,就能容易掌控,减少风险,我们团队对 Nginx 非常熟悉,所以,这里我 们推荐用 Nginx 作为软件的反向代理工具。 39 2.3.5 数据采集 1) 概述 数据采集功能主要完成海量智能终端的数据(台标、log 等等)采集、上传。 数据采集的来源有: IPP 客户端、浏览器、智能电视、智能空调、智能冰箱、 智能日电采集上来的用户基本数据、终端“传感器”数据、web 数据采集、用户 EPG 数据等。根据特定的通信解析协议对来自不同终端,不同应用,不同类型 的数据进行收集,并提供统一的数据采集方式,方便后台数据集成、数据存储。 数据采集结构图: 数据采集主要是由智能终端发起,通过 HTTP 协议和 Restful 技术把数据上 传并缓存在 WEB 及消息服务器上,WEB 及消息服务器可以缓存一周的数据上传 量,数据上传后,再由消息处理服务进程(MPS)进程完成数据的最终清洗及格 式,并最终入库存储。台标等非结构化数据存储在分布式文件系统(S2DFS)中, log 或者行为等结构化数据存储在分布式数据库(MongonDB)中。参见如下数 据采集/存储流程图: 40 MQ/WEB/APP服务器 智能终端 智能终端 分布式消息平台 防火墙 负载均衡 (旁路模式) 数据:HTTP (台标/行为) 数据:HTTP (台标/行为) 数据:HTTP (台标/行为) 负载信号 负载信号 数据:HTTP (台标/行为) S2DFS/MongoDB 数据:Native Client (台标/行为) MPS:Queue自动扫描 Queue Data DMQ 是一个分布式的消息服务平台,提供的功能包括:配置维护、名字服 务、分布式同步、组服务等,能提供一种高性能、可靠的、可扩展的、分布式的、 可配置关键特性,DMQ 的核心技术特点:  大容量堆内存和高可用性:假设你有 100 台服务器, 并且每个节点有 2GB 的空间用于复制缓存,最终你获得的总数据量的大小为 200GB, 每台服务器仅仅是一个拷贝。相反,借助于分布式复制架构,可获得 100GB 的备份虚拟堆内存,并且在网格中的任何位置都能访问。如果 某台服务器崩溃了, 网格只需要简单地创建一份丢失数据的新副本, 并将它们放到另一台服务器上。应用也无需再借助于一个巨大的独立 数据库来获取数据以追求最大性能的 - 这是 80%以上的企业应用中 的瓶颈所在!  扩展性:由于数据是均匀分布的,所以除了考虑到网络上的组通讯, 根本就没有必要来限制网格的大小 - 网络上的组通讯只要能够发现 一个新的节点即可. 所有的数据获取方式都是通过点对点通信,即节 41 点之间直接进行通信,非常容易控制。 DMQ 的增加或者减少不需要 关闭整个服务。 简单的添加删除集群中的机器不会引发任何服务中 断。  数据分布:DMQ 使用一致性哈希算法来决定集群中键值的存储位置。 一致性哈希算法成本低,速度快并且最重要的是不需要额外的元数据 或者网络通信就能确定键值的位置。 数据分布的目的是为了在集群 环境下保持足够的状态副本以使其具备可持续性和容错性,但是又不 会有过多的副本而阻碍 DMQ 的可扩展性。  原子性:一个 Update 操作不是成功就是失败,不会有第三种状态出现。  顺序性:在一个 DMQ 集群中,其中一台 DMQ 服务器上的消息 a 在 消息 b 之前发布,那么在所有的 DMQ 服务器上的消息 a 都会在消息 b 之前被发布,DMQ 会保持一致顺序。  实时性:对于每个 Client,DMQ 集群中的所有服务器都会保持实时更 新制度,使得所有的服务视图都会是最新的。  分布式统一镜像:Client 无论连接到集群中的哪一个 DMQ 集群节点 服务,都是得到同样的镜像视图。  可靠性:数据在内存中缓存了 2 份,任何一台计算机故障,都不会造 成数据的丢失。 2) 分布式消息管理架构图: 42 智能终端 智能终端 智能终端 Server2【主】 (数据) 智能终端 智能终端 数据网 (电信、移动、联通) 智能终端智能终端 智能终端 Server1【备】 (数据) Server3【备】 (数据) Server4【备】 (数据) 心跳/同步 MPS1 MPS2 MPS3 MPS4 MPS5 MPS6 MPS7 MPS8 MPS9 MPS10 MPS 统一的数据视图 DMQ 有以下几种关键较色,每类较色的职责如下表格描述? 角色名称 职责 领导者(Leader) 就是DMQ集群的老大,它不接受Client的请求,是管理其他DMQ服务 的,只负责进行投票的发起和决议,最终更新状态. 追随者(Follower) 追随者(Follower)的上司是领导者(Leader),参与领导者(Leader) 发起的投票,向下是面向客户端的交互,用于接收客户端的请求和反 馈客户端的结果。参与领导者(Leader)发起的投票。 观察者(Observer) 观察者可以接收客户端连接,将写请求转发给领导者(Leader)节点。 但是Observer不参加投票过程,只是同步领导者(Leader)的状态。 Observer为系统扩展提供了一种方法。 43 DMQ 的核心是原子广播,这个机制保证了各个 Server 之间的同步,有两种模 式,它们分别是恢复模式和广播模式。 恢复模式:一般是在服务刚启动或者在领导者(Leader)崩溃后,开始进入 恢复模式,此时先就会开始选举领导者(Leader),当领导者(Leader)被选举出 来,并且追随者(Follower)完成了和当前领导者(Leader)的状态及数据同步以 后,恢复模式就结束了。 广播模式:恢复模式结束后,即领导者(Leader)已经和追随者(Follower) 进行了状态同步以后,他就可以开始广播消息了,即进入广播状态。 3) 分布式消息数据架构图: 44 上图的 MM(Messages Manager):消息数据管理者。通过嵌入式 nosql 内核完 成上百万并发量的缓存数据来提供异步发布和订阅。应用程序通过 JDBC/REST/Memcached 等符合业界标准接口完成集群中的消息缓存数据的操作, 集群成员之间也通过该接口完成成员之间的数据同步,状探测步。 4) 典型分布式消息平台比较: 由于常见的RabbitMQ、ActiveMQ和ZeroMQ消息中间件不具备分布式功能, 所以不在比较之列。CC 数据采集中心面对的是百万/千万级以上的智能终端的高 并发海量数据上传,所以分布式消息平台必须在‘数据接收数据缓存数据发 布’整个过程保证数据的高性能吞吐、高可靠性、高扩展性、可维护性等属性。 45 注:*越多速速越快。 2.3.6 开放平台 比较项 DMQ Kafka 动态扩展 支持 需要第三方软件 负载均衡 缺省支持 需要第三方软件 故障检测 内置 heartbeat 需要第三方软件 拓扑架构 复制,分布式 复制 数据分区 有(hash) 有 数据存储方式 分布式内存缓存/硬盘存储 本地硬盘存储 分布式复制集 支持(内存/硬盘两两镜像) 不支持 实现语言 JAVA(维护支持方便) Scala(需要重新学习) 高并发下的性能 ***** ** 开放平台是企业通过公开应用程序编程接口(API)等方式更好地整合并利 用外部资源。平台商将服务打包成统一的、可识别的接口并开放出去,以使得第 三方的服务以相应形式接入到平台之上,第三方开发者为平台提供产品和服务的 同时能够与平台共享各种资源。 在开放平台的分类上,可根据如下维度进行分类:开放层级以及开放技术。  根据开放层级划分,开放平台主要分为四层,即“硬件”层、系统层、 业务层和应用层。其中,业务层开放和应用层开放是更加贴近互联网层 面的开放方式。  根据开放技术划分,可将开放平台划分为五种类型:OpenAPI 型开放平 46 台、插件式开放平台、综合型开放平台、应用超市型开放平台和基础服 务型开放平台(云计算平台)。 开放平台需要具备以下原则:  安全性: ◎ 用户数据安全性,如应用授权管理; ◎ 应用身份安全;  稳定性: ◎ 平台架构稳定; ◎ 海量访问稳定运营及快速响应;  易用性: ◎ 开发者学习成本低; ◎ 易查错; CC 的开放平台面向第三方应用开发者,提供 API 接口和相关开发环境。软 件开发者可通过平台 API 来获取智能家电的信息,以及智能家电的控制信息,镜 像电商网站的用户信息(卖方和卖方用户信息,私有信息需要授权)、商品信息 (商品的名称、类目、型号、介绍等信息)、商品类目信息(商品索引及分类明 细)、店铺信息、交易明细信息(在取得用户授权的情况下,查询每笔交易的详 细情况)、商品管理(商品的上传、编辑、修改等接口)等信息,并建立相应的 电子商务应用。 开放平台(Changhong Open Platform,简称 COP)是 CC 智能家电+电子商 务服务的重要开放途径,它将推动、定制、创新、进化, 并最终促成新商业文明 生态圈。开放平台的使命是把各种智能家电以及电商的商品、用户、交易、物流 47 等等基础服务,像水、电、煤一样输送给有需要的商家、开发者、社区媒体和各 行各业。 Linux集群 安全管理 资源管理 集 群 部 署 集 群 监 控 分布式文件系统 分布式数据库 作业调度 弹性计算服务 开放存储服务 开放数据服务 云服务引擎(API) 智能家电管控 电商搜索服务 其他云服务 CC 开放平台(COP)架构图 48 2.4 部署方案 1. 硬件配置表 序号 名称 配置 部署软件 数量 1. 存储及计 算服务器 1. 2U机架服务器;Intel Xeon E5-2620 2*CPU:12核心; 128GB ECC服务器内存 条;10k 2*300GB SAS硬盘 做系统盘,RAID1;Intel 千 兆网口 4*Gb NIC;SATA3 企业级硬盘 8*3TB:RAID10做数据盘 (保证高性能、高可靠性 的同时,单台有效空间为 12TB);冗余电源; 2. 主要用来存储非结构化和 结构化数据:日志、行为 记录;图片、视频、文档、 网页等文件、索引等记录; 部署备份数据也可以存储 在该存储集群上。 3. 存储1年的200万终端的数 据量,加上网爬1年的电商 数据,约85TB,作镜像模 式,则需约170TB存储空 间; 4. 前后2两个执行项目共计 投入16台存储服务器:总 192TB(镜像后:96TB) 1. 操作系统:RHEL 6.5 x64 或者 CentOS 6.5 x64(该类设备上都 要部署) 2. 分布式文件系统:S2DFS(该 类设备上都要部署) 3. 数据计算服务进程:DCS(该 类设备上都要部署) 4. 作业调度服务进程:JSS (部 署在其中 2 台设备上,主/备) 5. 自动清理服务进程:ACS(部 署在其中 2 台设备上,主/备) 6. 作业自动生成进程:JGS (部 署在其中 2 台设备上,主/备) 7. 分布式数据库:D2B(该类设 备上都要部署) 10 2. WEB 及消 息服务器 1. 2U机架服务器;Intel Xeon E5-2620 2*CPU:12核心; 128GB ECC服务器内存 条;Intel 千兆网口 4*Gb NIC;SATA3 企业级SATA 硬盘 2*4TB:RAID1;冗余 电源; 2. 主要用来部署WEB/APP 软件,部署分布式消息软 件平台,缓存上传上来的 采集数据和网络爬虫数 据; 1. 操作系统:RHEL 6.5 x64 或者 CentOS 6.5 x64(该类设备上都 要部署) 2. 分布式消息平台:DMQ(该类 设备上都要部署); 3. WEB 及应用服务中间价: Tomcat 或者 JBOSS(该类设备 上都要部署) 4. 消息处理服务进程:MPS(该 类设备上都要部署) 5. 实时流数据处理进程:SDS(该 类设备上都要部署) 6 49 3. 负载均衡 服务器 1. 机架服务器;Intel Xeon E5-2620 1*CPU:6 核心; 64GB ECC 服 务器内存 条;Intel 千兆网口 2*Gb NIC;SAS 硬盘 10K:2*300GB:RAID1;冗余 电源; 1. 操作系统:RHEL 6.5 x64 或者 CentOS 6.5 x64(2 台设备上都 要部署) 2. Nginx 1.4.5 x64 for Linux(该类 设备上都要部署) 4 4. 华为全千 兆交换机 产品型号 S5700-52C-PWR-SI 产品类型 千兆以太网 应用层级 三层 背板带宽 256Gbps 包转发率 132Mpps 传输方式 存储转发方式 接口类型 48 个 10/100/1000Base-T,上行支持 4 ×1000Base-X SFP,2×10GE SFP+,4×10GE SFP+插卡 接口数目 52 口 传输速率 10M/100M/1000Mbps 扩展插槽 4 堆叠支持 可堆叠 1U 机架式 2 5. 标准图腾 机柜 42U服务器机柜:600mm宽 *1000mm深*2000mm高,内含4个 风扇、10块托盘。 4 6. 线材、工 具、其他 材料等等 安普超5类双绞线、作线工具、 管材等等 若干 2. 软件配置表 序号 名称 配置描述 部署硬件 数量 用途 1. S2DFS 分布式文件系统 存储及计算服务器 10 用来存储非结构 化和结构化数据, 比如:视频、图片、 文档等富媒体文 件 2. JSS 作业调度服务进程 存储及计算服务器 2 作业(任务)的调 度程序,是计算任 务的发起者和调 度者 3. DCS 数据计算服务进程 存储及计算服务器 10 作业(任务)的具 体负责计算的程 序,接受 JSS 的分 配任务,处理任 务,比如:图片特 50 征批评,视频的分 析等等 4. JGS 作业自动生成进程 存储及计算服务器 2 作业(任务)的自 动生成,主要用来 生成固定规则的 任务,比如台标数 据清理任务 5. ACS 自动清理服务进程 存储及计算服务器 2 自动定时清除没 有利用价值的历 史数据,垃圾数据 6. MPS 消息处理服务进程 WEB 及消息服务器 6 获取分布式消息 队列中的数据,并 对获取的数据进 行既定规则的业 务处理,最后把数 据存储在 S2DFS 或者 D2B 中 7. SDS 实时流数据处理服务进程 WEB 及消息服务器 6 能够实时持续的 完成流式数据的 计算处理,具有实 时性,低延迟特 点,与批计算相对 应 8. D2B 分布式数据库(开源) 分布式数据库服务器 10 分布式 noSQL 数 据库,完成海量结 构化数据的存储, 具有容量大,分布 式,易扩展,性能 好的特点 2.5 实施计划 数据中心 IaaS 设施(软件、硬件)到位并部署工作安排,下面表格是实施 计划的主要交付节点: 序号 工作内容 时间 1. 实施启动 2014-2-25 前 2. 采购硬件(服务器、阵列柜、交换机、其他) 2014-3-5 前 3. 部署并联调硬件(安装操作系统)及局域网网络, 包括外接三线光纤网络 2014-3-10 前 4. 部署并联调PostgreSQL 9.3 x64 for Linux 、 Apache&Tomcat 7.0 2014-3-15 前 51 5. 部署并联调分布式文件系统(S2DFS)、部署分布 式数据库(D2B)、分布式消息(DMQ) 2014-3-31前 52 3 大数据计算平台 3.1 需求概述 摇立购应用,这个项目暂定为 200W 个终端,激活用户数位 200W*20%,并 发量为 5W。项目涉及的数据有 6 大电商的 5 类主要商品的信息,包括图片、连 接、价格等信息,每三十天进行覆盖更新,这些数据存储在数据中心,方便数据 共享。此项目还涉及海量图片的搜索与特征值匹配。初步估计数据量在 60TB-100TB 之间,由于数据量很大,需要配置大容量分布式存储空间,需要分布 式文件系统和分布式数据库支撑。 智能推荐应用,此项目跟智能电视终端密切相关,并与用户同时开机量、同 时在线使用数有关,所以并发量暂定为 10W。网络爬虫爬取的影视节目信息存储 在数据中心,此数据量跟用户收视记录相关,只爬取收视记录中涉及的影视节目。 同时,需要对清洗后的收视记录和计算好的推荐结果进行存储,但是这些数据不 放在数据中心。此项目之后会做成实时计算,需要用到流式计算的相关计算和调 度。计算量很大,可以多部署 DCS 进程,提高计算并发度,作业调度也要采用 分部署调度架构。 收视率应用,初步估计并发量为 1W。 3.2 总体设计 云数据采集中心与大数据计算平台的关系是,云数据采集中心提供存储和计 算资源,通过 API 的方式访问资源,大数据计算平台主要实现核心算法,包括图 像匹配算法,挖掘算法,智能推荐算法,知识学习算法等等,也能够通过 API 53 的方式建立收视率统计应用、智能推荐应用、拍立购应用等等。大数据计算平台 的需要的数据:包括智能终端上报的、网上实时爬取得、二次计算分析而获取的 等等,都通过通用接口存储在云数据采集中心的分布式存储平台中(分布式文件 系统(S2DFS)、分布式数据库(D2B))。计算时候,通过接口发起作业,由云 数据采集中心的作业调度服务进程(JSS)负责调度,由数据计算服务进程(DCS) 负责计算处理,并把结果反馈给大数据计算平台的各个应用。请参考下面的图例: 根据2.3.2小节对 S2DFS分布式文件系统的详细介绍,本章节就不重复叙述, 由于要增加新的存储设备,对于新设备上安装分布式文件系统是否继续选用 S2DFS 还是 HDFS,我们需要回答以下几个问题: 第一,预算增加及扩展问题:要部署 HDFS,还得单独购买两台高性能设备 作为 HDFS 的元数据库服务器(注:两台设备,构成主备;配置不能 比我们现在选择的设备配置差,不然就会成为瓶颈,如果差了,数据 节点就扩展不了几台。)。 第二,学习成本及进度问题:要使用 HDFS,必须熟悉它的 API,以及后面 带来的整个 HDFS 集群部署维护等工作,这个与可利用的团队资源相 冲突;S2DFS 提供标准的 POSIX 协议接口,应用程序代码不需作任 何改变就可以执行。如果采用 HDFS,为了保证应用系统的透明,那 么统一接口的底层必须要写两种代码,第一是对面 S2DFS,第二是面 对 HDFS。新增加了开发、维护、测试的时间。 第三,空间浪费及孤岛问题:S2DFS 与 HDFS 是两套不同体系的文件系统, 他们之间设备及存储空间是不能共用的,后面增加的 6 台设备在 2 副 54 本情况下,可以利用 3 台,3 台的存储空间是(如果采用低性能的 RAID5:21TB)63TB。前面部署的 10 台设备通过对原始数据处理压缩 后,存储空间还有多余。二者构成了孤岛,同时造成空间浪费。 第四,应用场景问题:HDFS 对存储网页等文件比较友好,毕竟它的基因就 是为互联网搜索而开发出来的,但是 CC 的应用场景很杂,要涉及到 网页,文本处理,也要涉及到图片、视频等搜索,HDFS 对大尺寸视 频文件,图像文件的性能就不能很好的适应。 所以,我们认为,CC 在“大数据计算平台”新部署 HDFS 在当前阶段来说 不很适合。 55 存储设备 网络设备 服务器设备 S2DFSD2B PostgreSQL Nginx CentOS 6.5 x64 Apache Tomcat DMQ JSS DCS JGSMPSSDS 收视率统计 智能推荐拍立购 开放 平台 资源及监控管理 第三方应用 API 资源及权利权限 …... CentOS 6.5 x64 挖掘算法 API 数据挖掘 分布式计算 调 用 云 数 据 中 心 API 大数据计算平台架构图 56 智能终端 智能终端 智能终端 …… 数据公共网 联通/电信/移动 骨 干 网 防火墙 存储/计算服务器 存储/计算服务器 存储/计算服务器 WEB及消息服务器 WEB及消息服务器 …… 作业调度 服务器(主) 作业调度 服务器(备) 收视率统计应 用 智能推荐应用 拍立购应用 …… 开放平台应用 负载均衡服务器 负载均衡服务器 …… 分布式数据库 服务器 分布式数据库 服务器分布式数据库 服务器 …… FC SAN 光纤 光纤 应用数据库 服务器(主) 应用数据库 服务器(备) 大数据计算平台网络图 57 3.3 应用建设 今后我们会在这次“云数据采集中心的平台”上构建以下几大应用:数据采 集、收视率统计、智能推荐、拍立购、开放平台。以下会对几大应用的核心架构 及功能加以详细的描述。 3.3.1 收视率统计 可对一段时间内数字电视的某个频道的某个节目进行人次收视率或收视时 长收视率进行统计。支持饼图、柱状图等形式的统计报表;  支持对数字电视收视率统计。  支持实时上报数据的查看,包括 IC 卡 ID、频道名称、频道 ID、收看开 始时间、收看结束时间,观看时长(秒)、GW2IP 地址。  支持频道管理。 ◎ 支持修改、删除、增加、查看频道 ID、频道名称。 ◎ 支持导入该频道下节目 EPG 信息。 ◎ 支持按频道 ID、频道名称、索引、导入文件的名称单项或组合查询 已添加频道。  支持节目管理。 ◎ 支持修改、删除、增加、查看节目名称、频道 ID、开始时间、结束 时间和栏目名称。 ◎ 支持批量导入多个频道下所有节目的 EPG 信息。 ◎ 支持按名称、频道 ID、开始时间单项或组合查询已添加节目。 58  节目收视率统计 ◎ 支持查询设定时间段内数字电视某频道下某节目的收视记录情况, 收视记录情况包括本时间段内某节目的频道归属、收视人次、人次 收视率、收视总时长、收视时长收视率和本节目的开始、结束时间 等信息。 ◎ 支持以饼图、柱状图的形式统计数字电视设定时间段内某频道所有 节目收视时长收视率和人次收视率。  频道收视率统计 ◎ 支持以人次或收视时长的升序、降序排序方式查询设定时间段内数 字电视某频道的收视记录情况,收视记录情况包括本时间段内某频 道的频道 ID、频道名称、收视总人次、人次收视率、收视总时长、 收视时长收视率信息。 ◎ 支持查询结果以 EXCEL 的格式导出。 ◎ 支持以多频道饼图或多频道柱状图的形式统计设定时间段内数字电 视所有频道收视时长收视率和人次收视率。 ◎ 支持以单频道折现图的形式统计数字电视设定时间段内某频道收视 时长收视率或人次收视率随时间的变化。  收视率统计报表 59 节目人次收视率饼图 多频道人次收视率饼图 60 人次收视率变化折现图 3.3.2 智能推荐 现有交互技术,用户不能快速定位感兴趣的视频节目,用户不能“随心看”, 也不知道“今晚看啥”,或者喜欢已看节目的同类节目,但是还要进行搜索,花 时间,很麻烦,还是找不到自己希望的节目。基于这种原因,CC 通过收集海量 用户行为数据,通过推荐算法,把观众想看的节目推荐给终端用户,提高用户的 体验。目标是通过建立基于视频数据挖掘的用户兴趣模型,实现视频内容的个性 化推荐服务系统。 数据采集的来源有: IPP 客户端、浏览器、智能电视、智能空调、智能冰箱、 智能日电采集上来的用户基本数据、终端“传感器”数据、web 数据采集、用户 EPG 数据等。 61 智能推荐应用架构图 智能推荐系统流程图 62 实现功能:  数据采集 ◎ 这个功能请参考功能应用章节的第一小节“数据采集”内容。  构建知识库: ◎ 通过第三方数据源扩充媒体大数据,为了精细化分析用户的兴趣爱 好,需要扩充电视直播、点播数据和 IPP 平台的 EPG 数据,增加视 频的显性内容; ◎ 构建影视内容知识库:通过分类、聚类、关联规则算法,实现影视 内容知识库构建; ◎ 构建领域知识库:在影视知识库的基础上,分析视频内容的隐性关 联数据,实现用户性格领域的知识库构建。  内容关联元数据定义 ◎ 视频节目特征向量={节目名称,播放时间,导演,主演,年份……}。 视频节目 名称 播放时间 导演 主演 出版年份 名字 国籍 性别 关联元数据定义示例图  用户兴趣度权重定义 ◎ 基于视频内容的兴趣度权重定义:对用户观看的视频节目进行聚类 分析,根据用户观看不同类型的节目的总次数和连续看某类视频的 63 次数,确定用户兴趣度。 ◎ 基于用户行为的兴趣度权重定义:对用户观看视频节目时的行为信 息进行分析,得到用户对单一视频节目的兴趣度。  用户兴趣模型呈现 ◎ 构建“用户-兴趣类别-兴趣特征”三级管理模式。 张三 兴趣类1 电影类 兴趣类3 兴趣类i 动作片,0.2,0 爱情片,0.1,0 兴趣i,权值i,遗 忘因子i 用户兴趣模型呈现示例图  推荐内容智能推送 ◎ 通过大数据平台+智能推荐算法的集成,可以实时的把用户感兴趣的 节目内容推送到用户智能终端上,并在 UI 上显示出来:内容链接、 内容简介、内容图片等等呈现给用户。 3.3.3 拍立购 随着移动业务和 3G 网络的快速发展,搜索功能已经成为第一大移动应用, 智能设备的普及使得图片搜索功能的需求快速增长。传统的商品搜索通常通过采 用关键词搜索技术进行商品信息整合展示,现实世界大量的都是图像数据,特别 电子商务平台上的商品展示全部是图像文件。 本应用采用大规模分布式爬虫收集主流电子商务网站中商品信息和对应图 64 片,建立自己的索引库,通过对海量图片数据的压缩、噪声过滤、特征识别、基 于内容的图像搜索技术,给用户提供一种“即拍即搜”的新体验。同时还利用文 本挖掘、关联规则等技术对商品品牌、型号等进行实体提取,优化搜索结果,提 升用户体验。系统推广后,即能实现商品在信息残缺情况下的比价搜索,又能充 分切合用户日益增长的移动购物需求,极大提高用户购物体验,有效促进电子商 务的快速发展。 拍立购主要用智能手机非常优秀的体验能力完成与电商平台的交互,智能手 机也可以与智能电视交互,获取电视屏幕图像,他们都可以通过基于图像特征值 和语义描述信息获取商品信息,完成商品采购。当然,也可以通过分类检索、全 文检索、类别查询等等传统检索方式获取商品信息。后面这种检索方式没有前面 的基于图像特征值和语义检索的方式友好。 65 数据网 (电信/联通/移动) WEB/APP 资源管理 数据存储 数据计算 防火墙 负载均衡 图像搜索 智能推荐 拍立购架构图 为了满足用户通过图片匹配进行图像搜索,用户即拍即搜即买,极大地提高 了用户体验。拍立购手机端是功能示意图以下所示: 66 手机客户端主页以及选择图片页 裁剪照片页和搜索结果页 67 商品详情页及流量引导 图像搜索流程图: 68 Native Client 1.2:建立新作业 (WEB SERVICE) 3.3:分配数据处理作业(TCP/IP) 6.3:数据处理作业结束(TCP/IP) DCS (数据计算服务 ) 2:获取未分配处理作业 (WEB SERVICE) WEB及DB Server WEB及DB Server 1.1提交计算作业 (应用客户端) DCS (数据计算服务1) DSC (数据计算服务2) Native Client Native Client 3.2:分配数据处理作业(TCP/IP) 6.2:数据处理作业结束(TCP/IP) 3.1:分配数据处理作业(TCP/IP) 6.1:数据处理作业结束(TCP/IP) 7:更新作业状态:结束 (WEB SERVICE) JSS (作业调度服务) 5.3:建立搜索 结果索引 5.2:建立搜索 结果索引 5.1:建立搜索 结果索引 4.1:特征匹配 4.2:特征匹配 4.3:特征匹配 S2DFS/MongoDB S2DFS/MongoDB S2DFS/MongoDB S2DFS/MongoDB S2DFS/MongoDB S2DFS/MongoDB 69 3.4 部署方案 1. 硬件配置表 序号 名称 配置 部署软件 数量 1. 存储及计 算服务器 1. 2U机架服务器;Intel Xeon E5-2620 2*CPU:12核心; 128GB ECC服务器内存条; 10k 2*300GB SAS硬盘做系 统盘,RAID1;Intel 千兆网口 4*Gb NIC;SATA3 企业级硬 盘 8*3TB:RAID10做数据盘 (保证高性能、高可靠性的 同时,单台有效空间为 12TB);冗余电源; 2. 主要用来存储非结构化和结 构化数据:日志、行为记录; 图片、视频、文档、网页等 文件、索引等记录;部署备 份数据也可以存储在该存储 集群上。 3. 存储1年的200万终端的数据 量,加上网爬1年的电商数 据,约85TB,作镜像模式, 则需约170TB存储空间; 4. 前后2两个执行项目共计投 入16台存储服务器:总192TB (镜像后:96TB) 1. 操作系统:RHEL 6.5 x64 或 者 CentOS 6.5 x64(该类设备 上都要部署) 2. 分布式文件系统:S2DFS(该 类设备上都要部署) 3. 数据计算服务进程:DCS(该 类设备上都要部署) 4. 作业调度服务进程:JSS (部 署在其中 2 台设备上,主/ 备) 5. 自动清理服务进程:ACS(部 署在其中 2 台设备上,主/ 备) 6. 作业自动生成进程:JGS (部 署在其中 2 台设备上,主/ 备) 7. 分布式数据库:D2B(该类 设备上都要部署) 6(增加 并共用) 2. WEB 及消 息服务器 1. 2U机架服务器;Intel Xeon E5-2620 2*CPU:12核心; 128GB ECC服务器内存条; Intel 千兆网口 4*Gb NIC; SATA3 企业级SATA硬盘 2*4TB:RAID1;冗余电源; 2. 主要用来部署WEB/APP软 件,部署分布式消息软件平 台,缓存上传上来的采集数 据和网络爬虫数据; 1. 操作系统:RHEL 6.5 x64 或 者 CentOS 6.5 x64(该类设备 上都要部署) 2. 分布式消息平台:DMQ(该 类设备上都要部署); 3. WEB 及应用服务中间价: Tomcat 或者 JBOSS(该类设 备上都要部署) 4. 消息处理服务进程:MPS(该 类设备上都要部署) 5. 实时流数据处理进程:SDS (该类设备上都要部署) 4(增加 并独立 部署) 3. 应用数据 库服务器 1. 机架服务器;Xeon E5-2620 2*CPU:12核心;64GB ECC服 务器内存条;Intel 千兆网口 2*Gb NIC;1*Qlogic 1. 操作系统:RHEL 6.5 x64 或 者 CentOS 6.5 x64(该类设备 上都要部署) 2. PostgreSQL 9.3 x64 for Linux 2 70 QLA2562F双通道 8GB HBA 卡;SAS硬盘 10K:2*600GB:RAID1;冗余电 源; (该类设备上都要部署) 3. WEB 及应用服务器:Tomcat 或者 JBOSS(该类设备上都 要部署) 4. 应用数据 库光纤柜 2U机架式12盘位光纤存储柜,双 控;4个8Gb FC主机接口,1个6Gb SAS扩展口;4TB*12 SATA3企业级 硬盘,RAID6;双冗余电源风扇; 配置2个8GB SFP+模块,2根5米 LC-LC光纤线;支持 UNIX/LINUX/WINDOWS等主 流的操作系统及VMware等虚拟机 应用;模块化且关键部件均支持热 插拔;高可用支持:Multi-path & load-balancing 支持; 1 5. 华为全千 兆交换机 产品型号 S5700-52C-PWR-SI 产品类型 千兆以太网 应用层级 三层 背板带宽 256Gbps 包转发率 132Mpps 传输方式 存储转发方式 接口类型 48 个 10/100/1000Base-T,上行支持 4× 1000Base-X SFP,2×10GE SFP+, 4×10GE SFP+插卡 接口数目 52 口 传输速率 10M/100M/1000Mbps 扩展插槽 4 堆叠支持 可堆叠 1(增加 并共用) 6. 标准图腾 机柜 42U服务器机柜:600mm宽 *1000mm深*2000mm高,内含4个风 扇、10块托盘。 4(共用) 7. 线材、工 具、其他 材料等等 安普超5类双绞线、作线工具、管 材等等 若干 2. 软件配置表 序号 名称 配置描述 部署硬件 数量 用途 1. S2DFS 分布式文件系统 存储及计算服务器 6(增加 并共用) 用来存储非结构 化和结构化数据, 比如:视频、图片、 文档等富媒体文 件 2. JSS 作业调度服务进程 存储及计算服务器 2(共 作业(任务)的调 71 用) 度程序,是计算任 务的发起者和调 度者 3. DCS 数据计算服务进程 存储及计算服务器 6(增加 并共 用) 作业(任务)的具 体负责计算的程 序,接受 JSS 的分 配任务,处理任 务,比如:图片特 征批评,视频的分 析等等 4. MPS 消息处理服务进程 WEB 及消息服务器 4(增加 并独立 部署) 获取分布式消息 队列中的数据,并 对获取的数据进 行既定规则的业 务处理,最后把数 据存储在 S2DFS 或者 D2B 中 5. JGS 作业自动生成进程 存储及计算服务器 2(共 用) 作业(任务)的自 动生成,主要用来 生成固定规则的 任务,比如台标数 据清理任务 6. ACS 自动清理服务进程 存储及计算服务器 2(共 用) 自动定时清除没 有利用价值的历 史数据,垃圾数据 7. SDS 实时流数据处理服务进程 WEB 及消息服务器 4(增加 并独立 部署) 能够实时持续的 完成流式数据的 计算处理,具有实 时性,低延迟特 点,与批计算相对 应 8. D2B 分布式数据库(开源) 分布式数据库服务器 6(增加 并共 用) 分布式 noSQL 数 据库,完成海量结 构化数据的存储, 具有容量大,分布 式,易扩展,性能 好的特点 备注: 共用:表示“大数据计算平台”共用“云数据采集中心”的设备(统一部署)。 增加:表示由于“大数据计算平台”的顺利上线,需要新增若干同类的设备。 72 3.5 实施计划 序号 工作内容 时间 1. 收视率和智能推荐应用正式上线 2014-4-30 前 2. 摇立购应用正式上线运营 2014-6-30 前 3. 大数据开放平台: 正式上线验证(第一期开放接口 发布) 2014-10-31 前 4. 大数据开放平台: 正式上线验证(第二期开放接口 发布) 2014-12-31 前 73 4 性能及成本分析 根据需求,我们最高并发数要达到 20 万/s。智能家电上传的采集数据大小 为 40Kbps(这里没包括网络爬虫的数据),计算出 1 万并发情况下,需要 400Mbps 网络带宽。 4.1 运营商网络性能分析 并发数量 总带宽 单价 合计 备注 1 万并发 400Mbps 5 万元/100Mbps 20 万元/年 双线:40 万元/年 10 万并发 4Gbps(4 个 Gbps) 50 万元/Gbps 200 万元/年 双线:400 万元/年 20 万并发 8Gbps(8 个 Gbps) 50 万元/Gbps 400 万元/年 双线:800 万元/年 注:以上价格为市场询价得出,最后成交价可能低于或者高于他。如果是双线,还得在 最后成本合计项乘以 2。另外,上面的计算是理想值,没考虑网络自身的数据头(包),以 及掉包重传,或者丢掉的情况,以及网络延迟等等情况(可以乘以 80%为最后结果参考值)。 4.2 服务器网卡性能分析 每台设备 4 个千兆网口,设置为 bond0,总网络带宽为 4Gbps,可以支持 10 万的并发。6 台 WEB/消息服务器可以支持 60 万的并发,10 台存储/计算服务器 可以支持 100 万的并发;如果去掉网络冲突或者掉包,乘以 60%70%。那么 6 台 WEB/消息服务器可以支持约 36 万42 万的并发,10 台存储/计算服务器可 以支持约 60 万70 万的并发。由于多台服务器构成了集群,网卡性能上完全可 以达到 30 万的并发数请求。 4.2 服务器内存性能分析 每台WEB/消息服务器内存是128GB,用 20GB的空间来缓存队列数据,20GB 内存空间可以满足每秒约 250 万并发(单台设备)的数据写入,所以按照现有的 74 内存配置,不会成为瓶颈,大容量内存可以为今后海量的数据查询用作缓存数据 用,提高查询性能。 4.3 服务器硬盘性能分析 WEB/消息服务器配置的是两块 4TB 硬盘,构建 RAID1,4TB 的硬盘 IO 带 宽在 140MB/s 以上,如果采集的数据直接写硬盘,单台 WEB/消息服务器可以 满足 2.8 万/s 并发写以上,6 台设备可以至少满足 10 万/s 以上的并发写入。存储 /计算服务器集群的设备配置 8*3TB 硬盘,构成 RAID10,IO 带宽约在 400MB/s-600MB/s 以上,单台存储/计算服务器可以满足 7 万/s-10 万/s并发以上, 16 台设备(RAID10 模式)可以同时满足 100 万/s 的并发以上写入。在网卡、内 存、硬盘三者的性能中,硬盘的性能最低,解决办法是“缓存在内存中,批量写 入硬盘”策略。由于 DMQ 和 D2B 都具备内存缓存功能,所以可以避免大并发 数的而带来的硬盘性能瓶颈问题。 4.4 服务器 RAID 模式分析 RAID 级 RAID-5 RAID-50 RAID-10 容错性 有 有 有 冗余类型 奇偶位 奇偶位 复制 热备盘选项 有 有 有 需要磁盘数 三个或更多 6,8,10,12,14,16 至少需要 4 块盘,偶数个盘 可用容量 n-1 的总磁盘容量。 其中 n 为磁盘数 n-2 的磁盘容量。 其中 n 为磁盘数 n/2 磁盘容量。 其中 n 为磁盘数 恢复速度 ** (计算 后恢 复,很 慢) ** (计算后恢复,很慢) **** (直接复制,很快) 可靠性级别 允许一 个驱 动器出 故障。 实现 RAID 50 后,每 个 RAID 5 集中允许 一个驱动器 出故障。 允许有多个驱动器出现故 障,但不允许一个RAID 1(镜 像)集同时失去两个驱动 器。 75 读取速度 (随机/连续) ****/*** ****/*** ****/**** 写入速度 (随机/连续) **/*** ***/*** ****/*** 注:*越多,表示速度越快。 通过上表的分析结果(选择主流的 RAID 构建模式作对比分析),以及 CC 应用场景(分布式文件系统、分布式数据库混合安装,前期的小尺寸文件(记录) 占主要数量),保证数据库可靠性的前提,需要同时考虑 1-2 年的存储容量和计 算性能,所以这里推荐使用 RAID10 模式构建磁盘组。 4.5D2B 性能分析 10 亿 约 600GB 以上(与每条记录大小有关系, 这里的数据:≤1Kb/条) 写(1 亿,无索引) 约 15000-20000 条/s 写(1 亿,有索引) 约 10000 条/s 写(1 亿:Replica Sets + Sharding 模式) 约 6000-8000 条/s 读(1 亿) 约 80MB-120MB/s 读(1 亿) 8000-10000 个查询/s 统计一个值(10 亿) <3s(复杂查询) 最大节点数量 >1024(理论上) 测试环境的硬件配置:Intel Xeon E7-8837 2 路 16 核心,256GB 内存,15k SAS 16*600GB 硬盘,RAID50;总共 12 台设备;D2B 的架构模式:Replica Sets + Sharding。 4.4DMQ 平台性能分析 DMQ 和 Tomcat 需要集成在一起,因为最终是看 Tomcat+DMQ 整体性能。 具体实现方法是通过 REST 方式调用 API,完成数据写入到 DMQ 平台中,DMQ 76 平台的 MQ 部分全内存缓存,定时批量刷 MQ 内存数据到 MQ 的硬盘文件上。 Tomcat+DMQ 的载体是 6 台 WEB/消息服务器,配置见“部署方案”一节。 通过在虚拟机和实际生产系统中的验证及测试,采用 DMQ 为全内存缓存, 批量定时刷硬盘。实测环境中的配置是:志强 E5 系列 CPU 4 核、64GB 内存、4 个 Tomcat 实例(内存约占 30 多 GB\CPU 约占 80%多),能够处理的并发数量共约 为 15000 次/s。如果在本方案中的 128GB、12 核 CPU(24 线程)的配置情况下开启 10 个 Tomcat 进程实例,可以近似推出 12 核心 CPU(24 线程)大约能够处理 3 万/s 多点并发数,那么 6 台 WEB/消息服务器总共能够处理约 18 万/s 多点并发 数,接近 CC 定的 20 万/s 的并发数目标,如果同时考虑外接运营商网络带宽及 成本的情况下,以及“大数据计算平台”等内部应用的压力情况下,所以暂时建 议部署 6 台 WEB/消息服务器设备。 5 存储空间规划表 由于 S2DFS 与 D2B 是统一安装在同一集群平台中,它们二者对处理数据方 式完全不一样,分布式文件系统侧重于 IO 带宽,分布式数据库侧重于 IOPS,所 以要考虑二者的综合读/写性能,也要考虑数据的可靠性。通过前面“4.4 服务器 RAID 模式分析”小节的分析,这里推荐用 RAID10 模式,在取得了性能和可靠 性之间的平衡的同时,又能满足 2014 的业务应用的存储空间的要求。 项目投资存储空间规划表 项目 2014 年存储容量 存贮服务器数量及主要配置 模式 结构化数 据 非结构化数 据 容量小 计 数据采集中心 10 台设备(SATA3):8*3T RAID10/S2DFS(D2B) 100GB 45TB ≈45TB 77 大数据计算平 台 6 台设备(SATA3):8*3T RAID10/S2DFS(D2B) 10TB 30TB 40TB 合计 ≈10TB 75TB ≈85TB 建议 2015,2016 年的存储/计算空间的规划等到 2014 年下半年开始执行,因 为通过实际运行后,我们掌握了大量的真实存储规模和计算规模等具体信息,再 结合 CC 公司的总体战略目标、业务应用目标等,作进一步的规划,这样规划出 来的方案符合实际情况。 6 机房选型 一个完整的云数据采集中心机房需要解决以下几个问题:  如何保障数据安全,业务连续性,打造自动化 7×24 全天候无人值守 的计算环境;  面临的设备快速增长,管理维护压力日益严重,亟需有效便捷的统 一管理。  面临着众多新型病毒和安全隐患的威胁,对提供优质服务造成了巨 大影响。  一个高等级云数据采集中心机房本身的建设、维护等面临的成本问 题。 要解决以上问题,我们首先得采购核心设备:油机,UPS,变压器,高低配 电柜,接地防雷等,另外还有空调,消防,排水,照明,装修,综合布线,安防 等附加必须设备,所以按照一个中等规模的云数据采集中心建设,至少需要投入 3000 万-5000 万资金。还不包括平时大量的电费和维护费。 78 所以,建议 CC 的云数据采集中心可以先租用电信或者万国数据等的成熟的 高等级机房,为了保证一定时期的设备扩容,建议机房租用在绵阳或者成都的成 熟数据数据中心。而自己只关注自身的核心业务,使其顺利上线。在后面如果随 着设备量的大量增加,通过成本评估后,在决定是否自己建设数据中心。 7 安全设计 云数据采集中心的安全分为两大部分,一个是应用数据的安全,一个是平台 运行的安全。 如果租用成熟的 IDC 机房,那么机房本身的安全就可以不管,防火,安防, 门禁等统统可以忽略,外接的路由器和防火墙也可以不采购。 1) 平台安全 平台本身的运行安全我们采用分布式集群技术完成,每个业务处理群都是以 集群方式存在,保证冗余度,每个集群中服务进程都是主/主、主/备方式运行, 承载设备都保证在 2 台以上。按照此设计思路,方案划分了存储/计算服务器集 群(共 8 台设备)、WEB/消息服务器集群(共 4 台设备)、应用数据服务器集群 (共两台设备),负载均衡服务器集群(共 2 台设备),专门的数据备份服务器设 备。 2) 数据安全 应用数据的安全采用实时或者定时备份方式完成,备份设备可以在一定时期 内把数据备份到专门的数据备份服务器上,试实际情况而定,也可以采用己构建 的分布式文件系统(S2DFS)来完成数据的存储备份。当然最好是构建异地灾备 79 平台,把数据同步到绵阳或者其他地方的数据中心中同样以分布式文件系统 (S2DFS)为主备份存储设备。 先期方案我们建议把数据备份到数据备份服务器上,存储在分布式文件系统 (S2DFS)由于数据量大,容量大,不建议再做备份,因为分布式文件系统(S2DFS) 可以建立 RAID1 架构模式。我们会把分布式数据库(D2B)除了架构构建为 Master-Slave、Replica Sets 模式外,另外通过 BackUp/Restore 工具完成数据备份及 恢复,第一次完成冷备份,后面我们就可以通过增量备份方式完成。参考下面的 备份及恢复架构: 3) 备份策略 80 一个好的备份恢复系统,除了配备有好的软硬件之外,更需要有良好的备份 策略进行保证。对于备份系统,必须根据各种应用和业务的处理类型来分别制定 具体的备份策略。 对于备份系统备份策略的规划,建议按照以下流程进行: 1)将数据备份任务按业务系统划分,确定各系统的备份数据量,并为每个 备份任务指定专用的介质集; 2)根据各业务系统对备份的需求,以及系统的忙闲程度,为每个备份任务 划定可以进行数据备份的时段。 3)合理的选择备份方式。备份的最终目的是为了进行数据恢复,在选择备 份方式时,要在业务系统性能需求许可的情况下,最大程度的降低数据恢复时的 复杂程度。建议: 对于数据量较大的系统,为降低数据备份对业务系统运行的影响,减少对备 份介质的需求,可采用全备份+增量备份的方式进行,建议每周进行一次全备, 一周内其他时间每天进行一次增量备份; 对于数据量较小的备份任务,或较为关键的业务,则建议每天进行一次全备 份,以降低恢复时的复杂程度; 在每次业务数据做大调整后应立即做一次全备份; 4)在确定以上内容后,对普通备份任务的调度策略进行统一规划: 对于相关业务系统的数据,为保证数据一致性,尽量安排在同一天进行备份; 首先保证关键业务的数据备份; 81 尽量使备份数量在一周内的每天平均分布,可以采用大小数据量相搭配,或 关键业务与非关键业务相搭配等方式进行; 5)根据业务需要确认备份介质保存周期。如无特殊需求,则保存周期的设 置应以保证每一 次全备份完成以前,都有可用介质供数据恢复使用为准。 下表给出了一个备份策略定制的示例: 星期一 星期二 星期三 星期四 星期五 星期六 星期日 备份任务组一 F I I I I I I 备份任务组二 I F I I I I I 备份任务组三 I I F I I I I 备份任务组四 I I I F I I I 备份任务组五 I I I I F I I 备份任务组六 I I I I I F I 备份任务组七 I I I I I I F …… 备注:F=Full Backup,即完全备份;I=Incremental Backup,即增量备份;具 体策略根据用户的要求来定。 8 风险分析 序号 风险内容 严重程度 应对办法 1. 能否在公司规定的较短时间内完成公司这次 要求建设的内容:IaaS 平台建设,包括软件硬 件平台的构建? 高 采用成熟的经过验证 的方案,包括在生产 环境中已经验证的核 心软件平台。 2. 负责该项目的设计和实施的团队是否能够很 快的掌握涉及到的核心技术(分布式文件系 统、分布式数据库、作业调度及并行计算等 等)? 高 与熟悉这些核心技术 的团队合作,保证在 公司规定的期限内完 成该项目。 82
还剩81页未读

继续阅读

下载pdf到电脑,查找使用更方便

pdf的实际排版效果,会与网站的显示效果略有不同!!

需要 10 金币 [ 分享pdf获得金币 ] 2 人已下载

下载pdf

pdf贡献者

guet_lee

贡献于2017-01-12

下载需要 10 金币 [金币充值 ]
亲,您也可以通过 分享原创pdf 来获得金币奖励!
下载pdf