数仓学习之路一

一、数据仓库的起源

数据仓库，英文名称为Data Warehouse，可简写为DW或DWH。数据仓库之父比尔∙恩门（Bill Inmon）在1991年出版的“Building the Data Warehouse”（《建立数据仓库》）一书中所提出的定义被广泛接受——数据仓库（Data Warehouse）是一个面向主题的（Subject Oriented）、集成的（Integrated）、相对稳定的（Non‐Volatile）、反映历史变化（Time Variant）的数据集合，用于支持管理决策(Decision Making Support)。
将业务处理系统和分析系统分开，即将业务处理和分析处理分为不同层次，针对各自的特点采取不同的架构设计原则定义了分析系统的四个组成部分：数据获取、数据访问、目录和用户服务。

二、数据仓库的背景

1、数仓主要用于解决企业级的数据分析问题。
2、数据库是面向事务的设计，数据仓库是面向主题设计的，即信息是按主题进行组织的。
3、数据库设计是尽量避免冗余，一般采用符合范式的规则来设计，数据仓库在设计是有意引入冗余，采用反范式的方式来设计。
4、数据库是为捕获和存储数据而设计，数据仓库是为分析数据而设计。
l 由于安全以及权限的因素，有些业务数据不能直接访问
l 业务系统变更频繁，每次变更都要重写分析系统，字段的增删更改等
l 很难生成和维护跨业务系统的汇总报表
l 业务系统的列名通常是硬编码，有时仅仅是无意义的字符串（拼音缩写等，很多保险公司的字段用大写的拼音缩写，基本上看不出含义），当业务系统很多，命名规范不一致的问题，给分析人员带来很大的困难
l 业务系统的表结构为事务处理性能而优化，有时并不适合查询分析，有时候要取个汇总的数据要关联很多表
l 没有适当的方式将有价值的数据合并进特定应用的数据库
l 没有适当的位置存储元数据
l 用户需要的字段，有时在业务数据库中并不存在
l 分析查询往往很耗性能，这给业务系统增加额外性能压力，会影响业务系统的正常运行
l 通常事务处理的优先级要高于分析系统，如果分析系统和事务处理运行在一个服务器上，分析系统往往性能很差
并且性能的消耗，如果宕机直接就影响到了事务处理，没有在业务系统运行的服务器上去分析数据的
l 背锅，如果跟业务系统一起，只要业务系统出了问题，开发人员一定会说是分析数
据造成的

三、数据仓库的定义

**数据仓库即Data Warehouse，简称DW，主要研究和解决从数据中获取信息的问题，为企业所有级别的决策制定过程，提供所有类型数据支持的战略集合。**本质上，数据仓库试图提供一种从操作型系统到决策支持系统的数据流架构模型。主要是解决多重数据复制带来的高成本问题。在有数仓之前，需要大量的冗余数据来支撑多个决策支持系统，尽管每个系统服务于不同的用户，但是这些系统经常需要大量相同的数据。决策支持系统Decision support System，即DDS，是用于支持业务或组织决策活动的信息系统，服务于组织管理、运营和规划管理层（通常是中层或高级管理层），帮助人们对可能快速变化且不容易预测结果的问题做出决策。数据仓库就是为决策系统提供数据支持的。

1.联机分析处理 VS 联机事务处理（OLAP和OLTP）

联机事务处理OLTP（on-line transaction processing） 主要是执行基本日常的事务处理，比如数据库记录的增删查改。比如在银行的一笔交易记录，就是一个典型的事务。

OLTP的特点一般有：

1.实时性要求高。曾经银行异地汇款，要隔天才能到账，而现在是分分钟到账的节奏，说明现在银行的实时处理能力大大增强。
2.数据量不是很大，生产库上的数据量一般不会太大，而且会及时做相应的数据处理与转移。
3.交易一般是确定的，比如银行存取款的金额肯定是确定的，所以OLTP是对确定性的数据进行存取
4.高并发，并且要求满足ACID原则。比如两人同时操作一个银行卡账户，比如大型的购物网站秒杀活动时上万的QPS请求。

联机分析处理OLAP（On-Line Analytical Processing） 是数据仓库系统的主要应用，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。典型的应用就是复杂的动态的报表系统。

