数据仓库如何建立

A. 数据仓库与数据挖掘技术—特点及元数据

数据仓库具有以下特点

数据仓库中的数据是面向主题组织的

在较高层次上对分析对象的数据做一个完整的、一致的描述，能有效地刻画出分析对象所涉及的各项数据及数据间的联系。主题通常在一个较高层次上将数据归类的标准，每个主题对应一个宏观分析领域。数据仓库中应重新组织数据，完成业务数据向主题数据的转换。主题的抽取则应根据分析的要求进行确定，根据所需要的信息，分不同类别、不同角度等主题把数据整理之后存储起来

数据仓库的数据是集成的

事务处理系统中的操作型数据在进入数据仓库之前，必须经过统一和综合，演变为分析性数据。需要完成的工作包括：处理字段的同名异义，异义同名，单位不统一，长度不一致等问题，然后对源数据进行综合和计算，生成面向主题分析的高层、综合的数据

数据仓库的数据是稳定的

数据仓库中存放的是供分析决策用的历史数据，而不是联机事务处理的当前数据。涉及的数据操作主要是数据查询，一般不进行数据的增删改操作

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

数据仓库系统需要不断获取联机事务处理系统不同时刻的数据，经集成后追加到数据仓库中

数据仓库中的数据分为四个级别、早期细节级，当前细节级，轻度综合级，高度综合级

首先进入当前细节级，并根据具体需要进一步的综合，从而进入轻度综合级，乃至高度综合级。老化的数据进入早期细节级，数据仓库中存在着不同的综合级别，一般称之为粒度。粒度越大，表示细节程度越低，综合程度越高

元数据是“关于数据的数据”，是新一轮迭代开发和数据仓库维护的主要技术手册。如同数据仓库的导航器，快速高效的定位信息，实现数据检索和挖掘

1、技术元数据

存储关于数据仓库系统技术细节的数据，是用于开发和管理数据仓库使用的数据。它主要包括数据仓库结构的描述、业务系统、数据仓库和数据集市的体系结构及模式以及汇总用的算法和操作环境到数据仓库环境的映射

2、业务元数据

业务元数据从业务角度表述了数据仓库中的数据

数据仓库的建立过程一般有两种方法，“自顶而下”和“自底而上”。

自顶而下：先建立一个企业级数据仓库，然后再在其基础上建立部门级数据集市。

自底向上：优先建立一些数据集市，最后再把它们汇集成一个企业级数据仓库。

B. 请问数据仓库都用什么建立

1、首先你得搞清楚建设数仓的目的是什么

是偏向于整合各系统数据，为数据分析决策服务，还是偏向于快速的完成分析决策需求？

如果是前者，那么在数据仓库建模的时候一般会选择ER建模方法；

如果是后者，一般会选择维度建模方法。

• ER建模：即实体关系建模，由数据仓库之父BIll Inmon提出，核心思想是从全企业的高度去设计三范式模型，用实体关系描述企业服务。主张的是自上而下的架构，将不同的OLTP数据集中到面向主题的数据仓库中。

• 维度建模：由Kimball提出，核心思想是从分析决策的需求出发构建模型。这种模型由事实表和维表组成，即星型模型和雪花模型。Kimball倡导自下而上的架构，可以针对独立部门建立数据集市，再递增的构建，汇总成数据仓库。

2、其次你得进行深入的业务调研和数据调研

• 业务调研：深入的业务调研能使你更加明确数仓建设的目的；同时也利于后续的建模设计，随着调研的开展，如何将实体业务抽象为数仓模型会更加明朗。
  

• 数据调研：各部门或各科室的数据现状了解，包括数据分类、数据存储方式、数据量、具体的数据内容等等。这对后续的主数据串联或者维度一致性处理等等都是必须的基础。

3、然后是数据仓库工具选型

• 传统型数据仓库：一般会选择第三方厂家的数据库和配套ETL工具。因为有第三方支持，相对有保障；但缺点也很明显，受约束以及成本较高。
  

• NoSQL型数据仓库：一般是基于hadoop生态的数据仓库。hadoop生态已经非常强大，可以找到各种开源组件去支持数据仓库。缺点是需要招聘专门人士去摸索，并且相对会存在一些未知隐患。

4、最后是设计与实施

• 设计：包括数据架构中的数据层次划分以及具体的模型设计；也包括程序架构中的数据质量管理、元数据管理、调度管理等；
  

• 实施：规范化的项目管理实施，但同时也需记住一点，数据仓库不是一个项目，它是一个过程。

C. 数据仓库的建立步骤

1)收集和分析业务需求
2)建立数据模型和数据仓库的物理设计
3)定义数据源
4)选择数据仓库技术和平台
5)从操作型数据库中抽取、净化、和转换数据到数据仓库
6)选择访问和报表工具
7)选择数据库连接软件
8)选择数据分析和数据展示软件
9)更新数据仓库 1)数据转换工具要能从各种不同的数据源中读取数据。
2)支持平面文件、索引文件、和legacyDBMS。
3)能以不同类型数据源为输入整合数据。
4)具有规范的数据访问接口
5)最好具有从数据字典中读取数据的能力
6)工具生成的代码必须是在开发环境中可维护的
7)能只抽取满足指定条件的数据，和源数据的指定部分
8)能在抽取中进行数据类型转换和字符集转换
9)能在抽取的过程中计算生成衍生字段
10)能让数据仓库管理系统自动调用以定期进行数据抽取工作，或能将结果生成平面文件
11)必须对软件供应商的生命力和产品支持能力进行仔细评估
主要数据抽取工具供应商：Prismsolutions.Carleton'sPASSPORT.InformationBuildersInc.'s
EDA/SQL.SASInstituteInc. 一般问题 (不完全是技术或文化，但很重要) 包括但不限于以下几点:
业务用户想要执行什么样的分析?
你现在收集的数据需要支持那些分析吗?
数据在哪儿？
数据的清洁度如何？
相似的数据有多个数据源吗？
什么样的结构最适合核心数据仓库 (例如维度或关系型)？
技术问题包括但不限于以下几点:
在你的网络中要流通多少数据？它能处理吗?
需要多少硬盘空间?
硬盘存储需要多快？
你会使用固态还是虚拟化的存储？

D. 构建企业级数据仓库的步骤是什么

现如今，很多企业都开始重视数据仓库的构建，其实构建数据仓库不是一个难事，难的地方在于如何构建企业级的数据仓库，这对于企业来说是一件十分困难又必须提上日程的事情。不过，不要灰心，虽然困难，但是我们也可以通过一些方法去构建企业数据仓库，在这篇文章中我们就给大家介绍一下构建数据仓库的步骤。
构建企业级的数据仓库第一步就是要确定主题，其实确定主题就是确定数据分析或前端展现的主题。主题要体现出某一方面的各分析角度和统计数值型数据之间的关系,确定主题时要综合考虑。这一点是非常重要的，大家一定要重视。
第二个步骤就是确定量度。当我们确定主题后，需要考虑分析的技术指标。一般来说，这些都是数据值型数据，其中有些度量值不可以汇总。有些是可以汇总起来，以便为分析者提供有用的信息。量度是要统计的指标，必须事先选择恰当，基于不同的量度可以进行复杂关键性指标的设计和计算。
第三个步骤就是确定事实数据粒度。当我们确定量度之后，需要考虑该量度的汇总情况和不同维度下量度的聚合情况。如果我们按照“天”为单位来汇总数据的在ETL处理过程中，按天来汇总数据,些时数据仓库中量度的粒度就是“天”。如果不能确认将来的分析需求中是否要精确的秒，那么，我们要遵循”最小粒度原则”,在数据仓库中的事实表中保留每一秒的数据，对数据提前进行汇总，保障产生分析结果的效率。
第四个步骤就是确定维度，其实维度是分析的各个角度。基于不同的维度，可以看到各个量度汇总的情况，也可以基于所有的维度进行交叉分析。
第五个步骤就是创建事实表。在确定好事实数据和维度后，将考虑加载事实表。业务系统的的一笔笔生产，交易记录就是将要建立的事实表的原始数据。具体的做法是将原始表与维度表进行关联，生成事实表。关联时有为空的数据时，需要使用外连接，连接后将各维度的代理键取出放于事实表中，事实表除了各维度代理键外，还有各度量数据，不应该存在描述性信息。
在这篇文章中我们给大家介绍了构建企业级数据仓库的相关步骤，相信大家看了这篇文章以后已经对数据仓库有所了解了吧？大家在构建数据仓库的时候一定要谨遵上面的步骤进行操作，这样才能够提高工作效率，少走弯路，更出色地完成工作任务。

