标签：
数据仓库是基于特定的数据结构（以及有关应用程序）所构建的数据的中央存储库，以便为分析和报表提供
一致的数据源。面向整个组织创建的企业数据仓库（Enterprise Data Warehouse，EDW）用于对整个组织的信息
数据集成技术对数据仓库的功能来说是至关重要的，因此有些数据仓库专家将数据集成看成数据仓库架构技
术的一个子集。然而，数据集成对于其他数据管理领域来说同样重要，是数据管理活动的一个独立的部分
数据仓库数据流图
操作型应用层由来自不同数据源的数据组成，这些数据将要被装入数据仓库，它们来自组织中执行着主要的
操作型功能的应用系统。这一层是组织的核心应用系统组合所在的层次。操作型报表关注的是某个特定应用内部
的处理，因为与应用系统的用户特定的功能和需求相关，因此，这些报表可能保留在应用中。
外部数据
数据仓库中有些数据来自组织外部。提供给数据仓库的数据，更多详细的信息可能来自于组织的客户、供应
商或者其他合作伙伴。标准代码、有效值，以及其他参考数据则有可能来自于政府的数据源、行业组织或者业务
交换。而且，很多数据仓库中，通过购买有关客户的数据增强了组织内部数据的可用性。
外部数据必须通过网络和组织的一些安全访问层次，以保护组织远离有害数据和攻击。
进入数据仓库的数据通常会被暂存，或者存储为原来的数据格式，这样就可以在源和数据仓库之间的处理时
序上做到松耦合，即可以确定什么时候从源发送数据和什么时候将数据装入数据仓库。数据暂存区还可以就发送
的数据进行追踪和审计，有助于在数据仓库或者报表中发现问题时进行问题分析。
通常每个数据源中都会有一个暂存区，针对进入数据仓库的所有的数据也会有个暂存区。有些数据仓库架构
中还包含一个操作型数据存储（Operational Data Store，ODS），以实时或者准实时的方式为分析和报表提供数
据。
加载到数据仓库中的数据，根据其类型的不同有着不同的处理方式和生命周期。有些数据与事务型系统中的
数据保持同步，只追踪那些变化的数据，并将其传送到数据仓库中。而对另外一些类型的数据，则周期性地获取
整个数据集的“快照”，而不管有没有发生变化，每次都完全复制所有的数据并加载到数据仓库。
数据集成（即移动和转换数据）是如何与数据仓库相关联的？
构建数据仓库深层次的目标是创建一个企业级的平台，以在一个单一集成的环境中提供一个统一的数据视 图。在这个环境中的数据经过清洗、转换，为下游的应用做好准备。数据集成就是这个数据处理层，管理着所有
的这些活动，包括数据移动、质量管理以及转换。
数据集成中最复杂的活动之一就是将数据由一种格式转换为另一种格式，包括了清洗、标准化、优化，以及 元数据处理。
如果数据仓库中缺少数据集成层则必将导致重大的失败。这是因为，数据仓库中的数据可能集成度低、重 复，也可能根据每条业务规则处理多次。这样混乱的架构的最终结果就是数据仓库项目的失败。因此，数据集成 无论对于结构化还是非结构化数据仓库都是必不可少的一部分。
为何以及如何为数据仓库移动数据？
数据就是数据仓库的心跳。为了保证数据仓库中信息的时效性，需要持续不断地将各种不同应用系统中的数 据移动到数据仓库中。按照传统的做法，数据的处理过程分为收集、传输、清洗、优化，以及集成这么几步。用 于随机的移动和处理的技术有多种，包括：
·ETL：最常用的方法就是抽取、转换和装载，也叫做ETL（Extract，Transform，and Load）。不同的源系统 产生的数据被集中到一个称为暂存区的中间层（在某些操作型数据存储的设计中是可选的）进行处理。在暂存环 境下，对数据进行清洗和优化，这些是数据转换首先要进行的步骤，进一步的处理则在数据仓库中，如应用业务 规则和集成规则进行大规模转换。
·ELT：另外一个流行的方法就是所谓的抽取、装载和转换（Extract，Load and Transform，ELT）。数据从源 系统和数据库中被抽取出来，装入暂存区并进行清洗和优化，而在数据仓库中则进行和集成有关的纯粹的转换。 这个方法比较适用于以下这些场合，即数据比较灵巧、结构化非常好，以及集成的工作量很小。
·CDC：第三种技术叫做变化数据抓取（Change Data Capture，CDC）。在源系统上安装某个第三方应用程序 以收集数据的变化。这种方法通常需要从数据库日志中提取变化数据，并不会对源数据库系统带来负面影响，因 此比较高效。变化的数据从源系统中抽取出来，并传送到数据仓库中。在目标端，安装同样的第三方应用系统， 用于处理每个抽取过来的数据，并装入数据仓库的暂存区。然后，在这里对数据进行清洗、优化并转换到其在数 据仓库中的最终目的地。CDC在需要以近乎实时的方式处理数据、数据的可用性非常关键的场合非常有用。在某
些架构中，将会直接加载到操作型数据存储中，然后才会将其加载到数据仓库的暂存区。
还有很多基于以上3种技术的多种不同的定制化的变体，为了满足多个可能相互冲突的需求，保持数据仓库中 数据的时效性，常常综合使用多种方法。
对移动到数据仓库中的数据需要做哪些转换？（例如，不同的数据结构、确认数据结构、维度模型）
就数据仓库中的数据处理而言，可以有多种数据转换。最基本的转换就是从源系统中抽取数据，将其装入数 据仓库中一个集成的模型中，就是说将这些数据从一个高度规范化的结构转换为一个非规范化的或者维度结构。 转换过程包括：
·去规范化——将高度规范化的结构转换为非规范化的数据仓库格式。在使用自上向下或者Inmon方法进行
数据仓库构建时非常流行。
·维度化——将高度规范化的结构转换为维度和事实；数据仓库的自下向上方法或者Kimball星形模型。
·元数据处理——将一个业务词汇表以及数据一起加工到数据仓库中。把多个不同的术语融合进一个唯一的 定义中。
·主数据处理——对关键的数据结构进行转换，以和主数据集匹配，创建一个高度集成的数据层。
·生成代理键——使用一个通用的技术处理维度数据转换，以便在数据仓库中创建代理键以保存数据历史。
·编码数据——创建查找表和列表，对冗余数据进行压缩。
·旋转数据——使用多维度数据转换，以加载数据。
·分割数据——将多值列转换为单值列。
·合并数据——将数据集成到一个单一的表或者数据结构。
·查找数据——创建并优化查找表数据。查找表数据是一个参考库，数据的标识值被替换为实际值。
除了上述列出的数据转换外，还有一些数据模型和数据架构驱动的转换，数据需要经过多个不同层次的转 换，然后聚合，按层次钻取转换，以及语义转换形成后继的转换集合以便业务用户使用。
另外一个经常会被忽略的转换就是数据库驱动的转换，即将表进行垂直切割，分区为离散的结构，再经过索 引和排序，从物理存储上进行优化。
这些多种多样的转换就是在将数据移入数据仓库的过程中所要执行的操作。
将数据移入和移出数据仓库有何不同之处？
毫无疑问，它们之间有不同之处。当数据集成是将数据移动到数据仓库中时，所要考虑的是将数据进行集成 以便为业务用户或者其他用户所使用。向内的转换就是将类似联机事务处理（OLTP）的数据结构整合到数据仓库 模型中，这种模型大部分是面向维度的，或者至少要比联机事务处理的结构非规范化。
另一方面，从数据仓库中抽取数据给下游应用程序，则是为了满足特定的报表和分析需求。为了这个目的而 抽取的数据在布局和结构上是不同的。典型情况下，为了这个目的而抽取的数据包括转换后的数据结构以及所有 的参考数据、元数据副本、元数据以及特殊的数据（如空间数据）。在将数据抽取出数据仓库时，需要保持抽取 数据的参照完整性，正如将数据加载入数据仓库。这一点是和联机事务处理系统中的参照完整性不同的。
结构化数据和非结构化数据的数据仓库有哪些不同之处？数据集成是否也不同？
基于结构化数据的数据仓库有确定的生命周期。从需求定义开始，然后进行数据建模。在创建了数据模型之
后，就可以获取数据并进行转换以存储到这个模型中，为集成和进一步处理做好准备。这是一个读取效率比较高 的操作，由于可以明确定义最终的状态结构，因此在数据完成加载之后，从这个结构中读取数据是非常高效的。
基于非结构化数据的数据仓库是比较不确定的。因为在获取数据之前，很难预测数据类型、格式、结构，以 及数据的质量。通常是在对数据进行处理加工之后才会设计数据模型。因此，这种类型的数据处理又称为“无模 式的”。数据以文件的方式获取，以文件的方式加工处理。
在处理非结构化数据的过程中，所有的数据获取和加工都是在找到那些可以与数据仓库进行集成的元素之前 完成的。在这个过程中，从传统意义上说是没有数据集成的。但是从数据分析的角度看，依然是有数据集成的。
你有没有遇到过由于数据集成的问题导致重大问题的一些数据仓库项目？
当然遇到过，作为一个架构师和专业顾问，我亲眼目睹了在某些项目中，由于客户不能理解构建一个健壮的 数据集成架构的重要性而导致项目失败。在很多情况下，当数据仓库的架构师和经理要求就项目失败的原因给出 独立意见时，深层次问题分析的结果通常都指向不良数据集成架构。
拙劣的数据集成架构给数据仓库造成的影响，常见的有：
·数据质量问题
·单一列的多值问题
·日期和时间格式
·字符集和语言翻译
·Unicode支持方面的问题
·货币格式
不良数据集成架构通常会让某些设计良好的数据仓库折戟沉沙，导致部署失败和成本超限。
你有没有经历过数据仓库的数据集成中那些需要特别注意的地方？
是的，不少优秀的数据集成架构创造了这些数据仓库的成功故事。这些数据仓库的处理复杂度是第一优先级 的：必须7×24小时运行，并且有非常严格的性能要求。在如此紧迫的期限下，唯一可以做到在数据处理时不出故 障的方法就是设计一个灵活的可伸缩的数据集成架构。
这个架构令人映像深刻的地方就在于它可以对多个国家和多种语言的数据集进行处理，并纳入一个全局的数 据仓库，在这个数据处理架构中整合了数据优化、转换、传输和集成。某些客户还因为他们对高效数据集成设计 的坚持而被授予了最佳实践奖。
你没有没有经历过对数据集成不够重视的数据仓库项目？
在我以架构师或者顾问的身份参与的大多数项目中，都强调数据集成的重要性。某些情况下，客户会反对实 施一个完整的数据集成架构，这时，团队就不得不在实现数据仓库的时候面对诸多的障碍。结果就是，实施周期 要比原来预计的要长两到三倍，成本也是原来开发成本的三倍。
你认为向数据仓库中加载数据时是否应该有一个独立的暂存区？为什么？
毫无疑问，我支持数据仓库中需要一个暂存区。这种架构决策最主要的原因在于，将数据加载到数据仓库之 前，需要进行数据的获取和预加工，以及数据清洗。无论对于主动式或者实时数据仓库，还是具有确定维度的传 统的Kimball架构，如果没有一个独立的暂存区以进行复杂的数据集成活动，就很难真正实现数据仓库的可伸缩性 和灵活性。在我参与的绝大多数项目中，我总是构建和部署一个暂存区。
就元数据在数据仓库中的移动来说，有没有一些特殊的考虑，即如何将业务、操作型和技术型的元数据传输
到商务智能层，或者从商务智能层如何访问这些元数据？
元数据成为世界上百分之九十的数据仓库中忽略最多的部分。很多时候，由于有多个团队如业务分析、设 计、开发以及部署等，每个团队都指责其他团队没有很好地维护元数据。
以我之见，需要在数据仓库中开发不同类型的元数据。在需求分析阶段需要定义业务元数据，这些元数据会 实施在语义层和数据库视图中。技术元数据在数据加工、数据建模、物理数据库设计和商务智能层实施。对于商 务智能层，现今绝大部分软件包都提供了一个元数据集成层。
元数据必须随着数据本身在数据仓库的不同层次之间移动。没有这个架构实现，数据仓库一定会失败。事实 上，在实现非结构化数据集成时，元数据层是关键。
基于Web 2.0的数据架构高度依赖于元数据层，以实现对来自多个数据库的数据的集成和处理。
你认为人们在构建数据仓库时会忽略数据集成吗？为什么？
在很多情况下，数据仓库架构师、设计师和经理们认为架构和实施数据集成方案比较昂贵，因此他们会缩减 这方面的开发活动，最终会导致要花费两倍甚至更多的成本来完成数据仓库的开发。而且，人们会假设数据处理 工具可以自动处理数据集成的问题，因此往往忽略了对这个重要活动的计划。
哪些工具或者技术可以用于数据仓库的数据集成？
在一个典型的结构化数据处理架构中，ETL、ELT、CDC、面向服务架构（SOA），以及定制化开发的软件 包都可以用于移动数据；数据质量工具可以用于数据清洗；主数据管理工具可以用于参考数据加工；元数据参考 库可以用来管理元数据。
用于数据仓库数据集成的工具对于结构化和非结构化的数据来说是否相同？
是的。对于非结构化数据集成来说，用到的工具包括Hadoop、NoSQL数据库以及文本ETL引擎。某些传统的
数据集成商已经宣布支持非结构化数据集成，但仍然处于早期发展阶段。有些特殊的技术可以处理大量非结构化 而且拥有多种格式的数据。
你认为数据仓库领域会如何变化？你认为这个领域的发展方向是什么？
数据仓库概念已经存在很长时间了。但是，这个领域里正在快速发生的变化就是将非结构化数据集成到数据 仓库，以及将Hadoop包含进来作为联合的数据存储库，同时保留企业级数据仓库以处理复杂的数据分析。数据仓 库的未来将演变成基于关系数据库和非结构化架构的、以语义接口驱动的数据存储库，可以为来自企业用户的任 何查询提供答案。
你认为数据仓库技术，特别是和数据集成相关的技术正在发生变化吗？
是的，毫无疑问，数据集成技术正在变化以支持非结构化数据集成。这需要供应商社区付出巨大的工程开发 工作量。另外一个流行的技术就是使用数据可视化工具，为非结构化数据的预处理和分析创建一个数据发现的环 境。
标签：
原文地址：http://blog.csdn.net/sinat_29581293/article/details/51276934
