当前位置：首页 > news >正文

NoETL | 数据虚拟化如何在数据不移动的情况下实现媲美物理移动的实时交付？

news 来源：原创 2025/6/11 5:56:17

在我们之前的文章中，我们回顾了Denodo在逻辑数据仓库和逻辑数据湖场景中所使用的主要优化技术（具体内容请参阅之前的文章）。

数据架构 | 逻辑数据仓库与物理数据仓库性能对比_物理数仓、逻辑数仓-CSDN博客文章浏览阅读1.5k次，点赞33次，收藏28次。在逻辑数据湖和逻辑数据仓库方法中，数据虚拟化系统在多个数据源之上提供统一的查询访问和数据治理功能（见图1）。这些数据源通常包括一个或多个物理数据仓库、Hadoop 集群、SaaS 应用程序以及其他数据库。两种方法的主要区别在于：逻辑数据湖更强调 Hadoop 的作用，而逻辑数据仓库则更偏向传统的 BI（商业智能）流程。在“逻辑数据仓库”和“逻辑数据湖”方法中，数据虚拟化系统在多个数据源之上提供统一的报表与治理功能。_物理数仓、逻辑数仓https://blog.csdn.net/Denodo/article/details/145004420?spm=1001.2014.3001.5501数据查询优化策略：全聚合下推、分区剪枝、部分聚合下推以及动态数据迁移_查询数据下推-CSDN博客文章浏览阅读1.5k次，点赞42次，收藏26次。关于数据虚拟化在逻辑数据仓库和逻辑数据湖架构中查询优化的实际应用示例。全聚合下推、分区剪枝、部分聚合下推以及动态数据迁移_查询数据下推https://blog.csdn.net/Denodo/article/details/145002597?spm=1001.2014.3001.5501数据湖与逻辑数据仓库的兴起：迈向 NoETL 数据虚拟化时代-CSDN博客文章浏览阅读1.6k次，点赞42次，收藏46次。逻辑数据仓库通过数据虚拟化技术，为企业提供了一种灵活、实时且高效的数据管理方案，帮助企业摆脱数据孤岛的困扰，提升跨部门协作的效率，并在竞争激烈的市场中保持敏捷性。https://blog.csdn.net/Denodo/article/details/145014913?spm=1001.2014.3001.5501

我们还提供了真实数据，证明如果数据虚拟化系统为每个查询采用正确的优化技术，逻辑架构的性能可以媲美传统物理架构。

但是，数据虚拟化（DV）系统如何为每个查询选择合适的优化技术呢？

答案是基于成本的优化：针对一个查询，DV系统会生成一组候选执行计划，估算它们的成本，并选择成本估算最低的计划。

这听起来与关系数据库的查询优化方式非常相似。实际上，大多数DV系统（以及一些大数据厂商商业化的“数据虚拟化”扩展）依赖于传统的数据库成本估算方法，仅进行了微小调整。然而，这通常会导致较大的估算误差，因为传统方法设计用于单一系统场景，而数据虚拟化查询需要整合多个异构数据源的数据。而Denodo的成本估算过程从零开始设计，专门考虑了DV系统中查询执行的特性。

为了说明DV系统需要考虑的成本因素，图1和图2展示了一个查询的两个候选执行计划。该查询整合了存储在传统数据库中的产品数据与存储在并行数据库中的销售数据，目的是获取过去9个月中每个产品应用的最大折扣。折扣是通过从产品数据库中的“标价”减去销售数据库中的“售价”计算得出的。您无需深入了解这些计划的细节，只需了解DV系统中查询的候选计划由哪些执行步骤组成即可。

正如上述图表所示，DV系统中的查询计划通常包括以下步骤：

将查询下推到不同类型的数据源。例如，Denodo将查询下推到传统数据库（计划A和计划B的步骤1）和并行数据库（计划A的步骤3，计划B的步骤4）。在许多场景中，还可能涉及其他类型的数据源，如Hadoop集群或SaaS应用。
从数据源向DV系统传输数据。在上述示例中，这对应于计划A中的步骤2和4，以及计划B中的步骤2和5。
向数据源中插入数据。“动态数据移动”优化技术（计划B中使用）通过将一个小型数据集从一个数据源移动到另一个数据源的临时表中，在目标数据源内直接整合数据集。因此，估算此操作的成本需要考虑数据插入成本（计划B中的步骤3）。
在DV系统中后处理并整合部分查询结果（计划A中的步骤5）。

接下来，我们分析成功估算这些步骤成本所需的信息：

1. 数据统计信息

与关系数据库中的基于成本优化类似，DV系统需要参与查询的关系的统计信息。这些统计信息可用于估算每个查询计划步骤中输入数据的大小，这是影响成本的关键因素。

由于DV系统并未本地存储实际数据，因此无法像传统数据库那样生成统计信息。Denodo通过以下两种方式解决该问题：

如果数据源自身维护统计信息（如大多数数据库），Denodo可以直接从数据源目录表中获取。
如果数据源不维护统计信息或无法对外部程序开放，Denodo可以通过对数据源执行预定义查询来计算统计信息。

2. 索引和物理数据访问结构

DV系统需要了解数据源中的索引（或其他物理数据访问结构）信息。下推到数据源的查询性能可能因可用索引的不同而发生数量级变化。Denodo会自动从支持索引信息公开的数据源中获取相关信息（如大多数数据库），或允许用户在无法自动获取时手动声明。

3. 针对不同数据源的成本估算模型

为了估算下推到数据源的查询成本，DV系统需要针对每种类型的数据源建立不同的成本估算模型。不同数据源的性能差异可能非常大，仅靠简单的修正因子（例如假设并行数据库查询速度是常规数据库的n倍）远远不够。有些查询中，并行数据库的速度比传统数据库快数个数量级，而另一些查询中，差异可能很小甚至不存在。因此，准确的估算需要详细计算，充分考虑每个系统的查询执行机制。

此外，还需要考虑数据源硬件的一些特性。例如，在一个拥有96个处理核心的并行数据库上执行查询，与在只有48个处理核心的数据库上执行查询的成本完全不同。

数据插入成本（操作类型3）的差异也需要根据数据源类型单独考虑。

为此，Denodo为逻辑数据仓库/数据湖场景中常见的主要数据源类型（包括传统数据库、并行数据库和Hadoop集群）提供了特定的成本估算模型。

4. 数据传输速度

DV系统还需要考虑从每个数据源传输数据的相对速度。例如，从本地数据库获取10万行数据的成本与从SaaS应用（如Salesforce）获取相同数据的成本差异巨大。Denodo允许为不同数据源指定数据传输因子，以考虑DV系统与数据源之间的传输速率差异。

Denodo是市场上唯一能够综合考虑数据源索引、数据传输速率，以及并行数据库和大数据源查询执行模型的DV系统。一些传统数据库和大数据系统的“数据虚拟化扩展”甚至不考虑虚拟关系的统计信息。在没有这些关键信息的情况下，DV系统无法自动生成高效的执行计划。在最好的情况下，您不得不手动优化每个查询，这会显著增加成本并降低灵活性。而在无法手动调整查询的情况下（例如由BI工具生成的查询），您可能面临性能问题。

因此，我们的建议是：在评估DV供应商和大数据集成解决方案时，不要满足于笼统的“支持基于成本的优化”声明，而应深入了解这些方法所考虑的信息以及它们能够自动做出的决策，从而明确预期性能。

1. 数据统计信息

2. 索引和物理数据访问结构

3. 针对不同数据源的成本估算模型

4. 数据传输速度

相关文章：