大数据挖掘通用解决方案

大数据挖掘解决方案建议书

目录

1概述 (3)

1.1建设背景 (3)

1.2设计范围 (3)

1.3总体设计原则 (3)

2系统平台设计 (5)

2.1项目需求 (5)

2.2设计思想 (6)

2.3系统方案 (6)

2.4系统优势和特点 (7)

2.5作业调度系统方案 (9)

2.6分布式数据处理系统方案 (9)

2.7分布式数据库方案 (10)

2.8分布式并行挖掘算法方案 (10)

3系统架构 (11)

3.1存储层基本组成 (11)

3.2Jobkeeper系统基本组成 (14)

3.3分布式数据立方系统基本组成 (16)

3.4数据挖掘层基本组成 (24)

4系统架构 (25)

4.1安全保障体系框架 (29)

4.2云计算平台的多级信任保护 (31)

4.3基于多级信任保护的访问控制 (35)

4.4云平台安全审计 (37)

5关键技术 (41)

5.1数据处理集群的可靠性与负载均衡技术 (41)

5.2计算与存储集群的可靠性与负载均衡 (45)

5.3计算与存储集群的负载均衡处理 (53)

5.4分布式文件系统的可靠性设计 (55)

5.5分布式数据立方可靠性设计 (57)

5.6分布式并行计算可靠性设计 (59)

5.7查询统计计算可靠性鱼负载均衡设计 (61)

5.8数据分析与数据挖掘 (63)

6大数据挖掘平台介绍 (72)

6.1平台介绍 (72)

6.2功能介绍 (73)

6.3可视化查询介绍 (76)

6.4分类算法介绍 (76)

6.5聚类算法介绍 (77)

1概述

1.1建设背景

随着云计算和大数据的兴起和发展，云计算已经处理大数据很重要的一个组成部分，伴随着数据量的几何增长，传统的数据挖掘平台系统架构模式已经远远不能适应现代数据挖掘的建设要求。大数据挖掘平台就是建立在数据立方基础上针对海量的数据的集中计算与挖掘，建立一套具有高可靠、可在线弹性伸缩，提供数据内在关系和价值的数据挖掘计算平台。为业务决策提供便捷、快速和高效的平台支撑。

1.2设计范围

本技术解决方案针对大数据挖掘平台技术，提供从系统软硬件技术架构、原理、硬件选型、网络接入以及软件与应用之间的接口等方面的全面设计阐述。

1.3总体设计原则

针对本次工程的实际情况,充分考虑系统建设的建设发展需求，以实现系统统一管理、高效应用、平滑扩展为目标，以“先进、安全、成熟、开放、经济”为总体设计原则。

1.3.1先进性原则

在系统总体方案设计时采用业界先进的方案和技术，以确保一定时间内不落后。选择实用性强产品，模块化结构设计，既可满足当前的需要又可实现今后系统发展平滑扩展。

1.3.2安全性原则

数据是业务系统核心应用的最终保障，不但要保证整套系统能够7X24运行，而且底层存储系统必须有高可用性，以保证应用系统对数据的随时存取。同时配置安全的备

份系统，对应用数据进行更加安全的数据保护，降低人为操作失误或病毒袭击给系统造成的数据丢失。

在进行系统设计时，充分考虑数据高可靠存储，采用高度可靠的软硬件容错设计，进行有效的安全访问控制，实现故障屏蔽、自动冗余重建等智能化安全可靠措施，提供统一的系统管理和监控平台，进行有效的故障定位、预警。

1.3.3成熟性原则

为确保整个系统能够稳定工作，软件平台将使用先进、完善、易于管理和稳定可靠的云存储资源管理系统，对于与应用的集成接口，提供统一的通用稳定访问接口。1.3.4开放性原则

系统建设具有开放性的标准体系，提供开放的应用API编程接口，提供人性化的应用和管理界面，以满足用户需求。遵循规范的通用接口标准，使全系统中的硬件、通信、软件、操作平台之间的互联共享。充分考虑系统的升级和维护问题，维护采用在线式的，即在系统不停止工作的情况下，可以更换单元备件。系统的维护和升级操作由系统管理员即可完成。

1.3.5经济性原则

现有业务系统存储数据量较大，且数据的增长速度较快。因此在建设系统存储架构时，应从长远的角度考虑，建设一个长期的存储架构，除了可以应对存储硬件设备的升级速度外，还必须考虑到对前期存储设备的投资保护，在保证不断提供功能和性能提高的同时，存储架构在较长的时间内能够保持相对稳定。结合先进的云平台技术架构优势，根据本次项目建设的实际容量需求设计，同时充分考虑应用发展需求，实现系统可弹性在线平滑升级。通过软件实现在较廉价普通服务器上实现高度容错，同时能够在较低冗余度的情况下实现高度可靠容错，大大节约和降低系统建设的硬件成本。