E. 带你深入了解建立数据仓库的八条基本准则[2]

规则三:定义目标和量化收益

在项目开始实施以前 用户必须明确回答几个问题 我们为什么要建立一个数据仓库?项目的目的同我们机构的任务一致吗?哪些问题是我们致力于要去解决的?要考虑及时推入市场 质量和客户满意度等因素吗?

在进行了目标问题的认知以后 应该认清哪些是关键性的影响成功的因素 以便于在解决方案的实施进程中进行跟踪 例如 收益和运输单位(units shipped)可能是对丧失市场份额产生作用的两个影响因素

在确立了这些关键的成功影响因素以后 用户就可以在应用中设置 自动水开标记或警报 这些警报保证对底层产生直接影响的最重要数据是清晰可见的 便于及时采取行动 定义了成功的影响因素后 在使用数据仓库时就可以检测到威胁成功的因素

一旦这些基本目标确立以后 下一个基本要求是对来自数据仓库的可预期的收益进行量化 只有在做了这些工作以后 管理层才会有据可依地判断一个数据仓库的成功与否

量化的目标不一定非是数字或金融表达式 它们只需要明确 有意义即可

许多机构都采用金融衡量标准 比如ROI 来对收益进行量化 IDC对 家数据仓库的实现进行研究表明 在数据仓库项目上的总体ROI为 % 平均回报时间为 ～ 年 数据集市的ROI经检验为 % 其他类型的收益衡量标准还包括成本节约程度以及可获得的能够进行衡量的效率

规则四:取得最高管理层的支持和认可

数据仓库中涉及到信息的共享 这必然会由于部门数据所有者的人为因素造成失控 在数据所有权和数据存放等问题上的内部纷争 很容易给数据仓库带来进程上的滞延和失败

lishixin/Article/program/SQL/201311/16252

F. 教你轻松掌握数据仓库的规划和构建策略

教你轻松掌握数据仓库的规划和构建策略

