数据仓库ETl工具箱6
数据仓库ETL工具选择与Workflow优化
数据仓库ETL工具选择与Workflow优化在大数据时代，数据仓库已经成为了企业管理和决策的重要基石。
而ETL工具作为数据仓库建设的关键环节，发挥着至关重要的作用。
本文将探讨数据仓库ETL工具的选择以及如何优化Workflow。
一、数据仓库ETL工具选择数据仓库ETL工具是实现数据抽取、转换和加载的关键工具。
在选择合适的ETL工具时，需考虑以下因素：1. 数据源适配性：不同企业的数据来源各异，因此ETL工具应具备对多种数据源的适配性，包括关系型数据库、文件系统、Web服务等。
2. 数据抽取和转换能力：作为ETL的核心步骤，数据抽取和转换的能力决定了ETL工具的实用性。
一个好的ETL工具应具备多样的抽取和转换功能，包括数据过滤、清洗、聚合、计算等。
3. 并行处理能力：随着数据量的增加，数据仓库的ETL过程往往需要大量的计算和处理。
因此，一个好的ETL工具应具备并行处理能力，以提高数据处理的效率。
4. 作业调度和监控：ETL工具应提供可靠的作业调度和监控功能，能够自动化执行ETL流程，并及时反馈运行情况和错误信息。
5. 扩展性和灵活性：ETL工具应具备良好的扩展性和灵活性，能够适应未来企业的数据需求变化，并支持自定义功能和插件的开发。
综上所述，选择一个适合企业需求的数据仓库ETL工具需要综合考虑以上因素，结合企业的实际情况进行评估和比较，选择最为合适的工具。
二、Workflow优化Workflow是指ETL过程中由多个任务节点组成的工作流，通过优化Workflow可以提升ETL的效率和性能。
以下是一些常见的Workflow优化技巧：1. 并行化处理：将一些可以并行执行的任务节点进行拆分，利用并行处理能力提高整体的处理速度。
2. 数据分区和分片：对于大容量的数据集，可以将其进行分区或分片处理，以减轻单个节点的压力，提高处理效率。
3. 缓存机制：针对经常使用的数据或计算结果，可以引入缓存机制，避免重复抽取和计算，提高数据处理的速度。
超详细的六款主流ETL工具介绍及功能对比
超详细的六款主流ETL⼯具介绍及功能对⽐概述ETL（Extract-Transform-Load的缩写，即数据抽取、转换、装载的过程），对于企业或⾏业应⽤来说，我们经常会遇到各种数据的处理，转换，迁移，所以了解并掌握⼀种etl⼯具的使⽤，必不可少。
最近⽤kettle做数据处理⽐较多，所以也就介绍下这⽅⾯内容，这⾥先对⽐下⼏款主流的ETL⼯具。
1、DataPipelineData Pipeline是⼀家为企业⽤户提供数据基础架构服务的科技公司，DataPipeline数据质量平台整合了数据质量分析、质量校验、质量监控等多⽅⾯特性，以保证数据质量的完整性、⼀致性、准确性及唯⼀性，彻底解决数据孤岛和数据定义进化的问题。
2、KettleKettle是⼀款国外开源的ETL⼯具，纯java编写，可以在Windows、Linux、Unix上运⾏，数据抽取⾼效稳定。
Kettle 中⽂名称叫⽔壶，该项⽬的主程序员MATT 希望把各种数据放到⼀个壶⾥，然后以⼀种指定的格式流出。
Kettle家族⽬前包括4个产品：Spoon、Pan、CHEF、Kitchen。
SPOON 允许你通过图形界⾯来设计ETL转换过程（Transformation）。
PAN 允许你批量运⾏由Spoon设计的ETL转换 (例如使⽤⼀个时间调度器)。
Pan是⼀个后台执⾏的程序，没有图形界⾯。
CHEF 允许你创建任务（Job）。
任务通过允许每个转换，任务，脚本等等，更有利于⾃动化更新数据仓库的复杂⼯作。
任务通过允许每个转换，任务，脚本等等。
任务将会被检查，看看是否正确地运⾏了。
KITCHEN 允许你批量使⽤由Chef设计的任务 (例如使⽤⼀个时间调度器)。
KITCHEN也是⼀个后台运⾏的程序。
3、TalendTalend，是⼀家专业的开源集成软件公司，为企业提供开源的中间件解决⽅案，从⽽让企业能够在他们的应⽤，系统以及数据库中赢取更⼤的价值。
在传统软件公司提供封闭、私有的解决⽅案的领域Talend系列软件以开源的形式进⾏开发。
三大主流ETL工具选型
三大主流ETL工具选型ETL(extract, transform and load) 产品乍看起来似乎并不起眼，单就此项技术本身而言，几乎也没什么特别深奥之处，但是在实际项目中，却常常在这个环节耗费太多的人力，而在后续的维护工作中，更是往往让人伤透脑筋。
之所以出现这种状况，恰恰与项目初期没有正确估计ETL工作、没有认真考虑其工具支撑有很大关系。
做ETL产品的选型，仍然需要从以前说的四点(即成本、人员经验、案例和技术支持) 来考量。
在此，主要列举三种主流ETL产品：Ascential公司的Datastage、Informatica公司的Powercenter、NCR Teradata公司的ETL Automation。
其中，ETL Automation相对其他两种有些特别之处，放在后面评述。
旗鼓相当：Datastage与Powercenter就Datastage和Powercenter而言，这两者目前占据了国内市场绝大部分的份额，在成本上看水平相当，虽然市面上还有诸如Business Objects公司的Data Integrator、Cognos公司的DecisionStream，但尚属星星之火，未成燎原之势。
谈Datastage和Powercenter，如果有人说这个就是比那个好，那听者就要小心一点了。
在这种情况下有两种可能：他或者是其中一个厂商的员工，或者就是在某个产品上有很多经验而在另一产品上经验缺乏的开发者。
为什么得出这一结论？一个很简单的事实是，从网络上大家对它们的讨论和争执来看，基本上是各有千秋，都有着相当数量的成功案例和实施高手。
确实，工具是死的，人才是活的。
在两大ETL工具技术的比对上，可以从对ETL流程的支持、对元数据的支持、对数据质量的支持、维护的方便性、定制开发功能的支持等方面考虑。
一个项目中，从数据源到最终目标表，多则上百个ETL过程，少则也有十几个。
这些过程之间的依赖关系、出错控制以及恢复的流程处理，都是工具需要重点考虑。
ETL工具在数据仓库建设中的应用
ETL工具在数据仓库建设中的应用随着企业信息化建设的不断深入，越来越多的企业开始重视数据仓库的建设。
作为企业数据管理的核心，数据仓库不仅可以实现对企业数据的高效管理和快速查询，还可以为企业的决策提供有力的支持。
然而，在数据仓库建设过程中，不可避免地需要面对海量数据的清洗与整合问题。
而ETL工具，则是解决这一问题的重要手段。
ETL工具的定义ETL是一个由Extract（提取）、Transform（转换）、Load（加载）三个单词的缩写，即将数据从其他系统中提取出来，进行转换和整理后，再加载到目标系统中。
ETL工具就是用来实现这一过程的软件工具。
它可以帮助企业将各种各样的数据从各个数据库、文件和应用程序中提取出来，并在目标系统中进行清洗、转换和加载。
从而实现对数据的全面整合和统一管理。
ETL工具的应用ETL工具在数据仓库建设过程中具有非常重要的应用价值。
主要包括以下几个方面：1. 数据清洗和整理企业的信息系统中存在着各种各样的数据源，有时这些数据源之间存在着冗余、重复或者不规范的数据。
使用ETL工具可以帮助企业对这些数据进行清洗和整理，消除冗余、重复，提高数据的质量和准确性。
2. 数据转换和集成不同的数据源之间存在着不同的数据格式和数据结构。
通过ETL工具，可以对这些数据进行格式转换和结构转换，使得它们可以被正确地集成到数据仓库中。
3. 数据质量的保证数据质量是企业信息化建设的一个核心问题。
使用ETL工具可以对数据进行一系列的质量检测和清洗，从而保证数据的准确性、完整性和一致性。
4. 数据仓库的构建和维护ETL工具可以帮助企业构建数据仓库，并实现数据的持续更新和维护。
在数据仓库的构建过程中，ETL工具可以自动地完成数据的抽取、转换和加载，极大地提高了数据仓库的建设速度和效率。
ETL工具的选择和使用ETL工具市场上有很多种，不同的ETL工具虽然都有相似的功能，但各自也有自己的优缺点。
如何选择和使用一个适合自己企业的ETL工具呢？1. 根据企业需求选择不同的企业面临的数据问题不尽相同，需要ETL工具的功能也不尽相同。
使用ETL工具进行数据集成与转换
使用ETL工具进行数据集成与转换随着数据量的不断增长和多样性的提升，数据集成和转换成为了数据管理的重要环节。
而ETL（Extract, Transform, Load）工具作为一种常见的数据集成与转换工具，被广泛使用于企业数据仓库和大数据分析中。
本文将探讨ETL工具在数据集成和转换中的作用、常见的ETL工具以及使用ETL工具进行数据集成与转换的方法。
一、ETL工具的作用ETL工具的主要作用是帮助将分散在不同数据源的数据进行抽取（Extract）、转换（Transform）和加载（Load）到目标数据仓库或数据湖中，以便进行后续的数据分析和决策支持。
具体而言，ETL工具能够实现以下功能：1. 数据抽取：从多个异构数据源中提取数据，并进行清洗和加工，使得数据能够被后续处理程序所识别和利用。
2. 数据转换：对提取出的数据进行格式转换、数据匹配与精简、数据合并和数据聚合等操作，以满足后续数据分析和应用的需要。
3. 数据加载：将经过转换的数据加载到目标数据仓库或数据湖中，保证数据的可用性和一致性。
二、常见的ETL工具市面上存在着多种ETL工具，各有特点和适用场景。
以下为几种常见的ETL工具：1. Informatica PowerCenter：作为市场上最常用的ETL工具之一，Informatica PowerCenter具备强大的数据转换能力和丰富的连接器，可支持多种数据源和目标，适用于各种规模的数据集成与转换任务。
2. Talend Open Studio：作为一款开源的ETL工具，Talend Open Studio十分灵活，提供了丰富的组件和插件，可以用于数据抽取、转换和加载等各个环节。
3. IBM InfoSphere DataStage：作为IBM的ETL解决方案，InfoSphere DataStage拥有可靠的数据集成和转换功能，支持高性能的批处理和实时处理，适用于大规模数据集成和转换。
4. Microsoft SQL Server Integration Services（SSIS）：作为微软SQL Server数据库的一部分，SSIS提供了强大的数据集成和转换能力，可以与SQL Server数据库无缝集成，方便进行数据仓库和大数据分析。
数据集市化etl工具使用说明书
数据集市化etl工具使用说明书数据集市化ETL工具使用说明书一、概述数据集市化ETL工具是一种用于数据集市建设和数据集市化过程中的数据集成、转换和加载的工具。
它可以帮助用户快速、高效地将不同数据源中的数据进行整合、清洗和转换，最终将数据加载到数据集市中，为数据分析和决策提供支持。
二、安装和配置1. 安装：将数据集市化ETL工具的安装包下载到本地，双击运行安装程序，按照提示完成安装过程。
2. 配置：在安装完成后，打开工具，进入配置界面，根据实际需求进行相应配置，包括数据库连接配置、数据源配置等。
三、数据源配置1. 新建数据源：在工具中选择“数据源管理”，点击“新建数据源”按钮，根据实际情况填写数据源名称、类型、地址、端口等信息，并进行测试连接。
2. 编辑数据源：在数据源管理界面，选中需要编辑的数据源，点击“编辑”按钮，对数据源进行相应的修改和配置。
3. 删除数据源：在数据源管理界面，选中需要删除的数据源，点击“删除”按钮，确认删除操作。
四、数据集成1. 新建数据集成任务：在工具中选择“数据集成任务管理”，点击“新建数据集成任务”按钮，根据实际需求填写任务名称、描述等信息。
2. 配置数据源：在数据集成任务管理界面，选择需要配置的数据集成任务，点击“配置数据源”按钮，选择源数据源和目标数据源，并进行字段映射和数据转换等配置。
3. 运行数据集成任务：在数据集成任务管理界面，选择需要运行的数据集成任务，点击“运行”按钮，等待任务执行完成。
五、数据转换1. 数据字段映射：在数据集成任务的配置过程中，可以根据需要进行源字段和目标字段的映射，确保数据能够正确转换和加载。
2. 数据清洗：在数据集成任务的配置过程中，可以进行数据清洗操作，包括数据去重、数据过滤、数据格式化等，以确保数据的质量和准确性。
3. 数据转换：在数据集成任务的配置过程中，可以进行数据转换操作，包括数据合并、数据拆分、数据计算等，以满足不同的业务需求。
数据仓库建模工具及ETL工具
数据仓库建模工具及ETL工具建模工具，一般企业以Erwin、powerdesigner、visio，甚至Excel等为主。
PowerDesigner是Sybase的企业建模和设计解决方案，是能进行数据库设计的强大的软件，是一款开发人员常用的数据库建模工具。
使用它可以分别从概念数据模型(Conceptual Data Model)和物理数据模型(Physical Data Model)两个层次对数据库进行设计。
ERWin全称是ERwin Data Modeler，是CA公司的数据建模工具。
ERwin提供数据库结构，管理界面的容易简单，图形显示对视觉复杂。
VisioVisio是Office 软件系列中的负责绘制流程图和示意图的软件，是一款便于IT和商务人员就复杂信息、系统和流程进行可视化处理、分析和交流的软件。
同时它也可以用来数据库建模。
打开visio 2010,文件—>新建—>数据库—>数据库模型图。
建立数据库模型图之后，菜单栏多出一个菜单项'数据库'。
ETL工具或类ETL的数据集成同步工具或语言，企业生产中工具也非常之多，主流的etl工具有Sqoop、DataX、Canal、flume、Logstash、kettle、DataStage、Informatica、Talend等，语言有强悍的SQL、Shell、Python、Java、Scala等。
而数据源多为业务系统，埋点日志，离线文件，第三方数据等。
Sqoop，SQL-to-Hadoop 即“SQL到Hadoop和Hadoop到SQL”。
是Apache开源的一款在Hadoop和关系数据库服务器之间传输数据的工具。
主要用于在Hadoop与关系型数据库之间进行数据转移，可以将一个关系型数据库（MySQL ,Oracle等）中的数据导入到Hadoop的HDFS中，也可以将HDFS的数据导出到关系型数据库中。
sqoop命令的本质是转化为MapReduce程序。
数据仓库中ETL工具的选型与使用
数据仓库中ETL工具的选型与使用随着企业信息化的深入发展，数据仓库在企业的日常运营中扮演着越来越重要的角色。
而在数据仓库建设中，ETL工具起着至关重要的作用。
本文将结合笔者多年的从业经验，深入探讨数据仓库中ETL工具的选型与使用，旨在为读者提供一些有用的参考。
一、ETL工具的概述首先，我们来了解一下ETL工具的概念。
ETL工具是指一类用于将不同来源的数据进行抽取（Extract）、转换（Transform）、加载（Load）等操作的软件。
在数据仓库中，ETL工具类似于“数据加工车间”，可以完成数据的清洗、整合、转换等多种工作。
目前市面上比较流行的ETL工具有很多，例如IBM DataStage、Informatica PowerCenter、Oracle Data Integrator等。
每个ETL工具都有其独特的特点及适用场景，选择一款合适的ETL工具非常关键。
二、ETL工具的选型在ETL工具的选型中，需要考虑以下几个方面：1. 企业规模及需求企业规模及需求是选择ETL工具的首要考虑因素。
对于规模较小的企业，可以选择一些开源的ETL工具，如Kettle和Talend Open Studio。
这些工具具有操作简便、易于掌握、可扩展性强等优点，适合小型企业以及需要快速实现数据仓库的项目。
而若企业具有大规模的数据仓库及数据流转需求，可以考虑一些成熟的商业ETL工具，如IBM DataStage、Informatica PowerCenter、Oracle Data Integrator等。
这些工具具有高度可靠性、高性能、强大的数据处理能力等优点，可以满足企业不断发展的需求。
2. 数据量及复杂度数据量及复杂度也是选择ETL工具的一个重要考虑因素。
对于数据量较小、简单的企业，可以选择一些基础的ETL工具，如Microsoft SQL Server Integration Services等。
这些工具主要用于数据提取、转换、加载等基础操作，适合数据量较小及较为简单的企业。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
提交事实表事实表装有企业的度量数据。
事实表与度量的关系非常简单。
如果存在一个度量，则它可以被模型化为事实表的行。
如果事实表的行存在，则它就是一个度量。
那么什么是度量呢？一个关于度量通用的定义是：通过工具或比例等级可以测量观察的数量值。
在维度建模时，我们有意识地围绕企业的数字度量创建我们的数据库。
事实表包含度量，维表包含关于度量的上下文。
这种关于事物的简单视图被一次又一次的证明是最终用户直观理解我们的数据仓库的方式。
这也是我们为什么通过维度模型打包和提交数据仓库内容的原因。
流程检查规划与设计：需求/现状 -> 架构 -> 实现 -> 测试/发布数据流：抽取 -> 清洗 -> 规格化 -> 提交第5章描述了如何创建数据仓库的维表。
也许从维表开始介绍会觉得很奇怪，因为度量以及事实表才是最终用户真正想要看的内容，但是维表是事实表数据的入口，事实只有通过维度解释才会变得有意义。
由于第5章详细完整地描述了维，因此本章的内容多少会变得简单一些。
事实表基本结构每一个事实表通过表的粒度来定义。
事实表的粒度是事件度量的定义。
设计者必须至始至终按照度量如何在现实世界中理解来规定事实表的粒度。
例如，图6.1中的事实表的粒度为指定的零售发票上的单个货品。
我们并不从定义这些字段的粒度开始，而是将粒度表示成为维度的外键和事实表的某些字段。
粒度定义必须按照现实的，物理的度量意义来定义，然后才考虑维度和事实表中的其他字段等其他因素。
所有的事实表包含了一组关联到维表的外键，而这些维表提供了事实表度量的上下文。
大多数的事实表还包括了一个或者多个数值型的度量字段，我们称之为事实（Fact）。
请看图6.1。
某些事实表中还包还了一个或者多个特殊的近似维度字段，他们是在第5章中介绍的退化维度(Degenerate Dimensions)。
退化维度存在于事实表，但是他们不是外键，不关联任何真正的维表。
我们在图6.1中使用符号DD来标识退化维度。
图6.1最细粒度的销售交易事实表在现实实践中，事实表一般都至少包含3个维度，而且绝大多数包含更多的维度。
由于过去的20年中，随着数据仓库以及相应的软、硬件技术的成熟，事实表技术有了很大的提高，可以存储越来越多的最细粒度上量测值。
越来越少的度量，越来越多的维度。
在最初的零售销售数据仓库中，数据集仅仅是粗粒度的聚合值。
这些早期的零售数据仓库通常只有3到4个维度（产品、市场、时间和促销）。
现在，我们搜集销售交易的原子级别的零售数据。
一个单独的销售交易中很轻易就包含了图6.1中的10个维度（日历日；产品；商店级别的现金帐簿；客户；员工；商店经理；价格范围；促销折扣；交易类型和付款方式）。
更多的时候我们还要在目前的基础上增加新的维度：比如商店人口统计学指标，市场竞争事件和天气！事实上，每个事实表都包含一组由表中的字段定义的主键。
在图6.1中，事实表一个可能的主键是由两个退化维度：发票号（Ticket number）和行号（LineNumber）组成的联合键。
这两个字段唯一的定义了出纳登记簿cashier register上的单个商品的度量事件。
另外一个可能的等价主键是时间戳和出纳登记簿cashier register的组合。
如果在设计的时候没有給于足够的注意，那么就可能违反事实表上主键的假设：可能在同一个时段两个同样的度量事件会发生，但是数据仓库团队却没有意识到这一点。
显然，每个事实表应该拥有一个主键，即使仅仅是出于管理的需要也应该在事实表设立主键。
如果没有主键完整性，那么事实表中有可能存在两个或者更多一样的记录，而且没有办法按照独立的量测事件来区分他们。
但是只要ETL团队保证单独的数据装载合理地表示唯一的量测事件，通过在装载时为数据增加唯一的序号就可以在事实表中唯一标识记录。
尽管唯一的序号和业务没有关联，而且不应该发布给最终用户，但是它在管理上保证了一个单独和可能的量测的发生。
如果ETL团队不能够保证单独加载表示的是合法的独立的量测事件，那么在数据加载的时候数据上必须已经正确的定义了主键。
前面的例子表明需要所有的ETL作业可以在发布或者发生错误时有再次运行的能力，以保证不会错误的更新目标数据库。
在SQL语法中，更新不变化的值通常是安全的，但是更新增量的值是危险的。
如果主键已经强制定义，那么插入是安全的，因为插入重复的值会触发错误。
如果限制是基于简单字段值，那么通常来说删除也是安全的。
确保参照完整性在维度模型中，参照完整性意味着事实表中的每个字段使用的是合法的外键。
换句话说，没有事实表记录包含了被破坏的或者未知的外键参照。
在维度模型中可能有两种情况会导致违反参照完整性：1. 加载包含了错误外键的事实表记录2. 删除了维表记录，而其主键在事实表中被使用。
如果没有注意参照完整性，那么就会非常容易破坏它。
笔者曾经研究了很多没有严格保证参照完整性的事实表；每个案例中都能够发现严重的冲突。
一个事实表记录违反参照完整性（记录中包含一个或者多个外键）不仅仅是讨厌，更严重的是这非常危险。
推想一下，一条合理的记录正确的记录了量测事件，但是不正确的存储在数据库中。
任何使用了坏维度的事实表查询将不能包含该记录，因为按照定义，维表和该事实表记录的关联不会发生。
但是在动态聚合中忽略该坏维度的查询结果却包含了这条记录。
在图6.2中，我们显示了在ETL过程中可以保证参照完整性的三个主要位置。
图6.2强制参考完整性选择1 在将事实数据加载到最终表之前，仔细的审核和准备数据，在删除任何维表记录之前，仔细地审核2 在每次事实表插入操作和每次维表删除操作动作发生时，使用数据库自己的参照完整性检查3 加载后对事实表进行扫描检查，以发现和更正有问题的外键，解决参照完整性冲突。
从实践角度来讲，第一个选择更加可行。
在数据加载到事实表中最后一步就是查找事实表记录中的自然外键，然后将他们替换成为维表中的代理键。
这个过程将在下一节代理键环节中仔细地介绍。
这个过程的核心是一个特殊的查找表，它包含了每一个外来的自然键所使用的代理键的值。
如果这张表被正确的维护，那么事实表中的记录将满足参照完整性。
同样在维表记录被删除的时候也需要尝试联结事实表和维表，只有在查询返回null的时候才能够删除该记录。
第二种选择利用数据库的参照完整性来检查的方法虽然很自然，但是在批量的加载成千上万条甚至几百万条记录的时候效率太低。
当然这只是一个软件技术的问题，如Reb Brick 数据库系统（现在IBM在销售）设计为在任何时候都维护参照完整性，它可以在1个小时内向事实表加载100万条记录，同时检查所有维度的参照完整性。
第三种在数据库更新完成后检查参照完整性的方法在理论上可以发现所有的冲突，但是花费的代价可能惊人的高，对参照完整性的检查需要使用：select f.product_keyfrom fact_table fwhere f.product_key not in (select p.product_key fromproduct_dimension p)在拥有几百万行产品维度数据，以及数亿行事实表纪录的环境中，这是一个荒谬的查询。
当然可以将查询仅仅限于当天加载的数据，但这需要假设时间维度的外键是正确的为前提。
但是使用第一种选择时，这种方法可以作为一种额外的检查。
代理键管道在建立事实表时，最终的ETL步骤是将新数据记录的自然键转化成正确的、当期的代理键。
在这节，我们假设所有的记录已经加载到事实表中。
换句话说，我们需要使用为每个维度实体（如客户或者产品）使用当前的代理键。
我们将在这章的最后处理迟到的事实记录。
我们理论上可以通过在每个维表中获取最新的记录来为自然键获得当前的代理键，这在逻辑上是正确的，但是很慢。
替代方法是为每一个维度维护一个专门的代理键查找表。
这张表在新的维度实体创建的时候或者记录在发生类型2缓慢变化维度2的更新的时候被更新。
我们在第5章讨论图5.16的时候介绍了这种表。
维表在插入或者缓慢变化维度2更新发生之后，在处理事实表之前，这个维表必须被完全的更新。
在更新事实表之前的维表更新过程是维护维表和事实表参照一致性的一般过程。
反向的过程在删除记录的时候发生，首先我们删除不需要的事实表记录，然后删除不再联结到事实表的维度记录。
不必因为事实表不再参照该记录而删除维表记录。
即使事实表中没有引用该维度实体，维度实体也可能需要存在或者保存在维表中。
当我们更新维表的时候，不仅仅要更新所有的维表记录，还要更新存储当期的数据仓库键和自然键关联关系的代理键查找表。
图6.3代理键管道我们处理新增的事实表记录的过程非常容易理解。
请看图6.3。
我们从新增事实表记录中获得每个自然键键值，然后替换成对应的当期代理键。
注意我们的提法：替换。
我们在事实表记录中并不保存自然键。
如果你关心具体的自然键值，你可以关联维表记录得到。
如果你有4到12个自然键，每个新增的事实表记录需要4到12个单独的查找表来获得正确的代理键。
首先，我们建立多线程的应用来流化所有的输入数据记录，使其通过图6.3中的所有步骤。
这里的多线程，指的是记录#1在完成连续的键查找和替换的同时，#2在后面进行相应的处理，我们并不在第一个查找步骤中处理所有的新增记录，然后将整个文件交给下一步。
在经过所有必要的处理过程后才将所有的记录写到磁盘意味着更高的效率。
在处理过程中应该尽量充分使用内存。
如果可能，所有需要的查找表应该常驻内存，以便每条事实表记录在处理它的自然键的时候随机访问。
这是将查找表从原始数据仓库维表中分离的一个原因。
假设对于某个维度，我们用上百万记录的查找表，如果自然键有20字节而代理键为4字节，我们需要24MB的内存来保存查找表。
在使用4-8GB内存的机器作为数据准备机data-staging的环境中，我们可以非常容易在内存中加载所有的查找表。
我们前面的讨论的架构是如何设计发挥最大性能。
如果你仅仅是每天加载几万条数据，而且装载窗口很大，那么你不需要强调这种级别的性能。
你可以定义事实表和维表的星型联结，将自然键转化成代理键，用SQL处理整个过程。
这种情况下，如果新增的数据不能匹配维度（参照完整性失败）你还可以对某些维度定义外联结。
可以在这种环境中使用程序工具awk，因为他支持在内存中使用自然键作为下标建立Array来完成自然键到代理键的翻译。
这样，如果你定义Translate_Dimension_A[natural_key] = surrogate_key，那么处理每一条事实表记录就非常简单：print Translate_Dimension_A($1), Translate_Dimension_B($2) 。
在一些重要的大事实表中，你可能会遇到不寻常的monster维度，例如居民客户，可能拥有上亿条记录。