分布式计算平台（精选7篇）
分布式计算平台 篇1
1 引言
中国制造业历经多年的信息化建设,国内的工业企业在各类信息系统中存储了大量数据,这些系统包括OA、HR、CRM、MES等。这些系统帮助企业优化资源配置、减化业务流程,极大地提升了企业的经营管理水平。伴随着数据的快速增长及新需求的不断涌现,原有系统越来越难以满足要求,如何将分散在各个系统中的数据整合起来,充分发挥数据对生产的指导作用,提升效率,优化生产流程,优化经营效率,己成为中国制造业的新挑战。
随着大数据技术在互联网行业中蓬勃发展,涌现了大量大数据处理框架,如Hadoop、Spark、Storm等,如何选择并整合各大数据处理框架,在其上开发、运行、维护处理海量数据的应用程序,成为制造业企业IT部门新的挑战和难题。分布式实时分析计算平台就是为了解决这一问题,帮助企业技术人员可以轻松架构,搭建适用于自身业务形态的分布式实时计算应用。
2 关键技术
本文提到的分布式实时计算平台,选择了多个优秀的开源构件作为平台的基础构件。整个技术平台自下而上主要包括:分布式文件系统层、分布式数据库、分布式数据分析、数据展示等基础功能模块。针对各个基础功能模块的功能要求及特点,筛选优秀开源构件,主要选择了以下开源构件。
2.1 Hadoop
Hadoop实现了一个分布式文件系统,为海量数据提供分布式存储。在此之上,Hadoop提供了Map Reduce分布式计算框架。该框架通过Map和Reduce两个步骤并行处理大规模的数据集。首先,Map会对由很多独立元素组成的逻辑列表中的每个元素执行指定的操作,原始表不会被更改,其会创建多个新的列表来保存Map的处理结果,这也意味着Map过程会产生大量的新数据,有大量的写磁盘操作。Map工作完成之后,会对新生成的多个列表进行shuffle和排序,之后完成Reduce操作。Map Reduce框架的最大不足在于,对于需多次迭代的复杂计算,会产生大量的中间结果,需频繁读写HDFS,无法满足实时应用的需求。
2.2 Hbase
Hbase是运行在Hadoop上的分布式、面向列的No Sql数据库,它是一个分布式可扩展的大数据仓库。它提供高可靠、高性能、列存储、可伸缩、实时读写的数据库系统,主要用来存储非结构化和半结构化的松散数据。它很好地融合了key/value存储模式带来的实时查询能力,以及通过Map Reduce进行离线处理或批处理能力。
2.3 Spark
Spark是开源的类Hadoop Map Reduce的通用并行框架,拥有Hadoop Map Reduce所具有的优点,但与Map Reduce不同的是,Job中间输出结果可以保存在内存中,从而不再需要读写HDFS,因此Spark能更好地适用于需要多次迭代Map Reduce的算法。相比Map Reduce,Spark在做重复计算时可以重复使用相关的缓存数据,无需不断地读写磁盘。
2.4 ANTLR
ANTLR是一款强大的语言识别工具,提供框架通过语法描述来构造语言识别器、编绎器和解释器。通过解析用户自定义的上下文无关描述语言,自动生成词法分析器、语法分析器和树分析器。
3 分布式工业数据实时分析计算平台
3.1 基本架构
本文中的分布式工业数据实时分析计算平台底层基于Hadoop、Hbase、Spark等构件。Hadoop为平台提供了分布式存储HDFS,在此之上是Hbase分布式No Sql数据库,由它组织和管理用户数据表。选用分布式实时计算框架Spark作为计算平台的基础计算框架。由yarn负责整个平台的系统资源调配。
计算平台主要包括Job Server、FCS(Function Compulation Service)、RESTful API等模块。Job Server负责与yarn协调申请资源,为特定应用启动单独的计算服务,管理各计算服务的计算任务。Job Server对外提供RESTful接口。FCS提供UI,供用户编排计算任务,并根据用户计划执行计算任务。平台架构如图1所示。
3.2 Job Server
Job Server主要由Context Manager、Job Manager、RDD Manager等子功能模块组成,对外提供RESTful API,用户可通过浏览器查看Job信息,如图2所示。
●Context Manager:为客户端应用管理应用上下文,每个应用可根据需求启动一个或多个Application Context,不同的Application Context均是独立的yarn应用,相互之间资源隔离。Application Context可分为长驻Context和一次执行Context。
●Job Manager:管理Application Context中的所有Job,包括创建Job、执行Job、保存Job处理结果,异步Job模式中,客户端可根据Job ID获取处理结果。
●RDD Manager:负责管理计算中生成的Spark RDD、客户端申请的有名RDD以及RDD缓存,方便客户端在Job之间共享RDD,以提升计算效率。
3.3 表达式计算引擎
分布式分析计算平台针对工业数据,抽取定义实现了适合工业计算的表达式计算引擎,主要有行计算和列计算两种模式。行计算对Hbase表中的记录行中各属性值执行表达式计算;列计算是纵向的,对表中某一列执行统计计算。两者间可嵌套执行。
海量数据计算中,同一表达式可能执行数以亿计的计算,如图3中所示,Expression parser(表达式解析器)对表达式进行词法以分析,并解析表达式,Expression compiler(表达式编绎器)将解析后的表达式编绎为可以直接执行的算子,RDD执行并行计算时,对每行数据提取算子中所需的列值,传输给表达式算子,多个算子运行结束后,由Result collector(计算结果收集器)收集、合并运算结果。RDD计算过程中无需重新解析表达式,极大地节约了计算时间,提升了计算效率。
3.4 FCS
FCS提供Web UI供客户端编排计算任务,可指定计算任务的执行模式,周期执行或符合条件的特定时间执行。可自定义计算表达式,并通过FCS提交计算任务至Job Server。
3.5 分布式工业数据实时分析计算平台与传统实时数据库对比
分布式工业数据实时分析计算平台与传统实时数据库对比如表1所示。由于传统实时数据库一般单机或多机冗余热备使用,对服务器的硬件要求高,且服务器数量有限,因此,存储容量最大为TB级。与之相比,分布式工业数据实时分析计算平台底层基于Hadoop,普通的服务器即可,群集支持数以千计的服务器,支持超大数据集,能存储PB级的数据,且在群集中维护多个工作数据副本,确保能够针对失败节点重新分布处理。从性能角度看,传统实时数据库由于架构简单,数据多缓存于共享内存,速度明显快于分布式工业数据实时分析计算平台,读写性能可达到十毫秒级。分布式工业数据实时分析计算平台因数据分布存取,存储最快可达到百毫秒级。可扩展性方面,分布式工业数据实时分析计算平台明显优于传统实时数据库,在可用的计算机集簇间分配数据并完成计算任务,可以方便地扩展到数以千计的节点中。而传统实时数据库可添加新节点,但节点数目到达一定规模后,对性能无提升。
4 结语
分布式工业数据实时分析计算平台为企业IT技术人员提供了一个支持分布式实时计算的开发平台,使得企业IT技术人员无需关心计算平台的底层架构,无需编写代码,仅通过FCS编排计算任务,即可快速完成业务计算的编写,进而对海量数据进行业务分析和处理。
参考文献
[1]朱江.基于云计算的数据挖掘平台架构及其关键技术研究[J].计算机光盘软件与应用,2015(19):53-56.
[2]梁九妹,卢忠田.一种基于云计算技术的实时业务服务模型[J].计算机与现代化,2013(07):160-163.
[3]王水萍,王方.一种基于云计算数据挖掘平台架构的设计与实现[J].信息安全与技术,2014(08):64-66.
[4]Michael Armbrust,Amando Fox,Rean Griffth,et al.Above the Clouds:A Berkeley View of Cloud Computing[R/OL].UC Berkeley Technical Report,UCB/EECS-2009-28,2009.http://www.eecs.berkeley.edu/Pubs/Tech Rpts/2009/EECS-2009-28.html.
分布式计算平台 篇2
随着移动互联网时代的高速发展, 海量数据的存储及处理成为当下的热门议题。分布式计算这个概念的提出, 为海量数据的处理提供了可能, 而这种全新计算框架最优秀的代表是Hadoop。Hadoop可以将海量数据存储在普通PC集群中, 利用分布式计算对海量数据做处理, 极大降低了分布式系统的成本。
二、分布式计算平台Hadoop概述
作为一个开源的分布式计算平台, Hadoop以分布式文件系统 (HDFS) 和Map Reduce计算框架为两大核心组件, 实现了系统底层透明的分布式基础架构, 具有良好的扩展性和容错性。HDFS为分布式任务提供了海量数据的存储支持, Map Reduce在集群上实现了分布式计算和任务处理, 在HDFS基础上实现了分发、跟踪和执行任务等操作, 二者相互支持, 构成了Hadoop集群的核心内容。由于对硬件的要求相对较低, Hadoop框架可以运行在廉价的PC上;HDFS的备份恢复机制协同Map Reduce的监控任务功能确保了分布式系统的可靠性;HDFS数据交互的高效实现以及Map Reduce分任务处理模式, 为海量信息的高效处理提供了有利条件。谷歌最早是为了海量数据分析提出的Map Reduce, Hadoop则最适合计算海量离线数据, 通过将数据分割于多个节点, 然后将每个节点计算的结果合并输出, 同时上一阶段的输出可以作为下一阶段计算的输入, 形成树型的计算图, 同时串、并行结合利于在分布式集群下更高效的处理数据。虽然Hadoop具有先天的优势, 但在处理小文件、实时计算等方面仍有缺陷。
三、HDFS及Map Reduce的技术分析
Map Reduce和HDFS是组成分布式计算框架Hadoop的两大核心组件。按照时间顺序, Map Reduce可以分为输入分片 (input split) 、map、combiner、shuffle和reduce五个阶段。在执行map任务之前, Map Reduce根据输入文件做分片处理, 一个分片对应一个map任务;map函数都是在本地的数据节点上操作的;combiner是一个可选阶段, 也是在本地的数据节点上执行的, 类似于reduce过程;将map的输出作为reduce的输入过程就是shuffle;reduce就是将最终计算的结果做存储。由于map和reduce的过程都需要大量的I/O操作, 使得Hadoop更适合做离线计算。
HDFS (Hadoop Distributed File System) 是以谷歌发表的有关GFS (Google File System) 论文翻版的, 它是Hadoop底层的文件存储系统, 可以支持超大文件的存储。HDFS具有高容错机制, 可以设置副本的保存数量, 在某个数据节点出现问题的时候, 可以调用其它数据节点上保存的数据块;可以部署在海量廉价的机器上, 可以大大地降低企业成本;可以处理海量数据。HDFS采用master/slave的架构模式, 主要由namenode和datanode组成。Namenode是master节点, 具有热备份功能, 负责集群的客户端的读写请求及数据映射, 即保存datanode存储的数据块的信息, 管理HDFS的副本存储和名称空间。Datanode是slave节点, 负责存储客户端发来的数据块及对数据块执行读写操作。写1T文件, 需要3T存储空间和3T流量带宽, 执行读、写过程中, 为确定数据节点活着, Master和Slave通过心跳机制保存通信。如果发现某个datanode挂掉了, 就将写入该datanode上的数据, 写入其他datanode;读取时, 相应的读其它datanode。一个datanode挂掉, 还有其他备份datanode;某一个机架断电, 其它机架上, 也有备份。
四、总结
本文介绍了新一代分布式计算平台Hadoop的框架原理, 给出了HDFS的文件存储策略及Map Reduce的计算过程, 使海量数据的存储和计算成为了可能, 同时为以后将Hadoop平台运用到各种场景打下了基础。
参考文献
[1]朱珠.基于Hadoop的海量数据处理模型研究和应用[D].北京邮电大学, 2008.
分布式计算平台 篇3
视频渲染是当前视频应用相关的核心技术之一。然而, 长期以来, 由于受到设备性能、成本等方面的限制, 如何实现大规模、高效率、高质量的视频渲染始终是一个视频处理必须面对的问题。随着云计算技术的成熟, “云渲染”作为一个全新的分布式渲染技术应用模式, 已经成为下一代视频渲染的重要技术基础。基于云计算的视频渲染服务, 将充分利用云计算的虚拟化、可伸缩、高性能计算的优势和特点, 实现海量级视频处理能力, 并支持用户依据需要的计算资源定制, 从而降低用户成本, 极大地提升视频渲染服务的效率。
传统视频渲染架构依赖于计算机或服务器集群开展, 其主要缺点如下:渲染单位以物理机为基础, 处理能力依赖于物理机本身的能力, 在物理机单机弱或物理机集群能力过于强大的前提下, 将会造成处理时间过长或物理机资源大量浪费的情况;处理机制以串行方式为主, 无法实现多个处理任务的高并行处理;渲染处理设备必须由各需求者自主建设, 无法促使处理设备的获得高度共享, 从而确保各类资源的高效利用。
针对上述问题, 本文提出了一种视频云渲染处理服务平台, 该平台引入云计算技术, 通过“基础资源服务”、“视频数据服务”、“平台服务”和“门户服务”, 实现海量视频的分布式并行云渲染, 从而全面提升视频渲染处理的工作效率。
2云渲染服务平台设计原则
云计算技术为当前高复杂度、高成本、大数据量的计算任务提供了有效的解决方案。本设计中, 为了满足云渲染的高并发、多任务、计算资源弹性分配的需求, 提出了如下设计原则。
(1) 资源虚拟化原则
云渲染服务平台中的所有资源, 包括服务器资源、网络资源、存储资源以及其他设备资源等, 均通过虚拟化技术进行管理, 使其由若干物理分散的资源虚拟化为逻辑统一的巨大资源。
(2) 平台服务原则
云渲染服务平台为各类视频渲染需求提供统一、无缝的平台接口, 并在各类接入设备之间提供服务协议和接口, 满足不同设备终端的访问、查询、展示以及任务管理相关平台需求。
(3) 按需服务原则
云渲染服务平台依据用户提出的渲染服务进行资源动态分配, 依据渲染任务的预期资源实现虚拟机的配置, 从而按用户的需要进行资源分配, 优化用户服务的成本。
(4) 多任务并行原则
云渲染服务依据用户视频渲染的实际工作流程, 利用并行计算技术, 将任务进行智能规划和分配, 保障多任务的并行渲染, 大幅提升服务效率。
3系统架构及设计
分布式视频云渲染平台的核心在于在通过统一的资源整合, 打造功能强大且弹性灵活的视频渲染服务平台, 实现视频渲染过程中依据用户、渲染任务和资源现有情况等信息的灵活调度;构建统一平台服务, 实现不同终端的接入、不同格式视频的兼容、第三方渲染器的部署等, 建设功能强大的系统平台;通过任务分配实现视频渲染的分布式、高并发处理, 大幅提升渲染效率。
依据云计算的基本提点, 我们将视频云渲染平台分为基础资源层、视频数据层、平台管理层和应用服务层。系统架构如图1所示。
3.1基础资源层
基础资源层核心在于高效率的资源整合, 完成底层计算资源服务器和存储资源设备集群, 以及各种网络接入整合, 引入虚拟化、聚合网络等技术, 形成统一的虚拟资源池, 构建整个云渲染服务平台的底层保障, 从而将单位各种物理分割、独立工作、各自为战的设备实现逻辑上的统一, 以便于优化调度。同时, 在该平台引入动态资源管理模块, 实现虚拟资源池中各类资源的弹性分配, 即依据要求分配虚拟机, 对虚拟机的使用情况进行监管, 并在虚拟机完成任务后进行资源回收, 使其回归资源池。
3.2视频数据层
视频数据层主要实现视频数据接收、清洗、格式识别、存储、管理、防灾等工作, 同时也需要完成视频渲染数据规则的定义、主数据和元数据管理等工作。主要包括视频数据存储模块、视频数据管理模块和视频数据规则模块。
(1) 视频数据存储模块
该模块负责接收来自用户提交的视频渲染数据、任务数据、中间状态数据等, 并将这些数据依据不同的格式、平台兼容性等特征进行分类存储, 并且负责完成日常数据备份, 以及故障恢复和数据防灾等工作, 实现视频渲染所需要存储和查询工作。
(2) 视频数据管理模块
该模块为视频渲染处理提供管理服务。主要包括:依据视频的格式、渲染规则等知识支持, 实现视频渲染过程必需的知识推理;视频渲染数据的日常更新、修改和维护, 保障不同视频渲染任务中数据的独立性、安全性和完整性;同时, 提供视频数据的访问提供统一的协议和接口等。
(3) 视频数据知识模块
定义视频数据的知识服务, 包括视频云渲染平台中的数据格式知识、渲染规则、处理规则、访问规则、任务规则等方面知识内容。
3.3平台服务层
平台服务层为视频云渲染服务平台提供支撑环境, 从而在底层资源、数据资源与顶层渲染应用服务之间构建一个支撑手段, 主要包括作业模块、并行调度模块、服务管理模块。
(1) 作业模块
主要包括云渲染服务所需要的作业创建、任务动态规划、资源分配、作业监管等方面功能。
(2) 并行调度模块
主要针对视频渲染处理所需要的计算环境进行管理和配置, 提供包括智能渲染任务调度、渲染环境配置、冲突检测和处理等服务, 为视频渲染处理的计算任务提供高效智能的并行计算环境, 自动配置并行计算过程, 按需配置计算资源。
(3) 服务管理模块
主要针对云计算平台中所有云渲染器、计算服务模块等提供管理能力, 包括对服务运行所需要的负载均衡、智能响应、动态扩容等服务, 对服务的接口、访问、响应、负载等进行管理, 应对访问量的突变及负载的不均衡, 保障服务效率。
(4) 第三方平台模块
提供可由第三方开发的视频渲染处理模块的部署平台, 允许第三方开发者在其上部署其符合本平台格式要求的视频处理服务, 并接受本平台的管理和调度。
3.4门户服务层
门户服务层中定义了视频云渲染处理的各类功能模块。
(1) 视频云渲染的用户管理服务
针对用户进行登录管理、资格认证、权限管理等。
(2) 视频云渲染任务处理服务
实现海量视频渲染任务的提交、确认、撤销等管理功能、渲染器定制、任务进度查询、目标管理等。
(3) 视频云渲染展示服务
通过用户定制的播放器为提供视频渲染效果的展示服务, 并支持用户自定义渲染过程中的相关参数设置等。
(4) 视频云渲染平台支持服务
提供用户在云渲染平台上的操作手册、历史记录查询、售后反馈等支持服务。
4视频云渲染处理技术
视频云渲染处理技术主要包括任务接受、资源分配、渲染处理和任务反馈四个关键环节。
4.1任务接受
如图2所示, 该环节中, 用户登录视频云渲染服务平台, 将所需要的渲染任务提交给云渲染平台。云渲染平台将依据用户身份、渲染任务描述信息、所提交视频格式等, 评估视频渲染的相关任务, 形成平台内部可接受和自动处理的任务封装;进一步, 接受用户提交的视频数据, 在平台内实现分类存储, 并将该任务提交给作业模块、资源分配模块进行处理。
4.2资源分配
该环节中, 平台依据任务相关信息进行任务分解、虚拟机配置、任务分发、运行环境配置、负载评估等工作。在该环节中, 视频渲染任务依据时间、逻辑等维度进行有序分解, 产生可并行处理的不同子任务序列;进一步, 平台依据不同子任务规划, 进行作业创建、虚拟计算单元配置、环境配置等工作;继而将各并行子任务分发到不同的计算单元中, 依据Map Reduce技术思路, 实现分布式并行渲染的环境配置。
4.3渲染处理
该环节中, 各虚拟计算单位依据子任务的渲染需要, 选择适合的处理模块对任务进行处理计算, 形成各子任务的渲染效果。
4.4任务反馈
该环节中, 任务监管模块在各子任务完成后, 对任务处理进行校验、反馈和展示等, 将最终结果反馈到用户;最后, 任务监管模块在得到用户确认任务结束后, 撤销对应生成的作业任务, 并回收各已分配的虚拟计算资源, 使其回到资源池, 等待新的资源分配。
5结束语
视频渲染是当前视频处理中非常重要的技术环节。利用云计算技术的优势提升视频处理能力, 是提升当前我国视频技术的重要关键技术基础。本文引入云计算, 提出一种基于云计算的视频渲染服务平台设计基本方法, 充分利用云计算优势, 通过构架基础资源、数据、平台和服务四个层次, 优化视频渲染过程, 致力于提升视频处理的质量和效率, 探索视频服务平台建设的创新之路。
摘要：本文提出了一种基于云计算的分布式视频渲染服务平台设计方法, 利用云计算技术实现基础资源虚拟化管理, 从而整合分散物理计算资源, 实现资源动态分配和弹性管理;同时利用云计算的并行处理能力, 实现视频渲染的任务并行渲染, 为其分配相应的虚拟计算处理单元, 达到视频渲染的效率优化。
分布式计算平台 篇4
关键词：超级计算机,分布式计算机资源共享平台,科学计算
1. 分布式计算的应用现状和发展
1.1 分布式计算的应用现状
分布式处理是大型项目的工作原则, 它将大型项目的海量数据拆分成许多相对较小的部分, 由中央服务器管理分发, 多台独立的计算机处理其中的一个或多个部分, 处理完成后把结果返回服务器并汇总分析[1]。
目前分布式计算在实际应用中大致分为三个方向。
其一, 类似与中科院的超级计算机, 通常是指由数百数千甚至更多的处理器 (机) 组成的、能计算普通PC机和服务器不能完成的大型复杂课题的计算机。如果把普通计算机的运算速度比做成人的走路速度, 那么超级计算机就达到了火箭的速度。在这样的运算速度前提下, 人们可以通过数值模拟来预测和解释以前无法实验的自然现象。"天河一号"是中国首台千万亿次超级计算机系统, 其系统峰值性能为每秒1206万亿次双精度浮点运算, Linpack测试值达到每秒563.1万亿次。"天河一号"中, 共有6144个Intel处理器和5120个AMD图像处理单元 (相当于普通电脑中的图像显示卡) 。"天河一号"将广泛应用于航天、勘探、气象、金融等众多领域, 为国内外提供超级计算服务。当然超级计算机所提供的服务是面向超大型的复杂性课题研究, 即使出的起昂贵的服务费也不一定能得到机会[2]。
其二, 是校园式的局域网机群分布式实现, 部分高等院校有一些复杂的研究课题时, 因为没有经费购置昂贵的高性能大中型计算机机, 就可以利用局域网建立分布式计算环境, 通过局域网定时开启网内的计算机, 在计算机群组并行计算的帮助下, 完成课题的运算量[3]。
其三, 是基于互联网的分布式计算平台, Sun公司很早就提出说"网络就是计算机"[4]。
随着计算机的普及, 个人电脑开始进入千家万户。与之伴随产生的是电脑的利用问题。越来越多的电脑处于闲置状态, 即使在开机状态下中央处理器的潜力也远远不能被完全利用。我们可以想象, 一台家用的计算机将大多数的时间花费在"等待"上面。即便是使用者实际使用他们的计算机时, 处理器依然是寂静的消费, 依然是不计其数的等待 (等待输入, 但实际上并没有做什么) 。
互联网的出现, 使得连接调用所有这些拥有限制计算资源的计算机系统的计算能力成为了现实。将大量个人电脑的空闲资源通过互联网连接起来, 其运算能力亦可媲美超级计算机。
1.2 分布式计算的优点
用户不必投资一台功能强大、价格昂贵的大型计算机来处理数据, 只需多台廉价的PC及网络, 辅以合适的分布式系统, 即可完成相同的工作。
对于贡献空闲资源的电脑而言, 一定程度上增加了电脑的使用率, 减少了资源的浪费。
本文讨论的解决方案旨在建立一个资源共享平台, 为有意参与分布式计算资源共享平台用户提供一个实用平台。
2. 基于Web Service的分布式计算机资源共享平台的设计
综上所述, 由于大量的个人电脑的使用率低下, 如果能够通过互联网将大量的电脑资源联系起来, 辅以合适的分布式系统, 充分利用这些大量浪费的电脑资源, 提供大规模的计算服务。那势必会得到经常参与大规模计算的用户的参与, 以期待能更高效率的进行大规模计算项目。
通过上述分析, 可以开发一个基于分布式计算的资源共享平台。用户的个人电脑链接服务器接受项目任务, 利用个人电脑空闲资源, 在不妨碍用户正常使用电脑的前提下, 进行轻量级计算。最后将计算结果通过互联网上传到服务器。由服务器统一解析, 得出最终的结果。其体系结构如图1所示。
2.1 系统主要功能设计
1.用户登陆和注册:
为新用户提供账号注册功能。为老用户提供登陆, 登陆后可进入系统。
2.个人信息管理:
为用户提供查看和修改个人基本资料信息的服务和功能, 包括客户名称、通信地址和邮编、邮箱地址、联系电话等。
3. 项目申请:
用户可以为自己的项目提出服务申请。管理员查收, 审核, 验证后, 即可使用平台提供的服务。
4. 接受项目:
平台会提供很多项目, 希望用户能够贡献自己电脑的空余资源到平台, 参与到分布式计算中来。
5. 项目管理:
用户可以管理自己电脑正在运行的项目的情况。
6. 项目查看:
用户可以查看自己申请项目的运行情况。
7. 资讯:提供一些项目的相关资讯, 以供用户参考。
8. 帮助中心:
提供网站官方帮助服务, 就网站的使用规则和操作等方面的问题向用户提供咨询。
9. 论坛:
提供用户与系统开发商的交流互动平台。系统开发商根据用户的反馈, 修改完善系统。
2.2系统关键部分的设计与实现
Web service又称之为web服务, 这是一种通过HTTP协议, 以web应用服务器为依托, 利用XML平台做交互的方式, 实现跨平台的功能。
Web服务体系结构是一种框架, 通过这个框架可以描述、发布、发现Web服务, 并且还可以在分布式计算环境中动态调用Web服务。在Web服务中, 通常定义三个角色:服务请求者、服务代理者和服务提供者。它们之间具体的关联可以通过图2所示的三种操作来描述:
1) 发布 (Publish) , 服务提供者向服务代理者发布其可提供的服务。
2) 查找 (Find) , 服务请求者执行查找操作以能满足其需要的服务。
3) 绑定 (Bind) , 服务请求者执行绑定操作以调用由服务提供者提供的服务。
基于Web Service这种web服务体系下的分布式系统可以在多种平台上实现, 从应用范围、开发成本等多方面综合比较, Windows和.NET平台无疑是十分值得考虑的。其良好的互操作性和多语言支持、使用标准的Web协议以及相对完善的安全验证技术, 结合.NET提供的丰富资源, 极大降低了分布式系统开发的门槛。
本方案的开发逻辑:
1) 建立数据库, 划分工作单元。数据库建立在远程服务器上, 整个系统的协调工作由服务器上的SQL Server数据库来完成, 包括已注册代理的清单、当前工作集清单、工作集拥有的工作单元清单等, 工作集被划分后, 将相关信息填入数据库。
2) 创建Web服务。工作在服务器上的Web服务, 为系统担任统筹安排的责任。主要用于接收代理的请求、分配工作单元、接收结果单元。
3) 建立代理并请求工作单元。首先代理不能始终占据计算机处理数据而影响用户使用, 应配置代理在计算机空闲时运行 (即让代理以较低的优先权运行) 。当代理向服务器申请工作时, 服务器将确定当前工作集, 从中选择下一个可用的、未处理的工作单元分配给代理, 并为它指定终止时间。如果代理在该时间内没有返回结果单元, 将由另一个需要工作的代理获得该单元。
4) 代理处理工作单元。
5) 返回结果单元。当一个工作单元被处理完成后, 代理将返回匹配的结果单元, 服务器经验证后保存结果, 将该工作单元标记为处理完成, 并为代理分配下一个工作单元, 直至工作集完成或代理退出。
6) 分析结果集。
对于工作集的划分, 结果单元组合为结果集, 可以开发相应的工具实现[5]。
3.结束语
分布式计算资源共享平台的建立可以适当的缓减资源浪费, 大规模计算资源紧张的现状。促进国家的科学计算的发展。同时, 借助Windows系统和DoNet平台, 基于Web Service, 以较低的代价实现了数据的分布式处理, 为快捷高效进行分布式系统开发的提供可选方案。
参考文献
[1]胡勇智, 张海军.一种基于Web Service实现分布式计算的方案[J].工程技术研究与应用, 2008, 12 (31) .
[2]封卫兵.基于CUDA的LBM方法研究[J].高性能计算发展与应用, 2009.
[3]马丽.Web Services技术研究及在数字化校园的应[J].计算机工程与应用, 2004.
[4]刘瑞挺.NDS:网络的灵魂[J].个人电脑, 1999.
分布式计算平台 篇5
随着有线数字电视整体转换工作的完成及应对三网融合提出的要求, 为提高用户粘合度和应对电信IPTV的竞争, 各地有线电视网络公司陆续开展了互动视频点播业务。
互动点播 (Video on Demand, 简称VOD) 和传统的广播式电视不同, 可以根据用户自己的意愿收看, 它打破了传统广播电视在时间、内容方面的限制, 可以在任何时间点播自己喜欢的节目, 收看过程中还可以进行快进、快退等各种操作, 提供用户完全不同于传统电视的收视体验, 其业务形态随着技术的发展和市场的需求还在逐步增加。
2 系统现状
互动点播可以划分为基于IPQAM/HFC技术和基于IPTV/LAN技术两种方式, 目前广电一般采用IPQAM/HFC方式, 而电信一般采用IPTV/LAN方式。在本文中互动点播 (VOD) 采用IPQAM/HFC方式。
基于IPQAM/HFC技术的VOD系统是建立在HFC网络架构上的根据DVB-C规范建设的系统, 是HFC网络交互电视经典的解决方案。IPQAM集“复用、加扰、调制、变频”功能于一体, 它将DVB/IP＿GBE输入的节目流重新复用在指定的MPTS中, 再进行QAM调制和频率变换, 输出RF信号。在使用IPQAM之后, STB和边缘视频服务器之间的控制信息和视频流分别通过不同的通路传输:STB的接入认证、EPG信息浏览等流程通过双向回传通道交互;边缘视频服务器收到用户的请求后将音视频流以恰当的封包形式输出至IPQAM设备, IPQAM将音视频流调制为RF信号后通过HFC网络传输给STB, STB对音视频流进行解调和解码。
在初期用户较少时, 系统采用集中模式, 将相关设备全部放置在中心机房, 与数字电视广播信号在总前端进行混频, HFC网络承载点播的视频流, 通过IPQAM调制后进行传输, 而IP城域网承载点播信令等控制信号。当点播用户规模逐步扩大后, 可以将IPQAM下移到分前端机房, VOD系统的视频流通过DWDM波分系统传送到分前端的IPQAM进行调制, 再与广播信号混合传输。随着点播用户的不断增加, 视频服务器集中于前端机房已经不能完全满足业务发展的需要, 此时采用CDN内容分发网方式, 在区域分中心机房部署边缘视频服务器, 所有的节目都在中心服务器存储, 而通过CDN网络把用户访问相对集中的内容分发到边缘服务器, 直接由边缘路由器提供用户服务。
采用IPQAM技术后, 一方面可以充分利用HFC的带宽资源以及传输特性, 向用户提供有QoS保障的视频服务, 更适合高清业务对传输网络的高下行带宽要求;另一方面降低了视频服务对IP网络的要求, 不再要求IP网络接入层提供较高的带宽, 使广电运营商可以以较低的成本实现交互视频业务。
利用IPQAM开展视频点播业务, 在美国的各大有线运营商中得到了大规模的应用, 随着国内有线网络双向业务的加快, 国内有线电视运营商也开始大量使用这种方式开展VOD业务, 比如:江苏有线按照“统一平台、统一内容”的运营模式, 建设了全省统一的互动电视点播系统, 覆盖全省的互动电视用户;后台管理系统在省中心平台, 包含视频流控制、计费信息管理、报表模块、数据库、网络管理及监控等功能;采用CDN内容分发网方式, 在苏州部署了视频服务器、页面服务器和IPQAM等设备, 热片通过苏州本地视频服务器直接播出, 冷片通过省中心的视频服务器播放。系统结构图如图1所示。
随着互动点播业务在各地的大力推广以及互动电视用户量的快速增长, 本地特色内容的业务需求不断增加, 为广大本地用户提供更加贴近本地生活的互动电视内容成为目前的重要任务。而目前互动点播系统分布式平台对本地并发流增加的支持性较好, 但是本地不能注入内容。下面以此为基础讨论几种本地内容注入的方式。
3 本地注入的几种方式
3.1 通过省中心注入本地内容
目前全省互动电视平台采用混合式部署, 用集中+分布相结合的方式实现全省内容的注入和分发, 对点播类内容的注入和分发统一在省中心进行。在省中心建立统一的点播类内容分发平台, 通过媒资系统和互动电视系统之间的标准接口, 从全省统一的内容集成平台把各类互动电视节目内容和信息集中注入互动电视平台核心存储上;然后再由核心存储根据节目的热播程度将最热播的节目内容分发到省中心以及各地分中心的视频服务器存储阵列中;各地的少量本地新闻节目由各地采集制作成媒资文件后, 通过省干线传输网以FTP或者其他方式上传到内容集成平台, 通过编目、审核后统一注入到互动电视平台。
各市县继续采用这种模式, 将需要新增加的电影、电视剧及本地戏曲等内容在本地制作、编辑后, 按照现有方式上传到内容集成平台, 由内容集成平台进行统一编目审核后统一注入, 但如果各市县都需要上传较多的节目内容量, 则内容集成平台的工作量将大大增加。
这种方式与现状完全保持一致, 系统不需要进行任何改造, 投资几乎没有, 但是需要省中心与各市县操作人员配合才能实现内容的及时发布, 各市县的自主性不够, 无法实现本地管理等功能。
3.2 建设多级分布式系统
该方案在省互动平台的现有基础上, 建设本地二级后台管理系统, 在充分利用目前互动平台的基础上, 实现本地节目的注入、本地页面的修改、本地节目的独立定价和系统的本地化管理等功能。
3.2.1 系统结构
该方式在现有互动平台基础上, 建设本地二级后台管理系统, 下移部分系统运行及管理权限, 包含页面管理、内容分发、资源调度、运行管理等功能模块。
3.2.2 系统集成
系统与目前省平台的互连如图2所示。
该方案需要在保持现有本地互动电视分布式平台正常运营的情况下, 完成新增二级后台管理系统与现省互动平台的对接, 省中心平台相应的功能模块也需要进行改造, 页面管理、内容分发、资源调度、运行管理等功能模块需要进行分级管理。相应的技术要点如下:
(1) 资源调度
本地IPQAM等资源通过本地SRM进行调度, 省中心SRM通过本地SRM对本地资源进行统一管理, 由原来一级管理调度改为二级。
(2) 内容分发
在完成本地的资产注入以后, 省网后台系统通知本地二级系统资产元数据进行发布, 本地的操作员做上片的申请操作, 根据预设的上片审核策略, 由审核人员在系统中完成本次上片的审核工作, 审核完成后, 本地二级系统自动向本地新建Portal系统进行节目的发布操作。
(3) 页面管理
需在同一页面服务器上对用户同时提供省中心提供的内容和本地注入的内容。本地新建Portal系统作为本地提供互动视频点播业务的展现, 通过与省中心平台Portal系统的对接来实现省中心平台Portal到本地新增Portal的链接跳转, 在不改变业务流程和用户体验的前提下, 保证了本地业务的顺利开展。
(4) 运行管理
需要实现省中心和本地同时对系统进行管理和维护。
这种方式在本地新增二级后台管理系统, 与现省互动平台进行对接, 可以本地管理等功能, 但是省中心平台相应的功能模块也需要进行改造, 对现有结构改动较大, 系统集成有一定工作量。
3.3 新建一套小型本地点播系统, 仅支持本地节目的用户点播
该方案新增一套小型的本地点播系统, 仅提供本地注入节目的点播和管理。系统结构与前一种方式一致, 只是规模较小, 同样需要增加视频服务器、本地存储、后台管理等系统设备 (并发流数量和存储容量规模较小) , 在充分利用目前互动平台的基础上, 实现本地付费节目的内容页面的注入和修改, 并与BOSS系统连通实现本地的认证计费, 通过本地BOSS系统与省BOSS系统连接, 实现数据报表的共享。
3.3.1 系统结构
新建系统是一个完整的点播系统, 仅提供本地注入节目的点播和管理, 系统支持的用户规模量比较小, 但是也是一个完整的点播系统, 也包含视频服务器、后台管理、互动应用、页面服务等完整的业务功能模块。
3.3.2 系统集成
系统组成及与目前省平台的互连如图3所示。
该方案需要在保持现有互动点播系统正常运营的情况下, 完成新增点播系统与现互动点播系统的对接, 新增点播系统需要和现互动点播系统共同向本地用户提供互动点播服务, 需要在两套系统之间完成页面切换、视频流切换、认证切换等, 并与本地BOSS的对接。相应的技术要点如下:
(1) Portal切换
在本地新增加Portal, 需要机顶盒在新增Portal和现有系统Portal直接自由切换。
(2) SRM切换
在本地新增加SRM系统, 这就需要机顶盒在点播本地节目和省平台节目时切换不同的SRM系统。
(3) 认证切换
将本地栏目的节目点播和定价计划由本地BOSS系统做定价策略, 省平台节目的认证和计费保持现状不变。
(4) 与BOSS对接
新增系统计费接口需要和本地BOSS进行集成, 直接访问本地AAA接口。
3.3.3 用户点播流程
(1) 用户点播某节目
用户机顶盒通过本地IP城域网访问现有互动页面, 可以通过连接切换到本地内容页面, 选择确认点播某节目。
(2) 用户认证
后台管理系统在收到用户点播请求后, 请求认证计费系统进行认证, 其中本地节目的认证由本地处理。
(3) 视频播出
用户认证通过后, 后台管理系统定位节目存储所在地。若在现有平台, 则通知现有视频服务器直接播出相应节目。若在本地新建系统, 则由本地视频服务器播出节目。
(4) 点播计费
视频播出且流控建立后, 通知计费系统对用户此次点播行为进行计费。
3.3.4 SRM对接
因为HFC网络的共享特性, 某个特定的机顶盒只能接收到来自特定的一组IPQAM端口的数据, 因此需要对服务区域有明确的规划和管理, 一般将这样的服务区域定义为Region, Region即预先定义的一组频率资源, 或者为一个IPQAM通道资源规划单元。资源管理模块 (SRM) 需要了解每个实际部署的IPQAM的资源使用情况以完成资源的分配和回收, 要求IPQAM设备提供接口供SRM完成心跳维护和状态查询, IPQAM的UDP端口和频点、节目号的映射规则应该全网统一设置, 以完成对所有资源按照统一的算法调度。
由于两套独立的互动点播系统需要共用同一组IPQAM资源, 所以本方式中SRM切换最为复杂, 可以以原有系统为主管理SRM, 向新建SRM开放接口, 两者协同进行工作, 这需要原系统开放核心接口并完成技术开发。在SRM切换没有实现前, 可以另外单独部署一套IPQAM系统, 需要另外占用频点资源, 两套系统都按最大并发流规模使用资源, 不能实现两套IPQAM、频点、骨干带宽等资源的共享, 会浪费一部分资源。
这种方式新建系统为一套小型的完整系统, 但是规模不大, 投资较小, 仅支持本地注入内容的点播并发流, 而互动点播系统规模复杂性与并发流数量并不是完全的线形关系, 并发流不大时比前一种方式大大节省投资, 可以在本地实现所有功能。但是需要进行共享IPQAM等资源, 集成比较复杂。
4 结语
分布式计算平台 篇6
本文的安全管理平台是基于信息安全的角度, 充分考虑到业务支撑系统不同主机、网络设备、应用、数据库等信息安全资产, 对网内的信息安全资产进行分级, 并实现对不同安全级别信息资产的安全告警监控。平台建成后, 可实现对业务支撑系统的设备安全监控、安全预警、以及整体系统安全状况评估, 极大地提升了业务支撑系统的安全性。
1 总体设计
1.1 系统的设计目标
整个系统采用J2EE的架构完成网络安全管理平台的研制和开发工作, 核心子系统采用UML进行建模, 实现模块化设计思想, 各个逻辑功能模块均能动态加载和独立运行, 满足未来扩展的需求。网络安全管理平台用于管理来自多种网络安全设备的安全事件, 基本的原理是对从网络安全设备上采集来的原始网络安全事件进行分类、关联、风险评估等分析处理, 通过该平台对运行在各种操作系统和硬件平台上的网络安全产品实施统一的配置、统一的策略、统一的日志和统一的报告, 以便用户进行相关的响应处理, 过程如图1所示:
1.2 系统的设计原则
系统采用目前业界流行的B/S结构, 分为客户层、控制层、业务处理层、数据访问层四层。系统主要基于Struts框架, 结合J2EE设计, 采用Oracle数据库存储数据。系统从可扩展性、高性能、系统的松耦合性、安全性等角度进行了充分的考虑。遵循的主要原则包括:系统采用面向对象设计思想, 系统遵循J2EE 2.0标准系统, 遵循SUN Java编程规范。
1.3 系统的部署方案
为了满足本项目的需求, 在业务支撑系统湖东机房局域网部署SOC管理平台, 其中包含HA工作模式的台SOC应用服务器与2台SOC数据库服务器、1台WEB服务器与1套2TB带库系统, 三台安全信息收集分析服务器, 分别部署在湖东、金山与乌山三地机房中, SOC应用服务器通过网络方式从三地安全信息收集分析服务器中获取数据。同时异常流量分析采集服务器部署在湖东, 通过NETFLOW与SNMP方式进行全网网络设备的智能关联分析, 将分析之后的数据统计提交到SOC应用服务器进行集中处理, 同时保存到SOC数据库服务器中。整体部署如图2所示。
2 网络架构设计
参照上述的部署方案, 我们可以看到架构设计从总体上可分为数据采集层、应用服务层、应用展现层 (终端显示) 3个逻辑层次, 如图3所示。
(1) 数据采集层:
根据要求采集各种安全信息。负责从已经汇总了福建移动业务支撑系统网络上的安全信息的网管和服务器上收集汇总后的安全信息。
(2) 数据处理层/应用服务层:
负责对采集到的原始数据进行聚并处理, 完成数据的智能关联分析, 为应用展示层提供数据支持。
(3) 应用展现层:
实现安全运维管理平台的统一界面展示。通过统一的图形化管理界面, 安全运维管理平台实现了安全监控、维护、管理、展示的全部功能。
2.1 数据采集层
数据采集层负责根据要求采集各种安全信息。针对福建移动业务支撑系统网络, 从福建移动业务支撑系统各个局域网上的网络设备、安全设备、服务器系统和主机系统收集汇总安全信息。
数据采集是整个安全管理的核心, 数据采集的关键是:首先要支持丰富的采集对象, 保证即插即用;其次是采用开放的架构, 方便体现环境和需求的特殊性。
本系统数据采集主要包括安全事件数据采集, 安全漏洞数据采集, 安全配置采集。其中实时采集安全事件和告警, 便于实时告警、分析和响应。采集安全漏洞数据用于主动防御和风险管理。收集各个安全产品、路由器的安全配置, 用于审计。必要时可以实现配置的一致性。
2.2 应用服务层
应用服务层负责对采集到的原始数据进行分析处理。将从不同来源采集到的数据进行关联分析, 为应用展示层提供数据支持。
应用服务层在应用展示层和数据采集层之间起到承上启下的作用, 完成了除收集安全信息以外剩余的所有功能。如:资产管理、安全信息监控、脆弱性管理、安全事件处理、安全知识管理、安全策略管理、安全状况评估、安全预警等。
2.3 应用展现层
应用展现层实现了安全运维管理平台的统一界面展示。通过应用展现层, 能够查看资产分布状态、关注区域的安全状况、安全事件发生的趋势、各类资产的脆弱性状况等;通过应用展现层, 完成对资产管理、安全信息监控、脆弱性管理、安全事件处理、安全知识管理、安全策略管理、安全状况评估、安全预警功能模块的配置;通过应用展现层, 完成报表的生成、输出 (保存和打印) 等。
2.4 网络架构设计的特点
数据采集采用了开放的架构设计, 将安全设备被管理的能力视为设备对外提供的一类服务——管理服务。SOC安全运维平台的主要功能就是对安全设备进行统一监管, 也就是集中使用这些服务。采用这样的架构设计系统很好的反映了现实的问题, 体现了SOC安全运维平台的实质。
通过对服务的集中管理实现对设备的统一管理, 由于安全设备的多样性和异构性是统一管理的难题, 应用服务层实现了在各种异构的安全设备和SOC安全运维平台之间搭建的一个统一的中间层——服务。服务屏蔽了各种安全设备, 在SOC安全运维平台看来, 管理活动实际上是以服务请求者的身份使用一个个的管理服务, 而无需考虑服务建立在何种硬件或操作系统上以及服务涉及的接口。
3 软件体系结构的设计
在网络架构设计的基础上, 本课题提出了如下的概念模型。整个SOC系统分为SOC界面、应用服务器、采集层和数据库服务器4个部分。此概念模型的设计理念为:鉴于网络安全管理平台在体系结构和业务功能方面都比较复杂, 本设计对系统分层, 各个层次相对独立和分离, 其中应用服务器的安全事件处理模块以及采集层的各个模块可以根据用户的需求进行平行扩展, 在采集层还可以根据业务的发展和新的要求进行功能的扩展, 并通过统一消息系统完成数据的标准化。本设计降低了应用服务器和SOC界面之间的相关性, 降低了应用服务器各个模块之间的耦合度, 便于积木式构建系统。由于这两层软件独立开发, 通过开放式接口连接, 降低了开发的难度, 提高了系统的稳定性和可维护性, 方便系统扩容、新业务开发以及为其它系统的用户提供开放式接口连接。
3.1 SOC界面
在建移动业务支撑系统安全管理平台SOC的设计中, 主要采用了面向对象的设计方法, 使用了J2EE技术, 进行基于J2EE的多层B/S结构设计。
SOC界面采用浏览器/服务器模式软件体系结构。这种三层B/S (浏览器/服务器) 体系结构是把传统的两层C/S结构的业务逻辑从客户机的任务中分离出来, 用户通过浏览器向分布在网络上的许多服务器发出请求, 服务器对浏览器的请求进行处理, 将用户所需信息返回浏览器, 而其余如数据请求、加工、结果返回以及动态网页生成、对数据库的访问和应用程序的执行等工作全部由中间层完成。B/S结构减轻了客户机的负载, 降低了客户机的性能要求, 而且使系统的管理更为集中, 成为目前业务系统采用的主流结构。
3.2 应用服务层
应用服务层主要是完成对采集来的各类资源数据的处理, 形成对风险、策略、知识等的综合管理, 同时按照安全问题的处理流程、依照相关的规则和安全风险管理模型来实现对防火墙、入侵检测、防病毒、主机、网络等构成的安全防护体系的统一监控和管理, 该层在系统实现时主要依靠基于消息通信的后台程序来支撑。应用服务器上安装了SOC界面服务器和SOC后台处理程序, 主要包括安全事件处理、安全状况评估、脆弱性收集分析、风险值计算等功能。
3.3 安全信息收集代理层
安全信息收集代理层主要是完成资产自动发现和收集日志信息生成安全信息, 主要功能是根据要求采集被管理资源 (包括各种安全设备、网络和主机设备) 的原始信息, 包含事件信息、漏洞信息、流量信息和安全和操作日志信息等, 将对所管理资源 (硬件、软件等) 中与安全相关的信息按照一定格式进行预处理 (如过滤、标准化、关联等) , 同时要求遵循标准的通信协议进行输出或被访问。例如, 安全事件的采集需要不断侦听本地主机端口, 接受安全设备发送来的安全事件, 再将其转换成标准的安全事件信息存入安全事件数据库中, 状态信息和配置规则信息主要是根据安全设备所支持的管理接口编写合适、高效的调用程序调用管理接口。
在安全信息收集代理层中, 安全事件的采集主要是运用了JAVA的一个很重要的特性, 即多线程。在客户端向服务器端发出请求时, 客户端把发来的请求放在一个消息队列中, 服务端依次从这个消息队列中取出请求来处理, 但是如果遇到单线程, 那么消息队列中的下一个请求就要等到前一个请求完全处理完后才会响应, 从而导致客户端的长时间等待;而如果采用多线程, 则服务端处理可以同时多个请求, 提高系统的性能。新线程完成的工作主要是通过调用函数readline () 读取一行的安全事件记录, 利用可重用的安全事件分析类从各式各样的安全事件格式中提取与安全统一管理有关的信息, 建立起与数据库服务器的连接, 将这些关键信息保存在数据库中。
3.4 数据库服务器
数据库服务器采用ORACLE 10g, 需要对数据资源或中间数据进行管理, 还需要具有完备的通讯、应用日志功能。按照请求命令的优先级提取用户数据 (并保证同一用户按照时间排序) , 交给通信进程处理, 并接受通信进程的应答将结果返回数据库, 属于非数据的原因造成的指令执行失败可以自动重新处理。
数据库服务器选型确定之后, 就开始数据库的设计。数据库设计分为4个步骤。
首先, 确定建立数据库的目的并收集数据, 即进行需求分析。通过详细调查要处理的对象来明确用户的各种需求, 并且通过调查、收集和分析信息, 了解数据库中需要存储哪些数据以及完成何种数据处理功能。确定了建立数据库的目的之后就需要根据目的收集相关信息。
数据库设计过程的第二阶段是建立概念模型。根据应用的需求, 画出能反映每个应用需求的E-R图, 其中包括确定实体、属性和联系的类型。然后优化初始的E-R图, 消除冗余和可能存在的矛盾。概念模型是对用户需求的客观反映, 并不涉及具体的计算机的软、硬件环境。这一阶段的工作重心是如何表达出用户对信息的需求, 暂时不考虑具体的实现问题。
数据库设计过程的第3阶段是建立数据库模型。将概念模型中得到的E-R图转换成具体的数据模型, 实际上是使用关系数据模型把实体、实体的属性和实体之间的联系转换为关系模式。
分布式计算平台 篇7
系统日志是分布式系统在运行过程中对其运行状态进行实时记录的文件, 该文件通常用于故障排查, 会使用一些工具进行记录和保存, 随着时间的推移, 这种分布式系统日志的数量会越来越多, 由于这些日志文件中对系统所有的操作、机器行为及用户行为进行了大量记录, 因此, 这种系统日志文件成为系统中最复杂但也最有价值的数据, 通过对大量的日志文件进行挖掘分析, 可以找出系统的性能瓶颈, 并有针对性地进行合理优化。
在大数据到来之前, 分布式日志的处理和分析通常是由经验丰富的工程师采用人工查找方式完成, 这种工作方式完全依赖人的工作经验。同时, 也是非常浪费时间、耗费人力的工作, 效率不高, 也极易出错, 而且, 在目前数据呈指数级增加趋势的情况下, 仍然采用人工的方式进行处理已越来越不可能。因此, 必须利用新技术新手段来构建新的日志分析系统。本文提出一种基于云平台的分布式日志分析系统, 对系统的构建进行需求分析, 并设计了基于云平台的存储策略、日志清洗流程等, 实验证明该日志分析系统可行有效, 具有一定的实践意义。
1 云计算概述
云计算的出现是信息技术领域的一大变革, 云计算的基本思想是将网络上的计算资源作为一种公共资源, 通过管理和控制, 用户可以像公共资源一样根据自己的需求进行获取, 用户不需要了解相关的技术和细节, 所有的控制由云平台实现。这种云计算的思想为互联网带来了新的生机, 是一种全新的信息服务模式。
实际上云平台综合了两大典型的分布式系统, 分别是Hadoop和Spark, 这两大系统是目前应用最广泛的基础性云平台, 包括云平台文件存储层、数据仓储、数据挖掘及分布式执行引擎等。
2 系统设计与实现
2.1 需求分析
随着互联网的需求量不断增加, 站点的用户访问量也不断增多, 系统日志的数据量呈海量增加, 为保证系统能利用分布式日志进行数据挖掘分析, 提供决策支持, 保险系统应该具有稳定的数据存储和处理功能, 同时具备较高的执行效率和较强的容错能力。
基于云平台的分布式日志系统还需要通过对日志数据进行分析, 挖掘有用信息, 了解和掌控站点的使用质量, 了解用户的行为习惯, 因此, 日志系统应具有独立且完整的统计指标, 如用户的页面停留时间、页面访问量、独立IP等。同时, 系统应具有灵活的数据清洗转换功能, 能够进行不同类型的数据处理, 具有高效的数据处理流程。由于不同的日志系统采用的格式可能不完全一致, 因此需要设计标准统一的结构化数据格式, 提高数据格式转换功能的灵活性, 保证不同类型的日志数据能够得到兼容处理。
2.2 系统架构设计
如图1所示, 系统从上至下分别是用户界面层、接口层、核心功能层以及平台层。其中, 平台层主要包括云平台和关系型数据库, 大量的数据存储由HDFS完成, 资源的管理和调度则利用YARN实现, 计算引起采用结合Spark和Map/Reduce的分布式计算框架构成, 为保证系统的稳定性, 设计了数据的冗余备份功能。
核心功能层主要包括数据交换模块、工作流调度模块、格式转换模块、并行ETL模块、云平台数据仓库模块及指标统计模块六个功能模块。
接口层和用户界面层都是对界面的设计与实现, 其中, 用户界面层是包括了核心功能的用户界面, 并提供了多种执行方式, 接口层则是提供了界面和具体功能代码接口。
2.3 数据处理流程
首先系统根据实际需要设置日志格式, 为方便对日志数据进行处理, 将全部日志数据转换为定长的格式, 然后, 将系统产生的原始数据进行ETL数据清洗转换, 转换为中间格式, 这种中间格式将更方便日后的分析处理, 然后, 在这种中间日志格式上进行日志分析, 并获得日志分析的结果, 该结果可以从数据仓库中进行查询。通常数据仓库由两个部分构成, 分别是传统的关系型数据库和云平台下的仓储工具, 即Database和Hive/Shark。
2.4 数据模型设计
数据模型设计主要包括日志数据分类、中间日志数据模型设计和数据仓库数据模型设计三个部分, 本节主要对中间数据模型进行说明。
由于原始日志数据通常是不规则的数据, 数据格式并不一致。为方便日后的日志分析统计处理, 需要将原始的日志数据利用ETL清洗转换和格式转化, 最终将其转换成标准的日志格式, 并提取出需要使用的字段, 因此, 在此过程中需要有一种中间形式的数据。
2.5 并行数据挖掘模块
在本文所设计的日志分析系统中, 并行数据挖掘模块是重点难点之一。利用该模块可以对大量的数据进行分析处理, 获得有价值的决策信息, 本系统的数据挖掘模块包括两个部分, 分别是开源算法库Mahout和自主开发的DM模块。
这种基于Spark的方式效率就较高, 但是, 其稳定性还有所欠缺, 因此, 本设计中的数据模块采用DM和Mahout结合的方式进行补充, 从而保证系统的处理能力和性能更稳定。
3 日志分析系统测试
本文的研究基于云平台, 设计日志分析系统, 为验证该系统可靠性, 必须进行系统测试, 本文以独立访客统计为例对日志系统进行测试。
测试从原始的日志数据开始, 根据2.3节中说明的数据处理流程进行处理, 数据为国内某搜索网站的日志数据, 数据格式如图2所示。
如图3所示, 利用UV统计组件进行计算后可以获得时间分布示意图。从该图中可以看出, 系统每天的访问量情况为:每天10~18时段的用户访问量最大, 之后逐步降低, 显然这一统计分析结果符合日常生活中人们的习惯, 从而证明了系统流程的正确性。
4 结语
本文针对目前网络应用不断增加, 日志系统所获取的数据量越来越大的情况, 通过对日志系统挖掘分析可以获得有价值的信息, 为决策提供支持。本文基于云平台开发了一种分布式日志系统, 该系统基于Map/Reduce和Spark编码设计了指标统计、数据挖掘、ETL清洗转换等功能, 通过实验证明了该系统能基本符合系统的功能需求, 具有一定的实践意义。
参考文献
[1]赵莹莹, 韩元杰.Web日志数据挖掘中数据预处理模型的研究与建立[J].现代电子技术, 2007 (4) :103-105.
[2]刘永增, 张晓景, 李先毅.基于Hadoop/Hive的web日志分析系统的设计[J].广西大学学报 (自然科学版) , 2011 (S1) :314-317.