1.3.6高效性原则

由于平台本身数据输入规模很大，要求系统能够在较短的时间内对大规模的数据提供数据挖掘分析等业务，为业务决策提供高效快速准确的支持。

2系统平台设计

2.1项目需求

2.1.1容量需求

针对本次建设实际数据容量，建设适合存储容量数据平台，主要存储数据，数据立方可以支持万亿条数据的存储和查询。

2.1.2吞吐量需求

为满足多用户或应用整体吞吐带宽和高并发需要，确保数据访问流畅，系统需提供多用户或应用高并发访问、高吞吐带宽设计，系统能够有效利用各机器的物理资源，性能可通过规模增加实现平滑增长。

2.1.3扩展性需求

未来根据业务应用的变化和发展，需要快速实施系统资源的升级，可以在业务服务不间断的状态下平滑扩展，不会导致架构发生根本性变化，为不断产生和变化的业务需求提供持续的支持，支持业务系统的快速整合和部署对核心系统基础架构的特别要求。

2.1.4低成本需求

要求系统能够以低硬件成本、低维护成本实现高可靠高性能应用要求，充分提高资源利用率，简化管理，并能灵活、可持续扩展。

2.1.5可维护性需求

要求系统具有自适应管理能力，安装、维护、升级简易方便，提供统一易用的WEB 配置管理监控平台，实现智能化管理。

2.1.6接口需求

要求能够提供通用的可编程接口，方便用户及应用系统访问，减少与应用集成或开发工作量，实现系统快速部署与集成。

2.1.7功能需求

系统实现了大多数主流的数据挖掘功能，包括属性选择、分类预测、回归预测、聚类分析、关联分析、时间序列分析等6大类。为适应不同业务数据的特点，对同一个数据挖掘功能，通过多种算法进行实现，例如“分类预测”有决策树、分类回归树、支撑向量机分类、神经网络分类、贝叶斯网络、朴素贝叶斯、逻辑回归、分类组合模型等算法可供用户选用。共计包含了27个数据挖掘算法。

2.2设计思想

采用业界成熟先进的数据立方做为系统大数据底层存储，采用软件实现对大量普通商用服务器存储空间资源进行虚拟化整合，实现软硬件故障高度容错。对于大数据挖掘采用云计算技术将传统单机运行的数据挖掘算法转为分布式并行计算，这样保证大数据数据挖掘的快速高效。同时采用了分布式调度框架JobKeeper，使得系统能够合理有效的实现系统资源的平衡利用，对于系统宕机能够及时的转移计算任务提高了系统的可靠性。系统各个处理节点采用了自注册机制、故障自动屏蔽、自动冗余重建技术实现系统自我维护和平滑扩展，系统服务7×24小时不间断。

2.3系统方案

采用业界已经成熟的数据立方一体机系统，在多台普通商用服务器上构建高性能高可靠云平台系统，使用分布式调度框架JobKeeper协调节点之间的任务处理,其系统软硬件结构图如下。

系统软硬件结构

2.4系统优势和特点

大数据挖掘平台是一套软件与硬件相结合的系统，其中专有技术和软件是高附加值部分，可以广泛应用于需要海量数据挖掘的应用场合（如广电、电信、互联网、银行等领域）。该系统相比传统数据挖掘系统有如下技术优势：

2.4.1高度可靠

大数据挖掘系统采用云架构，底层数据被分块存储在不同的存储节点上，数据采用先进的1:1容错机制进行容错，可在任意损坏一个存储服务器节点的情况下实现数据完整可靠，系统对外存储访问服务不间断。

云存储的管理节点采用了主备双机镜像热备的高可用机制，在主管理节点出现故障时，备管理节点自动接替主管理节点的工作，成为新的主管理节点，待故障节点修复并重启服务后，它则成为新的备管理节点，保障系统的7×24小时不间断服务。

数据挖掘采用了先进任务调度框架JobKeeper,当出现故障节点后,JobKeeper会自动

转移处理任务,保证数据挖掘过程的完整性和正确性。

2.4.2优异性能

数据挖掘采用分布式并行计算技术，将海量数据的计算处理转化为各个存储节点上并行读写和计算，这样减少了网络的带宽使用，提高了数据的处理速度。同时随着处理节点数目的增多，整个系统的计算性能将呈线性增长。

