大数据平台建设关键技术_通过网络将抽样的、可伸缩的、便于管理的数据能源、服务、存储方式传递给终端客户

 

1. 1. NoSql数据库

传统的关系型分布式数据库已经不能适应大数据时代的数据存储要求：

数据规模变大。大数据时代的特征之一“Volume”，就是指巨大的数据量，因此必须采用分布式存储方式。传统的数据库一般采用的是纵向扩展（scale-up）的方法，这种方法对性能的增加速度远远低于所需处理数据的增长速度，因此不具有良好的扩展性。大数据时代需要的是具备良好横向拓展（scale-out）性能的分布式并行数据库。

数据种类增多。大数据时代的特征之二”Variety”，就是指数据种类的多样化。也就是说，大数据时代的数据类型已经不再局限于结构化的数据，各种半结构化､非结构化的数据纷纷涌现。如何高效地处理这些具有复杂数据类型､价值密度低的海量数据，是现在必须面对的重大挑战之一。

设计理念的差异。传统的关系型数据库讲求的是“One size for all”，即用一种数据库适用所有类型的数据。但在大数据时代，由于数据类型的增多､数据应用领域的扩大，对数据处理技术的要求以及处理时间方面均存在较大差异，用一种数据存储方式适用所有的数据处理场合明显是不可能的，因此，很多公司已经开始尝试“One size for one”的设计理念，并产生了一系列技术成果，取得了显著成效。

为了解决上述问题，Google公司无疑又走在了时代的前列，它提出了BigTable的数据库系统解决方案，为用户提供了简单的数据模型，这主要是运用一个多维数据表，表中通过行､列关键字和时间戳来查询定位，用户可以自己动态控制数据的分布和格式。BigTable中的数据均以子表形式保存于子表服务器上，主服务器创建子表，最终将数据以GFS形式存储于GFS文件系统中；同时客户端直接和子表服务器通信，Chubby服务器用来对子表服务器进行状态监控；主服务器可以查看Chubby服务器以观测子表状态检查是否存在异常，若有异常则会终止故障的子服务器并将其任务转移至其余服务器。

除了BigTable之外，很多互联网公司也纷纷研发可适用于大数据存储的数据库系统，比较知名的有Yahoo!的PNUTS和Amazon的Dynamo。这些数据库的成功应用促进了对非关系型数据库的开发与运用的热潮，这些非关系型数据库方案现在被统称为NoSQL（Not Only SQL）。就目前来说，对于NoSQL没有一个确切的定义，一般普遍认为No-SQL数据库应该具有以下特征：模式自由（schema-free），支持简易备份（easy replication support），简单的应用程序接口（simple API），一致性，支持海量数据（huge amount of data）。

为弥补关系型数据库的不足，各种各样的NoSQL数据库应运而生。关系型数据库能进行事务处理和JOIN等复杂处理。相对地，NoSQL数据库只应用在特定领域，基本上不进行复杂处理，但恰恰弥补了关系型数据库的不足之处。

可以处理超大量的数据。

可以运行在便宜的大规模的PC服务器集群上。

集群扩充起来非常方便并且成本很低，避免了分片操作的复杂性和成本。

执行速度变得更快，省去将应用和数据转换成SQL友好格式的时间。

没有过多的操作。

NoSQL数据库是非关系型数据存储的广义定义，它打破了长久以来关系型数据库与ACID理论大一统的局面。NoSQL数据存储不需要固定的表结构，通常也不存在连接操作。NoSQL数据库不使用传统的关系数据库模型，而是使用如key-value存储、文档型的、列存储、图型数据库、xml等方式存储数据模型。其中用的最多的是：key-value存储。

NoSQL数据库经常被用作很多非功能性的地方，这些NoSQL的特性在理论和实践中都正在被广泛应用，CAP理论也被很好地应用于NoSQL系统中。CAP即，一致性(Consistency)，可用性(Availability)，分区容忍性(Partition tolerance)。在分布式系统中，这三个要素最多只能同时实现两个，而NoSQL一般放弃的是一致性。

NoSQL数据库种类繁多，但是一个共同的特点都是去掉关系数据库的关系型特性。数据之间无关系，这样就非常容易扩展。也无形之间，在架构的层面上带来了可扩展的能力。

NoSQL数据库都具有非常高的读写性能，尤其在大数据量下，同样表现优秀。这得益于它的无关系性，数据库的结构简单。一般关系型数据库使用Query Cache，每次表的更新Cache就失效，是一种大粒度的Cache，在针对交互频繁的应用，Cache性能不高。而NoSQL的 Cache是记录级的，是一种细粒度的Cache，所以NoSQL在这个层面上来说就要性能高很多了。

NoSQL无需事先为要存储的数据建立字段，随时可以存储自定义的数据格式。而在关系数据库里，增删字段是一件非常麻烦的事情。如果是非常大数据量的表，增加字段简直就是一个噩梦。这点针对大数据量的应用尤其明显。

尽管目前流行的NoSQL数据存储系统的设计与实现方式各有不同,但是总结起来大体上有两种架构：master-slave 结构和P2P 环形结构。两者各具特色。在采用master-slave结构的系统中,master节点负责管理整个系统，监视slave节点的运行状态，同时为其下的每一个slave节点分配存储的范围,是查询和写入的入口。master节点一般全局只有1个,该节点的状态将严重影响整个系统的性能，当master节点宕机时，会引起整个系统的瘫痪。实践中，经常设置多个副本master节点，通过联机热备的方式提高系统的容错性。slave节点是数据存储节点，通常也维护一张本地数据的索引表。系统通过添加slave节点来实现系统的水平扩展。在master-slave框架下，master节点一直处于监听状态，而slave节点之间尽量避免直接通信以减少通信代价。在运行过程中，salve节点不断地向master节点报告自身的健康状况和负载情况，当某个节点宕机或负载过高时，由master节点统一调度，或者将此节点的数据重新分摊给其他节点，或者通过加入新节点的方式来调节。

在P2P环形结构中，系统节点通过分布式哈希算法在逻辑上组成一个环形结构，其中的每个node节点不但存储数据，而且管理自己负责的区域。P2P环形结构没有master节点，可以灵活地添加节点来实现系统扩充，节点加入时只需与相邻的节点进行数据交换，不会给整个系统带来较大的性能抖动。P2P环形结构没有中心点。每个节点必须向全局广播自己的状态信息。

Redis是NoSql数据库的典型代表，兼具临时性和永久性存储功能，且集合了临时性key-value存储和永久性key-value存储的优点。Redis首先把数据保存到内存中，在满足特定条件（默认是15分钟一次以上，5分钟内10个以上，1分钟内10000个以上的key发生变更）的时候将数据写入到硬盘中。这样既确保了内存中数据的处理速度，又可以通过写入硬盘来保证数据的永久性。这种类型的数据库特别适合于处理数组类型的数据。

同时在内存和硬盘上保存数据。

可以进行非常快速的保存和读取处理。

保存在硬盘上的数据不会消失，可以恢复。

适合于处理数组类型的数据。

Redis官方测试数据，

配置：Linux2.6 Xeon X3320 2.5GHz

模拟：50个并发，请求10W次，读写256bytes的字符串

结果：写的速度11w次/秒，读的速度8.1w次/秒

Slave 在21秒即完成对Amazon网站10G key-set的复制

1. 1. 实时数据库

实时数据库可用于生产过程的自动采集、存储和监视。作为大型实时数据库，可在线存储每个生产过程点的多年数据。它提供了清晰、精确的操作情况画面，用户既可浏览当前的生产情况，也可回顾过去的生产情况。可以说，实时数据库对于企业来说就如同飞机上的“黑匣子”。另一方面，实时数据库为最终用户提供了快捷、高效的企业信息。由于企业实时数据存放在统一的数据库中，企业中的所有人，无论在什么地方都可看到和分析相同的信息，客户端的应用程序可使用户很容易在企业级实施管理，诸如工艺改进、质量控制、故障预防维护等。通过实时数据库可集成DMS、EMS、ERP、设备维护管理、MIS、模拟与优化等应用程序，在业务管理和实时生产之间起到桥梁作用，实现企业数字化管理。

实时数据库在流程企业的应用市场前景极其广阔。仅中国石油集团公司新疆乌鲁木齐石化总厂下属的炼油厂、化肥厂、化纤厂投资2200万元进行实时数据库和信息管理系统建设。九江石化总厂投资320万元进行实时数据库管理系统建设。中国石化集团公司济南炼油厂投资300万美元从美国IBM公司购置了实时数据库和信息管理系统。宝钢投资2.5亿元开发全厂的信息管理系统。中石化和中石油二大型集团公司下属的企业已采用实时数据库和信息管理系统的约25%，而且每年以15%的速度递增。由此看来流程企业的实时数据库管理系统和信息系统发展的空间是巨大的。除了石油化工行业，实时数据库还可广泛应用于钢铁、冶金、电力、造纸、制药、食品、交通、证券、飞行控制、航空航天等领域，所以国内目前市场潜力巨大。

在电力系统中的应用

设备的安全运行是电力安全运行的重要保证。本子系统的目标是通过建立全局关键设备运行状态实时数据库系统，使得各级管理人员、设备检修人员通过广域网进行远程设备监控、故障分析等。系统的逻辑结构如下图所示。

众所周知，实时数据库系统可以有效解决实时数据的实时存贮、管理、查询、海量历史数据压缩等关系数据库所不具备的特征，同时，它又可采用多种通讯规约，与多种数据采集系统进行实时数据通讯。建立设备运行状态实时数据库系统，将有如下一些主要功能：

设备运行状态参数的实时采集

设备运行故障实时报警

发生故障后，进行故障分析与故障追忆

异常报警跟踪

历史数据分析与设备操作优化

多种不同规约的数据采集接口

采用组态工具进行监控应用开发，快速、简便

报表自动生成

B/S结构，信息无处不在

支持面向对象的二次开发接口

与MIS系统无缝集成

 

建立生产状态实时数据库系统对电网调度、安全生产至关重要。本系统的目标是将各变电所的SCADA子系统的数据进行集成，面向管理系统进行数据管理，同时，提供与MIS系统的无缝集成，达到整个电业局范围内实时数据、关系数据的平滑流动。本子系统是企业综合数据集成平台的有效组成部分之一。系统的逻辑结构如下图所示。

采用生产状态实时数据库系统，具有如下关键优点：

电网运行状态参数的实时采集

电网运行故障实时报警

发生故障后，进行故障分析与故障追忆

异常报警跟踪

历史数据分析与电网调度优化

多种不同规约的数据采集接口

采用组态工具进行监控应用开发，快速、简便

报表自动生成

B/S结构，信息无处不在

支持面向对象的二次开发接口

与MIS系统无缝集成

所有变电站、输电设备的运行参数据全部集成，有效支持DMS系统、EMS系统及全局范围内的操作优化与区域协调控制

 

在石化企业中的应用

以某炼油厂为例简要说明实时数据库在炼化企业中的应用

根据《XX石化分公司“十五”发展规划》，《XX石化分公司“十五”发展规划汇报材料》的要求，为了进一步加快企业发展，在信息化进程上取得更大优势，增强公司在石化企业的竞争力，需要建立一个生产管理信息综合平台，对公司的生产实时工艺数据、质量数据、库存数据等进行统一管理，能够解决各个管理部门方便地对生产数据进行查询、统计、汇总等问题。为公司领导层对生产科学管理和决策提供有力支持。

该企业采用快速以太网作为企业主干网。为了减少广播风暴及增加安全性，又把网络划分为9个网段。所有服务器位于0网段，所有网络通过双网卡与服务器通信。拓扑结构如下图所示。

 

系统设计数据采集点为10000点，用户数为100，服务器采用双机热备方式。支持报表生成、数据整合及网上发布。

 

该厂的装置采用的控制系统如下。

实时数据库的安装使用实现了生产数据的实时采集，采集数据5324点，采集频率支持到毫秒级，为企业的安全生产、统一调度、节能减排提供了基本保障。

在企业优化运行中的应用

开放结构的分布式实时数据库系统（RTDB——Real-Time DataBase）能够提供高速、及时的实时数据服务，能够有效地集成异构控制系统。它在工厂控制层（现场总线ESB、DCS，PLS等）与管理信息系统(MIS)之间建立了实时的数据连接，使企业全生产控制过程和业务管理相结合。同时它也是企业SMS（Smart Manufacturing System）系统的核心，是工艺模拟、先进控制、实时在线优化、生产全过程管理等系统的数据平台。

实时参数的在线获取

通过组态生成的画面及客户端的查询工具，操作人员可以方便地获得任意工位的实时数据。

先进控制的实现

在实时数据库的基础上，可以挂接先进的控制算法，如多变量动态矩阵控制(DMC Plus)、鲁棒多变量预估控制（Robust Multi-variable Predictive Control Technology）等，该技术已以在多个石化企业中应用。

区域协调优化控制的实现

由于生产过程中，装置（车间）与装置（车间）之间耦合严重，传统的控制手段中解决本装置（车间）内部的优化问题，对装置（车间）之间由于没有共用的数据平台而无法解决。实时数据库为这种优化问题提供很好的数据平台。

操作优化指导

利用实时数据库系统，可以对操作人员的调整操作进行在线指导。即通过偏差控制和耗差控制，达到经济运行的目的。运行操作优化的核心是耗差分析（或称能损分析）。通过耗差计算，对机组的运行总耗差进行分割、解剖，找出机组能量损失的分布情况，给出各项损失的大小及其原因，并进行正确的调节指导。

优化运行分析

系统运行工程师和有关技术人员可以通过查阅实时数据，参数的波幅监视（通道监视），结合历史数据查询和相关分析，实现运行分析的优化功能。

考核指标自动生成

在实时服务器实现历史数据的存储。管理人员只要键入统计起止时间，就能自动产生相应的电子报表。并使报表上网，实现报表的网上打印。采用实时数据库可以实现连续、动态的考核方法；科学、合理的差异计算与统计，排除人为因素，使考核结果更合理。

实时数据管理技术

实时数据管理是整个实时数据库系统最关键的部分，它负责调度实时数据处理任务和协调各个组件的工作。由于实时数据管理部件所处的位置，以及数据库系统的设计采用微内核机制，我们又称之为实时数据库运行核。

 

实时数据组织技术

实时数据库必须能够高速、按时的存取和处理数据，必须尽量保证关键的数据操作能够在规定的时间内完成。因而，为了提高数据操作的可预见性，实时数据库在数据存储方式和索引方式上与传统的数据库有很大的不同。为了避免不必要的磁盘操作和避免不可预测时间的动态资源分配，实时数据库一般采用静态数据结构，使用大量缓冲和预分配内存。为了提高数据检索速度，一般采用多级索引机制进行快速的数据定位

历史数据压缩与存储技术

在实时数据库系统中，数据压缩在传统意义上是为了减少磁盘空间。针对不同的应用，数据压缩有多种算法，实时数据库系统不仅要求能够在有限的硬盘空间中存储大量历史数据，而且还要求这些数据能够快速地被访问。然而在使用压缩技术以后出现的主要问题是，在压缩数据库中处理查询变得很慢，这就需要对数据压缩算法有一定的限制要求，要根据过程数据的特点，进行数据压缩。

历史数据管理采用了时态数据模型，其存储分为三级：历史数据缓冲池，当前历史数据文件队列和历史数据归档文件。它们分别记录了现场实时数据的近期、中期和远期数据。

历史数据缓冲队列：它是实时数据库运行核与历史数据管理组件的连接桥梁。用于缓冲实时运行核发来的实时数据，便于对历史数据的异步处理。

 

历史数据缓冲池：它是历史数据在内存中的主要缓冲空间。用于存储近期历史数据。它提高了近期历史数据的存取效率，减少不必要的磁盘操作。

历史数据文件：历史文件采用页式布局。每个历史文件分为两个数据区，基本数据区和扩展数据区。基本数据区定义了数据的的索引信息。扩展数据区可以动态的追加和插入历史数据。

历史数据归档：当系统中存储了过多的历史数据后。可以定期或手工将历史数据文件从历史数据文件队列摘除。进行二次压缩，用于信息储备，必要时再挂入系统。

用户可以根据历史数据的规模配置历史数据文件的大小和历史数据文件队列的长度，并且可以方便的将文件进行压缩和归档

高效实时的分布式消息通信中间件

实时消息通信中间件是一种面向分布式应用的消息队列中间件产品，它通过消息队列（Message Queue）为分布式应用提供了一种可靠的信息交换的机制。一个应用将消息放到队列中，而另一个应用则可以从该队列中获取消息，以此来达到通信的目的。这两个应用可以在同一台机器上,也可以在由局域网或广域网所连接的不同的机器上。实时消息通信中间件是实现分布式实时数据库的重要环节。

在实时消息通信中间件（RTMQ）中应用程序之间交流的基本信息单位是消息。它分为两个部分：消息描述头和消息内容。消息描述头给出了消息的标识、消息的系统属性和目的队列等，而消息内容则是由应用程序定义的数据流。RTMQ在消息的存储和发送、接收过程中对消息内容不做任何处理。消息队列是消息存放的缓冲，消息按优先级与截止期在消息队列中排队。

在每个提供消息队列服务的RTMQ节点上由消息队列管理器负责消息队列的管理以及消息的发送和接收，不同的消息队列管理器之间可以通过底层的网络平台进行消息交换。基于RTMQ的应用程序可以通过消息队列接口(MQ API Library)与消息队列管理器通信，完成消息的发送和接收。

RTMQ所提供的消息队列服务是一种松耦合的分布式应用集成形式。对于所支持的应用程序要求不高。它们的运行地点、运行方式和运行时间上是相互独立的，可以是同步，也可以是异步，可以同时运行，也可以在各自条件下独立运行。这种松耦合的工作方式也为负载平衡提供了有力支持。

RTMQ的技术要求包括：

提供端到端(Peer-to-Peer)的消息通讯能力，提供QoS保证；

消息发送单次可达：即保证每个消息将能从发送者到达接收者，且保证每个消息仅被接收一次；

提供多种消息缓存机制：使其能够支持各种不同应用在消息的访问速度、持久性和可靠性等方面的不同需求；

多级的消息队列存储结构：在消息的可靠存储方面，结合消息队列的特点，设计了基于分页的消息队列存储结构。该技术的优点在于分页方式和现在的磁盘技术结合最紧密，可以尽可能提高消息的存储以及访问的效率；增加存储的可靠程度；便于缓冲池的组织，易于控制其刷新过程，能够为事务恢复提供必要的支持；

消息的调度管理：队列中的消息可以按照时限或优先级进行排列；