数据仓库作为决策支持系统（DSS）的基础，具有面向主题的、集成的、不可更新的、随时间不断变化的特性。这些特点说明了数据仓库从数据组织到数据处理，都与原来的数据库有很大的区别，这也就需要在数据仓库系统设计时寻求一个适合于数据仓库设计的方法。在一般的系统开发规划中，首先需要确定系统的功能，这些系统的功能一般是通过对用户的需求分析得到的。从数据仓库的应用角度来看，DSS分析员一般是企业中的中高层管理人员，他们对决策支持的需求不能预先做出规范的说明，只能给设计人员一个抽象地描述。
这就需要设计人员在与用户不断的交流沟通中，将系统的需求逐步明确，并加以完善。因此数据仓库的开发规划过程实际上是一个用户和设计人员对其不断了解、熟悉和完善的过程。 数据仓库的开发应用规划是开发数据仓库的首要任务。只有制定了正确的数据仓库规划，才能使组织主要力量有序地实现数据仓库的开发应用。在数据仓库规划中一般需要经历这样几个过程：选择实现策略、确定数据仓库的开发目标和实现范围、选择数据仓库体系结构、建立商业和项目规划预算。 当数据仓库规划完成后，需要编制相应的数据仓库规划说明书，说明数据仓库与企业战略的关系，以及与企业急需处理的、范围相对有限的开发机会，重点支持的职能部门和今后数据仓库开发工作的建议，实际使用方案和开发预算，作为数据仓库实际开发的依据。
1、选择数据仓库实现策略
数据仓库的开发策略主要有自顶向下、自底向上和这两种策略的联合使用。自顶向下策略在实际应用中比较困难，因为数据仓库的功能是一种决策支持功能。这种功能在企业战略的应用范围中常常是很难确定的，因为数据仓库的应用机会往往超出企业当前的实际业务范围，而且在开发前就确定目标，会在实现预定目标后就不再追求新的应用，是数据仓库丧失更有战略意义的应用。由于该策略在开发前就可以给出数据仓库的实现范围，能够清楚地向决策者和企业描述系统的收益情况和实现目标，因此是一种有效的数据仓库开发策略。该方法使用时需要开发人员具有丰富的自顶向下开发系统的经验，企业决策层和管理人员完全知道数据仓库的预定目标并且了解数据仓库能够在那些决策中发挥作用。
自底向上策略一般从某个数据仓库原型开始，选择一些特定的为企业管理人员所熟知的管理问题作为数据仓库开发的对象，在此基础上进行数据仓库的开发。因此，该策略常常用于一个数据集市、一个经理系统或一个部门的数据仓库开发。该策略的优点在于企业能够以较小的投入，获得较高的数据仓库应用收益。在开发过程中，人员投入较少，也容易获得成效。当然，如果某个项目的开发失败可能造成企业整个数据仓库系统开发的延迟。该策略一般用于企业洗碗对数据仓库的技术进行评价，以确定该技术的应用方式、地点和时间，或希望了解实现和运行数据仓库所需要的各种费用，或在数据仓库的应用目标并不是很明确时，数据仓库对决策过程影响不是很明确时使用。
在自顶向下的开发策略中可以采用结构化或面向对象的方法，按照数据仓库的规划、需求确定、系统分析、系统设计、系统集成、系统测试和系统试运行的阶段完成数据仓库的开发。而在自底向上的开发中，则可以采用螺旋式的原型开发方法，使用户可以根据新的需求对试运行的系统进行修改。螺旋式的原型开发方法要求在较短的时间内快速的生成可以不断增加功能的数据仓库系统，这种开发方法主要适合于这样一些场合：在企业的市场动向和需求无法预测，市场的时机是实现产品的重要组成部分，不断地改进对与企业的市场调节是必需的；持久的竞争优势来自连续不断地改进，系统地改进是基于用户在使用中的不断发现。 自顶向下和自底向上策略的联合使用具有两种策略的优点，既能快速的完成数据仓库的开发与应用，还可建立具有长远价值的数据仓库方案。但在实践中往往难以操作，通常需要能够建立、应用和维护企业模型、数据模型和技术结构的、具有丰富经验的开发人员，能够熟练的从具体（如业务系统中的元数据）转移到抽象（只基于业务性质而不是基于实现系统技术的逻辑模型）；企业需要拥有由最终用户和信息系统人员组成的有经验的开发小组，能够清楚地指出数据仓库在企业战略决策支持中的应用。
2、确定数据仓库的开发目标和实现范围
为确定数据仓库的开发目标和实现范围，首先需要对企业管理者等数据仓库用户解释数据仓库在企业管理中的应用和发展趋势，说明企业组织和使用数据来支持跨功能系统的重要性，对企业经营战略的支持，以确定开发目标。在该阶段确认与使用数据仓库有关的业务要求，这些要求应该只支持最主要的业务职能部门，将使用精力集中在收益明显的业务上，使数据仓库的应用立即产生效果，不应该消耗太多的精力在各个业务上同时铺开数据仓库的应用。
在确定开发目标和范围以后，应该编制需求文档，作为今后开发数据仓库的依据。 数据仓库开发的首要目标是确定所需要信息的范围，确定用户提供决策帮助时，在主题和指标域需要哪些数据源。这就需要定义：用户需要什么数据？面向主题的数据仓库需要什么样的支持数据？为成功地向用户提交数据，开发人员需要哪些商业知识？哪些背景知识？这就需要定义整体需求，以文件的形式整理现存的记录系统和系统环境，对使用数据仓库中数据的候选应用系统进行标识、排序，构造一个传递模型，确定尺度、事实及时间标记算法，以便从系统中抽取信息且将他们放入数据仓库。通过信息范围确定可为开发人员提供一个良好的分析平台，和用户一起分析哪些信息是数据仓库需要的，进行商业活动需要什么数据。开发人员可以和用户进一步定义需要，例如数据分级层次、聚合的层次、加载的频率以及需要保持的时间表等。 数据仓库开发的另一个重要目标是确定利用哪些方法和工具访问和导航数据？虽然用户都需要存取并且检索数据仓库的内容，但是所存取的粒度有所不同，有的可能是详细的记录，有的可能是比较概括的记录或十分概括的记录。用户要求的数据概括程度不同，将导致数据仓库的聚集和概括工具的需求不同。
数据仓库还有具有一定功能来访问和检索图表、预定义的报表、多维数据、概括性数据和详细记录。用户从数据仓库中获得信息，应该有电子表格、统计分析器和支持多维分析的分析处理器等工具的支持，以解释和分析数据仓库中的内容，产生并且验证不同的市场假设、建议和决策方案。为将决策建议和各种决策方案向用户清楚地表达出来，需要利用报表、图表和图像等强有力的信息表达工具。 数据仓库开发的其他目标，是确定数据仓库内部数据的规模。在数据仓库中不仅包含当前数据，而且包含多年的历史数据。数据的概括程度决定了这些数据压缩和概括的最大限度。如果要让数据仓库提供对历史记录进行决策查询的功能，就必须支持对大量数据的管理。数据的规模不仅直接影响决策查询的时间，而且还将直接影响企业决策的质量。
在数据仓库的开发目标中，还有：根据用户对数据仓库的基本需求，确定数据仓库中数据的含义；确定数据仓库内容的质量，以确定使用、分析和建议的可信级别；哪种类型的数据仓库可以满足最终用户的需求，这些数据仓库应该具有怎样的功能；需要哪些元数据，如何使用数据源中的数据等。 数据仓库的开发目标多种多样，十分复杂，需要开发人员和用户在开发与使用的过程中不断交互完善。因此，在规划中需要确定数据仓库的开发范围。使开发人员能够根据需求和目标的重要性逐步进行，并且在开发中吸取经验教训，为数据仓库在企业中的全部实现提供技术准备。因此，在为数据仓库确定总体开发方向和目标以后，就必须确定一个有限的能够很快体现数据仓库效益的使用范围。在考虑数据仓库苦的应用范围时，主要从使用部门的数量和类型、数据源的数量、企业模型的子集、预算分配以及开发项目所需的时间等角度分析。
在分析这些因素时，可从用户的角度和技术的角度两方面进行。 从用户的角度应该分析哪些部门最先使用数据仓库？是哪些人员为了什么目的使用数据仓库？以及数据仓库首先要满足哪些决策查询？因为这些决策查询往往确定了关于数据维数、报表的种类，这些因素都将确定数据仓库定义时所需要的数量关系。查询的格式越具体，越容易提供数据仓库的维数、聚集和概括的规划说明。 从技术角度分析，应该确定数据仓库中元数据库的规模，数据仓库的元数据库是存储数据仓库中数据定义的模型。数据定义存储在仓库管理器的目录中，可以作为所有查询和报表工具构造和查询数据仓库的依据。元数据库的规模直接表示了数据仓库中必须管理的数据规模。通过对元数据库规模的管理，实际上就确定了数据仓库中所需要管理的数据规模。
3、数据仓库的结构选择
数据仓库的结构可以进行灵活的选择，可将组织所使用的各种平台进行恰当的分割，把数据源、数据仓库和最终用户使用的工作站分割开来进行恰当的设计。
（1）数据仓库的应用结构
基于业务处理系统的数据仓库 在这种结构中，将运作的数据用于无需修改数据的只读应用程序中。具有这种结构的数据仓库元数据库是一种虚库，而不是数据仓库自身的元数据。在数据仓库元数据库的直接指导下，对数据仓库的查询就是简单的从数据库中抽取数据。
单纯数据仓库
利用在数据仓库中的数据源净化、集成、概括和集成等操作，将数据源从业务处理系统中传输进集中的数据仓库，各部门的数据仓库应用只在数据仓库中进行。这种结构经常发生在多部门、少用户使用数据仓库的情况下。这里的集中仅仅是逻辑上的，物理上可能是分散的。
单纯数据集市
数据集市是指在部门中使用的数据仓库，因为企业中的各个职能部门都有自己的特殊需要，而统一的数据仓库可能不能满足这些部门的特殊要求。这种体系结构经常发生在个别部门对数据仓库的应用感兴趣，而组织中其他部门却对数据仓库的应用十分冷漠之时，由热心的部门单独开发式所采用。
数据仓库和数据集市
企业各部门拥有满足自己需要的数据集市，其数据从企业数据仓库中获取，而数据仓库从企业各种数据源中收集和分配。这种体系结构是一种较为完善的数据仓库体系结构，往往发生在组织整体对数据仓库应用感兴趣之时所采用的体系结构。
（2）数据仓库的技术平台结构 单层结构
单层结构主要是在数据源和数据仓库之间共享平台，或者让数据源、数据仓库、数据集市与最终用户工作站使用同一个平台。共享一个平台可以降低数据抽取和数据转换的复杂性，但是共享平台在应用中可能遇到性能和管理方面的问题，这种体系结构一般在数据仓库规模较小，而组织的业务系统平台具有较大潜力之时所采用。
客户/服务器两层结构
一层为客户机，一层为服务器，最终用户访问工具在客户层上运行，而数据源、数据仓库和数据集市位于服务器上，该技术机构一般用于普通规模的数据仓库。
三层客户/服务器结构
基于工作站的客户层、基于服务器的中间层和基于主机的第三层。主机层负责管理数据源和可选的源数据转换；服务器运行数据仓库和数据集市软件，并且存储仓库的数据；客户工作站运行查询和报表运用程序，且还可以存储从数据集市或数据仓库卸载的局部数据。在数据仓库稍具规模，两层数据仓库结构已经不能满足客户的需求，要讲数据仓库的数据存储管理、数据仓库的应用处理和客户端应用分开之时，可以采用这种结构。
多层式结构
这是在三层机构基础上发展起来的数据仓库结构，在该结构中从最内数据层到最外层的客户层依次是：单独的数据仓库存储层、对数据仓库和数据集市进行管理的数据仓库服务层、进行数据仓库查询处理的查询服务层、完成数据仓库应用处理的应用服务层和面向最终用户的客户层。体系层次可能多达五层，这种体系结构一般用于超规模数据仓库系统。
4、数据仓库使用方案和项目规划预算
数据仓库的实际使用方案与开发预算，是数据仓库规划中最后需要确定的问题。因为数据仓库主要用于对企业管理人员的决策支持，确保其实用性是十分重要的，因此需要让最终用户参与数据仓库的功能设计。这种参与是通过用户的实际使用方案进行的，使用方案是一个非常重要的需求模型。实际使用方案必须有助于阐明最终用户对数据仓库的要求，这些要求有的只使用适当的数据源就可以得到基本满足，而有的却需要来自企业外部的数据源，这就需要通过使用方案将这些不同的要求联系起来。 实际使用方案还可以将最终用户的决策支持要求与数据仓库的技术要求联系起来。因为当用户确定最终要求后，为元数据库的范围确定一个界限。还可以确定所需要的历史信息的数量，当根据特定的用户进行数据仓库的规划时，就可确定最终用户所关心的维度（时间、方位、商业单位和生产企业），因为维度与所需要的概括操作有明显的关系，必须选择对最终用户有实际意义的维度，如：“月”、“季度”、“年”等。最后，还可以确定数据集市/数据仓库的结构需要，使设计人员确定采用单纯数据仓库结构，还是单纯的数据集市结构或者是两者相结合的结构。
在实际使用开发方案确定后，还需要对开发方案的预算进行估计，确定项目的投资数额。投资方案的确定可以依据以往的软件开发成本，但是这种预算的评估比较粗糙。另一种方法是参照结构进行成本评估，也就是说，将数据仓库实际使用方案所确定的构件进行分解，根据各个构件的成本进行预算估算。数据仓库的构件包含在数据源、数据仓库、数据集市、最终用户存取、数据管理、元数据管理、传输基础等部分中，这些构件有的在企业原有信息系统中已经具备，有的可以选择商品化构件，有的则需要自我开发。根据这些构件的不同来源，可以确定比较准确的预算。 在完成数据仓库规划后，就需要编制数据仓库开发说明书，说明系统与企业战略目标的关系，以及系统与企业急需处理的范围相对有限的开发机会，所设想的业务机会的说明以及目标任务概况说明、重点支持的职能部门和今后工作的建议。数据仓库项目应有明确的业务价值计划开始，在计划中需要阐明期望取得的有形和无形的利益。无形利益包含利用数据仓库使决策完成得更快更好等利益。
业务价值计划最好由目标业务主管来完成，因为数据仓库是用户驱动的，应该让用户积极参与数据仓库的建设，在规划书中要确定数据仓库开发目标的实现范围、体系结构和使用方案及开发预算。