同时，JobKeeper采用负载均衡技术，自动均衡各服务器负载，使得各处理节点的性能调节到最高，实现资源优化配置。

2.4.3海量存储

数据挖掘平台所依赖的数据存储层数据立方容量仅受限于卷管理服务器内存，可支撑的容量接近无限，经推算，理论容量为1024×1024×1024 PB (1G个PB容量)。这样为超大规模的数据挖掘提供了数据支撑。

2.4.4在线伸缩

大数据挖掘系统扩容非常方便，支持不停止服务的情况下，动态加入新的处理节点，无需任何操作，即实现扩容；同时，无需人为干预，也可以摘下任意节点，系统自动缩小规模而不影响挖掘业务，运行在此节点上的计算将会重新运行到其他节点上。

2.4.5通用易用

大数据挖掘系统提供专用的API接口，供开发人员调用。

2.4.6智能管理

提供基于WEB的管理控制平台，所有的管理工作均由大数据挖掘管理模块自动完成，使用人员无需任何专业知识便可以轻松管理整个系统。通过管理平台，可以对数据立方中的数据源进行挖掘业务，同时提供挖掘结果的可视化查询界面，可以方面的查看挖掘结果，为业务决策做支持。此外，用户还可以通过监控界面可以清楚地了解到每一个处理节点的负载、存储和运行情况。

2.4.7快速高效

大数据挖掘平台算法库采用了分布式并行算法能够在较短的时间内完整各种算法，同时随着机器的增加系统性能线性增长。

2.5作业调度系统方案

采用业界已经成熟的Jobkeeper多任务调度系统，在多台普通商用服务器上构建高性能高可靠的任务调度平台。

2.5.1高度可靠性

Jobkeeper采用“多主多备，负载均衡”的管理节点，从而保证无论管理节点还是处理节点都不存在任何单点故障问题。

2.5.2低依赖性

Jobkeeper采用模块化设计思想，通过统一化配置和API接口的方式向用户提供服务。

2.5.3低干预性

Jobkeeper采用基于事件化的统一管理模式。在系统无人值守的情况下自动完成故障处理等功能。

2.5.4高实时性

Jobkeeper在机器性能允许的范围内，所有任务的控制工作基本都在秒级完成，具有前所未有的高效性。

2.6分布式数据处理系统方案

采用业界已经成熟的MapReduce数据处理模型，在多台普通商用服务器上构建高性能高可靠的数据处理平台。

2.6.1高度可靠性

采用调度节点贮备模式，确保MapReduce的可靠性。

2.6.2扩展性

在服务不停止的情况下，可以动态扩展云平台规模，线性扩大计算能力。

2.6.3负载均衡性

MapReduce负载平衡用的是公平调度算法，公平调度是一种多用户的赋予作业（job）

资源的策略，它的目的是让所有的作业随着时间的推移，都能获取与权值相应的共享资

源。当单独一个作业在运行时，它将使用整个集群。当有其它作业被提交上来时，系统

会将任务（task）空闲计算槽（slot）赋给这些新的作业，以使得每一个作业都大概获

取到与权值相应的计算时间。这个特性让短作业在合理的时间内完成的同时又保证了长

作业的服务质量。

2.7分布式数据库方案

采用分布式数据立方分布式数据库结合Hive平台，提供高性能高可靠性的、面向列的结构化、非结构化数据的即时访问。分布式数据立方和Hive构建于HDFS之上，通过HDFS的高可靠性和易扩展的性能，为分布式数据库提供了廉价的解决方案。

2.8分布式并行挖掘算法方案

采用高效的任务调度框架JobKeeper,将传统的单机运行的各种数据挖掘算法(如:分类、聚类、关联规则)算法，转化为可以运行在JobKeeper上的分布式计算任务。对于数据的存储以及ETL等操作，通过数据立方来完成，这样极大的简化了挖掘算法本身所需要处理的逻辑，使得数据挖掘本身之需要关注处理数据的入口格式即可。

3系统架构

在本次云建设中，HDFS属于基础平台支撑层，以用于数据集中存储和共享，实现对数据的统一管理和高效应用；分布式数据立方属于分布式数据库层，用于结构化和非结构化数据的高性能访问；MapReduce和Hive则基于云存储进行大规模的高性能的数据ELT操作。数据挖掘层则是对清洗过的数据进行知识发现的关键处理层。

下面具体说明各系统的基本组成和主要功能。

3.1存储层基本组成