支持消息操作的事务特性；操作也可以以事务为单位进行提交和回滚以及故障恢复，这样可以进一步加强消息队列的可靠性；

提供消息队列访问的同步、异步接口：对于响应时间要求高，耦合要求紧密的系统可以使用同步接口，提高响应速度以满足实时应用的需求；对于业务逻辑相对独立，耦合松散的系统可以采用异步接口，通过批处理或RTMQ提供的事件机制来触发处理程序，而不必采用长时间的循环等待，以此来提高工作效率；

应用服务请求的并发处理：服务器方可以根据服务请求的数量，动态调整服务策略，提高响应速度；

订阅发布服务：服务的请求者和提供者可以通过订阅和发布指定类型的消息来进行通信；

确保消息完整性、安全性；

提供简洁的API编程接口；

支持主流操作系统平台，包括Unix、Linux与Windows；

在语义上支持实时应用中的五种主要的数据流类型：实时信号、实时命令、实时状态、实时事件、实时请求。

解决方案/产品综述

目前国内外工业自动化控制领域的各厂商都有自主产权的实时数据库产品，如国外的PI、IBM的Infomix、霍尼韦尔的PHD，国内的紫金桥、浙大中控等，主流实时数据库的关键参考指标如下：

采用基于定阅的数据前推机制，也支持实时数据、历史数据在线远程查询。

报警管理、实时规则的在线建立

在系统不停机的情况下，在线修改报警触发条件、事件触发方式等。

事故追忆

将事故点附近的数据再现出来，帮助事后分析与总结。

异常报警跟踪

设置异常报警条件及跟踪对象，当满足触发条件对跟踪对象进行连续采样，并能以曲线的形式表现。

数据整合、发布

可以通过发布组件整合到符合ODBC开放标准的关系数据库及EXCEL电子表格中，方便进行二次开发、报表生成及信息集成。

协议转换（数据软总线），可以有效集成多种异构的设备

快速的组态开发、动态报表生成

统一数据平台支持（管理数据、过程数据无缝集成）

支持面向对象的二次开发接口

B/S结构，事件驱动、数据前推,信息到桌面、到设备

大规模：多达5万点的数据采集规模

高性能：系统核心每秒至少处理3000个事件

实用性：24＊7连续在线、在线组态

可靠性：故障自恢复（3天）

扩展性：模块构件、灵活配置

开放性：统一接口

1. 1. Hadoop

大数据时代对于数据分析?管理都提出了不同程度的新要求，许多传统的数据分析技术和数据库技术已经不足以满足现代数据应用的需求。为了给大数据处理分析提供一个性能更高?可靠性更好的平台，Doug Cutting模仿GFS，为MapReduce开发了一个云计算开源平台Hadoop，用Java编写，可移植性强。现在Hadoop已经发展为一个包括分布式文件系统HDFS、分布式数据库HBase以及数据分析处理MapReduce等功能模块在内的完整生态系统Ecosystem，现已经发展成为目前最流行的大数据处理平台。Intel公司根据Hadoop的系统构造，给出了一种Hadoop的实现结构。

 

在这个系统中，以MapReduce算法为计算框架，HDFS是一种类似于GFS的分布式文件系统，可以为大规模的服务器集群提供高速度的文件读写访问。HBase是一种与BigTable类似的分布式并行数据库系统，可以提供海量数据的存储和读写，而且兼容各种结构化或非结构化的数据。Mahout是Apache旗下的一个开源项目，对海量数据进行挖掘的一种方式，提供数据挖掘､机器学习等领域中经典算法的实现。Hive是一种基于Hadoop的大数据分布式数据仓库引擎，它使用SQL语言对海量数据信息进行统计分析､查询等操作，并且将数据存储在相应的分布式数据库或分布式文件系统中。为了对大规模数据进行分析就要用到相关的数据分析处理语言PigLatin，它借鉴了SQL和MapReduce两者的优点，既可以像SQL语言那样灵活可变，又有过程式语言数据流的特点。Zookeeper是分布式系统的可靠协调系统，可以提供包括配置维护､名字服务､分布式同步､组服务等在内的相关功能，封装好复杂易出错的关键服务，将简单易用的接口和性能高效､功能稳定的系统提供给用户。Sqoop是一个用来将Hadoop和关系型数据库中的数据双向转移的工具，可以将一个关系型数据库（MySQL，Oracle，Postgres等）中的数据导入到Hadoop的HDFS中，也可以将HDFS的数据导入到关系型数据库中，还可以在传输过程中实现数据转换等功能。Flume是一种分布式日志采集系统，特点是高可靠性､高可用性，它的作用是从不同的数据源系统中采集､集成､运送大量的日志数据到一个集中式数据存储器中。

HDFS

在Google之前，没有哪一个公司曾需要处理数量如此多､种类如此繁杂的数据，因此，Google公司结合自己的实际应用情况，自行开发了一种分布式文件系统GFS（Google File System）。这个分布式文件系统是个基于分布式集群的大型分布式处理系统，作为上层应用的支撑，为MapReduce计算框架提供低层数据存储和数据可靠性的保障。

GFS同传统的分布式文件系统有共同之处，比如性能､可伸缩性､可用性等。然而，根据应用负载和技术环境的影响，GFS和传统的分布式文件系统的不同之处使其在大数据时代得到了更加广泛的应用。GFS采用廉价的组成硬件并将系统某部分出错作为常见情况加以处理，因此具有良好的容错功能。从传统的数据标准来看，GFS能够处理的文件很大，尺寸通常100MB以上，数GB也很常见，而且大文件在GFS中可以被有效地管理。另外，GFS主要采取主从结构（Master-Slave），通过数据分块､追加更新等方式实现海量数据的高速存储。

随着数据量的逐渐加大､数据结构的愈加复杂，最初的GFS架构已经无法满足对数据分析处理的需求，Google公司在原先的基础上对GFS进行了重新设计，升级为Colosuss，单点故障和海量小文件存储的问题在这个新的系统里得到了很好的解决。

除了Google的GFS以及Colosuss，HDFS､FastDFS和CloudStore等都是类似于GFS的开源实现。由于GFS及其类似的文件处理系统主要用于处理大文件，对图片存储､文档传输等海量小文件的应用场合则处理效率很低，因此，Facebook开发了专门针对海量小文件处理的文件系统Hay-stack，通过多个逻辑文件共享同一个物理文件，增加缓存层､部分元数据加载到内存等方式有效地解决了海量小文件存储的问题；此外，淘宝也推出了类似的文件系统TFS（Taobao File System），针对淘宝海量的非结构化数据，提供海量小文件存储，满足了淘宝对小文件存储的需求，被广泛地应用在淘宝各项业务中。

 

HDFS 是Hadoop 的分布式文件系统，为分布式计算提供底层存储支持。HDFS 将文件划分成多个数据块并为各数据块建立多个副本进行分布式冗余存储确保数据的高可用性。HDFS 采用了主从（Master/Slave）结构模型，一个HDFS 集群由一个NameNode 和若干个DataNode 组成。其中NameNode作为主服务器（Secondary NameNode 是NameNode 的元数据信息的备份节点），管理文件系统的命名空间和客户端对文件的访问操作；DataNode 负责存储数据。Secondary NameNode定期从NameNode上下载元数据信息（元数据镜像fsimage 和元数据操作日志editlog），然后将fsimage 和editlog 合并成一个新的fsimage，在本地保存（Checkpoint），并将其推送至NameNode，同时重置NameNode上的editlog。NameNode 维护分布式文件系统的命名空间，同时负责维护数据块到具体DataNode 的映射。DataNode 负责处理Client的文件读写请求，并在NameNode 的统一调度下进行数据块的创建、删除和复制等工作。

HDFS 集群主要由NameNode（名称节点）和DataNode（数据节点）组成，其中名称节点是来管理元数据的而数据节点是用来存储实际数据的。HDFS 的特性包括：支持超大文件，检测到硬件故障并快速响应，流式数据访问，简化的一致性模型。HDFS 具有高容错性，它可以部署在廉价的通用硬件上，并可以提供高吞吐率的数据访问，适合那些需要处理海量数据集的应用程序。HDFS 没有遵循可移植操作系统接口的要求，而是提供了一套特有的，基于Hadoop 抽象文件系统的API，支持以流的形式访问文件系统中的数据。

我们知道，为了便于管理，设备往往将存储空间组织成为具有一定结构的存储单位。如磁盘，文件是以块的形式存储在磁盘中，块的大小代表系统读/写操作的最小单位；在Linux 的EXT3 或EXT4 格式的文件系统中，数据块默认为4096字节。对于系统使用者来说数据块管理的内部细节是不需要了解就能轻松的使用的。

HDFS 也有块的概念（即Block[21]），不过是更大的单元，默认的HDFS 数据块大小是64MB。和一般文件系统相似，HDFS 上的文件也分块的。HDFS 是针对大文件而设计的分布式文件系统，使用数据块可以带来很多好处，具体如下：

(1) HDFS 可以保存比存储节点单一磁盘容量大的文件文件块可以保存在不同的磁盘上。其实，在HDFS 中，文件数据可以存放在集群上的任何一个磁盘上，不需要保存在同一个磁盘上，或同一个机器的不同磁盘上。

(2) 方便容错，有利于数据复制数据块会在不同的机器上进行复制，通常为3 份副本，如果一份数据块的丢失或损坏时，系统会找到其他地方副本来读，这个过程对用户来说是透明的，它实现了分布式系统中的位置透明性和故障透明性。同时，一个数据块因损坏或者机器故障而缺失，那么会从其他有这个数据块的地方复制到另外一个机器上，以确保数目恢复到设置好的水平（即3 个副本）。

Namenode也叫名字节点，是HDFS 的master-slave 结构中master 节点上运行的核心进程，它指导master-slave 结构中的slave 节点，数据节点具体操作底层的输入输出工作。

Namenode 是HDFS 的核心，对整个分布式系统的整个目录树进行维护，记录着文件/目录的元数据情况和文件的数据块索引，即每个文件的数据块对应表。这些信息以两种形式存储在本地文件系统中：一种是命名空间镜像即FSImage，另一种是命名空间镜像的编辑日志即Edit Log。

名称节点的FSImage 存储着一特定时刻的HDFS 目录树、元数据信息和数据块索引和其他信息，对这些变化的跟踪信息，存储在编辑日志，它们一起提供了一个完整的命名空间。

在fsimage 里，没有每一块的数据节点对应表的信息记录，但简单地存储所有有关命名空间的相关信息。对应于真正的每一块数据节点列表信息在Hadoop并没有持久性存储，但在所有数据节点启动时，每个数据节点扫描本地磁盘，保存数据节点块信息汇总并告诉名称节点，名称节点在收到到每一个数据节点的块讯息的反馈后，得到了这些数据块讯息，并在名称节点中将这些数据节点的讯息存储在名称节点的内存中。HDFS 就是采取这种数据库讯息报告的形式来搭建块-> 数据节点的对应表结构的。数据节点的数据块信息汇报过程叫做blockReport，而名称节点将块 -> 数据节点的对应表信息保存在叫做BlocksMap 的地方。

HDFS 里面数据块是保存在Datanode（数据节点）上的，part-0 文件有2 个副本且由1 号和3 号这2个数据块组成，part-1 文件有3 个副本且由2 号4 号5 号这3 个数据块组成。以linux 文件系统上的一般文件进行存储。数据节点是一个文件系统的实际执行者是个工人。数据节点保存数据块还提供定位块的工作，而且每过一段时间的向名称节点汇报它们保存的数据块的列表。这样名称节点就知道某个文件中包含哪些数据块，且在哪些datanode 上，但并不知道datanode 上的存放具体位置。同时数据节点知道他们的机器的数据块的具体位置，但不知道这些数据块属于哪个文件。客户端需要读取文件时先由名称节点通知它各个数据块保存在哪一个数据节点上，然后它就可以和这个数据节点进行直接通信，处理与数据块对应的本地文件。并且默认每个数据块有多个副本，并分布在不同的数据节点上，确保冗余性万一哪台数据节点宕机时也不影响整个系统的数据，也提供了数据就近读取的可能，提高了数据的读取的性能。

Yarn

YARN 是apache 的新一代的框架，它是将原mapreduce 框架中的jobtracker的任务拆开变成两个单独的任务：其中一个是作为整个集群的资源管理器（Resource Manager）和另一个是各个应用程序独有的任务即应用管理器（Application Master）。其中，整个hadoop 的资源分配以及管理是由资源管理进程负责，而解决单个应用程序的管理任务的是应用管理进程。当用户提交一个应用程序时，需要提供一个用于跟踪和管理这个程序的应用管理器。这个程序的任务是向资源管理器请求各种资源，同时请求节点管理器启动一个可以利用一部分资源的任务。因为各个应用管理器分散在各个不同的节点上，所以各个应用管理器之间不会彼此影响。

YARN 的工作可以分为以下几个步骤：

步骤1 用户向YARN 提交应用程序，其中包括应用管理器程序、启动应用管理器的指令、用户程序等。

步骤2 资源管理器为这个程序安排第一个容器（Container），和相关的节点管理器进行通信，要求它在这个容器中启动这个程序的应用管理器。

步骤3 应用管理器需要先向资源管理器进行注册，然后用户可以在资源管理器中查看应用程序的运行状态，随后，它将申请资源给各个任务，并监控其运行状态，一直到它运行结束为止，即重复步骤4-7。

步骤4 应用管理器采用轮询的方式，发送RPC 协议向资源管理器申请资源和领取资源。

步骤5 当应用管理器申请到资源后，就和相应的节点管理器进行通信，要求它启动任务。

步骤6 节点管理器为任务设置好运行环境（包括运行变量、jar 包、二进制程序等）后，在一个脚本中写入任务启动命令，最后通过运行该脚本启动任务。

步骤7 任务将自己运行情况的信息通过RPC 协议向应用管理器汇报。让应用管理器时刻了解各个任务的运行情况，这样就可以在任务失败时进行重新启动任务。在应用程序运行的过程中，用户可以时刻从RPC 协议向应用管理器查询到应用程序的进度和当前运行状态。

步骤8 应用程序运行完成后，应用管理器向资源管理器注销，并关闭自己这个程序。

MapReduce

MapReduce技术是Google公司于2004年提出，作为一种典型的数据批处理技术被广泛的应用于数据挖掘､数据分析､机器学习等领域， MapReduce因为它并行式数据处理的方式已经成为大数据处理的关键技术。

MapReduce系统主要由两个部分组成：Map和Reduce。MapReduce的核心思想在于“分而治之”，也就是说，首先将数据源分为若干部分，每个部分对应一个初始的键-值（Key/Value）对，并分别给不同的Map任务区处理，这时的Map对初始的键-值（Key/Value）对进行处理，产生一系列中间结果Key/Value对，MapReduce中间过程Shuffle将所有具有相同Key值的Value值组成一个集合传递给Reduce环节；Reduce接收这些中间结果，并将相同的Value值合并，形成最终的较小Value值的集合。MapReduce系统的提出简化了数据的计算过程，避免了数据传输过程中大量的通信开销，使得MapReduce可以运用到多种实际问题的解决方案里，公布之后获得了极大的关注，在各个领域均有广泛的应用。

MapReduce 的计算框架，是为解决这样一类问题非常适合：问题可以分解为若干个子问题，且相互独立，互不包含，可以通过并行处理这些子问题后，来解决这个任务的。map()函数以键值对作为输入，产生一系列的 键值对写入本地磁盘作为中间输出。MapReduce 框架会自动将这些数据按照key 值进行汇集，且key 值相同（用户可设定汇集的策略，默认情况下是对key 值进行哈希取模）的数据被统一交给reduce()函数处理。reduce()函数以key 及对应的value 列表作为输入，经合并key 相同的value 值后，产生另外一系列键值对作为最终输出写入HDFS。早先版本mapreduce 中jobtracker 包含资源管理和任务调配2 大功能，而由于YARN 的产生，已经将资源管理功能放入YARN 的资源管理器中，Mapreduce（V2）计算框架仅需要一个在YARN 上运行的应用管理器即可。

Hive

Hive是一个基于Hadoop的数据仓库平台和SQL基础结构，是Facebook在2008年8月开始开源的一个数据仓库框架。Hive将数据存储在Hadoop中的HDFS文件系统中，并提供了一套类似于关系型数据库的处理机制。

Hive采用了一种类SQL语言：HiveQL，对数据进行管理，经过解析和编译，这种HiveQL最终生成基于Hadoop的MapReduce任务。最后，Hadoop通过执行这些任务完成查询任务和数据处理。和传统的数据库相比，Hive也是将数据存储于表中，表的每一列都有一个相关的类型。Hive支持常见的的原语类型并支持复合类型。再加上其查询语言与SQL极其相似，因此，Hive很容易被用户接受并掌握。

Hive采用了RcFile(Record Columnar File)这种数据存储结构。RCFile基于HDFS，每个表可能占用多个HDFS块。而每个HDFS块中的所有记录又分成多个行。RCFile通过采用对表格数据的不同压缩算法、数据追加、限制行组大小等机制使得Hive够很好地满足基于MapReduce的数据仓库所要求的四个条件：①快速数据加载；②快速的查询处理；③高效的存储空间利用；④对高度动态负载模式的较强适应性。

在HBase中，对数据仅提供了基本的数据插入、读取语句，这种语句能做的事情非常有限，并且不支持常用的类SQL语句的查询方式，所以在此将HBase与Hive整合，由Hive提供的强大搜索接口——HiveQL来进行数据分析工作，它支持绝大多数常见的原语类型，查询语言与SQL极其相似。

Hive可以将结构/非结构化的数据文件映射成一张虚拟的表，基于这张表，提供基于HiveQL的查询功能。但从实现过程上来看，Hive最终还是将查询语句转换为MapReduce程序提交执行。相对于具有同样功能的MapReduce程序而言，执行效率有所降低，但它的学习成本低，可以直接进行基于MapReduce的各项工作，而不必开发专门的MapReduce应用，适合对数据仓库进行快速的离线分析。

HBase与Hive均属于Hadoop的子项目，因此两者具有比较好的兼容性。通过修改配置文件，将两者有效地集成到一起。集成后，Hive可以通过HBase的库函数访问到存储在HBase中的数据，同时也可以使用HiveQL语言对其进行检索操作。

HBase

HBase是基于Apache Hadoop的、分布式的、多版本的、面向列的数据库，能够对大型数据提供随机、实时的读写访问。

其技术特点：支持很高的写吞吐；有良好的随机读性能；高可用性，故障可恢复性；错误隔离性。一个结点的错误不会影响到其它结点，磁盘故障只会对相应的小规模的数据产生影响。可在廉价PC Server搭建大规模结构化存储集群。横向扩展性强。