G. 数仓建模分层理论

这篇文章较为完整、清晰的讲述了数仓建模分层理论，要点如下：

1、分层的意义：清晰结构体系、数据血缘跟踪、减少重复开发、复杂问题简单化及统一数据口径

2、ODS：用作缓冲，可以存一周左右，跟DWD大多重复，留存的目的还在于保持跟源端一致，方便追溯

3、DWD：针对ODS做数据的清洗和整合，在DWD层会根据维度模型，设计事实表和维度表，DWD层是一个非常规范的、高质量的、可信的数据明细层

4、DWS：基于DWD层形成某一主题的轻度汇总表或分析宽表，DWS形成大量维度退化的事实表以提高易用性，DWS层应覆盖80%的应用场景

5、TDM：标签层，通过统一的ID-Mapping 把各个业务板块，各个业务过程中同一对象的数据打通，形成对象的全域数据标签体系，方便深度分析、挖掘、应用，大家注意，这个ID不仅仅指客户或用户ID，也包括其它的主数据ID，其是全流程分析的基础

6、ADS：数据应用层ApplicationDataService面向业务定制的应用数据，主要提供给数据产品和数据分析使用的数据，一般会放在ES，MYSQL，Redis等前端系统供线上系统使用，也可以放在Hive中供数据分析和数据挖掘使用

7、DM：主要是提供数据产品和数据分析的数据，主要解决部门用户报表和分析需求而建立数据库，数据集市就代表数据仓库的主题域。DM 是面向单个主题的，所以它不会从全局考虑进行建设。

强烈推荐阅读！

正文开始

简单点儿，直接ODS+DM就可以了，将所有数据同步过来，然后直接开发些应用层的报表，这是最简单的了；当DM层的内容多了以后，想要重用，就会再拆分一个公共层出来，变成3层架构,这个过程有点类似代码重构，就是在实践中不断的进行抽象、总结。

数仓的建模或者分层，其实都是为了更好的去组织、管理、维护数据,所以当你站在更高的维度去看的话，所有的划分都是为了更好的管理。小到JVM 内存区域的划分，JVM 中堆空间的划分(年轻代、老年代、方法区等)，大到国家的省市区的划分，无一例外的都是为了更好的组织管理 。

所以数仓分层是数据仓库设计中十分重要的一个环节， 优秀的分层设计能够让整个数据体系更容易理解和使用 。

这一节，我们主要是从整体上出发进行分析和介绍，就和上一节数仓建模方法论一样，进度对比分析，更多细节的东西我们后面会单独拆分出来，用案例进行演示，例如维度建模，维度表的设计，事实表的设计、以及如何设计标签、如何管理标签等等。

每一个数据分层都有它的作用域，这样在使用表的时候能更方便的定位和理解。

由于最终给业务呈现的是一个能直接使用的业务表，但是表的数据来源有很多，如果有一张来源表出问题了，我们希望能够 快速准确的定位到问题，并清楚它的影响范围，从而及时给到业务方反馈，从而将损失降到最低 。

将一个复杂的任务分解成多个步骤来完成，每一层只处理单一的步骤，比较简单和容易理解。而且便于维护数据的准确性，当数据出现问题之后，可以不用修复所有的数据，只需要从有问题的步骤开始修复。

过数据分层提供统一的数据出口，统一对外输出的数据口径，这往往就是我们说的数据应用层。

前面我们说到分层其实是为了更好更快更准的组织管理，但是这个是从宏观上来说的，接下来我们从微观上也来看一下分层。

越靠上的层次，对应用越友好,比如ADS层，基本是完全为应用设计,从数据聚合程度来讲，越上层的聚合程度越高，当然聚合程度越高可理解程度就越低。

数仓层内部的划分不是为了分层而分层， 分层是为了解决 ETL 任务及工作流的组织、数据的流向、读写权限的控制、不同需求的满足等各类问题 ，当然我们常说的分层也是面向行业而言的，也是我们常用分层方法，但是你需要注意的是分层仅仅是手段而已。

ODS 全称是 OperationalDataStore， 操作数据层存储的是面向业务系统的数据 ，也是最接近数据源中数据的一层，数据源中的数据，经过抽取、洗净、传输，也就说传说中的 ETL 之后，装入本层。

本层的数据，总体上大多是 按照源头业务系统的分类方式而分类的 ，前面我们说到为什么在数仓主要用维度建模的情况下，我们依然要学习范式建模呢，因为我们的数据源是范式建模的，所以学习范式建模可以帮助我们更好的理解业务系统，理解业务数据，所以你可以认为我们的ODS 层其实就是用的实范式建模。

这里的数据处理，并不涉及业务逻辑，仅仅是针对数据完整性以及重复值和空值的处理，其实就是做的是数据规约，数据清洗，但是为了考虑后续可能追溯数据源问题，因此 对这一层不建议做过多的数据清洗工作 ，原封不动接入源数据即可，至于数据的去噪，去重，异常值处理等过程可以放在后面的DW层

表名的设计 ODS_业务系统_表名_标记 ，这样的设计可以保持与业务表名一致，又可以有清晰的层次，还可以区分来源。标记一般指的是其他数仓特有的属性，例如表是天级的还是小时的，是全量的还是增量的。

ods 的设计可以保证所有的数据按照统一的规范进行存储。

DW是数据仓库的核心，从ODS层中获得的数据按照主题建立各种数据模型。DW又细分数据明细层DWD 和轻度汇总层DWS

这一层和维度建模会有比较深的联系，业务数据是按照 业务流程方便操作的角度 来组织数据的，而统一数仓层是 按照业务易理解的角度或者是业务分析的角度 进行数据组织的，定义了一致的指标、维度，各业务板块、数据域都是按照统一的规范来建设，从而形成统一规范的 标准业务数据体系 ，它们通常都是基于Kimball的维度建模理论来构建的， 并通过一致性维度和数据总线来保证各个子主题的维度一致性 。

公共层的维度表中相同维度属性在不同物理表中的字段名称、数据类型、数据内容必须保持一致，因为这样可以降低我们在使用过程中犯错误的概率，例如使用了不正确的字段，或者因为数据类型的原因导致了一些奇怪的错误

将维度所描述业务相关性强的字段在一个物理维表实现。相关性强是指经常需要一起查询或进行报表展现、两个维度属性间是否存在天然的关系等。例如，商品基本属性和所属品牌。

公告明细数据层，可以说是我们数仓建设的核心了。

DWD层要做的就是将 数据清理、整合、规范化、脏数据、垃圾数据、规范不一致的、状态定义不一致的、命名不规范的数据都会被处理 。然后加工成面向数仓的基础明细表，这个时候可以加工一些面向分析的大宽表。

DWD层应该是覆盖所有系统的、完整的、干净的、具有一致性的数据层。在DWD层会根据维度模型，设计事实表和维度表，也就是说DWD层是一个非常规范的、高质量的、可信的数据明细层。

DWS层为 公共汇总层 ，这一层会进行轻度汇总，粒度比明细数据稍粗， 基于DWD层上的基础数据，整合汇总成分析某一个主题域的服务数据 ，一般是也是面向分析宽表或者是面向某个注意的汇总表。DWS层应覆盖80%的应用场景，这样我们才能快速响应数据需求，否则的话，如果很多需求都要从ods开始做的话，那说明我们的数仓建设是不完善的。

例如按照业务划分，例如流量，订单，用户等，生成字段比较多的宽表，用于后续的业务查询，OLAP分析，数据分析等。

一般采用维度模型方法作为理论基础，更多的采用一些维度退化手法，将维度退化至事实表中，减少维度表与事实表的关联，提高明细数据表的易用性；同时在汇总数据层要加强指标的维度退化，采用更多的宽表化手段构建公共指标数据层，提升公共指标的复用性，减少重复加工 。

