论文翻译：从传统数据仓库到实时数据仓库_rtdw

英文名：From Traditional Data Warehouse To Real Time Data Warehouse

译者：维克先生（首发于CSDN，转载请私信）

摘要：传统的数据仓库不包含像今天这样的数据。在传统数据仓库中检索数据并处理它们是很困难的。此外，它的内容也不是高频更新的，这可能会导致错误的决策。数据通常从传统业务系统加载。鉴于当今商业世界的决策对实时性要求越来越高。因此，人民越来越推崇支持实时决策的系统。在本文中，我们从传统的数据仓库到实时数据仓库进行了调查分析。本综述首先关注数据仓库体系结构。其次，详细介绍了提取（E）转换（T）加载（L）过程中的变化，以处理实时数据仓库。第三，描述了实时数据仓库中的集成数据。最后，本文还对实际数据仓库方法进行了比较研究。

1 简介

数据仓库（DW）是一个集成历史数据的集合，通常用于通过在线分析处理（OLAP）技术做出战略决策。它集成了来自各个独立的异构业务数据源的数据，并创建了有关组织的单一视图。一旦进入数据仓库，这些数据就会转化为结构化信息，决策过程可以轻松处理这些信息。

由于新的业务需求需要不断更新最新的信息，而且及时的数据可以确保做出更明智的决策，因此实时数据仓库是能够满足需求的未来发展趋势，它提供了对组织信息的实时准确、集成、整合视图的访问 [8]。

对于实时数据仓库，目前文献中没有正式的定义。实时数据仓库 (RTDW) 可以定义为代表组织特征和实际情况的系统。例如，如果我们有一个分析组织某个特定方面的请求，那么在发送请求时，答案将以组织的真实状态表示 [6]。与大多数传统数据仓库不同，RTDW 包含组织的当前数据（实时）。因此，刷新频率在 RTDW 中起主要作用。通常，根据文献 [1,3,6]，RTDW 每天会经历多次更新，这使得决策者能够访问组织的当前数据。

为了提供数据新鲜度、性能、可用性和预测能力，并提供一个集成的信息存储库来驱动和战术决策，人们提出了许多方法来处理RTDW体系结构和RTDW中的数据集成。

本文的其余部分内容如下：

在第2节，我们介绍了为什么需要RTDW，并解释了RTDW和传统DW之间的主要比较。

第3节介绍了一些研究，这些研究使我们能够提供解决方案，以改变传统的提取转换加载（ETL）过程，从而更接近于RTDW。

第4节描述了一些研究中提出的一些架构。

第5节介绍了一些解决数据集成问题的建议方法。第6节总结和讨论了本文研究的所有方法。

最后，第7节给出了一个结论，并提出了一些未来的研究方向。

2 对实时数据仓库的需求

数据仓库可以通过传统方式或实时方式进行更新。传统方法的缺点是数据内容没有更新，可能会导致数据使用者做出错误的决策。因此，企业需要建立近乎实时的数据仓库，其中一些数据是实时更新的，其余的一些数据是传统的刷新。以接近实时的方式存储数据将减少业务事务到操作源和它们在数据仓库中出现之间的延迟。这有助于分析最新数据并加快决策速度。

然而，数据仓库和商业智能实时应用的提出，正是为了回答用户想要的实时数据的问题类型。实时数据仓库能够在数据产生的时候存储数据，并立即捕获、清理和存储在数据仓库的结构中。这样来看，传统的周期性刷新的方式就不再有效了。数据仓库必须能够读取在其产生的同一时间在操作系统中移动的相同数据。

实时数据仓库的目的是使企业能够迅速获取信息，并通知用户或决策系统几乎立即对信息做出反应。有两个论点可以证明使用实时数据仓库的合理性。(1) 传统的数据仓库，它提供了公司在过去某个特定时间（每天、每周或每月）的状态。 然而，有些应用需要更高的数据实时性（例如每小时）。 实时仓库使组织能够在一天内找到其状态的变化。(2) 第二个论点集中在这样一个事实：当大量的数据在一天内被输入交易系统（金融部门）；处理ETL有时会导致问题[1]。实时仓库的运作是在一天内相当频繁和有规律地添加数据。表1列出了传统数据仓库环境和实时数据仓库环境之间的详细比较。