OLAP的特点一般有：

1.实时性要求不是很高，比如最常见的应用就是天级更新数据，然后出对应的数据报表。
2.数据量大，因为OLAP支持的是动态查询，所以用户也许要通过将很多数据的统计后才能得到想要知道的信息，例如时间序列分析等等，所以处理的数据量很大;
3.OLAP系统的重点是通过数据提供决策支持，所以查询一般都是动态，自定义的。所以在OLAP中，维度的概念特别重要。一般会将用户所有关心的维度数据，存入对应数据平台。

总结：

OLTP即联机事务处理，就是我们经常说的关系数据库，增删查改就是我们经常应用的东西，这是数据库的基础；TPCC(Transaction Processing Performance Council)属于此类。

OLAP即联机分析处理，是数据仓库的核心部心，所谓数据仓库是对于大量已经由OLTP形成的数据的一种分析型的数据库，用于处理商业智能、决策支持等重要的决策信息；数据仓库是在数据库应用到一定程序之后而对历史数据的加工与分析，读取较多，更新较少，TPCH属于此类。
随着大数据时代的到来，对于OLAP，列存储模式或者说nosql模式比传统意义的行存储模式可能更具优势。

联机事务处理【OLTP Online Transaction Processing】
联机事务处理，表示事务性非常高的系统，一般都是高可用的在线系统，以小的事务以及小的查询为主，以传统的
关系型数据库为主要应用，主要是基本的、日常的事务处理，主要为业务数据，例如银行交易
OLTP系统最容易出现瓶颈的地方就是CPU与磁盘子系统。 OLTP比较常用的设计与优化方式为Cache技术与B‐tree索
引技术.OLTP 系统是一个数据块变化非常频繁，SQL 语句提交非常频繁的系统.

联机分析处理【OLAP Online Analytical Processing】：
联机分析处理，有的时候也叫DSS决策支持系统，就是我们说的数据仓库，重点主要是面向分析，支持复杂的分析操
作，侧重决策支持，并且提供直观易懂的查询结果。典型的应用就是复杂的动态的报表系统。会产生大量的查询，一般
很少涉及增删改。在这样的系统中，语句的执行量不是考核标准，因为一条语句的执行时间可能会非常长，读取的数据
也非常多。所以，在这样的系统中，考核的标准往往是磁盘子系统的吞吐量（带宽），如能达到多少MB/s的流量。
在OLAP系统中，常使用分区技术、并行技术。 分区技术在OLAP系统中的重要性主要体现在数据库管理上，分区技
术对性能上的影响，它可以使得一些大表的扫描变得很快（只扫描单个分区）。另外，如果分区结合并行的话，也可以
使得整个表的扫描会变得很快。总之，分区主要的功能是管理上的方便性，它并不能绝对保证查询性能的提高，有时候
分区会带来性能上的提高，有时候会降低

四、数仓的意义

对于不同行业的数仓意义不一样，但是盈利或者变得更好等都是最终目的。如一个电商行业的数据仓库从各个角度观察其意义如下：
从商户角度，有利于企业新产品开发；有利于企业产品不同时期生产情况调整；有利于企业战略布局。 从电商平台角度，有利于在不同时期推出该时期大部分客户需要的产品；提高产品销售额从而给股东更大收益；有利于节省成本等。 从用户角度，有利于方便快捷的购买到所需产品；有利于提高生活质量等。 从数据角度，可以保存历史数据；可以获取变化数据；同时不仅仅需要以往历史数据而且还需要根据时代发展方向和消费行为转变及时调整，从而在未来发展上取得更大收获。

五、数据仓库的四大特征

数据仓库的数据是面向主题的：

与传统数据库面向应用进行数据组织的特点相对应，数据仓库中的数据是面向主题进行组织的。什么是主题呢？首先，主题是一个抽象的概念，是较高层次上企业信息系统中的数据综合、归类并进行分析利用的抽象。在逻辑意义上，它是对应企业中某一宏观分析领域所涉及的分析对象。面向主题的数据组织方式，就是在较高层次上对分析对象的数据的一个完整、一致的描述，能完整、统一地刻划各个分析对象所涉及的企业的各项数据，以及数据之间的联系。所谓较高层次是相对面向应用的数据组织方式而言的，是指按照主题进行数据组织的方式具有更高的数据抽象级别。

