全新大数据最佳实践
Kimball 集团白皮书
作者：Ralph Kimball
与我们所熟知的文本和数值数据相去甚远，20 多年来，我们一直把这些数据存储在关
系数据库中并使用 SQL 分析它们。大数据的格式和内容很广，涵盖范围从非结构化
的自由文本一直到高度结构化的关系、矢量、矩阵、图像和名称-值对。
对系统的第一个巨大冲击在于，标准的关系数据库和 SQL 根本就不能存储或处理大数
据，并且正在接近基本能力和扩展的极限。不仅其数据格式超出了关系数据库的范围，
而且很多处理需要迭代逻辑、复杂分支和特殊的分析算法。SQL 是一种描述性语言，具
有强大却又固定的语法。大数据一般需要过程式语言以及任意新逻辑编程的能力。
对系统的第二个巨大冲击是摒弃了基于简单过滤和聚合进行分析的切片和切块报告。
报告、仪表盘和临时查询始终都非常重要，但利用大数据的最好方式是通过对海量未
过滤数据集进行梳理，此类数据集由历史和实时数据合并而成。
对系统的第三个巨大冲击是人们都认识到，随着延迟缩短、数据的更快交付，
大数据的价值会陡然升高。性能十倍百倍的提高造就了本质上不同的各种分析机会，而这些分析机会经常会转化为更高的营收和利润。
所有这些都促成了一个生机勃勃的由技术驱动的市场，这个市场两条主要的发展思
路：扩展关系数据库和 Hadoop。我在Informatica 赞助的白皮书中对这两种架构作
过深入的阐述。这两种架构都力求解决上面所列的大数据挑战。
大数据市场远未成熟，但是我们现在已经积累了数年的经验，有很多针对大数据的最
佳实践。本白皮书搜罗了这些最佳实践，并在追本溯源式的引经据典和针对单个工
具、不厌其烦的技术性繁枝末节之间，开辟一条中间路线。
重要的是要认识到，我们有一套为基于关系的企业数据仓库(EDW)开发的最佳实
践，这套最佳实践行之有效，大数据工作应该对此加以利用。我们将它们简单列出：? 由业务需求驱动 EDW 的输入数据源选择
? 对用户界面简单性和性能的不懈重视
下列 EDW 最佳实践尤其与大数据有关：
? 多维思考：将世界划分为维度和事实
? 将单独的数据源与一致性的维度集成
? 用渐变维度(SCD) 跟踪时变
? 通过持久的代理键锁定所有维度
在本文中我们将大数据最佳实践分为四大类：数据管理、数据体系架构、数据建模和
数据治理。
下列最佳实践适用于大数据环境的整体管理。
围绕分析而不是临时查询或标准报告来构造大数据。从原始源到分析师的屏幕，数据通路中的每一步必须支持复杂分析路线，这种分析路线或者作为用户定义函数 (UDF)，或者通过一种可为每种类型的分析编程的元数据驱动开发环境实施。这包括加载器、清洗器、集成器、用户界面和最终的商业智能工具。这种最佳实践并不建议废弃现有的环境，而是将其扩展来支持新的分析需求。见下文中的体系架构最佳实践部分。
现在不要尝试建立遗留的大数据环境。当前的大数据环境变化迅速，因此还不是考虑构建长久基础的时候。相反，要规划方方面面颠覆性的变化: 新的数据类型、竞争性的挑战、编程方法、硬件、网络技术和数以百计的全新大数据提供商所提供的服务。
在可预见的将来，需要保持几种实施方法之间的均衡，其中包括 Hadoop、传统的网格计算、RDBMS 的下推优化、内部计算、云计算甚至大型机。这些方法中没有一种将在这场长跑中成为唯一的赢家。平台即服务 (PaaS) 提供商提供了引人注目的选项，可以帮助您组成一套兼容的工具。与此类似，很多系统体系结构和编程可在具体部署选择之上的层面上指定，这正是元数据驱动开发环境的鲜明优势。
示例：在Hadoop 环境中使用HCatalog 提供一个具体存储位置和数据格式之
上的抽象层。举例来说，这就允许Pig 脚本在位置和格式变更时保持不变。
示例：将Hadoop 看成一个用于很多形式ETL 处理的灵活、通用的环境，目标是向大数据加入足够的结构和上下文，使其能够加载到RDBMS 中。Hadoop
中相同的数据可使用各种各样的语言编写的Hive、Pig、HBase 和
MapReduce 代码访问和转换，访问和转换甚至同步完成。
最要紧的是，这需要灵活性。假定您要在两年内重新编程并重新移植所有的大数据应用程序，请选择可进行重新编程和移植的方法，并考虑使用一种元数据驱动的无代码
开发环境，以提高生产率，并与底层技术变化隔离。
编程环境构造数据实验和原型。然后，在概念得到证明后，由“IT 接管团队”系统性
地改编程序和/或配置这些实施。
示例：您进行客户分析编程的生产环境可能是PostgreSQL 中的MatLab 或
Teradata RDBMS 中的SAS，但是您的数据科学家可能用各种各样他们偏好的
语言和体系架构来构建概念证据。先见之处在于：IT部门必须一反常态地不去
计较数据科学家使用的技术，并且要时刻准备着使用一套长远来看能够得到支
持的标准技术，来重新实施数据科学家的工作。
示例：您的沙盒开发环境可能是ETL 转换和直接访问Hadoop 的R 代码的组
合，但是由Informatica PowerCenter 控制。然后，当数据科学家准备好移交概
念证据时，大部分逻辑可以在PowerCenter 下立即重新部署，在网格计算环境
中运行，这是一种可扩展、高度可用并且安全的环境。
先从简单大数据应用程序试起：备份和存档。在准备开始大数据程序时，在寻找有价
值同时风险不高的业务用例时，以及在汇集必备的大数据技能时，可以考虑使用
Hadoop 作为一种低成本、灵活的备份和存档技术。Hadoop 可存储和检索所有格式的
数据，范围从完全非结构化到高度结构化的专用格式。这种方法还让您能够解决“日
落”问题，其中原来的应用程序在不久的将来可能不可用 (可能因为许可限制)，但是
您可以将这些应用程序内的数据转储为自己的记录格式。最后请记住，即使是
Hadoop 也会消耗资源和成本——所以只要用 Hadoop 存储数据时，都应该事先考虑
数据保留，这样 HDFS 文件夹和数据集在保留期满时就能被清除或很方便地以更低存
储成本在 HDFS 之外存档。
大数据体系架构最佳实践
下列最佳实践影响大数据环境的总体结构和组织。 用延迟依次增加的多个缓存规划逻辑上的“数据高速公路”。物理上仅实施适应您环境的缓存。数据高速公路最多可以有五个数据延迟依次增加的缓存，各有其独特的分析优势和不足：
* 原始源应用程序：信用卡诈骗探测、包括网络稳定性和网络攻击探测在内的瞬时复杂事件处理 (CEP)。 * 实时应用程序：网页广告选择、个性化降价促销，网络游戏监视、各种形式的预测和主动监控。 * 业务活动应用程序：向用户推送的低延迟 KPI 仪表盘、故障单跟踪、过程完成跟踪、“融合”CEP 报告、客户服务门户和仪表盘以及移动销售应用程序。 * 一线应用程序：战术报告、促销跟踪、基于社交媒体动向的中途修正。“一线”指的是高级经理审核企业24小时内所发生的主要事务的通常实践。 * EDW 和长时间序列应用程序：所有形式的报告、临时查询、历史分析、主数据管理、大规模的时间动态和马尔可夫链分析。 存在于给定环境中的每种缓存都实际存在，并与其他的缓存有明显的区别。数据通过 ETL 进程从原始源开始沿这条高速公路一路向下。从原始源到各中间缓存有多种路径。例如，数据可能进入实时缓存来驱动零延迟式用户界面，但同时被直接提取到看起来像是典型操作型数据存储 (ODS) 的日常一线缓存。随后，来自这个 ODS 的数据可以输入到 EDW 。数据同样还会沿高速公路反方向流动。见下面的“实施回流”。 沿这条高速公路传输的很多数据必须保持非关系型格式，其范围从非结构化文本一直到复杂的多结构化数据，如图像、数组、图形、链接、矩阵和名称-值对集。 使用大数据分析作为“事实提取器”，将数据移动到下一个缓存。例如，对非结构化推文的分析可以产生一整套数值和趋势型的情绪测量值，包括语音共享、观众参与、对话范围、主动倡导、倡导的影响、宣传的影响、解决率、解决时间、满意度评分、主题趋势、情感比和思想影响。同样还有 Splunk ，一种为很多形式的非结构化机器数据标引以及从中提取特征的技术；Kapow ，一种从博客、论坛、网站和门户网提取多原始源 (瞬时) 实时缓存 (数秒) 业务活 动缓存 (数分钟) 一线缓存 (24 小时) EDW 和长时间序列 (每日、定期、每年)
非结构化文本文件、多结构化 XML 文件和 web 日志以及市场数据、SWIFT、FIX、CDR、HL7、HIPAA 等等各种工业标准结构中提取事实和维度。
使用大数据集成构建一个全面的生态系统，将常规结构化RDMS 数据、电子邮件和内
部以业务为导向的社交网络集成在一起。大数据透露出的强有力信息之一是能够集成
模式各不相同的数据源。我们正在从社交网络、移动设备和自动警报流程这样的新数
据生成渠道获取数据流。想象一下，一家大型金融机构正在应对数以百万计的账户、
以千万计的相关纸质文件，以及数以千计的组织内专业人员 (同时又是该领域中的合作
方或客户)。现在建立一个所有信任方的安全“社交网络”，在开展业务的同时进行沟
通。这种沟通很多都非常重要，应该以可查询的方式加以保存。在Hadoop 中捕捉所
有这种信息，确定其维度 (见下面的建模最佳实践)，在业务过程中加以使用，然后将
其备份和存档。
作出规划让数据质量沿数据高速公路越来越佳。这是典型的延迟和数据质量的取舍问
题。分析师和业务用户必须接受这个现实，那就是延迟非常低(即瞬时) 的数据不可避
免的会“脏”，这是因为在非常短的时间间隔中能完成的清洗和诊断有一定限度。单
独字段内容的测试和修正可以在最快的数据传输速度下进行。多个字段中以及数据源
之间结构型关系的测试和修正必定更慢。测试和修正涉及复杂的业务规则，其范围从
瞬时(如一组日期是否按特定顺序) 到花去任意长的时间 (如等着看异常事件的阈值是
否已被超过)。最后，更慢的ETL 进程，输入日常一线缓存的进程通常建立在从根本上
来说更完整的数据上，例如将不完整的交易集和拒付交易删除。在这些情况下，瞬时
数据源根本就没有正确信息。
在尽可能早的接触点应用过滤、清洗、修整、遵从、匹配、合并和诊断。这是上述各项
最佳实践的必然结果。数据高速公路上的每一步都提供更多的时间增加数据的价值。过滤、清洗和修整减少了传输到下一个缓存的数据量，消除了无关或受损数据。说句老实话，有一种流派就主张仅在分析运行时间应用清洗逻辑，因为清洗可能删除“有趣的异常值”。遵从则采取积极步骤将高度管理下的企业属性放入客户、产品和日期这样的主要实体。这些遵从属性的存在允许了跨越不同应用程序域的高价值合并。这个步骤简化的含义就是“集成！”诊断允许将很多有趣的属性加入数据，包括特殊的自信度标签和代表数据挖掘专业人员识别出的行为集群的文本标识符。数据发现和探查有助于识别数
据域、关系、搜索的元数据标签、敏感数据以及数据质量问题等。
和日期等高度管理下的主维度应反过来与较早的缓存连接在一起。理想情况下，需要
的只是所有缓存中这些实体的唯一持久键。这里的必然结果就是，从一个缓存到下一
个的每个 ETL 步骤中，头等大事就是用唯一的持久键替换特异性的专用键，这样每个
缓存中的分析可以只需通过连接唯一的持久键就对丰富的上游内容加以利用。甚至能
够当原始源数据传输到实时缓存时不到一秒的时间内实施这种 ETL 步骤？
维度数据不是高速公路上向源方向回传的唯一数据。历史摘要和复杂数据发掘结果等
在事实表中派生的数据可以打包成简单的指标或总数——然后传输到数据高速公路上
更早的缓存中。最后，有用的键或码等参考链接可被嵌入低延迟数据缓存中，以便允
许分析师通过单击链接到其他相关数据。
在所选的数据流中执行流数据分析。对低延迟数据的一个有趣的角度是需要在数据流
入但是数据传输进程可能远没有最终结束前开始数据上的认真分析。人们对流分析系
统有很大的兴趣，该系统允许类似 SQL 的查询在数据流入系统时对其进行处理。在一
些使用案例中，当流查询的结果超过阈值时，分析可能中止，不会让作业运行到底。
被称为连续查询语言 (CQL) 的一项学术工作在定义流数据处理要求方面取得了令人瞩
目的进展，其中包括流数据上动态移动时间窗口的巧妙语义。在加载程序中为 RDBMS 和 HDFS 部署的数据集寻找 CQL 语言扩展和流数据查询功能。理想的实施会使数据以每秒吉字节加载时的流数据分析得以实现。
在可扩展性上设置长远限制以避免“边界崩溃”。在计算机编程早期，计算机的硬盘
和物理内存都小的可怜，边界崩溃司空见惯，是应用程序开发的克星。应用程序用完
磁盘空间或物理内存时，开发人员必须求助于精心设计的手段，这些手段通常需要大
量与应用程序主要内容无关的编程工作。对于一般的数据库应用程序来说或多或少都
已经消除了边界崩溃，但是大数据又让这个问题浮出水面。Hadoop 是一种使编程可扩
展性问题大大降低的体系架构，这是因为人们在大多数情况下可以无限制添加商品硬
件。当然，即使是商品硬件也必须进行配置、插入并且还要有高带宽的网络连接。教
训就是规划要非常超前，为巨大的容量和吞吐量留足空间。
在公共云实施大数据原型开发，然后转移到私有云。公共云的优势在于其可以即时提
供和扩展。这样的例子包括 Amazon EMR 和 Google BigQuery。对于有的案例，其
数据敏感性允许原型开发快进快出，在这种情况下这样做可能非常有效。只是要记住
不要在程序员回家过周末的时候还把海量数据集留在网上的公共云提供商那里！但是
请记住，在某些情况下，在试图通过机架感知 MapReduce 进程对数据局部性加以利
用时，可能无法使用公共云服务，因为它们可能不会提供你所需要的数据存储控制。
大数据市场的开放性催生了数以百计针对特定分析类型的专用紧密编码解决方案。这
是一个巨大的福音，也是一个魔咒。一旦不被大供应商的RDBMS 优化工具和内部循
环所左右，聪明的开发人员就可以实施真正百倍高于标准技术的局部解决方案。例
如，在出了名的“大合并”问题上已经有了一些令人印象深刻的进展，在这个问题中
要将一亿行的维表加入到一万亿行的事实表中。例如雅虎处理海量数据集上稀疏连接
的方法以及谷歌的Dremel 和BigQuery 项目。魔咒在于这些单独的局部解决方案还
游离在统一的单一体系架构之外。
大数据一个非常明显的主题就是数据集的可视化。拍字节数据“飞来飞去”需要惊人
的性能!大数据的可视化是一个激动人心的新开发领域，能够分析和发现意想不到的功
能以及进行数据探查。
另一个激动人心的应用领域是没有预聚合的语义缩放，这种应用也提出了巨大性能需
求，其中分析师从高度聚合的层次上走下来，逐步进入非结构化或半结构化数据更详
细的层次，这很像在地图上放大。
这种最佳实践背后的重要一课是，在我们使用和分析大数据的能力上，革命性的进步
将来自于10 倍到100 倍的性能提升，我们必须准备好将这些发展加入我们的工具套
件中。
将大数据分析工作量与常规EDW 分开，以保持EDW 服务层协议。如果你的大数据
在Hadoop 中托管，就有可能不会与基于RDBMS 的常规EDW 争夺资源。但是要留
心你的大数据分析是否在EDW 计算机上进行，因为大数据要求向着需要更多计算资
源的方向势不可挡地迅速变化。
利用数据库内分析的独特功能。主要的RDBMS 参与者都对数据库内分析方面进行了
巨大的投入。一旦你付费将数据加载到关系表中，SQL 可以通过非常强大的方式与分
析扩展相结合。最近的著名数据库内进展包括IBM 收购Netezza 和SPSS、Teradata 和Greenplum 嵌入SAS、Oracle 的Exadata R Enterprise 和PostgreSQL 用于编程分析的语法，以及其他具有数据库内循环的任意函数。所有这些选件使数以百计分析例程的测试库可供使用。一些数据集成平台提供下推优化，利用
数据库内分析作为数据流或ELT 进程的一部分。
下列最佳实践影响数据的逻辑和物理结构。
多维思考：将世界划分为维度和事实。业务用户发现，维度的概念非常自然和明显。不管是什么格式的数据，总是能够找到基本的关联实体，如客户、产品、服务、地点或时间。在下面的最佳实践中，我们将看到如何通过制定少量规则，将维度用于集成数据源。但是在我们到达集成终点线之前，必须要识别每个数据源中的维度，并把它们附加到每个低等级的基本数据观察值上。这种维度化的过程就是大数据分析很好的一种应用。例如，一句Twitter 的推文“哇！真棒！”看起来可能并不包含任何值得维度化的东西，但是通过一些分析，我们经常可以得到客户(或市民或患者)、地点、产品(或服务或合约或事件)、市场情况、提供商、天气、队列组(或人口统计学集群)、会期、触发前事件、最终结果，不胜枚举。为了始终跟进高速数据流，需要有某种形式的自动维度化。正如我们在随后的最佳实践中指出的那样，传入的数据应在最早的提取步骤完全维度化。
将单独的数据源与一致性的维度集成。一致性的维度是将孤立的数据源粘合在一起的胶水，这样它们就可以合并在单一的分析中。一致性的维度可能是来自传统EDW 世界最强大的最佳实践，大数据应该加以继承。
一致性维度背后的基本思想是在与孤立数据源相关联的各种版本的维度中存在一个或多个企业属性(字段)。例如，企业中每个面向客户的流程都会有一些客户维度的差异。这些客户维度的差异可能有不同的键、不同的字段定义甚至不同的粒度。但是即使在不兼容数据的最坏情况下，一个或多个可定义的企业属性都可以被嵌入所有客户维度变化中。例如，客户人口统计学类别就是一个言之成理的选择。这种描述符可以附加到几乎每种客户维度上，即使在更高的聚合层次上也是如此。完成了这一项工作后，就可以通过对不同数据源上单独运行查询后的简单排序-合并进程，跨每个参与数据源进行这种客户人口统计学类别上的分组分析。最重要的是，将企业属性引入到单独数据库的步骤可以通过一个渐进、灵活和非破坏性的方式完成，如同我在Informatica 赞助的白皮书中针对这个主题的详细说明。在一致性维度内容推出时所有现有分析应用程序将继续运行。
通过持久的代理键锁定所有维度。如果我们在EDW 世界中有经验教训的话，那就是不要将客户、产品和时间等重要实体用具体应用程序定义的“自然键”锁定。这些自然键最终被证明是一个陷阱，是真实世界中的错觉。它们在不同应用程序间互不兼容，很难管理。每个数据源中的第一个步骤是用企业范围内的持久代理键扩充来自数
据源的自然键。持久意味着没有业务规则能够更改这个键。持久键属于IT 部门，并不
一性的鲁棒哈希算法生成。隔离的代理键没有应用程序内容。它仅仅是一个标识符。 大数据世界充斥着显而易见的维度，它们必须要有持久代理键。在前文中，我们建议将数据沿数据高速公路反向推回时提到，我们依赖于持久代理键的存在而使这种过程得以实现。我们还说过，每次从原始数据源进行数据提取的头等大事就是在适当的维度嵌入持久代理键。
迎接结构化和非结构化数据的集成。大数据极大地扩大了集成的挑战。很多大数据将
永远不会在关系数据库中终结；而是将留在Hadoop 或网格中。但是我们一旦用一致
性维度和持久代理键武装起来，所有形式的数据都能合并在单一的分析中。例如，医
学研究可能选取一组具有特定人口统计学和健康状态属性的患者，然后将他们的常规
EDW 型数据与图像数据(照片、x 线、心电图)、自由文本形式的数据(医生接诊记
录)、社交媒体情绪(对治疗的看法) 以及队列组联系(有类似情况的患者)。
在体系架构上讲，这种集成步骤应在查询而非数据加载和构建时进行。执行这种集成
的最灵活方式是通过数据虚拟化，其中的集成数据集看似物理表，但实际上是类似关
系视图的规格，其中的独立数据源在查询时连接在一起。如果没有数据虚拟化，最终
的商业智能层必须完成这种集成步骤。
用渐变维度(SCD) 跟踪时变。跟踪维度的时变是来自EDW 世界的一种长期以来备受
推崇的最佳实践。从根本上讲，它兑现了我们所做的准确跟踪历史的承诺。将当前的
客户 (或市民、或患者、或学生) 资料和陈旧的历史相关联是绝不能接受的。最差的情
况下，当前的资料应用到旧历史时会错的离谱。用渐变维度 (SCD) 处理有三种形式。
第一种类型的SCD 在发生改变时覆盖资料，因此丢失了历史。我们在纠正数据错误时
可能这样做。第二种类型的SCD 是最常使用的技术，在发生改变时生成一个修订后的
维度记录。第二种类型的SCD 要求在我们生成新维度记录时保留持久代理键作为将新
旧记录结合在一起的粘合剂，但是我们还必须为维度成员的快照生成一个唯一的主
键。和一致性维度类似，这种流程得到了很广泛的描述和审查。最后是第三种类型的
SCD，这种类型不像其他两种那样常见，其涉及定义了与当前现实共存的“备用现
实”的情况。请参阅我对SCD 的介绍性文章以及我的著述中大量涉及SCD 的内容。
但是，就大数据而言，要点是将重要实体正确的当前资料和历史关联在一起，其重要
性正如已在EDW 世界中加以证明的一样。
要习惯在分析时间前不去声明数据结构。大数据的魅力之一就是在加载到Hadoop 或
数据网格时推迟声明数据结构。这带来了很多优势。数据结构在加载时可能不清楚。
数据可能有变化多样的内容，用单一的数据结构可能或者没有意义，或者会强迫你修
改数据来适合结构。举例来说，如果能不声明数据结构就将其加载到Hadoop 中，就
同的数据。当然，在某些情况下会需要付出代价，因为未声明结构的数据可能很难或
不可能像在RDBMS 中那样编索引进行快速访问。但是，大部分大数据分析算法可处
理整个数据集，并不期望数据子集的精确过滤。
这种最佳实践与传统的RDBMS 方法论相抵触，后者着重强调在加载前对数据进行细
致建模。但是，这并不会导致致命的冲突。对于发往RDBMS 的数据，从Hadoop 或
数据网格环境以及从名称-值对结构传输到RDBMS 命名列可以认为是一个有价值的ETL 步骤。
围绕名称-值对数据源构建技术。大数据源总是充斥让人惊奇的内容。在很多情况下，
你就像打开了消防水龙头，发现喷涌出来的是意料之外或没有记录的数据内容，无论
如何你必须以每秒吉字节的速度加载。从这个问题脱身的方法就是将这样的数据作为
简单的名称-值对加载。例如，如果申请人披露其金融资产，他们可能会声明一些出乎
意料的东西，例如“珍品邮票= $10,000”。在名称-值对数据集中，加载将从容进
行，即使你在加载时从来没有见过“珍品邮票”，也不知道该拿它怎么办。当然，这
种做法与前述将声明数据结构推迟到加载时间后的做法协调得很好。 MapReduce 编程框架需要数据用名称-值对表示，鉴于大数据完全可能的一般性，完全有道理这样做。
使用数据虚拟化实现快速原型开发和方案变更。数据虚拟化是一种声明底层物理数据
上不同逻辑数据结构的强大技术。SQL 中的标准视图定义是数据虚拟化的一个很好的
例子。数据虚拟化在理论上可按分析师所需的任何格式显示数据源。但是数据虚拟化
只是以运行前构建物理表的ETL 开销取代了运行时的计算开销。数据虚拟化是一种开
发数据结构原型和实现快速变更或提供不同备选方案的强有力方式。最好的数据虚拟
化策略是预期在虚拟架构已通过测试和审核，并且分析师希望提高实际物理表性能之
后对其进行实体化。
大数据的数据治理最佳实践
下列最佳实践适用于将数据作为宝贵的企业资产进行管理。
并不存在所谓的“大数据治理”。您需要牢记的是，数据治理必须是用于整个数据生
态系统的全面方法，而不仅仅是用于大数据的局部解决方案。大数据的数据治理应该
是所有企业数据治理方法的延伸。关于必须怎样通过将大数据与其他现有形式的数据(尤其是来自EDW 中的数据) 集成对大数据进行改进，我们已经提供了令人信服的用例。但是成功集成的同时单独为大数据建立(或忽略) 数据治理会造成巨大的风险数据
治理至少包含隐私性、安全性、合规性、数据质量、元数据管理、主数据管理以及向
列表，IT 部门在取得来自管理层的重要和深入支持之前，不应贸然从事——管理层必
须了解采取措施的范围并支持必要的企业跨组织合作。
应用治理前使数据维度化。这是大数据带来的一个有趣的挑战：甚至在你不知道数据
有哪些内容时就必须应用数据治理的原则。你将以高达每秒吉字节的速度接收到达的
数据，这些数据通常是名称-值对的形式。通过数据治理责任非常重要的方式进行数据
分类时，你最好的机会就是在数据管道的最早阶段尽可能充分实现维度化。在动态中
解析数据、匹配数据并应用身份识别。我们在主张数据集成的优势时持相同的观点，
但是在这里我们倡导不要在这种维度化步骤之前使用数据。
如果分析数据集包括识别有关个人或组织的信息，在使用任何包含有关个人或组织信
息的大数据集时，个人隐私就是治理最重要的一方面。尽管数据治理的每个方面看起
来都至关重要，但是在这些情况下隐私承载了最多的责任和最大的业务风险。侵犯个
人或团体隐私的丑闻可能损害你的声誉、削弱市场信任、使你卷入民事诉讼并承受相
关制裁。这些危害同时可能是在公司、机构、第三方甚至组织内部共享丰富数据集的
障碍，严重限制大数据可在医疗保健、教育和执法等行业发挥的功能。我们有权访问
的海量个人信息很可能会让我们的感觉迟钝，警惕放松。对于大多数形式的分析来
说，至少必须将个人详细资料屏蔽掉，并将数据聚合到足以无法识别个体的程度。请
注意，如果将敏感数据存储在Hadoop 中，在这样的写入时必须特别加以注意，因为
一旦把数据写入Hadoop，Hadoop在管理更新方面就做得不是很好——所以或者应将
数据屏蔽或写入时加密 (即持续数据屏蔽) 或应在读取时屏蔽数据 (即动态数据屏蔽)。 不要因为急于使用大数据就将数据治理完全抛开。即使是试探性的大的数据原型项
目，也要准备问题清单，在向前推进时考虑周详。你不想要一个无效的机构，但或许
你可以努力实现一个灵活的机制！你需谨慎保持的清单应该包括：
? 验证是否有一种构想和业务案例来提供方向和优先事项。
? 确定人员职责，包括数据管理员、赞助商、程序推动者和用户。
? 验证组织赞同和跨组织的指导委员会以及赞助以支持上报和优先事项。
? 限定现有和所需的工具及体系架构，为进行管理的大数据生命周期提供支持。
? 加入一些数据使用政策和数据质量标准的概念。
? 在这个清单上的所有其他要点都采用轻量级的组织变更管理。
? 测量结果、运营以及业务价值投资回报率。
? 评估和影响上下游相关流程，以尽量减少无时不在的垃圾输入/垃圾输出的窘境。
大数据为IT 部门带来很多变化和机遇，同时也需要IT部门建立一套新的规则。但是受益于近十年的经验，已有许多最佳实践涌现出来。可以看出这些实践中很多是企业数据仓库/商业智能的扩展，当然还有不少是有关数据和IT 部门任务的新颖奇特的思考方式。对任务已扩大的认知是件好事，在某些方面这一认知却是姗姗来迟。当前数据收集渠道、新数据类型和新分析机会的爆炸式增长，意味着最佳实践的列表将会以有趣的方式继续增长。
致谢
十分感谢下列大数据专家，很荣幸在本白皮书撰写过程中与他们探讨。以下按组织名称的字母顺序排列：
EMC：Bill Schmarzo
Fannie Mae：Javed Zaidi
美国联邦航空管理局：Wayne Larson 及其同事
Informatica：John Haddad, Robert Karel
摩根大通：Tom Savarese
Kimball 集团：Margy Ross
默克：John Maslanski
Rackspace：Pete Peterson
VertiCloud：Raymie Stata
雅虎：George Goldenberg
Informatica 赞助的Kimball 大数据和Hadoop 白皮书：
https://www.doczj.com/doc/bb7835172.html,/?elqPURLPage=8808
Informatica 赞助的Kimball 一致性维度和集成白皮书：
https://www.doczj.com/doc/bb7835172.html,/?elqPURLPage=807
Kimball 关于渐变维度的介绍性文章：
https://www.doczj.com/doc/bb7835172.html,/2008/08/21/slowly-changing-dimensions/
https://www.doczj.com/doc/bb7835172.html,/2008/09/22/slowly-changing-dimensions-part-2/
雅虎应对大合并挑战的方法：
https://www.doczj.com/doc/bb7835172.html,/Hadoop_Summit/yahoo-display-advertising-attribution 无预聚集的语义缩放演示稿：
https://www.doczj.com/doc/bb7835172.html,/Hadoop_Summit/empowering-semantic-zooming-with-
hadoop-and-hbase
2012年2月1日 Oracle数据库的一些基本概念 –数据库安全 ?用户：数据库中的用户，用于组织和管理数据库对象的。通常一个应用软件的数据库对象被存放在一个数据库用户下。使用数据库用户连接数据库后，可以对这些数据库对象进行操作 ?方案：一组数据库对象的集合。一个方案对应一个唯一的数据库用户，方案名和用户名完全相同。在访问数据库对象的时候，可以才用“方案名.对象名”的方式进行访问 ?权限：权限决定了数据库用户在数据库中可以作什么。如果用户没有权限，那么对数据库就不能进行任何操作。权限由高权限用户授予 ?角色：一组命名的权限，用于简化对权限的管理操作。可以一次将多个权限（一个用户的权限）授予一个或多个用户–数据库文件与存储： ?数据文件：用于存放数据的操作系统文件。数据库包含一个或多个数据文件 ?表空间：数据被存储在文件中，但是在数据库中数据文件组织在一起，被按照表空间的方式来进行管理。表空间是一个或者多个数据文件的集合，在数据库中的存储空间表现为表空间，在操作系统中表现为数据文件。一个数据库包含一个或多个表空间 ?控制文件：数据库的核心文件，存放着数据库的重要信息。 例如数据库的名称和数据库的结构（数据文件，重作日志文件的名称和目录） ?重做日志文件：记录数据库中数据变化的文件。所有数据的修改都被记录在日子文件中，主要用于保证数据库的可恢复性?初始化参数文件：存放数据库初始化参数的文件。用于设置
关于数据库的一些参数，在数据库启动的时候需要读取，并根据初始化参数的设置分配数据库的内存空间 –数据库网络访问： ?数据库名：数据库的名称 ?实例名：数据库的内存区域和后台进程集合的总称 ?服务名：数据库在操作系统上被当作一个服务对待 ?连接字符串：通过网络访问远端服务器上的数据库时，用于描述数据库访问地址的字符串。通常的结构是：“主机名（或IP):端口号:服务名”，例如：192.168.2.200:1521:orcl ?监听器：在服务器端运行的一个进程。用于监听客户端到数据库的连接请求。在通过网络访问时必须启动 表中的常用字段类型 ?Char(n) 定长字符串 ?Varchar2(n) 变长字符串 ?Varchar(20) 变长字符串 ?Number(m,p) 数字类型 ?Number(m) 数字类型 ?Date 日期类型 ? ? Sql语句分类 –Select查询语句 –DML语句（数据操作语言） Insert / Update / Delete / Merge –DDL语句（数据定义语言） Create / Alter / Drop / Truncate –DCL语句（数据控制语言） Grant / Revoke –事务控制语句 Commit / Rollback / Savepoint –WHERE子句在FROM 子句后 SELECT last_name, job_id, department_id FROM employees WHERE last_name = …KING'; –使用ORDER BY 子句将记录排序 ASC: 升序,缺省 DESC: 降序 –ORDER BY 子句出现在SELECT语句的最后 SQL> SELECT last_name, job_id, hire_date 2 FROM employees 3 ORDER BY hire_date; SQL> SELECT last_name, job_id, hire_date
1Informatica概述 (3) 2安装Informatica8.6.1 (3) 2.1服务端安装 (3) 2.2客户端安装 (7) 3配置管理服务器 (9) 3.1创建知识库和集成服务 (9) 3.2客户端到集成服务端的连接 (12) 4PowerCenter Designer学习 (13) 4.1概念和基本定义 (13) 4.2Mapping设计和组件的使用 (15) 4.2.1实例一：聚合抽取 (15) 4.2.2实例二：取TOP前三条记录 (16) 4.2.3实例三：抽取XML源 (19) 4.3WorkFlow的设计和使用 (20) 4.3.1创建Session (20) 4.3.2设计WorkFlow (22) 4.4Repository Manager (23)
1 Informatica概述 Informatica一直致力于为客户提供具有强大的元数据管理、数据集成和个性化分析递送功能的世界通行标准的统一数据服务平台。Informatica的基础设施产品以可伸缩的、可扩展的企业级数据集成平台为特点，并广泛支持来自Informatica和其他的领先商务智能提供商的数据仓库基础设施和分析型应用软件的开发和管理，提供元数据管理解决方案，帮助企业集成、优化、审核信息资产以提高运营效率，增加客户收益，取得竞争优势。 详见文档： 2 安装Informatica8.6.1 这里以Informatica8.6.1为例： 2.1 服务端安装 找到安装目录pc861_win32_x86.zip\Server\Windows\Disk1\InstData\VM下 点击安装
Informatica所有的元数据信息均以数据库表的方式存到了元数据库中。当然Infa本身工具提供了很多的人性化的功能，使我们在开发时可以很方便的进行操作，但人们的需求总是万变的，需要方便的取到自己需要的信息，那就需要我们对他的元数据库有很深的了解。 Informatica所有的元数据信息均以数据库表的方式存到了元数据库中。当然Infa本身工具提供了很多的人性化的功能，使我们在开发时可以很方便的进行操作，但人们的需求总是万变的，需要方便的取到自己需要的信息，那就需要我们对他的元数据库有很深的了解。Informatica通过表和视图给我们提供着所有的信息，在此将通过一个系列的帖子，将大部分常见的，且非常有用的表及视图介绍一下。基于这些东西，我们即可以根据不同的需求查出自己需要的数据，也可以开发一些辅助的Infa应用程序。 ///////////////////////////////////////////////////////////////////////////// OPB_ATTR : INFORMATICA (Designer,Workflow等)设计时及服务器设置的所有属性项的名称，当前值及该属性项的简要说明 例如： ATTR_NAME: Tracing Level ATTR_VALUE: 2 ATTR_COMMENT: Amount of detail in the session log 用途：可以通过该表快速查看到设计或设置时碰到的一些属性项的用途与说明 OPB_ATTR_CATEGORY: INFORMATICA各属性项的分类及说明 例如： CATEGORY_NAME: Files and Directories DESCRIPTION: Attributes related to file names and directory locations 用途：查看上表所提的属性项的几种分类及说明 OPB_CFG_ATTR: WORKFLOW MANAGER中的各个Folder下的Session Configuration的配置数据，每个配置对应表中一组Config_Id相同的数据，一组配置数据共23条 例如： ATTR_ID: 221 ATTR_VALUE: $PMBadFileDir 用途：查看所有的Session Configuration的配置项及值，并方便的进行各个不同Folder 间的配置异同比较 OPB_CNX: WORKFLOW MANAGER中关于源、目标数据库连接的定义，包括Relational Connection,Queue Connection,Loader Connection等 例如： OBJECT_NAME: Orace_Source USER_NAME: oral USER_PASSWORD: `?53S{$+*$*[X]
INFORMATICA关于WORKFLOW Manager系统的元数据 解析 INFORMATICA关于WORKFLOW Manager系统的元数据解析关键词：INFORMATICA,WOR Manager,元数据 informaica是一个很强大的ETL工具。其WORKFLOW MANAGER负责对ETL调度流程进行设计与管理和执行！informatica在在资料库中提供以下表来存储调动流程的相关信息。 以便WORKFLOW MANAGER对用户所设计的调动流程进行管理和执行。 opb_wflow_dep:描述workflow执行步骤相关信息和每个步骤执行的条件信息 opb_wflow_dep_run：描述workflow执行步骤运行时相关信息 opb_wflow_expr ：描述workflow中相关的表达式或条件的相关信息 opb_wflow_perval：描述workflow可持续性变量相关信息opb_wflow_run:描述workflow运行日志相关信息 opb_wflow_var:描述workflow变量相关信息
opb_task:描述任务对象的基本信息 opb_task_attr:描述任务对象相关的属性的信息 opb_task_inst:描述任务对象实例的基本信息 opb_task_inst_run:描述任务对象实例运行日志相关信息opb_task_val_list:描述任务对象实例中command信息WORKFLOW MANAGER系统中常用的有这几个模块，Command模块， Session模块， Waiting_Event模块， Raising_Event模块， Assignment模块， Worklet模块 WORKFLOW MANAGER系统中上述的这些模块统称为任务(Task).如果你对一个模块进行了 复制后新的模块就称作该任务的任务实例（Task_Inst）. WORKFLOW MANAGER系统中Worklet模块可以有其他非Worklet模块组成。 在WORKFLOW MANAGER系统中一个工资流被称作Workflow,Workflow由各种任务模块组合而成。 同时一个Workflow也是一个任务。以下是WORKFLOW 元数据表的详细说明， -----------------------------------------------------------------------
informatica_powercenter 资料库元数据查询 ——Informatica PowerCenter培训系列
TABLE OF CONTENTS 1 Overview 2 FOLDER 2.1 List folder details 2.2 List of shared folders 2.3 List of Users and Groups having Privileges on Folders 3 SOURCE 3.1 List of source tables 3.2 List and count of tables in each folder by db type 3.3 List and count of tables overall used 3.4 List of source tables used in mappings 3.5 List of Sources tables using as Shortcuts 4 TARGET 4.1 List of Target Tables 4.2 List and count of tables in each folder by db type 4.3 List and count of table overall used 5 TRANSFORMATION 5.1 List of filer transformations 5.2 List of Sequence transformations 5.3 List of tables used as lookups 5.4 List of transformations using sql overrides 5.5 List all transformations 5.6 List all Expression transformations using ‘concat’ function 5.7 List of all port details of an Expression transformations 5.8 List of all Expression transformation port links 5.9 List of LKP transformation port links used in mappings 6 MAPPING 6.1 List mapping names 6.2 List total count of mappings 6.3 List last saved user for a mapping 6.4 List Mapping parameters and variables 6.5 List all Mappings using PARALLEL hints 7 MAPPLET 7.1 List Mapplets in all folders
? 技术交流 数据集成产品介绍 Informatica华南.西南区销售总监 XX 1
日程 ?数据集成之领域挑战 ?Informatica 公司及产品定位 ?企业数据管理 ?数据集成平台–PowerCenter 介绍 ?数据质量控制–Data Quality ?实时数据交换–PowerExchange ?数据审计管理–Metadata Manager ?Informatica PowerCenter&元数据案例演示 ?解决方案特点及主要收益 ?案例介绍 2
3 挑战是什么？ 市场趋势加速数据分散状况 ?TDWI 调查： ?不好的数据质量导致美国商业市场每年花费6千亿美金?超过55%公司必须投资高水平的人员与预算来进行数据集成工作?Ventana Research ?超过60%的IT 预算花费在“集成”工作上?为了集成而集成?Gartner ： ?“缺乏全面性的策略…”使得“集成”所付出的成本相当高
4 编码定义完全不同 Other Xerox Divisions Other Contacts Buying Organization Xerox Imaging Contacts Jon Hart Corporation Xerox 渠道 销售 OA 人事 Xerox Imaging ID -992231 Xerox Image ID R1187X Xerox ID R1221 R1221 A8839 TT232 44123 财务OA 渠道人事John Hart ID TT232 Jon Heart ID 44123财务 企业编码关系图 人事 销售渠道人事Legacy 992231 R1187X 97735-1 4429Y9 KN222112 Jon Hart ID A8839
Informatica 9 安装手册 项目号xxxx 文档编号xxxx 版本号 1.0 保密级别一般内部公开秘密机密
修订记录 日期作者版本修订原因主要修订内容
目录 一、文档说明 (4) 二、安装前系统环境准备 (4) 1.确认系统需求 (4) 2.检查Informatica环境变量 (5) 3.确定端口 (5) 4.创建Informatica用户 (5) 三、安装介质准备 (6) 四、安装Informatica 服务端 (6) 1.创建informatica安装用户并设置安装目录 (6) 2.表空间及数据库用户准备 (6) 3.准备安装介质 (7) 4.运行install.sh，开始安装 (7) 5.选择图形化方式进行全新安装 (8) 6.选择安装类型 (8) 7.系统环境检查 (9) 8.指定license，设定安装目录 (9) 9.安装概要 (10) 10.安装过程 (10) 11.创建Domain并启用HTTPS安全管理 (11) 12.设置配置Domain的数据库连接信息 (11) 13.配置Domain和Node信息 (12) 14.安装结束 (12) 五、安装informaitca客户端 (13) 六、安装之后的设置 (18) 1.配置环境变量 (18) 2.安装/配置数据库客户端 (19) 七、Informatica服务端创建服务 (20) 八、验证安装结果 (22)
一、文档说明 二、安装前系统环境准备 1.确认系统需求 Domain和应用服务的系统需求 可以在同一机器配置Informatica Domain和一个node，所有application服务运行在同一node。 如果创建包括多个node的domain，可以将application服务运行不同的node上。Informatica node支持以下Unix或Linux安装平台： ?Sun Solaris ?HP-UX ?IBM AIX ?Red Hat Linux ?SUSE Linux 下表中列出了Informatica Domain包括不同node配置的最小系统需求： 安装组件处理器需求内存需求磁盘需求 4 CPU 8GB 20GB Domain with all Data Quality,Data Services and PowerCenter services running on one node 2 CPU 4GB 4GB Domain with all PowerCenter services running on one node 1CPU 2GB 3GB Domain with all PownerCenter services running on one node except Metadata Manager Service and Reporting Service 2CPU 2GB 3GB Metadata Manager Service running on a separate node Reporting Sevice running on a separate node 1CPU 512MB 3GB Orchestration Server running on a separate node 1CPU 512MB 3GB 安装过程中临时磁盘空间需求 在安装过程中会产生大量的临时文件，确保有足够的可用临时空间。安装结束后，会删除临
INFA9.1.0 Domain、资料库元数据库迁移方案 1、备份元数据库（10.33.1.79） 2、将元数据库(10.33.1.79)迁移到https://www.doczj.com/doc/bb7835172.html,中 3、切换Domain元数据库 关闭informatica服务 路径：$INFA_HOME/tomcat/bin 命令：infaservice.sh shutdown [infa@ecinfa01 server]$cd $INFA_HOME/tomcat/bin [infa@ecinfa01 server]$./infaservice.sh shutdown 修改Domain元数据库JDBC 路径：$INFA_HOME/server 命令：infasetup.sh updateGatewayNode -da sz01db01:1521 -ds s1g1_pubdb1_srv ./infasetup.sh updateGatewayNode -da 10.33.81.102:1521 -ds s2g1_ecsmsinfa1_srv -du ezhan -dp EcMinF1659
启动服务 路径：$INFA_HOME/tomcat/bin 命令：infaservice.sh startup 检查服务启动是否成功 ?登陆informatica mapping客户端，看是否能登陆
?如果登陆失败，查看启动日志；如果能够登陆，无需看日志。 日志文件及路径：$INFA_HOME/tomcat/logs/catalina.out ?检查控制台Domain的元数据JDBC是否修改成功 控制台网址：http://ip:6008/ Domain =>属性=>数据库属性 4、切换资料库元数据库 ?关闭资料库服务 登录控制台，关闭资料库服务
Informatica VS IBM-DataStage
对比项Informatica PowerCenter IBM Datastage 产品完整性对 比 数据整合部分：PowerCenter，是业界公认领导者 数据质量管理：Data Quality，成熟稳定技术，在 中国有大规模应用的成功案例。 实时数据捕获：PowerExchange，业界领先实时 采集技术，支持广泛数据源的CDC和Realtime， 与PowerCenter无缝集成。 元数据管理：Metadata Manager，是业界领先的 企业级元数据管理平台，可做到字段级的元数据 各项分析，有广泛的元数据采集接口，图形化无 需编程，并可自动维护变更。 数据整合部分：Datastage，属于业 界一类产品 数据质量管理：QualityStage，收购 的技术，不是主要其主要产品组成 实时数据捕获：MQ和DataMirror 的技术，技术复杂，与DataStage 是不同风格产品，产品的耦合度极 差。 元数据管理：MetaStage，几乎免费 的产品，应用性极差，并不能管理 企业级的元数据。而新推出的产品 与旧有产品线耦合度差，并未经过 市场的考验。 开发人员的使用效率 Informatica 是全图形化的开发模式，不需要编 码，工具易使用，界面友好、直观。 专业的三天培训，可使开发人员快速入门，进行 开发设计。 开发人员只要懂得数据库知识，即可。 Informatica 产品是以元数据为核心的，其开发过 程中，所有的元数据，包括规则和过程，均是可 复用，共享的。 经过简单配置即可支持大数据量的处理。 Informatica是完全基于引擎级别的，所有功能模 块化，扩展性强，维护成本低。 虽然也是图形化的界面，但复杂的 转换过程，里面嵌入了很多类Basic 脚本的成份。 要求开发人员，有编程语言基础。 在处理大数据量，必须使用 Datastage企业版。但如果客户原先 使用的Datastage 标准版，其作业 的版本移植问题很大。这两个版本 的工作平台、机制完全不同。作业 移植，大概要有70%左右需要重新 开发定义。 Datastage是基于脚本级的，底层基 于PICK BASIC和COBOL（Main Frame上）内核开发，要求不同的 平台需要不同的系统环境变量配 置。 应用需求的改变和拓展的支 持 Informatica 是以元数据为核心的平台，现在完全 支持SOA的思想，其最大特点就是完全支持松 耦合．可拆分成Service 进行调用．这样需求变 化，其需改动的部分，其影响会很小。 开发转换过程，均为共享的、可复用的。 元数据发生变化，可通过View Dependencies功 能，生成所有相关对象的报表，方便跟踪、校验， 以应对需求的变化。 应用需求变化，调整作业后，直接可以运行，不 需要重新编译。 作业移植等，也不需要重新编译。与平台和数据 库无关。 支持跨操作系统的集群技术，可方便的进行平台 级的扩展。 需求发生变化，需调整相应的作 业。如果是复杂需求，改动已有的 脚本，其维护成本相对比较高。 每次作业变化调整，均需重新编 译，才可执行。 Datastage企业版与Datastage 标准 版，其作业的版本移植问题很大。 这两个版本的工作平台、机制完全 不同。作业移植，大概要有70%左 右需要重新开发定义。一旦新的需 求，需要企业版，其移植和再次开 发，工作量要增加很多。 也因为两个版本的不兼容和脚本 编译的开发模式，使之产品面对变
1Informatica概述 (3) 2安装Informatica8.6.1 (3) 2.1服务端安装 (3) 2.2客户端安装 (7) 3配置管理服务器 (9) 3.1创建知识库和集成服务 (9) 3.2客户端到集成服务端的连接 (11) 4PowerCenter Designer学习 (13) 4.1概念和基本定义 (13) 4.2Mapping设计和组件的使用 (15) 4.2.1实例一：聚合抽取 (15) 4.2.2实例二：取TOP前三条记录 (16) 4.2.3实例三：抽取XML源 (19) 4.3WorkFlow的设计和使用 (20) 4.3.1创建Session (20) 4.3.2设计WorkFlow (22) 4.4Repository Manager (23)
1 Informatica概述 Informatica一直致力于为客户提供具有强大的元数据管理、数据集成和个性化分析递送功能的世界通行标准的统一数据服务平台。Informatica的基础设施产品以可伸缩的、可扩展的企业级数据集成平台为特点，并广泛支持来自Informatica和其他的领先商务智能提供商的数据仓库基础设施和分析型应用软件的开发和管理，提供元数据管理解决方案，帮助企业集成、优化、审核信息资产以提高运营效率，增加客户收益，取得竞争优势。 详见文档： 2 安装Informatica8.6.1 这里以Informatica8.6.1为例： 2.1 服务端安装 找到安装目录pc861_win32_x86.zip\Server\Windows\Disk1\InstData\VM下 点击安装
Informatica学习整理 https://www.doczj.com/doc/bb7835172.html,rmatica产品介绍: ?PowerCenter：Informatica PowerCenter是世界级的企业数据集成平台，它在ETL领域中无论是执行能力还是战略远见方面都是佼佼者，是Informatica的核心产品。 2.ETL环节中最重要的: ?大家可能大部分会认为转换才是最重要的环节，但事实上是加载环节。 ?按重要程度递减排序，分别是load（装载）、clean（清洗）、transfer（转换）、extract（抽取） 3.具有2个server: ?Informatica Repository Server:资料库server,管理ETL过程产生的元数据,用来管理对资料库中元数据的请求和操作; ?Informatica server:实际的ETL引擎; 4.具有5个client: ?PowerCenter Designer：设计开发环境，定义源及目标数据结构；设计转换规则，生成ETL映射 ?Workflow Manager：合理地实现复杂的ETL工作流，基于时间、事件的作业调度?Workflow Monitor：监控Workflow和Session运行情况，生成日志和报告 ?Repository Manager：资料库管理，包括安全性管理等，元数据维护和安全操作，如：元数据查找，用户、组、权限管理等。 ?Repository Server Administrator Console：对知识库的操作，如：知识库的创建、备份、恢复等。 5.基本的ETL任务设计和部署的大致步骤: ?使用Designer客户端，获取源数据表的元数据。 ?使用Designer客户端，获取目标数据表的元数据。 ?使用Designer客户端，设计一个Mapping，其中就是源->目标的ETL规则。 ?使用Workflow Manager客户端，针对上面实现的Mapping，实例化为一个Session，为其指定实际的数据源、目标连接，以及其他属性。 ?使用Workflow Manager客户端，创建一个Workflow，其中包含上述的Session 以及其他的Task，在Workflow中可实现复杂的流程控制。 ?运行上述Workflow，使用Workflow Monitor客户端，监测最终的任务运行结果。 6.一个简单的Mapping设计过程(8.1.1版本): 第一步:进入Repository Manager,在你的库下建立一个文件夹,用来储存自己的Mapping, 如图1.1:
Informatica元数据库解析 ZDNet管理软件频道时间：2008-03-03作者：来源：| 本文关键词： Informatica所有的元数据信息均以数据库表的方式存到了元数据库中。当然Infa本身工具提供了很多的人性化的功能，使我们在开发时可以很方便的进行操作，但人们的需求总是万变的，需要方便的取到自己需要的信息，那就需要我们对他的元数据库有很深的了解。 Informatica所有的元数据信息均以数据库表的方式存到了元数据库中。当然Infa本身工具提供了很多的人性化的功能，使我们在开发时可以很方便的进行操作，但人们的需求总是万变的，需要方便的取到自己需要的信息，那就需要我们对他的元数据库有很深的了解。Informatica通过表和视图给我们提供着所有的信息，在此将通过一个系列的帖子，将大部分常见的，且非常有用的表及视图介绍一下。基于这些东西，我们即可以根据不同的需求查出自己需要的数据，也可以开发一些辅助的Infa应用程序。 ///////////////////////////////////////////////////////////////////////////// OPB_ATTR : INFORMATICA (Designer,Workflow等)设计时及服务器设置的所有属性项的名称，当前值及 该属性项的简要说明 例如：ATTR_NAME: Tracing Level ATTR_VALUE: 2 ATTR_COMMENT: Amount of detail in the session log 用途：可以通过该表快速查看到设计或设置时碰到的一些属性项的用途与说明 OPB_ATTR_CATEGORY: INFORMATICA各属性项的分类及说明 例如：CATEGORY_NAME: Files and Directories DESCRIPTION: Attributes related to file names and directory locations 用途：查看上表所提的属性项的几种分类及说明 OPB_CFG_ATTR: WORKFLOW MANAGER中的各个Folder下的Session Configuration的配置数据，每个配置对应表中一组Config_Id相同的数据，一组配置数据共23条 例如：ATTR_ID: 221 ATTR_VALUE: $PMBadFileDir 用途：查看所有的Session Configuration的配置项及值，并方便的进行各个不同Folder间的配置异同比较