表1. 传统数仓与实时数仓的主要区别

在下面的章节中，我们将介绍一些可以更接近实时数据仓库的方法和其他代表RTDW架构的方法，并讨论实时数据的整合。

3 接近实时数据仓库

在大多数情况下，更新DW也意味着在更新过程中使其停止使用（关闭），或者至少这使其使用更加困难，性能更差。使用中的仓库进行更新可能会导致查询返回的结果中的一些不一致，如果被访问的数据恰巧同时被更新，那么它们的逻辑合理性、准确度将大幅降低。在不关机的情况下，连续更新所需的标准通常与传统ETL工具不一致。为了解决这个问题，新的解决方案专门用于实时ETL和数据加载。也有一些解决方案修改了传统的ETL系统，以便以接近实时的频率加载数据仓库。

现有的ETL系统可以被修改以执行实时或接近实时的数据仓库加载。其中一些解决方案在[3]中有所描述：

近实时 ETL（Near Real-Time ETL）：第一种解决方案是简单地增加向仓库加载新数据的频率。例如，通常每周进行一次的加载可以每天执行一次。然而，这种方法可能会涉及到关机问题。这种变化将使DW的用户能够访问更多的最新数据，而不需要对加载过程或数据模型进行重大修改。虽然说不是真正的实时，不过近实时是一个较好的低成本解决方案。

持续加载（Direct Trickle）：如果一个应用程序需要实时性，最简单的方法是不断地用新数据加载DW。通过这种方式，我们将消除任何中间的存储步骤。然而，当一个或多个用户利用DW时，这种解决方案可能会导致性能损失，因为仓库的更新本身就需要承载它的机器进行大量的工作。

分区加载（Trickle and Flip）：这种方法需要将加载的事实表制作成第二个分区。在定期的基础上，我们用第二个分区替换数据仓库中的事实表，这个分区负责新数据。通过这种方式，可搜索的事实表以较低的频率更新，以限制其运行期间的性能损失。它还包含自上次更新以来的所有新数据。这个解决方案可以根据一个周期来使用，这个周期可以从几小时到几分钟不等[3] 。

外部实时数据缓存：这种方法是在仓库外部的实时存储器（实时数据缓存）中实时存储数据，完全避免了任何潜在的性能问题。 实时数据缓存可以简单地成为存储和数据处理的另一个专门的仓库负载。处理大量数据或要求很短的处理时间的应用程序可以从这个解决方案中受益。这个解决方案的主要缺点是它涉及到一个必须安装和维护的额外数据库。为实现这种方法所做的工作较多，但在许多情况下，使用这种方法可以证明购买更有效的设备或额外的内存所花费的费用是合理的。

在[10]中，作者提出了近实时ETL的一些挑战和可能的解决方案。他们为每个提取、转换和加载阶段确定了两个问题。在提取阶段，有一些问题，例如使用流处理器和数据集成工具的变化数据捕获解决了多个异质数据源的集成问题。这个阶段的第二个问题是使用更新服务的过载数据源。在转换阶段，作者发现了两个问题，第一个是主数据开销，第二个重点是服务器聚合数据的需要。第一个问题的解决方案是维护一个数据和数据库队列的主缓存。然而，第二个问题的解决方案包括转换和加载数据，而不是转换这两项任务，换句话说，先加载数据，然后再进行转换，这可能会减少汇总所消耗的时间。在加载阶段，问题是：性能下降和OLAP内部不一致。在解决这些问题的方案中包括：暂存表（Trickle and Flip），多级的Trickle and Flip，在DW更新期之外的组织，快照数据，实时数据缓存和基于层的视图等都被提出。从这项工作的一部分来看，在调查ETL在近实时的挑战方面没有做太多工作。

4 实时数据仓库架构

在实时数据仓库体系结构方面已经做了大量工作。作为拟议架构的一个示例，我们将在下面详细介绍Vassiliadis et al.，2009和Obali et al.，2013的方法。

4.1 Vassilidis 等人的架构，2009

图1显示了被称为RTDWg的一般建议架构。它处理的是连续加载，而不是传统中的周期性加载。

图1. 近实时数据仓库的架构[9]

它由三个主要部分组成。(1) 承载填充数据仓库的生产系统的数据源，(2) 中间的数据处理区（DPA），在这里进行数据的清理、提取和转换，(3) 数据仓库。

