建立实时ETL数据仓库的解决方案需要理解不同的整合技术，这个领域体现了具有新技术、新方法、新词汇的全新理念。通过选择合适的实时ETL技术、特征、方法来指导专业实验数据仓库构建实时ETL的四个过程：
调研：实时数仓技术的状态、历史以及业务情况描述：区分组织的实时需求的方式、方法评估：针对实时报告以及整合服务机制，对每一个方法提供最合适的技术并进行分析判定：按需求分类，通过选择技术途径以及方法论上指导ETL工作组对于快速执行的垂直系统，数据仓库要完成决策任务，要给操作系统反馈丰富的信息，使这个系统能提高处理执行过程、提供个性化服务并体现面向需求，推动信息的不断更新。以下还有许多其它因素：
客户关系管理：CRM要求一个同步的、稳定的、完整的客户形象提供给操作系统。
零滞后的企业业务处理模型：在一个实时、零之后的企业中，信息在一个恰当的时间提交到一个恰当的地方就意味着获取最大的商业价值。
全球化及互联网：最终，最有效的使全球化和网络化的共同作用，使得数据仓库能在全球任意时间进行数据的存取与操作，适应对数据参考古能在全球任一时间进行数据的存取与操作
实时ETL在数据仓库中既不是真正的实时，也不完全是ETL。这个术语指的是可以在事务处理执行的几分钟内将数据尽可能快的传输到数据仓库中的软件。多数情况下提交实时数据数据参考古化需要的方法，完全不同于使用定向批处理程序组数据仓库化的方法。单一的以更多频次地运行常规ETL程序组是不可能实现实时ETLde ,无论是OLTP系统还是对数据仓库。反之，OLTP系统的逻辑提交任务处理中的数据仓库也是不能这样工作的。从技术结构方面看，实时数据仓库要有大批量处理的能力，每天晚上批次处理ETL事务，使之形成整日的连续不断的ETL数据流；从数据结构方面，实时数据仓库以离散周期测定值建立的数据仓库地位。数据仓库的实时方式能够很清晰的追溯到最原始的ODS系统。第一代被称作操作性数据存储（ODS），它构造的框架视图在数据仓库中分离出明显的框架结构及应用，来获得低滞后的报告，ODS是半运行半支持决策的系统。实际上，ODS已成为数据分级、数据清理、数据展现以及执行报表的架构元件汇集区，根据这些不同的作用，它是每一项任务的综合协调器，一个过度体；第二代被称为实时分隔区。逻辑或物理的实时分隔区的使用是一个用于从数据仓库中传递实时分析的有效可用的解决方法，使用这种方法创建了离散的实时事实表，它的粒度和维数与每晚加载的静态数据仓库中相关的事实表相匹配。这种事实表只含有当天所发生的流量。数据集市实时部分的逻辑关系如下图：
如果单独的时间记录被逐步地插入到实时间隔区，这时需要某些策略来处理发生在夜间的大容量负载产生的维度变化。事实数据仓库就能选择保持更多的频次断点来改变维度简单映射或可以放弃时间点的概念而捕捉到所有的刚发生的维度变化。
在数据仓库的维度总线结构中，逻辑和物理独立主题区域的联合维持了维度和事实的规范化，通常唯独管理者被认为是定义、维护、给所有数据中心发布特殊维度的一种角色，这些数据中心是经数据仓库中的传输总线相互作用的。最后，实时数据仓库将把大型目标的准备通道提供给当前最重要的数据，并提供给企业的所有客户。另外，为了给数据仓库快速提交事实记录，在提供实时同步关键维度方面，要建立巨大的竞争优势。这个机构提供数据仓库分布式分区的方法和给操作领域提供其他丰富的信息，在操作领域和数据仓库间形成闭环。降低OLTP与数据仓库间反应时间的发展成本和复杂性是遵循收益递减法则的，降低反应时间会非线性的增加复杂性和成本，因此，必须为数据仓库的数据饱满度设置现实的目标和期望值。困难的商业需求设置既不能满足传统数据仓库日常的发布，也不能满足OLTP系统的操作报告，需要考虑下列标记的内容：
低于5分钟的响应：以这样低的响应速度生成报告将不能满足主流实时数据仓库的可靠性。企业信息集成程序不涉及到这种响应时间的限制并能够之间通过操作系统传输几乎最新的报告。然而他们也有其它必须要考虑的限制。只需要很少或无需历史数据支持的单一数据源需求：这种报告不要求由数据仓库提供集成的历史数据，并且最好由操作系统本身寻址通过已存在的数据仓库生成面向不同用户的报告：这些报告的分发也许需要新的报告词汇和机制，以及会使已经很复杂的实时数据仓库发展成果更加复杂的因素特定分析非实际需求：如果能够稍微对低响应数据部分进行特定分析的话，可以避免对一个完整的ETL系统流进行重新设计还没有成功实现数据仓库的企业组织：空间数据仓库架构和方法允许企业组织添加实时报告功能数据综合化和应用程序综合化是最常用的实时数据仓库横跨操作系统的综合测量的要求分类。数据综合化是能够通过简单的在数据库间移动数据来满足综合化叫做数据综合化；应用程序综合化是通过使用一些常见的中间设备把应用程序连通化从而建立新的商业解决方案。数据仓库中在批处理过程中更改维度是不可能的，ETL不适合于对系统需要低延迟报告的数据和整合申请，对于需要获取更详细的维度变化的系统也不适合，传统的ETL处理方式如下图:
小批处理ETL与传统ETL除了批处理频率被增加外，在其他方面是非常类似的。关系图如下：
微处理ETL要求一个全面的工作管理，计划安排，从属关系和减少错误的方式，在大部分的时间是无人看管下，对于运行给予足够强壮的支持。在处理最常见的载入数据事务方面能够执行数据仓库发布的策略。一些可控事务的实效性支持这一个功能，但是传统发展型的任务很可能与微处理ETL数据仓库自动操作的任务相背离。微处理ETL在OLTP系统上，也要求更加频繁检测新产生的和更新的交易记录，因此应考虑和谨慎处理加载对整个系统运行的影响。识别微处理ETL载入实时数据仓库的更新候选记录可以采用如下方法：
时间戳：验证性和有效性ETL日志表：在OLTP环境下创建触发器，将新的独特的传统标识符和被改变的记录插入到一系列的特定的ETL日志表格中数据库管理系统日志筛选：审计日志文件通过日志筛选的特定功能来辨别新的和被改变的操作网络探测器：监控指定的网络流量，过滤并记录流量企业应用集成（EAI）是出现于复杂频谱的高端功能，是一套支持真实应用程序综合化的技术，它允许每个独立的操作系统通过潜在的不同新方法进行互联操作。 EIA需要建立一套典型的能够通过消息的形式，在综合化网络中跨多种系统推动商业操作，并能够使用该网络中所有系统从技术和独立性上完全独立与其他系统的适配器和broker组件。跨应用的两个系统可以通过EAI交互数据，如下图：
实时EAI数据仓库架构如下图:
任何一个OLTP应用的客户或产品变化事务都会被适配器所捕获，发送不规则的维度消息给broker，然后broker将维度消息发送给那些订阅了维度消息的系统，特别是维度管理系统。系统将维度记录以某种规则一致化，然后适配器将规则的维度消息返回给broker，broker再把规则的消息发送给所有订阅消息的系统，特别是数据集市和OLTP系统。在集成网络上，OLTP系统或者维度管理系统上设计一个可选择的发布策略时，一定要避免无限循环。
获取、转换和流动（CTF）是数据集成工具一种新的相关类别，这种数据集成工具被用来设计简化实时数据在不同数据库中转移。事务性应用的应用层是旁路的bypassed。相反的，直接库对库的交换被执行。事务包括新实时和维度变化可以直接快速从操作型系统向数据仓库进行数据移植，只需要几秒钟时间。CTF工具的转换功能基本上是基于与现今成熟ETL工具的对比之下的。所以实时数据仓库的CTF方案经常是操作环境中转移数据，使用CTF工具作数据住那换，然后转移数据。CTF架构关系图如下：
一些CTF工具能够简化信息从数据仓库返回到操作型系统的批处理，它可以很好的处理核心应用软件较低的共同活动时期，可以让数据同步发生混乱最低。CTF融合了EAI的好处部分，同时避免了复杂。
为了提高BI系统的实时上报能力，企业采用EII（企业信息集成）的方法，在传统ETL中，在OLTP系统中定义一系列的源结构，在数据仓库中定义目标结构。根据时间计划，选择业务低峰期（一般在晚上）触发ETL进程，ETL工具抽取数据，转换格式，然后将其装载到数据仓库表中，电子表格，或者对象链接或嵌入数据库，或者XML对象。EII触发器都是通过业务分析员推动，EII系统实际上产生了一系列的数据库查询，基本上是通过SQL请求时返回的结果数据，然后将数据释放给业务用户。一个零延迟报告引擎需要联合成熟的ETL工具数据集成的充足作用来增强。数据仓库本身也可以被定义为一个EII系统的源信息，所以操作型系统的实时数据与数据仓库中历史数据的集成时可行的。EII的转换能力虽然很强大，但也是有界限的。它并不能在线支持所有的现代ETL和数据清洗功能，所以响应的降低了对它的预期。同样的，由于抽取的数据直接依靠OLTP系统，因此在抽取的频率和复杂度的管理上要参照OLTP技术框架上的脚本大小的管理。EII可以尽可能快的满足实时集成操作性上报。
实时维度管理，主要在客户信息中使用，转换新引入的客户信息，这些客户信息有可能是不安全的、错误的或者冗余的。所有的合理方法被用来消除冗余、除去脏数据，尽可能的将数据编译完整，同时指派代理数据键值。实时维度管理架构如下：
EAI broker 是相同的EAI中间件组成部分，而中间件是在另一个EAI图标中被描述的。它负责在适配器之间根据发出和接受规则“路由”消息，在维度管理中EAI是根据操作型系统的；不规则维度离散信息改变到维度管理者进行路由处理，并将规则的维度改变返回需要接受信息的操作性系统上，或者是数据集市上。从实时维度管理得到的规则的客户信息一定也被包含在一系列OLTP系统的历史键值中，这些OLTP系统是被规则化进程连接在一起的，这些舰只被OLTP系统的适配器用来指认出如何应用规则化后的客户信息到各自的应用上。这些OLTP的结果性改变可以导致新记录的产生，对原有数据的更新或者两条或更多数据的合并，这些数据被维度数据管理认为是冗余的。在实时数据集市装载软件中也可以使用出现再引入到数据仓库替代键的实时记录的原有键值。实时规则维度是下列子部分的典型模块：
清洗：清洗部分读取引入的不规则数据，从工作流中抛弃那些残缺的或非法的维度实例，保证查询被展示出来，保证包含在属性里的数据值的合法性规范化：规范化部分从工作流中获取清洗后的数据，执行域对域转换匹配：匹配部分从工作流中获取清洗一致化后的数据，识别并排除冗余数据。不足匹配大体上被认为比过渡匹配更保守且较低插入，并且被认为是规范的。在实施EAI环境中消除一个错误匹配并不容易，客户处理常常已经被OLTP系统错误整理过了，是在OLTP系统对维度管理者手工分离和中继转发的融合请求，做出反应时的错误处理。
在实施环境中，需要手工维护的记录对于不匹配状态是一种典型的缺省状态，而且手工维护可以延迟执行。由于性能原因，当处理大维度时一定有要限定候选键，使其达到合理的实时性能。抽取候选键可以大幅度加快匹配处理，但是有时会在传递用来匹配的候选记录时出错。因此，实时在线匹配优势会危机安全，同时，整个维度的周期性重新匹配也是必须的。
当设计实时数据集市分区或维度系统时，经常设计一套方案来处理频度发生的微批处理，使用标准转变工作来控制元数据结构。微批处理数据模型如下图：
各个处理连续运行，而且像邮件收发狗太程序一样和其它处理共同完成同一工作，因此设置工作处理事件和微批处理状态值，然后继续。所以，一个维度管理者的数据清洗，一致化、匹配、存在和发布处理后台处理有时会在；不同的工作任务上同时发生。如果有失败发生或一个无法接受的大数量任务处理事件状态为失败，将会执行回滚处理，数据库将会回复到微批处理执行之前的状态。回滚事件并不一定回滚错误信息或控制表中的状态值，很多关系型数据库提供了处理控制选项来支持这种约束。实时维度微批处理流程如下图：
每个处理在任务事件表中更新状态值，在分段传输阶段修改和新建数据，或一致化维度。
在清洗过程从分段传输库中读取未经验证的数据，并只向控制库中写入状态值在规范化过程中，从分段传输读取清洗后的没有一致化的数据，并向分段传输写入一致值来保证一致属性匹配阶段从分段传输读取一致化后的未经匹配的数据，向分段传输写入匹配键值存在阶段从分段传输读取经过匹配的为存在的记录，并向一致化维度库中插入或更新记录发布阶段从一致化维度库中读取经过一致化的记录，唤起维度管理者适配器，然后适配器将记录发布到集成网络中实时报告决策向导矩阵如下图：
实时ETL是物理和逻辑上的挑战，实时系统的最好设备是用流动ETL替代面向批操作的ETL。为一个数据仓库设计并构建一个ETL系统一定要深化ETL的定义，在数据抽取、清洗、规范化以及提交等每一个步骤的内容都要提供了ETL元数据的基础。通过提供实际数据的状态来降低处理ETL元数据的困难，在清洗步骤中的审计维度直接验证。IT事实上只有两个相辅相成任务：获取数据和输入数据，获得的数据也就是事务处理。
至此，数据仓库ETL工具箱书中的所有内容全部介绍完毕，由于笔者技术能力和理解能力有限且对数据仓库尚在学习阶段，因此博客中大部分都是抄写的书中原文，之后会对本书内容做补充说明。