数据架构 | 逻辑数据仓库与物理数据仓库性能对比

在逻辑数据湖和逻辑数据仓库方法中，数据虚拟化系统在多个数据源之上提供统一的查询访问和数据治理功能（见图1）。这些数据源通常包括一个或多个物理数据仓库、Hadoop 集群、SaaS 应用程序以及其他数据库。两种方法的主要区别在于：逻辑数据湖更强调 Hadoop 的作用，而逻辑数据仓库则更偏向传统的 BI（商业智能）流程。

数据虚拟化集成示意图
图1： 在“逻辑数据仓库”和“逻辑数据湖”方法中，数据虚拟化系统在多个数据源之上提供统一的报表与治理功能。这些数据源通常包括一个或多个物理数据仓库或数据集市（Data Mart）、基于 Hadoop 的系统、业务运营数据库、SaaS 应用（例如 Salesforce）等。

逻辑数据湖和逻辑数据仓库的吸引力在于，与“物理”方法相比，它们可以节省大量的时间和成本。在“物理”方法中，所有数据都需要预先复制到一个单一系统中。数据复制意味着更高的硬件成本、更多的软件许可费用、更多需要开发和维护的 ETL 流程、更大的数据不一致风险以及更高的数据治理成本。此外，这也意味着更长的上市时间。而逻辑方法则能够利用现有系统，最大限度地减少甚至完全消除对数据复制的需求。

然而，在这些“逻辑”方法中，数据虚拟化服务器需要在多个系统之间执行分布式查询。因此，自然会有人问：这些查询的性能与“物理”方法相比如何？

正如我们在之前的文章中所展示的，即使是需要处理数十亿行数据的复杂分布式查询，如果使用正确的优化技术，也可以通过网络传输非常少量的数据来完成。现在，是时候用一个真实的示例来量化这些技术的性能了！

示例场景：逻辑数据仓库性能测试

请看图2中简化的逻辑数据仓库场景。在这个场景中，信息分布在三个不同的系统中：

• 包含销售数据的 Netezza 系统（大约 2.9 亿行数据）
• 包含客户信息的 Oracle 数据库（大约 200 万行数据）
• 包含产品信息的 SQL Server 数据库（大约 20 万行数据）

这些表的模式和数据由 TPC-DS 定义，这是决策支持系统行业最重要的基准测试标准。

逻辑数据仓库场景
图2： 一个简化的“逻辑数据仓库”场景。销售数据、客户数据和产品数据分布在三个不同的系统中。

性能测试结果

以下表格展示了一些常见决策支持查询在“逻辑”场景（使用 Denodo 作为数据虚拟化工具）和“物理”场景（将所有数据预先复制到 Netezza 系统中）的执行结果对比：

数据分析

• 查询条件的选择性较低：从第一列可以看出，这些查询并未使用高度选择性的条件。例如，第1和第3行的查询完全没有指定过滤条件，因此需要在各自的数据源中处理数亿行数据。
• 返回结果规模较大：第二列显示，查询返回了数百万行的结果。
• 性能差异很小：第三列和第四列的对比表明，逻辑方法与物理方法之间的性能差异非常小。

最后一列展示了每个查询执行时，Denodo 自动选择的优化技术（这些技术在之前的文章中有详细描述）。

数据查询优化策略： 全聚合下推、分区剪枝、部分聚合下推以及动态数据迁移-CSDN博客文章浏览阅读128次，点赞2次，收藏4次。关于数据虚拟化在逻辑数据仓库和逻辑数据湖架构中查询优化的实际应用示例。全聚合下推、分区剪枝、部分聚合下推以及动态数据迁移https://blog.csdn.net/Denodo/article/details/145002597?spm=1001.2014.3001.5501

结论

在这一系列文章中，我们比较了逻辑数据仓库和逻辑数据湖方法与“物理”方法的性能表现。在“物理”方法中，所有数据都需要预先复制到一个单一系统中。我们证明了，在处理数十亿行数据的复杂 BI 查询（甚至不使用任何过滤条件）时，逻辑方法仍能够实现与物理方法相当的性能。

实现这一点的关键在于，数据虚拟化系统能够智能地选择和应用一系列优化技术，最大限度地减少网络中的数据传输量。此外，逻辑方法还避免了与基于复制的方法相关的大量时间和精力投入，提供了更短的上市时间，并为统一的安全性和治理功能提供了单一入口。

我们认为，这一洞察对于当前和未来的 BI 和大数据架构具有重要意义。