每个数据源都有一个源流量调节器（SFlowR）模块，负责识别相关变化，并将其传播到DW。然后，数据处理流量调节器（DPFlowR）模块负责决定哪个源准备好传输数据。仓库流量调节器（WFlowR）协调数据从DPA到仓库的传播。这种传播是基于终端用户提出查询的当前工作负荷以及对数据新鲜度、ETL吞吐量和查询响应时间的要求[9]。

4.1 4.2 Obali 等人的架构，2013

如下图，提出的 RTDW 可确保近乎实时地访问来自不同数据源的采集数据 [7]。该架构的组件包括：Web 服务客户端、Web 服务提供者、元数据、ETL、实时分区、数据仓库和实时数据集成（图 2）。

图2. 基于 Web 服务的实时数据仓库架构 [7]

Web服务（WS）客户端用于从原始数据系统中获取数据变化（称为变化数据捕获-CDC），并通过调用相关的网络服务将其发送到网络服务提供者。DW所需的数据是从业务系统和其他外部来源收集的。正在使用的数据捕获（CDC）技术包括：源数据提取、日志捕获、触发式捕获、应用辅助捕获、基于时间戳的捕获和文件比较捕获[7]。

Web服务提供者获得由RTDW网络服务客户端发送的数据，并将它们添加到实时分区中。这个组件获得由RTDW Web服务客户端发送的数据传输对象，并将它们分解成两部分：数据和元数据。RTDW Web服务使用元数据通过SQL-Generator生成结构化查询语言（SQL），将数据插入到RTDW日志表中，然后在RTDW数据库中执行这些生成的SQL，并插入数据。在实时分区中，作者使用了三个阶段：第一步包括将CDC数据放入相关的仓库日志表。第二步包括按需清洗CDC日志数据，最后一步是按需清洗的CDC数据的汇总。

实时数据集成组件用于整合实时分区和数据仓库中的数据。当用户向该组件发送查询时，如果查询只需要历史数据，那么该组件将查询发送到数据仓库；如果查询需要历史和实时数据，那么该组件将重写查询以获得和整合数据[7]。

5 处理实时数据集成的方法

为了使数据集成接近实时，不同的方法[2,4,5]已经处理了实时数据仓库中的数据整合。

5.1 Lebdaoui等人的方法，2013年

在[4]中，作者处理了数据完整性问题，以满足访问RTDW的需要，并引入了一个IA-RTDWg模型，同时保留了数据完整性和可用性。在这项工作中，作者讨论了关于违反RTDWg时间限制的数据完整性。他们还介绍了他们的模型，该模型是基于事实表的临时复制，这些事实表与数据的变化有关，同时保持其完整性约束。为了管理实时数据的变化，RTDW使用特定的标准或措施，如：实时表、实时分区和智能搜索工具，根据数据的重要性来确定整合的优先次序。

RTDW 系统必须确保数据完整性。如果有人可以访问刚刚被 CDC 机制捕获或被 ETL 工具转换的数据并非法修改它们，那么完整性就会被剥夺。如果 DW 解决方案中的程序或工具未根据预定义的规则处理数据，并且如果 DW 步骤被忽略或跳过，则完整性也可能被破坏。

5.2 Ferreira 等人的方法，2013

在行业和理论思想的基础上，[2]定义了一个数据仓库架构，用于在不影响请求性能的情况下进行持续的数据整合，并评估其提供实时性的能力。

在这个实时数据仓库中，作者定义了一个动态存储组件和一个静态存储组件，分别代表最近集成的数据和其余的数据，并对组件的合并方式进行了适当的选择。他们还提出了有关查询机制计算的设计选择，并对备选方案进行了估计，以得出什么是这些机制的最有效的实现。