分布式的HBase系统应用架构如下：

 

为客户端提供访问入口，存贮所有Region的寻址入口；选举HBase集群中的master，确保任何时候，只有一个master；实时监控Region Server的状态，将Region server的上线和下线信息实时通知给Master；存储Hbase的schema,包括有哪些table，每个table有哪些column family。

Hbase的服务器体系结构遵从简单的主从服务器架构，由Hregion服务器群和HBase Master主服务器构成。在整个架构中负责数据的读写、调度等。Master主要负责Table和Region的管理工作；RegionServer主要负责响应用户I/O请求，向HDFS文件系统中读写数据。

Hadoop文件系统也是主从架构，由唯一一个目录节点和数个数据节点组成。在整个架构中负责数据的物理存储。

Client包含访问hbase的接口，client维护着一些cache来加快对hbase的访问，比如regione的位置信息。client访问hbase上数据的过程并不需要master参与（寻址访问zookeeper和region server，数据读写访问regione server），master仅仅维护者table和region的元数据信息，负载很低。

HBase以表的方式存储数据。表是由行和列构成的，列从属于某一个列族（column family）。行和列的交叉点称之为cell，cell是版本化的。cell的内容就是数据，cell中的数据是没有类型的，全部是字节码形式存贮，是不可分割的字节数组。HBase表中的所有行都按照row key的排序的，一个表 在行的方向上分割为多个region。region按大小分割的，每个表一开始只有一个region，随着数据不断插入表，region不断增大，当增大到一个阀值的时候，region就会等分会两个新的region。

region是Hbase中分布式存储和负载均衡的最小单元。不同的region可以分布在不同的Region server上。但一个region是不会拆分到多个server上。Region虽然是分布式存储的最小单元，但并不是存储的最小单元。Region由一个或者多个Store组成，每个store保存一个columns family。每个Strore又由一个memStore和0至多个StoreFile组成。如图：StoreFile以HFile格式保存在HDFS上。

Hbase的服务器体系结构遵从简单的主从服务器架构，由region服务器群和 Master主服务器构成。尽管是主从架构，但是，Master没有单点问题。HBase中可以启动多个Master，通过Zookeeper的Master Election机制保证总有一个Master在运行。Master主要负责Table和Region的管理工作：处理用户对表的schema更新请求，增、删、改表结构。管理RegionServer的负载均衡，调整Region分布。 Region Split后，负责新Region的分布。在RegionServer停机后，负责失效RegionServer上Region迁移。

RegionServer是HBase中最核心的模块，主要负责响应用户I/O请求，向HDFS文件系统中读写数据。RegionServer管理一些列HRegion对象；每个HRegion对应Table中一个Region，HRegion由多个HStore组成；每个HStore对应Table中一个Column Family的存储；Column Family就是一个集中的存储单元，故将具有相同IO特性的Column放在一个Column Family会更高效.

Store 是HBase存储的核心。由一个MemStore和多个StoreFile组成。用户写入数据时，HStore工作机制：数据首先放入MemStore。当MemStore满了以后会Flush成一个StoreFile（底层实现是HFile）。当StoreFile文件数量增长到一定阈值，会触发Compact合并操作，将多个StoreFiles合并成一个StoreFile，合并过程中会进行版本合并和数据删除。当StoreFiles Compact后，会逐步形成越来越大的StoreFile，当单个StoreFile大小超过一定阈值后，会触发Split操作，把当前Region Split成2个Region，父Region会下线，新Split出的2个孩子Region会被HMaster分配到相应的HRegionServer上，使得原先1个Region的压力得以分流到2个Region上。根据以上过程可知，HBase只是增加数据，有所得更新和删除操作，都是在Compact阶段做的，所以，用户写操作只需要进入到内存即可立即返回，从而保证I/O高性能。

Mahout

Apache Mahout是Apache开发的一个全新的开源项目，其主要目标是创建一些可伸缩的机器学习算法，供开发人员在Apache的许可下免费使用。

Mahout包含许多实现，包括集群、分类、CF(Collaborative Filte—ring)和进化程序。此外，通过使用Apache Hadoop库，Mahout可以有效地扩展到云中。用Mahout来构建推荐系统，是一件既简单又困难的事情。简单是因为Mahout完整地封装了“协同过滤”算法，并实现了并行化，提供非常简单的API接口；困难是因为我们不了解算法细节，很难根据业务的场景进行算法配置和调优。

常用的使用Mahout实现的算法有：基于用户的协同过滤算法UserCF、基于物品的协同过滤算法ItemCF、SlopeOne算法、KNN Linear interpolation item—based推荐算法、SVD推荐算法和Tree Cluster—based推荐算法等。

Sqoop

Sqoop项目开始于2009年，最早是作为Hadoop的一个第三方模块存在，后来为了让使用者能够快速部署，也为了让开发人员能够更快速的迭代开发，Sqoop独立成为一个Apache项目。Apache Sqoop项目旨在协助RDBMS与Hadoop之间进行高效的大数据交流。用户可以在Sqoop的帮助下，轻松地把关系型数据库的数据导入到Hadoop与其相关的系统(如HBase和Hive)中；同时也可以把数据从Hadoop系统里抽取并导出到关系型数据库里。除了这些主要的功能外，Sqoop也提供了一些诸如查看数据库表等实用的小工具122I。

理论上，Sqoop支持任何一款符合JDBC规范的数据库，如DB2、MySQL、SQL Server等。现有的成功案例是微软的SQL Server 2012，SQL Server 2012支持的Hadoop连接器的基础是Sqoop连接器，主要目标是提供SQL Server与Hadoop之间的数据转换，即结构化数据与非结构化数据之间的双向数据传输。

1. 1. Spark

Spark 是UC Berkeley AMPLab于2009年发起的，然后被Apache软件基金会接管的类Hadoop MapRe鄄duce通用性并行计算框架，是当前大数据领域最活跃的开源项目之一。Spark是基于MapReduce计算框架实现的分布式计算，拥有Hadoop MapReduce所具有的优点；但不同于MapReduce的是中间输出和结果可以保存在内存中，从而不再需要读写HDFS，因此Spark更适用于数据挖掘与机器学习等需要迭代的算法。逻辑回归算法在Hadoop和Spark上的运行时间对比图，可以看出Spark的效率有很大的提升。Spark由Scala语言实现的，Scala是一种基于JVM的函数式编程语言，提供了类似DryadLINQ的编程接口。而且Spark还提供修改的Scala语言解释器，能方便地用于交互式编程，用户可以定义变量、函数、类以及RDD。

Spark称为快数据，比Hadoop的传统处理方式MapReduce有着很大的差别，效率至少提高100倍以上。Spark分为四大模块：Spark SQL-RDD（数据执行的基本单元），MLlib（机器学习）、Graphx（图计算），Spark Streaming（实时处理）。这四个部分的数据处理单元都是RDD。所以整个框架形成了大数据处理各种应用场景编程的一致性。同时，Spark是基于内存的编程模型，它可以把中间的迭代过程不放在磁盘中，直接数据不落地在内存中执行，极大地提高了它的执行速度。下面来介绍它的各个模块。

Spark SQL允许在SQL和HiveQL 中的相关查询表达式在Spark中的执行。这个组件的核心是一个新型的RDD，JavaSchemaRDD。JavaSchemaRDD是由Row对象和Schema描述行中每一列的数据类型。JavaSchemaRDD类似一个关系型数据库中的表。一个JavaSchemaRDD可以通过已存在的RDD，Parquet文件，一个JSON数据集或者存储在Apache Hive 通过HiveQL运行的数据来创建。

MLlib是一些常用机器学习算法和工具中非常突出的，分类，回归，聚类，协同过滤，降维，以及相关的优化原语。许多标准的机器学习方法可以归结为一个凸优化问题，例如一项任务，去找到一个凸面函数f的最小值，这个凸面函数依赖于可变的Vectorw向量，这个向量在一个Node 中叫做Weights权值，我们可以把这个在客观函数里写成最优化问题。MLlib 包括的评价指标有：精确度，回收，F值，ROC，精密回收曲线，曲线下面积(AUC)，AUC常用来比较模型，而精确度，回收，F值，ROC用来确定阀值。

GraphX是新的Spark用于图表和图形，并行计算的的API。在一个高层次上, GraphX 延伸了Spark RDD 通过引入Resilient Distributed Property Graph (弹性分布式属性图)：一个有向多重图与附加到每个顶点和边的属性。为了支持图形计算,，GraphX公开了一组基本的运算符(subgraph ，joinVertices，mapReduceTriplets) 以及一个最优的转变的Pregel API。此外， GraphX包含一个对图形Algorithms (算法)and builders(构建器) 不断增长的包集合，用以简化图形分析任务。从社交网络到语言建模，图形数据的增长规模和重要性，带动众多新图形并行系统(例如，Giraph and GraphLab)的发展。通过限制可以被表示计算的类型和引入新技术来划分和分配图形，这些系统能够有效地执行复杂的图形算法命令并远快于大多数普通的数据并行系统。

如果要用一句话来概括Spark Streaming的处理思路的话，那就是“将连续的数据持久化，离散化，然后进行批量处理”。SparkStreaming是Spark核心的扩展API,允许使高通量、容错实时数据流的流处理。数据可以从许多来源摄取如Kafka，Flume，Twitter，ZeroMQ或普通TCP套接字和使用复杂的算法表达式处理的高级函数如：map, reduce, join 和window 的数据。最后处理过的数据可以放到文件系统,数据库和可视化仪表板上。事实上,你可以引用内置的Spark的机器学习算法,数据流图处理算法。

Spark应用程序在集群上是一个独立运行的过程，在你的主程序中有SparkContext对象协调（驱动程序）。SparkContext可以连接多种类型的Cluster managers（Spark’s own standalonecluster manager or Mesos/YARN），跨应用程序分配资源。一旦连接，Spark获得集群中节点的Executors（执行权），应用程序进行计算和存储数据是一个过程。接下来，它将发送你的程序代码（JAR或Python文件传递给SparkContext）到executors。最后，SparkContext发送tasks给executors执行。

RDD(Resilient Distributed Datasets)弹性分布式数据集是分布式内存的一个抽象概念，RDD设计了一种高度受限的共享内存模型，通过在其他弹性分布式数据集执行确定转换操作而创建，这些限制使得容错实现的开销代价降低。Spark的设计思想是在任务和数据的容错方式基础上，设计出一种全新的容错方式模型，能够减少网络流量及磁盘输入输出开销。RDD是一种只读数据块，可以通过从存储系统上读取数据或者进行其他RDD操作。RDD数据的只读特性表示如果对一个RDD数据块进行了操作，那么结果将会是一个新的RDD，这种情况放在代码情景下，假设变换前后都是使用同一个变量表示这一RDD，RDD里面的数据意义并不是真实的数据，而是一些元数据信息。

RDD具有以下五个方面的特性：1)分区列表(数据块列表)；2)计算每个分片的函数；3)对父RDD的依赖列表；4)对Key—Value RDD的Partitioner；5)每个数据分片的预定义地址列表。RDD的生成有两种方式：1)从文件系统输入(例如HDFS)创建；2)从父RDD转换得到新RDD。RDD提供了四种算子：输入算子、变换算子、缓存算子和行动算子，其中MapReduce的Map算子和Reduce算子也被封装入RDD的变换算子，可以说Spark RDD在继承MapReduce优秀基因的同时提供了更为丰富的接口和操作。广播变量(Broadcast)是Spark的一种共享变量。这类变量解决了并行时个相互隔离的节点之间需访问的公共变量的存储问题。需注意的是广播变量是只读的，变量被广播后即不能再被修改。

Spark提供多种计算方式，使其他成为高效的数据流水线，提供了复杂查询，流式计算、机器学习、图计算等功能。Spark支持scala、python和java评议，提供了shell，方便与用户交互。Spark可以运行在Hadoop数据源上，如HDFS、Hive、HBase等，这样的一种特征，可以让Spark开发者及用户轻易地从原系统迁移到Spark系统上来。

Spark计算模型采用Lambda Architecture架构处理批量及实时流数据，Lambda Architecture 架构分为三层：包括BatchLayer批处理层、Serving Layer服务层以及Speed Layer速度层。其中批处理层设计基于Hadoop计算模型，在Spark平台上开发的图计算框架GraphX和机器学习库Mllib可作为批量数据分析。服务层可以接收外部ad-hoc查询请求，利用Shark等索引服务对批量处理层的结果进行索引，完成准实时的SQL查询任务。速度层采用Spark Streaming分布式的流处理平台实时处理数据成查询处理。

JavaHdfsLR是逻辑回归分类算法的Spark实现，采用渐进梯度下降模型。使用SGD加上诸如牛顿-拉普森的近似法来预测似然函数。输入数据集及输出结果都是Hadoop分布式文件系统中的文件。

使用SVMModel内部类表示训练过程中返回模型对象以及SVMWithSGD。支持向量机的工作流：

1）创建Spark上下文。2）加载已标记的输入训练数据，SVM中用到的标记必须是{0，1}。3）使用由{label,features}对及其他输入参数组成的RDD输入来训练模型。4）使用输入数据来创建一个类型为SVMWithSGD的对象。5）调用GenerallizedLinearModel重写后的run()方法，它会使用预配置的参数在输入RDD的LabeledPoint上运行算法，并对所有输入特征的初始权重进行处理。6）获得一个SVM模型对象。7）终止Spark上下文。

Spark适用于那些在多个并行操作之间重用数据的应用， 而MapReduce在这方面效率并不高， 因为MapReduce和DAG引擎是基于非循环数据流的，即一个应用被分成一些不同的作业，每个作业从磁盘中读数据，然后再写到磁盘。Spark不太适合那些异步更新共享状态的应用，例如并行Web爬行器。

迭代式算法，许多机器学习算法都用一个函数对相同的数据进行重复的计算， 从而得到最优解。MapReduce计算框架把每次迭代看成是一个MapReduce 作业， 而每个作业都要从磁盘重新加载数据，这就导致了效率不高，而Spark可以把中间数据缓存到内存中加快计算效率。

交互式数据分析，用户经常会用SQL对大数据集合做临时查询（Ad-Hoc Query）。Hive把每次查询都当作一个独立的MapReduce作业，并且从磁盘加载数据，有很大的延迟，而Spark可以把数据加载到内存中，然后重复的查询。

流应用：需要实时处理的应用，这类应用往往需要低延迟，高效率。

1. 1. Storm

实时计算具备分布式、低延迟、高性能、可扩展、高容错、高可靠、消息严格有序、定制开发等特点。在整个计算过程中，实时计算引擎与各处理单元均处于运行状态，接收源源不断流进的消息，进行任务的分配、调度、路由、计算，最后将处理结果进行存储。

通常，实时计算引擎由数据读取、模型转换、逻辑处理等组件组成，数据读取组件从外部数据源源源不断的读取数据，然后依据内容数据模型转换为内部源数据，让后交由逻辑处理组件进行数据处理，处理内容包括了过滤、计算、合并、存储等操作，处理完毕后将结果写入目的数据源。

实时计算主要含有几个关键的特性：

(1) 数据处理的低延迟。对于实时计算的系统来说，最关键的指标就是计算的延迟，从输入到输出，整个并行处理的时间越少越好，基本需要延迟在毫秒级，才可以称得上是实时计算。

(2) 良好的系统容错性。由于延迟低、吞吐高，所以容错成了实时系统中的一个难点，各种故障有可能经常发生，而对每个数据就记录其负责的状态又太浪费存储资源，计算框架必须容忍故障的多发性。

(3) 很好的机器扩展能力。实时计算系统除了常规的扩展要求以外，还需要在扩展机器后，能同时不增加系统的延迟，不能因为满足高扩展而使得规模扩大明显降低系统的处理速度。

(4) 灵活的计算逻辑表达能力。实时计算系统需要在多阶段处理的任务中满足比较好的逻辑表达且不影响计算效率。

 

Storm 是一个分布式的、可靠的、容错的数据实时流式处理系统，Spout 是Storm 中的消息源， 用于为Topology 生产消息， 一般从外部数据源（如MessageQueue、RDBMS、NoSQL、Log）不间断地读取数据并发送Tuple 给Bolt 进行数据操作，Bolt 是Storm 中的消息处理者，用于为Topology 进行消息处理，Bolt 可以执行过滤、聚合、查询数据等操作，而且可以一级一级地进行处理。这种Topology 模型采用消息传递方式交互数据，数据量相比较从磁盘获取要小，而且动态地读取，每次读取量小。

Storm 的高可靠性和容错性主要集中体现在Storm的数据重发机制上，由于每个Bolt 可以启动多个task，每个task 都会带有一个唯一标示的ID，Storm 将此ID持久化，在数据重发时候读取发送失败的task 的ID 状态，重发发送数据，保证了数据的一致性，这明显优于S4 实时流系统，而且Topology 递交之后，Storm 会一直运行直到主动释放Topology 或者kill 掉， 这明显要优于Hadoop 系统。Hadoop 的批处理和Storm 的实时流处理，本是两种不同的业务场景， 但是如果我们很好地进行融合和集成， 就会发现组合在一起的新型处理方案在性能和扩展性以及稳定性上都得到了提升。

Storm通常由主控节点（Master Node）和工作节点（Work Node）组成：

1、主控节点运行一个被称为Nimbus的后台程序，它负责在Storm集群内分发代码，分配任务给工作机器，并且负责监控集群运行状态；

2、工作节点运行一个被称为Supervisor的后台程序。Supervisor负责监听从Nimbus分配给它执行的任务，据此启动或停止执行任务的工作进程；

3、Nimbus和Supervisor节点之间所有的协调工作是通过Zookeeper集群来实现的。此外，Nimbus和Supervisor进程都是快速失败（fail-fast)和无状态（stateless）的；Storm集群所有的状态要么在Zookeeper集群中，要么存储在本地磁盘上。这种设计使得Storm集群拥有不可思议的稳定性；

4、Zookeeper存储客户端提供的topology任务信息，nimbus负责将任务分配信息写入Zookeeper，supervisor从Zookeeper上读取任务分配信息；存储supervisor和worker的心跳，使得nimbus可以监控整个集群的状态，从而重启一些挂掉的worker；存储整个集群的所有状态信息和配置信息；

 

5、topology：一个拓扑是一个个计算节点组成的图，每个节点包换处理的逻辑，节点之间的连线表示数据流动的方向；

6、spout：表示一个流的源头，产生tuple；

7、bolt：处理输入流并产生多个输出流，可以做简单的数据转换计算，复杂的流处理一般需要经过多个bolt进行处理；

