图片简介:
本技术介绍了一种实时数据仓库平台，该实时数据仓库平台包括：业务数据采集系统、日志数据采集系统、分析系统；业务数据采集系统包括candu模块，candu模块对业务数据的变更日志进行同步解析，并将解析后的数据存储至分析系统的kudu存储模块中；日志数据采集系统，用于收集日志数据、对日志数据进行计算，并将计算结果存储至kudu存储模块中；kudu 存储模块根据存储的解析后的数据和计算结果进行实时的数据分析。本技术通过candu模块实时收集分布在各个业务系统上的业务数据的变更日志，实现了业务数据的实时同步。
技术要求
1.一种实时数据仓库平台，其特征在于，包括：业务数据采集系统、日志数据采集系统、分析系统；
所述业务数据采集系统包括candu模块，所述candu模块对业务数据的变更日志进行同步解析，并将解析后的数据存储至所述分析系统的kudu存储模块中；
所述日志数据采集系统，用于收集日志数据、对所述日志数据进行计算，并将计算结果
存储至kudu存储模块中；
所述kudu存储模块根据存储的所述解析后的数据和所述计算结果进行实时的数据分析。
2.根据权利要求1所述的实时数据仓库平台，其特征在于，所述日志数据采集系统包括：
kafka模块，所述日志数据写入所述kafka模块中。
3.根据权利要求2所述的实时数据仓库平台，其特征在于，所述日志数据采集系统还包括：
spark streaming模块，读取所述kafka模块中的所述日志数据、进行实时计算，并将所述计算结果存储至kudu存储模块中。
4.根据权利要求1所述的实时数据仓库平台，其特征在于，所述业务数据采集系统还包括：
业务数据库，用于记录业务数据的变更日志；
canal模块，通过模拟与业务数据库的交互协议，使得所述业务数据库向所述canal模块推送所述变更日志。
5.根据权利要求1所述的实时数据仓库平台，其特征在于，所述分析系统还包括：
impala分析引擎，利用所述impala分析引擎以实现实时的数据分析。
6.根据权利要求1所述的实时数据仓库平台，其特征在于，所述candu模块包括：
Operation子模块，用于通过kudu原生api的异步写入模式，将所述解析后的数据存储至所述kudu存储模块中。
7.根据权利要求6所述的实时数据仓库平台，其特征在于，所述candu模块还包括：
读取子模块，用于从所述candu模块中存储的配置表；
Exchange子模块，用于进行配置表数据的初始化同步。
8.根据权利要求6所述的实时数据仓库平台，其特征在于，所述candu模块还包括：
Manager子模块，用于管理多个Task线程，所述Operation子模块在Task线程中将所述解析后的数据存储至所述kudu存储模块中。
技术说明书
实时数据仓库平台
技术领域
本技术涉及网络技术领域，具体来说，涉及一种实时数据仓库平台。
背景技术
在现有的针对数据仓库的技术方案中，都是采用离线的、且不可更新的分布式hive数据仓库，很难做到实时数据仓库的级别，并且不能做到实时同步业务数据库。如果不能保证时效性，则不能对现有的业务数据分析提供更多改的进。除此之外，现有的数据仓库，不能很方便地被业务人员使用。
整体来说，现有的日志系统存在以下缺陷：1)现有系统大都是hive的离线式的分布式数据仓库，不能满足用户的更新与记录级别的插入功能。2)性能差。现有的hive分布式数据仓库，小数据量的查询性能极差，甚至达不到传统关系数据仓库的性能。3)日志实时数据与历史数据融合问题。现有数据仓库都是离线数据，与实时日志数据无法融合，这样间接阻碍了业务的全数据的分析与挖掘。
针对相关技术中的上停问题，目前尚未提出有效的解决方案。
技术内容
针对相关技术中的上述问题，本技术提出一种实时数据仓库平台，能够实现业务数据库的实时同步。
本技术的技术方案是这样实现的：
根据本技术的一个方面，提供了一种实时数据仓库平台，包括：业务数据采集系统、日志数据采集系统、分析系统；业务数据采集系统包括candu模块，candu模块对业务数据的变更日志进行同步解析，并将解析后的数据存储至分析系统的kudu存储模块中；日志数据采集系统，用于收集日志数据、对日志数据进行计算，并将计算结果存储至kudu存储模块中；kudu存储模块根据存储的解析后的数据和计算结果进行实时的数据分析。
在一个实施例中，日志数据采集系统包括：kafka模块，日志数据写入kafka模块中。
其中，日志数据采集系统还包括：spark streaming模块，读取kafka模块中的日志数据、进行实时的计算，并将计算结果存储至kudu存储模块中。
在一个实施例中，业务数据采集系统还包括：业务数据库，用于记录业务数据的变更日志；canal模块，通过模拟与业务数据库的交互协议，使得业务数据库向canal模块推送变更日志。
在一个实施例中，分析系统还包括：impala分析引擎，利用impala分析引擎以实现实时的数据分析。
在一个实施例中，candu模块包括：Operation子模块，用于通过kudu原生api的异步写入模式，将解析后的数据存储至kudu存储模块中。
其中，candu模块还包括：读取子模块，用于从candu模块中存储的配置表；Exchange子模块，用于进行配置表数据的初始化同步。
其中，candu模块还包括：Manager子模块，用于管理多个Task线程，Operation子模块在Task线程中将解析后的数据存储至kudu存储模块中。
本技术通过candu模块实时收集分布在各个业务系统上的业务数据的变更日志，实现了业务数据的实时同步；利用canal模块、candu模块完成业务数据库数据的实时同步，并利用kafka模块作为日志传输工具发送日志，吞吐量大，且不易丢失日志；利用kudu存储模块可以完成数据的修改，支持增删查改功能；利用分布式查询引擎的impala分析引擎，可以做到实时同步与实时分析；将数据实时同步或写入kudu存储模块，通过impala分析引擎查询kudu存储模块，提高了查询性能；同时，实现了业务数据的实时同步与日志数据的实时同步，能够完成全域的数据融合，帮助用户全面准确的进行数据分析。
附图说明
为了更清楚地说明本技术实施例或现有技术中的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本技术的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1是根据本技术实施例的实时数据仓库平台的框图；
图2是图1中candu模块类图的示意图。
具体实施方式
下面将结合本技术实施例中的附图，对本技术实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本技术一部分实施例，而不是全部的实施例。基于本技术中的实施例，本领域普通技术人员所获得的所有其他实施例，都属于本技术保护的范围。
如图1所示，根据本技术实施例的一种实时数据仓库平台100，包括：业务数据采集系统、日志数据采集系统、分析系统；业务数据采集系统包括candu模块118，candu模块118对业务数据的变更日志进行同步解析，并将解析后的数据存储至分析系统的kudu存储模块130中；日志数据采集系统，用于收集日志数据122、对日志数据122进行计算，并将计算结果存储至kudu存储模块130中；kudu存储模块130根据存储的解析后的数据和计算结果进行实时的数据分析。
实时同步生产系统数据至数据仓库平台100，支持读写分离，能够提供实时分析与数据挖掘的平台100系统。kudu存储模块130是支持快速分析的新型的存储系统，kudu存储模块130可以支持分布式超大数据集的快速查询与分析；利用kudu存储模块130还可以完成数据仓库中数据的修改。
在一个实施例中，candu模块118包括：Operation子模块，用于通过kudu原生api的异步写入模式，将解析后的数据存储至kudu存储模块130中。
其中，candu模块118还可包括：读取子模块，用于从candu模块118中存储的配置表；Exchange子模块，用于进行配置表数据的初始化同步。
其中，candu模块118还可包括：Manager子模块，用于管理多个Task线程，Operation子模块在Task线程中将解析后的数据存储至kudu存储模块130中。
candu模块118是一款实时将变更日志，例如mysql binlog中记录的变更日志，同步解析存储至kudu存储模块130。结合图2所示，candu模块118主要通过CanduManager管理每个CanduTask线程，通过CanduDbsService，CanduDdlService，CanduTablesService读取数据库中的配置表，完成初始化工作，以及作业的控制。CanduTask线程中将Entry解析的数据保存到kudu分布式存储中去。每个数据库对应一个线程。通过kudu原生api的异步写入模式，可以将海量的数据在短时间内写入kudu存储模块130，保证数据的高效写入。Exchange 主要功能是完成表数据初始化同步的功能，每张表在最开始同步的时候，会有历史数据，这部分数据没法从canal中获取到，所以通过初始化可以将数据全部同步到kudu存储模块 130，保证kudu存储模块130的数据完整性。通过CanduTask处理线程类，可有效的管理线程，提供稳定的服务。其中，candu模块118可通过
Candu_dbs，Candu_ddl，Candu_tables三张表控制同步表的增加，删除，与暂停，以及线程数目的控制，一个数据库会起一个CanduTask线程用于同步数据。
在一个实施例中，日志数据采集系统包括：kafka模块124，日志数据122写入kafka模块124中。
在本实施例中，日志数据采集系统还可包括：spark streaming模块126，读取kafka模块124中的日志数据、进行实时计算，并将计算结果存储至kudu存储模块130中。在本实施例中，通过采用spark streaming模块126和kafka模块124，通过kafka模块124与spark streaming 模块126解决日志收集与计算，将结果存储至kudu存储模块130，能够实现实时计算。
kafka模块124是一个开源的消息发布和订阅系统。kafka模块124能够对于TB级别的数据提供一个常量时间性能；采用普通的硬件支持每秒百万级别的吞吐量。通过kafka服务器和消费者机器的集群分布式消费，维持每一个分区是有序的。另外，kafka模块124还具有实时性，消息被生成者线程生产就能马上被消费者线程消费。同时，spark streaming模块126可以在很小的间隔完成数据的处理，spark streaming模块126用来处理kafka模块124的日志数据可做到实时处理，并将结果写入kudu存储模块130，可以保证实时数据仓库的日志数据的实时性。
在一个实施例中，业务数据采集系统还包括：业务数据库114，用于记录业务数据的变更日志；canal模块116，通过模拟与业务数据库114的交互协议，使得业务数据库114向canal 模块116推送变更日志。在一个实施例中，业务数据库114为mysql数据库，mysqlbinlog记录了业务数据库114中所有的变更日志，对外以dump协议的方式提供服务。canal模块116可通过模拟mysql slave的交互协议，伪装自己为mysql slave，向mysql master发送dump协议，这样业务数据库114会将数据推向canal模块116。
在一个实施例中，分析系统还包括：impala分析引擎140，利用impala分析引擎140以实现实时的数据分析。impala分析引擎140是能够与kudu存储模块130很好匹配的查询引擎。通过impala分析引擎140查询kudu存储模块130，可以提供很高的查询性能；将数据实时同步或写入kudu存储模块130，利用impala分析引擎140可完成实时分析。保证了实时数据仓库平台100对全域数据的实时分析。
综上所述，借助于本技术的上述技术方案，通过candu模块实时收集分布在各个业务系统上的业务数据的变更日志，实现了业务数据的实时同步；利用canal模块、candu模块完成业务数据库数据的实时同步，并利用kafka模块作为日志传输工具发送日志，吞吐量大，且不易丢失日志；利用kudu存储模块可以完成数据的修改，支持增删查改功能；利用分布式查询引擎的impala分析引擎，可以做到实时同步与实时分析；将数据实时同步或写入kudu存储模块，通过impala分析引擎查询kudu存储模块，提高了查询性能；同时，实现了业务数据的实时同步与日志数据的实时同步，能够完成全域的数据融合，帮助用户全面准确的进行数据分析。
以上所述仅为本技术的较佳实施例而已，并不用以限制本技术，凡在本技术的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本技术的保护范围之内。
2.5数据仓库模型的设计 数据仓库模型的设计大体上可以分为以下三个层面的设计151: .概念模型设计; .逻辑模型设计; .物理模型设计; 下面就从这三个层面分别介绍数据仓库模型的设计。 2.5.1概念模型设计 进行概念模型设计所要完成的工作是: <1>界定系统边界 <2>确定主要的主题域及其内容 概念模型设计的成果是，在原有的数据库的基础上建立了一个较为稳固的概念模型。因为数据仓库是对原有数据库系统中的数据进行集成和重组而形成的数据集合，所以数据仓库的概念模型设计，首先要对原有数据库系统加以分析理解，看在原有的数据库系统中“有什么”、“怎样组织的”和“如何分布的”等，然后再来考虑应当如何建立数据仓库系统的概念模型。一方面，通过原有的数据库的设计文档以及在数据字典中的数据库关系模式，可以对企业现有的数据库中的内容有一个完整而清晰的认识;另一方面，数据仓库的概念模型是面向企业全局建立的，它为集成来自各个面向应用的数据库的数据提供了统一的概念视图。 概念模型的设计是在较高的抽象层次上的设计，因此建立概念模型时不用考虑具体技术条件的限制。 1.界定系统的边界 数据仓库是面向决策分析的数据库，我们无法在数据仓库设计的最初就得到详细而明确的需求，但是一些基本的方向性的需求还是摆在了设计人员的面前: . 要做的决策类型有哪些? . 决策者感兴趣的是什么问题? . 这些问题需要什么样的信息? . 要得到这些信息需要包含原有数据库系统的哪些部分的数据? 这样，我们可以划定一个当前的大致的系统边界，集中精力进行最需要的部分的开发。因而，从某种意义上讲，界定系统边界的工作也可以看作是数据仓库系统设计的需求分析，因为它将决策者的数据分析的需求用系统边界的定义形式反映出来。 2，确定主要的主题域 在这一步中，要确定系统所包含的主题域，然后对每个主题域的内
数据仓库 学号：20111004458 班级：193113 姓名：华秀 指导老师：李程俊 2015年1月20日
目录 一、数据仓库的定义 (3) 二、实时数据仓库的技术基础和研究现状 (3) 1.技术基础： (3) 2.研究现状 (7) 三、什么是OLTP、OLAP它们的区别有哪些？ (8) OLTP： (8) OLAP: (8) OLAP和OLTP的区别 (8) 四、OLAP有哪些操作 (9) 五、数据立方体 (10) 六、数据挖掘分类 (11) 七、数据挖掘技术 (11) （1）决策树方法 (11) （2）关联规则 (12) （3）神经网络 (12) （4）遗传算法 (12) （5）聚类分析 (12) （6）统计学习 (12) （7）粗糙集 (13) 八、 K means聚类算法 (13)
一、数据仓库的定义 数据仓库之父Bill Inmon在1991年出版的“Building the Data Warehouse”一书中所提出的定义被广泛接受：数据仓库（Data Warehouse）是一个面向主题的（Subject Oriented）、集成的（Integrated）、相对稳定的（Non-Volatile）、反映历史变化（Time Variant）的数据集合，用于支持管理决策（Decision Making Support）。 对于数据仓库的概念我们可以从两个层次予以理解，首先，数据仓库用于支持决策，面向分析型数据处理，它不同于企业现有的操作型数据库；其次，数据仓库是对多个异构的数据源有效集成，集成后按照主题进行了重组，并包含历史数据，而且存放在数据仓库中的数据一般不再修改。数据仓库是近年来才提出的新概念.所谓数据仓库（Data Warehouse）是指这样一种数据的存储地,来自于异地、异构的数据源或数据库的数据经加工后在数据仓库中存储、提取和维护.传统数据库主要面向业务处理,而数据仓库面向复杂数据分析、高层决策支持.数据仓库提供来自种类不同的应用系统的集成化和历史化的数据,为有关部门或企业进行全局范围的战略决策和长期趋势分析提供了有效的支持.数据仓库使用户拥有任意提取数据的自由,而不干扰业务数据库的正常运行. 当前,一些企业已经在传统数据处理方面有了较丰富的经验,他们采用数据仓库希望能从中得到更多好处,例如,以合理的代价取得有效的决策支持、促进企业中业务处理过程的重组、改善并强化对客户的服务、强化企业的资产/负债管理、促进市场优化、加速资金周转、帮助实现企业的规模优化.数据仓库的产生和发展为数据采掘技术开辟了新的战场,同时也提出了新的要求和挑战.目前的研究还主要着眼于数据仓库的构建和维护的基本理论、方法上,例如数据仓库更新问题的研究,因为这是迈向实用化的第一步的、首要的任务.下一步将把重点放在数据仓库的有效应用研究上.为高级的决策支持服务是数据仓库的最终目的,因此基于数据仓库的数据采掘理论和技术的研究,自然成为信息科学学术界的热点问题. 二、实时数据仓库的技术基础和研究现状 1.技术基础： 数据仓库系列技术，主要支撑技术有以下一些： 数据库技术、ETL技术、OLAP技术、元数据管理技术、前台展现技术、报表技术、挖掘技术、仿真优化技术。 这些支撑技术结合各行业业务后，可以生产各式各样的应用。当然这些技术中，重点突出了在数据仓库方面的特征，而忽略了计算机技术的一些特征。比如：OLAP技术，那么就需要计算机存储技术、压缩技术、分区技术、加解密技术、图形化技术等等，这里就不再单独列示。 数据库技术是支撑数据仓库技术的最基础技术。有关系数据库、层次数据库、网络数据库等类型，目前呈现比较好的发展态势的对象关系数据库也是一种类型。最典型的是关系数据库的应用。在数据仓库实践中，关系数据库是实质的数据库存储工具，但针对不同的数据仓库方案，有的关系数据库是还提供了有关的数据仓库元素的查询函数或组件，在支撑数据仓库数据存储的基础上，还能支撑数据仓库的数据探查，比如：Teradata，但是，大部分数据库，以及在大部分数据仓库建设方案中，只是利用数据库作为数据存储的工具。这样，实质上数据仓库与数据库在技术表现看起来可能是一样的，但是，在系统存储模型上却有着本质的区别。数据库技术在存储模型建设方面强调数据模型的规范性和高效存储能力（少冗
前言： 随着我国企业信息化建设步伐的不断加快，全球性市场竞争的加剧，越来越多的企业开始建设自己的数据仓库系统，希望能对历史数据进行具体而又有针对性的分析与挖掘，以期从中发现新客户和客户新的需求。 目前市场上各种数据仓库产品及其解决方案品种繁多，且大多属于“舶来品”，产品定位不同，各有特点，究竟选择哪家的产品能更适合自己的企业特点与未来发展？ 本文对目前市场上九种主流数据仓库产品(Business Objects、Oracle、IBM、Sybase、Informix、NCR、Microsoft、SAS、CA)进行分析与总结，根据各公司提供的数据仓库工具的功能，将其分为三大类：单点产品、提供部分解决方案的产品、提供全面解决方案的产品。下面对其进行一一介绍，以期能够给你的选择提供一定的参考。 九种数据仓库产品及解决方案评析 =============================================== 一、单点产品 这类产品仅局限于数据仓库方案实施中的一部分或某一特定功能，主要是作为第三方产品或者和其它公司的产品结合起来进行使用。比较有特色的是Business Objects。 Business Objects 所谓单点产品是指仅局限于数据仓库方案实施中的一部分或某一特定功能，主要是作为第三方产品或者和其它公司的产品结合起来进行使用。 ?产品特点： Business Objects是一个集查询、报表和OLAP技术为一身的智能决策支持系统。它使用独特的“语义层”技术和“动态微立方”技术来表示数据库中的多维数据，具有较好的查询和报表功能，提供钻取(Drill)等多维分析技术，支持多种平台（所有Windows 平台及Unix平台）和多种数据库（如Oracle、informix、Sybase、Microsoft SQL Server、DB2、CA-Ingres、Teradata、Red Brick、FoxFro、dBase、Access等），同时它还支持Internet/Intranet，可以通过WWW进行查询、报表和分析决策。 ?主要工具： Business Objects提供工具如下： BusinessObjects是集成查询，报表和分析功能的工具； Webintelligence是世界上第一个通过Web进行查询、报表和分析的决策支持工具； Businessquery是第一个可以在Microsoft Excel中集成企业公共数据源中数据的工具； Businessminer是面向主流商业用户的数据挖掘工具，可以实现深入的分析用以发掘深层次的数据之间的关系。
数据分析平台 分析平台 实时加载 & 查询 高级库内分析 数据设计 & 管理工具 列式存储 & 执行 强劲的数据压缩 扩展的MPP架构 自动的高可用性 优化器, 执行引擎 & 负载管理 内在的 BI, ETL, & Hadoop/MapReduce 集成 Vertica的分析平台为特定目的建造的，以使公司从他们的数据中提取价值，他们需要在今天的经济环境中茁壮成长的速度和规模。不像大多数其它的数据仓库供应商正试图改造21世纪的技术，几十年的老基础设施，Vertica的设计和建造自成立以来，为当今最苛刻的分析工作负载。此外，每一个的Vertica的成分是由设计，能够充分利用其他。
Vertica分析平台关键特性 实时查询 & 加载 ?通过不断加载的信息，获取数据的时间 价值，同时允许立即进行丰富的分析。 高级的库内分析 ?不断增长的特点和功能库，展示和处理 更多和CPU内核紧密结合的数据，而无需解压。 数据设计 & 管理工具 ?强大的设置，调整和控制以达到使 用最小的管理工作，就可以进行持续改进，而系统仍然保 持在线。 列式存储 & 执行 ?执行查询快50 - 1000倍，消除了昂贵的 磁盘I / O，没有的索引和物化视图的麻烦和开销。 强劲的数据压缩 ?我们的引擎，以较少的资本性支出完成 更多的压缩数据，同时提供卓越的性能。 可扩展的MPP架构 ?Vertica的自动和无限线性扩展，只需 在网格中添加行业标准x86服务器 自动的高可用性 ?不间断地运行与优化，提供卓越的查询 性能，良好的自动冗余，故障切换和恢复。 优化器执行引擎 & 负载管理 ?获得最大的性能，而无需担 心它如何工作的细节。用户只思考有关的问题，我们快速 地提供答案。 内在的 BI, ETL, & Hadoop/MapReduce 集成 ?一个强大和 不断增长的生态系统的分析解决方案的无缝集成。 今天，世界各地的信息是连续产生的。因此，隔夜批量加载 数据已经成为奢侈的过去。组织必须能够不停顿地加载到信 息到他们的分析平台，同时允许进行数据丰富的分析。 信息的时间价值是非常重要的，在数据产生后，用户越早处理就越有价值。对于零售商来说，这可能意味着即时的 促销和库存的摆放。对于金融公司，这会影响到及时的交易 决策。对于网络游戏公司，这提供了更加个性化和引人入胜 的游戏体验。这个最小延迟的量是不容易的壮举。因为从网 络源，用户鼠标点击，金融交易，传感器网络和越来越多的 其他来源的信息量是压倒性的挑战。
基于阿里云搭建实时数据仓库项目阿里云大学& 尚硅谷联合出品
课程目标 1）学习搭建一个实时数据仓库，掌握数据采集、存储、计算、输出、展示等整个业务流程。 2）整个实时数据仓库系统是在阿里云架构上搭建，掌握并学会运用各个服务组件，及各个组件之间如何联动。 3）前置知识要求 ?熟练掌握SQL语法 ?对Hadoop大数据体系有一定的了解
第1章课程目录 1. 项目需求及架构设计 1.1 项目需求分析 1.2 项目框架 1.2.1 阿里云技术框架 1.2.2 技术选型 1.2.3 系统架构设计 1.2.4 业务流程 1.3 电商表结构 2.业务数据准备 3.缓冲数据 4.同步业务数据 5.实时数仓分层 6.数据可视化
1.1 项目需求分析1）实时采集埋点日志数据2）实时采集业务数据库中数据3）对数据进行清洗和处理4）保存数据到分析型数据库5）对结果进行可视化展示
1.2.1 阿里云技术框架 阿里云产品简介 类比DataHub 数据总线 Kafka +各种服务接口DataWorks （Stream Studio ）可视化StreamCompute 的开发管理平台 目前没有RDS 关系型数据库 MySql DataV 可视化数据展示工具Tableau 、Echarts 、Kibana ECS 弹性服务器 Linux 服务器AnalyticDB for MySql 分析型数据库 MySql 集群实时计算实时计算 Spark 、Flink
1.2.2 技术选型 ?数据存储：?数据计算：?数据可视化： 开源框架 阿里云框架 Flume、Kafka、Canal、MaxWell DataHub、DTS MySql、Hadoop、HBase RDS、AnalyticDB Spark、Flink 实时计算 ?数据采集传输： Tableau、Echarts、Kibana DataV、QuickBI
数据仓库系统与传统数据库系统的区别数据库是面向事务的设计，数据仓库是面向主题设计的。数据库一般存储在线交易数据，数据仓库存储的一般是历史数据。数据库设计是尽量避免冗余，一般采用符合范式的规则来设计，数据仓库在设计是有意引入冗余，采用反范式的方式来设计。数据库是为捕获数据而设计，数据仓库是为分析数据而设计，它的两个基本的元素是维表和事实表。数据仓库，是在数据库已经大量存在的情况下，为了进一步挖掘数据资源、为了决策需要而产生的，它决不是所谓的“大型数据库”。 数据挖掘与传统分析工具不同的是数据挖掘使用的是基于发现的方法，运用模式匹配和其它算法决定数据之间的重要联系。 数据挖掘的步骤 1.描述数据--- 计算统计变量（比如平均值、均方差等），再用图表或图片直观的表示出来，进而可以看出一些变量之间的相关性。 2.历史数据建立一个预言模型，然后再用另外一些数据对这个模型进行测试。 3.验证你的模型 数据挖掘与传统数据分析方法区别（1）数据挖掘的数据源与以前相比有了显著的改变；数据是海量的;数据有噪声；数据可能是非结构化的；（2）传统的数据分析方法一般都是先给出一个假设然后通过数据验证，在一定意义上是假设驱动的；与之相反，数据挖掘在一定意义上是发现驱动的，模式都是通过大量的搜索工作从数据中自动提取出来。即数据挖掘是要发现那些不能靠直觉发现的信息或知识，甚至是违背直觉的信息或知识，挖掘出的信息越是出乎意料，就可能越有价值。在缺乏强有力的数据分析工具而不能分析这些资源的情况下，历史数据库也就变成了“数据坟墓”－里面的数据几乎不再被访问。也就是说，极有价值的信息被“淹没”在海量数据堆中，领导者决策时还只能凭自己的经验和直觉。因此改进原有的数据分析方法，使之能够智能地处理海量数据，即演化为数据挖掘。 数据挖掘方法与过程 方法：决策树关联规则人工神经网络粗糙集理论遗传算法 过程：1.对数据库数据整理，抽取出用来完成特定挖掘目标的数据集。2.选择合适的挖掘方法和工具，在领域专家指导下进行知识获取研究3.对事物的发展进行预测 数据采集与处理：从数据仓库中选取相关的数据集合。知识库：指导数据挖掘和评价挖掘结果。数据挖掘：对数据仓库中提取的数据进行分析处理。知识评价：是以兴趣度作为衡量标准来查找和选择对最终决策活动友有益的的知识。OLAP与数据挖掘（DM）的比较相同之处：OLAP与DM都是数据库(数据仓库)上的分析工具；不同之处：（1）前者是验证型的,后者是挖掘型的；（2）前者建立在多维视图的基础之上，强调执行效率和对用户请求命令的及时响应，而且其直接数据源一般是数据仓库；后者建立在各种数据源的基础上,重在发现隐藏在数据深层次的对人们有用的模式,一般并不过多考虑执行效率和响应速度。 （3）数据挖掘与OLAP不同，主要体现在它分析数据的深入和分析过程的自动化，自动化的含义是其分析过程不需要客户的参与，这是它的优点，也正是其不足。因为在实际中，客户也希望参与到挖掘中来，例如只想对数据的某一子集进行挖掘，对不同抽取、集成水平的数据进行挖掘，或是根据自己的需要动态选择挖掘算法等等。因此，OLAP与数据挖掘各有所长。 OLAP与OLTP的区别（1）OLTP主要面向公司职员;OLAP则主要面向公司领导者。（2）OLTP应用主要是用来完成客户的事务处理，其数据基础是操作型数据库，如民航订票系统、银行储蓄系统等等，通常需要进行大量的更新操作，同时对响应时间要求较高;而OLAP是以数据仓库或数据多维视图为基础的数据分析处理，是针对特定问题的联机数据访问和分析，它一般不对仓库数据作修改处理，而只是查询，其应用主要是对客户当前及历史数据进行分析，辅助领导决策，其典型的应用有对银行信用卡风险的分析与预测、公司市场营销策略的制定等，主要是进行大量的查询操作，对时间的要求不太严格。 OLTP OLAP 面向人群业务系统的操作、维护人员管理、决策者 功能日常操作处理分析、决策辅助 实现方式基于交易的处理系统基于查询的分析系统 应用场合面向生产应用面向特定主题 数据库设计实体-联系模型星形或雪花模型 数据当前的、最新的细节数据历史的、聚合的数据 响应时间对响应时间要求非常高查询时间长 数据仓库与数据集市的差别 （1）范围不同：数据仓库面向的是整个企业，为整个企业提供所需的数据；数据集市则面向各个部门。 （2）粒度不同：数据仓库中的数据粒度非常小；数据集市中的数据主要是概括级的数据。 （3）数据组织方式不同数据集市中数据的结构通常被描述为星型结构或雪花结构。一个星型结构包含两个基本部分—一个事实表和各种支持维表。事实表描述数据集市中最密集的数据。在电话公司中，用于呼叫的数据是典型的最密集数据；在银行中，与账目核对和自动柜员机有关的数据是典型的最密集数据。对于零售业而言，销售和库存数据是最密集的数据等等。 数据仓库:是一个面向主题的、集成的、不可更新的且随时间不断变化的数据集合，用来支持管理人员的决策。数据仓库的根本任务：把信息加以整理归纳并及时提供给管理决策人员。主要作用：提供报表和图表、支持多维分析、数据挖掘的基础。
提升数据保护：Oracle数据仓库的实时数据采集在使用数据仓库软件时，最常见的约束之一是源系统数据批量提取处理时的可用时间窗口。通常，极其耗费资源的提取流程必须在非工作时间进行，而且仅限于访问关键的源系统。 低影响实时数据整合软件可以释放系统的批处理时间。当提取组件使用非侵入式方法时，如通过读取数据库事务日志，只会捕捉发生变化的数据，不会对源系统产生影响。因此，数据提取流程可以在任意时段全天候执行，即使用户在线也可以。 当以实时方式提取数据时，虽然必须改变数据采集流程中各个元素支持实时数据的方式，但是这些数据可以带来不一般的业务价值。而且，这些数据必须得到有效的保护，同时也很难针对这些不停变化的数据应用灾难恢复和备份技术。 但是，在数据仓库中应用实时数据整合的技术也可以进一步保护数据。毕竟，实时移动数据的技术也可以实时操作数据，从而形成一个数据保护技术入口。但是，变化数据的速度和效率可能会受制于数据保护流程的延迟。
这意味着，在转到整合数据仓库的主动数据采集模式时，首要考虑的问题之一是数据经过IT系统的流程和可能产生的延迟。换而言之，实时数据整合要求理解变化的数据，以及促进或妨碍这种变化的组件。 显然，企业希望保护他们的数据。然而，随着数据容量需求的增长，存储技术也成为业务持续性依赖的重要业务资产。而且，随着实时分析成为业务流程的一部分，它也归入到业务持续性的范畴之中。实现数据安全性和持续性的最基本方法是硬件或软件复制，它会自动保存第二个关键数据副本。此外，自行创建或基于开源软件创建的备份方法也不存在。 企业级数据管理应用主要涉及5个重要领域：灾难恢复、高可用性、备份、数据处理性能和更高级数据库移植。这促使IT不停地追寻先进技术，如实现数据整合及其相关基础架构元素。此外，这些战略投资能够提供符合预算的资源，在加快实时技术应用的同时，提高投资回报和修正实时数据整合项目的商业提案。
数据仓库概念的简单理解 一个典型的企业数据仓库系统通常包含数据源、数据存储与管理、OLAP服务器以及前端工具与应用四个部分。如下图所示： 数据源： 是数据仓库系统的基础，是整个系统的数据源泉。通常包括企业内部信息和外部信息。内部信息包括存放于企业操作型数据库中（通常存放在RDBMS中）的各种业务数据和办公自动化（OA）系统包含的各类文档数据。外部信息包括各类法律法规、市场信息、竞争对手的信息以及各类外部统计数据及各类文档等；数据的存储与管理： 是整个数据仓库系统的核心。在现有各业务系统的基础上，对数据进行抽取、清理，并有效集成，按照主题进行重新组织，最终确定数据仓库的物理存储结构，同时组织存储数据仓库元数据（具体包括数据仓库的数据字典、记录系统定义、数据转换规则、数据加载频率以及业务规则等信息）。按照数据的覆盖范围，数据仓库存储可以分为企业级数据仓库和部门级数据仓库（通常称为“数据集市”，Data Mart）。数据仓库的管理包括数据的安全、归档、备份、维护、恢复等工作。这些功能与目前的DBMS基本一致。 OLAP服务器： 对分析需要的数据按照多维数据模型进行再次重组，以支持用户多角度、多层次的分析，发现数据趋势。其具体实现可以分为：ROLAP、MOLAP和HOLAP。ROLAP 基本数据和聚合数据均存放在RDBMS之中；MOLAP基本数据和聚合数据均存放于多维数据库中；而HOLAP是ROLAP与MOLAP的综合，基本数据存放于RDBMS之中，聚合数据存放于多维数据库中。 前端工具与应用： 前端工具主要包括各种数据分析工具、报表工具、查询工具、数据挖掘工具以及各种基于数据仓库或数据集市开发的应用。其中数据分析工具主要针对OLAP服务器，报表工具、数据挖掘工具既针对数据仓库，同时也针对OLAP服务器。? 集线器与车轮状结构的企业级数据仓库 ?
1、数据仓库定义：数据仓库是一种新的数据处理体系结构，它与组织机构的操作数据库分别维护，允许将各种应用系统一起，为统一的历史数据分析提供坚实的平台，对信息处理提供支持。数据仓库是面向主题的、集成的、相对稳定的、反映历史变化的数据集合，为企业决策支持系统提供所需的集成信息。设计和构造步骤：1）选取待建模的商务处理；2）选取商务处理的粒变；3）选取用于每个事实表记录的维；4）选取事实表中每条记录的变量 系统结构：（1）底层是仓库数据服务器，总是关系数据库系统。（2）中间层是OLAP服务器，有ROLAP 和MOLAP，它将对多维数据的操作映射为标准的关系操作（3）顶层是前端客户端，它包括查询和报表工具、分析工具和数据挖掘工具 2、数据仓库的多维数据模型：（1）星形模式：在此模型下，数据仓库包括一个大的包含大批数据并且不含冗余的中心表，一组小的附属表，维表围绕中心事实表显示的射线上。特征：星型模型四周的实体是维度实体，其作用是限制和过滤用户的查询结果，缩小访问围。每个维表都有自己的属性，维表和事实表通过关键字相关联。【例子：sales数据仓库的星形模式，此模式包含一个中心事实表sales，它包含四个维time, item, branch和location。 （2）雪花型模式：它是星形模式的变种，其中某些维表是规化的，因而把数据进一步分解到附加的表中。特征：雪花模型通过最大限度地减少数据存储量和联合较小的维表来改善查询性能，增加了用户必须处理的表数量和某些查询的复杂性，但同时提高了处理的灵活性，可以回答更多的商业问题，特别适合系统的逐步建设要求。【例子同上，只不过把其中的某些维给扩展了。 （3）事实星座形：复杂的应用可能需要多个事实表共享维表，这种模式可看作星形模式的汇集。 特征：事实星座模型能对多个相关的主题建模。例子：有两个事实表sales和shipping，它们可以共享维表time, item和location。 3、OLAP：即联机分析处理，是在OLTP基础上发展起来的、以数据仓库基础上的、面向高层管理人员和专业分析人员、为企业决策支持服务。特点：1.实时性要求不是很高。2.数据量大。3.因为重点在于决策支持，所以查询一般是动态的，也就是说允许用户随机提出查询要求。 OLAP操作：上卷：通过沿一个维的概念分层向上攀登，或者通过维归约，对数据立方体进行类聚。下钻：是上卷的逆操作，它由不太详细的数据得到更详细的数据，下钻可以通过沿维的概念分层向下或引入附加的维来实现。切片：对给定方体的一个维进行进行选择，导致一个子立方体。切块：通过对两个或多个维执行选择，定义子立方体。转轴：是一种可视化操作，它转动数据的视角，提供数据的替代表示。 OLTP：即联机事务处理，是以传统数据库为基础、面向操作人员和低层管理人员、对基本数据进行查询和增、删、改等的日常事务处理。OLTP的特点有：a.实时性要求高；b.数据量不是很大。C.交易一般是确定的，是对确定性数据进行存取。d.并发性要求高且严格的要求事务的完整性，安全性。 OLTP和OLAP的区别：1）用户和系统的面向性:OLTP面向顾客，而OLAP面向市场；2）数据容：OLTP 系统管理当前数据，而OLAP管理历史的数据；3）数据库设计：OLTP系统采用实体-联系（ER)模型和面向应用的数据库设计，而OLAP系统通常采用星形和雪花模型；4）视图：OLTP系统主要关注一个企业或部门部的当前数据，而OLAP 系统主要关注汇总的统一的数据；5）访问模式：OLTP访问主要有短的原子事务组成，而OLAP系统的访问大部分是只读操作，尽管许多可能是复杂的查询。 7、PageRank算法原理：1）在初始阶段：构建Web图，每个页面初始设置相同的PageRank 值，通过迭代计算，会得到每个页面所获得的最终PageRank值。2）在一轮中更新页面 PageRank得分的计算方法：每个页面将其当前的PageRank值平均分配到本页面包含的出 链上。每个页面将所有指向本页面的入链所传入的权值求和，即可得到新的PageRank得分。 优点：是一个与查询无关的静态算法，所有网页的PageRank值通过离线计算获得；有效减 少在线查询时的计算量，极大降低了查询响应时间。 缺点：1）人们的查询具有主题特征，PageRank忽略了主题相关性，导致结果的相关性和主 题性降低。2）旧的页面等级会比新页面高。因为即使是非常好的新页面也不会有很多上游， 除非它是某个站点的子站点。
BI项目技术总结(2) ----DW设计 1数据仓库模型设计 注意事项：本文的所有SQL脚本都经过测试，如有问题请随时联系沟通。 1.设计模型图例 2.设计模式对比 星型设计 优点：使用星型结构，使维度和事实表的关系简单、清晰，且计算没有冗余。 缺点：前期数据仓库设计要求高，合理规划事实表与维表的星型结构。 雪花型设计 优点：数据仓库前期的设计要求不高，易于边实施边设计。 缺点：使用雪花型结构，使维度与事实表的关系复杂，且出现多表关联的冗余，降低sql的运行效率。 2数据仓库设计注意事项 以星型设计模式为例简单阐述数据仓库设计的注意事项。 维表设计注意事项（Dim）
1)维度设计原则：以事实表为中心，维度表确保星型连接优化； 2)使用整型键列连接事实表和维度表，可以最低占用内存，便于压缩，优化查询； 3)避免主外键约束，在ETL过程中提高数据库执行效率； 4)在Loopup所使用的业务键上建立聚集索引： –业务键不作维度表主键 –可以提升Loopup速度； 5)在维度主键、其他常用列上建立非聚集索引； 6)不建议对维度表分区。 事实表设计注意事项（Fct） 1)一般在事实表的维度列上创建聚集索引，支持对指定的维度提取事实表的业务数据； 2)在其他常用列上建立非聚集索引， 3)TempDB的大小与事实表相匹配，以Oracle为例，一般建议TempDB大小为事实表的20% 左右（仅供参考）； 4)对大表进行分区，一般在日期列或者地区代码列上建立分区索引 –易于新增和删除数据 –易于新增和删除分区 –提高数据执行效率 –易于数据管理：恢复、备份等； 5)日期型数据建议用整型格式表示(20090215) –作为索引值可以提高数据库执行效率 –易用于条件查询 3数据仓库模式选择 对于BI项目，一般数据量比较大，会达到千万级、亿级的数据记录。这就要对事实表设计时既要考虑数据的粒度，同时要兼顾系统的运行效率。 目前数据仓库主要设计模式如下： 1)关系型OLAP(ROLAP)表示基于关系数据库的OLAP实现（Relational OLAP）； 2)多维型OLAP(MOLAP) 基于多维数据存储的在线分析处理，MOLAP服务器提供数据存储管理，一
数据仓库生产环境操作手册 一．运维概述 “数据仓库生产系统”的运行维护责任在于保障系统运行，运维方式主要是操作员通过工作机远程登陆到系统中的相关主机，对主机进行操作，包括automation 调度系统、数据库、磁盘、软件环境、数据情况等，查看批出理的运行情况，一 旦运行出现问题作相应的记录并通知相关的技术人员，作出相应的处理。 所有运维项目成员严格按照《数据仓库系统运维守则.doc》文档来进行运维检查工作，否则出现事故由值班人员和当日值班负责人承担事故责任。 二．运维内容 1．每日维护 1.1数据检查 每日批处理运行前运行完成后都需要对源头的数据和生产出的数据进行检查，确保当日批处理程序正常从事生产。检查工作在每日9：00-9：30之间完成，且必须在启动程序（批处理程序）前执行。具体规定如下： 1.1.1 转定长数据的检查 每天上午9:00--9：45之间，运维值班人员进行这项工作具体执行步骤如下: 1.在本地工作机上使用telnet远程登录工具登录到168.7.6.163服务器上，输入用户名sjtq,密码:cib2009edw, 2.输入命令cd EDW/sh/log 3.输入命令more yyyymmdd当天的日志，是否有错误信息，最后数据是否都上传结束。 4.以下错误属于正常情况： 03:00:03 : 1.检查20091031标志文件失败～～～～～～～～～ 03:00:03 : 1.数据标志检查失败，等待5分钟(06001/dta_varied) 正常等待情况 5.检查点如下： 1）每个大任务开始的初始化操作 03:00:00 : ================ 0.环境变量设置完毕================
第1章数据仓库建设 1.1数据仓库总体架构 专家系统接收增购项目车辆TCMS或其他子系统通过车地通信传输的实时或离线数据，经过一系列综合诊断分析，以各种报表图形或信息推送的形式向用户展示分析结果。针对诊断出的车辆故障将给出专家建议处理措施，为车辆的故障根因修复提供必要的支持。 根据专家系统数据仓库建设目标，结合系统数据业务规范，包括数据采集频率、数据采集量等相关因素，设计专家系统数据仓库架构如下： 数据仓库架构从层次结构上分为数据采集、数据存、数据分析、数据服务等几个方面的内容： 数据采集：负责从各业务自系统中汇集信息数据，系统支撑Kafka、Storm、Flume
及传统的ETL采集工具。 数据存储：本系统提供Hdfs、Hbase及RDBMS相结合的存储模式，支持海量数据的分布式存储。 数据分析：数据仓库体系支持传统的OLAP分析及基于Spark常规机器学习算法。 数据服务总线：数据系统提供数据服务总线服务，实现对数据资源的统一管理和调度，并对外提供数据服务。 1.2数据采集 专家系统数据仓库数据采集包括两个部分内容：外部数据汇集、内部各层数据的提取与加载。外部数据汇集是指从TCMS、车载子系统等外部信息系统汇集数据到专家数据仓库的操作型存储层（ODS）；内部各层数据的提取与加载是指数据仓库各存储层间的数据提取、转换与加载。 1.2.1外部数据汇集 专家数据仓库数据源包括列车监控与检测系统（TCMS）、车载子系统等相关子系统，数据采集的内容分为实时数据采集和定时数据采集两大类，实时数据采集主要对于各项检测指标数据；非实时采集包括日检修数据等。 根据项目信息汇集要求，列车指标信息采集具有采集数据量大，采集频率高的特点，考虑到系统后期的扩展，因此在数据数据采集方面，要求采集体系支持高吞吐量、高频率、海量数据采集，同时系统应该灵活可配置，可根据业务的需要进行灵活配置横向扩展。 本方案在数据采集架构采用Flume+Kafka+Storm的组合架构，采用Flume和ETL 工具作为Kafka的Producer，采用Storm作为Kafka的Consumer，Storm可实现对海量数据的实时处理，及时对问题指标进行预警。具体采集系统技术结构图如下:
·数据仓库（Data Warehouse）是一个面向主题的（Subject Oriented）、集成的（Integrate）、相对稳定的（Non-Volatile）、反映历史变化（Time Variant）的数据集合，用于支持管理决策。 ·数据仓库的特点 –面向主题 –集成 –相对稳定 –反映历史变化 数据仓库是一个面向主题的、集成的、不可更新的、随时间不断变化的数据集合，它用于支持企业或组织的决策分析处理。 数据仓库，Data Warehouse，可简写为DW。 数据仓库之父Bill Inmon在1991年出版的“Building the Data Warehouse”一书中所提出的定义被广泛接受——数据仓库（Data Warehouse）是一个面向主题的（Subject Oriented）、集成的（Integrated）、相对稳定的（Non-Volatile）、反映历史变化（Time Variant）的数据集合，用于支持管理决策(Decision Making Support)。 ◆面向主题：操作型数据库的数据组织面向事务处理任务，各个业务系统之间各自分离，而数据仓库中的数据是按照一定的主题域进行组织的。 ◆集成的：数据仓库中的数据是在对原有分散的数据库数据抽取、清理的基础上经过系统加工、汇总和整理得到的，必须消除源数据中的不一致性，以保证数据仓库内的信息是关于整个企业的一致的全局信息。 ◆相对稳定的：数据仓库的数据主要供企业决策分析之用，所涉及的数据操作主要是数据查询，一旦某个数据进入数据仓库以后，一般情况下将被长期保留，也就是数据仓库中一般有大量的查询操作，但修改和删除操作很少，通常只需要定期的加载、刷新。 ◆反映历史变化：数据仓库中的数据通常包含历史信息，系统记录了企业从过去某一时点(如开始应用数据仓库的时点)到目前的各个阶段的信息，通过这些信息，可以对企业的发展历程和未来趋势做出定量分析和预测。 从功能结构化分，数据仓库系统至少应该包含数据获取（Data Acquisition）、数据存储（Data Storage）、数据访问（Data Access）三个关键部分。 发展阶段： 数据仓库的架构 1.数据源：他是数据仓库的基础，位于数据仓库构架的最底层，是数据仓库的数据源泉。包括各个业务处理子系统的信息。 2. ETL：是数据仓库的核心。数据仓库如何高效管理数据是区别与面向操作数据库的主要标准。完成按照主题管理数据，聚合数据存放于多维数据库中。 3.数据存储与管理：是整个数据仓库系统的核心 4.OLAP服务器：对分析需要的数据进行有效集成，按多维模型予以组织，以便进行多角度、多层次的分析，并发现趋势 5.前端展现：主要包括各种报表、查询、OLAP分析、数据挖掘等。
数据仓库 一数据仓库简介 随着处理信息量的不断加大，企业需要多角度处理海量信息并从中获取支持决策的信息，面向事务处理的操作型数据库就显得力不从心，面向主题集成大量数据的数据仓库技术产生。数据仓库因其面向主题性，集成性，稳定性和时变性，不仅在数据的集成，存储上效果好，在从操作系统提取信息和支持系统造作者的前端工具上更是充分利用了数学严谨的逻辑思维和统计学知识，以及先进的信息技术，使企业的信息利用更有价值。数据仓路按照特定的方法（ETL）从数据源中提取数据，以特定主题作维度利用特定的算法集成数据，给数据用户提供实时查询，最终集成有效信息供决策者使用。数据仓库是个过程而不是一个项目，是一个解决方案而不是一个产品。 数据仓库之父比尔·恩门（Bill Inmon）在1991年出版的“Building the Data Warehouse”（《建立数据仓库》）一书中所提出的定义被广泛接受，数据仓库是一个面向主题的（Subject Oriented）、集成的（Integrate）、相对稳定的（Non-Volatile）、反映历史变化（Time Variant）的数据集合，用于支持管理决策。 二数据仓库历史 1.1981年NCR公司（national cash register corporation）为Wal mart 建立了第一个数据仓库，总容量超过101TB(十年的会计文档还不足1TB) 2.商务智能的瓶颈是从数据到知识的转换。1979年，一家以决策支持系统为已任、致力于构建单独的数据存储结构的公司Teradata诞生了。Tera，是万亿的意思，Teradata的命名表明了公司处理海量运营数据的决心。1983年，该公司利用并行处理技术为美国富国银行（Wells Fargo Bank）建立了第一个决策支持系统。这种先发优势令Teradata至今一直雄居数据行业的龙头榜首。 3. 1988年，为解决企业集成问题，IBM公司的研究员Barry Devlin和Paul Murphy创造性的提出了一个新的术语：数据仓库（Data Warehouse） 4.1992年，比尔·恩门（Bill Inmon）出版了《如何构建数据仓库》一书，第一次给出了数据仓库的清晰定义和操作性极强的指导意见，真正拉开了数据仓库得以大规模应用的序幕。 5.1993年，毕业于斯坦福计算机系的博士拉尔夫·金博尔，也出版了一本书：《数据仓库的工具》（The Data Warehouse Toolkit），他在书里认同了比尔·恩门对于数据仓库的定义，但却在具体的构建方法上和他分庭抗礼。最终拉尔夫金博尔尔由下而上，从部门到企业的数据仓库建立方式迎合人们从易到难的心理，得到了长足的发展。 6.1996年，加拿大的IDC（international date corporation）公司调查了62家实现数据仓库的欧美企业，结果表明：数据仓库为企业提供了巨大的收益、进行数据仓库项目开发的公司在平均2.72年内的投资回报率为321%。 7．到如今，数据仓库已成为商务智能由数据到知识，由知识转化为利润的基础和核心技术。 8.在国内，因数据仓库的实施需要较多的投入，再加之需要足够的数据积累才能看到结果，不能很好的被企业普遍接受。对数据仓库的发展产生了一些负面影响。但实时的，多维的处理海量数据已成为信息时代企业发展所必须的工作。 三主流数据仓库产品 IBM、Oracle、Sybase、CA、NCR、Informix、Microsoft和SAS等有实力的公司相继通过收购或研发的途径推出了自己的数据仓库解决方案。BO和Brio等专业软件公司也前端在线分析处理工具市场上占有一席之地。根据各个公司提供的数据仓库工具的功能，可以将其分为3大类：解决特定功能的产品（主要包括BO的数据仓库解决方案）、提供部分解决方案的产品（主要包括Oracle、IBM、Sybase、Informix、NCR、Microsoft及SAS等公司的数据仓库解决方案）和提供全面解决方案的产品（CA是目前的主要厂商）。
分享三款主流数据库及其特点 1.Oracle数据库 Oracle Database，又名Oracle RDBMS，或简称Oracle。是甲骨文公司的一款关系数据库管理系统。它是在数据库领域一直处于领先地位的产品。可以说Oracle数据库系统是目前世界上流行的关系数据库管理系统，系统可移植性好、使用方便、功能强，适用于各类大、中、小、微机环境。它是一种高效率、可靠性好的、适应高吞吐量的数据库解决方案。 基本介绍： ORACLE数据库系统是美国ORACLE公司（甲骨文）提供的以分布式数据库为核心的一组软件产品，是目前最流行的客户/服务器(CLIENT/SERVER)或B/S体系结构的数据库之一。比如SilverStream就是基于数据库的一种中间件。ORACLE数据库是目前世界上使用最为广泛的数据库管理系统，作为一个通用的数据库系统，它具有完整的数据管理功能；作为一个关系数据库，它是一个完备关系的产品；作为分布式数据库它实现了分布式处理功能。但它的所有知识，只要在一种机型上学习了ORACLE知识，便能在各种类型的机器上使用它。Oracle数据库最新版本为Oracle Database12c。Oracle数据库12c引入了一个新的多承租方架构，使用该架构可轻松部署和管理数据库云。此外，一些创新特性可最大限度地提高资源使用率和灵活性，如Oracle Multitenant可快速整合多个数据库，而Automatic Data Optimization和Heat Map能以更高的密度压缩数据和对数据分层。这些独一无二的技术进步再加上在可用性、安全性和大数据支持方面的主要增强，使得Oracle数据库12c成为私有云和公有云部署的理想平台。
1.数据仓库概述 经过多年IT的建设，信息对于XXX的日常管理已经日益重要，并逐渐成为重要的信息资产，信息资产的管理已经成为日常管理中一个非常重要的环节。如何管理和利用好XXX内部纷繁的数据也越来越成为信息管理的一项重要工作。 在过去相当一段时间内，XXX业务系统的构建主要围绕着业务的数据展开，应用的构建多是自下而上构建，主要以满足某个部门的业务功能为主，我们称之为业务处理的时代。这样的构建方式造成了一个个分立的应用，分立的应用导致了一个个的静态竖井。由于数据从属于应用，缺乏XXX全局的单一视图，形成了一个个信息孤岛，分立的系统之间缺乏沟通，同样数据的孤岛导致只能获得片面的信息，而不是全局的单一视图。存储这些信息的载体可能是各种异构或同构的关系型数据库，也有可能是XML、EXCEL等文件。因此，构建新一代的一体化平台提上了日程并最终促成全域数据的管理方式，目的是覆盖XXX各个环节的关键业务数据，完善元数据管理，形成全局的数据字典、业务数据规范和统一的业务指标含义，能够灵活的获取XXX业务数据的单一视图（需要保证数据的一致性、完整性、准确性和及时性）。数据的交换和共享主要发生在上下级组织机构之间或同级的不同部门之间。最终，这些数据可以为部队分析、决策支持（多维分析、即席查询、数据挖掘）等应用提供更及时、准确、有效的支持。 数据仓库的目标是实现跨系统数据共享，解决信息孤岛，提升数据质量，辅助决策分析，提供统一的数据服务。同时，数据仓库的构建也面临着各种挑战，比如信息整合在技术上的复杂度、信息整合的管理成本、数据资源的获取、信息整合的实施周期以及整合项目的风险等。
2. 全域数据库总体架构 边防一体化其他XML Excel Web 服务消息队列文本数据智能传感器 虚拟传感器摄像头全域数据库总体架构 全域数据库总体的层次，最下面是基础架构层，主要包括支撑这一架构运行的主机系统、存储备份系统、网络系统等内容。从下往上看，再上面是数据源层，既包括各个业务的关系型数据源、内容管理数据源也包括半结构化数据源比如XML 、EXCEL 等，也包括各个总队、支队的业务数据源。 数据源层之上是“交换服务体系”，主要包括信息服务总线和服务总线两部分。信息服务总线主要实现数据层的信息整合和数据转换，而服务总线主要实现应用层的信息交换和整合。信息服务总线主要依托联邦、复制、清洗、转换等技术实现，其主要包括信息整合服务和清洗转换加载服务两部分。通过信息服务总线的信息整合服务（数据联邦、复制），可以透明、实时的访问分布在总队和支队的各个业务系统中的