作者从一个基本的DW架构中提出了RTDW架构。 这种方法能够更新连续的数据，同时在DW中保持最新的信息，并使查询具有任何所需的新鲜程度。 该架构由三个主要部分组成。它们是动态数据仓库（DW-D）、静态数据仓库（S-DW）和融合。在[2]中，作者还提出了一个允许实时整合新数据的解决方案。该解决方案涉及将数据有效加载到一个拥有最新信息并提供快速整合机制的组件--D-DW。 这个组件的创建是为了让整合的速度非常快。由于数据量小，查询运行很快，并引入了低效率的充电。 这个D-DW组件可以在内存中运行。然而，数据仓库也是一个庞大的历史数据集，而处理这些数据是一项成本很高的任务。这些历史数据被存储在S-DW组件中，鉴于D-DW组件独立于S-DW运行。有了这个架构（图3.），就有可能为不断的整合、新的数据提供保证，同时，在没有明显的额外性能成本的情况下，既可以访问最多的数据，也可以访问最少的数据。

图3. 提议的 RTDW 草图 [2]

5.3 Lebdaoui 等人的方法，2014

为了对未来做出快速而有效的决策，数据仓库必须反映业务数据的真实变化，并为分析系统提供最新鲜的数据。在[5]中，作者提出了一种改进数据整合的新方法，同时在尊重现有安全规则的前提下保持数据的完整性。他们在短时间内处理了数据仓库中大量数据的整合问题，并提出了一个新的模型，称为分割-连接数据整合（DJ-DI）。这个模型建立在划分数据变化量和事实表的重复上，与普通配置相比，数据整合率有了真正的提高。作者进行了各种模拟DJ-DI模型作为一个实验平台。结果表明，DJ-DI模型对数据整合率有显著的改善。

6 讨论

应该注意的是，大多数提出的关于RTDW的研究都没有明确ETL的实时架构。只有Wibowo A.的工作[10]专门确定了ETL过程中每个阶段的问题及其解决方案。[2,4,5]研究了在RTDW中处理集成数据。此外，所有提出的方法都集中在RTDW的架构上，没有详细说明这些架构的设计和实现。表2给出了基于一些标准的文献综述的摘要。

表 2. 文献综述总结

 7 结论

在本文中，我们通过指出问题和解决方案来处理一项关于数据仓库实时性的调查，以便更接近RTDW。这项调查的重点是现有数据仓库架构的文献回顾。然后，详细介绍了ETL过程中处理实时数据仓库系统的变化，以及如何在RTDW中处理集成数据。未来的研究中，我们将提出一个包含RTDW构造的通用体系结构，并使用实时UML标准对RTDW进行建模。考虑到实时收集的数据的特殊性，我们考虑RTDW和实时ETL过程的加载策略。

参考文献

1. Basu, R.: Challenges of real-time data warehousing (2003). www.dmreview.com
2. Ferreira, N., Martins, P., Furtado, P.: Near real-time with traditional data warehouse architectures: factors and how-to. In: Proceedings of the 17th International Database Engineering & Applications Symposium, IDEAS’13, New York, NY, USA, pp. 68–75. ACM (2013). http://doi.acm.org/10.1145/2513591.2513650
3. Langseth, J.: Real-time data warehousing: Challenges and solutions (2004). http://dssresources.com
4. Lebdaoui, I., Orhanou, G., ElHajji, S.: Data integrity in real-time data warehousing. In: Proceedings of the World Congress on Engineering, vol. 3 (2013）
5. Lebdaoui, I., Orhanou, G., Elhajji, S.: An integration adaptation for real-time datawarehousing. Int. J. Softw. Eng. Appl. 8(11), 115–128 (2014)
6. Levy, E.: What is real-time data warehousing? (2005). www.dmreview.com
7. Obali, M., Dursun, B., Erdem, Z., Grr, A.K.: A real time data warehouse approach for data processing. In: Signal Processing and Communications Applications Conference SIU 2013 21st, pp. 1–4 (2013)
8. Santos, J.R., Bernardino, J.: Real-time data warehouse loading methodology. In: Proceedings of the 2008 International Symposium on Database Engineering & Applications, IDEAS’08, New York, NY, USA, pp. 49–58. ACM (2008). http://doi.acm.org/10.1145/1451940.1451949
9. Vassiliadis, P., Simitsis, A.: Near real time ETL, pp. 1–31. Springer, Boston (2009). http://dx.doi.org/10.1007/978-0-387-87431-9 2
10. Wibowo, A.: Problems and available solutions on the stage of extract, transform, and loading in near real-time data warehousing. In: 2015 International Seminar on Intelligent Technology and Its Applications (ISITIA), pp. 345–350, May 2015