清洗和规范化实际上真正的改变了数据，并对数据能否用于预期的目标起到决定作用。
会有三个表：数据评估报告，错误事件事实表，审计维。清洗和规范化步骤中产生元数据。
四个部分：1 设计目标 2 清洗提交 3 快照及其度量 4 规范化提交
清洗和规范化过程中关注的更多的是约束关系与控制而不是数据上的内容。
提交阶段，主要会介绍清洗子系统的主要结构：错误事件表和审计维
定义数据质量：正确的，明确的，一致的，完整的（每个实例定义了特定的值和描述，要确保总数量是完整的）
有两个里程碑：1 是在数据抽取完毕之后 2 是在数据清理和规范化之后
1 设计目标
参与者： 数据仓库管理员（日常决策），信息驾驶员（定义信息策略，对分析目标进行正规化定义，选取适当的数据源，设置声称原则，组织发布元数据），信息质量负责人，维表管理员（创建发布整个组织使用的多个规范化维表），事实表提供者（从不同的维表管理员接受维，将本地原始键转化为规范化维表中的代理键，创建和管理聚合表，聚合表用户提高查询性能）
平衡冲突的优先级：完备性与快速性，校正与透明（数据清洗过程通常用来改正脏数据，但同时会给组织提供一份不加掩饰的原始的视图，这里实现适当的平衡是非常重要的：完全透明的系统会产生一个功能不足的商务职能系统，使得无法深入分析，而过分的纠正的系统会掩盖操作上的不足，从而减缓组织的发展，解决的办法是对不同的错误建立一个可判断的原则界限，这些错误由清洗过程进行纠正或者标志，并生成一个容易使用的审计工具（审计纬度）,用来如实记录那些修改，标准化以及错误检测和数据再造组件的基本规则和设想）
A：无论什么原因导致A问题，都必须简单的在数据源进行处理，比如：缺失的客户投诉主题，销售电话接受能力的假信息，没有技术方法再获取这些信息。当处理这些问题的时候，清洗子系统应该把它们看作是数据源的缺陷，把所有的明显的假的信息从原始报表和分析维和事实表删除，并清楚地表明这些信息是缺失或者伪造，使管理工作直接集中在源系统的问题上面。（很多这种问题，所以必须检测数据质量，并与最终用户群体清晰的沟通）
D类：数据质量只能ETL系统上解决，例如来自第三方数据提供者的缺失和不完整信息i，这里可以通过集成完全修正，另外还有来自固定的操作系统的坏数据的修正（这类问题较少），ETL系统被授权创建这些值来修正数据缺陷，但必须保证他的策略和行为能够通过描述的和完善的元数据对用户可见。
B：即使有些创造性地方法能推断或者再造丢弃的信息。A和B的分界线是技术，而不是策略。如果一个给定的数据问题能有效地在技术上解决，他明显属于A
C：C和D类的界限也是技术上的而非策略上的，如果给定的数据质量问题能合理的在数据源处理，明显属于D类。
2 清洗提交报告
需要回答各种问题：数据质量正在逐渐好还是糟，哪个数据源系统会产生最多/少的质量问题，整个过程又没有什么趋势，数据质量水平和作为整体组织的效率之间有没有相关性，ETL中 哪个数据质量过滤器消耗了最多的时间，对于那些不再数据中出现的已发现的问题类型，是否可以去掉它们的数据质量过滤器？
数据清洗后报告：数据评估结果，错误事件表，审计维
审计维：事件粒度是在ETL系统中的任何表中的单条记录。显然，这些事件不可能在最终提交到前段的表的个别记录的粒度上发生。为了把数据质量指示器和最终用户的事实表进行关联，我们需要在这些表的粒度上单独赋值建立一个维，我们把其叫做审计维。审计纬描述了被递交到前端的事实表记录的完整性质量上下文。审计维按照字面上与数据仓库中的每个事实记录相关联，它将保存ETL过程中里程碑的事件戳和输出结果，以及明显的错误和它们在记录上发生的频率，另外还有整个数据质量评分，审计维记录在清洗和规范化事实表记录处理的最后一步创建，并且必须包括应用到该记录的修复描述。
审计维取得每一事实记录的特定数据质量上下文，但这通常不会引起审计大小记录的巨量增加，因为审计维的目的是描述遇到的每种数据质量类型，在理想的情况下，对于一个将数据的载入到事实表完整干净的过程，只有一条审计记录产生。如果该过程除了一些因为异常值而触发了越界检查的输入记录外都是干净的，则将生成两条审计记录，一条是正常的，一条是越界的。但绝大多数事实记录会使用代理建作为正常的审计记录，极少数异常的事实记录会使用代理建作为审计记录。
3 过滤器及其度量
ETL过程创建时暴露数据异常是导致ETL部署延时的主要原因。发现数据异常会花很多时间分析，提前这样分析可以节省时间，较好地方式是一次一次重建ETL作业，此时可以尝试去纠正由于没有被发现的数据异常导致的错误影射。
数据采样：可以是随机数目，可以使把表分成几个部分然后选择1000行。（注意：常用的一个错误就是选择一个日期区间来缩小结果集，比如换操作员什么的，因此在一定日期区间中选择数据可以很容易的错过这些异常）
约束的类型：列属性约束（检查列的Null值，超出期望的最高和最低范围的数值，长度超常或者超短的列，包含有效值列表之外的数值，匹配所需的格式或者一组格式，在已知的错误值列表中命名数，拼写检查器），结构约束（主键外建，父子关系），数值约束，值约束
ETL作业流可以选择：1 让没有错误的记录通过2 记录通过，标记所有错误值 3 拒绝记录 4 停止ETL。一般会选择第2 项。
整个处理流：
为了更好的性能，数据清理子系统的处理流程的目标是触发可以并行运行的批过滤器。这些批过滤器识别出数据质量问题，并在错误事件事实表中插入记录。为最大成都减少数据库的冲突问题，应该在错误事件事实表上避免不需要的索引或者约束，以便当多个过滤器处理同时写记录时候不会引起问题。调用过程在触发下一个批过滤器前要等待每一个批过滤器的执行完成，直到没有剩下的批过滤器要执行。过滤器元数据表中的处理顺序号是用于调度过滤器的，相同处理顺序号的过滤器能并行执行。建议的运行过滤器的方法是建立一个通用的软件模型，它可以执行任何过滤器，只需要批处理ID和过滤器代理键作为参数即可。这一模型为过滤器抽取元数据并构造一个动态的insert语句。
持续运行：
数据清洗子系统的指导原则是发现并记录存在的数据质量错误，而不是跳过记录或者停止ETL。清理子系统也必须提供一些处理意想不到情况的机制，包括由于太严重而不被允许进入数据仓库的记录，也包括那些很严重的系统级的缺陷能导致整个ETL过程停止的记录。小的低级错误采取异常动作，大的异常，可能表示上一级处理过程有问题，严重到影响ETL处理流中的数据完整性，这种情况建议创建额外的数据质量过滤器，让他直接针对错误事件事实表运行，计算在整个数据质量批处理中捕获的数据质量错误事件记录的数目，并且触发异常处理程序。
过滤器
运行过滤器之前，需要建立全局的数据评估基本规则。包括定义列的属性等，无效数值，数字列的方位，长度，表大小等。对于每个被载入的数据源，需要检查：为抽取的表提供每天记录数的历史，提供每天的关键业务度量的总数历史，确定需要的列，确定需要唯一的列集合，确定允许不允许为空的列，数字字段可接受范围，字符长度，有效数值集，无效值的频繁程度。
4 规范化报表
数据集成意味着创建规范化报表，以及通过组合来自多个数据源的最有效信息为一个综合的试图来创建的事实实力。为了实现这些，导入的数据需要结构统一，并过滤掉无效记录，将内容术语标准化，删除重复记录，将内容术语标准化，删除重复记录，从而产生新的规范化后的映像。标准化，匹配和删除重复记录，生存。
跨越多个数据源，多个数据集市，以及访问分布式的数据仓库的多个远程客户端来规范化描述属性，是个关键步骤。
规范化维：数据仓库从某种程度来说是分布的，因为每种类型的度量总是必须存在于各自的事实表中。对于从多个分离的事实表组合数据的最终用户来说，必须为这些事实表提供统一的界面，这样数据才可以被整合。我们称这类一致的界面叫做规范化维和规范化事实。
规范化维对于每一个可以被关联的事实表来说都是相同的，通常，规范化维对于每一事实表都是相同的。如果可以共享一个或更多的取自同一个域的值得属性，那么这两个维是规范化的，当使用规范化维在不同的事实表间钻去的时候，应用请求必须使用这一相同的属性来作为约束和分组的基础。
设计规范化维：规范化维的可变性（有可能为这些事实表创建规范化维表的子集，因为特定事实表的数据范围仅仅是子集的情况，如不需要某些日期什么的），规范化事实(在规范化会议中，管理员也需要确定在每一张事实表里呈现的类似的事实。例如，许多事实表可以报告收入信息。如果最终用户应用期望添加或比较这些来自多个事实表收度量，则定义这些收入度量的业务规则必须是相同的。也许有的表是在月末记录收入度量，但是另外的表则可能从帐单期的聚合得到收入信息)，维表管理（当维表发布新版本了，事实表提供者需要立刻更新本地的维表拷贝，每一个规范化维都必须在每一条记录上都有一个类型的版本号字段）
匹配驱动去重复： 包括标准化记录重复值得删除
共存：规范化的最后一步
共存性是指整合一组匹配（去重复）记录到统一的映像，他把每一条匹配的记录组合成最高质量的列值来建立规范维记录。
提交
提交是ETL 最后的重要步骤。在此步骤中，已经清洗并规范化过的数据被实际写入到维结构中供最终用户和应用系统访问。在只由一个表空间组成供最终用户访问的最小经数据仓库中，维表只是简单地写入这个表空间。但对于大型的数据仓库，从含有多个表空间到更广泛的分布式数据集市自治网络，维表必须以一致的方式仔细地发布。提