维表层，所以其实维度层就是大量维表构成的，为了统一管理这些维度表，所以我们就建设维度层，维度表本身也有很多类型，例如稳定维度维表，渐变维度维表。

维度指的是观察事物的角度，提供某一业务过程事件涉及用什么过滤和分类的描述属性 ，"谁、什么时候、什么地点、为什么、如何"干了什么，维度表示维度建模的基础和灵魂。

所以可以看出，维度表包含了业务过程记录的业务过程度量的上下文和环境。维度表都包含单一的主键列， 维度表设计的核心是确定维度字段，维度字段是查询约束条件(where)、分组条件(group)、排序(order)，与报表标签的基本来源 。

维度表一般为 单一主键 ，在ER模型中，实体为客观存在的事务，会带有自己的描述性属性，属性一般为文本性、描述性的，这些描述被称为维度。维度建模的核心是 数据可以抽象为事实和维度 ，维度即观察事物的角度，事实某一粒度下的度量词， 维度一定是针对实体而言的 。

每个维度表都 包含单一的主键列 。维度表的主键可以作为与之关联的任何事实表的外键，当然，维度表行的描述环境应与事实表行完全对应。维度表通常比较宽，是扁平型非规范表，包含大量的低粒度的文本属性。例如customer（客户表）、goods(商品表)、d_time(时间表)这些都属于维度表，这些表都有一个唯一的主键，然后在表中存放了详细的数据信息。

维度表通常比较宽 ，包含多个属性、是扁平的规范表 ，实际应用中包含几十个或者上百个属性的维度并不少见，所以 维度表应该包括一些有意义的描述，方便下游使用 。

维度表的维度属性，应该尽可能的丰富，所以维度表中，经常出现一些反范式的设计，把其他维度属性并到主维度属性中， 达到易用少关联的效果。

维度表的设计包括维度选择，主维表的确定，梳理关联维度，定义维度属性的过程。

维度的选择一般从报表需求和从业务人员的交谈中发现，主要用于过滤、分组、排序，主维度表一般从业务库直接同步，比如用户表，但是数仓的本身也会有自己的维度，这是因为数仓是面向分析的，所以会有很多从分析的角度出发的维度。

关联维度主要是不同业务系统或者同一业务系统的表之间存在关联性(范式建模)，根据对业务表的梳理，确定哪些表和主维度表之间存在关联关系，并选择其中的某些表用于生成维度属性。

随着互联网的普及，获客成本越来越高，这也使得公司对用户运营提出了更高的要求，不仅需要精细化更需要个性化。解决这一问题的办法之一就是建立相对完备的标签系统，而数仓的标签层对于标签系统而言就像数据仓库对于数据系统一样，有着举足轻重的地位，这样的标签系统需要与业务进行紧密结合， 从业务中获取养分—用户标签，同时也要服务于业务—给用户提供更加精准和个性的服务 。

底层的标签系统就像一个索引，层层展示大千世界，而用户就从这大千世界中不断选择一些东西表明自己的身份和喜好，也不断反哺，使得这个大千世界更加丰富多彩。 其实到最后用户就是一些标签的集合。

对跨业务板块、跨数据域的特定对象进行数据整合，通过统一的ID-Mapping 把各个业务板块，各个业务过程中 同一对象的数据打通 ，形成对象的全域数据标签体系，方便深度分析、挖掘、应用。ID-Mapping 可以认为是通过对象的标识对不同数据体系下相同对象进行关联和识别。对象的标识可以标识一个对象，一般是对象的ID,比如手机号，身份证，登录账号

完成对象的ID 打通需要给对象设置一个超级ID,需要根据对象当前业务体系的ID和获取得到或者计算得到超级ID,进而完成所有业务标识的ID打通一般来说ID打通是建设标签体系的前提，如果没有ID打通就无法收集到一个对象的全面信息，也就无法对这个对象进行全面的标签刻画。

传统的计算方法要有 ID-ID之间的两两关系，例如邮箱和手机号可以打通，手机号和身份证号可以打通，那么邮箱就和身份证号可以打通，但是当数据量非常大，且业务板块非常多的时候，例如有上一个对象，每个对象有数十种ID,这个时候打通就需要非常漫长的计算

那么什么是标签呢，利用原始数据，通过一定的逻辑加工产出直接能被业务所直接使用的、可阅读的，有价值的数据。标签类目，是标签的分类组织方式，是标签信息的一种结构化描述，目的是管理、查找，一般采用多级类目，一般当一个对象的标签个数超过50个的时候，业务人员查找标签就会变得非常麻烦，这个时候我们往往会通过标签类目进行组织管理

标签按照产生和计算方式的不同可分为属性标签，统计标签，算法标签，关联标签。

对象本身的性质就是属性标签，例如用户画像的时候打到用户身上的标签。

对象在业务过程中产生的原子指标，通过不同的计算方法可以生成统计标签。

对象在多个业务过程中的特征规律通过一定的算法产出的标签。

对象在特定的业务过程会和其他对象关联，关联对象的标签也可以打在主对象上。

我们的标签一定是针对用户的，而不是一些虚假、高大上、无用的标签，一定要真实反映用户行为喜好的，所以我们不能只依赖人工智能算法的分析，来完成对一个用户标签的建立与定期维护，我们需要走出去和用户交互，引导用户使用，要抓住用户痛点，及时获取用户反馈，形成闭环。

如何引导使用呢？这个方式有很多我们就不再这里介绍了，后面我们会专门介绍这一层的建设细节。

数据应用层ApplicationDataService面向业务定制的应用数据，主要提供给数据产品和数据分析使用的数据，一般会放在ES，MYSQL，Redis等系统供线上系统使用，也可以放在Hive中供数据分析和数据挖掘使用，或者使用一下其他的大数据工具进行存储和使用。

数仓层，DIM 层，TDM 层是相对稳定的，所以无法满足灵活多变业务需求 ，所以这和数仓层的规范和划分相矛盾，所以我们在此基础上建立了另外一个层，这就是ADS 层，解决了规划稳定和灵活多变之间的矛盾。其实到这里你也就慢慢的看明白了，分层和分类其实没多大差别，其实就是相似的放在一起，有点代码重构的意味啊。

数据应用层，按照业务的需要，然后从统一数仓层和DIM进行取数，并面向业务的特殊需求对数据进行加工,以满足业务和性能的需求。ADS 层因为面向的实众多的需求，所以这一层没有太多的规范，只需要按照命名规范来进行就可以了。

前面也说了，ADS 层因为面向的实众多的需求，所以这一层没有太多的规范，但是ADS 层的建设是强业务推动的，业务部门需要参与到ADS 的建设中来，至少我们得了解用户的痛点才能对症施药啊。

理清需求，了解业务方对数据内容、使用方式(怎么交互的，报表、接口、即席查询、在线查询、指标查询、搜索)、性能的要求。

盘点现有的数仓表是否可以支持，看以前有没有类似的需求，有没有可以复用的接口、报表什么的。

代码实现，选择合适的存储引擎和查询引擎，配置线上监控然后交付。

主要是提供数据产品和数据分析的数据，一般会存放在ES、Mysql、也可能直接存储在hive中或者druid供数据分析和数据挖掘使用。主要 解决部门用户报表和分析需求 而建立数据库，数据集市就代表数据仓库的主题域。

DM 是面向单个主题的，所以它不会从全局考虑进行建设，只专注于自己的数据、往往是某个业务线，例如流量主题、社交主题、电商主题等等。

H. 万字详解ETL和数仓建模

ETL是数据抽取（Extract）、转换（Transform）、加载（Load ）的简写，它是将OLTP系统中的数据经过抽取，并将不同数据源的数据进行转换、整合，得出一致性的数据，然后加载到数据仓库中。简而言之ETL是完成从 OLTP系统到OLAP系统的过程

数据仓库（Data Warehouse DW）是基于OLTP系统的数据源，为了便于多维分析和 多角度展现将其数据按特定的模式进行存储而建立的关系型数据库，它不同于多维数据库，数据仓库中的数据是细节的，集成的，数据仓库是面向主题的，是以 OLAP系统为分析目的。它包括星型架构与雪花型架构，其中星型架构中间为事实表，四周为维度表， 类似星星；雪花型架构中间为事实表，两边的维度表可以再有其关联子表，而在星型中只允许一张表作为维度表与事实表关联，雪花型一维度可以有多张表，而星型 不可以。考虑到效率时，星型聚合快，效率高，不过雪花型结构明确，便于与OLTP系统交互。在实际项目中，我们将综合运用星型架构与雪花型架构。

