The+Data+Warehouse+ETL+Toolkit中文版 四Word格式文档下载.docx
《The+Data+Warehouse+ETL+Toolkit中文版 四Word格式文档下载.docx》由会员分享，可在线阅读，更多相关《The+Data+Warehouse+ETL+Toolkit中文版 四Word格式文档下载.docx（44页珍藏版）》请在冰点文库上搜索。
供一组不变的数据，提供一个可靠的信息平台。
针对某一时刻数据库的最新报告
t，业务用户都是以事务的生产应用为目标，因此用户必须了解，到昨天为止这
个事件所发生的历史过程，同时还要看到许多OLTP系统今天所发生的事情。
业
务用户完全不需要接受这种分割，他们为什么不能只去一个地方就可以得到他们
所需的所有信息呢？
那好，许多都改变了，数据仓库已经成为他自己牺牲品becomeavictimofits
ownsuccess。
虽然在数据仓库中事物处理及事物再现之间的延迟一般小于24小
时，但对于快速运行的垂直运行的系统，这个延迟就太长了。
数据仓库要完成决
策的任务，要给操作系统反馈回丰富的信息，使这个系统能提高处理执行过程、
提供个性化服务并体现面向需求，推动信息的不断更新。
还有很多其他的重要因素，使数据仓库的实践者反思早就出现过情况：
客户关系管理（CRM）。
现代CRM要求一个同步的、稳定的、完整的客
户形象提供给操作系统。
CRM又在相当高的层面上直接或间接地服务于
客户。
尽管市场对于CRM卖主包装的需求而言，性能不能超出构架来购
买，除非所有面对消费者的系统可由CRM单元来付清。
尽管市场需要的
都是已经打包好的CRM产品，但是这种需求是不可能实现现货供应；
除
非将所有的面向客户的系统都包装上CRM的外壳。
在业务上，也需要集
中消费者的实时信息来跨越传统的处理型stovepipe的应用。
数据仓库当
然完全需要从操作型应用上获取稳定不变的客户信息流来充实仓库中的
客户信息，但事实上，越来越明显的是，操作型应用也依赖于数据仓库
中丰富的客户信息。
因此，可以预言，组织者已经开始开发结构化的交
变器architecturalalternatives使它能够支持没有显著特征但更为复杂的
集成情况——操作型数据在操作系统和数据仓库同步进出——越发紧
迫。
413
零滞后的企业业务处理模型。
这里提倡的是理想化的速度效益和真实的
单一模式。
在一个实时、零滞后的企业中，信息在恰当的时间提交到一
个恰当的地方就意味着获取最大的商业价值。
某些人称这个为即时时间
系统。
正是企业对及时编目、实时供应链及客户化的指令和物理集成业
务模式的需要，扩大了对绝对数据流和渗透信息的需求。
现实中，真正
的零滞后是不可能达到的理想状态，跨越各种生产系统和数据中心来统
一信息是需要时间的。
但是对于当前许多只能提供反映事物最佳状况的
低滞后的数据仓库上的压力却是真实存在的。
全球化及互联网。
最终，可能最有效的是全球化和网络化的共同作用，
他使得数据仓库能在全球任一时间进行数据的存取与操作，能适应对数
据仓库日益广泛的需求，这样就强烈地压缩了下载数据仓库需要的时间。
需要输入数据仓库的数据量不断扩大，而业务荡机时间（downtime）又要不
断收缩，这对已超负荷工作的热爱数据仓库的ETL团队是一个挑战。
如果你能设
法在全天的时间中细水长流地不断输入数据仓库的数据，而不是猛地扩充数据载
荷到因停机时间而收缩的时间期限，这可能会更容易些。
所有这些因素促使数据
仓库逐渐达到实时状态。
12.2实时ETL的定义
实时ETL在许多情况下是对提供数据仓库式服务的一个误称。
这个服务既不
是真的实时也不是ETL。
而这个术语指的是可以在事物处理执行的几分钟内将数
据马上但非同步地传输到数据仓库中的软件。
多数情况下提交实时数据数据仓库
化需要的方法，完全不同于使用定向批处理程序组数据仓库化的方法。
整天单一
的以更多频次地运行常规ETL程序组是不可能实现实时ETL的，无论是OLTP系
统还是对数据仓库。
反之，OLTP系统的逻辑提交任务处理中的数据仓库也是不
能这样工作的。
让OLTP系统在着手它的下一个交易之前，等待数据仓库的数据
下载到提交任务上，那简直是奢望。
也没有任何同步的或两相的逻辑提交任务能
实际跨越不同结构，不同粒度水平的系统。
而你仅仅希望在事务可接受的限定时
间内，将新的处理输入到数据仓库的特殊的实时分隔区（本章后边会有定义）内，
并为每日的操作决策提供分析支持。
就目前来说，这个过程就是我们对实时ETL
414
的实际定义。
本章为了实现这些目标使用了数据仓库设计师熟悉的主流工具装置，研究了
某些实际方法。
然而，实时数据仓库是一个新的领域，充斥着各种各样的软件
商的要求和较高的风险。
本章所研究的实时ETL方法试图通过控制预期、重视成
熟方法和实施战略工具选择来将风险减到最小。
本章提供了在业务处理上和数
据仓库可提供的范围内，为目标分配达到最短时间滞后的方法。
12.3实时数据仓库化的挑战和机遇
实施实时数据仓库，给ETL的设计者提出了许多独特的挑战和机遇。
从技术
结构方面看，它要有大批量处理的能力，每天晚上批次处理ETL事务，使之形成
整日的连续不断的ETL数据流。
当事务开始依赖数据仓库中事务处理低滞后时间
效应时，相对于实用性，系统就需要升级了。
如果组织者选择本章所述的实时维
管理方式，实用性就成为战略优势了。
从数据结构方面看，实时数据仓库挑战了以离散周期测定值建立的数据仓库
的地位。
后者只是提供了业务简单映射，而现在我们提倡的是更加综合，更加连
续的瞬时信息系统。
这种变化的发生是很细微的。
例如，事实加载频率从每日一
次增至每15分钟一次，但是如果事实加载和维度记录能连续进行那岂不是更加
生动了吗。
那么数据仓库就可以在所有的时间点上及时捕捉到事务处理的信息和
他们前后的维度。
维度的缓慢变化变为快速变化，数据仓库的支撑（bearing）变
得更贴近实际的情况了。
事实上实时数据仓库也支撑了实时维度的形成及同步
化，它也涉及了操作系统本身的逻辑延伸。
12.4实时数据仓库的回顾
数据仓库的实时方式能够很清晰的追溯到最原始的ODS系统。
原始ODS的
目的与现代实时数据仓库非常类似，但实时数据仓库的应用还影响到了新一代的
硬件、软件技术的发展。
下边将更详细论述这些思想。
第一代――操作性数据存储
操作性数据存储或称ODS，是第一代数据仓库。
它构造的框架试图在数据仓
415
库中分离出明显的框架结构及应用，来获得低滞后的报告。
ODS是半运行半支持
决策的系统。
试图在频繁更新和频繁访问的即时响应之间达到平衡。
早期的ODS
架构被描述成一个数据被整合并反馈到下层数据仓库的模式，因而起到扩展数据
仓库ETL层的作用。
后期的架构被描述成集成来自数据仓库ETL层数据的消费者，
按照已存在的全面的架构和从操作型系统下载数据的及时性，将架构分为从类型
1到类型4，以及内在的或外在的ODS。
实际上，ODS已成为数据分级、数据清理、数据展现以及执行报表的架构元
件汇集区。
根据这些不同的作用，它是每一项任务的综合协调器，一个初级的、
欠折衷的过渡体。
第二代――实时分隔区
逻辑或物理的实时分隔区的使用，就像RalphKimball原来所描述的那样，是
一个用于从数据仓库中传递实时分析的有效可用的解决方法。
使用这种方法，创
建了离散的实时事实表，它的粒度和维数与每晚加载的静态数据仓库中相关的事
实表相匹配。
这种实时事实表只含有当天所发生的流量（这些尚未加载到静态数
据仓库表中）。
图11.1显示了2组星型结构分别连接到实时和静态零售销售点事实表，他们
的维度相同。
416
图11.1静态和实时星形结构之间的关系
每晚。
实时分隔区的内容都被写进静态事实表中，然后实时分区即被清空，
准备接收第二天的处理情况。
图11.2列出了这个过程是如何工作的。
实质上，
这个方法将ODS实时报告的好处带给了数据仓库本身，使其在过程中消除了过
多的ODS结构的开销。
417
图11.2数据集市实时部分的逻辑关系
剩下整个一天的时间，事件逐步插入到实时事实列表中，客户对实时列表的
查询,不会不完整,也不会被加载过程所中止。
为了减小数据加载作用和查询回应
次数所带的影响，实时事件列表的索引是最小的或不存在的。
靠限制（一天内）
列表中的数据量和将完整的实时事件列表存入内存中可以提高性能。
不经意间，
在实时和静态列表中的关联事件的观点就产生了。
如果单独的事件记录被逐步地插入到实时间隔区，这时需要某些策略来处理
发生在夜间的大容量载荷产生的维度变化。
例如，在白天出现新的客户记录，你
可能会延迟将这些新变动的客户的一个批次加载到静态客户维数中。
因为一般新
的客户记录都是在晚上更新到进一步描述客户记录的客户维数中。
而实时数据仓
库就能选择保持更多的频次断点来改变维度简单映射或可以放弃时间点
418
（point-in-time）的概念而捕捉到所有刚发生的维度变化。
最近，本章所描述的问题与选择合适的方法来处理维度的变化有关，一些有
效的方法是将数据在整个事务日内逐步地插入到实时间隔区，及对这种方法的利
弊。
最近CRM的趋势
CRM要求对每一位客户系统的历史包括对所有客户的每一个接触点都有一
个全面的了解，并要洞察客户在市场中所面临的挑战及前瞻预期。
在过去几年中
完整地CRM系统已被广泛的应用于商务活动，以支持前期目标，使组织系统中
最简单最普通的客户接触点一致化。
然而，在分割客户来支持分析系统上，这些
系统体现了对组织的重要优势，面对这种优势他们就不理解了。
常常是那些比较
老的，比较特殊的系统都还存在着，而这些支持客户相互作用的系统不再是CRM
系统体系了。
这些处理过程再没有找到他们返回CRM系统体系的方法。
CRM系
统体系也是典型的用户智能装备不合格的组织机构，它需要被它的客户认识到作
为智能合作者和伙伴，他们还缺乏收集、获得成功的机构，协调一致的客户、和
跨企业的智能市场。
进一步打破CRM体系市场，建立相对应的分析型CRM类型
的运作型CRM扩大了这种分化。
业务没有运作或分析型的客户，同样操作型和
决策支持系统也要共同运作以服务于客户。
现在需要一种方法，这种方法可以将过去和现在的客户相互作用的组织数据
一起快速整合，联合外部市场信息，用某些机制将数据转换为客户智能，这意味
着组织中的每个人都可以共享资源。
将这些东西集中在一起代表了混合数据仓库
的技术和集成技术的应用。
CRM的供应商敏锐的察觉到组织结构所面临的挑战，所以某些结构就将商务
智能能力与他们的操作型CRM系统结合起来。
这个结果只是基本的，过分简单
化的，对结构的保护是困难的，最终难于形成不同于他人的有竞争力的产品。
第二代CRM入我们在本章定义的，不是可以购买和安装的应用程序。
它要
求是一个综合数据仓库，含有所有客户接触点、智能筛选和市场数据的利用；
它
要求是一个连续获取客户智能的数据仓库，要求是一个在跨企业间分享和同步传
递客户信息的机制。
能提供这种能力的任务，似乎更应放进同期ETL结构后备库
419
中。
维度管理者的战略角色
在数据仓库中维度总线结构中，逻辑和物理独立主题区域的联合维持了维度
和事实的规范化，可以通过利用本章描述的维度管理系统完成。
。
通常维度管理
者被认为是定义、维护、给所有数据中心发布特殊维度的一种角色。
这些数据中
心是经数据仓库中的传输总线相互作用的。
最后，实时数据仓库将把大型目标的准备通道提供给最当前的最重要的数
据，并提供给企业的所有客户另外为了给数据仓库快速提交事实记录，在提供实
时同步关键维度方面，诸如跨越所有组织的操作系统的客户和产品上，要建立巨
大的竞争优势。
这种同步信息作用要考虑维度管理作用的逻辑扩展，要是一个有
效的、可靠的机构。
这个机构提供数据仓库分布式分区的方法和给操作领域提供
其他丰富的信息，在操作领域和数据仓库间形成闭环。
在战略实时数据仓库中客户维度的管理者不仅可以向数据仓库逐步插入新
的合适的客户信息，而且可以与某些机构合作跨越相关操作系统提供同步客户信
息。
这个实时客户信息应包括数据仓库本身客户智能。
显然这些是很有雄心的目标。
如本文所写，非整套的决策方案或endtoend
端对端衔接的工具装置，显著地简化了建造一个双向EAI或实时数据仓库解决方
案的过程。
但是，像这样的系统已经创建出来了，这些系统的基本结构几乎已经
存在并变得更加完善。
由这样的系统提供的商务差异的可能性被取消了。
它就像
当今早期的接收器，具有市场的有利条件，可推动将来更广泛的使用这样的系统。
今天建造这样的系统应考虑将来能使这种组织能力发展为实时EAI或数据仓库华
的解决方法。
组织机构处于竞争的压力下，或现在需要通过友好的客户寻求存在
差异的市场来越过这一关.
12.5需求分类
很明显，这个话题给我们提供了很多架构方面的思考。
提供更为复杂的一系
列与主流实时数据仓库相关的优劣分析，，列出实时需求的范围是非常重要的。
在接下来的部分向您展示的是一些litmus测试问题，这些问题的答案可以帮
420
助您将您的企业组织需要的实时系统的能力进行分类,并且为您以后的任务选择
适当的方法和工具。
在本章临近结束的时候我们给您列出了一个矩阵，这个矩阵
概括了这些讨论内容并且能够在方法和架构的选择上引导ETL团队。
数据的饱满度和历史的需求
降低OLTP与数据仓库间反应时间的发展成本和复杂性是遵循收益递减法则
的，降低反应时间会非线性的增加复杂性和成本。
因此，您需要为数据仓库必需
的数据饱满度设置现实的目标和期望值。
同时您还需要彻底明确一个概念，即困难的商业需求设置既不能满足传统数
据仓库日常的发布也不能满足OLTP系统的操作报告。
当您考虑期望的实时数据
仓库的需求时请参考下列红色标记的内容。
低于5分钟的响应：
以这样低的响应速度生成报告将不能满足主流实时
数据仓库的可靠性。
这个时间是持续降低的，但是它同样需要进行超大
量的处理和时间将信息从OLTP系统中移动、转换并装载到实时分区中。
那些完全拥有超过5分钟刷新时间的信息量的企业组织应当考虑直接通
过操作系统生成他们的报告。
企业信息集成程序不涉及到这种响应时间的限制并能够直接通过操作系统
传输几乎最新的报告。
然而他们也有其他必须考虑的特点和限制。
企业信息集
成系统以及这些限制将会在本章稍后讨论。
只需要很少或无需历史数据支持的单一数据源需求：
这种报告不要求由
数据仓库提供集成的历史数据，并且最好由操作系统本身寻址
（addressed）。
恰当的来说，他们应当呈现非常细致的OLTP系统报告
（footprint）并且不能明显降低操作性能。
如果网络可用的话，这些报
告可以通过商业智能入口（BIportal）呈现，这个时候用户群则会认为这
些是基于数据仓库的报告。
通过已存在的数据仓库生成面向不同用户的报告：
这些报告的分发也许
需要新的报告词汇和机制，以及会使已经很复杂的实时数据仓库发展成
果更加复杂的因素。
实时系统不是一个自动的项目终结者，举一个例子
来说，实施系统架构师应当意识到在海运中和市场管理中所应用到的商
421
业词汇和矩阵很可能是有很大差别的。
特定分析的非实际需求：
如果能够稍微对低响应数据部分进行特定分析
的话，你就可能避免对一个完整的ETL系统流进行重新设计。
也许你只
需要简单的创建一个基于最新操作系统数据的快速报告，并将这个报告
附加在传统数据仓库中根据昨天的数据所生成的报告中。
还没有成功实现数据仓库的企业组织：
至少从目前来看，将尝试建立一
个实时数据仓库作为最初的商业智能发展成果是不被推荐的，仅仅是因
为它需要同时精通大量的学科。
值得庆幸的是空间数据仓储架构和方法
允许企业组织今后可以很好的添加实时报告功能。
以上这些红色标志的共同的象征应该是一个报告，这个报告要求的数据是在
昨晚之前更新的而且必须能够满足最少5分钟的响应时间。
这样的报告也许同样
依赖于数据历史、报告词汇、已存在的非实时数据仓库的演示等方面的连续性。
这些红色的标志是符合实时数据仓储ETL方法所描述的合适考虑对象。
接下来的部分我们将讨论一些关于实时报告的基本要求。
仅仅是报告还是一个综合过程？
企业组织需要一个单一的解决方法仅仅为了报告的目的而把操作数据移动
到数据仓库中吗？
或者说对于通过在操作系统自身和/或数据仓库间闭环转移的
规范化的维度数据也同样有需求？
举一个例子来说，将基于数据仓库的客户部分
返回操作系统是否需要一个机制？
这也许是最为影响选择实时数据仓储方法的
一个问题。
当然，任何客户关系管理策略都可能需要共享时间列表和最为完整的客户信
息，包括可操作的客户数据（例：
最近的销售或投诉信息）和源于数据仓储或数
据挖掘的客户市场信息，比如客户分割、资料以及寿命值。
在企业组织可操作系
统和决策支持系统间闭环循环的过程中，实时报告是否为第一步骤？
仅仅是事实还是包括维度变化？
商业人士和空间维度数据仓库架构师将世界定义为事实和维度，但是OLTP
系统不会做出如此明确的区别。
但是，作为工程师来说，你必须明白并将OLTP
422
系统的商业操作按照终端用户的喜好做好分类并进行适当的设计。
实时报告需求是否专一的关注在诸如最近提交的订单、最近发送的电话、近
期完成的股票交易以及近期拨打的销售电话等最新的事实吗？
还是说它同样要
考虑到一些诸如客户或产品记录的更新维度一类的最新操作？
如果实时空间维
度变化是报告所必需的，那么他是否是连续或缓慢变化的？
换句话说，用户群在
面临做出操作的时候是否需要一个准确的维度表，或者当更新发生时，是否所有
或部分维度更新会被破坏性的进行过度重写？
报告是否需要有可重复性？
第一
类型慢慢地改变维度，对维数属性的变动破坏性地重写期望值，导致连续重建历
史的数据仓库，报告事件不是看他们操作的时间而是要看今天的维度状况。
在这
种情况下，通过不同的时间点相同的维度生成的报告可能会有轻微的或者显著的
不同。
如果第一类型转变用于聚集演算依据的话会造成历史聚集的无效，因此这
种变动是危险的。
类型2和类型3在某些点上会缓慢的改变维度从而使得粒状维度图更加清
晰，也许是每天都在改变，但是他们仍然不能捕获到发生在抽取时的维度变化。
实时维度刷新可以使粒度提升到每隔几分钟或者捕获所有维度变化。
建筑学的含义不是微观的。
通过采取加快捕获维度变化图像频率的方法，数
据仓库远离了他的早期状态即周期性测量（快照）系统，继而转变为0响应时间
的决策支持理想模型。
当数据仓库和应用综合化技术开始相结合的时候，数据仓
库实际上将成为管理企业操作的系统的一个真实的逻辑引伸。
暂时作为当务之急
的，ETL系统大概需要被设计成为能为被测量的事实提供尽可能接近0的响应速
度，但是同时还要允许部分或所有维度属性可以进行批量更新。
告警，持续处理或者无事件?
虽然通常情况下ETL系统对于维度化数据递交前台的界限有非常明确的定
义，但是在许多情况下一个实时系统无法有这个界限。
Thearchitectureof
front-endtoolsisaffectedatthesametime。
现有三种数据交付范例，都要求通过
端对端的观点来达到所有从初始源到终端用户的方法。
告警：
通过源数据条件强制用户界面进行更新。
持续处理：
终端用户的应用程序为了实时更新屏幕而连续探查源数据。
423
无事件通知：
如果某个特定事件在某一间隔时间内或者由于某些特定条
件制约而没有发生，终端用户将被通知。
在以上每一个事件中，实时ETL系统将通过发送通报或者接受直接请求的方
式与终端用户的应用程序相连接。
数据综合化或应用程序综合化?
假设实时数据仓库的要求同样适用于某些横跨可操作系统的综合的测量，您
需要将您的要求分类为数据综合化或应用程序综合化。
总的来说，能够通过简单的在数据库间移动数据来满足综合化叫做数据
综合化。
通常，这些解决方案都是点对点的形式，对于异构数据库通过
ASCII码文件抽取、触发、数据库链接和网关执行，或者通过同类数据库
的复制服务或者表格快照方式执行的。
精炼的说，在所有参与的应用程
序间数据是共享的，完全绕过应用程序的逻辑。
一些高结束数
升级会员 