数据编织的性能-数据虚拟化架构比较-2024.08-19正式版-WN8

白皮书数据编织的性能数据虚拟化架构比较作：PabloÁlvarezYáñez©2024DenodoTechnologies目录I3概述I4引言：数据虚拟化架构专用数据虚拟化层4具有数据虚拟化扩展的数据引擎4I5数据虚拟化架构中的查询执行比较专用数据虚拟化层5具有数据虚拟化扩展的数据湖引擎7混合方法9其他加技术10缓存10聚合感知加速10I11基准测试12环境规格1313场景1：访问外部源14场景2：联合两个外部源15场景3：联合数据湖和小型外部源16场景4：联合数据湖和大型外部源17I18总结概述数据编织后的一个关键思想，能够通过一个易于使用的中心化接从业务角度来，数据编入点访问组织中的任何数据资产。最终用户不必应对幕后的复杂数据生态系统，也不需了解组织中每个数据库和应用程序的实质细节。织的主目标创建一个敏捷平台，通过自助服务数据虚拟化层可以实现这一点，它可以抽象出复杂性，并提供中心化数据层，以业务部门可以的接入点。除了集中访问之外，该层通常还提供其他功能，如缓存、理解和使用的方式公开数安全、建模和跨联合等，能够在整个组织中统一实施。即使公司数据，从而缩短获取数据的据分散在数十个异构系统中，这些功能仍将让最终用户感觉，所有数时。据都整合并存储在单一系统中。数据编织供应采用两种主架构提供这种功能：■专用数据虚拟化层■具有数据虚拟化扩展的数据引擎在这份白皮书中，我们将详细探讨这两种架构，并重点关注这些实现决策对查询执行性能的影响。为进一步说明这两种架构之的差异，我们使用TPC-H展开广泛的准测试，展示这两种架构在不场景下的表现。您可以在下的“准测试”小节中找到测试方法和环境规格的详细说明。在这里，我们先简总结测试结果。专用数据虚拟化层：具有数据虚拟化扩展的数据引擎：场景Denodo平台领先的数据湖供应商访问外部26.525小时8分28秒秒联合两个外部3分192小时27分15秒秒联合数据湖和小型外部2分29秒2分13秒联合数据湖和大型外部6分16秒4小时10分32秒这些结果展示了分布式环境中专用数据虚拟化层的强大能力。在这种环境下，其引擎的复杂程度和专业化程度超越了数据湖并行引擎在访问外部数据集和多数据联合的潜在优势。©2024DenodoTechnologies3引言：数据虚拟化架构数据管理供应采用两种主的数据虚拟化技术来提供跨多个数据的通用访问层。在本节中，我们将比较它们的共通点和差异。专用数据虚拟化层在这类架构中，虚拟化层位于所有数据之上，提供一个中心化接入点。它分析传入的查询并将每个请求转发到包含相应数据的数据。这个过程被称为“查询下推”或“查询委托”。由于查询可能涉及来自多个数据的表，因此这类软件需包含具有跨数据联合功能的引擎和目的驱动型优化器。缓存、聚合感知加速等技术被频繁使用。Denodo就这类技术提供。具有数据虚拟化扩展的数据引擎在这类架构中，数据系统包含一个扩展，不仅能够链接自有数据，也能链接外部数据。这种架构例子早期包括OracleDB链接或MicrosoftSQLServer链接服务器等工具。目前，许多具备并行处理MPP功能的数据湖引擎都实现了此类架构，如Spark、Dremio或Starburst(Trino)。因此，对于这一类别，本白皮书的重点将放在数据湖引擎上。在这些系统中，当请求外部数据时，工作器节点会查询外部表，并将其输入并行引擎处理管道。此类供应也提供缓存之类技术。专用数据虚拟化层传统DB和DW云数据湖/湖仓一体数据湖分布式文件系统传统DB和DW云Excel分布式文件系统（S3、ADLS、HDFS）专用数据虚拟化对比数据湖扩展两种架构都允许最终用户在分布式数据环境中运行查询，但处理方式显著不。下一节我们将深入探讨这些设计差异对查询执行性能的影响。，专用数据虚拟化解决方案通常包含额外功能（例如高级建模、数据沿袭和治理），用于创建和管理跨多个数据的语义层。数据湖供应往往更关注针对对象存储中的数据执行查询，这些功能的分析不在本白皮书讨论范之中，您可以在白皮书《释放数据生态系统的全部潜力》中找到更深入的讨论。©2024DenodoTechnologies4数据虚拟化架构中的查询执行比较现在，让我们来重点探讨这些架构的运作方式，以及这些架构差异对查询执行和性能的影响。专用数据虚拟化层专用数据虚拟化层将充当关系数据库系统，但有一个重大区别：它们仅托管元数据，它们可以表示对象的元数据（如表、视图和存储过程），这一点与其他任何数据库无异，但它们实际上并不托管数据。数据结果总从始数据或缓存中获取，并按需查询。这些元数据不仅包含表名、列和数据类型，还包含执行底层数据查询所需的所有信息。其中一些细节包括：数据类型、版本和供应；数据类型和结构映射；用于成本估的数据统计；以及特定配置，如批量加载设置、API中的分页等。数据虚拟化扩展的数据引擎仅仅支持RDBMS和noSQL，相比之下，这种架构通常支持更广泛的数据。当最终用户发出查询时，优化器会构建执行计划，涉及多个步骤，首先分析查询中涉及的表/视图的元数据。分析元数据和专用数据虚拟化引擎的查询优化管道初始元数据分析期，引擎可以检测两种可能的场景，并利用这些信息比较可行的查询执行技术：1.应答查询所需的所有数据都在一系统中。根据数据的特征，引擎可以决定：a.利用底层系统的处理能力。这种技术被称为“查询下推”，对于具有处理能力的底层数据（如关系数据库、MongoDB，甚至像Salesforce这样的系统），首选方法。i.此步骤至关重，因为它使引擎能够利用数据所有与处理能力相关的功能，例如并行处理、索引、缓存、分区，以及数据引擎可用于加快执行速度的其他工件。ii./函数语法。SQL转换的质量越高，性能越好。b.这首选策略。执行计划将整个数据集引入虚拟化引擎，执行任何其他操作（如：列转换、聚合等）。©2024DenodoTechnologies52.数据分布在多个系统中。在这种情况下，数据虚拟化优化器需在多种操作技术中选择，例如连接或聚合（内存合并、哈希连接、嵌套循环、数据即时移动到临时表等）和查询重写规则（分支修剪、部分聚合拆分等）。于成本的优化器发挥重作用，因为它使用全的数据统计数据和其他数据详细信息（例如MPP系统的集群规模）来估计部分数据量，并利用它们来权衡不执行方案的成本，然后选择最优方案。这此类架构中引擎最复杂的部分，查询性能在很大程度上取决于优化器做出的决定。我们将在下一个例子。3.两种技术的结合。在大多数查询中，即使数据分布在多个数据中，执行也会时使用上述两种技术，因为可能有些操作可以下推，而其他操作可以后处理。例如，您可能连接三个表，但如果其中两个表位于一数据，那么这个JOIN仍然可以在单个执行分支中下推。结果一个执行计划中包含一个或多个“执行分支”，这些分支通常并行执行，以到达每个数据并检索部分数据集。最终数据集由数据虚拟化引擎的上层处理阶段使用优化器选择的技术组成，并被发送到客户端工具。为说明这些效果，我们以一个简单的查询为例：SELECTc.country,SUM(s.amount)