即 确定数据分析或前端展现的某一方面的分析主题，例如我们分析某年某月某一地区的啤酒销售情况，就是一个主题。主题要体现某一方面的各分析角度（维度）和统 计数值型数据（量度），确定主题时要综合考虑，一个主题在数据仓库中即为一个数据集市，数据集市体现了某一方面的信息，多个数据集市构成了数据仓库。

在 确定了主题以后，我们将考虑要分析的技术指标，诸如年销售额此类，一般为数值型数据，或者将该数据汇总，或者将该数据取次数，独立次数或取最大最小值 等，这样的数据称之为量度。量度是要统计的指标，必须事先选择恰当，基于不同的量度可以进行复杂关键性能指标（KPI）等的计算。

在 确定了量度之后我们要考虑到该量度的汇总情况和不同维度下量度的聚合情况，考虑到量度的聚合程度不同，我们将采用“最小粒度原则”，即将量度的粒度设置 到最小，例如我们将按照时间对销售额进行汇总，目前的数据最小记录到天，即数据库中记录了每天的交易额，那么我们不能在ETL时将数据进行按月或年汇总， 需要保持到天，以便于后续对天进行分析。而且我们不必担心数据量和数据没有提前汇总带来的问题，因为在后续的建立CUBE时已经将数据提前汇总了。

维 度是要分析的各个角度，例如我们希望按照时间，或者按照地区，或者按照产品进行分析，那么这里的时间、地区、产品就是相应的维度，基于不同的维度我们可 以看到各量度的汇总情况，我们可以基于所有的维度进行交叉分析。这里我们首先要确定维度的层次（Hierarchy）和级别（Level）（图 四：pic4.jpg），维度的层次是指该维度的所有级别，包括各级别的属性；维度的级别是指该维度下的成员，例如当建立地区维度时我们将地区维度作为一 个级别，层次为省、市、县三层，考虑到维度表要包含尽量多的信息，所以建立维度时要符合“矮胖原则”，即维度表要尽量宽，尽量包含所有的描述性信息，而不 是统计性的数据信息。

还有一种常见的情况，就是父子型维度，该维度一般用于非叶子节点含有成员等情况，例如公司员工 的维度，在统计员工的工资时，部 门主管的工资不能等于下属成员工资的简单相加，必须对该主管的工资单独统计，然后该主管部门的工资等于下属员工工资加部门主管的工资，那么在建立员工维度 时，我们需要将员工维度建立成父子型维度，这样在统计时，主管的工资会自动加上，避免了都是叶子节点才有数据的情况。

另外，在建立维度表时要充 分使用代理键，代理键是数值型的ID号码，好处是代理键唯一标识了每一维度成员信息，便于区分，更重要的是在聚合时由于数值型匹 配，JOIN效率高，便于聚合，而且代理键对缓慢变化维度有更重要的意义，它起到了标识 历史 数据与新数据的作用，在原数据主键相同的情况下，代理键起到了 对新数据与 历史 数据非常重要的标识作用。

有时我们也会遇到维度缓慢变化的情况，比如增加了新的产品，或者产品的ID号码修改了，或者产品增加了一个新的属性，此时某一维度的成员会随着新的数据的加入而增加新的维度成员，这样我们要考虑到缓慢变化维度的处理，对于缓慢变化维度，有三种情况：

在确定好事实数据和维度后，我们将考虑加载事实表。

在公司的大量数据堆积如山时，我们想看看里面究竟是什么，结果发现里面是一笔笔生产记录，一笔笔交易记录… 那么这些记录是我们将要建立的事实表的原始数据，即关于某一主题的事实记录表。

我 们的做法是将原始表与维度表进行关联，生成事实表（图六：pic6.jpg）。注意在关联时有为空的数据时（数据源脏），需要使用外连接，连接后我们将 各维度的代理键取出放于事实表中，事实表除了各维度代理键外，还有各量度数据，这将来自原始表，事实表中将存在维度代理键和各量度，而不应该存在描述性信 息，即符合“瘦高原则”，即要求事实表数据条数尽量多（粒度最小），而描述性信息尽量少。

如果考虑到扩展，可以将事实表加一唯一标识列，以为了以后扩展将该事实作为雪花型维度，不过不需要时一般建议不用这样做。

事 实数据表是数据仓库的核心，需要精心维护，在JOIN后将得到事实数据表，一般记录条数都比较大，我们需要为其设置复合主键和索引，以为了数据的完整性和 基于数据仓库的查询性能优化，事实数据表与维度表一起放于数据仓库中，如果前端需要连接数据仓库进行查询，我们还需要建立一些相关的中间汇总表或物化视图，以方便查询。

在构建数据仓库时，如果数据源位于一服务器上，数据仓库在另一 服务器端，考虑到数据源Server端访问频繁，并且数据量大，需要不断更新，所以可以建立准备区数据库（图七：pic7.jpg）。先将数据抽取到准备 区中，然后基于准备区中的数据进行处理，这样处理的好处是防止了在原OLTP系统中中频繁访问，进行数据运算或排序等操作。例如我们可以按照天将数据抽取 到准备区中，基于数据准备区，我们将进行数据的转换，整合，将不同数据源的数据进行一致性处理。数据准备区中将存在原始抽取表，一些转换中间表和临时表以 及ETL日志表等。

时间维度对于某一事实主题来说十分重要，因为不同的时间有不同的统计数据信息，那么按照时间记录 的信息将发挥很重要的作用。在ETL中，时间戳有其特殊的 作用，在上面提到的缓慢变化维度中，我们可以使用时间戳标识维度成员；在记录数据库和数据仓库的操作时，我们也将使用时间戳标识信息，例如在进行数据抽取 时，我们将按照时间戳对OLTP系统中的数据进行抽取，比如在午夜0：00取前一天的数据，我们将按照OLTP系统中的时间戳取GETDATE到 GETDATE减一天，这样得到前一天数据。

在对数据进行处理时，难免会发生数据处理错误，产生出错信息，那么我们 如何获得出错信息并及时修正呢? 方法是我们使用一张或多张Log日志表，将出错信息记录下来，在日志表中我们将记录每次抽取的条数，处理成功的条数，处理失败的条数，处理失败的数据，处 理时间等等，这样当数据发生错误时，我们很容易发现问题所在，然后对出错的数据进行修正或重新处理。

在对数据仓库进行 增量更新时必须使用调度（图八：pic8.jpg），即对事实数据表进行增量更新处理，在使用调度前要考虑到事实数据量，需要多长时间更 新一次，比如希望按天进行查看，那么我们最好按天进行抽取，如果数据量不大，可以按照月或半年对数据进行更新，如果有缓慢变化维度情况，调度时需要考虑到 维度表更新情况，在更新事实数据表之前要先更新维度表。

调度是数据仓库的关键环节，要考虑缜密，在ETL的流程搭建好后，要定期对其运行，所以 调度是执行ETL流程的关键步骤，每一次调度除了写入Log日志表 的数据处理信息外，还要使用发送Email或报警信息等，这样也方便的技术人员对ETL流程的把握，增强了安全性和数据处理的准确性。

ETL构建数据仓库需要简单的五步，掌握了这五步的方法我们将构建一个强大的数据仓库，不过每一步都有很深的需要研究与挖掘，尤其在实际项目中，我们要综合考虑，例如如果数据源的脏数据很多，在搭建数据仓库之前我们首先要进行数据清洗，以剔除掉不需要的信息和脏数据。

总之，ETL是数据仓库的核心，掌握了ETL构建数据仓库的五步法，就掌握了搭建数据仓库的根本方法。不过，我们不能教条，基于不同的项目，我们还将要进行 具体分析，如父子型维度和缓慢变化维度的运用等。在数据仓库构建中，ETL关系到整个项目的数据质量，所以马虎不得，必须将其摆到重要位置，将ETL这一 大厦根基筑牢。