8、stream grouping：即消息的partition方法,提供若干种实用的grouping方式，包括shuffle, fields hash, all, global, none, direct等；

9、stream：对数据进行的抽象，是时间上无界的tuple元组序列，Spout是Stream的 源头，负责为Topology从特定数据源发射Stream；

10、tuple：表示流中一个基本的处理单元，可以包括多个field，每个filed表示一个属性；

11、Java序列化：client提交topology任务后，Storm将topology任务序列化并发送给nimbus；supervisor从Zookeeper取得任务信息后，从nimbus下载序列化文件和jar包，启动worker进程并反序列化得到提交任务时的topology对象。

Storm之于实时处理，就如Hadoop之于批处理。

Storm可用于实时计算、实时监控、实时统计等场景，通常与分布式数据库Hbase一起使用。Storm保证每个消息都会得到处理，而且它很快——在一个小集群中，每秒可以处理数以百万计的消息。

Storm架构主要由两种节点构成：Nimbus(主控节点)和Supervisor(工作节点)。集群由主控节点协调控制，主控节点主要负责分配计算任务、容灾控制和传输代码包等协调管理功能。集群中其它服务器机器作为工作节点，随时候命，等待主控节点的命令，根据其命令开启或停止负责的计算任务，每个工作节点可以作为多个拓扑任务的计算。

ZooKeeper集群也用作状态信息的存储，每次状态的改变，Nimbus和Supervisor都会把数据存储在集群上，这样所有节点都是无状态的服务，可以轻易的进行故障恢复，一旦有节点出现故障，可以随时在另一台机器上启动相同的服务节点，不会丢失任何状态信息，防止Storm 集群的不可恢复。但是这里的故障恢复指的是Storm 的管理状态信息，具体计算任务的状态信息还需要用户自己存储。

Storm 的DAG 拓扑结构中，计算节点分为两类，一类是计算任务的数据输入节点Spout，它负责和外部进行数据传输，转换数据格式，然后把输入的数据发到下游的计算节点中，外部输入一般是Kafka类似的消息系统。另一类是进行具体计算的节点Bolt，Bolt 接收上游传输过来的数据，进行用户定义的计算，产生衍生的数据，并发传输到下游节点，Bolt 之间通过特定的接收方式串接起来构成一个DAG图。计算任务往往是可以分解的，可以将复杂的计算任务分解成多个计算节点构成的DAG图，计算节点之间通过拓扑结构嵌套关联起来，Storm 的DAG 结构中比较常见的一些基本拓扑结构包含：流水线、随机分组、直接分组、全部分组和字段分组。流水线(Pipeline)就是将多个计算任务通过数据流连接起来，每个节点只专注自己的工作。

随机分组(Shuffle grouping)是指并发的两个计算任务之间比较均衡的拓扑结构。直接分组(Direct grouping)是一个特殊的拓扑结构，上游节点可以获取到下游节点的每个编号，它将由用户动态指定数据的目的地。

全部分组(All grouping)在数据分发模式上和其它的结构都不同，在分发数据时，会把数据拷贝多份，发往每一个下游节点中。

字段分组(Fields grouping)和随机分组在基本结构上类似，不同的是在发送数据时下游节点的选取上，随机分组随机的选取下游节点，而字段分组是通过定义的某个或某些字段来进行特殊计算后得到的下游节点，具体的计算可能是哈希后取余的方式，也可以是一致性哈希的方式。字段分组保证了拥有相同字段的数据可以被分发到固定的计算节点中。

Storm 支持“至少送达一次”的语义，Storm 使用一种特殊的Acker 节点实现送达保证，Acker 节点会追踪Spout 节点发射的每个数据，进而通知Spout 节点数据的完成情况。Spout 节点在发射数据时会赋予一个随机的64 位的消息ID，Acker 会维护ID和追踪值的Key/Value 对，当追踪值为零时表示数据处理完成，当此值超时通知Spout 重发。Bolt 节点接收到数据时会通知Acker 使用相同的ID 来对相应的追踪值进行异或(XOR)操作，Bolt 节点产生的数据，也会生成随机的ID 值。这样，如果其追踪值变为数值零，则表示Storm 已经成功处理完成这条数据，而超时则代表处理失败。使用异或的方式来实现送达保证并不能保证完全的可靠，因为有不同的数异或等于零的情况，但是这种情况可能性非常低，小到可以忽略不计，绝大多数场景都没有什么问题。

Storm是成熟的实时计算引擎，具备如下特点：

1、简单的编程模型：降低并行批处理复杂性，降低实时处理复杂性；

2、支持各种编程语言：可以使用各种编程语言，需要支持Java、Ruby、Python等，并可以通过增加通信协议的方式增加对新语言的支持；

3、支持容错：管理工作进程和节点的故障；

4、支持水平扩展：计算是在多个线程、进程和服务器之间并行进行的；

5、可靠的消息处理：保证每个消息至少能得到一次完整处理。任务失败时，它会负责从消息源重试消息；

6、高效消息处理：系统设计保证消息能得到快速的处理，使用队列作为其底层消息队列。

Storm最大的缺点是不支持批计算模型，很多过程需要拿到一定量的数据之后才可以开始计算，比如说数据的批量更新，如果简单的把历史数据保存在内存中，就会有数据丢失的风险。Trident是构建在Storm底层计算引擎上的一个以实时计算为目标的高级抽象，对Storm进行了批处理的封装，提供了易于理解的算子层，开发者可以进行类似Spark的算子运算，而不用关心底层逻辑。Tident提供了joins、aggregations、grouping、functions，以及filters等能力。除此之外，Trident 还提供了一些专门的原语，从而在基于数据库或者其他存储的前提下应付有状态的递增式处理。

Storm使用元组来作为它的数据模型，它可以看作一个没有方法java对象 。 每个元组由若干值成，支持任何类型包括常见的基本类型、字符类型等，甚至可以使用其他自定义的序列化类型，且每个值都有一个名字。一个元组代表数据流中的一个最基本的处理单元，比如一条日志，它可以包含多个列，每个列表示一个属性。元组只需要按序填入各个值，事先已经定义好各个组件间传递的元组的字段名称，一个元组就是值列表列表中的每个值都有一个名字，节点通过订阅标签可以接受处理单元。

Storm作为一个开源的实时分布式计算平台，有着以下几个优点：(1)其简单的编程模型降低了开发人员开发的难度，能够实现了快速、高效的开发应用；(2)Storm系统支持各种编程语言，默认支持clojure、Java、Ruby和脚hon。若需要实现对其他语言的支持，通过实现一个简单的stom通信协议就可以完成；(3)Storm系统具备高容错性，当某个任务失败时，Storm将会从消息源重新获取消息进行处理，这种方式能够保障spout发出的每条消息都被正确处理。Storm系统采用了发送方和应答方都需与系统内部的第三方acker进行异或随机数的方式来判断tuple是否丢失，若acker上记录的消息随机数为1则认为消息处理失败，acker将通知spout进行重放；(4)Stom系统支持水平扩展，只要增加节点即可增加其吞吐量并且减少时延；(5)Stmm系统支持本地模式，Storm系统能在进程中模拟Storm集群，提供集群所有的功能，即在单机上运行的topology和集群上运行topology，相似；(6)Storm系统采用了zeroMQ作为底层消息队列，保障了获取的消息能够被快速处理。

1. 1. ETL

数据集成是现有企业系统间集成解决方案中最普遍的一种形式，主要指将不同来源、格式、特点性质的数据在逻辑上或物理上有机地集中，从而为企业提供全面的数据共享。数据集成发生在企业内的数据库和数据源级别，通过从一个数据源将数据移植到另外一个数据源来完成数据集成。

ETL是对企业数据进行数据抽取（Extract）、转换（Transform）、装载（Load）的过程，负责将分布的、异构数据源中的数据如关系数据、平面数据文件等抽取到临时中间层后进行清洗、转换、集成，最后加载到数据仓库或数据集市中，成为联机分析处理、数据挖掘的基础。

ETL通过数据抽取、数据转换和数据装载的连续操作，将不同来源、不同格式的数据抽取到数据中心的主题数据共享区，经过转换，加载存储到星型结构的统计数据分析区，再在数据集市进一步分类汇总，以满足不同主题的展现、分析需要。

ETL是指从源系统中提取数据，转换数据为一个标准的格式，并加载数据到目标数据存储区，通常是数据仓库。ETL体系结构图如下所示：

 

ETL体系结构由核心服务组件、流程调度、ETL管理组成。核心服务组件由抽取、转换、加载组成；流程调度由传输服务、操作管理组成；ETL管理由设计管理器、元数据管理组成。

抽取：通过接口提取源数据，例如ODBC、专用数据库接口和平面文件提取器，并参照元数据来决定数据的提取及其提取方式；

转换：根据提取数据，按照业务需要转换为目标数据结构，并实现汇总；

加载：加载经转换和汇总数据到目标数据库中，可实现SQL或批量加载。

数据清洗：为实现企业数据质量准确、可靠，通过分析企业数据情况，归纳总结数据质量规则，并基于ETL进行数据质量规则配置，执行ETL，通过元数据管理，可发现具体的问题数据。

数据加载：由源数据库灵活将所需数据加载到目标数据库，供数据分析、展现使用。

数据归集到数据仓库：由多个源数据库向一个目标数据库复制，用于跨平台多系统的数据集成，为应用系统提供统一视图便于查询和统计，同时实现操作数据与分析数据分离。

数据集市：基于ETL技术，实现数据多层转换、加载至数据集市，在典型的数据中心应用中，业务应用系统数据可通过ETL方式抽取至数据中心ODS层，再从数据中心ODS层，加载到数据仓库层，最终到达数据集市。

传输服务：利用网络协议或文件协议，在源和目标系统之间移动数据，利用内存在ETL处理的各组件中移动数据；

操作管理：可让管理员基于事件和时间进行调度、运行、监测ETL作业、管理错误信息；

设计管理器：提供图形化的映射环境，定义从源到目标的映射关系、转换、处理流程。设计过程各对象的逻辑定义存储在统一的元数据资料库；

元数据管理：提供元数据资料库，存储关于ETL设计和运行处理等相关定义、管理信息。ETL引擎及其它应用都可参考此资料库中的元数据。

ETL管理简单，采用元数据方法，集中进行管理；接口、数据格式、传输有严格的规范；尽量不在外部数据源安装软件；数据抽取系统流程自动化，并有自动调度功能；抽取的数据及时、准确、完整；可以提供同各种数据系统的接口，系统适应性强；提供软件框架系统，系统功能改变时，应用程序很少改变便可适应变化；可扩展性强。

合理的业务模型设计对ETL至关重要。数据仓库是企业唯一、真实、可靠的综合数据平台。数据仓库的计建模一般都依照三范式、星型模型、雪花模型，无论哪种设计思想，都应该最大化地涵盖关键业务数据，把运营环境中杂乱无序的数据结构统一成为合理的、关联的、分析型的新结构，而ETL则会依照模型的定义去提取数据源，进行转换、清洗，并最终加载到目标数据仓库中。

模型的重要之处在于对数据做标准化定义，实现统一的编码、统一的分类和组织。标准化定义的内容包括：标准代码统一、业务术语统一。ETL依照模型进行初始加载、增量加载、缓慢增长维、慢速变化维、事实表加载等数据集成，并根据业务需求制定相应的加载策略、刷新策略、汇总策略、维护策略。

ETL的质量问题具体表现为正确性、完整性、一致性、完备性、有效性、时效性和可获取性等几个特性。而影响质量问题的原因有很多，由系统集成和历史数据造成的原因主要包括:业务系统不同时期系统之间数据模型不一致；业务系统不同时期业务过程有变化。

Informatica Corporation是全球首屈一指的独立数据集成软件提供商。通过 Informatica 的支持，世界各地的组织都将能够为其主要的业务需求提供及时、相关和可信的数据，使其在当今全球信息经济中获得竞争优势。目前，全球已有超过 4,630 多家企业依靠 Informatica 提供的解决方案访问、集成并信任其位于企业内外及云中的信息资产。

Informatica PowerCenter是Informatica核心产品，是专注于ETL领域的产品，是世界级的企业数据集成平台，它在ETL领域中无论是执行能力还是战略远见方面都是佼佼者。Informatica PowerCenter功能强大，支持各种数据源和目标系统，强大的转换、清洗与维护功能，灵活的作业调度，让企业在较短的时间内高质量的完成项目。尤其在海量数据处理、多线程并发处理、负载均衡等方面表现出良好的性能，连续在IDC、Gartner的ETL工具评比报告中名列第一。使用Informatica PowerCenter，企业能够通过“一次建立，任意部署”的方法从事多个不同的集成项目。Informatica独特的、以元数据为核心的架构体系，可以轻松的收集、管理、浏览元数据，受到全球遍及电信、金融、制造、零售、医疗等领域用户的好评与认可。

Informatica是基于元数据驱动的，所有的元数据都保存在Repository（中，该知识库可以创建在所有主流数据库当中，充分体现了它元数据的开放性。Repository Server用来管理所有客户端以及Informatica Server跟Repository的交互，并且一个Repository Server可以管理多个Repository，而Repository Server可为每个Repository分配一个Repository Agent来处理所对有元数据操作的响应。Informatica Server是实际处理ETL任务的后台服务，它是基于内存运行、高效的ETL服务，不需要产生任何的代码，每次执行任务之前都会从Repository中读取最新的ETL规则。Informatica的客户端提供了无编码、完全图形化的设计和管理调度界面，可实现快速开发和部署。

功能强大：支持多种数据库、套装软件、封闭式主机、EAI软件、文本以及“指令”；支持批次、近实时抽取，通过侦测LOG的技术减少对业务系统的效能影响；支持资料归档作业；经验证的主机码转码、造字难字处理、与主机资料规范化功能；支持Push-Down最佳化机制，可充分运用所有的软硬件设备；支持Enterprise Grid，首创不限制平台的Grid架构。

强调管理：逻辑设计与数据库独立，开发人员不需要直接接触实体数据库，符合IT管理需求；项目冲击性分析，当表级项出现异动时可透过此功能了解对其他表项的影响范围和评估；执行过程以甘特图的形式展现，可以跟踪执行状态，成功失败笔数，耗用资源等等，其日志LOG可存放到数据库中，便于提供后续的系统查询和整合。

提升开发生产力：图形化界面提升开发和维护生产力；内嵌超过100种运算，提供数据仓库模型载入时常用的Sequential Generator、Lookup以及其他常用函数如RANK等；支持数据仓库模型常用的Slowly Change Dimension功能，提供模版提升开发速度；支持数据库的Partitioning功能，可支持动态Partitioning，不需要人工调整Partitioning设定。

灵活性与开放标准：数据源和目的端的数据库可根据需要调整，不限制厂商，开发环境和生产环境可采用不同的厂商的数据库或文本文件，不需要重新编译；主动式Metadata，可存放在各种主流的开放式数据库中，可方便的进行移植；支持C、DCOM、JAVA、Stored Procedure，提供SDK，提升与外部集成的接口的弹性；支持SOA架构，可以成为Web Services的Consumer及Provider

性能优异： 7.7MB/sec/CPU or 27.72GB/hr/CPU的高性能，PowerCenter每次大版本的更新都会有很大的性能提高。

1. 1. 数据复制

数据复制是在数据库之间对数据和数据库对象进行复制和分发并进行同步，以确保其一致性的一组功能强大的技术，是一种实现数据发布的方法，它是把一个数据库服务器上的数据通过网络传输到一个或多个地理位置不同的数据库服务器的过程。

大数据平台采用数据复制技术，基于数据库的数据复制技术通过解析源数据库在线日志或归档日志获得数据的增删改变化，再将这些变化应用到目标数据库，实现源数据库与目标数据库同步、双活。

 

数据复制技术利用捕捉进程在源系统端读取在线日志或归档日志，然后进行解析，只提取其中数据的变化如增、删、改操作，并将相关信息转换为中间格式存放在队列文件中。再利用传送进程将队列文件通过TCP/IP传送到目标系统。捕捉进程在每次读完日志中的数据变化并在数据传送到目标系统后，会写检查点，记录当前完成捕捉的日志位置，检查点的存在可以使捕捉进程在中止并恢复后可从检查点位置继续复制。

目标系统接受数据变化并缓存到信息传输队列当中，队列为一系列临时存储数据变化的文件，等待投递进程读取数据。投递进程从队列中读取数据变化并创建对应的SQL语句，通过数据库的本地接口执行，提交到数据库成功后更新自己的检查点，记录已经完成复制的位置，数据的复制过程最终完成。

数据复制技术可以提供可靠的数据复制，主要体现在下面三点：

保证事务一致性

在灾备数据库应用复制数据库交易的顺序与在生产中心数据库上的顺序相同，并且按照相同的事务环境提交，确保在目标系统上数据的完整性和读一致性，为实时查询和事务处理创造了条件；

检查点机制保障数据无丢失

抽取和复制进程使用检查点机制记录完成复制的位置。对于抽取进程，其检查点记录当前已经抽取日志的位置和写队列文件的位置；对于投递进程，其检查点记录当前读取队列文件的位置。检查点机制可以保证在系统、网络或进程故障重启后数据无丢失；

可靠的数据传输机制

用应答机制传输交易数据，只有在得到确认消息后才认为数据传输完成，否则将自动重新传输数据，从而保证了抽取出的所有数据都能发送到备份端。

数据复制技术应用灵活，用户可以根据自己的需求选择特定的复制方式，并根据系统扩展对复制进行扩展，具体如下：

报表应用，由一个源数据库复制到一个目的数据库，一般用于高可用性和容灾，为生产机保持一个活动的备份数据库，从而在发生灾难的时候迅速切换，减少数据丢失和系统宕机时间；

双活容灾，利用数据复制技术可以实现两个数据库之间数据的双向复制，任何一方的数据变化都会被传递到另一端， 可以利用此模式开展双业务中心；

数据仓库，由多个数据库向一个数据库复制，可以将分布的、跨平台或异构的多个数据库集中到一个数据库。用于跨平台多系统的数据集成，为这些提供系统提供一个统一视图便于查询和统计；

数据分发，由一个数据库向多个数据库复制，利用数据过滤功能可以实现数据的有选择分发。

Oracle GoldenGate，是基于日志的结构化数据复制备份软件，它通过解析源数据库在线日志或归档日志获得数据的增量变化，再将这些变化应用到目标数据库，从而实现源数据库与目标数据库同步。

