《Denodo：2024数据编织的性能-数据虚拟化架构比较白皮书（19页）.pdf》由会员分享，可在线阅读，更多相关《Denodo：2024数据编织的性能-数据虚拟化架构比较白皮书（19页）.pdf（19页珍藏版）》请在本站上搜索。 1、数据虚拟化架构比较白皮书数据编织的性能 2024 Denodo Technologies作者：Pablo lvarez Yez目录I3I444I5579101010I1112131314151617I18概述专用数据虚拟化层具有数据虚拟化扩展的数据引擎场景 1：访问外部源场景 2：联合两个外部源场景 3：联合数据湖和小型外部源场景 4：联合数据湖和大型外部源引言：数据虚拟化架构数据虚拟化架构中的查询执行比较总结专用数据虚拟化层具有数据虚拟化扩展的数据湖引擎混合方法其他加速技术缓存聚合感知加速基准测试查询环境规格基准测试场景基准测试3 2024 Denodo Technologies概述场景专用2、数据虚拟化层：Denodo 平台具有数据虚拟化扩展的数据引擎：领先的数据湖供应商访问外部源26.52 秒3 分 19 秒5 小时 8 分 28 秒联合两个外部源2 小时 27 分 15 秒联合数据湖和小型外部源2 分 29 秒2 分 13 秒联合数据湖和大型外部源6 分 16 秒4 小时 10 分 32 秒这些结果展示了分布式环境中专用数据虚拟化层的强大能力。在这种环境下，其引擎的复杂程度和专业化程度超越了数据湖并行引擎在访问外部数据集和多源数据联合的潜在优势。数据编织背后的一个关键思想是，能够通过一个易于使用的中心化接入点访问组织中的任何数据资产。最终用户不必应对幕后的复杂数据生态系统，也不3、需要了解组织中每个数据库和应用程序的实质细节。数据虚拟化层可以实现这一点，它可以抽象出复杂性，并提供中心化的接入点。除了集中访问之外，该层通常还提供其他功能，如缓存、安全、建模和跨源联合等，能够在整个组织中统一实施。即使公司数据分散在数十个异构系统中，这些功能仍将让最终用户感觉，所有数据都整合并存储在单一系统中。专用数据虚拟化层数据编织供应商采用两种主要架构提供这种功能：具有数据虚拟化扩展的数据引擎从业务角度来看，数据编织的主要目标是创建一个敏捷平台，通过自助服务数据层，以业务部门可以理解和使用的方式公开数据，从而缩短获取数据的时间。在这份白皮书中，我们将详细探讨这两种架构，并重点关注这些实现4、决策对查询执行性能的影响。为进一步说明这两种架构之间的差异，我们使用 TPC-H 展开广泛的基准测试，展示这两种架构在不同场景下的表现。您可以在下面的“基准测试”小节中找到测试方法和环境规格的详细说明。在这里，我们先简要总结测试结果。4 2024 Denodo Technologies引言：数据虚拟化架构数据管理供应商采用两种主要的数据虚拟化技术来提供跨多个数据源的通用访问层。在本节中，我们将比较它们的共通点和差异。专用数据虚拟化层在这类架构中，虚拟化层位于所有数据源之上，提供一个中心化接入点。它分析传入的查询并将每个请求转发到包含相应数据的数据源。这个过程被称为“查询下推”或“查询委托”。由5、于查询可能涉及来自多个数据源的表，因此这类软件需要包含具有跨数据源联合功能的引擎和目的驱动型优化器。缓存、聚合感知加速等技术被频繁使用。Denodo 就是这类技术提供商。具有数据虚拟化扩展的数据引擎在这类架构中，数据系统包含一个扩展，不仅能够链接自有数据，也能链接外部数据源。这种架构例子早期包括Oracle DB 链接或 Microsoft SQL Server 链接服务器等工具。目前，许多具备并行处理MPP功能的数据湖引擎都实现了此类架构，如 Spark、Dremio 或 Starburst(Trino)。因此，对于这一类别，本白皮书的重点将放在数据湖引擎上。在这些系统中，当请求外部数据时，6、工作器节点会查询外部表，并将其输入并行引擎处理管道。此类供应商也提供缓存之类技术。专用数据虚拟化对比数据湖扩展两种架构都允许最终用户在分布式数据环境中运行查询，但处理方式显著不同。下一节我们将深入探讨这些设计差异对查询执行性能的影响。数据湖/值得注意的是，专用数据虚拟化解决方案通常包含额外功能（例如高级建模、数据沿袭和治理），用于创建和管理跨多个数据源的语义层。数据湖供应商往往更关注针对对象存储中的数据执行查询，这些功能的分析不在本白皮书讨论范围之中，您可以在白皮书释放数据生态系统的全部潜力中找到更深入的讨论。湖仓一体分布式文件系统（S3、ADLS、HDFS）云传统DB 和 DW专用数据虚拟化7、层云传统DB 和 DWExcel数据湖分布式文件系统5 2024 Denodo Technologies1.应答查询所需的所有数据都在同一系统中。专用数据虚拟化引擎的查询优化管道初始元数据分析期间，引擎可以检测两种可能的场景，并利用这些信息比较可行的查询执行技术：根据数据源的特征，引擎可以决定：a.利用底层系统的处理能力。这种技术被称为“查询下推”，对于具有处理能力的底层数据源（如关系数据 i.库、MongoDB，甚至是像 Salesforce 这样的系统），是首选方法。此步骤至关重要，因为它使引擎能够利用数据源所有与处理能力相关的功能，例如并行处理、索引、缓存、分区，以及数据源引擎可用于加快8、执行速度的其他工件。ii.为高效完成这项工作，引擎必须充分理解数据类型映射、SQL 方言，以及针对每个供应商/版本的转换b.使用自己的引擎。这种技术通常称为“后处理”，对于不具备处理能力的数据源（例如 Excel 函数语法。SQL 转换的质量越高，性能越好。电子表格），这是首选策略。执行计划将整个数据集引入虚拟化引擎，执行任何其他操作（如：列转换、聚合等）。基于规则的优化器基于成本的优化器数据虚拟化架构中的查询执行比较现在，让我们来重点探讨这些架构的运作方式，以及这些架构差异对查询执行和性能的影响。专用数据虚拟化层专用数据虚拟化层将充当关系数据库系统，但有一个重大区别：它们仅托管元数据，它们可9、以表示对象的元数据（如表、视图和存储过程），这一点与其他任何数据库无异，但它们实际上并不托管数据。数据结果总是从原始数据源或缓存中获取，并按需查询。这些元数据不仅包含表名、列和数据类型，还包含执行底层数据源查询所需的所有信息。其中一些细节包括：数据源类型、版本和供应商；数据类型和结构映射；用于成本估算的数据统计；以及特定配置，如批量加载设置、API 中的分页等。数据虚拟化扩展的数据引擎仅仅支持 RDBMS 和 noSQL，相比之下，这种架构通常支持更广泛的数据源。当最终用户发出查询时，优化器会构建执行计划，涉及多个步骤，首先是分析查询中涉及的表/视图的元数据。SQL查询解析分析元数据和源功能执10、行计划6 2024 Denodo TechnologiesSELECT c.country,SUM(s.amount)FROM psql.customer c JOIN sf.sales sON c.id=s.customer_idGROUP BY c.country优化器将生成算法和查询重写规则的多种组合，估算每一步涉及的数据量，并根据估算成本选择最优方案。例如，以该查询计算每个国家/地区的总销售额。作为背景信息，我们假设 Customer 表位于 PostgreSQL 中，有 200 万行数据，而 Sales 表位于 Snowflake 中，有 3 亿行数据。如何处理该查询？下是优化器可能11、生成的三种候选方案：SalesCustomer3 亿200 万JOIN分组依据JOIN分组依据SalesCustomer临时Customer1 亿数据移动200 万JOIN分组依据SalesCustomer200 万分组依据Customer ID200 万候朴选素方策案略1候选方案 候选方案 数据移动23部分聚合下推 2.数据分布在多个系统中。在这种情况下，数据虚拟化优化器需要在多种操作技术中选择，例如连接或聚合（内存合并、哈希连接、嵌套循环、数据即时移动到临时表等）和查询重写规则（分支修剪、部分聚合拆分如 MPP 等）。基于成本的优化器发挥着重要作用，因为它使用全面的数据源统计数据和其他数据12、源详细信息（例系统的集群规模）来估计部分数据量，并利用它们来权衡不同执行方案的成本，然后选择最优方案。这是此类架构中引擎最复杂的部分，查询性能在很大程度上取决于优化器做出的决定。我们将在下面看到 一个例子。数据源，那么这个 JOIN 3.两种技术的结合。在大多数查询中，即使数据分布在多个数据源中，执行也会同时使用上述两种技术，因为可能有些操作可以下推，而其他操作可以后处理。例如，您可能要连接三个表，但如果其中两个表位于同一仍然可以在单个执行分支中下推。结果是一个执行计划中包含一个或多个“执行分支”，这些分支通常并行执行，以到达每个数据源并检索部分数据集。最终数据集由数据虚拟化引擎的上层处理阶段13、使用优化器选择的技术组成，并被发送到客户端工具。为说明这些效果，我们以一个简单的查询为例：7 2024 Denodo Technologies时间57 分 2 秒10.26 秒15.23 秒从这里我们看出，糟糕的计划可能需要一小时，最优计划只需要几秒钟。在这个例子中，候选方案 2 是最优选择，也是优化器选择用来执行查询的方案。但这个例子只触及了问题表面，例如，我们没有涉及连接算法或表顺序等主题，另外需要注意的是，我们没有采用任何缓存或聚合感知加速技术，仅仅是实时执行（有关这些方案的更多详细信息，请参阅下面的“其他加速技术”小节）。但我们不难看出，技术先进的优化器对于及时产生结果至关重要。具有数14、据虚拟化扩展的数据湖引擎现代数据湖引擎是大规模并行处理(MPP)系统，其中执行引擎已与存储解耦。这些引擎最初为 Hadoop 生态系统创建，处理与存储分离的理念也使这些引擎能够整合与其他系统的连接器，如外部关系型数据库或noSQL后迅速发展，可适应云环境和不同类型的对象存储，如 Amazon Web Services(AWS)的 S3 和 Microsoft Azure的ADLS。平台。数据湖 MPP 引擎部署在多节点集群中，通常包含三种类型的节点：协调器节点，负责解析查询、创建执行计划和管理工作器节点。协调器还负责向客户端返回最终结果集。元存储，存储表的元数据信息，包括列、数据类型、分区和统15、计信息。工作器节点，负责执行查询和处理数据，还负责获取数据（通常从对象存储中获取），并可以相互通信。我们来详细看看这些候选方案：Snowflake这如何影响执行时间？方案候选方案 1候选方案 2候选方案 3对较少的几百行结果。，以利用其处理能力。候选方案 1 最朴素，是对 SQL 查询候选方案 2 采用完全不同的技术，多候选方案 3 回归到了单步执行，但会使用一种可用技术（如合并或哈Snowflake 中的临时表。在第二阶段，的直接转换。数据将同时从销售表步骤执行。第一步，从 PostgreSQL 并未采用朴素策略，而是将查询重和客户表中提取，数据虚拟化引擎中检索客户数据，并将其移动至写为更高16、效的形式。为了最大程度地实施查询下推，聚合将分为两个 希连接），在内存中合并数据，随由于所有数据都存在于 Snowflake 步骤：首先按客户 ID 进行，然后最终输出。该策略的最大不足是，Snowflake，并发送给使用者。我们后按照国家/地区进行汇总，生成中，整 个 查 询 处 理 将 被 下 推 到按国家/地区进行。尽管可能有违直觉，但它显著减少了网络流量和需要移动大量数据（3.02 亿行），可以看到，数据移动已大幅减少到仅数据虚拟化引擎中的处理量，同时并在引擎中进行处理，才能产生相200 万行，并且所有处理都已下推到充分利用Snowflake等引擎的MPP功能。8 2024 Denod17、o Technologies此外，如上图所示，数据集通常以文件的形式存储在对象存储（一种分布式文件系统，常位于云环境，如 AWS 的 S3、Azure 的 ADLS 等）中，这些文件采用专门用于分析的格式，如 Parquet、ORC，以及最近的 Delta 或 Iceberg 等表格式。在执行管道方面，当协调器接收到查询后，它会解析查询，将其映射到元存储中的信息，并利用其优化器创建分布式查询计划。查询计划以层级化任务结构形式构建，这些任务在各工作器节点上运行。每项任务都会操作一个数据目前为止，我们已经了解如何使用数据湖中的数据（如对象存储中的 Parquet 分片，即更大数据集的一部分，使执行18、能够并行化。例如，访问大型 Parquet 文件的任务可以分解到多个工作器中，由它们访问和处理文件的不同部分。协调器会跟踪各任务的执行位置。文件）完成执行任务，但这种架构如何应用于外部数据源？思考我们在上一节中用作示例的 PostgreSQL 和 Snowflake 数据集。在这种情况下，协调器将实例化任务，通过 JDBC 将这些数据集检索到工作器节点。工作器节点将检索数据集，使用 MPP 引擎进行处理，就像处理来自对象存储的数据一样。然而，与访问对象存储中可以拆分给多个工作器的 Parquet 文件不同，对外部数据的访问通过 JDBC 连接进行，这些连接将工作节点映射到每个表，限制了可实现的19、并行程度，如上图所示，产生了与上一节所述候选方案 1 类似的情况，在数据传输上也有同样问题。此外，数据湖引擎的优化器并不像专用数据虚拟化引擎那样，提供各种可联合的先进技术（正如我们在上一节所见）。它们的重点在于为处理湖中的数据（如 Parquet、ORC、Iceberg 等）提供强大架构，而联合功能仅仅是重复使用相同的处理管道。客户端应用程序协调器工作器工作器工作器工作器对象存储元存储SQL 查询数据流其他调用客户端应用程序协调器工作器工作器工作器元存储SalesCustomer3 亿200 万9 2024 Denodo Technologies即使所有数据都在同一个数据源中，大多数数据湖引擎20、也会使用这种相同的执行模式，因为连接器不具备高级SQL 方言转换逻辑、复杂数据类型的映射，以及关于数据源逻辑的其他信息，例如数据整理（数据源对非数字值进行排序的方式）。这意味着数据湖引擎将对每张表进行扫描，并使用自己的引擎处理来自外部源的查询。这种方法有一些优点（例如，减少遗留数据源的工作负载），但也存在重大问题。例如，无法利用数据源的内部结构来加速处理查询（如索引、分区、缓存等）。值得注意的还有，以数据湖为中心的生态系统中，经常会看到将数据湖内容与外部系统混合在一起的查询。这类情况下，引擎将采用并行访问数据湖文件和单独访问外部内容的方式（上述两种场景的结合）。混合方法目前，我们可以看到，许多21、供应商正在跨越不同架构界限，融合两种方法概念的混合型产品变得十分常见。实际上，数据湖引擎的协调器节点和专用虚拟化服务器的实例有很多共同点。数据湖引擎通常能够下推简单的谓词，如 WHERE 子句中的筛选条件。一些数据湖供应商在其企业级产品中宣传更强管如此，总体而言，数据湖引擎的下推能力较为有限，部分原因是其 SQL 大的下推功能，这些功能是对其开源版本所提供功能的扩展。这些功能使引擎能够下推一些额外操作，如连接。尽方言转换能力有限，另一部分原因则是缺乏上一节提到的高级重写技术。您也会看到多家专业数据虚拟化供应商在其产品中包含MPP引擎，使这些引擎能够在数据湖场景中提供更好的集成，并在多源查询的上22、层处理初期阶段利用并行处理的优势。例如，Denodo 嵌入了开源数据湖引擎 Presto，作为其架构中的组件。既可用于数据湖处理，也可用于加速联合场景中的执行。Denodo数据 APIWarehouseDenodo虚拟化服务器IdPDenodo数据目录其他应用程序BI 工具数据科学笔记本本地数据Denodo 调度程序对象存储（S3、ADLS 等）Denodo MPP操作型 RDBMS10 2024 Denodo Technologies其他加速技术尽管此次分析的重点在于实时查询，但该领域的许多供应商都提供其他加速功能来提高性能。缓存几乎所有供应商都提供缓存功能。缓存允许引擎重复使用之前计算的结23、果。大多数供应商还提供更新缓存内容的功专门组件：Denodo 能，以保持其时效性（通常通过增量更新实现，以避免全盘更新）。此外，Denodo 平台还包含用于编排缓存加载的调度器。当优化器检测到“缓存命中”时，无论是完全命中，还是部分命中，都会将引擎重定向到缓存系统，以检索该数据，而不是根据原始表重新计算。通常会有一个可配置的存活时间(TTL)参数，告诉系统缓存的计算在多长时间之内仍然有效，以避免返回陈旧数据。聚合感知加速此外，Denodo还提供聚合感知加速，该技术将利用聚合产生的较小数据集，以及“分析查询经常聚合原始数据，产生最终结果”这一事实。例如，回想上一节中描述的“按国家/地区的总销售额24、”查询，聚合感知加速所基于的理念是：预聚合的中间结果可用作计算最终结果的基础，比使用原始表快得多。这项技术有两大优势，在分析领域极为有用：提供了极高的加速系数，通常比原始查询快 10 倍、20 倍，甚至 50 倍。同时，提供的“命中”次数往往比传统缓存高得多。也就是说，单一的加速聚合可以服务于数百个不同的分析查询。不需要最终用户的输入。执行引擎会自动检测可加速的查询，并重写它们，以使用预先计算的聚合。这项技术的实施相当复杂，而且提供这项功能的数据虚拟化提供商不多，如下图所示，其优势显而易见。使用Denodo平台进行聚合感知查询加速的效果。所有查询均利用基于人工智能推荐创建的单一加速结构，执行时25、间以秒为单位。智能查询加速原始时间加速时间161412108642012345611 2024 Denodo Technologies最后，要让这项技术有效发挥作用，关键在于熟练选择应进行预计算和预聚合的数据，但这种决策并非易事。在过去，需要经验丰富的 DBA 干预，分析需要做出性能改进的报告和仪表板，以发现常见模式，将其转换为聚合。幸运的是这方面，人工智能可以提供帮助，Denodo 等供应商提供了人工智能辅助向导，通过分析使用情况，生成定制推荐。关于这项功能的更深入解释，可在这篇文章中找到，基于人工智能的推荐引擎在这篇文章中有描述。基准测试比例因子为 100 的版本，在这个版本中，最大的表(26、LineItem)包含 6 亿行数据。TPC-H 为测试这些不同的架构，我们基于事务处理委员会(TPC)的基准测试 TPC-H v3.0.1，设计了一个场景。我们选择了的使用在数据管理供应商中非表行(SF 100)常普遍，能够相当合理地代表现实中的分析场景。Customer15,000,000Orders150,000,000Lineltem600,037,902PartSuppr80,000,000Part20,000,000Supplier1,000,000Nation25Region5LineltemSF*6000KLORDERKEYLLINENUMBERPartSuppSF*800KP27、S PARTKEYPS SUPPKEYSupplierSF 10KS_SUPPKEYPartSF*200KP_PARTKEYRegion5R_REGIONKEYNation25N_NATIONKEYOrdersSF 1500KO_ORDERKEYCustomerSF*150KC_CUSTKEY12 2024 Denodo Technologies1234基准测试查询为了将运行基准测试的时间和成本保持在合理的范围内，我们专注于 TPC-H 前 10 个查询（共 22 个）。查询编号业务问题此查询确定订单优先级系统的运行情况，并评估客户满意度。此查询列出通过本地供应商完成的收入额。此查询检索价值最28、高的 10 张未发货订单。此查询查找应选择哪家供应商在特定地区下单购买特定零件。此查询报告开票、发货和退货的业务量。56此查询量化了如果在给定年份消除特定百分比范围内的全公司折扣，将会带来的收入增加金额。提出这类“如果”查询可用于寻找增加收入的方法。78910此查询确定在特定国家之间运送的货物的价值，有助于重新协商运输合同。此查询确定特定国家在特定地区的特定零件类型市场份额在两年内的变化情况。此查询确定特定零件系列的利润额，按供应商所在国家和年份细分。此查询识别可能因为发送给他们的零件而遇到问题的客户。这些查询的相应 SQL 语句可在 TCP 网站在线提供的 TPC-H 技术规范中找到。为了呈29、现一个分布式数据环境，相同的 TPC-H 数据集已经以不同的来源和格式提供（详情请参阅下方各个场景）：AWS Redshift、PostgreSQL 和 AWS S3 中的 Parquet 文件。13 2024 Denodo Technologies环境规格本次基准测试中测试的所有不同数据源均在 AWS 的同一区域内部署，具体配置如下：Redshift：dc2.8xlarge-4 个节点 PostgreSQL：m5.2xlarge Parquet 格式的对象存储数据(S3)对于数据湖引擎，我们使用了数据湖领域一家领先开源供应商的最新版本（撰写本文时的 2024 年 2 月版本）。该引擎还部署在30、 AWS 的同一区域和 VPC 中，规格如下：R5.4xlarge 节点 每个节点 16 个核心 每个节点 128GB RAM 20 个工作器节点 每个工作器最大 140GB 堆内存 元数据存储于 Hive Metastore 中对于 Denodo 虚拟化服务器，我们使用了以下配置：M4.2xlarge 服务器 8 个核心 32 GB RAM 1 台虚拟化服务器 最大 8GB 堆内存在这些测试中，没有对任何数据源使用缓存机制。虚拟层中也没有使用缓存或查询加速机制。基准测试场景为了代表分布式场景，我们将 TPC-H 表放置在了多个系统中。这为实现我们在每个场景中详细描述的基准测试多源变体提供了可31、能性。为了避免异常值或外部因素的影响，每个查询都被执行三次，这些表格中使用的数值是这些执行时间的平均值。14 2024 Denodo Technologies在这个场景中，我们要模拟的查询需要完全存储在外部系统中的数据。例如，您可能需要使用来自数据仓库的数据执行查询。在这个场景中，我们使用 AWS Redshift 作为数据源。查询编号Denodo 数据湖供应商11123.6774772052849.3314067031272.0067051849205.3330807845430.3313824726397.3324604.575897.67119142181361.33152631393432、17.332529649102570.67484988总计26524.9918508624.5执行时间以毫秒为单位。Redshift）两个引擎均成功完成了所有测试。然而很明显，Denodo 平台的专用架构能够利用对外部企业数据仓库（如的访问能力，其速度比数据湖引擎快几个数量级。如上一节所述，为每张表使用一个工作器的数据湖策略需要在网络上移动大量数据，因此即使有 20 个节点并行处理查询，执行时间也明显高于 Denodo 平台执行的正确下推查询。另外需要注意的是，一些数据湖供应商在其商业产品中提供企业连接器，其下推逻辑比这些测试中使用的开源版本更好。虽然提高了性能，仍然比 Denodo 慢几个数33、量级。在“数据虚拟化架构中的查询执行比较”一节中，您可以找到这些差异背后原因的详细解释。DENODO 总执行时间26.52 秒数据湖供应商总执行时间5 小时 8 分 28 秒场景 1：访问外部源小结如下：15 2024 Denodo Technologies对于第二个场景，我们将数据集分为两个源，以模拟联合场景。大型表仍保留在 AWS Redshift 中，但某些表已移至 PostgreSQL。分布情况如下：AWS Redshift：Supplier，PartSuppr，LineItem，Orders查询编号 PostgreSQL：Customer，Part，Nation，Region注意：查34、询 1、4 和 6 不涉及多源联合，不属于本测试的范围，因为与场景 1 中已显示的数据完全相同。Denodo 数据湖供应商267567747522317927.2514067054005.25670518720549.253328448819205.513824729204782916110110142.251327585总计199063.58835578Denodo 平台的多功能性再次战胜数据湖方法。我们可以看到，数据湖中的执行时间与单源场景 1 非常的相似，因为数据湖引擎采用的执行计划非常相似，即基于将工作器映射到数据源表。值得注意的是，在这次联合测试中，一些查询速度更快。考虑到数据湖引擎35、中的执行计划几乎完全相同，解释为数据源的工作负载减少了，现在分成了两个不同的系统。小结如下：DENODO总执行时间3 分 19 秒数据湖供应商总执行时间2 小时 27 分 15 秒场景2：联合两个外部源执行时间以毫秒为单位。16 2024 Denodo Technologies查询编号Denodo 数据湖供应商281225473.75310591.757070.2556929.2523262.5710251802481571112532.59204787951.75107719169454.25总计149274133769两家供应商均成功完成所有测试。这种场景正是数据湖的强项，在并行访问事实表36、的情况下，可以并行处理大部分过程。Denodo 平台执行展示一种混合计划，可以利用其MPP进行处理，在需要时进行联合，提供非常相似的结果。小结如下：DENODO总执行时间2 分 29 秒数据湖供应商总执行时间2 分 13 秒执行时间以毫秒为单位。数据湖引擎高度关注将数据湖作为生态系统核心部分的场景，测试部分数据集位于数据湖中的场景也是合理的。本测试和下面的测试代表了这种情况。为通过 Denodo 平台访问数据湖，我们使用 Denodo 平台中包含的基于 Presto 的嵌入式 MPP 引擎。集群和工作器的 数据湖：Supplier、PartSuppr、LineItem、规格与其他数据湖供应商完37、全相同。在本特定案例中，我们将大型事实表置于数据湖中，而较小的维度表则存放在PostgreSQL 中。表的分布情况如下：Orders PostgreSQL：Customer、Part、Nation、Region场景3：联合数据湖和小型外部源17 2024 Denodo Technologies查询编号Denodo 数据湖供应商224430426883731574612750395412272318577712960.51297888*816325.252774511*931007.56537800*1014736.25559807总计376306.515032459我们再次看到，Denodo平38、台提供的灵活选项更好适应了这种场景。例如，遵循数据引力概念，Denodo平台能够执行从数据湖到 EDW 的即时数据移动，以及数据湖无法实现的其他高级技术。小结如下：DENODO总执行时间6 分 16 秒数据湖供应商总执行时间4 小时 10 分 32 秒执行时间以毫秒为单位。作为上述场景变体，我们修改了表的分布，使大型表格位于数据湖之外，代表了例如企业数据仓库中大型表需要与数据湖交叉的场景。表的分布情况如下：场景4：数据湖：Customer，Part，Nation，Region AWS Redshift：Supplier，PartSuppr，LineItem，Orders联合数据湖和大型外部源139、8 2024 Denodo Technologies总结Denodo 平台领先的数据湖供应商26.52 秒5 小时 8 分 28 秒2 小时 27 分 15 秒并不适合分布式环境的数据交付层。当小部分数据位于数据湖之外时，其多源查询功能表现良好（如场景3数据湖引擎被设计为在大规模数据量下，为分析查询提供充足的处理能力。然而，正如这些测试所示，其处理方式所示），但对大多数其他场景，数据湖并不能提供可行的解决方案。2 分 29 秒3 分 19 场景访问外部数据2 个外部源的联合联合数据湖和小型外部源秒2 分 13 秒联合数据湖和大型外部源6 分 16 秒4 小时 10 分 32 秒像 Denodo40、 平台这样的现代化、专业化的数据虚拟化解决方案，可以作为一种跨多个数据源的“元协调器”，提供强大、高性能和设计更佳的解决方案，作为整个企业数据环境的全球接入点。其基于 Presto 的 MPP 引擎也将高性能带入了以数据湖为中心的场景中。最后，在选择任何能够实现数据编织的架构时，还必须考虑数据治理、建模、安18000000全和自助服务等领域的其他能力。有关这些领域的更深入分析，请参阅逻辑数据编织白皮书。150000008000000300000200000100000访问外部数据2 联个合外部源的联合数据湖和小型外部源联合数据湖和大型外部源数据虚拟化场景中的性能Denodo 平台领先的数据湖供应商官网 |电邮 |社区网站 Denodo公众号数据编织咨询群