如果ETL和SQL来说，肯定是SQL效率高的多。但是双方各有优势，先说ETL，ETL主要面向的是建立数据仓库来使用的。ETL更偏向数据清洗，多数据源数据整合，获取增量，转换加载到数据仓库所使用的工具。比如我有两个数据源，一个是数据库的表，另外一个是excel数据，而我需要合并这两个数据，通常这种东西在SQL语句中比较难实现。但是ETL却有很多现成的组件和驱动，几个组件就搞定了。还有比如跨服务器，并且服务器之间不能建立连接的数据源，比如我们公司系统分为一期和二期，存放的数据库是不同的，数据结构也不相同，数据库之间也不能建立连接，这种情况下，ETL就显得尤为重要和突出。通过固定的抽取，转换，加载到数据仓库中，即可很容易实现。

那么SQL呢？SQL事实上只是固定的脚本语言，但是执行效率高，速度快。不过灵活性不高，很难跨服务器整合数据。所以SQL更适合在固定数据库中执行大范围的查询和数据更改，由于脚本语言可以随便编写，所以在固定数据库中能够实现的功能就相当强大，不像ETL中功能只能受组件限制，组件有什么功能，才能实现什么功能。

所以具体我们在什么时候使用ETL和SQL就很明显了，当我们需要多数据源整合建立数据仓库，并进行数据分析的时候，我们使用ETL。如果是固定单一数据库的数据层次处理，我们就使用SQL。当然，ETL也是离不开SQL的。

主要有三大主流工具，分别是Ascential公司的Datastage、Informatica公司的Powercenter、NCR Teradata公司的ETL Automation.还有其他开源工具，如PDI(Kettle)等。

DW系统以事实发生数据为基础，自产数据较少。

一个企业往往包含多个业务系统，均可能成为DW数据源。

业务系统数据质量良莠不齐，必须学会去伪存真。

业务系统数据纷繁复杂，要整合进数据模型。

源数据之间关系也纷繁复杂，源数据在加工进DW系统时，有些必须遵照一定的先后次序关系;

流水事件表：此类源表用于记录交易等动作的发生，在源系统中会新增、大部分不会修改和删除，少量表存在删除情况。如定期存款登记簿;

常规状态表：此类源表用于记录数据信息的状态。在源系统中会新增、修改，也存在删除的情况。如客户信息表;

代码参数表：此类源表用于记录源系统中使用到的数据代码和参数;

数据文件大多数以1天为固定的周期从源系统加载到数据仓库。数据文件包含增量，全量以及待删除的增量。

增量数据文件：数据文件的内容为数据表的增量信息，包含表内新增及修改的记录。

全量数据文件：数据文件的内容为数据表的全量信息，包含表内的所有数据。

带删除的增量：数据文件的内容为数据表的增量信息，包含表内新增、修改及删除的记录，通常删除的记录以字段DEL_IND='D'标识该记录。

可划分为： 历史 拉链算法、追加算法(事件表)、Upsert算法(主表)及全删全加算法(参数表);

历史 拉链：根据业务分析要求，对数据变化都要记录，需要基于日期的连续 历史 轨迹;

追加(事件表)：根据业务分析要求，对数据变化都要记录，不需要基于日期的连续 历史 轨迹;

Upsert(主表)：根据业务分析要求，对数据变化不需要都要记录，当前数据对 历史 数据有影响;

全删全加算法(参数表)：根据业务分析要求，对数据变化不需要都要记录，当前数据对 历史 数据无影响;

所谓拉链，就是记录 历史 ，记录一个事务从开始，一直到当前状态的所有变化信息(参数新增开始结束日期);

一般用于事件表，事件之间相对独立，不存在对 历史 信息进行更新;

是update和insert组合体，一般用于对 历史 信息变化不需要进行跟踪保留、只需其最新状态且数据量有一定规模的表，如客户资料表;

一般用于数据量不大的参数表，把 历史 数据全部删除，然后重新全量加载;

历史 拉链，Upsert,Append,全删全加;加载性能：全删全加，Append，Upsert， 历史 拉链;

APPEND算法，常规拉链算法，全量带删除拉链算法;

APPEND算法，MERGE算法，常规拉链算法，基于增量数据的删除拉链算法，基于全量数据的删除拉链算法，经济型常规拉链算法，经济型基于增量数据的删除拉链算法，经济型基于全量数据的删除拉链算法，PK_NOT_IN_APPEND算法，源日期字段自拉链算法;

此算法通常用于流水事件表，适合这类算法的源表在源系统中不会更新和删除，而只会发生一笔添加一笔，所以只需每天将交易日期为当日最新数据取过来直接附加到目标表即可，此类表在近源模型层的字段与技术缓冲层、源系统表基本上完全一致，不会额外增加物理化处理字段，使用时也与源系统表的查询方式相同;

此算法通常用于无删除操作的常规状态表，适合这类算法的源表在源系统中会新增、修改，但不删除，所以需每天获取当日末最新数据(增量或全增量均可)，先找出真正的增量数据(新增和修改)，用它们将目标表中属性发生修改的开链数据(有效数据)进行关链操作(即END_DT关闭到当前业务日期)，然后再将最新的增量数据作为开链数据插入到目标表即可。

此类表再近源模型层比技术缓冲层、源系统的相应表额外增加两个物理化处理字段START_DT(开始日期)和END_DT(结束日期)，使用时需要先选定视觉日期，通过START_DT和END_DT去卡视觉日期，即START_DT'视觉日期';

此算法通常用于有删除操作的常规状态类表，并且要求全量的数据文件，用以对比出删除增量;适合这类算法的源表在源系统中会新增，修改，删除，每天将当日末最新全量数据取过来外，分别找出真正的增量数据(新增，修改)和删除增量数据，用它们将目标表中属性发生修改的开链数据(有效数据)进行关链操作(即END_DT关闭到当前业务日期)，然后再将最新增量数据中真正的增量及删除数据作为开链数据插入到目标表即可，注意删除记录的删除标志DEL_IND会设置为‘D’;

此类表在近源模型层比技术缓冲层，源系统的相应表额外增加三个物理化处理字段START_DT(开始日期)，ENT_DT(结束日期)，DEL_IND(删除标准)。使用方式分两类：一时一般查询使用，此时需要先选定视角日期，通过START_DT和END_DT去卡视角日期，即START_DT‘视角日期’，同时加上条件DEL_IND 'D';另一种是下载或获取当日增量数据，此时就是需要START_DT'视角日期' 一个条件即可，不需要加DEL_IND 'D'的条件。

此算法通常用于流水事件表，适合这类算法的源表在源系统中不会更新和删除，而只会发生一笔添加一笔，所以只需每天将交易日期为当日的最新数据取过来直接附加到目标表即可;

通常建一张名为VT_NEW_编号的临时表，用于将各组当日最新数据转换加到VT_NEW_编号后，再一次附加到最终目标表;

此算法通常用于无删除操作的常规状态表，一般是无需保留 历史 而只保留当前最新状态的表，适合这类算法的源表在源系统中会新增，修改，但不删除，所以需获取当日末最新数据(增量或全量均可)，用于MERGE IN或UPSERT目标表;为了效率及识别真正增量的要求，通常先识别出真正的增量数据(新增及修改数据)，然后再用这些真正的增量数据向目标表进行MERGE INTO操作;

通常建两张临时表，一个名为VT_NEW_编号，用于将各组当日最新数据转换加到VT_NEW_编号;另一张名为VT_INC_编号，将VT_NEW_编号与目标表中昨日的数据进行对比后找出真正的增量数据(新增和修改)放入VT_INC_编号，然后再用VT_INC_编号对最终目标表进行MERGE INTO或UPSERT。

此算法通常用于无删除操作的常规状态表，适合这类算法的源表在源系统中会新增、修改，但不删除，所以需每天获取当日末最新数据(增量或全增量均可)，先找出真正的增量数据(新增和修改)，用它们将目标表中属性发生修改的开链数据(有效数据)进行关链操作(即END_DT关闭到当前业务日期)，然后再将最新增量数据作为开链数据插入到目标表即可;

通常建两张临时表，一个名为VT_NEW_编号，用于将各组当日最新数据转换加到VT_NEW_编号;另一张名为VT_INC_编号，将VT_NEW_编号与目标表中昨日的数据进行对比后找出真正的增量数据(新增和修改)放入VT_INC_编号，然后再将最终目标表的开链数据中的PK出现在VT_INT_编号中进行关链处理，然后将VT_INC_编号中的所有数据作为开链数据插入最终目标表即可。