数据仓库的数据是集成的：

数据仓库的数据是从原有的分散的数据库数据抽取来的。操作型数据与DSS分析型数据之间差别甚大。
第一，数据仓库的每一个主题所对应的源数据在原有的各分散数据库中有许多重复和不一致的地方，且来源于不同的联机系统的数据都和不同的应用逻辑捆绑在一起；
第二，数据仓库中的综合数据不能从原有的数据库系统直接得到。因此在数据进入数据仓库之前，必然要经过统一与综合，这一步是数据仓库建设中最关键、最复杂的一步，所要完成的工作有：
（1）要统一源数据中所有矛盾之处，如字段的同名异义、异名同义、单位不统一、字长不一致，等等。
（2）进行数据综合和计算。数据仓库中的数据综合工作可以在从原有数据库抽取 数据时生成，但许多是在数据仓库内部生成的，即进入数据仓库以后进行综合生成的。

数据仓库的数据是非易失的：

数据仓库的数据主要供企业决策分析之用，所涉及的数据操作主要是数据查询，一般情况下并不进行修改操作。数据仓库的数据反映的是一段相当长的时间内历史数据的内容，是不同时点的数据库快照的集合，以及基于这些快照进行统计、综合和重组的导出数据，而不是联机处理的数据。数据库中进行联机处理的数据经过集成输入到数据仓库中，一旦数据仓库存放的数据已经超过数据仓库的数据存储期限，这些数据将从当前的数据仓库中删去。因为数据仓库只进行数据查询操作，所以数据仓库管理系统相比数据库管理系统而言要简单得多。数据库管理系统中许多技术难点，如完整性保护、并发控制等等，在数据仓库的管理中几乎可以省去。但是由于数据仓库的查询数据量往往很大，所以就对数据查询提出了更高的要求，它要求采用各种复杂的索引技术；同时由于数据仓库面向的是商业企业的高层管理者，他们会对数据查询的界面友好性和数据表示提出更高的要求。

数据仓库的数据是随时间不断变化的：

数据仓库中的数据不可更新是针对应用来说的，也就是说，数据仓库的用户进行分析处理时是不进行数据更新操作的。但并不是说，在从数据集成输入数据仓库开始到最终被删除的整个数据生存周期中，所有的数据仓库数据都是永远不变的。数据仓库的数据是随时间的变化而不断变化的，这是数据仓库数据的第四个特征。这一特征表现在以下3方面：
（1）数据仓库随时间变化不断增加新的数据内容。数据仓库系统必须不断捕捉OLTP数据库中变化的数据，追加到数据仓库中去，也就是要不断地生成OLTP数据库的快照，经统一集成后增加到数据仓库中去；但对于确实不再变化的数据库快照，如果捕捉到新的变化数据，则只生成一个新的数据库快照增加进去，而不会对原有的数据库快照进行修改。
（2）数据仓库随时间变化不断删去旧的数据内容。数据仓库的数据也有存储期限，一旦超过了这一期限，过期数据就要被删除。只是数据仓库内的数据时限要远远长于操作型环境中的数据时限。在操作型环境中一般只保存有60 ~ 90天的数据，而在数据仓库中则需要保存较长时限的数据 （如5~10年），以适应DSS进行趋势分析的要求。
（3）数据仓库中包含有大量的综合数据，这些综合数据中很多跟时间有关，如数据经常按照时间段进行综合，或隔一定的时间片进行抽样等等。这些数据要随着时间的变化不断地进行重新综合。因此，数据仓库的数据特征都包含时间项，以标明数据的历史时期。

数据仓库的作用

1. 可以整合公司的所有业务，建立统一的数据中心。
2. 分析用户行为数据，通过数据挖掘来降低投入成本，提高投入效果。
3. 可以作为各个业务的数据源，形成业务数据互相反馈的良性循环。
4. 可以提供数据报表，用于公司的决策等等。

六、数据库与数据仓库的区别

综合以上我们得出结论