OGG可以在异构的IT基础结构之间实现大量数据亚秒一级的实时复制,从而在可以在应急系统、在线报表、 实时数据仓库供应、交易跟踪、数据同步、集中/分发、容灾、数据库升级和移植、双业务中心等多个场景下应用。同时，Oracle Golden Gate可以实现一对一、广播(一对多)、聚合(多对一)、双向、点对点、级联等多种灵活的拓扑结构。和传统的逻辑复制一样，OGG实现原理是通过抽取源端的redo log或者archive log，然后通过TCP/IP投递到目标端，最后解析还原应用到目标端，使目标端实现同源端数据同步。

GoldenGate 是高可用和实时数据整合的最优方案，协助关键系统保持 24*7 小时运作，满足最终用户连续可用的要求，帮助组织在企业范围内快速分发关键数据，以便及时和准确的决策。简而言之，GoldenGate 解决方案就是实时获取实时信息。

GoldenGate解决方案提供异构系统间事务数据实时捕获、路由、转换和投递，同时系统消耗最低。基于GoldenGate的数据复制方案，能够在异构环境下有效保护用户业务数据安全和业务连续性，并且具有高性能、高可靠性、高可扩展性。

Oracle GoldenGate软件是一种基于log(日志)的结构化数据复制软件，它通过解析源数据库在线log或归档log获得数据的增、删、改变化，再将这些变化应用到目标数据库，实现源数据库与目标数据库同步、双活。Oracle GoldenGate 软件可以在异构的IT基础结构（包括几乎所有常用操作系统平台和数据库平台）之间实现大量数据亚秒级的实时复制，其复制过程简图如下：

 

如上图所示，Oracle GoldenGate的数据复制过程如下：

利用捕捉进程(Capture Process)在源系统端读取Online Redo Log或Archive Log，然后进行解析，只提取其中数据的变化如增、删、改操作，并将相关信息转换为Oracle GoldenGate自定义的中间格式存放在队列文件中。再利用传送进程将队列文件通过TCP/IP传送到目标系统。捕捉进程在每次读完log中的数据变化并在数据传送到目标系统后，会写检查点，记录当前完成捕捉的log位置，检查点的存在可以使捕捉进程在中止并恢复后可从检查点位置继续复制；

目标系统接受数据变化并缓存到Oracle GoldenGate队列当中，队列为一系列临时存储数据变化的文件，等待投递进程读取数据。队列数据量一般只有log的四分之一左右；

Oracle GoldenGate投递进程从队列中读取数据变化并创建对应的SQL语句，通过数据库的本地接口执行，提交到数据库成功后更新自己的检查点，记录已经完成复制的位置，数据的复制过程最终完成。

由此可见，Oracle GoldenGate是一种基于软件的数据复制方式，它从数据库的log解析数据的变化。Oracle GoldenGate将数据变化转化为自己的格式，直接通过TCP/IP网络传输，无需依赖于数据库自身的传递方式，而且可以通过高达9:1的压缩率对数据进行压缩，可以大大降低带宽需求。在目标端，Oracle GoldenGate可以通过交易重组，分批加载等技术手段大大加快数据投递的速度和效率，降低目标系统的资源占用，可以在亚秒级实现大量数据的复制，并且目标端数据库是活动的。

Oracle GoldenGate支持多种拓扑结构，为用户数据复制方案的灵活性、先进性奠定基础，如图所示：

 

单向数据复制：由一个源数据库复制到一个目的数据库，一般用于高可用性和容灾，为生产机保持一个活动的备用数据库，从而在发生灾难的时候迅速切换，减少数据丢失和停机时间；

双向数据复制：利用Oracle GoldenGate可以实现两个数据库之间数据的双向复制，任何一方的数据变化都会被传递到另一端，可以利用此模式开展双业务中心；

广播复制：由一个数据库向多个数据库复制，利用Oracle GoldenGate的数据过滤功能可以实现数据的有选择分发；

集中复制：由多个数据库向一个数据库复制，可以将分布的、跨平台或异构的多个数据库集中到一个数据库。此种模式广泛应用于N+1模式的容灾，通过将多个系统数据库集中到一起，可以充分利用备份中心的设施，大幅减少投资；另外也用于跨平台多系统的数据集成，为这些提供系统提供一个统一视图便于查询和统计数据。

多层复制：由A数据库向B复制，同时又由B向C复制，可以在以上几种模式基础上无限制扩展。

由此可见，Oracle GoldenGate的复制模式非常灵活，用户可以根据自己的需求选择特定的复制方式，并根据系统扩展对复制进行扩展。

Oracle Data Integrator 利用开放的集成式 E-LT 架构在各种企业平台上提供高性能的数据移动和数据转换。它包含与所有主流数据库、数据仓库、面向对象的架构以及商务智能的内置连接，因此有助于降低各种以数据为中心的架构的总拥有成本。易用的界面与丰富的可扩展性框架的结合有助于提高生产力和降低开发成本。Oracle Data Integration与 Oracle 融合中间件、Oracle 数据库以及 Oracle 数据库云服务器 Exadata 充分集成，将数据置于企业的中心位置。此外，该产品具有开放性且基于标准，可与第三方应用程序和其他 Oracle 管理软件一起运行。主要特征：

提供了与以下内容的现成集成：数据库、ERP、CRM、B2B 系统、平面文件、XML 数据、LDAP 、JDBC 、ODBC。

知识模块框架支持可扩展性。

在所有数据库上通过 ETL 进行数据库内转换和数据完整性控制。

为 Oracle 数据库（包括 Oracle 数据库云服务器 Exadata）提供了丰富的 ETL，支持加载复杂的维度和多维数据集。

与 Oracle GoldenGate 集成，可进行实时数据仓储。

元数据驱动的数据沿袭与影响分析。

提供独立的以及在数据库内使用的数据分析、数据质量和数据治理选件。

主要优势：

通过改善的利用率和高性能数据集成削减了硬件成本。

在一个解决方案中统一了基于数据、基于事件和基于服务的集成。

通过最大限度地提高设计器的效率降低了总拥有成本。

开放、100% Java、SOA、基于标准。

支持异构源、目标和应用程序。

Oracle Data Integrator 是以 Java 图形模块和调度代理访问的模块化信息库为中心进行组织的。图形模块用于设计和构建集成过程，代理用于安排和协调集成任务。当 Oracle Data Integrator 项目投入生产时，数据管理员可以使用基于 Web 的 Metadata Navigator 应用程序来根据信息库中的元数据生成报告。现成的知识模块可以使用特定于平台代码和工具跨异构平台提取和加载数据。

 

Oracle Data Integrator 信息库包含一个主信息库（包含有关用户和角色的详细信息）、到数据库和其他数据源的连接、项目版本以及一个或多个工作信息库（包含数据模型的详细信息以及用于集成数据的映射）。这些信息库可以存储在 Oracle 和非 Oracle 关系数据库中，可以使用图形模块进行管理，并可以在运行时由代理进行访问。

有四个图形模块可用来创建和管理 Oracle Data Integrator 项目：

Designer 用于定义数据存储（表、文件、Web 服务等）、接口（数据映射）以及程序包（包括接口在内的几组集成步骤）。

Topology Manager 用于创建和管理到数据源和代理的连接，通常限制为只有管理员可以访问。

Operator 用于查看和管理产品集成作业。

Security Manager 管理用户及其信息库权限。

这些基于 Java 的应用程序可在包括 Microsoft Windows、Macintosh OS X 和 Linux 在内的任何 Java 环境中运行。

Oracle 数据集成套件采用了 Oracle 的核心技术，是业界功能最强大且最轻量数据集成解决方案。Oracle Data Integrator 提供了具有划时代意义的、完全基Java 的 E-LT 引擎，能够满足所有最重要的数据集成要求—从高容量、高性处理到事件驱动、少量供给集成流程以及支持 SOA 的数据服务。

 

 Oracle Data Integrator 的提取、加载和转换 (E-LT) 体系结构充分利用了不同的关系数据库管理系统 (RDBMS) 引擎来处理和转换数据。这种方法优化了性能和可扩展性，简化了数据中心体系结构，并降低了解决方案和维护成本。

Oracle Data Integrator 采用批处理、实时、同步和异步模式简化了系统间的数据移动和转换。其模块化设计和到所有主要数据库、数据仓库设备以及分析型应用程序的内置连接极大地提高了用户效率。

GoldenGate一般延时在几秒之内。能够保证源端和目标端的数据完整性。在项目应用中，主要注意以下几点：

1) 数据库归档模式；开启数据库附加日志；开启数据库强制日志模式。

2) 应要考虑数据初始化和增量的临界点，通过SCN来切或停业务的方式最好。初始化最好用RMAN或expdp的方式。初始化一定要检查最长事务的情况，从DB的方面结束长事务。这里的长事务是指涉及到的复制表的DML长时间没提交，而归档也找不到这个事务的头的。

3)    增量同步过程，OGG的捕获、传输、交付进程都会有严格的检查点机制，保证不会有丢数据的情况。

4)合理化参数，例：增量过程一定要关闭HANDLECOLLISIONS 参数。

5)默认是只要有一条数据同步错误，OGG链路就会报错中断。

6)一旦中断最好要查清楚，到底是什么原因中断的。例如通过 view report repxx  和logdump等，再结合DB的手段来查。之所以出错肯定是有原因的，应该找到原因。切不可急于恢复链路，而丢失这些错误痕迹。

7)如果复制表中有建触发器和级职删除，要排查是否与复制的表有交集，避免数据冲突和额外的操作。

ODI实施应用中，因其主要特性是E-LT，最佳的方式是在同一数据库中进行转换，从架构上讲完全可以满足ODI功能特性。ODI的使用应以熟悉数据库SQL的开发人员为主，可避免新知识的投入成本。

根据我们的实施经验，ODI实施的风险主要体现在：

1)项目成员的风险，如项目组人员的频繁更换，相关人员技术能力不能胜任，项目组人员设计思路不一致等。

2)关于硬件、网络和软件的风险，如：在项目开始时没有可用的硬件服务器和网络，产品版本存在故障(Bug) 或者产品不能提供资料所列的标准功能，系统运行的性能指标不能满足要求系统，“开发环境”或“生产环境”的意外破坏影响项目进行。

3)数据质量的风险，如来自不同系统的数据的一致性。

1. 1. 数据爬虫

随着大数据时代的来临，互联网对人类的生活影响越来越深入，已经成为人类获取信息的主要来源之一。互联网为用户带来海量数据的同时也带来了困扰，如何及时获得有效信息成为研究重点。搜索引擎根据预定的策略从互联网上发现和抓取数据，存入本地；对数据进行去噪、抽取和生成索引等处理，最终为用户提供信息检索服务，将相关信息展示给用户的系统。

爬虫（Crawler）是搜索引擎架构中的最底层模块，以一定的策略从互联网上抓取数据，并对数据进行预处理，然后将处理后的数据提交给搜索引擎其他模块，数据的质量和数量直接影响用户的体验。但是，随着大数据时代互联网数据爆炸式增长，爬虫抓取数据的速度越来越不能满足实际应用的需要。解决这个问题主要从软硬件考虑：一是升级爬虫的硬件，使用性能更好的硬件设备，但性价比不高，且不易扩展；二是利用分布式方式提高爬虫的并行处理能力，但这种方法会增加爬虫系统设计的复杂度。

目前，大多数大型爬虫系统采用的是分布式方式，但仍然不能满足用户的实际需要。其次，爬虫系统还需解决网页动态变化导致本地副本过期的问题。网页随时都可能变化，有的几小时更新一次，爬虫系统必须及时的发现并更新本地的网页，但互联网海洋中网页数量多、分布广，爬虫系统更新一遍需要数周甚至更长的时间，使得本地库中网页副本时新性较低。因此，一个采集速度快，网页更新及时的高可靠爬虫系统，不仅仅为搜索引擎提供基础数据，也可以为数据分析、挖掘提供基础数据，从而获得信息、知识。

Nutch 是Apache 软件基金会的一个开源项目，由Java 编写的可扩展和可伸缩的搜索引擎，具有跨平台的优点，使用基于模块化的思想设计。它基于Hadoop的分布式处理模型保证了系统的性能，类似Eclipse 的插件机制有利于用户自定义扩展Nutch。Nutch 为我们研究搜索引擎爬虫的原理及工作机制提供了一个很好的平台。

Nutch 有两种运行模式：分布式模式和单机模式。分布式模式采用HDFS 作为存储文件系统，并利用MapReduce 实现爬虫抓取网页的各个环节，从而使Nutch 能够抓取、存储海量网页。Nutch有两部分：爬虫和检索。爬虫负责从互联网抓取数据存储在本地，索引程序对抓取在本地的数据建立索引，然后存储在索引库。检索程序接收用户的查询请求，搜索索引库中的索引并返回结果。

Nutch 爬虫系统是由爬虫程序以及用于维护相关数据结构的程序组成，采用插件机制进行设计，因此可以很清晰地分离出爬虫运行各阶段的任务。Nutch 的爬虫通过累积式抓取和增量式抓取方式从互联网中将网页抓下来，分布式模式下将数据存储在HDFS 中，为其他模块提供基础数据。在 Hadoop 分布式平台下，Nutch 在抓取数据的各阶段都向Hadoop 提交MapReduce job，且这些job 都有严格的前后顺序关系。

Nutch 爬行工作流程如下：

1）建立初始种子URL 集：一般新建一个文件包含指定的网址，上传到HDFS上。非全网爬行时，还需在$NUTCH_HOME/conf/regex-urlfilter.txt 文件中设置超链接的过滤规则，过滤掉不合规则的URL；

2）Inject：该操作是由org.apache.nutch.crawl 包中的Injector 类完成，将URL集注入 CrawlDB 数据库。利用插件 URL Normalizers 和URL Filters 对URL 格式化、过滤，消去重复的URL，并设置URL 状态和初始化分值，再更新CrawlDB 数据库中相对应的内容，并标记已经爬行的URL；

3）Generate：该操作是由org.apache.nutch.crawl 包中的Generator 类完成，从CrawlDB 数据库中取出URL 创建抓取列表。当一次爬行完成后， Generate 阶段利用CrawlDB 库中的信息对已爬的URL进行过滤，之后运用Hash 算法对URL 进行降序排列，结果存入segments 目录下的一个目录，目录名是一个时间戳。循环爬行多少次，segments 目录下就有多少这样的文件；

4）Fetch：该操作是由org.apache.nutch.fetcher 包中的Fetcher 类完成，执行抓取，获取网页信息。抓取按 segments 目录下的URL 列表进行，可以自定义爬行的深度（depth）及线程数，适度的增加线程数可以很好地提高Nutch 爬行的效率。网页结果存储在segments 相对应的目录下；

5）Parse：该操作是由org.apache.nutch. parse 包中的ParseSegment 类完成。对 Fetch 抓到的网页进行解析，得到parse-data 和parse-text 两个目录。parse-text 目录存储的是网页的文本信息，parse-data 目录存储的是日期、超链接、题名等其他网页信息；

6）Update CrawlDB：该操作是由org.apache.nutch.crawl 包中的CrawlDb 类完成。根据抓取下来的 segments 目录下的内容更新CrawlDB数据库，更新包括URL爬行周期、爬行间隔、网页指纹等，还要将Parse 阶段解析出的新的URL 加入到CrawlDB，为新的抓取提供URL 列表；

7）循环执行3～6 的步骤，直到depth 的值。以上循环过程可以总结为“产生/抓取/更新”循环；

8）Update LinkDB：Nutch 爬行结束后，更新LinkDB 并建立索引。

Nutch 网页更新机制采用的是邻比法。对第一次采集的网页，邻比法设置其更新时间为初始值。如果该网页在这个时间内更新了，则更新时间缩小一定值；如果没有更新，则更新时间增加一定值。Nutch 网页更新机制我们称为Recrawl 机制，它提供Adaptive FetchSchedule class 来管理爬虫的重新抓取。

Nutch作为开源的搜索引擎框架，能够得到极速的发展使用，不仅是因为Nutch具有以上的功能，还有一项重要的机制促使了Nutch的快速发展，那便是Nutch的插件机制，这种机制极大地方便了研究工作，通过这个扩展机制，能满足了个性化需求。Nutch的插件机制的基本思想是借鉴了Eclipse软件对插件的使用。其优点主要体现为以下几点：

1．可扩展性。插件机制的使用，极大地提高了Nutch对于不同应用的扩展，在实际开发中只需要对特定的接口进行简单的实现，便能够生成具有特定功能的搜索引擎，满足了各种特色的搜索服务。

2．灵活性。插件拥有着强大的资源库，这些插件都在Nutch的plugins中，开发者在使用Nutch框架定制符合自己需求的插件，，比如：开发者可以选择不同的实现算法，寻找满足自己需要的最优解，也可以增加对不同格式文档的分析解压。

3．可维护性。每个开发者只需要关注自己需要关注的问题，如内核的开发者为引擎内核扩展时，只需添加一个描述它的接口；plugin的开发者只需关注这个plugin所要实现的功能，不需要完全了解整个系统工作的工作流程。仅仅需要知道plugin和plug之间交换的数据类型。这使得内核更加简单，也更容易维护。

插件机制在Nutch中的实现，是由Nutch框架提供的扩展点，为其增加一系列的扩展项，从而实现复杂的业务功能。

Nutch的爬虫属于普通的爬虫，这样的爬虫在工作的时候，首先要选好一定的URL集合作为一个起始队列。爬虫通过爬取、解析等过程，获取到网页上新的URL，并且把这些URL添加到队列之中，当第一轮抓取完成之后，就会继续以这些获取到的新的URL为起始地址，继续向深层次抓取，如此循环抓取，直到满足抓取停止的条件或者队列为空，爬虫才会停止工作。普通的爬虫一般会包括待爬行队列模块，获取网页模块，页面解析模块等。

与普通爬虫相比，主题爬虫一般会增加一个主题相关度判断的模块，也是主题爬虫的核心模块。该模块负责爬虫在抓取到网页之后，对网页的内容进行一次主题判断，如果判断结果为与主题相关或者相近，则该页面可以保留；若判断结果为该页面与主题无直接关系，则可以认为这个页面对于抓取后的操作意义不大，可以直接舍弃。由此可以推断出，抓取页面质量的优劣直接有主题爬虫设计的好坏决定，而主题爬虫好坏又直接受到主题相关度判断模块影响。

目前，主要的主题爬虫爬行策略有两种：一是广度优先搜索策略，二是最佳优先搜索策略。二者各有优点和缺点，很多时候都是结合着使用的。

广度优先搜索策略是一种图形搜索算法，在互联网上，网页与网页之间相联系是靠URL，假设通过页面A上的某一URL可以跳转到页面B，则可以认为页面A为上层，页面B为下层。广度优先搜索策略都是按照层次搜索的，总是优先搜索上层的结点，从根节点出发，逐层向下搜索新的与上层邻近的节点，网页的存在基本上就是被URL分成了层。