分布式文件系统HDFS被设计为将海量文件存储在一个大集群的多台计算机上。HDFS 将每一个文件以分块序列的形式进行存储，一个文件的所有分块除去最后一个分块外都是等大小的。为了实现容错将文件分块进行自动复制。文件分块的块大小和复制比例都是可以按照单个文件进行配置的。HDFS中的所有文件都是“只写一次”并且严格限定在任何时候只有一个写文件操作者。

HDFS是Hadoop框架的分布式并行文件系统，是分布式计算的存储基石。

负责数据分布式存储及数据的管理，并能提供高吞吐量的数据访问。HDFS的基本特征如下：

(l)对于整个集群有单一的命名空间。

(2)文件会被分割成多个文件块，每个文件块被分配存储到数据节点上，而且根据配置会有复制的文件块来保证数据安全性。

(3)数据一致性。适合一次写入多次读取的模型，客户端在成功创建文件之后，才能看到文件的存在。

(4)Hadoop，包括HDFS，非常适合在廉价机器上的分布式存储和分布式处理。它是容错的、可伸缩的、非常易于扩展。并且，以简单性和适用性著称的MapReduce是Hadoop 不可缺少的重要组成部分。

(5)HDFS的默认配置适合于大多数安装的应用。通常情况下，只有在一个非常大规模的

集群上才需要修改默认配置。

(6)支持shell命令行风格的HDFS目录交互。

(7)HDFS是用java编写的，可广泛运行在多种软硬件平台上。

(8)HDFS经常性地实现新的特性和改进。

(9)Namenode和DataNode都内建了Web服务器，可以方便地查看集群的状态。

HDFS的体系框架是Master/Slave结构，一个典型的HDFS通常由单个Namenode和多个DataNode组成。Namenode是一个中心服务器，负责文件系统的名字空间的操作，比如打开、关闭、重命名文件或目录，它负责维护文件路径到数据块的映射，数据块到DataNode的映射，以及监控DataNode的心跳和维护数据块副本的个数。集群中的DataNode一般是一个节点一个，负责管理它所在节点上的存储。HDFS暴露了文件系统的名字空间，用户能够以文件的形式在上面存储数据。从内部看，一个文件其实被分成一个或多个数据块，这些块存储在一组DataNode上。DataNode负责处理文件系统客户端的读写请求。在Namenode的统一调度下进行数据块的创建、删除和复制。

所有对目录树的更新和文件名和数据块关系的修改，都必须能够持久化，文件在HDFS中存储图如图：

HDFS结构

HDFS涉及到Namenode、DataNode和客户端们之间的交互。本质上，客户端与Namenode通讯是通过获取或者修改文件的元数据，与 DataNode进行实际的I/O操作。

如图13所示，在HDFS中有三个重要的角色：Namenode、DataNode和Client，其中Client 就是需要获取分布式文件系统文件的应用程序。

这里通过三个操作来说明他们之间的交互关系：

(l)文件写入。首先Client向Namenode发起文件写入的请求，Namenode根据文件大小和文件块配置情况，返回给Client它所管理部分DataNode的信息。Client将文件划分为多个Block，根据DataNode的地址信息，按顺序写入到每一个DataNode块中。

(2)文件读取。Client向Namenode发起文件读取的请求，Namenode返回文件存储的DataNode的信息。Client根据返回的信息读取DataNode上的文件信息。

(3)文件Block复制。Namenode发现部分文件的Block不符合最小复制数或者部分DataNode失效，通知DataNode相互复制Block。DataNode收到通知后开始直接相互复制。

HDFS Namenode、DataNode和客户端们之间的交互3.2Jobkeeper系统基本组成

Jobkeeper的系统架构如下图所示：

上图中对Jobkeeper进行了分层，对每层进行具体阐述

?虚拟化资源层：将机器进行虚拟化，形成更大范围的服务集群。?存储层：存储数据的处理结果集或其他中间结果集的单元。

?数据处理层：独立的数据处理程序，是对不同需求数据的统一处理方案，由JobKeeper调度平台进行统一的配置管理。

?业务层：对于应用层的相关功能的业务化，数字化处理，用于将应用层的需求任务进行规则化划分，形成统一的处理化模式。

?应用层：一组用于管理和结果反馈的显示组件。是整个系统面向用户和开发人员的基础承载。

JobKeeper的任务分发流程如下图所示：

JobKeeper任务分发流程图

