數(shù)據(jù)編織的性能-數(shù)據(jù)虛擬化架構(gòu)比較-2024.08-19正式版-WN8

白皮書(shū)數(shù)據(jù)編織的性能數(shù)據(jù)虛擬化架構(gòu)比較作：PabloálvarezYá?ez?2024DenodoTechnologies目錄I3概述I4引言：數(shù)據(jù)虛擬化架構(gòu)專用數(shù)據(jù)虛擬化層4具有數(shù)據(jù)虛擬化擴(kuò)展的數(shù)據(jù)引擎4I5數(shù)據(jù)虛擬化架構(gòu)中的查詢執(zhí)行比較專用數(shù)據(jù)虛擬化層5具有數(shù)據(jù)虛擬化擴(kuò)展的數(shù)據(jù)湖引擎7混合方法9其他加技術(shù)10緩存10聚合感知加速10I11基準(zhǔn)測(cè)試12環(huán)境規(guī)格1313場(chǎng)景1：訪問(wèn)外部源14場(chǎng)景2：聯(lián)合兩個(gè)外部源15場(chǎng)景3：聯(lián)合數(shù)據(jù)湖和小型外部源16場(chǎng)景4：聯(lián)合數(shù)據(jù)湖和大型外部源17I18總結(jié)概述數(shù)據(jù)編織后的一個(gè)關(guān)鍵思想，能夠通過(guò)一個(gè)易于使用的中心化接從業(yè)務(wù)角度來(lái)，數(shù)據(jù)編入點(diǎn)訪問(wèn)組織中的任何數(shù)據(jù)資產(chǎn)。最終用戶不必應(yīng)對(duì)幕后的復(fù)雜數(shù)據(jù)生態(tài)系統(tǒng)，也不需了解組織中每個(gè)數(shù)據(jù)庫(kù)和應(yīng)用程序的實(shí)質(zhì)細(xì)節(jié)?？椀闹髂繕?biāo)創(chuàng)建一個(gè)敏捷平臺(tái)，通過(guò)自助服務(wù)數(shù)據(jù)虛擬化層可以實(shí)現(xiàn)這一點(diǎn)，它可以抽象出復(fù)雜性，并提供中心化數(shù)據(jù)層，以業(yè)務(wù)部門可以的接入點(diǎn)。除了集中訪問(wèn)之外，該層通常還提供其他功能，如緩存、理解和使用的方式公開(kāi)數(shù)安全、建模和跨聯(lián)合等，能夠在整個(gè)組織中統(tǒng)一實(shí)施。即使公司數(shù)據(jù)，從而縮短獲取數(shù)據(jù)的據(jù)分散在數(shù)十個(gè)異構(gòu)系統(tǒng)中，這些功能仍將讓最終用戶感覺(jué)，所有數(shù)時(shí)。據(jù)都整合并存儲(chǔ)在單一系統(tǒng)中。數(shù)據(jù)編織供應(yīng)采用兩種主架構(gòu)提供這種功能：■專用數(shù)據(jù)虛擬化層■具有數(shù)據(jù)虛擬化擴(kuò)展的數(shù)據(jù)引擎在這份白皮書(shū)中，我們將詳細(xì)探討這兩種架構(gòu)，并重點(diǎn)關(guān)注這些實(shí)現(xiàn)決策對(duì)查詢執(zhí)行性能的影響。為進(jìn)一步說(shuō)明這兩種架構(gòu)之的差異，我們使用TPC-H展開(kāi)廣泛的準(zhǔn)測(cè)試，展示這兩種架構(gòu)在不場(chǎng)景下的表現(xiàn)。您可以在下的“準(zhǔn)測(cè)試”小節(jié)中找到測(cè)試方法和環(huán)境規(guī)格的詳細(xì)說(shuō)明。在這里，我們先簡(jiǎn)總結(jié)測(cè)試結(jié)果。專用數(shù)據(jù)虛擬化層：具有數(shù)據(jù)虛擬化擴(kuò)展的數(shù)據(jù)引擎：場(chǎng)景Denodo平臺(tái)領(lǐng)先的數(shù)據(jù)湖供應(yīng)商訪問(wèn)外部26.525小時(shí)8分28秒秒聯(lián)合兩個(gè)外部3分192小時(shí)27分15秒秒聯(lián)合數(shù)據(jù)湖和小型外部2分29秒2分13秒聯(lián)合數(shù)據(jù)湖和大型外部6分16秒4小時(shí)10分32秒這些結(jié)果展示了分布式環(huán)境中專用數(shù)據(jù)虛擬化層的強(qiáng)大能力。在這種環(huán)境下，其引擎的復(fù)雜程度和專業(yè)化程度超越了數(shù)據(jù)湖并行引擎在訪問(wèn)外部數(shù)據(jù)集和多數(shù)據(jù)聯(lián)合的潛在優(yōu)勢(shì)。?2024DenodoTechnologies3引言：數(shù)據(jù)虛擬化架構(gòu)數(shù)據(jù)管理供應(yīng)采用兩種主的數(shù)據(jù)虛擬化技術(shù)來(lái)提供跨多個(gè)數(shù)據(jù)的通用訪問(wèn)層。在本節(jié)中，我們將比較它們的共通點(diǎn)和差異。專用數(shù)據(jù)虛擬化層在這類架構(gòu)中，虛擬化層位于所有數(shù)據(jù)之上，提供一個(gè)中心化接入點(diǎn)。它分析傳入的查詢并將每個(gè)請(qǐng)求轉(zhuǎn)發(fā)到包含相應(yīng)數(shù)據(jù)的數(shù)據(jù)。這個(gè)過(guò)程被稱為“查詢下推”或“查詢委托”。由于查詢可能涉及來(lái)自多個(gè)數(shù)據(jù)的表，因此這類軟件需包含具有跨數(shù)據(jù)聯(lián)合功能的引擎和目的驅(qū)動(dòng)型優(yōu)化器。緩存、聚合感知加速等技術(shù)被頻繁使用。Denodo就這類技術(shù)提供。具有數(shù)據(jù)虛擬化擴(kuò)展的數(shù)據(jù)引擎在這類架構(gòu)中，數(shù)據(jù)系統(tǒng)包含一個(gè)擴(kuò)展，不僅能夠鏈接自有數(shù)據(jù)，也能鏈接外部數(shù)據(jù)。這種架構(gòu)例子早期包括OracleDB鏈接或MicrosoftSQLServer鏈接服務(wù)器等工具。目前，許多具備并行處理MPP功能的數(shù)據(jù)湖引擎都實(shí)現(xiàn)了此類架構(gòu)，如Spark、Dremio或Starburst(Trino)。因此，對(duì)于這一類別，本白皮書(shū)的重點(diǎn)將放在數(shù)據(jù)湖引擎上。在這些系統(tǒng)中，當(dāng)請(qǐng)求外部數(shù)據(jù)時(shí)，工作器節(jié)點(diǎn)會(huì)查詢外部表，并將其輸入并行引擎處理管道。此類供應(yīng)也提供緩存之類技術(shù)。專用數(shù)據(jù)虛擬化層傳統(tǒng)DB和DW云數(shù)據(jù)湖/湖倉(cāng)一體數(shù)據(jù)湖分布式文件系統(tǒng)傳統(tǒng)DB和DW云Excel分布式文件系統(tǒng)（S3、ADLS、HDFS）專用數(shù)據(jù)虛擬化對(duì)比數(shù)據(jù)湖擴(kuò)展兩種架構(gòu)都允許最終用戶在分布式數(shù)據(jù)環(huán)境中運(yùn)行查詢，但處理方式顯著不。下一節(jié)我們將深入探討這些設(shè)計(jì)差異對(duì)查詢執(zhí)行性能的影響。，專用數(shù)據(jù)虛擬化解決方案通常包含額外功能（例如高級(jí)建模、數(shù)據(jù)沿襲和治理），用于創(chuàng)建和管理跨多個(gè)數(shù)據(jù)的語(yǔ)義層。數(shù)據(jù)湖供應(yīng)往往更關(guān)注針對(duì)對(duì)象存儲(chǔ)中的數(shù)據(jù)執(zhí)行查詢，這些功能的分析不在本白皮書(shū)討論范之中，您可以在白皮書(shū)《釋放數(shù)據(jù)生態(tài)系統(tǒng)的全部潛力》中找到更深入的討論。?2024DenodoTechnologies4數(shù)據(jù)虛擬化架構(gòu)中的查詢執(zhí)行比較現(xiàn)在，讓我們來(lái)重點(diǎn)探討這些架構(gòu)的運(yùn)作方式，以及這些架構(gòu)差異對(duì)查詢執(zhí)行和性能的影響。專用數(shù)據(jù)虛擬化層專用數(shù)據(jù)虛擬化層將充當(dāng)關(guān)系數(shù)據(jù)庫(kù)系統(tǒng)，但有一個(gè)重大區(qū)別：它們僅托管元數(shù)據(jù)，它們可以表示對(duì)象的元數(shù)據(jù)（如表、視圖和存儲(chǔ)過(guò)程），這一點(diǎn)與其他任何數(shù)據(jù)庫(kù)無(wú)異，但它們實(shí)際上并不托管數(shù)據(jù)。數(shù)據(jù)結(jié)果總從始數(shù)據(jù)或緩存中獲取，并按需查詢。這些元數(shù)據(jù)不僅包含表名、列和數(shù)據(jù)類型，還包含執(zhí)行底層數(shù)據(jù)查詢所需的所有信息。其中一些細(xì)節(jié)包括：數(shù)據(jù)類型、版本和供應(yīng)；數(shù)據(jù)類型和結(jié)構(gòu)映射；用于成本估的數(shù)據(jù)統(tǒng)計(jì)；以及特定配置，如批量加載設(shè)置、API中的分頁(yè)等。數(shù)據(jù)虛擬化擴(kuò)展的數(shù)據(jù)引擎僅僅支持RDBMS和noSQL，相比之下，這種架構(gòu)通常支持更廣泛的數(shù)據(jù)。當(dāng)最終用戶發(fā)出查詢時(shí)，優(yōu)化器會(huì)構(gòu)建執(zhí)行計(jì)劃，涉及多個(gè)步驟，首先分析查詢中涉及的表/視圖的元數(shù)據(jù)。分析元數(shù)據(jù)和專用數(shù)據(jù)虛擬化引擎的查詢優(yōu)化管道初始元數(shù)據(jù)分析期，引擎可以檢測(cè)兩種可能的場(chǎng)景，并利用這些信息比較可行的查詢執(zhí)行技術(shù)：1.應(yīng)答查詢所需的所有數(shù)據(jù)都在一系統(tǒng)中。根據(jù)數(shù)據(jù)的特征，引擎可以決定：a.利用底層系統(tǒng)的處理能力。這種技術(shù)被稱為“查詢下推”，對(duì)于具有處理能力的底層數(shù)據(jù)（如關(guān)系數(shù)據(jù)庫(kù)、MongoDB，甚至像Salesforce這樣的系統(tǒng)），首選方法。i.此步驟至關(guān)重，因?yàn)樗挂婺軌蚶脭?shù)據(jù)所有與處理能力相關(guān)的功能，例如并行處理、索引、緩存、分區(qū)，以及數(shù)據(jù)引擎可用于加快執(zhí)行速度的其他工件。ii./函數(shù)語(yǔ)法。SQL轉(zhuǎn)換的質(zhì)量越高，性能越好。b.這首選策略。執(zhí)行計(jì)劃將整個(gè)數(shù)據(jù)集引入虛擬化引擎，執(zhí)行任何其他操作（如：列轉(zhuǎn)換、聚合等）。?2024DenodoTechnologies52.數(shù)據(jù)分布在多個(gè)系統(tǒng)中。在這種情況下，數(shù)據(jù)虛擬化優(yōu)化器需在多種操作技術(shù)中選擇，例如連接或聚合（內(nèi)存合并、哈希連接、嵌套循環(huán)、數(shù)據(jù)即時(shí)移動(dòng)到臨時(shí)表等）和查詢重寫(xiě)規(guī)則（分支修剪、部分聚合拆分等）。于成本的優(yōu)化器發(fā)揮重作用，因?yàn)樗褂萌臄?shù)據(jù)統(tǒng)計(jì)數(shù)據(jù)和其他數(shù)據(jù)詳細(xì)信息（例如MPP系統(tǒng)的集群規(guī)模）來(lái)估計(jì)部分?jǐn)?shù)據(jù)量，并利用它們來(lái)權(quán)衡不執(zhí)行方案的成本，然后選擇最優(yōu)方案。這此類架構(gòu)中引擎最復(fù)雜的部分，查詢性能在很大程度上取決于優(yōu)化器做出的決定。我們將在下一個(gè)例子。3.兩種技術(shù)的結(jié)合。在大多數(shù)查詢中，即使數(shù)據(jù)分布在多個(gè)數(shù)據(jù)中，執(zhí)行也會(huì)時(shí)使用上述兩種技術(shù)，因?yàn)榭赡苡行┎僮骺梢韵峦?，而其他操作可以后處理。例如，您可能連接三個(gè)表，但如果其中兩個(gè)表位于一數(shù)據(jù)，那么這個(gè)JOIN仍然可以在單個(gè)執(zhí)行分支中下推。結(jié)果一個(gè)執(zhí)行計(jì)劃中包含一個(gè)或多個(gè)“執(zhí)行分支”，這些分支通常并行執(zhí)行，以到達(dá)每個(gè)數(shù)據(jù)并檢索部分?jǐn)?shù)據(jù)集。最終數(shù)據(jù)集由數(shù)據(jù)虛擬化引擎的上層處理階段使用優(yōu)化器選擇的技術(shù)組成，并被發(fā)送到客戶端工具。為說(shuō)明這些效果，我們以一個(gè)簡(jiǎn)單的查詢?yōu)槔篠ELECTc.country,SUM(s.amount)