最佳优先搜索策略的实施与网页评分相关联。进行最佳优先搜索，要给每一个页面进行一个打分，分数的高低也直接决定了网页的优劣。网页抓取到之后，也会根据网页的分数的高低将网页放入队列，便于下一轮的抓取操作。该算法相较于广度优先搜索策略有一定的优势，但是也存在自身的缺点，就是网页的主题性往往是不连贯的，需要经过多层的网页也许才会到达另一个与主题相关的网页，这就产生了“隧道”现象。

1. 1. 数据采集

Flume 是一个分布式、可靠、和高可用的海量日志聚合的系统，支持在系统中定制各类数据发送方，用于收集数据；同时，Flume 提供对数据进行简单处理，并写到各种数据接受方(可定制)的能力。

Flume 的特点是可以通过手工配置，可以自动收集日志文件，在大数据处理及各种复杂的情况下，flume 经常被用来作为数据处理的工具，Flume 搜集日志的方式多种多样，比如可以检测文件夹的变化，可以监测端口信息等等， 检测文件夹变化的方式来实时收集信息。

source：顾名思义，就是数据的来源，这个来源可以来自Web Service 中封装的客户端(AVRO 客户端)，可以是NETCAT 服务，也可以是一个不断增长的日志文件(tail -f)。

channel：提供了一层缓冲机制，来实现数据的事务性传输，最大限度保证数据的安全传输。这层缓冲可以在内存中，可以在文件中、数据库中，当然也可以是自定义的实现。

sink：将数据转发到目的地，或者继续将数据转发到另外一个source，实现接力传输。可以通过AVRO Sink来实现。

通常处理离线业务，可以把收集来的数据放在HDFS 上，如果要实时的计算数据流就把数据收集在Kafka 中。使用的是对文件夹中文件变化进行监测的Spooling Directory Source，channel 是用的内存空间，sink 是自定义的kafkasink，用于向kafka 发送数据。

Flume 的可靠性是指Flume 在数据的传输过程中，保证Events 的可靠专递。为了保证Event 在数据流点对点传输中是可靠地。这里要注意Channel 的选择，MemoryChannel：所有的events 被保存在内存中。优点是高吞吐。缺点是容量有限并且Agent 死掉时会丢失内存中的数据。FileChannel：所有的Events 被保存在文件中。优点是容量较大且死掉时数据可恢复。缺点是速度较慢。

Kafka 是一个开源的分布式消息系统，由LinkedIn 开发，主要用于处理LinkedIn 的活跃数据。活跃数据主要包括页面浏览量(PV)、用户行为(登陆、浏览、搜索、分享、点击)、系统运行日志(CPU、内存、磁盘、进程、网络)等方面的数据。这些数据通常以日志的形式进行存储，然后周期性的对这些数据进行统计分析。传统的日志分析系统主要用于处理离线数据，对于实时数据的处理，有较大的延迟性。现有的消息队列系统可以很好的用于日志分析系统对于实时数据的处理，但通常未被处理的数据不会写到磁盘上，这样不利于Hadoop 这样的离线分析系统的使用。

Kafka 可以很好的解决以上问题，能够很好的为离线和实时的分析系统提供服务。kafka 是一种高吞吐量的分布式发布订阅消息系统， 它有如下特点：数据在磁盘上存取代价为O(1)一般数据在磁盘上是使用BTree 存储的，存取代价为O(lgn)；高吞吐率，即使在普通的节点上每秒钟也能处理成百上千的message；显式分布式，即所有的producer、broker 和consumer 都会有多个，均为分布式的；支持数据并行加载到Hadoop 中。

Kafka 结构中Producer 用于收集数据，Broker 用于数据的中间存储，consumer 用于数据的订阅，Kafka 是显式分布式架构，producer、broker(kafka)和consumer 都可以有多个。Kafka 的作用类似于缓存，即活跃的数据和离线处理系统之间的缓存。多个broker 协同合作，producer 和consumer 部署在各个业务逻辑中被频繁的调用，三者通过zookeeper 管理协调请求和转发。这样一个高性能的分布式消息发布与订阅系统就完成了。

Kafka 源于LinkedIn，LinkedIn于2010 年12 月开源，是一种高吞吐量的分布式发布订阅消息系统，有如下特性：通过O(1) 的磁盘数据结构提供消息的持久化，这种结构对于即使数以TB 的消息存储也能够保持长时间的稳定性能。高吞吐量：即使是普通的硬件Kafka 也可以支持每秒数十万的消息；支持通过Kafka 服务器和消费机集群来分区消息；支持HDFS 并行数据加载。

Kafka 的目的是提供一个发布订阅解决方案，它可以处理消费者规模的网站中的所有动作流数据。Kafka 的目的是通过HDFS 的并行加载机制来统一线上和离线的消息处理，也是为了通过集群机来提供实时的消费。Producer 主要功能是向Broker 同步或者异步的发送消息，可以通过任意的一个Broker 发现其他的Broker 位置信息；broker 是Producer 和Consumer 之间的桥梁，可以将信息可靠地缓存一段时间，这个我们可以定义；Kafka 的Consumer主要是用户应用程序，负责从Kafka 中读取数据，并行进行处理。

1. 1. 联机分析

OLAP分析，是一批采用切片、切块、旋转、钻取等基本操作手段，对以多维形式组织的数据进行深入研究，从而使农户达到从多个角度、多个细节分析数据的目的。

数据展开分析，通过数据展开来分析更深层次的数据。如按时间维度展开得到各个年度的各个月份的销售数据；或按地域展开得各省、各市、各县的数据。一般使用多层报表展现，它是对多维数据的一个透视。

数据钻取分析，在某个维上（如时间维），对于你感兴趣的某个成员数据（如2011年）进行进一步钻取（如看下属各月数据）。

钻取可以向下钻取，以更精细的层次观察数据，去揭示那些没有被意识到的趋势、比例、结构以及异常数据的构成因素。如按时间维度进行钻取，将得到某一年的各个月份的销售数据。

与下钻相反的操作，称为上钻，或上卷。它是某个维度上的泛化，返回较高的维度层次，恢复数据的宏观景象。如从月数据上钻回到年数据。

数据旋转分析，改变维和指标的行、列位置，实现数据的排列方向选择，让我们得以从不同角度观察分析数据。如月份地区分析经系统旋转得到地区月份分析。它与我们平时做的报表转置本义相同，但在BI工具中可进行比报表转置更复杂的操作，即可以将维度和指标在行、列任意组合，也称为交叉分析。

条件组合查询，指定某个或几个维的数值，输出其它维的数据。这是一种切片操作；若是指定某个维的一段值域，它就是一种切块操作。它可以让我们集中分析多维数据中的某个子集。通常以多条件组合查询的方式提供用户操作，输出方式通常是多层次报表。如产品经理可以在产品切块中看“品名＝靴子”的数据。

Cognos 是一个BI(商务智能与绩效管理)平台，它为用户提供了丰富的BI功能。Cognos通过统一的产品，统一的架构为最终用户提供了报表，查询、分析、仪表盘、记分卡、企业事件管理等功能，这些功能涵盖了全部的BI要求。这些全方位的BI能力都是集成在统一的Cognos平台之上，用户无需额外购买任何的功能组件和模块，从而大大降低了集成、部署和学习难度与成本。Cognos提供的常用报表类型如下：

即席查询报表：Cognos Query Studio查询功能提供给用户自助式的即席查询功能，用户可以按照自己的需要通过鼠标拖拽的方式查询自己关心的内容，设置查询条件，设置过滤，定义格式，套用模版，通过自助式的查询，大大提高了用户得到个性化信息的速度。用户的操作可以完全基于业务的逻辑，而不需要理解复杂的数据库结构，SQL语法等。用户的操作过程基本上不需要培训。同时查询的结果可以方便的生成HTML、PDF甚至是XML等多种输出格式，提供给用户最全面的数据查询和即席报表展现功能。同时通过简单的点击鼠标的操作就可以将个性化的查询就行保存和共享。真正实现了用户的自助操作，用户使用起来得心应手。

专业报表：Cognos Report Studio提供了专业的报表功能，报表支持多页设计，支持多查询，每个查询支持多数据源。报表的制作，发布，共享，权限控制等都是采用没有插件的纯浏览器方式。用户只需要在浏览器中通过简单的鼠标拖拽，属性设置等操作就能进行各种报表的制作，如列表，交叉表，图表，财务报表，地图报表，仪表盘报表，KPI报表，甚至是中国式的复杂嵌套表头的非平衡报表都可以直接通过鼠标拖拽的方式实现。还能够进行交叉表中点的公式定义。整个过程不需要编写程序。强大的报表制作和展示功能能够制作/展示任何形式的报表，其纯粹的Web界面使用方式又使得部署成本和管理成本降到最低。Report Studio还提供了HTML、PDF甚至是XML等多种输出格式，提供给用户最全面报表功能。

多维分析报表：Analysis Studio是能够向各种用户提供综合的OLAP多角度，多层次，多指标的分析，它允许IT部门在Internet 、Intranet和 Extranet环境中向系统中的每一个用户迅速而经济有效地部署强有力的报表和分析功能。能够轻松地将分析扩展到上千个用户。

Analysis Studio的多维分析功能全面支持MOLAP和ROLAP，不管是多维立方体还是关系型数据库，用户都可以进行多维分析。用户只需要在Web界面中通过简单的鼠标拖拽等操作，就可以进行各种OLAP分析，如上钻，下钻，切片，旋转，切块等，同时Cognos支持用户进行混合粒度的分析，支持用户自定义子集，支持混合维度的分析，支持多维立方体之间的相互钻取，多维立方体和关系型数据库之间的钻取，能够使用用户从宏观到微观的决策思路和过程。从而迅速的发现问题，确定趋势，找到问题发生原因。Analysis Studio可以提供零客户端，没有插件，没有Applet的纯Web访问方式，具有易用性出色的使用界面，同时又使得部署成本降到最低。它不仅能够让系统中的每一位用户都能够轻松自如地访问重要数据，从而更有效地管理其业务，作出正确决策；还能对关键数据进行多维分析和统计汇总报表制作，从而展现整个行业或大环境的发展的趋势、跟踪主要性能指标(KPI)、控制流程运作、有力支持高层决策。而这一切仅需用户通过鼠标托拽操作来完成。

仪表盘报表：IBM Cognos Business Insight提供了一个全新的交互式界面的仪表盘编辑视窗，用户可以编辑出展示形式多样，反应迅速的仪表盘，增强了 Cognos 基本报表制作的功能。

记分卡报表：Cognos 记分卡帮助您定义和监控企业的关键指标，其数据来源可靠，其工具使您能够对企业内不同的项目（从分散的战略项目到企业级的战略）使用同一种方法来展示指标。通过将战术和战略转换成特定的可度量的目标，记分卡帮助确保企业目标能够被始终如一地定义、应用、理解和传达。

Cognos平台具有非常好的开放性，提供了多种与其他系统集成的方案，详细说明如下：

将Cognos报表的URL直接嵌入到Portlet的IFrame中。

使用Cognos URL API，参数URL是整合Cognos和其他第三方应用或构建客户首页时普遍并被广泛使用的技术。URL API提供了一种快捷的方式链接到Cognos报表或其他功能模块。通过参数URL，用户可以运行报表，启动各种studio，查看页面，客户化用户界面等，而这些可以在没有任何编码的情况下完成，并且可以在几分钟内配置完成。例如：

将Cognos 自带的Portlet安装到WebSphere中，通过Cognos Portlet展现报表。

可以在WebSphere Portal 的管理WEB模块界面中安装Cognos Portlet，共有8种类型的Cognos Portlet可供用户选用。

使用WebSphere Factory自定义Portlet展现Cognos报表。

WebSphere Portlet Factory (WPF)是用来快速创建应用和 portlet 的集成环境，这个环境支持开发，部署，维护以及重用定制的 SOA 风格的 portlets——包括 SAP, Domino, PeopleSoft, Siebel 以及 Web Service portlets。例如：

使用Cognos Mashup service接口集成Cognos报表。

Cognos Mashup Service是Cognos API的一部分，它通过Web Service的方式，将Cognos的BI 内容提供给用户，使用户能更方便的、安全的使用报表中的内容。例如：

Cognos 支持主流的 UNIX、 Linux 和Windows 操作系统，在各个平台上的功能相同。Cognos 的数据探查，分析，报表的各种功能不依赖于任何第三方的支持，对所有数据源都能提供同样强大的功能和出色的表现。

Cognos基于开放式的架构，支持各种主流的应用服务器，且Cognos在产品的安装程序中已经默认集成了Tomcat。具体支持情况见下表：

Cognos支持访问各种数据源，包括关系型数据库，数据仓库，MOLAP,ROLAP等各种数据源，基于这些数据源制作报表，分析。

关系型数据库：包括IBM DB2, Oracle,MS SQL Server, Teradata, Sybase, Sybase IQ，Informix， ODBC,等)

Cognos支持访问各种数据源，包括关系型数据库，数据仓库，MOLAP,ROLAP等各种数据源，基于这些数据源制作报表，分析。

OLAP数据源包括：Cognos PowerCubes, Cognos Planning Contributor Cubes, and Cognos Finance Cubes，MSAS, IBM DB2/OLAP, Hyperion Essbase， SAP BW等OLAP。

Cognos的元数据模型设计工具Framework Manger提供了从数据库到业务逻辑的映射技术，它可以连接企业的各种数据源（包括关系型数据库，多维数据库，文本，OLAP等），对数据结构进行描述，为Cognos的多维分析，即席查询，报表等各种应用提供统一一致的数据视图，降低对企业数据访问的复杂性，同时提供对各种应用使用的结构的统一的管理。通过元数据模型，系统为用户的各种应用访问屏蔽了使用中对数据结构的理解障碍，使得用户无需掌握任何SQL基础，即可自主进行计息查询、报表创建和多维分析等操作。

此外，由于Cognos各报表功能模块共用同一份元数据，当后台数据结构发生变化的时候，只需要对元数据模型进行简单的修改就可以了，基于元数据模型的所有报表应用不需要修改，保证了应用的相对稳定性，最大限度的提高了系统适应复杂应用环境的能力。

Cognos 能够同时连接各种数据源 (包括关系型数据库、多维OLAP数据源、企业级应用比如EPR的数据源等等) 来生成报表。Cognos 真正支持单一报表内容级的多数据源访问，在Cognos的报表中，同一个报表的不同行或列都可以来源于不同的数据源。

Cognos提供了专业的报表功能，报表支持多页设计，支持多查询，每个查询支持多数据源。报表的制作，发布，共享，权限控制等都是采用没有插件的纯浏览器方式。用户只需要在浏览器中通过简单的鼠标拖拽，属性设置等操作就能进行各种报表的制作，如列表，交叉表，图表，分段报表，财务报表，地图报表，仪表盘报表，KPI报表，甚至是中国式的复杂嵌套表头的非平衡报表都可以直接通过鼠标拖拽的方式实现。还能够进行交叉表中点的公式定义。整个过程不需要编写程序。强大的报表制作和展示功能能够制作/展示任何形式的报表，其纯粹的Web界面使用方式又使得部署成本和管理成本降到最低。

Cognos固定报表支持用户自定义参数生成表头，Cognos提供了内置自定义参数或系统环境参数的获取方法，能够直接用于动态表头或报表内容的生成。

Cognos 支持通过鼠标拖拽的方式生成各种报表，可以将包括声音，视频，图形，表格，文字，关系行数据库内容，OLAP等任何有用的信息集成在报表中，同时这些内容还可以和查询相关联，使报表的内容声色并茂，内容饱满，充实。

Cognos支持多种开发方式，支持组件化、模块化、分主题等多种形式的报表和多维分析的快速开发。在实际项目开发过程中，用户可以灵活选择各种方式来进行。由于Cognos采用的是统一的元数据管理和元数据模型定义，无论采用何种开发方式，都可以保证报表和分析结果数据的一致性。

Cognos所有的报表开发环节都是通过纯Web、所见即所得的图形化方式提供给最终用户，用户只需要在Web界面下通过简单的鼠标拖拽即可实现多维分析和报表应用的开发。

Cognos采用标准的三层架构，支持分布式的部署模式，也支持物理合一的部署模式。Cognos采用的是纯浏览器方式，不论是报表的开发，还是报表浏览、生成、调度、管理都可以采用纯浏览器客户端完成，报表以纯HTML展示，不需要下载任何ActiveX控件，整个系统中最终用户的使用界面为真正的零安装、零维护。

Cognos支持几乎所有的数据源，全面支持MOLAP和ROLAP分析，不管是多维立方体还是关系型数据库，用户都可以进行多维分析。用户只需要在Web界面中通过简单的鼠标拖拽等操作，就可以进行各种OLAP分析，如上钻，下钻，切片，旋转，切块等。无论是何种数据源，用户在进行开发和查看时的界面和操作方式没有任何差别，能够让用户拥有一致的用户体验。

Cognos底层采用Unicode编码真正支持多语言，产品本身提供了对中文非常好的支持。Cognos产品提供了多语言版本的、完整的从产品安装部署到报表开发及维护方面的文档，这些文档涵盖了Cognos产品应用的各个环节。这些文档在Cognos产品安装完成后放置在Cognos产品安装目录下的documents文件夹中，这些文档同样是多语言文档，包括中文、繁体中文、英语等近20多种语言，用户可根据自己的需要选择合适语言的文档进行浏览。此外，在Cognos的SDK开发包中，针对不同的语言还提供了大量的Cognos集成开发文档，包括产品培训的PPT、新手上路指南、开发宝典等，这些文档也提供了中文版本，方便国内用户查阅。

Cognos提供了强大的多维分析能力，能够向各种用户提供综合的OLAP多角度，多层次，多指标的分析。用户只需要在Web界面中通过简单的鼠标拖拽等操作，就可以进行各种OLAP分析，如上钻，下钻，切片，旋转，切块等，同时Cognos支持用户进行混合粒度的分析，支持用户自定义子集，支持混合维度的分析，支持多维立方体之间的相互钻取，多维立方体和关系型数据库之间的钻取，能够使用用户从宏观到微观的决策思路和过程。

此外，Cognos还提供了BI产品中最强大的高级分析和数据挖掘的支持组件——Cognos Statistics。Cognos Statistics是Cognos 10中新增加的组件，他不仅继承了常用的SPSS统计分析和数据挖掘功能，而且还支持与Cognos Report Studio的集成。Cognos Statistics提供了包括过程控制的统计（如例外值的分析）；数据分析和测试（比如衰退、线性、回归和相关性的分析等），以及对数据的分布和状态的研究等等分析功能。Cognos 还提供“WhatIf”功能，某主题的某些指标调整后，分析系统会根据调整后的指标对所涉及的关联指标做出相应的联动调整，用户可以根据预测后的指标与原有指标比较，从而判断某个指标变化对其他方面的影响，结果还可以保存。