当用户在应用层下发任务给管理节点，管理节点调度机器采集机器节点的信息，根据具体的算法选取最优节点并分发任务，接下来具体的处理节点接收到任务并处理同时将结果返回给管理节点，管理节点整理汇总处理结果，而后返回给应用层。

服务器节点组：负责对处理节点的系统信息以及任务处理信息进行实时的跟踪和保

存，对应的信息镜像存储在基于cStor或者NFS服务的存储系统上。

处理节点组：通过RPC的远程调用获取各自节点的任务处理目标，并实时的和处理节点上的任务处理目标进行对比，控制程序的执行和结束。处理节点组会在一个设定的心跳间隔内主动的和管理节点组联系一次，报告节点存活状态。

3.3分布式数据立方系统基本组成

分布式数据立方，是一个高可靠性、高性能、面向列、可伸缩的分布式存储系统，利用分布式数据立方技术可在廉价PC Server上搭建起大规模结构化存储集群。其目的是处理庞大的表，可以用普通的计算机处理10亿行数据，并且有数百万列元素组成的数据表这张表的索引是行关键字。分布式数据立方可以直接使用本地的文件系统和Hadoop作为数据存储方式，不过为了提高数据的可靠性和系统的健壮性，发挥分布式数据立方处理大数据量等功能，需要使用Hadoop作为文件系统。

1、数据模式

分布式数据立方类似Bigtable的分布式数据库，是一个稀疏的，长期存储的，多维的，排序的映射表.这张表的索引是行关键字，列关键字和时间戳。每个值是一个不解释的字符数组，数据都是字符串，没类型。

用户在表格中存储数据，每一行都是一个可排序的主键和任意多的列。由于是稀疏存储的，所以同一张表里面的每一行数据都可以有截然不同的列。

列名字的格式是":",都是由字符串组成，每一张表有一个family集合，这个集合是固定不变的，相当于表的结构，只能通过改变表的结构来改变。但是lable值相对于每一行来说都是可以改变的。

分布式数据立方把同一个family里面的数据存储在同一个目录底下，而分布式数据立方的写操作时锁行的，每一个都是一个原子元素都可以加锁。

所有数据库的更新都是一个时间戳标记，每个更新都是一个新的版本，而分布式数据立方会保留一定数量的版本，这个值是可以设定的。客户端可以获取距离某个时间最近的版本，或者一次获取所有版本。

2、概念视图

分布式数据立方以表的形式存储数据。表有行和列组成。列划分为若干个列族(row family)

Row Key

与nosql数据库们一样,row key是用来检索记录的主键。访问分布式数据立方 table 中的行，只有三种方式：

1 通过单个row key访问

2 通过row key的range

3 全表扫描

Row key行键 (Row key)可以是任意字符串(最大长度是 64KB，实际应用中长度一般为10-100bytes)，在分布式数据立方内部，row key保存为字节数组。

列族

分布式数据立方表中的每个列，都归属与某个列族。列族是表的chema的一部分(而列不是)，必须在使用表之前定义。列名都以列族作为前缀。例如courses:history，courses:math 都属于courses 这个列族。

时间戳

分布式数据立方中通过row和columns确定的为一个存贮单元称为cell。每个 cell

都保存着同一份数据的多个版本。版本通过时间戳来索引。时间戳的类型是 64位整型。时间戳可以由分布式数据立方(在数据写入时自动 )赋值，此时时间戳是精确到毫秒的当前系统时间。时间戳也可以由客户显式赋值。如果应用程序要避免数据版本冲突，就必须自己生成具有唯一性的时间戳。每个 cell中，不同版本的数据按照时间倒序排序，即最新的数据排在最前面。

Cell

由{row key, column(= + ), version} 唯一确定的单元。cell中的数据是没有类型的，全部是字节码形式存贮。

3、物理存储

1 Table中的所有行都按照row key的字典序排列。

2 Table 在行的方向上分割为多个Hregion。

3 region按大小分割的，每个表一开始只有一个region，随着数据不断插入表，region 不断增大，当增大到一个阀值的时候，Hregion就会等分会两个新的Hregion。当table 中的行不断增多，就会有越来越多的Hregion。

4 Hregion是分布式数据立方中分布式存储和负载均衡的最小单元。最小单元就表示不同的Hregion可以分布在不同的HRegion server上。但一个Hregion是不会拆分到多个server上的。

5 HRegion虽然是分布式存储的最小单元，但并不是存储的最小单元。

事实上，HRegion由一个或者多个Store组成，每个store保存一个columns family。每个Strore又由一个memStore和0至多个StoreFile组成。如图：

StoreFile以HFile格式保存在HDFS上。