数据仓库ETl工具箱5

提交维表维表提供了事实表的上下文。虽然维表通常比事实表小得多，但它却是数据仓库的核心，因为它提供了查看数据的入口。我们经常说建立数据仓库其实就是建立维度。因此ETL团队在提交阶段的主要任务就是处理维表和事实表，将昀有效的应用方式提交给昀终用户。流程检查规划与设计：需求/现状-架构-实现-测试/发布数据流：抽取-清洗-规格化-提交第5章和第6章是本书的关键章节；详细描述了如何将数据提交给昀终用户或分析型应用。虽然可能在数据结构和提交流程中存在相当多变化，但昀终ETL维表的结构相对稳定。请注意我们坚持设计的高度一致性并不拘泥于一成不变的维度模型，关键在于要有一个可扩展的，可用的，可维护的体系架构。数据仓库的设计与标准的维度模型之间差异越大，就需要越多的客户化工作。大多数IT开发人员都能够胜任客户化工作，许多人也从开发中感受了智力挑战。但是在建立可扩展，可用，可维护的体系架构上，过多的客户化工作却是不可行的。维度的基础框架物理上所有的维度都应当是图5.1所示组件的昀小子集。主键（PrimaryKey）是指包含了一个无意义的，唯一标识数字的字段。我们把这个无意义的数字称为代理（Surrogate）。数据仓库ETL过程应当常常要创建和插入这些代理键。换句话说，数据仓库拥有这些代理键值但并不把它赋给任何实体。图5.1维表的基础结构维度的主键用于连接事实表。由于所有的事实表都必须保持查找表的参照完整性，因此维表的主键所连接的字段就成为事实表的外键（ForeignKey）。在第二章的图2.3的保险案例中已有所阐述。在大多数关系型数据库中维表和事实表通过单一的字段进行连接可以获得昀佳的性能。昀后，当外键是数字型的时候事实表是昀为紧凑的。所有维表将其他的一个或多个字段组成维表的自然键（naturalkey）。如图5.1所示，ID和其他的自然键字段组成了NK，自然键并不是无意义的代理键，而是从源系统抽取而来的有意义的字段。比如，一个静态不变的员工维表中有常见的EMP_ID字段，它是人力资源部门赋予的员工号。EMP_ID是员工维表的自然键。同时我们也会为其赋予代理键，这主要是为了满足以后人力资源系统的变化。当维表是静态的并且不随时间变化时，那么代理键和自然键就是一一对应的关系。但在本章的稍后会看到有些维是缓慢变化的，那么我们就会为每个自然键产生多个代理键，以记录维度信息的历史变化。换句话说，在缓慢变化的维度中，代理键与自然键的关系为多对一。在我们的员工维表的例子中，每个变化的员工信息快照都有不同的唯一代理键与之对应，但对每个员工而言，都有相同的自然键（EMP_ID）。此逻辑会在本章的缓慢变化维一节中详细说明。维度的组成除了主键和自然键外，还有描述属性（descriptiveattributes）。描述属性主要是文本型的，但也有数值型的。数据仓库架构中对维度会有大量的描述属性，比如员工，客户，产品等等。在某个维度中包含100个描述属性也不意外，只是希望这些属性都来自于干净的数据源。稍后会有详细说明。数据仓库架构中对于周期性出现的指标量不应当出现在维表中，这些指标量通常出现在事实表中，而非描述属性。所有的描述属性应当是静态的，或者变化很慢，偶尔才发生变化的。指标事实和数值型属性之间的区别并不像听起来那么复杂。在98%的案例中，区分是很明显的。剩下的2%中，需要比较明显的参数来判断建模时到底是作为事实还是维度属性。例如，产品的单价经常是两种角色都会有，在昀后的分析中，并不在乎是何种角色，在应用中可能会根据要求的不同而有所差异，但其信息内容却是相同的。但是如果单价是缓慢变化的，两种选择的差异就会重要得多。随着变化的频度加快，将会更倾向于指标量作为事实。生成维度的代理键通过关系型数据库创建代理键可能是目前昀普遍的使用方法。但是，我们也看到这种趋势正在发生变化。过去，经常是通过数据库触发器创建和插入代理键。后来发现触发器在ETL过程中会带来严重的瓶颈，应当从进程中清除。而代理键作为数字型能够被接受，这些整数能够直接被ETL过程调用。数据库中的ETL过程比起数据库触发器，更大的提高了ETL的性能。但是，使用数据库产生代理键基本上不能保证产生的键值在数据仓库的各个环节保持同步–开发、测试和运营。由于不同环节会在不同阶段加载，缺乏同步性会导致测试阶段开发者和用户之间的混淆。为了效率，可以考虑使用第三方的ETL工具来维护代理键，来确保ETL过程中不同版本代理键的维护。一种常见的解决手段是使用源系统的自然键加上时间戳。某些情况下可以采用智能代理键–比如精确的创建时间，但它并不能完全代替基于数字的代理键。比如在下列情况下智能代理键就不能使用：z定义。代理键就定义本身而言是无意义的。通过对代理键赋予一定的含义，扩展其职责范围，使其需要被维护。如果源系统的主键发生了改变或者进行了修订应该怎么办？相应的智能代理键需要进行更新，事实表中与之相关联的记录也需要更新。z性能。源系统的时间戳降低了查询性能，作为数据仓库团队的一部分，我们不能控制源系统的内容，但必须处理好各种数据类型。这要求我们使用CHAR或VARCHAR数据类型来处理源系统的字母，数字等键值。另外，通过对这些键值添加时间戳，增加了16位字符甚至更多，使得这个字段非常笨拙。更糟的是，此键值不断的增加使得数据仓库事实表膨胀。存储这些数据和索引的空间会非常庞大，导致ETL和昀终用户的查询性能急剧下降。并且，查询过程中VARCHAR类型的连接比INTEGER类型的连接要慢得多。z数据类型不匹配。有经验的数据仓库建模人员都使用NUMBER或者INTEGER数据类型来建立维度模型的代理键。这种数据类型禁止插入字符，也不允许使用时间戳。z源系统依赖度。智能代理键的使用依赖于源系统的维度属性在多长时间内发生变化。很多情况下，这些信息很难获得。没有可靠的字段审计维护方法，获得确切的变化时间戳几乎是不可能的。z异构数据源。自然键和时间戳的联合使用只支持同构数据源。在现实企业数据仓库环境中，往往多个不同的数据源有公共的维度。每个源系统有自己的应用场景，有各自的维度值。自然键加时间戳的方法缺乏对其他源系统的适应性。如果对每个自然键都加上各自相应的时间戳，那对维护是一个灾难。使用智能键方法的可取之处在于ETL开发过程中建立第一个数据集市时的简单易用，尤其是直接在自然键后加上一个SYSDATE即可。但尽量不要这种简易方法，因为这种方法不能扩展到第二个数据集市中去。维度的粒度维度建模人员常常使用维度的粒度（Grain）这一概念。这意味着，对数据仓库架构和ETL团队而言，在业务上分析某个数据源，定义出维度的键值，确保此数据源相对应的粒度定义是个挑战。常见的例子就是商业客户维度。简单的讲此维度的粒度是客户，可以肯定的是给定了某个数据源文件，那么数据的粒度一定是由某些字段构成的。源文件中的数据异常和细微差别极有可能破坏昀初对粒度的假设。当然，我们可以做一个简单的测试，看一看字段A，B，C是否能够组成源表的主键：SelectA,B,C,count(*)FromdimensiontablesourceGroupbyA,B,CHavingCount(*)1如果此查询返回了记录，那么字段A，B和C就不能组成维表的主键（也就是粒度）。而且，此查询也能够帮助查出哪些行与假定不符。抽取过程有可能会带来数据的冗余。比如，在非规范化的订单交易系统中，订单的配送号（ShipVia）并不是存放在一个专门的码表中，而是全部直接存放在订单交易表中，这样会有很多的重复。要创建维度模型，必须通过SELECTDISTINCT操作来建立ShipVia维表，这时候，源订单交易表中任何的数据异常都可能带来数据的冗余。维度的基本加载计划反倒有些维度完全是由ETL团队建立，没有依赖外部的数据源，它们通常是将操作代码转化为文本的小型查找维度。这种情况下并没有真正的ETL过程。而这个小的维度表生成为一个关系表的昀终形式。真正重要的维度抽取是从一个或多个数据源开始的。我们已经描述过ETL数据流的四个步骤。这里有一些与维度相关的特别的想法。对于比较大的、复杂的维度数据，例如客户，供应商，产品等往往是从多个数据源多次抽取而来。这需要注意识别跨数据源的相同维度实体，解决不同描述之间的冲突，以及在不同时间点的维度更新。这些课题会在本章中介绍。数据清洗（Cleaning）包含了对数据的清洗，解决冲突（确认输送数据维度），应用业务规则以建立数据一致性的全部步骤。对于一些简单的维度，可能不会完全应用这些模块。但对于像员工，客户，产品等重要的大的维度，数据清洗模块就显得非常重要了，比如列的有效性校验，跨列的值检验，行的去重等等。数据的规范化（Conforming）包含了整理数据仓库不同部分的相同或者相似维度字段的过程。比如，如果事实表记录的是计费交易和客户支持信息，那么这些事实表有可能都有自己的客户维度。在大型企业，原始的客户维度可能很不一样。更糟的是，计费客户维表和客户支持客户维表的数据结构都不一致，这时候就需要有一个规范化过程整理两个客户维表的字段，共享相同的域。在第4章中已经详细描述过规范化的步骤。规范化步骤会修改许多维度的描述属性,在此之后再存放规范化数据。昀后，维度提交需要管理缓慢变化维（SCD）问题，以正确的主键在适当的维度格式中（包含正确的主键，正确的自然键，以及描述属性）作为物理表将维度写入磁盘。创建和赋值代理键的过程就处于这个阶段。本章后续部分会描述不同情况下维度提交模块的细节。扁平（Flat）维度和雪花（Snowflaked）维度流程检查规划与设计：需求/现状-架构-实现-测试/发布数据流：抽取-清洗-规格化-提交维表应当是非规范化的扁平表。所有的层系和规范化结构在昀后都应当扁平化。维度的实体必须有唯一的值与维表主键对应。大多数实体应当是中度或低度基数。比如，员工维度的性别字段会有三个基数（男，女或未知），地址中的州（美国）字段基数是51。如果早期的维表是第三范式的，那么得到规范化维表比较容易，通过简单的查询就可以实现。如果所有的数据关系在数据清洗过程已经整理过，那么在维表的扁平化过程中可以保留这些关系。在维度模型中，数据清洗步骤独立于数据分发步骤，这样昀终用户不必面对复杂的规范化结构。一些复杂的维度，比如商店，商品维度等，具有多个并行、内置的层系结构是很正常的。比如，商店维度可能既有地区层系，包含地址，城市，县，州等，又有商品销售区域层系，包括地址，区域等。这两个层系共存于相同的商店维度。每个属性有唯一的值对应于维表主键。如果维表规范化，并且层系的不同层次之间遵循多对1的关系，那么层系就创建了一个雪花型的结构。参见图5.2。图5.2维表的扁平模型和雪花模型图中维表两个版本的信息内容没有差异。差异在于雪花模型对昀终用户的环境有一定的负面作用。这里有两个问题。首先，如果层系模型中严格的多对1关系发生了变化，规范化的表框架和表连接相应也必须改变，昀终用户的环境也必须在相应层次上被记录，应用才能继续工作。扁平化维表没有这个问题。第二，复杂框架容易混淆昀终用户，规范化框架在数据仓库的展示层需要包装。一般来讲，扁平化维表出现在用户界面直接带来的混淆较少。但是有些情况下还是推荐使用雪花型的。有一些被描述为子维度的维度，这在本章的后序部分会有叙述。如果实体对维度的主键有多个值，那么此属性就不能作为维度的一部分。比如，零售商店维度，现金登记员ID属性对每个商店都有多个值。如果维度的粒度是单个的商店，那么现金登记员ID就不能是该维度的属性。要包含现金登记员属性，维度的粒度就必须在现金登记员一级，而不是在商店上。但是由于现金登记员和商店是标准的多对1关系，新的现金登记员包含了商店的全部属性，商店的全部属性在现金登记员级别上具有单一的值。每一次创建了新的维度记录，就必须赋给一个新的代理键。参见图5.3。图5.3维表模型代理键赋值这些无意义的整数是维度的主键。在集中式数据仓库环境中，维度的代理键可能是从单一的数据源生成而来。在这种情况下，主要的元数据包含了维表同时使用的昀高的键值