此算法通常用于有删除操作的常规状态表，并且要求删除数据是以DEL_IND='D'删除增量的形式提供;适合这类算法的源表再源系统中会新增、修改、删除，除每天获取当日末最新数据(增量或全量均可)外，还要获取当日删除的数据，根据找出的真正增量数据(新增和修改)以及删除增量数据，用它们将目标表中属性发生修改的开链数据(有效数据)进行关链操作(即END_DT关闭到当前业务时间)，然后再将增量(不含删除数据)作为开链数据插入到目标表中即可;

通常建三张临时表，一个名为VT_NEW_编号，用于将各组当日最新数据 (不含删除数据)转换加载到VT_NEW_编号;第二张表名为VT_INC_编号，用VT_NEW_编号与目标表中的昨日的数据进行对比后找出真正的增量数据放入VT_INC_编号;第三张表名为VT_DEL_编号，将删除增量数据转换加载到VT_DEL_编号;最后再将最终目标表的开链数据中PK出现在VT_INC_编号或VT_DEL_编号中的进行关链处理，最后将VT_INC_编号中的所有数据作为开链数据插入最终目标表即可;

此算法通常用于有删除操作的常规状态表，并且要求提供全量数据，用以对比出删除增量;适合这类算法的源表在源系统中会新增、修改、每天将当日末的最新全量数据取过来外，分别找出真正的增量数据(新增、修改)和删除增量数据，用它们将目标表中属性发生修改的开链数据(有效记录)进行关链操作(即END_DT关闭到当前业务时间)，然后再将最新数据中真正的增量数据(不含删除数据)作为开链数据插入到目标表即可;

通常建两张临时表，一个名为VT_NEW_编号，用于将各组当日最新全量数据转换到VT_NEW_编号;另一张表名为VT_INC_编号,将VT_NEW_编号与目标表中昨日的数据进行对比后找出真正的增量数据(新增、修改)和删除增量数据放入VT_INC_编号，注意将其中的删除增量数据的END_DT置以最小日期(借用);最后再将最终目标表的开链数据中PK出现再VT_INC_编号或VT_DEL_编号中的进行关链处理，然后将VT_INC_编号中所有的END_DT不等于最小日期数据(非删除数据)作为开链数据插入最终目标表即可;

此算法基本等同与常规拉算法，只是在最后一步只将属性非空即非0的记录才作为开链数据插入目标表;

此算法基本等同于基于增量数据删除拉链算法，只是在最后一步只将属性非空及非0的记录才作为开链数据插入目标表;

此算法基本等同于基于全量数据删除拉链算法，只是在最后一步只将属性非空及非0的记录才作为开链数据插入目标表;

此算法是对每一组只将PK在当前VT_NEW_编号表中未出现的数据再插入VT_NEW_编号表，最后再将PK未出现在目标表中的数据插入目标表，以保证只进那些PK未进过的数据;

此算法是源表中有日期字段标识当前记录的生效日期，本算法通过对同主键记录按这个生效日期排序后，一次首尾相连行形成一条自然拉链的算法

I. 数据仓库之数据粒度

确定数据仓库中数据的恰当粒度是数据仓库开发者需要面对的一个最重要的设计问题。数据粒度主要针对指标数据的计算范围，如人口这个数据项在统计部门是以街区范围还是一个社区为范围统计的。人口数据细化程度越高，粒度级就越小；相反，细化程度越低，粒度级就越大。粒度是数据仓库主要设计问题，因为它极大地影响存放在数据仓库中的数据量的大小，同时影响数据仓库所能回答的查询类型。在设计数据仓库的时候权衡数据量大小和查询类型得出合理的粒度大小。下面我们通过规划设计和建设两个阶段来讲解数据仓库粒度的确定。

1.规划阶段

“规划”——对未来整体性、长期性、基本型问题的思考和考量，设计未来整套行动的方案。在规划阶段过程中首先粗略估算数据量，估算的目的是掌握数据仓库中数据量的一个范围。第二步预测未来数据集市中应用需要的粒度，数据仓库存储数据集市使用的最小粒度。

1.1. 建立良好的循环反馈机制是很重要的。

首先就要建立完善的循环反馈机制。数据仓库是面对模糊需求开始建立的，粒度不可能一次就能规划好，先导入少量数据，建立一部分应用提交给用户使用，并聆听用户使用意见，根据用户的使用意见调整粒度的大小。

1.2. 对存储数据进行粗略估算对设计体系结构的人员来说非常有用。

粗略估算数据仓库的数据量，可跟好的规划数据仓库架构。如果数据只有10 000行，那么数据仓库采用粒度级越小的数据存储，数据仓库中存储所有明细数据。如果明细数据有10 000 000行，进入数据仓库的数据就需要进行初步汇总。如果有100亿行，数据仓库不但需要有一个高粒度级，还可能将大部分数据移到溢出存储器上去。

估算方法如下：

1.3. 预测数据集市中可能使用的数据粒度是很必要的。

为了合适地填充所有的数据集市，数据仓库中的数据必须在一个所有数据集市所需要的最低粒度水平上。

规划阶段的成果是数据仓库建设的重要依据内容。规划阶段对组织架构，数据量大小和后期应用的摸底，可以制定方案，并对可能的结果有预先的认知，对可能存在的问题设计上进行避免。

2. 建设阶段

2.1.根据估算的空间结果，在体系架构设计上可以根据数据量大小进行存储设备选择。需要多少直接存取存储设备，是否需采用双重粒度设计。

2.2.设计溢出数据的管理。溢出数据是指数据仓库将不经常被访问的过时的数据转移到存储量更大的访问速度慢的存储器上的数据。管理溢出数据可以方便索引定位历史数据并可以快速取出该数据。

跨介质存储管理器和数据活动监控器可以对溢出数据进行有效的管理。磁盘存储器和大容量低速存储器之间的数据移动是通过一种称为“跨介质存储管理器（CMSM）”的软件来控制的。数据活动监控器，用来确定哪些数据正在被访问，哪些没被访问。数据活动监控器能提供数据存储的位置信息。

2.3.实施数据仓库过程中粒度的确定是一个往复循环的过程。利用规划阶段建立的反馈循环方法，不断的从分析员获得反馈，不断的优化数据仓库。

从图可以看出成功建立数据仓库离不开分析人员的通力协作。建设者要不断的聆听分析员的意见。分析人员在建立数据仓库的时候并不知道自己需要什么，只有在他们看到最终分析结果，才能告诉数据仓库工作人员什么才是他们真正有用的。为了有效的获得反馈，以下几点技巧可供参考：

快速建立数据仓库很小的子集并认真听取用户的反馈意见；

          使用原型方法；

          参考别人的经验；

          与有经验的用户协同工作；

          以企业中已有的功能需要作参考；

          定期举行数据仓库建设例会。

3.例举银行粒度小例子

3.1.银行环境中粒度级别，下图是银行中的数据粒度例子。

银行的操作层存放的是以日为单位粒度的数据。银行的各个业务系统只存放最近60天交易活动明细内容，方便用户查询最近两个月的交易信息详情，这段时间用户对交易数据明细最为关心。

数据仓库层将数据汇聚成以月为单位粒度的汇总数据。银行将过去长达十年的数据按每个账户每月交易信息进行汇聚，存储在直接存储设备，供高速查询访问，用户对过去很久的交易明细并不在意，但是用户需要快速查询得出结果，此时提供以月为单位的汇总数据可以满足用户的需求。

所有的历史数据以日为单位存放在溢出存储区，该区域数据量极大，访问频率极低。一般银行不受理长达十年的历史明细数据查询的请求，如果一些特殊情况需要查询超过十年的历史数据，查询时间会相当缓慢。

4.小结

数据仓库粒度的确定是一个困难的过程，要求一个合适的级别，既不能太高也不能太低。

选择粒度级别很大程度上基于常识。建设之前作好适当的规划，估算数据量并建立相应的反馈制度。在实施的过程中，首先建立数据仓库的一小部分，并让分析人员使用。然后聆听他们的意见，根据他们的反馈对粒度级别进行适当的调整。