Cognos具有丰富的图形展现形式，支持如柱图、线图、面积图、组合图、雷达图、气泡图、饼图、仪表盘、地图等，并且图形都可以选择普通二维和3D图形进行展现。图形之间可以通过Cognos的穿透钻取来进行图形-图形，图形-数据表格之间的关联分析功能。

Cognos平台能够提供完备的平台监控能力，能够帮助系统管理员及时掌握系统状态和提供相应的系统优化建议。Cognos平台还提供完整的审计功能，用户在Cognos系统上进行的操作，如登录、修改、删除、导出、执行等操作，都可以被记录在日志文件或日志数据库中。这些审计记录能够为系统管理员优化系统提供数据依据，协助管理员完成系统调优。

Cognos自身提供不依赖第三方的软件级别的负载均衡功能，也可以配合J2EE应用服务器(如WebSphere)或者第三方负载均衡路由器来实现负载均衡。根据不同的并发用户访问量和硬件环境，Cognos提供不同的可扩展的负载均衡方案。Cognos的集群方式采用对等网络集群而非传统的主从式集群，从根本上消除了集群节点单点故障的隐患。

Cognos提供了向导式的多维分析产生关系型报表的功能，用户可以在纯Web界面上所见即所得的进行各种报表的格式化工作。新生成的报表无需发布，可直接在Web上供具有相应浏览权限的用户浏览和查看。

Cognos支持和的导出文件格式为xls、xml、html、csv、pdf、doc（或rtf）、txt等，Cognos中所有的报表中的表格和图形均支持打印及导出，导出为Excel的时候，导出的图形是Excel格式的图形，可以对其进行再加工。

Cognos能够支持用户将分析的中间结果和状态保存到用户个人空间形成下次可直接访问的书签，方便用户的重新进入时的快速查看。用户也可以将这些个人私有的内容设置共享内容，分享给其他用户浏览和分析。

Cognos提供了强大的数据访问权限控制功能，能够支持类似“机构树”的权限管理功能，使得每个用户都只能看到与其权限相应的数据切片，且能够实现报表内容单元格级的权限控制能力。

Cognos提供了多种数据源访问接口方式，支持通用的C/S接口、ODBC接口、JDBC接口等方式访问数据源。Cognos平台具有较好的开放性，支持主流的前端工具访问。此外，数据存储本身也基于开放标准，不会对前端设计、管理和展示功能构成任何限制。

Cognos具有企业级的OLAP Server，能够同时提供对MOLAP和ROLAP的支持。Cognos自身提供了MOLAP分析引擎Cognos PowerCube，能够为用户的分析，报表等各种应用提供高效的秒级响应。

Cognos OLAP Server的特点：

极快的数据立方体生成速度

压缩型数据立方体，通常为原始数据占用空间的十分之一，甚至更小

支持对异构数据源的读取

文件型的数据立方体，避免对数据库的开销

支持虚拟Cube技术，能够基于时间进行增量更新，能够基于时间进行定点更新，支持超大数据量

智能的高速缓存技术，支持大用户并发访问

OLAP模型设计界面友好，不需要编写程序

Cognos多维分析组件Cognos Analysis Studio通过纯浏览器界面，向各种用户提供综合的OLAP多角度，多层次，多指标的OLAP分析能力。Cognos Analysis Studio可以提供零客户端，没有插件，没有Applet的纯Web访问方式，具有易用性出色的使用界面，同时又使得部署成本降到最低。用户只需要在Web界面中通过简单的鼠标拖拽等操作，就可以进行各种OLAP分析，如上钻，下钻，切片，旋转，切块等多角度分析能力。

Cognos Analysis Studio可以提供零客户端，没有插件，没有Applet的纯Web访问方式，具有易用性出色的使用界面，同时又使得部署成本降到最低。用户只需要在Web界面中通过简单的鼠标拖拽等操作，就可以进行各种OLAP分析，如上钻，下钻，切片，旋转，切块等，同时Cognos支持用户进行混合粒度的分析，支持用户自定义子集，支持混合维度的分析，支持多维立方体之间的相互钻取，多维立方体和关系型数据库之间的钻取，能够使用用户从宏观到微观的决策思路和过程。从而迅速的发现问题，确定趋势，找到问题发生原因。

Cognos多维分析同图形报表功能一样，同样具有丰富的图形展现形式，支持如柱图、线图、面积图、组合图、雷达图、气泡图、饼图、仪表盘、地图等，并且图形都可以选择普通二维和3D图形进行展现。图形之间可以通过Cognos的穿透钻取来进行图形-图形，图形-数据表格之间的关联分析功能。

Cognos的报表开发和设计都在纯Web界面下完成，无需下载任何插件和Applet、ActiveX等。当用户完成报表的开发和设计保存报表时，新报表将会自动发布到Cognos报表平台，无需任何发布过程和发布工具。

Cognos支持自定义需要查询的字段，产品自身自包含了对分组排序、求和、最大值、最小值、汇总、排序、前N名、后N名等计算的支持，且支持自定义计算公式。

Cognos内置了非常多的函数， 包括各种运算符，汇总函数，维度函数，成员汇总函数，IF-Then等判断逻辑函数，块函数，时间日期函数等（参见下图），能够很好的支持维度处理，如期初、期末、同期、累计、年累计、季度累计、月累计、周累计等功能。此外，Cognos还支持DB2，Oracle，Sql Server，Teradata等数据库的内嵌函数的直接使用。

Cognos内置了非常多的函数，能够直接使用各种数据库的内嵌函数和方法，也提供了对递归计算的支持。

Cognos平台采用了会话缓存、模型缓存和报表结果缓存等多级缓存机制。会话缓存能够重用已有的数据源会话链接，复用数据库的连接访问请求。模型缓存能够支持快速的模型解析，快速响应用户的各种操作。报表结果缓存能够让重复的查询和计算直接使用缓存结果的切片（钻取分析同样可以使用到相应的缓存内容），而无需再次查询数据库，减少对数据库的压力，从而提高性能，支持大用户的并发访问。

1. 1. 数据挖掘

方差分析

在实际生活中，人们往往通过试验来了解各种因素对诸如产品销量、产品产量、产品质量等指标的影响，不仅如此，还要在各种因素中找出显著的因素以及这些因素在什么状态（水平）对改变产品质量，增加产品产量、产品销量最有利，从而选出最优的因素水平，为此，首先设计一个合适的实验方案，按照该实验方案进行试验，然后对试验结果进行分析，方差分析就是解决这项工作的有效方法。方差分析按照影响试验指标的个数分为单因素方差分析、双因素方差分析和多因素方差分析。

方差分析就是要分析控制变量的不同水平是否对观察变量产生了显著影响。如果控制变量的不同水平对实验结果产生了显著影响，那么他和随机变量共同作用必然使得观察变量数据有显著变动；相反，如果控制变量的不同水平对实验结果没有产生显著影响，那么，观察变量数据的变动就不会明显表现出来，他的变动可以归结为受随机变量影响造成的。

单因素方差分析实质也采用了统计推断的方法，其目的是通过实验数据（样本数据）研究观察变量中的若干个不同水平下，其各个总体在分布上是否存在显著差异。

多因素方差分析既要分析多个控制变量独立作用对观察变量的影响，又要分析多个控制变量交互作用对观察变量的影响和其他随机因素对观察变量的影响，因此，它将观察变量总的变差平方和分解成多个控制变量单独作用引起的、由多个控制变量交互影响引起的、由其他随机因素引起的等三部分。以分析控制变量各水平的交互作用对观察变量均值有没有产生显著影响。

无论单因素方差分析还是多因素方差分析，它们都有一个共同的特点就是控制变量的各个水平是人为可以控制的。但在许多实际问题中，有些因素的不同水平难以人为控制，但它们确确实实对观察变量产生较为显著的影响。在方差分析中，如果忽略这些因素的存在而单纯去分析其他因素对观察变量的影响，往往会夸大或缩小这些因素的影响作用，使得分析结论不准确。

为了更加准确地研究控制变量不同水平对观察变量的影响，应尽量排除其他能够排除的因素对分析的影响作用。

协方差分析是将那些很难控制的因素作为协变量，在排除协变量影响的条件下，分析控制变量对观察变量的影响，从而更加准确地对控制因素进行评价。

回归分析

相关分析以现象之间是否相关、相关的方向和密切程度等为主要研究内容，它一般不区分自变量与因变量，对各变量的构成形式也不涉及。其主要分析方法有绘制相关图、计算相关系数和检验相关系数。回归分析包括对现象间具体的相关形式的分析，在回归分析中根据研究的目的，应区分出自变量和因变量，并研究确定自变量和因变量之间的具体关系的方程式。回归分析是将相关的因数进行测定，确定其因果关系，并以数学模型来表示其具体关系式，从而进行的各类统计分析。分析中所形成的这种关系式称为回归模型，其中以一条直线方程表示两变量相关关系的模型叫一元线性回归模型；以曲线方程表示两变量相关关系的模型叫曲线回归模型。

线性回归分析是侧重考虑变量之间的数量变化规律，并通过一定的数学表达式，即回归方程，来描述这种关系，进而确定一个或几个变量之间的变化对另一个变量的影响程度，为预测提供科学的数学依据。

相关分析

相关分析就是一种测度事物间统计关系强弱的一种手段和工具，旨在衡量事物之间，或称变量之间线性相关程度的强弱。

在所有的相关分析中，最简单的是两个因素之间的线性相关，它只涉及一个自变量和一个因变量。而且自变量数值发生随之发生大致均等的变动，从平面图上观察其各点的分布近似地表现为一直线，这种相关关系被称为直线相关（也叫线性相关）。

线性相关分析是用相关系数来表示两个变量间相互的直线关系，并判断其密切程度的统计方法。

在线性相关分析中，两个变量X和Y的值总是成对的出现的，形成直角坐标系中的一个点。根据这些点在直角坐标系的位置及紧密程度，可以判断两个变量的相关情况：正相关，负相关，无相关，非线性相关。

ABC分类分析

ABC分类法：又称重点管理法、帕累托分析法，是根据事物在技术经济方面的主要特征，进行分类排队，分清重点和一般，从而有区别地确定管理方式的一种分析方法。

ABC分析法就是用于从众多任务中选择有限数量的任务以取得显著的整体效果的分析方法。它使用了帕累托法则，即关于做20%的事可以产生整个工作80%的效果的法则。一个系统中，少数事物具有决定性的影响。相反，其余的绝大部分事物却不太有影响。很明显，如果将有限的力量主要(重点)用于解决这具有决定性影响的少数事物上，和将有限力量平均分摊在全部事物上。两者比较，当然是前者可以取得较好的成效，而后者成效较差。ABC分析便是在这一思想的指导下，通过分析，将“关键的少数”找出来，并确定与之适应的管理方法，这便形成了要进行重点管理的A类事物。这就能够以“一倍的努力取得7—8倍的效果”。

聚类分析

聚类分析正是统计学中研究“物以类聚”问题的一种方法，它属于多元统计分析的范畴。

聚类分析实质是一种建立分类的方法，他能够将一批样本数据（或变量）按照它们在性质上的亲疏程度在没有先验知识的情况下进行分类。这里，一个类就是一个具有相似性的个体的集合，不同类之间有明显的非相似性。在分类过程中，人们不必实现给出一个分类标准，聚类分析能够从样本数据出发，客观地决定分类标准。

聚类分析的基本思想是在样品之间定义距离，在变量之间定义相似系数，距离或相似系数代表样品或变量之间的相似程度。按相似程度的大小，将样品（或变量）逐一归类，关系密切的类聚集到一个小的分类单位，然后逐步扩大，使得关系疏远的聚合到一个大的分类单位，直到所有的样品（或变量）都聚集完毕，形成一个表示亲疏关系的谱系图，依次按照某些要求对样品（或变量）进行分类。

快速聚类法

快速聚类法先将样品粗略地分一下类，然后再按照某中原则进行修正，直到分类比较合理为止。快速聚类的过程大致可由下图表示。理论研究及计算实践都表明，快速聚类法是快速有效的聚类方法。

时间序列分析

时间序列是按时间顺序排列的，随时间变化且相互关联的数据序列。这样的例子在工程，经济等各个领域都广泛存在，而分析时间序列的方法构成数据分析的一个重要领域，即时间序列分析。时间序列分析法是依据预测对象过去的统计数据，找到其随时间变化的规律，建立时序模型，以推断未来数值的预测方法。其基本设想是：过去变化规律会持续到未来，即未来是过去的延伸。

时间序列通常含有三大特性：趋势性，季节性与随机性。

进度分析

进度分析是通过图形的方式将计划完成情况反映出来，如将生产的计划完成情况反映出来，以便随时掌握工业生产进度。

指标关联分析

根据指标的相关性，分析指标相互影响程度。以杜邦分析为例，可以变动树节点的任一个指标，其他相关指标随着变化，从而可以确定对关键指标的影响程度。

预警分析

预警分析是根据经济运行数据和事前制定的指标阀值，做出预警分析，为对生产经营及时提供预警信号。它将异常的数据从大量纷繁的数据当中及时挑出来，大大提高了我们数据处理的及时性和工作的有效性。

通过对每个指标设置临界值，每个临界值对应不同颜色，若指标超过临界值，则以不同的颜色显示出来，进行预警分析，提请分析人员注意。对告警监控的结果数据提供多种分析手段，发现告警数据背后的更深层次信息。提供告警规则集的定制功能，在更高的逻辑层次上封装多条告警规则，实现更复杂的告警条件组合。

我们也常用仪表盘展示关键指标分析，用指针和刻度表示指标是否在正常范围，如生产废品率。该方法常用于构造管理驾驶舱，方便领导快速掌握关键指标运行情况。

1. 1. 机器学习

随着大数据时代的到来，大数据逐渐成为学术界和产业界的热点，已在很多技术和行业广泛应用，从大规模数据库到商业智能和数据挖掘应用；从搜索引擎到推荐系统；推荐最新的语音识别、翻译等。大数据算法的设计、分析和工程涉及很多方面，包括大规模并行计算、流算法、云技术等。 由于大数据存在复杂、高维、多变等特性，如何从真实、凌乱、无模式和复杂的大数据中挖掘出人类感兴趣的知识，迫切需要更深刻的机器学习理论进行指导。

传统机器学习的问题：理解并且模拟人类的学习过程；针对计算机系统和人类用户之间的自然语言接口的研究；针对不完全的信息进行推理的能力，即自动规划问题；构造可发现新事物的程序。

传统机器学习面临的一个新挑战是如何处理大数据。 目前，包含大规模数据的机器学习问题是普遍存在的，但是，由于现有的许多机器学习算法是基于内存的，大数据却无法装载进计算机内存，故现有的诸多算法不能处理大数据。 如何提出新的机器学习算法以适应大数据处理的需求，是大数据时代的研究热点方向之一。

分治策略是一种处理大数据问题的计算范例，尤其是近来在分布式和并行计算有很大发展的情况下，分治策略显得尤为重要。一般来说，数据中不同样本对学习结果的重要程度也不相同。 一些冗余和噪音数据不仅造成大量的存储耗费，降低学习算法运行效率，而且还会影响学习精度。 因此更倾向于依据一定的性能标准(如保持样本的分布、拓扑结构及保持分类精度等)选择代表性样本形成原样本空间的一个子集，之后在这个子集上构造学习方法，完成学习任务。这样能在不降低甚至提高某方面性能的基础上，最大限度地降低时间空间的耗费。在大数据的背景下，样本选取的需求更迫切。但已有的大部分样本选取方法只适用于较小规模的数据集，如传统的压缩最近邻、约减最近邻、编辑最近邻，它们的核心概念都是最小一致子集，而要找到这个子集需逐一测试样本，并且对子集的初始化及样本加入子集的顺序很敏感。数据分治与并行处理策略是大数据处理的基本策略，但目前的分治与并行处理策略较少利用大数据的分布知识，且影响大数据处理的负载均衡与计算效率。 如何学习大数据的分布知识用于优化负载均衡是一个亟待解决的问题。

在数据挖掘、文档分类和多媒体索引等新兴领域中，所面临的数据对象往往是大数据集，其中包含的属性数和记录数都很大，导致处理算法的执行效率低下。 通过属性选择可剔除无关属性，增加分析任务的有效性，从而提高模型精度，减少运行时间。大数据处理的一个巨大挑战是如何处理高维、稀疏数据。 大数据环境下，网络流量、通讯记录、大规模社会网络产生大量、多方面的高维数据，张量(如多维数组)表示法提供一种大数据的自然表示。 故张量分解成为一种重要的汇总和分析工具。 由于大数据存在复杂、高维、多变等特性，如何采用降维和特征选择技术以降低大数据处理难度，是大数据特征选择技术迫切需要解决的问题。

有监督学习(分类)面临的一个新挑战是如何处理大数据。 目前包含大规模数据的分类问题是普遍存在的，但是传统分类算法不能处理大数据。

1)支持向量机分类，传统统计机器学习方法用于大数据分类有两大瓶颈问题：计算密集型，几乎不能用于大规模数据集；鲁棒和非参数的置信区间的拟合模型的预测往往是未知的。

2)决策树分类，传统决策树(Decision Tree)作为一种经典的分类学习算法，对大数据处理存在内存开销过大的问题。

3)神经网络与极端学习机，传统前馈神经网络一般采用梯度下降算法调整权值参数，学习速度慢、泛化性能差等问题是制约前馈神经网络应用瓶颈。

4)应用领域的分类算法， 除此之外，在一些应用领域，也有针对大数据的分类算法提出。 在计算机辅助诊断领域，机器学习广泛应用于帮助医学专家从已诊断案例中获取先验知识，但大量的已诊断样本很难获取。

传统机器学习的分类方法很难直接运用到大数据环境下，不同的分类算法都面临着大数据环境的挑战，针对不同分类算法如何研究并行或改进策略成为大数据环境下分类学习算法研究的主要方向。

聚类学习是最早被用于模式识别及数据挖掘任务的方法之一，并且被用来研究各种应用中的大数据库，因此用于大数据的聚类算法受到越来越多关注。