FROMpsql.customercJOINsf.saless

ONc.id=s.customer_idGROUPBYc.country该查询计每个国家/地区的总销额。作为景信息，我们假设Customer表位于PostgreSQL中，有200万行数据，而Sales表位于Snowflake中，有3亿行数据。如何处理该查询？优化器将生成法和查询重写规则的多种组合，估每一步涉及的数据量，并根据估成本选择最优方案。例如，以下优化器可能生成的三种候选方案：1亿分组依据数据移动分组依据JOINJOIN

分组依据万万3亿万JOIN分组依据CustomerID万SalesCustomerSales临时CustomerSalesCustomerCustomer候选方案候选方案候选方案123朴素策略数据移动部分聚合下推©2024DenodoTechnologies6我们来详细候选方案1最朴素，对SQL查询候选方案2采用完全不的技术，多候选方案3回归到了单步执行，但的接转换。数据将时从销表步骤执行。第一步，从PostgreSQL并未采用朴素策略，而将查询重和客户表中提取，数据虚拟化引擎中检索客户数据，并将其移动至写为更高效的形式。为了最大程度会使用一种可用技术（如合并或哈地实施查询下推，聚合将分为两个希连接），在内存中合并数据，随由于所有数据都存在于Snowflake步骤：首先按客户ID进行，然后后按照国家/地区进行汇总，生成中，整个查询处理将被下推到按国家/地区进行。尽管可能有违最终输出。该策略的最大不足，Snowflake，并发送给使用者。我们觉，但它显著减少了网络流量和需移动大量数据（3.02亿行），可以到，数据移动已大幅减少到仅数据虚拟化引擎中的处理量，时并在引擎中进行处理，才能产生相200万行，并且所有处理都已下推到充分利用Snowflake等引擎的MPP对较少的几百行结果。，以利用其处理能力。功能。Snowflake这如何影响执行时？方案时间候选方案157分2秒候选方案210.26秒候选方案315.23秒从这里我们出，糟糕的计划可能需一小时，最优计划只需几秒钟。在这个例子中，候选方案2也优化器选择用来执行查询的方案。但这个例子只触及了问题表，例如，我们没有涉及连接法或表序等主题，另外需注意的，我们没有采用任何缓存或聚合感知加速技术，仅仅实时执行（有关这些方案的更多详细信息，请参阅下的“其他加速技术”小节）。但我们不难出，技术先进的优化器对于及时产生结果至关重。具有数据虚拟化扩展的数据湖引擎现代数据湖引擎大规模并行处理(MPP)系统，其中执行引擎已与存储解耦。这些引擎最初为Hadoop生态系统创建，后迅速发展，可适应云环境和不类型的对象存储，如AmazonWebServices(AWS)的S3和MicrosoftAzure的ADLS。处理与存储分离的理念也使这些引擎能够整合与其他系统的连接器，如外部关系型数据库或noSQL平台。数据湖MPP引擎部署在多节点集群中，通常包含三种类型的节点：■协调器节点，负责解析查询、创建执行计划和管理工作器节点。协调器还负责向客户端返回最终结果集。■元存储，存储表的元数据信息，包括列、数据类型、分区和统计信息。■工作器节点，负责执行查询和处理数据，还负责获取数据（通常从对象存储中获取），并可以相互通信。©2024DenodoTechnologies7SQL数据流其他调用元存储客户端应用程序协调器工作器工作器工作器工作器的、Azure的ADLS等）中，这些文件采用专门用于分析的格式，如Parquet、ORC，以及最近的Delta或Iceberg等表格式。在执行管道方，当协调器接收到查询后，它会解析查询，将其映射到元存储中的信息，并利用其优化器创建分布式查询计划。查询计划以层级化任务结构形式构建，这些任务在各工作器节点上运行。每项任务都会操作一个数据分片，即更大数据集的一部分，使执行能够并行化。例如，访问大型Parquet文件的任务可以分解到多个工作器中，由它们访问和处理文件的不部分。协调器会跟踪各任务的执行位置。目前为止，我们已经了解如何使用数据湖中的数据（如对象存储中的Parquet文件）完成执行任务，但这种架构如何应用于外部数据？思考我们在上一节中用作示例的PostgreSQL和Snowflake数据集。在这种情况下，协调器将实例化任务，通过JDBC将这些数据集检索到工作器节点。工作器节点将检索数据集，使用MPP引擎进行处理，就像处理来自对象存储的数据一样。3亿Sales200万Customer然而，与访问对象存储中可以拆分给多个工作器的Parquet文件不，对外部数据的访问通过JDBC连接进行，这些连接将工作节点映射到每个表，限制了可实现的并行程度，如上图所示，产生了与上一节所述候选方案1类似的情况，在数据传输上也有样问题。此外，数据湖引擎的优化器并不像专用数据虚拟化引擎那样，提供各种可联合的先进技术（正如我们在上一节所见）。它们的重点在于为处理湖中的数据（如Parquet、ORC、Iceberg等）提供强大架构，而联合功能仅仅重复使用相的处理管道。©2024DenodoTechnologies8即使所有数据都在一个数据中，大多数数据湖引擎也会使用这种相的执行模式，因为连接器不具备高级SQL方言转换逻辑、复杂数据类型的映射，以及关于数据逻辑的其他信息，例如数据整理（数据对非数字进行排序的方式）。这意味数据湖引擎将对每张表进行扫描，并使用自己的引擎处理来自外部的查询。这种方法有一些优点（例如，减少遗留数据的工作负载），但也存在重大问题。例如，无法利用数据的内部结构来加速处理查询（如索引、分区、缓存等）。到将数据湖内容与外部系统混合在一起的查询。这类情况下，引擎将采用并行访问数据湖文件和单独访问外部内容的方式（上述两种场景的结合）。混合方法目前，我们可以到，许多供应正在跨越不架构界限，融合两种方法概念的混合型产变得十分常见。实际上，数据湖引擎的协调器节点和专用虚拟化服务器的实例有很多共点。数据湖引擎通常能够下推简单的谓词，如WHERE子句中的选条件。一些数据湖供应在其企业级产中传更强大的下推功能，这些功能对其开版本所提供功能的扩展。这些功能使引擎能够下推一些额外操作，如连接。尽管如此，总体而言，数据湖引擎的下推能力较为有限，部分因其SQL方言转换能力有限，另一部分因则缺乏上一节提到的高级重写技术。您也会到多家专业数据虚拟化供应在其产中包含MPP引擎，使这些引擎能够在数据湖场景中提供更好的集成，并在多查询的上层处理初期阶段利用并行处理的优势。本地数据例如，Denodo嵌入了开数据湖引擎Presto，作为其架构中的组件。既可用于数据湖处理，也可用于加速联合场景中的执行。©2024DenodoTechnologies9其他加速技术尽管此次分析的重点在于实时查询，但该领域的许多供应都提供其他加速功能来提高性能。缓存几乎所有供应都提供缓存功能。缓存允许引擎重复使用之前计的结果。大多数供应还提供更新缓存内容的功能，以保持其时效性（通常通过增量更新实现，以避免全盘更新）。此外，Denodo平台还包含用于编排缓存加载的专门组件：Denodo调度器。当优化器检测到“缓存命中”时，无论完全命中，还部分命中，都会将引擎重定向到缓存系统，以检索该数据，而不根据始表重新计。通常会有一个可配置的存活时(TTL)参数，告诉系统缓存的计在多长时之内仍然有效，以避免返回陈旧数据。聚合感知加速此外，Denodo还提供聚合感知加速，该技术将利用聚合产生的较小数据集，以及“分析查询经常聚合始数据，产生最终结果”这一事实。例如，回想上一节中描述的“按国家/地区的总销额”查询，聚合感知加速所于的理念：预聚合的中结果可用作计最终结果的础，比使用始表快得多。这项技术有两大优势，在分析领域极为有用：■提供了极高的加速系数，通常比始查询快10倍、20倍，甚至50倍。时，提供的“命中”次数往往比传统缓存高得多。也就说，单一的加速聚合可以服务于数百个不的分析查询。■不需最终用户的输入。执行引擎会自动检测可加速的查询，并重写它们，以使用预先计的聚合。这项技术的实施相当复杂，而且提供这项功能的数据虚拟化提供不多，如下图所示，其优势显而易见。智能查询加速161412使用Denodo平台进行聚合感知查询10加速的效果。所有查询均利用于8人工智能推荐创建的单一加速结构，6执行时以秒为单位。420时加速时间123456©2024DenodoTechnologies10最后，让这项技术有效发挥作用，关键在于熟练选择应进行预计和预聚合的数据，但这种决策并非易事。在过去，需经验丰富的DBA干预，分析需做出性能改进的报告和仪表板，以发现常见模式，将其转换为聚合。幸运的这方，人工智能可以提供帮助，Denodo等供应提供了人工智能辅助向导，通过分析使用情况，生成定制推荐。关于这项功能的更深入解释，可在这篇文中找到，于人工智能的推荐引擎在这篇文中有描述。为测试这些不的架构，我们于事务处理委员会(TPC)的准测试TPC-Hv3.0.1，设计了一个场景。我们选择了比例因子为100的版本，在这个版本中，最大的表(LineItem)包含6亿行数据。TPC-H的使用在数据管理供应中非常遍，能够相当合理地代表现实中的分析场景。表行(SF100)Customer15,000,000LineltemSF*6000KLORDERKEYLLINENUMBEROrdersSF1500KO_ORDERKEYCustomerSF*150KC_CUSTKEYOrders150,000,000Lineltem600,037,902PartSuppr80,000,000Part20,000,000PartSuppSF*800KPSPARTKEYPSSUPPKEYSupplierSF10KS_SUPPKEYNation25N_NATIONKEYSupplier1,000,000Nation25PartSF*200KRegion5P_PARTKEYR_REGIONKEYRegion5©2024DenodoTechnologies11基准测试查询为了将运行准测试的时和成本保持在合理的范内，我们专注于TPC-H前10个查询（共22个）。查询编号业务问题1此查询报告开、发货和退货的业务量。2此查询查找应选择哪家供应在特定地区下单购买特定零件。3此查询检索价最高的10张未发货订单。4此查询确定订单优先级系统的运行情况，并评估客户满意度。5此查询列出通过本地供应完成的收入额。6此查询量化了如果在给定年份消除特定百分比范内的全公司折扣，将会带来的收入增加金额。提出这类“如果”查询可用于寻找增加收入的方法。7此查询确定在特定国家之运送的货物的价，有助于重新协运输合。8此查询确定特定国家在特定地区的特定零件类型市场份额在两年内的变化情况。9此查询确定特定零件系列的利润额，按供应所在国家和年份细分。10此查询识别可能因为发送给他们的零件而遇到问题的客户。这些查询的相应SQL语句可在TCP网站在线提供的TPC-H技术规范中找到。为了呈现一个分布式数据环境，相的TPC-H数据集已经以不的来和格式提供（详情请参阅下方各个场景）：AWSRedshift、PostgreSQL和AWSS3中的Parquet文件。©2024DenodoTechnologies12环境规格本次准测试中测试的所有不数据均在AWS的一区域内部署，具体配置如下：■Redshift：dc2.8xlarge-4个节点■PostgreSQL：m5.2xlarge■Parquet格式的对象存储数据(S3)对于数据湖引擎，我们使用了数据湖领域一家领先开供应的最新版本（撰写本文时的2024年2月版本）。该引擎还部署在AWS的一区域和VPC中，规格如下：■R5.4xlarge节点■每个节点16个核心■每个节点128GBRAM■20个工作器节点■每个工作器最大140GB堆内存■元数据存储于HiveMetastore中对于Denodo虚拟化服务器，我们使用了以下配置：■M4.2xlarge服务器■8个核心■32GBRAM■1台虚拟化服务器■最大8GB堆内存在这些测试中，没有对任何数据使用缓存机制。虚拟层中也没有使用缓存或查询加速机制。基准测试场景为了代表分布式场景，我们将TPC-H表放置在了多个系统中。这为实现我们在每个场景中详细描述的准测试多源变体提供了可能性。为了避免异常或外部因素的影响，每个查询都被执行三次，这些表格中使用的数的平均。©2024DenodoTechnologies13场景1：访问外部源在这个场景中，我们模拟的查询需完全存储在外部系统中的数据。例如，您可能需使用来自数据仓库的数据执行查询。在这个场景中，我们使用AWSRedshift作为数据。查询编号数据湖供应商Denodo11123.6774772052849.3314067031272.0067051849205.3330807845430.3313824726397.3324604.575897.67119142181361.33152631393417.332529649102570.67484988总计26524.9918508624.5执行时以毫秒为单位。两个引擎均成功完成了所有测试。然而很明显，Denodo平台的专用架构能够利用对外部企业数据仓库（如Redshift）的访问能力，其速度比数据湖引擎快几个数量级。如上一节所述，为每张表使用一个工作器的数据湖策略需在网络上移动大量数据，因此即使有20个节点并行处理查询，执行时也明显高于Denodo平台执行的正确下推查询。小结如下：DENODO数据湖供应商总执行时总执行时间26.525小时8分28秒秒另外需注意的，一些数据湖供应在其业产中提供企业连接器，其下推逻辑比这些测试中使用的开版本更好。虽然提高了性能，仍然比Denodo慢几个数量级。在“数据虚拟化架构中的查询执行比较”一节中，您可以找到这些差异后因的详细解释。©2024DenodoTechnologies14场景2：联合两个外部源对于第二个场景，我们将数据集分为两个，以模拟联合场景。大型表仍保留在AWSRedshift中，但某些表已移至PostgreSQL。分布情况如下：■AWSRedshift：Supplier，PartSuppr，LineItem，Orders■PostgreSQL：Customer，Part，Nation，Region注意：查询1、4和6不涉及多联合，不属于本测试的范，因为与场景1中已显示的数据完全相。查询编号数据湖供应商Denodo267567747522317927.2514067054005.25670518720549.253328448819205.513824729204782916110110142.251327585总计199063.58835578执行时以毫秒为单位。Denodo平台的多功能性再次战胜数据湖方法。我们可以到，数据湖中的执行时与单场景1非常的相似，因为数据湖引擎采用的执行计划非常相似，即于将工作器映射到数据表。得注意的，在这次联合测试中，一些查询速度更快。考虑到数据湖引擎中的执行计划几乎完全相，解释为数据的工作负载减少了，现在分成了两个不的系统。小结如下：DENODO数据湖供应商总执行时总执行时间3分192小时27分15秒秒©2024DenodoTechnologies15场景3：联合数据湖和小型外部源数据湖引擎高度关注将数据湖作为生态系统核心部分的场景，测试部分数据集位于数据湖中的场景也合理的。本测试和下的测试代表了这种情况。为通过Denodo平台访问数据湖，我们使用Denodo平台中包含的于Presto的嵌入式MPP引擎。集群和工作器的规格与其他数据湖供应完全相。在本特定案例中，我们将大型事实表置于数据湖中，而较小的维度表则存放在PostgreSQL中。表的分布情况如下：■数据湖：Supplier、PartSuppr、LineItemOrders、■PostgreSQL：Customer、Part、Nation、Region查询编号数据湖供应商Denodo281225473.75310591.757070.2556929.2523262.5710251802481571112532.59204787951.75107719169454.25总计149274133769执行时以毫秒为单位。两家供应均成功完成所有测试。这种场景正数据湖的强项，在并行访问事实表的情况下，可以并行处理大部分过程。Denodo平台执行展示一种混合计划，可以利用其MPP进行处理，在需时进行联合，提供非常相似的结果。小结如下：DENODO数据湖供应商总执行时总执行时间2分292分13秒秒©2024DenodoTech