1. 数仓工作的绝大部分工作是ETL(业务沟通也较多)。(可以说多大百分之80左右)
2. 大数据类型的数据仓库解决方案之一:hadoop + hive+hue(zeeplin)。
3. 数仓的数据源多和杂。一方面数仓数据来自于业务系统，比如订单系统、用户系统、库存系统等；另一方面数仓数据来源于杂数据的整合，比如整合表、整合库、日志文件、excel文件、csv文件、json文件等。
4. 数仓的数据来源：前端的业务系统(绝大多数)、服务端数据、设备数据、购买的数据源、爬虫的数据源等。
5. 数据的整合是数仓的基础。比如可能每个业务系统都有用户表，但是各个业务系统的信息还不相同，所以需要全部拿过来整合成宽表等。将不同来源或者不同格式的数据整合到一块或者形成一张或多张表，这就是所谓的整合。
6. 数据建模：大实话就是建表，根据业务将来源不同的复杂的数据形成一张或多张表，每一张表都有每一张表的维度或者信息。
7. 数仓工具：kattle(开源etl工具)、Saiku、bdp(www.bdp.cn)等很多。
8. 数据挖掘的基础是数据仓库。
9. 数据仓库核心之一分层(操作层、明细层、整合层、分析层、应用层等)
10. 数仓的常见分层：ods层‐‐‐>dw层‐‐dwd层‐‐dwa层‐‐‐‐>dm层
11. 数仓的构建步骤:分析业务‐‐‐>建模(维度层创建、事实表)‐‐‐>数据收集‐‐>加载数据‐‐‐>数据etl‐‐>查数据‐‐‐>出报表(挖掘等分析应用)支持决策

七、数仓的建设流程

1.业务建模

这部分建模工作，主要包含以下几个部分：
https://baike.baidu.com/item/%E4%B8%9A%E5%8A%A1%E5%BB%BA%E6%A8%A1/6812236?fr=aladdin
业务模型是需求工作流程的一种重要输入，用来了解对系统的需求。
1.划分整个单位的业务，一般按照业务部门的划分，进行各个部分之间业务工作的界定，理清各业务部门之间的关系。
2.深入了解各个业务部门的内具体业务流程并将其程序化。
3.提出修改和改进业务部门工作流程的方法并程序化。
4.数据建模的范围界定，整个数据仓库项目的目标和阶段划分。

• 操作出现的频率，即业务部门每隔多长时间做一次查询分析。
• 在系统中需要保存多久的数据，是一年、两年还是五年、十年。
• 用户查询数据的主要方式，如在时间维度上是按照自然年，还是财政年。
• 用户所能接受的响应时间是多长、是几秒钟，还是几小时。
• 由于双方在理解上的差异，确定问题和了解问题可能是一个需要多次往复的过程，信息部门的人员可能需要做一些
  原型演示给业务部门的人员看，以最终确定系统将要实现的功能确实是业务部门所需要的。

2.选择满足数据仓库系统要求的软件平台

在数据仓库所要解决的问题确定后，第二个步骤就是选择合适的软件平台，包括数据库、建模工具、分析工具等。
这里有许多因素要考虑，如系统对数据量、响应时间、分析功能的要求等，以下是一些公认的选择标准：

• 厂商的背景和支持能力，能否提供全方位的技术支持和咨询服务。
• 数据库对大数据量(TB级)的支持能力。
• 数据库是否支持并行操作。
• 能否提供数据仓库的建模工具，是否支持对元数据的管理。
• 能否提供支持大数据量的数据加载、转换、传输工具(ETL)。
• 能否提供完整的决策支持工具集，满足数据仓库中各类用户的需要。

3.概念建模

这部分建模工作，主要包含以下几个部分：
https://baike.baidu.com/item/%E6%A6%82%E5%BF%B5%E6%A8%A1%E5%9E%8B/3187025?fr=aladdin
1.抽取关键业务概念，并将之抽象化。
2.将业务概念分组，按照业务主线聚合类似的分组概念。
3.细化分组概念，理清分组概念内的业务流程并抽象化，将关键业务流程抽象出实体和实体之间的关系。
4.理清分组概念之间的关联，形成完整的概念模型。