FROMpsql.customercJOINsf.saless

ONc.id=s.customer_idGROUPBYc.country該查詢計(jì)每個(gè)國(guó)家/地區(qū)的總銷額。作為景信息，我們假設(shè)Customer表位于PostgreSQL中，有200萬(wàn)行數(shù)據(jù)，而Sales表位于Snow?ake中，有3億行數(shù)據(jù)。如何處理該查詢？?jī)?yōu)化器將生成法和查詢重寫(xiě)規(guī)則的多種組合，估每一步涉及的數(shù)據(jù)量，并根據(jù)估成本選擇最優(yōu)方案。例如，以下優(yōu)化器可能生成的三種候選方案：1億分組依據(jù)數(shù)據(jù)移動(dòng)分組依據(jù)JOINJOIN

分組依據(jù)萬(wàn)萬(wàn)3億萬(wàn)JOIN分組依據(jù)CustomerID萬(wàn)SalesCustomerSales臨時(shí)CustomerSalesCustomerCustomer候選方案候選方案候選方案123樸素策略數(shù)據(jù)移動(dòng)部分聚合下推?2024DenodoTechnologies6我們來(lái)詳細(xì)候選方案1最樸素，對(duì)SQL查詢候選方案2采用完全不的技術(shù)，多候選方案3回歸到了單步執(zhí)行，但的接轉(zhuǎn)換。數(shù)據(jù)將時(shí)從銷表步驟執(zhí)行。第一步，從PostgreSQL并未采用樸素策略，而將查詢重和客戶表中提取，數(shù)據(jù)虛擬化引擎中檢索客戶數(shù)據(jù)，并將其移動(dòng)至寫(xiě)為更高效的形式。為了最大程度會(huì)使用一種可用技術(shù)（如合并或哈地實(shí)施查詢下推，聚合將分為兩個(gè)希連接），在內(nèi)存中合并數(shù)據(jù)，隨由于所有數(shù)據(jù)都存在于Snow?ake步驟：首先按客戶ID進(jìn)行，然后后按照國(guó)家/地區(qū)進(jìn)行匯總，生成中，整個(gè)查詢處理將被下推到按國(guó)家/地區(qū)進(jìn)行。盡管可能有違最終輸出。該策略的最大不足，Snow?ake，并發(fā)送給使用者。我們覺(jué)，但它顯著減少了網(wǎng)絡(luò)流量和需移動(dòng)大量數(shù)據(jù)（3.02億行），可以到，數(shù)據(jù)移動(dòng)已大幅減少到僅數(shù)據(jù)虛擬化引擎中的處理量，時(shí)并在引擎中進(jìn)行處理，才能產(chǎn)生相200萬(wàn)行，并且所有處理都已下推到充分利用Snow?ake等引擎的MPP對(duì)較少的幾百行結(jié)果。，以利用其處理能力。功能。Snow?ake這如何影響執(zhí)行時(shí)？方案時(shí)間候選方案157分2秒候選方案210.26秒候選方案315.23秒從這里我們出，糟糕的計(jì)劃可能需一小時(shí)，最優(yōu)計(jì)劃只需幾秒鐘。在這個(gè)例子中，候選方案2也優(yōu)化器選擇用來(lái)執(zhí)行查詢的方案。但這個(gè)例子只觸及了問(wèn)題表，例如，我們沒(méi)有涉及連接法或表序等主題，另外需注意的，我們沒(méi)有采用任何緩存或聚合感知加速技術(shù)，僅僅實(shí)時(shí)執(zhí)行（有關(guān)這些方案的更多詳細(xì)信息，請(qǐng)參閱下的“其他加速技術(shù)”小節(jié)）。但我們不難出，技術(shù)先進(jìn)的優(yōu)化器對(duì)于及時(shí)產(chǎn)生結(jié)果至關(guān)重。具有數(shù)據(jù)虛擬化擴(kuò)展的數(shù)據(jù)湖引擎現(xiàn)代數(shù)據(jù)湖引擎大規(guī)模并行處理(MPP)系統(tǒng)，其中執(zhí)行引擎已與存儲(chǔ)解耦。這些引擎最初為Hadoop生態(tài)系統(tǒng)創(chuàng)建，后迅速發(fā)展，可適應(yīng)云環(huán)境和不類型的對(duì)象存儲(chǔ)，如AmazonWebServices(AWS)的S3和MicrosoftAzure的ADLS。處理與存儲(chǔ)分離的理念也使這些引擎能夠整合與其他系統(tǒng)的連接器，如外部關(guān)系型數(shù)據(jù)庫(kù)或noSQL平臺(tái)。數(shù)據(jù)湖MPP引擎部署在多節(jié)點(diǎn)集群中，通常包含三種類型的節(jié)點(diǎn)：■協(xié)調(diào)器節(jié)點(diǎn)，負(fù)責(zé)解析查詢、創(chuàng)建執(zhí)行計(jì)劃和管理工作器節(jié)點(diǎn)。協(xié)調(diào)器還負(fù)責(zé)向客戶端返回最終結(jié)果集。■元存儲(chǔ)，存儲(chǔ)表的元數(shù)據(jù)信息，包括列、數(shù)據(jù)類型、分區(qū)和統(tǒng)計(jì)信息?！龉ぷ髌鞴?jié)點(diǎn)，負(fù)責(zé)執(zhí)行查詢和處理數(shù)據(jù)，還負(fù)責(zé)獲取數(shù)據(jù)（通常從對(duì)象存儲(chǔ)中獲?。⒖梢韵嗷ネㄐ?。?2024DenodoTechnologies7SQL數(shù)據(jù)流其他調(diào)用元存儲(chǔ)客戶端應(yīng)用程序協(xié)調(diào)器工作器工作器工作器工作器的、Azure的ADLS等）中，這些文件采用專門用于分析的格式，如Parquet、ORC，以及最近的Delta或Iceberg等表格式。在執(zhí)行管道方，當(dāng)協(xié)調(diào)器接收到查詢后，它會(huì)解析查詢，將其映射到元存儲(chǔ)中的信息，并利用其優(yōu)化器創(chuàng)建分布式查詢計(jì)劃。查詢計(jì)劃以層級(jí)化任務(wù)結(jié)構(gòu)形式構(gòu)建，這些任務(wù)在各工作器節(jié)點(diǎn)上運(yùn)行。每項(xiàng)任務(wù)都會(huì)操作一個(gè)數(shù)據(jù)分片，即更大數(shù)據(jù)集的一部分，使執(zhí)行能夠并行化。例如，訪問(wèn)大型Parquet文件的任務(wù)可以分解到多個(gè)工作器中，由它們?cè)L問(wèn)和處理文件的不部分。協(xié)調(diào)器會(huì)跟蹤各任務(wù)的執(zhí)行位置。目前為止，我們已經(jīng)了解如何使用數(shù)據(jù)湖中的數(shù)據(jù)（如對(duì)象存儲(chǔ)中的Parquet文件）完成執(zhí)行任務(wù)，但這種架構(gòu)如何應(yīng)用于外部數(shù)據(jù)？思考我們?cè)谏弦还?jié)中用作示例的PostgreSQL和Snow?ake數(shù)據(jù)集。在這種情況下，協(xié)調(diào)器將實(shí)例化任務(wù)，通過(guò)JDBC將這些數(shù)據(jù)集檢索到工作器節(jié)點(diǎn)。工作器節(jié)點(diǎn)將檢索數(shù)據(jù)集，使用MPP引擎進(jìn)行處理，就像處理來(lái)自對(duì)象存儲(chǔ)的數(shù)據(jù)一樣。3億Sales200萬(wàn)Customer然而，與訪問(wèn)對(duì)象存儲(chǔ)中可以拆分給多個(gè)工作器的Parquet文件不，對(duì)外部數(shù)據(jù)的訪問(wèn)通過(guò)JDBC連接進(jìn)行，這些連接將工作節(jié)點(diǎn)映射到每個(gè)表，限制了可實(shí)現(xiàn)的并行程度，如上圖所示，產(chǎn)生了與上一節(jié)所述候選方案1類似的情況，在數(shù)據(jù)傳輸上也有樣問(wèn)題。此外，數(shù)據(jù)湖引擎的優(yōu)化器并不像專用數(shù)據(jù)虛擬化引擎那樣，提供各種可聯(lián)合的先進(jìn)技術(shù)（正如我們?cè)谏弦还?jié)所見(jiàn)）。它們的重點(diǎn)在于為處理湖中的數(shù)據(jù)（如Parquet、ORC、Iceberg等）提供強(qiáng)大架構(gòu)，而聯(lián)合功能僅僅重復(fù)使用相的處理管道。?2024DenodoTechnologies8即使所有數(shù)據(jù)都在一個(gè)數(shù)據(jù)中，大多數(shù)數(shù)據(jù)湖引擎也會(huì)使用這種相的執(zhí)行模式，因?yàn)檫B接器不具備高級(jí)SQL方言轉(zhuǎn)換邏輯、復(fù)雜數(shù)據(jù)類型的映射，以及關(guān)于數(shù)據(jù)邏輯的其他信息，例如數(shù)據(jù)整理（數(shù)據(jù)對(duì)非數(shù)字進(jìn)行排序的方式）。這意味數(shù)據(jù)湖引擎將對(duì)每張表進(jìn)行掃描，并使用自己的引擎處理來(lái)自外部的查詢。這種方法有一些優(yōu)點(diǎn)（例如，減少遺留數(shù)據(jù)的工作負(fù)載），但也存在重大問(wèn)題。例如，無(wú)法利用數(shù)據(jù)的內(nèi)部結(jié)構(gòu)來(lái)加速處理查詢（如索引、分區(qū)、緩存等）。到將數(shù)據(jù)湖內(nèi)容與外部系統(tǒng)混合在一起的查詢。這類情況下，引擎將采用并行訪問(wèn)數(shù)據(jù)湖文件和單獨(dú)訪問(wèn)外部?jī)?nèi)容的方式（上述兩種場(chǎng)景的結(jié)合）?；旌戏椒壳?，我們可以到，許多供應(yīng)正在跨越不架構(gòu)界限，融合兩種方法概念的混合型產(chǎn)變得十分常見(jiàn)。實(shí)際上，數(shù)據(jù)湖引擎的協(xié)調(diào)器節(jié)點(diǎn)和專用虛擬化服務(wù)器的實(shí)例有很多共點(diǎn)。數(shù)據(jù)湖引擎通常能夠下推簡(jiǎn)單的謂詞，如WHERE子句中的選條件。一些數(shù)據(jù)湖供應(yīng)在其企業(yè)級(jí)產(chǎn)中傳更強(qiáng)大的下推功能，這些功能對(duì)其開(kāi)版本所提供功能的擴(kuò)展。這些功能使引擎能夠下推一些額外操作，如連接。盡管如此，總體而言，數(shù)據(jù)湖引擎的下推能力較為有限，部分因其SQL方言轉(zhuǎn)換能力有限，另一部分因則缺乏上一節(jié)提到的高級(jí)重寫(xiě)技術(shù)。您也會(huì)到多家專業(yè)數(shù)據(jù)虛擬化供應(yīng)在其產(chǎn)中包含MPP引擎，使這些引擎能夠在數(shù)據(jù)湖場(chǎng)景中提供更好的集成，并在多查詢的上層處理初期階段利用并行處理的優(yōu)勢(shì)。本地?cái)?shù)據(jù)例如，Denodo嵌入了開(kāi)數(shù)據(jù)湖引擎Presto，作為其架構(gòu)中的組件。既可用于數(shù)據(jù)湖處理，也可用于加速聯(lián)合場(chǎng)景中的執(zhí)行。?2024DenodoTechnologies9其他加速技術(shù)盡管此次分析的重點(diǎn)在于實(shí)時(shí)查詢，但該領(lǐng)域的許多供應(yīng)都提供其他加速功能來(lái)提高性能。緩存幾乎所有供應(yīng)都提供緩存功能。緩存允許引擎重復(fù)使用之前計(jì)的結(jié)果。大多數(shù)供應(yīng)還提供更新緩存內(nèi)容的功能，以保持其時(shí)效性（通常通過(guò)增量更新實(shí)現(xiàn)，以避免全盤(pán)更新）。此外，Denodo平臺(tái)還包含用于編排緩存加載的專門組件：Denodo調(diào)度器。當(dāng)優(yōu)化器檢測(cè)到“緩存命中”時(shí)，無(wú)論完全命中，還部分命中，都會(huì)將引擎重定向到緩存系統(tǒng)，以檢索該數(shù)據(jù)，而不根據(jù)始表重新計(jì)。通常會(huì)有一個(gè)可配置的存活時(shí)(TTL)參數(shù)，告訴系統(tǒng)緩存的計(jì)在多長(zhǎng)時(shí)之內(nèi)仍然有效，以避免返回陳舊數(shù)據(jù)。聚合感知加速此外，Denodo還提供聚合感知加速，該技術(shù)將利用聚合產(chǎn)生的較小數(shù)據(jù)集，以及“分析查詢經(jīng)常聚合始數(shù)據(jù)，產(chǎn)生最終結(jié)果”這一事實(shí)。例如，回想上一節(jié)中描述的“按國(guó)家/地區(qū)的總銷額”查詢，聚合感知加速所于的理念：預(yù)聚合的中結(jié)果可用作計(jì)最終結(jié)果的礎(chǔ)，比使用始表快得多。這項(xiàng)技術(shù)有兩大優(yōu)勢(shì)，在分析領(lǐng)域極為有用：■提供了極高的加速系數(shù)，通常比始查詢快10倍、20倍，甚至50倍。時(shí)，提供的“命中”次數(shù)往往比傳統(tǒng)緩存高得多。也就說(shuō)，單一的加速聚合可以服務(wù)于數(shù)百個(gè)不的分析查詢?！霾恍枳罱K用戶的輸入。執(zhí)行引擎會(huì)自動(dòng)檢測(cè)可加速的查詢，并重寫(xiě)它們，以使用預(yù)先計(jì)的聚合。這項(xiàng)技術(shù)的實(shí)施相當(dāng)復(fù)雜，而且提供這項(xiàng)功能的數(shù)據(jù)虛擬化提供不多，如下圖所示，其優(yōu)勢(shì)顯而易見(jiàn)。智能查詢加速161412使用Denodo平臺(tái)進(jìn)行聚合感知查詢10加速的效果。所有查詢均利用于8人工智能推薦創(chuàng)建的單一加速結(jié)構(gòu)，6執(zhí)行時(shí)以秒為單位。420時(shí)加速時(shí)間123456?2024DenodoTechnologies10最后，讓這項(xiàng)技術(shù)有效發(fā)揮作用，關(guān)鍵在于熟練選擇應(yīng)進(jìn)行預(yù)計(jì)和預(yù)聚合的數(shù)據(jù)，但這種決策并非易事。在過(guò)去，需經(jīng)驗(yàn)豐富的DBA干預(yù)，分析需做出性能改進(jìn)的報(bào)告和儀表板，以發(fā)現(xiàn)常見(jiàn)模式，將其轉(zhuǎn)換為聚合。幸運(yùn)的這方，人工智能可以提供幫助，Denodo等供應(yīng)提供了人工智能輔助向?qū)?，通過(guò)分析使用情況，生成定制推薦。關(guān)于這項(xiàng)功能的更深入解釋，可在這篇文中找到，于人工智能的推薦引擎在這篇文中有描述。為測(cè)試這些不的架構(gòu)，我們于事務(wù)處理委員會(huì)(TPC)的準(zhǔn)測(cè)試TPC-Hv3.0.1，設(shè)計(jì)了一個(gè)場(chǎng)景。我們選擇了比例因子為100的版本，在這個(gè)版本中，最大的表(LineItem)包含6億行數(shù)據(jù)。TPC-H的使用在數(shù)據(jù)管理供應(yīng)中非常遍，能夠相當(dāng)合理地代表現(xiàn)實(shí)中的分析場(chǎng)景。表行(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基準(zhǔn)測(cè)試查詢?yōu)榱藢⑦\(yùn)行準(zhǔn)測(cè)試的時(shí)和成本保持在合理的范內(nèi)，我們專注于TPC-H前10個(gè)查詢（共22個(gè)）。查詢編號(hào)業(yè)務(wù)問(wèn)題1此查詢報(bào)告開(kāi)、發(fā)貨和退貨的業(yè)務(wù)量。2此查詢查找應(yīng)選擇哪家供應(yīng)在特定地區(qū)下單購(gòu)買特定零件。3此查詢檢索價(jià)最高的10張未發(fā)貨訂單。4此查詢確定訂單優(yōu)先級(jí)系統(tǒng)的運(yùn)行情況，并評(píng)估客戶滿意度。5此查詢列出通過(guò)本地供應(yīng)完成的收入額。6此查詢量化了如果在給定年份消除特定百分比范內(nèi)的全公司折扣，將會(huì)帶來(lái)的收入增加金額。提出這類“如果”查詢可用于尋找增加收入的方法。7此查詢確定在特定國(guó)家之運(yùn)送的貨物的價(jià)，有助于重新協(xié)運(yùn)輸合。8此查詢確定特定國(guó)家在特定地區(qū)的特定零件類型市場(chǎng)份額在兩年內(nèi)的變化情況。9此查詢確定特定零件系列的利潤(rùn)額，按供應(yīng)所在國(guó)家和年份細(xì)分。10此查詢識(shí)別可能因?yàn)榘l(fā)送給他們的零件而遇到問(wèn)題的客戶。這些查詢的相應(yīng)SQL語(yǔ)句可在TCP網(wǎng)站在線提供的TPC-H技術(shù)規(guī)范中找到。為了呈現(xiàn)一個(gè)分布式數(shù)據(jù)環(huán)境，相的TPC-H數(shù)據(jù)集已經(jīng)以不的來(lái)和格式提供（詳情請(qǐng)參閱下方各個(gè)場(chǎng)景）：AWSRedshift、PostgreSQL和AWSS3中的Parquet文件。?2024DenodoTechnologies12環(huán)境規(guī)格本次準(zhǔn)測(cè)試中測(cè)試的所有不數(shù)據(jù)均在AWS的一區(qū)域內(nèi)部署，具體配置如下：■Redshift：dc2.8xlarge-4個(gè)節(jié)點(diǎn)■PostgreSQL：m5.2xlarge■Parquet格式的對(duì)象存儲(chǔ)數(shù)據(jù)(S3)對(duì)于數(shù)據(jù)湖引擎，我們使用了數(shù)據(jù)湖領(lǐng)域一家領(lǐng)先開(kāi)供應(yīng)的最新版本（撰寫(xiě)本文時(shí)的2024年2月版本）。該引擎還部署在AWS的一區(qū)域和VPC中，規(guī)格如下：■R5.4xlarge節(jié)點(diǎn)■每個(gè)節(jié)點(diǎn)16個(gè)核心■每個(gè)節(jié)點(diǎn)128GBRAM■20個(gè)工作器節(jié)點(diǎn)■每個(gè)工作器最大140GB堆內(nèi)存■元數(shù)據(jù)存儲(chǔ)于HiveMetastore中對(duì)于Denodo虛擬化服務(wù)器，我們使用了以下配置：■M4.2xlarge服務(wù)器■8個(gè)核心■32GBRAM■1臺(tái)虛擬化服務(wù)器■最大8GB堆內(nèi)存在這些測(cè)試中，沒(méi)有對(duì)任何數(shù)據(jù)使用緩存機(jī)制。虛擬層中也沒(méi)有使用緩存或查詢加速機(jī)制?；鶞?zhǔn)測(cè)試場(chǎng)景為了代表分布式場(chǎng)景，我們將TPC-H表放置在了多個(gè)系統(tǒng)中。這為實(shí)現(xiàn)我們?cè)诿總€(gè)場(chǎng)景中詳細(xì)描述的準(zhǔn)測(cè)試多源變體提供了可能性。為了避免異常或外部因素的影響，每個(gè)查詢都被執(zhí)行三次，這些表格中使用的數(shù)的平均。?2024DenodoTechnologies13場(chǎng)景1：訪問(wèn)外部源在這個(gè)場(chǎng)景中，我們模擬的查詢需完全存儲(chǔ)在外部系統(tǒng)中的數(shù)據(jù)。例如，您可能需使用來(lái)自數(shù)據(jù)倉(cāng)庫(kù)的數(shù)據(jù)執(zhí)行查詢。在這個(gè)場(chǎng)景中，我們使用AWSRedshift作為數(shù)據(jù)。查詢編號(hào)數(shù)據(jù)湖供應(yīng)商Denodo11123.6774772052849.3314067031272.0067051849205.3330807845430.3313824726397.3324604.575897.67119142181361.33152631393417.332529649102570.67484988總計(jì)26524.9918508624.5執(zhí)行時(shí)以毫秒為單位。兩個(gè)引擎均成功完成了所有測(cè)試。然而很明顯，Denodo平臺(tái)的專用架構(gòu)能夠利用對(duì)外部企業(yè)數(shù)據(jù)倉(cāng)庫(kù)（如Redshift）的訪問(wèn)能力，其速度比數(shù)據(jù)湖引擎快幾個(gè)數(shù)量級(jí)。如上一節(jié)所述，為每張表使用一個(gè)工作器的數(shù)據(jù)湖策略需在網(wǎng)絡(luò)上移動(dòng)大量數(shù)據(jù)，因此即使有20個(gè)節(jié)點(diǎn)并行處理查詢，執(zhí)行時(shí)也明顯高于Denodo平臺(tái)執(zhí)行的正確下推查詢。小結(jié)如下：DENODO數(shù)據(jù)湖供應(yīng)商總執(zhí)行時(shí)總執(zhí)行時(shí)間26.525小時(shí)8分28秒秒另外需注意的，一些數(shù)據(jù)湖供應(yīng)在其業(yè)產(chǎn)中提供企業(yè)連接器，其下推邏輯比這些測(cè)試中使用的開(kāi)版本更好。雖然提高了性能，仍然比Denodo慢幾個(gè)數(shù)量級(jí)。在“數(shù)據(jù)虛擬化架構(gòu)中的查詢執(zhí)行比較”一節(jié)中，您可以找到這些差異后因的詳細(xì)解釋。?2024DenodoTechnologies14場(chǎng)景2：聯(lián)合兩個(gè)外部源對(duì)于第二個(gè)場(chǎng)景，我們將數(shù)據(jù)集分為兩個(gè)，以模擬聯(lián)合場(chǎng)景。大型表仍保留在AWSRedshift中，但某些表已移至PostgreSQL。分布情況如下：■AWSRedshift：Supplier，PartSuppr，LineItem，Orders■PostgreSQL：Customer，Part，Nation，Region注意：查詢1、4和6不涉及多聯(lián)合，不屬于本測(cè)試的范，因?yàn)榕c場(chǎng)景1中已顯示的數(shù)據(jù)完全相。查詢編號(hào)數(shù)據(jù)湖供應(yīng)商Denodo267567747522317927.2514067054005.25670518720549.253328448819205.513824729204782916110110142.251327585總計(jì)199063.58835578執(zhí)行時(shí)以毫秒為單位。Denodo平臺(tái)的多功能性再次戰(zhàn)勝數(shù)據(jù)湖方法。我們可以到，數(shù)據(jù)湖中的執(zhí)行時(shí)與單場(chǎng)景1非常的相似，因?yàn)閿?shù)據(jù)湖引擎采用的執(zhí)行計(jì)劃非常相似，即于將工作器映射到數(shù)據(jù)表。得注意的，在這次聯(lián)合測(cè)試中，一些查詢速度更快。考慮到數(shù)據(jù)湖引擎中的執(zhí)行計(jì)劃幾乎完全相，解釋為數(shù)據(jù)的工作負(fù)載減少了，現(xiàn)在分成了兩個(gè)不的系統(tǒng)。小結(jié)如下：DENODO數(shù)據(jù)湖供應(yīng)商總執(zhí)行時(shí)總執(zhí)行時(shí)間3分192小時(shí)27分15秒秒?2024DenodoTechnologies15場(chǎng)景3：聯(lián)合數(shù)據(jù)湖和小型外部源數(shù)據(jù)湖引擎高度關(guān)注將數(shù)據(jù)湖作為生態(tài)系統(tǒng)核心部分的場(chǎng)景，測(cè)試部分?jǐn)?shù)據(jù)集位于數(shù)據(jù)湖中的場(chǎng)景也合理的。本測(cè)試和下的測(cè)試代表了這種情況。為通過(guò)Denodo平臺(tái)訪問(wèn)數(shù)據(jù)湖，我們使用Denodo平臺(tái)中包含的于Presto的嵌入式MPP引擎。集群和工作器的規(guī)格與其他數(shù)據(jù)湖供應(yīng)完全相。在本特定案例中，我們將大型事實(shí)表置于數(shù)據(jù)湖中，而較小的維度表則存放在PostgreSQL中。表的分布情況如下：■數(shù)據(jù)湖：Supplier、PartSuppr、LineItemOrders、■PostgreSQL：Customer、Part、Nation、Region查詢編號(hào)數(shù)據(jù)湖供應(yīng)商Denodo281225473.75310591.757070.2556929.2523262.5710251802481571112532.59204787951.75107719169454.25總計(jì)149274133769執(zhí)行時(shí)以毫秒為單位。兩家供應(yīng)均成功完成所有測(cè)試。這種場(chǎng)景正數(shù)據(jù)湖的強(qiáng)項(xiàng)，在并行訪問(wèn)事實(shí)表的情況下，可以并行處理大部分過(guò)程。Denodo平臺(tái)執(zhí)行展示一種混合計(jì)劃，可以利用其MPP進(jìn)行處理，在需時(shí)進(jìn)行聯(lián)合，提供非常相似的結(jié)果。小結(jié)如下：DENODO數(shù)據(jù)湖供應(yīng)商總執(zhí)行時(shí)總執(zhí)行時(shí)間2分292分13秒秒?2024DenodoTech