随着信息技术的迅猛发展，聚类所面临的不仅是数据量越来越大的问题，更重要的还是数据的高维问题。 由于数据来源的丰富多样，图文声像甚至视频都逐渐成为聚类处理的目标对象，这些特殊对象的属性信息往往要从数百个甚至成千上万个方面来表现，其每个属性都成为数据对象的一个维，对高维数据的聚类分析，已成为众多领域研究方向之一。 高维数据的聚类方法包括基于降维的聚类、子空间聚类、基于图的聚类等。 在很多需处理高维数据的应用领域，降维是常用的方法之一。 直观地讲，降维就是通过把数据点映射到更低维的空间上以寻求数据的紧凑表示的一种技术，这种低维空间的紧凑表示将有利于对数据的进一步处理。 降维从一般意义上代表着数据信息的损失，如何保证降维而不损失聚类性能是传统数据领域仍在研究和讨论的问题。

经典的聚类算法在大数据环境下面临诸如数据量大、数据体积过大、复杂度高等众多挑战，如何并行或改进现有聚类算法，进而提出新的聚类算法成为研究关键。

关联分析的研究源自于Apriori 算法，Apriori性质要求频繁模式的子模式必须也是频繁的。 基于这一启发，出现一系列的类Apriori 算法：AprioriAll，AprioriSome， DynamicSome ， 广义序列模式GSP及基于等价类的序列模式发现SPADE。后来，研究者又提出一系列基于数据投影的算法，包括频繁模式投影序列模式挖掘算法FreeSpan和前缀投影序列模式挖掘算法PrefixSpan。 SPADE是基于格点的算法。 基于内存索引的序列模式挖掘算法MEMISP是基于内存索引的方法。 而基于正则表达式约束的序列模式挖掘算法SPIRIT通过使用正则表达式将约束整合到一起。解决大数据的关联分析主要有两种途径：并行和增量。

如何把传统机器学习算法运用到大数据环境中，一个典型策略是对现有学习算法并行化。 例如，图形处理器GPU平台从并行上得到较显著的性能提升。 这些GPU 平台由于采用并行架构，使用并行编程方法，使得计算能力呈几何级数增长。

大数据具有属性稀疏、超高维、高噪声、数据漂移、关系复杂等特点，导致传统机器学习算法难以有效处理和分析，为此，需在包括数据抽样和属性选择等大数据处理的基本技术，设计适合大数据特点的数据挖掘算法，以实现超高维、高稀疏的大数据中的知识发现。适合大数据分布式处理的数据挖掘算法编程模型和分布式并行化执行机制，支持数据挖掘算法迭代、递归、集成、归并等复杂算法编程。在Hadoop、CUDA 等并行计算平台上，设计和实现复杂度低、并行性高的分布式并行化机器学习与数据挖掘算法。

1. 1. 任务调度

随着云计算的兴起，分布式系统的应用越来越广泛，在Hadoop系统大规模普及的今天，一大批配套的软件系统正在涌现。Zookeeper即是这样一个数据同步系统，它是Hadoop旗下的一个正式子项目，属于对chubby的开源实现，其核心是一个精简的分布式文件系统。与HDFS不同，它注重数据的可靠性，所以只存储少量的重要数据，但将这些数据在每个集群节点上都保留一个备份。

ZooKeeper是一种用于提供配置信息维护、命名服务、分布式同步和组服务等的集中式协调系统，所有这些服务都以一种或多种形式被分布式系统使用。ZooKeeper本质上是一个分布式的小文件存储系统，具有下述应用特性：

简单。ZooKeeper允许通过分布式程序共享方式，组织成类似标准文件系统层级命名空间协调的分布式程序。这个命名空间包含类似文件和目录的数据寄存器，不像一个典型的用于存储的文件系统。ZooKeeper的数据保存在内存中，可实现高吞吐量和低延迟访问。

冗余。ZooKeeper本身和其自身协调的程序一样，设计为冗余的，在拥有许多主机集合的主机组上运行。组成ZooKeeper服务群的所有服务器都已知对方，只要所有服务器中的主服务器可用，ZooKeeper服务就是可用的。客户端链接的一个ZooKeeper服务器通过发送请求、获取响应、监听事件、发送心跳维持一个TCP(传输控制协议)链接，如果链接中断，客户端将连接到另外一个服务器。

有序。ZooKeeper用一个反映所有ZooKeeper事务顺序的数字，标记每一个更新。以后的操作可以使用这个顺序数字标记。

(4)快速。ZooKeeper在读取占主要地位的负载环境下，在读取操作比写入操作更频繁的情况下，读取速度非常快。

(5)丰富的API(应用程序编程接口)。ZooKeeper为开发人员提供了一套丰富的API，减轻了开发人员编写通用协议的负担。

对Zookeeper上文件的任意增、删、写操作都会发送给领导节点，然后由领导节点同时发送给所有的集群节点，只有集群里超过半数以上节点都得到消息并给出响应后，这个操作才能成功进行，这样只要集群内失效的节点不超过一半，就不会有任何的数据丢失，从而提供一个高可靠性的分布式文件统。由于Hadoop集群通常是由一系列性能参差不齐的节点组成，系统单节点故障率非常高，为保证集群关键数据的可靠存储，Zookeeper是必不可少的。

由于Zookeeper提供的是高可靠性的服务，每次操作均需要集群内半数以上的节点响应，那么当Zookeeper集群的规模变大之后，节点响应带来的延时也与日剧增，为了解决节点响应带来的延迟过高问题，Zookeeper将集群内节点分成2类：一类是响应节点；另一类是观察节点。响应节点对数据更新请求做出应答，而观察节点不参与数据更新请求的应答，故集群的数据更新延迟主要由响应节点决定。这样，当集群规模增大时，只要保持响应节点的数量不变，即可使数据更新的延迟保持在一个恒定的值。

但是目前Zookeeper的响应节点和观察节点都是由用户手动指定的，用户并不能预知集群内各节点的性能、状态，因此，用户手动设定的响应节点可能并非最合适的节点。

1. 1. ESB

应用集成是企业系统间集成解决方案中最主要的一种形式，主要是指将基于各种不同平台、不同方案建立的应用软件和系统中的数据与逻辑进行准实时地集成。应用集成的最佳方式是：基于企业服务总线，各个应用系统将逻辑的不同功能单元抽象为Web服务，这些服务之间定义了良好的接口和契约，通过面向服务架构中的企业服务总线联系起来。对于不同集成需求，企业服务总线可提供同步与异步两种集成模式，其中异步模式可通过JMS消息机制实现，以满足对实时性要求较高的需求。

大数据平台提供了基于SOAP协议的Web服务应用和基于Restful风格的两种ESB集成方式。通过ESB获取营销业务数据并按照主题模型标准进行存储，总部和省（市）营销业务应用系统通过ESB从大数据平台获取业务数据，实现营销业务数据的共享应用。

企业服务总线（Enterprise Service Bus，ESB）是传统中间件技术与XML、Web服务等技术结合的产物，符合业界标准的消息交换、服务流程引擎，使用统一的服务调用和业务表现模型，并遵循业界的开放标准。ESB系统采用J2EE架构，保证系统可移植性和可扩展性，使用基于XML和SOAP的 Web Service技术，能够实现XML到数据库、数据库到XML和数据库到数据库之间的数据交换和共享；同时支持作为服务网关进行不同系统间服务的调用与交互，完全实现了跨平台跨系统的服务调用交互、支持各种异构数据库的动态数据交换功能。具体有如下特点：

1、采用SOA的技术实现，内核消息格式采用SOAP格式，天生具备对SOA的良好支持能力，具有天然的灵活性、扩展性；

2、高性能的引擎结构，提供了高并发的映射、转换计算能力；支持为不同计算负载的服务组件调配相应的服务器资源配置，优化服务器内部资源分配；

3、强大的的服务流引擎，支持任意符合业务规则的服务流的调度运行；支持多种服务流模式：服务流的分支、合并、并行运行流程与长周期的同步处理，可适应复杂业务的计算处理；

4、灵活应变的部署模式支持，构建单点乃至庞大的分布式总线轻而易举：

（1）既可以满足同级多应用间的服务交互与协作；企业应用间数据交换集成及数据集中管理；

（2）又可以支持上下级多级互联实现数据的贯通和交换、多级的业务流协作，同时扩容方便，保护用户投资；

5、强大的节点扩展计算能力保障复杂业务的实现：提供Java扩展，处理复杂的业务逻辑；提供简单SQL扩展，方便多种数据处理方式；可支持插入第三方扩展实现；提供强大的多步数据映射和计算能力；

6、高可靠性：提供数据持久缓冲保证业务操作不丢失，运行时错误/异常处理机制，通过恢复、重试以及自定义的补偿等措施保证服务调用的可靠性、一致性；

7、开放性：拥有多种接入方式供异构系统、消息中间件甚至其它厂商ESB的连接；并支持多种自定义的扩展，实现客户化的节点处理功能；

8、完备的设计开发工具和基于Web的图形化的管理控制台，使得开发管理一切尽在掌控之中。

各应用系统之间的信息交互均通过ESB企业服务总线来进行，ESB具备的功能主要包括：路由寻址、数据转换、事件管理和安全认证等。ESB与服务注册库相结合提供服务端点的查找与动态路由能力。

1、路由寻址：接收服务使用者的服务请求，根据上下文信息从服务注册库中得到服务提供者的地址，通过服务路由器转发服务到具体的服务提供者。业务系统根据处理处理结果反馈响应信息到服务总线，服务总线则将响应返回给服务请求方；

2、数据转换：接收不同格式的数据，将其转换成服务提供者能识别的数据，使得不同系统间能进行相互调用；

3、事件管理：对服务的请求、执行全过程进行记录，对服务进行监控；

4、安全认证：对服务请求方和提供者之间的Web服务访问提供安全性的保障，通过用户认证及服务权限检查，将具有权限的服务请求路由转发到提供服务的业务系统进行处理。

1. 1. 可视化

技术作为解释大数据最有效的手段之一最初是被科学与计算领域运用，它对分析结果的形象化处理和显示，在很多领域得到了迅速而广泛应用。数据可视化（Data Visualization）技术是指运用计算机图形学和图像处理技术，将数据转换为图形或图像在屏幕上显示出来，并进行交互处理的理论､方法和技术。由于图形化的方式比文字更容易被用户理解和接受，数据可视化就是借助人脑的视觉思维能力，将抽象的数据表现成为可见的图形或图像，帮助人们发现数据中隐藏的内在规律。

可视分析起源于2005年，它是一门通过交互可视界面来分析､推理和决策的科学，通过将可视化和数据处理分析方法相结合，提高可视化质量的同时也为用户提供更完整的大规模数据解决方案。如今，针对可视分析的研究和应用逐步发展，已经覆盖科学数据､社交网络数据､电力等多个行业。面对海量数据的涌现，如何将其恰当､清楚地展现给用户是大数据时代的一个重要挑战。学术科研界以及工业界都在不停致力于大数据可视化的研究，已经有了很多经典成功的应用案例。

1）互联网宇宙（The Internet Map）。为了探究互联网这个庞大的宇宙，俄罗斯工程师Ruslan Enikeev根据2011年底的数据，将196个国家的35万个网站数据整合起来，并根据这些网站相互之间的链接关系将这些“星球”联系起来，命名为“The Internet Map”。一个“星球”代表一个网站，每一个“星球”的大小根据其网站流量来决定，而“星球之间”的距离远近则根据链接出现的频率､强度和用户跳转时创建的链接等因素决定。

2）标签云（Tag Cloud）。标签云的本质就是一种“标签”，用不同的标签标示不同的对象。标签的排序一般按照字典的顺序排列，并根据其热门程度确定字体的颜色和大小，出现频率越高的词语字体就越大，反之越小，这就方便用户按照字典或是该标签的热门程度来寻找信息。

3）历史流图（History Flow）。提出了一种用于可视化文档编辑的“历史流图”，这样的一个流程，意味着这是一个面向广大用户的开放型文档，用户可以在其中自由地编辑和查阅，随时根据自己的理解进行增加和删除操作。在历史流图中，用一个坐标轴表示对一篇文档做出任何修改的行为：横坐标表示时间，纵坐标表示修改的人员；随着时间的推移，横坐标越来越长，文档内容也随着不断变化，修改的人员也随之增加，可以很容易看出每个人对这篇文档的贡献。最显著的应用案例就是“维基百科”的注释文档，“历史流图”的效果很明显。

关于大数据可视化的研究依然在继续，比如大众点评网上，可以轻松的根据地理信息找到附近的餐厅､KTV､商店等，用户可以根据自己的体验对这些店铺进行评价，这些反馈信息就在网络上留下了痕迹，为后来的用户使用提供了参考，这种常见的社交网络或生活消费类应用与数字网络地图的叠加，就是多维叠加式数据可视化应用；另外，支付宝的电子对账单通过用户一段时间（一般是1个月）的支付宝使用信息，自动生成专门针对此用户的本月消费产品数据图表，可以帮助用户分析其自身的消费情况，这是一种即时的关联规则下可视化技术的应用，通过对那些彼此间存在关联性的数据进行分析处理，挖掘出数据间联系并预测出发展趋势，随后即时生成可视化方案反馈给用户，可以给客户下个月的消费管理提供参考意见。

场景设计与配置工作包括：需求描述、场景设计说明书、场景DEMO，每阶段成果需要与业务专家进行确认，并反复迭代完善，定稿进入下一阶段，输出场景规范之前均可能返回之前阶段进行修改完善，流程如下：

 

展示设计指结合视觉效果以及界面排版原则，对业务数据的最终表现形式进行描述，对设计的功能进行说明。

展示设计以展示主题为单位，多个展示主题组合形成展示场景，所有展示主题构成展示主题库以统一管理。

展示主题库按照覆盖全面、重点突出的原则，建立覆盖全貌的展示域；依据有效支撑、分类清晰的原则，构建支撑各核心领域的展示子域；根据亮点突出、特点鲜明的原则，确定突显各业务特色的展示主题，形成“展示域、展示子域、展示主题”三级展示基础体系，展示主题是全景展示的最小展示单元，是模块化展示的基础。通过业务素材收集、场景逻辑视图设计、场景联运功能设计、美工优化处理输出设计说明书，经用户确认后输出设计终稿。

根据不同的展示对象，通过展示主题的灵活组合，构建展示场景；也可以选择需要的展示子域或展示域，快速组合展示场景，如图所示。

 

展示场景分为典型场景和可定制场景两种模式。对于特定的服务对象，采用“套餐”设计模式，选择固定的展示主题，构建典型展示场景。对临时参观人员及特殊群体，根据展示需求，采用“定制”方式，可在“套餐”基础上，适度增减展示主题，也可完全自由选择展示主题，组成展示场景。针对各专业领域的专题展示需求，设计展示方案，形成具有专业特色的专题展示场景。

以需求分析总结的业务需求、功能需求、指标体系为输入，参考业务素材，组织业务专家进行展现形式研讨，形成需求描述；

依据需求描述，组织专业设计人员进行场景设计，参考平台现有成果，结合实际业务，形成场景设计说明书；

展示配置工作以主题设计说明书作为输入，在工作台上进行操作，完成相应展示主题从设计到具体实现的配置过程。

主要依据主题设计说明书与工作台操作规范，合理运用工作台组件，将平面效果转变为实际可操作的互动型主题演示DEMO，供关键用户实际体验。

根据主题设计说明书，参考国网运营监测（控）现有配置成果，组织专业配置人员进行配置开发，形成场景演示DEMO，供关键用户确认；

对关键用户提出的修改意见进行分析，组织相应人员进行修订。如此经过确认与迭代修改完善后，形成主题终稿，导入主题管理库统一管理。

1. 1. 虚拟化

虚拟现实是“通过由电脑提供的感官刺激（例如视觉和听觉），使用户产生一种人工环境的体验，并且在这人工环境中，用户的行动部分地由该环境中所发生的事情所决定”。虚拟化正是这样做的：虚拟机软件在一台真正的物理系统上创建一个或多个虚拟工作站或服务器。磁盘空间、处理器性能、网络适配器及大量随机访问存储器（RAM）均取决于真正物理机上的资源。

一般的计算机模型可以抽象成为一定的物理资源和运行其上的计算机元件，它们之间通过定义好的物理资源接口进行交互。虚拟化层必须能够捕捉到计算机元件对物理资源的直接访问，并将其重新定向到虚拟资源池中。

KVM 的全称是Kernel Virtual Machine，翻译成中文就是基于内核的虚拟机，是一个开源的虚拟化模块。KVM 最早是由以色列的Qumranet 公司开发的，后于2008 年被Linux 的发行版提供商Redhat 收购，从而成为KVM 开源项目的新主人，开始着手用KVM 替换掉早前已经集成在系统中却由于其自身管理系统资源架构的问题引起内核开发人员不满的Xen。2010 年后，RedHat 在其新推出的Redhat Enterprise Linux 6.0 以后2.6.20 以上版本的系统内核中集成了KVM 虚拟机，摒弃了早前RHEL 5.X 系列中集成的Xen。

KVM 是基于Linux 内核的完全原生的全虚拟化解决方案。与半虚拟化（准虚拟化）不同，全虚拟化提供了完整的X86 平台，包括处理器、磁盘空间、网络适配器及RAM 等，其无须对客户机操作系统做任何修改便可运行已存在的基于X86 平台下的操作系统和应用程序。与Xen 相比，其优势显而易见：

KVM 是开源平台，大幅降低了虚拟机的部署成本； KVM 在内核2.6.20 版之后，自动整合到Linux 内核中；Xen 所需的内核源代码补丁与特定的内核版本绑定，而且安装时需要大量的软件包，却仍然无法保证每个Xen 的正常运行；Xen 的虚拟机管理程序是一段单独的源代码，并提供一组专门的管理命令，不是所有Linux 使用者都熟悉；KVM 的命令行管理工具继承自QEMU，已经被Linux 学习者广泛接受。

作为开源虚拟化平台，KVM 适用于规模较大的环境，如虚拟主机达到2500 台以上的情况，旨在节约平台采购与部署的成本；规模在500 台虚拟主机以下时，不妨使用商业平台，毕竟此时在稳定性与性价比上商业平台能达到平衡；当主机数目在两者之间时，不妨考虑以商用平台为主，开源平台为辅的方法更能很好的发挥二者的优势。

目前KVM 已经得到了相当广泛的支持，除了一线的商业Linux 厂商的支持外，蓝色巨人IBM 的鼎力支持也是KVM发展中不可或缺的一个环节。其完善了X86 架构上进行虚拟的限制，并推出了多种KVM 的虚拟化解决方案，意在迅速将虚拟化系统转化为私有云。不得不说，KVM 已经很大程度上成为Linux 系统上创建和支持虚拟机的默认开源方案，将Xen 取而代之，成为未来能与Hype-V 乃至VMware 相抗衡的有力劲旅。