概念建模建模步骤
局部模型
① 确定局部概念模型的范围；
② 定义实体；
③ 定义联系；
④ 确定属性；
⑤ 逐一画出所有的局部ER图，并附以相应的说明文件。
全局模型
建立全局E‐R图的步骤如下：
① 确定公共实体类型；
② 合并局部E‐R图；
③ 消除不一致因素；
④ 优化全局E‐R图；
⑤ 画出全局E‐R图，并附以相应的说明文件。
模型评审
概念模型的评审分两部分进行：
第一部分是用户评审。
第二部分是开发人员评审。

4.逻辑建模

这部分的建模工作，主要包含以下几个部分：
1.业务概念实体化，并考虑其具体的属性。
2.事件实体化，也就是所谓的事实，并考虑其属性内容。
3.说明实体化，也就是所谓的维度，并考虑其属性内容。

步骤：
1、确定建立数据仓库逻辑模型的基本方法。
2、基于主题视图，把主题视图中的数据定义转到逻辑数据模型中。
3、识别主题之间的关系。
4、确定量度
在确定了主题以后，我们将考虑要分析的技术指标，诸如年销售额之类。量度是要统计的指标，必须事先选择恰当，基于不同的量度将直接产生不同的决策结果。
5、确定数据粒度
考虑到量度的聚合程度不同，我们将采用“最小粒度原则”，即将量度的粒度设置到最小。例如如果知道某些数据细分到天就好了，那么设置其粒度到天；但是如果不确定的话，就将粒度设置为最小，即毫秒级别的。对数据操作的效率与能得到数据的详细程度是一对矛盾，通常，人们希望建成的系统既有较高的效率，又能得到所需的详细资料。实施数据仓库的一个重要原则就是不要试图包括所有详细数据，因为90%的分析需求是在汇总数据上进行的。试图将粒度细化到最低层，只会增加系统的开销，降低系统的性能。
6、确定维度
设计各个维度的主键、层次、层级

5.物理建模

这部分的建模工作，主要包含以下几个部分：
1.针对特定物理化平台，做出相应的技术调整。
2.针对模型的性能考虑，对特定平台作出相应的调整。
3.针对管理的需要，结合特定的平台，做出相应的调整。
4.生成最后的执行脚本，并完善之。

说明：
（1）删除非战略性数据：数据仓库模型中不需要包含逻辑数据模型中的全部数据项，某些用于操作处理的数据项要删除。
（2）增加时间主键：数据仓库中的数据一定是时间的快照，因此必须增加时间主键。
（3）增加派生数据：对于用户经常需要分析的数据，或者为了提高性能，可以增加派生数据。
（4）加入不同级别粒度的汇总数据：数据粒度代表数据细化程度，粒度越大，数据的汇总程度越高。粒度是数据仓库设计的一个重要因素，它直接影响到驻留在数据仓库中的数据量和可以执行的查询类型。显然，粒度级别越低，则支持的查询越多；反之，能支持的查询就有限。

数据模型

在说数据模型前，先说说数据存储，数据存储方式有如下几种：

• 虚拟存储方式
• 基于关系表的存储方式

虚拟存储方式：
没有专门的数据仓库数据存储，数据仓库中的 数据仍然在源数据库中。只是根据用户的多维需求及形成的多维视图临时在源数据库中找出 所需要的数据，完成多维分析。
优点：组织方式简单、花费少、使用灵活；
缺点：只有当源数据库的数据组织比较规范、 没有数据不完备及冗余，同时又比较接近多 维数据模型时，虚拟数据仓库的多维语义才 容易定义。而在一般的数据库应用中，这很 难做到。
基于关系表的存储方式：
将数据仓库的数据存储在关系数据库的表结构中，在元数据的管理下完成数据仓库 的能。
实体关系（ER）模型一般用于关系型数据 库设计，而数据仓库采用星型、雪花型、事实星座基于关系表的存储方式。
关系数据库一般采用二维数据表的形式来表示 数据，一个维是行，另一个维是列，行和列的 交叉处就是数据元素。关系数据的基础是关系数据库模型，通过标准的SQL语言来加以实现。
数据仓库是多维数据库，它扩展了关系数据库模型，以星形架构为主要结构方式的，并在它的基础上，扩展出理论雪花形架构和数据星座等方式，但不管是哪一种架构，维度表、事实表和事实表中的量度都是必不可少的组成要素。

