数据编织的性能 2024-数据虚拟化架构比较

denodo·······I概述3I引言：数据虚拟化架构4专用数据虚拟化层具有数据虚拟化扩展的数据引擎4I数据虚拟化架构中的查询执行比较5专用数据虚拟化层具有数据虚拟化扩展的数据湖引擎7混合方法I基准测试11I总结18数据编织背后的一个关键思想是，能够通过一个易于使用的中心化接数据编织背后的一个关键思想是，能够通过一个易于使用的中心化接入点访问组织中的任何数据资产。最终用户不必应对幕后的复杂数据数据虚拟化层可以实现这一点，它可以抽象出复杂性，并提供中心化的接入点。除了集中访问之外，该层通常还提供其他功能，如缓存、安全、建模和跨源联合等，能够在整个组织中统一实施。即使公司数据分散在数十个异构系统中，这些功能仍将让最终用户感觉，所有数从业务角度来看，数据编织的主要目标是创建一个敏捷平台，通过自助服务数据层，以业务部门可以理解和使用的方式公开数据，从而缩短获取数据的您可以在下面的“基准测试”小节中找到测试方法和环境规格的详细说明。在这里，我们先简要总结测试结果。26.52秒这些结果展示了分布式环境中专用数据虚拟化层的强大能力。在这种环境下，其引擎的复杂程度©2024DenodoTechnologies3数据管理供应商采用两种主要的数据虚拟化技术来提供跨多个数据源的通用访问层。在本节中，我们将比较它们的在这类架构中，虚拟化层位于所有数据源之上，提供一个中心化接入点。它分析传入的查询并将每个请求转发到包含相应数据的数据源。这个过程被称为“查询下推”或“查询委托”。由于查询可能涉及来自多个数据源的表，因此这类软件需要包含具有跨数据源联合功能的引擎和目的驱动型优化器。缓存、聚合感知加速等技术被频繁使用。在这类架构中，数据系统包含一个扩展，不仅能够链接自有数据，也能链接外部数据源。这种架构例子早期包括在这些系统中，当请求外部数据时，工作器节点会查询外部表，并将其输入并行引擎处理管道。此类供应商也提供++++++++++++++++云云++十+++ >云数据湖数据湖/湖仓一体分布式文件系统分布式文件系统专用数据虚拟化对比数据湖扩展两种架构都允许最终用户在分布式数据环境中运行查询，但处理方式显著不同。下一节我们将深入探讨这些设计差值得注意的是，专用数据虚拟化解决方案通常包含额外功能（例如高级建模、数据沿袭和治理用于创建和管理跨多个数据源的语义层。数据湖供应商往往更关注针对对象存储中的数据执行查询，这些功能的分析不在本白皮书©2024DenodoTechnologies专用数据虚拟化层将充当关系数据库系统，但有一个重大区别：它们仅托管元数据，它们可以表示对象的元数据（如表、视图和存储过程），这一点与其他任何数据库无异，但它们实际上并不托管数据。数据结果总是从原始数据源或缓存中获取，并按需查询。这些元数据不仅包含表名、列和数据类型，还包含执行底层数据源查询所需的所有信息。其中一些细节包括：数据源类型、版本和供应商；数据类型和结构映射；用于成本估算的数据统计；以及 基于规则的优化器↓执行计划查询解析基于成本的优化器分析元数据和源功能 基于规则的优化器↓执行计划查询解析基于成本的优化器分析元数据和源功能a.利用底层系统的处理能力。这种技术被称为“查询下推”，对于具有处理能力的底层数据源（如关系数据i.此步骤至关重要，因为它使引擎能够利用数据源所这是首选策略。执行计划将整个数据集引入虚拟化引擎，执行任何其他操作（如：列转换、聚合等）。©2024DenodoTechnologies52.数据分布在多个系统中。在这种情况下，数据虚拟化优化器需要在多种操作技术中选择，例如连接或聚合（内存合并、哈希连接、嵌套循环、数据即时移动到临时表等）和查询重写规则（分支修剪、部分聚合拆分等）。基于成本的优化器发挥着重要作用，因为它使用全面的数据源统计数据和其他数据源详细信息（例这是此类架构中引擎最复杂的部分，查询性能在很大程度上取决于优化器做出的决定。我们将在下面看到3.两种技术的结合。在大多数查询中，即使数据分布在多个数据源中，执行也会同时使用上述两种技术，因为可能有些操作可以下推，而其他操作可以后处理。例如，您可能要连接三个表，但如果其中两个表位于同一结果是一个执行计划中包含一个或多个“执行分支”，这些分支通常并行执行，以到达每个数据源并检索部分数据优化器将生成算法和查询重写规则的多种组合，估算每一步涉及的数据量，并根据估算成本选择最优方案。例如，以分组依据JOIN分组依据JOIN数据移动数据移动分组依据JOIN分组依据JOIN200万200万3亿200万临时Customer临时Customer朴素策略朴素策略数据移动分组依据分组依据JOIN200200万分组依据Customer分组依据CustomerID200200万部分聚合下推©2024DenodoTechnologies6的直接转换。数据将同时从销售表和客户表中提取，数据虚拟化引擎会使用一种可用技术（如合并或哈希连接），在内存中合并数据，随后按照国家/地区进行汇总，生成最终输出。该策略的最大不足是，需要移动大量数据（3.02亿行），并在引擎中进行处理，才能产生相步骤执行。第一步，从PostgreSQL中检索客户数据，并将其移动至由于所有数据都存在于Snowflake中，整个查询处理将被下推到Snowflake，并发送给使用者。我们可以看到，数据移动已大幅减少到仅200万行，并且所有处理都已下推到并未采用朴素策略，而是将查询重写为更高效的形式。为了最大程度地实施查询下推，聚合将分为两个按国家/地区进行。尽管可能有违直觉，但它显著减少了网络流量和数据虚拟化引擎中的处理量，同时充分利用Snowflake等引擎的MPP但这个例子只触及了问题表面，例如，我们没有涉及连接算法或表顺序等主题，另外需要注意的是，我们没有采用任何缓存或聚合感知加速技术，仅仅是实时执行（有关这些方案的更多详细信息，请参阅下面的“其他加速技术”■工作器节点，负责执行查询和处理数据，还负责获取数据（通常从对象存储中获取），并可以相互通信。©2024DenodoTechnologies数据流------->其他调用客户端应用程序对象存储对象存储在执行管道方面，当协调器接收到查询后，它会解析查询，将其映射到元存储中的信息，并利用其优化器创建分布式查询计划。查询计划以层级化任务结构形式构建，这些任务在各工作器节点上运行。每项任务都会操作一个数据 元存储客户端应用程序客户端应用程序协调器协调器工作器工作器工作器200万工作器200万工作器在数据传输上也有同样问题。此外，数据湖引擎的优化器并不像专用数据虚拟化引擎那样，提供各种可联合的先进©2024DenodoTechnologies即使所有数据都在同一个数据源中，大多数数据湖引擎也会使用这种相同的执行模式，因为连接器不具备高级SQL方言转换逻辑、复杂数据类型的映射，以及关于数据源逻辑的其他信息，例如数据整理（数据源对非数字值进行排序的方式）。这意味着数据湖引擎将对每张表进行扫描，并使用自己的引擎处理来自外部源的查询。这种方法有一些优点（例如，减少遗留数据源的工作负载但也存在重大问题。例如，无法利用数据源的内部结构来加速处理值得注意的还有，以数据湖为中心的生态系统中，经常会看到将数据湖内容与外部系统混合在一起的查询。这类目前，我们可以看到，许多供应商正在跨越不同架构界限，融合两种方法概念的混合型产品变得十分常见。实际大的下推功能，这些功能是对其开源版本所提供功能的扩展。这些功能使引擎能够下推一些额外操作，如连接。尽Warehouse调度程序数据目录+++++++++.虚拟化服务器对象存储数据科学笔记本其他应用程序本地数据Warehouse调度程序数据目录+++++++++.虚拟化服务器对象存储数据科学笔记本其他应用程序本地数据操作型操作型©2024DenodoTechnologies几乎所有供应商都提供缓存功能。缓存允许引擎重复使用之前计算的结果。大多数供应商还提供更新缓存内容的功能，以保持其时效性（通常通过增量更新实现，以避免全盘更新）。此外，De当优化器检测到“缓存命中”时，无论是完全命中，还是部分命中，都会将引擎重定向到缓存系统，以检索该数据，此外，Denodo还提供聚合感知加速，该技术将利用聚合产生的较小数据集，以及“分析查询经常聚合原始数据，产生最终结果”这一事实。例如，回想上一节中描述的“按国家/地区的总销售额”查询，聚合感知加速所基于的理念是：预聚合的中间结果可用作计算最终结果的基础，比使用原始表快得多。这项技术有两大优势，在分析领域极为有用：■不需要最终用户的输入。执行引擎会自动检测可加8使用Denodo平台进行聚合感知查询加速的效果。所有查询均利用基于人工智能推荐创建的单一加速结构，执行时间以秒为单位。864200©2024DenodoTechnologies最后，要让这项技术有效发挥作用，关键在于熟练选择应进行预计算和预聚合的数据，但这种决策并非易事。幸运的是这方面，人工智能可以提供帮助，Denodo等供应商提供了人定制推荐。关于这项功能的更深入解释，可在这篇文章中找到，基于人工智能的推荐引擎在这篇文章中有描述。 15,000,000150,000,000600,037,90280,000,00020,000,0001,000,000255<<<<<<<<2555©2024Denodo123456此查询量化了如果在给定年份消除特定百分比范围内的全公司折扣，将会带来789©2024DenodoTechnologies对于数据湖引擎，我们使用了数据湖领域一家领先开源供应商的最新版本（撰写本文时的2024年2月版■20个工作器节点■©2024DenodoTechnologies在这个场景中，我们要模拟的查询需要完全存储在外部系统中的数据。例如，您可能需要使12349205.3330807845624604.5789252964948498826524.9918508624.5执行时间以毫秒为单位。两个引擎均成功完成了所有测试。然而很明显，Denodo平台的专用架构能够利用对外部企业数据仓库（如Redshift）的访问能力，其速度比数据湖引擎快几个数量级。如上一节所述，为每张表使用一个工作器的数据湖策略需要在网络上移动大量数据，因此即使有20个节点并行处理查询，执行时间也明显高于Denodo平台执26.52秒26.52秒另外需要注意的是，一些数据湖供应商在其商业产品中提供企业连接器，其下推逻辑比这些测试中使用的开源版本场景2：联合两个外部源26756354005.25720549.2533284488920478199063.58835578执行时间以毫秒为单位。数据湖引擎采用的执行计划非常相似，即基于将工作器映射到数据源表。值得注意的是，在这次联合测试中，一些查询速度更快。考虑到数据湖引擎中的执行计划几乎完全相同，解释为数据源的工作负载减少了，现在分成了两个©2024DenodoTechnologies场景3：联合数据湖和小型外部源数据湖引擎高度关注将数据湖作为生态系统核心部分的场景，测试部分数据集位于数据湖中的场景也是合理的。本规格与其他数据湖供应商完全相同。在本特定案例中，我们将大型事实表置于数据湖中，而较小的维度表则存放在237070.2556929.2523262.578024892047869454.25执行时间以毫秒为单位。两家供应商均成功完成所有测试。这种场景正是数据湖的强项，在并行访问事实表的情况下，可以并行处理大部分2分29秒©2024DenodoTechnologies场景4：联合数据湖和大型外部源作为上述场景变体，我们修改了表的分布，使大型表格位于数据湖之外，代表了例如企业数据仓库中大型表需要与