星型模型

数据仓库中包含：
(1) 一个大的包含大批数据和不冗余的事实表（中心表）；
(2)一组小的附属表，称为维表。每维一 个。
事实表中每条元组都含有指向各个维表的外键和一些相应的测量数据，事实表的记录数量很多，维表中记录的是有关这一维的属性。
星形模型可以采用关系型数据库结构，模型的核心是事实表，围绕事实表的是维度表。通过事实表将各种不同的维度表连接起来，各个维度表都连接到中央事实表。 维度表中的对象通过事实表与另一维度表中的对象相关联，这样就能建立各个维度表对象之间的联系。
事实表
主要包含了描述特定商业事件的数据，即某些特定商业事件的度量值。
一般情况下，事实表中的数据不允许修改，新的数据只是简单地添加进事实表中。
维度表
主要包含了存储在事实表中数据的特征数据。
每一个维度表利用维度关键字通过事实表中的外键约束于事实表中的某一行，实现与事实表的关联，这就要求事实表中的外键不能为空，这与一般数据库中外键允许为空是不同的。
这种结构使用户能够很容易地从维度表中的数据分析开始，获得维度关键字，以便连接到中心的事实表，进行查询。

星型模型示例：

雪花模型

雪花模型是对星形模型的扩展，每一个维度都可以向外连接多个详细类别表。
在这种模式中，维度表除了具有星形模型中维度表的功能外，还连接对事实表进行详细描述的详细类别表，详细类别表通过对事实表在有关维上的详细描述达到了缩小事实表和提高查询效率的目的。

雪花模型示例：

事实星座模型

一个复杂的商业智能应用往往会在数据仓库中存放多个事实表，这时就会出现多个事实表共享某一个或多个维表的情况，这 就是事实星座，也称为星系模型(galaxy schema)。

事实星座模型示例：

星型模型与雪花模型区别

雪花模式的维表可能是规范化的，以便减少冗余。这种表易于维护，并节省存储空间。
实际上，与巨大的事实表相比，这种空间的节省可以忽略。
由于执行查询需要更多的连接操作，雪花结构可能降低浏览的性能。
在数据仓库设计中，雪花模式不如星型模式流行。

模型应用场景

现目前绝大多数项目中，大部分 Fact 和 Dimension 的关联关系都是星型，极少数采用雪花模型 。至于什么样的模型适用什么场景很难有一个硬性的规则去决定，主要取决于模型的运行效率和研发人员的经验 ，以及当前的趋势，而当前的趋势则是星型模型。

6.数据仓库数据模型优化

数据仓库设计时，性能是一项主要考虑因素。在数据仓库建成后，也需要经常对其性能进行监控，并随着需求和数据量的变更进行调整。

优化数据仓库设计的主要方法是：

• 合并不同的数据表。
• 通过增加汇总表避免数据的动态汇总。
• 通过冗余字段减少表连接的数量，不要超过3~5个。
• 用ID代码而不是描述信息作为键值。
• 对数据表做分区。

7.数据清洗转换和传输（ETL数仓示例2.0文档）

由于业务系统所使用的软硬件平台不同，编码方法不同，业务系统中的数据在加载到数据仓库之前，必须进行数据的清洗和转换，保证数据仓库中数据的一致性。 在设计数据仓库的数据加载方案时，必须考虑以下几项要求：

• 加载方案必须能够支持访问不同的数据库和文件系统。
• 数据的清洗、转换和传输必须满足时间要求，能够在规定的时间范围内完成。
• 支持各种转换方法，各种转换方法可以构成一个工作流。
• 支持增量加载，只把自上一次加载以来变化的数据加载到数据仓库。

8.开发数据仓库的分析应用

建立数据仓库的最终目的是为业务部门提供决策支持能力，必须为业务部门选择合适的工具实现其对数据仓库中的数据进行分析的要求。
信息部门所选择的开发工具必须能够：

• 满足用户的全部分析功能要求。数据仓库中的用户包括了企业中各个业务部门，他们的业务不同，要求的分析功能也不同。如有的用户只是简单的分析报表，有些用户则要求做预测和趋势分析。
• 提供灵活的表现方式。分析的结果必须能够以直观、灵活的方式表现，支持复杂的图表。使用方式上，可以是客户机/服务器方式，也可以是浏览器方式。
  事实上，没有一种工具能够满足数据仓库的全部分析功能需求，一个完整的数据仓库系统的功能可能是由多种工具来实现，因此必须考虑多个工具之间的接口和集成性问题，对于用户来说，希望看到的是一致的界面。

9.数据仓库的管理

只重视数据仓库的建立，而忽视数据仓库的管理必然导致数据仓库项目的失败。数据仓库管理主要包括数据库管理和元数据管理。
数据库管理需要考以下几个方面：

• 安全性管理。

数据仓库中的用户只能访问到他的授权范围内的数据，数据在传输过程中的加密策略。

• 数据仓库的备份和恢复

数据仓库的大小和备份的频率直接影响到备份策略。如何保证数据仓库系统的可用性，硬件还是软件方法。

• 数据老化

设计数据仓库中数据的存放时间周期和对过期数据的老化方法，如历史数据只保存汇总数据，当年数据保存详细记录。

• 元数据管理

元数据管理贯穿于整个系统的建设过程中，元数据是描述数据的数据。

在数据采集阶段，元数据主要包括下列信息：

• 源数据的描述定义：类型、位置、结构。
• 数据转换规则：编码规则、行业标准。
• 目标数据仓库的模型描述：星型/雪花模型定义，维/事实结构定义。
• 源数据到目标数据仓库的映射关系：函数/表达式定义。
• 代码：生成转换程序、自动加载程序等。

在数据管理阶段，元数据主要包括下列信息：

• 汇总数据的描述：汇总/聚合层次、物化视图结构定义。
• 历史数据存储规则：位置、存储粒度。
• 多维数据结构描述：立方体定义、维结构、度量值、钻取层次定义等。

在数据展现阶段，元数据主要包括以下信息：

• 报表的描述：报表结构的定义。
• 统计函数的描述：各类统计分析函数的定义。
• 结果输出的描述：图、表输出的定义。

数据维护与管理分为目标数据维护和元数据维护两方面。目标数据维护是根据元数据库所定义的更新频率、更新数据项等更新计划任务来刷新数据仓库，以反映数据源的变化，且对时间相关性进行处理。更新操作有2种情况，即在仓库的原有数据表中进行某些数据的更新和产生一个新的时间区间的数据，因为汇总数据与数据仓库中的许多信息元素有关系，必需完整地汇总，这样才能保证全体信息的一致性。

• 加载方案必须能够支持访问不同的数据库和文件系统。
• 数据的清洗、转换和传输必须满足时间要求，能够在规定的时间范围内完成。
• 支持各种转换方法，各种转换方法可以构成一个工作流。
• 支持增量加载，只把自上一次加载以来变化的数据加载到数据仓库。
• 源数据的描述定义：类型、位置、结构。
• 数据转换规则：编码规则、行业标准。
• 目标数据仓库的模型描述：星型/雪花模型定义，维/事实结构定义。
• 源数据到目标数据仓库的映射关系：函数/表达式定义。
• 代码：生成转换程序、自动加载程序等。

元数据不但是独立存放，而且对用户是透明的，标准元数据之间可以互相转换数据仓库规模一般都很大，从建立之初就要保证它的可管理性，一个企业可能建立几个数据仓库或数据集市，但他们可共用一个元数据库对其进行管理。首先从元数据库查询所需元数据，然后进行数据仓库更新作业， 更新结束后，将更新情况记录于元数据库中。当数据源的运行环境、结构及目标数据的维护计划发生变化时， 需要修改元数据。元数据是数据仓库的重要组成部分，元数据的质量决定整个数据仓库的质量。
对企业自身来说，数据仓库的建设是一个系统工程，是一个不断建立、发展、完善的过程，通常需要较长的时间。
这就要求各企业对整个系统的建设提出一个全面、清晰的远景规划及技术实施蓝图，将整个项目的实施分成若干个阶段，以“总体规划、分步实施、步步见效”为原则，不仅可迅速从当前投资中获得收益，而且可以在已有的基础上，结合其他已有的业务系统，逐步构建起完整、健壮的数据仓库系统。