數(shù)據(jù)編織的性能 2024-數(shù)據(jù)虛擬化架構(gòu)比較

denodo·······I概述3I引言：數(shù)據(jù)虛擬化架構(gòu)4專用數(shù)據(jù)虛擬化層具有數(shù)據(jù)虛擬化擴(kuò)展的數(shù)據(jù)引擎4I數(shù)據(jù)虛擬化架構(gòu)中的查詢執(zhí)行比較5專用數(shù)據(jù)虛擬化層具有數(shù)據(jù)虛擬化擴(kuò)展的數(shù)據(jù)湖引擎7混合方法I基準(zhǔn)測試11I總結(jié)18數(shù)據(jù)編織背后的一個關(guān)鍵思想是，能夠通過一個易于使用的中心化接數(shù)據(jù)編織背后的一個關(guān)鍵思想是，能夠通過一個易于使用的中心化接入點(diǎn)訪問組織中的任何數(shù)據(jù)資產(chǎn)。最終用戶不必應(yīng)對幕后的復(fù)雜數(shù)據(jù)數(shù)據(jù)虛擬化層可以實(shí)現(xiàn)這一點(diǎn)，它可以抽象出復(fù)雜性，并提供中心化的接入點(diǎn)。除了集中訪問之外，該層通常還提供其他功能，如緩存、安全、建模和跨源聯(lián)合等，能夠在整個組織中統(tǒng)一實(shí)施。即使公司數(shù)據(jù)分散在數(shù)十個異構(gòu)系統(tǒng)中，這些功能仍將讓最終用戶感覺，所有數(shù)從業(yè)務(wù)角度來看，數(shù)據(jù)編織的主要目標(biāo)是創(chuàng)建一個敏捷平臺，通過自助服務(wù)數(shù)據(jù)層，以業(yè)務(wù)部門可以理解和使用的方式公開數(shù)據(jù)，從而縮短獲取數(shù)據(jù)的您可以在下面的“基準(zhǔn)測試”小節(jié)中找到測試方法和環(huán)境規(guī)格的詳細(xì)說明。在這里，我們先簡要總結(jié)測試結(jié)果。26.52秒這些結(jié)果展示了分布式環(huán)境中專用數(shù)據(jù)虛擬化層的強(qiáng)大能力。在這種環(huán)境下，其引擎的復(fù)雜程度?2024DenodoTechnologies3數(shù)據(jù)管理供應(yīng)商采用兩種主要的數(shù)據(jù)虛擬化技術(shù)來提供跨多個數(shù)據(jù)源的通用訪問層。在本節(jié)中，我們將比較它們的在這類架構(gòu)中，虛擬化層位于所有數(shù)據(jù)源之上，提供一個中心化接入點(diǎn)。它分析傳入的查詢并將每個請求轉(zhuǎn)發(fā)到包含相應(yīng)數(shù)據(jù)的數(shù)據(jù)源。這個過程被稱為“查詢下推”或“查詢委托”。由于查詢可能涉及來自多個數(shù)據(jù)源的表，因此這類軟件需要包含具有跨數(shù)據(jù)源聯(lián)合功能的引擎和目的驅(qū)動型優(yōu)化器。緩存、聚合感知加速等技術(shù)被頻繁使用。在這類架構(gòu)中，數(shù)據(jù)系統(tǒng)包含一個擴(kuò)展，不僅能夠鏈接自有數(shù)據(jù)，也能鏈接外部數(shù)據(jù)源。這種架構(gòu)例子早期包括在這些系統(tǒng)中，當(dāng)請求外部數(shù)據(jù)時(shí)，工作器節(jié)點(diǎn)會查詢外部表，并將其輸入并行引擎處理管道。此類供應(yīng)商也提供++++++++++++++++云云++十+++ >云數(shù)據(jù)湖數(shù)據(jù)湖/湖倉一體分布式文件系統(tǒng)分布式文件系統(tǒng)專用數(shù)據(jù)虛擬化對比數(shù)據(jù)湖擴(kuò)展兩種架構(gòu)都允許最終用戶在分布式數(shù)據(jù)環(huán)境中運(yùn)行查詢，但處理方式顯著不同。下一節(jié)我們將深入探討這些設(shè)計(jì)差值得注意的是，專用數(shù)據(jù)虛擬化解決方案通常包含額外功能（例如高級建模、數(shù)據(jù)沿襲和治理用于創(chuàng)建和管理跨多個數(shù)據(jù)源的語義層。數(shù)據(jù)湖供應(yīng)商往往更關(guān)注針對對象存儲中的數(shù)據(jù)執(zhí)行查詢，這些功能的分析不在本白皮書?2024DenodoTechnologies專用數(shù)據(jù)虛擬化層將充當(dāng)關(guān)系數(shù)據(jù)庫系統(tǒng)，但有一個重大區(qū)別：它們僅托管元數(shù)據(jù)，它們可以表示對象的元數(shù)據(jù)（如表、視圖和存儲過程），這一點(diǎn)與其他任何數(shù)據(jù)庫無異，但它們實(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ì)；以及 基于規(guī)則的優(yōu)化器↓執(zhí)行計(jì)劃查詢解析基于成本的優(yōu)化器分析元數(shù)據(jù)和源功能 基于規(guī)則的優(yōu)化器↓執(zhí)行計(jì)劃查詢解析基于成本的優(yōu)化器分析元數(shù)據(jù)和源功能a.利用底層系統(tǒng)的處理能力。這種技術(shù)被稱為“查詢下推”，對于具有處理能力的底層數(shù)據(jù)源（如關(guān)系數(shù)據(jù)i.此步驟至關(guān)重要，因?yàn)樗挂婺軌蚶脭?shù)據(jù)源所這是首選策略。執(zhí)行計(jì)劃將整個數(shù)據(jù)集引入虛擬化引擎，執(zhí)行任何其他操作（如：列轉(zhuǎn)換、聚合等）。?2024DenodoTechnologies52.數(shù)據(jù)分布在多個系統(tǒng)中。在這種情況下，數(shù)據(jù)虛擬化優(yōu)化器需要在多種操作技術(shù)中選擇，例如連接或聚合（內(nèi)存合并、哈希連接、嵌套循環(huán)、數(shù)據(jù)即時(shí)移動到臨時(shí)表等）和查詢重寫規(guī)則（分支修剪、部分聚合拆分等）。基于成本的優(yōu)化器發(fā)揮著重要作用，因?yàn)樗褂萌娴臄?shù)據(jù)源統(tǒng)計(jì)數(shù)據(jù)和其他數(shù)據(jù)源詳細(xì)信息（例這是此類架構(gòu)中引擎最復(fù)雜的部分，查詢性能在很大程度上取決于優(yōu)化器做出的決定。我們將在下面看到3.兩種技術(shù)的結(jié)合。在大多數(shù)查詢中，即使數(shù)據(jù)分布在多個數(shù)據(jù)源中，執(zhí)行也會同時(shí)使用上述兩種技術(shù)，因?yàn)榭赡苡行┎僮骺梢韵峦?，而其他操作可以后處理。例如，您可能要連接三個表，但如果其中兩個表位于同一結(jié)果是一個執(zhí)行計(jì)劃中包含一個或多個“執(zhí)行分支”，這些分支通常并行執(zhí)行，以到達(dá)每個數(shù)據(jù)源并檢索部分?jǐn)?shù)據(jù)優(yōu)化器將生成算法和查詢重寫規(guī)則的多種組合，估算每一步涉及的數(shù)據(jù)量，并根據(jù)估算成本選擇最優(yōu)方案。例如，以分組依據(jù)JOIN分組依據(jù)JOIN數(shù)據(jù)移動數(shù)據(jù)移動分組依據(jù)JOIN分組依據(jù)JOIN200萬200萬3億200萬臨時(shí)Customer臨時(shí)Customer樸素策略樸素策略數(shù)據(jù)移動分組依據(jù)分組依據(jù)JOIN200200萬分組依據(jù)Customer分組依據(jù)CustomerID200200萬部分聚合下推?2024DenodoTechnologies6的直接轉(zhuǎn)換。數(shù)據(jù)將同時(shí)從銷售表和客戶表中提取，數(shù)據(jù)虛擬化引擎會使用一種可用技術(shù)（如合并或哈希連接），在內(nèi)存中合并數(shù)據(jù)，隨后按照國家/地區(qū)進(jìn)行匯總，生成最終輸出。該策略的最大不足是，需要移動大量數(shù)據(jù)（3.02億行），并在引擎中進(jìn)行處理，才能產(chǎn)生相步驟執(zhí)行。第一步，從PostgreSQL中檢索客戶數(shù)據(jù)，并將其移動至由于所有數(shù)據(jù)都存在于Snow?ake中，整個查詢處理將被下推到Snow?ake，并發(fā)送給使用者。我們可以看到，數(shù)據(jù)移動已大幅減少到僅200萬行，并且所有處理都已下推到并未采用樸素策略，而是將查詢重寫為更高效的形式。為了最大程度地實(shí)施查詢下推，聚合將分為兩個按國家/地區(qū)進(jìn)行。盡管可能有違直覺，但它顯著減少了網(wǎng)絡(luò)流量和數(shù)據(jù)虛擬化引擎中的處理量，同時(shí)充分利用Snow?ake等引擎的MPP但這個例子只觸及了問題表面，例如，我們沒有涉及連接算法或表順序等主題，另外需要注意的是，我們沒有采用任何緩存或聚合感知加速技術(shù)，僅僅是實(shí)時(shí)執(zhí)行（有關(guān)這些方案的更多詳細(xì)信息，請參閱下面的“其他加速技術(shù)”■工作器節(jié)點(diǎn)，負(fù)責(zé)執(zhí)行查詢和處理數(shù)據(jù)，還負(fù)責(zé)獲取數(shù)據(jù)（通常從對象存儲中獲?。?，并可以相互通信。?2024DenodoTechnologies數(shù)據(jù)流------->其他調(diào)用客戶端應(yīng)用程序?qū)ο蟠鎯ο蟠鎯υ趫?zhí)行管道方面，當(dāng)協(xié)調(diào)器接收到查詢后，它會解析查詢，將其映射到元存儲中的信息，并利用其優(yōu)化器創(chuàng)建分布式查詢計(jì)劃。查詢計(jì)劃以層級化任務(wù)結(jié)構(gòu)形式構(gòu)建，這些任務(wù)在各工作器節(jié)點(diǎn)上運(yùn)行。每項(xiàng)任務(wù)都會操作一個數(shù)據(jù) 元存儲客戶端應(yīng)用程序客戶端應(yīng)用程序協(xié)調(diào)器協(xié)調(diào)器工作器工作器工作器200萬工作器200萬工作器在數(shù)據(jù)傳輸上也有同樣問題。此外，數(shù)據(jù)湖引擎的優(yōu)化器并不像專用數(shù)據(jù)虛擬化引擎那樣，提供各種可聯(lián)合的先進(jìn)?2024DenodoTechnologies即使所有數(shù)據(jù)都在同一個數(shù)據(jù)源中，大多數(shù)數(shù)據(jù)湖引擎也會使用這種相同的執(zhí)行模式，因?yàn)檫B接器不具備高級SQL方言轉(zhuǎn)換邏輯、復(fù)雜數(shù)據(jù)類型的映射，以及關(guān)于數(shù)據(jù)源邏輯的其他信息，例如數(shù)據(jù)整理（數(shù)據(jù)源對非數(shù)字值進(jìn)行排序的方式）。這意味著數(shù)據(jù)湖引擎將對每張表進(jìn)行掃描，并使用自己的引擎處理來自外部源的查詢。這種方法有一些優(yōu)點(diǎn)（例如，減少遺留數(shù)據(jù)源的工作負(fù)載但也存在重大問題。例如，無法利用數(shù)據(jù)源的內(nèi)部結(jié)構(gòu)來加速處理值得注意的還有，以數(shù)據(jù)湖為中心的生態(tài)系統(tǒng)中，經(jīng)常會看到將數(shù)據(jù)湖內(nèi)容與外部系統(tǒng)混合在一起的查詢。這類目前，我們可以看到，許多供應(yīng)商正在跨越不同架構(gòu)界限，融合兩種方法概念的混合型產(chǎn)品變得十分常見。實(shí)際大的下推功能，這些功能是對其開源版本所提供功能的擴(kuò)展。這些功能使引擎能夠下推一些額外操作，如連接。盡Warehouse調(diào)度程序數(shù)據(jù)目錄+++++++++.虛擬化服務(wù)器對象存儲數(shù)據(jù)科學(xué)筆記本其他應(yīng)用程序本地?cái)?shù)據(jù)Warehouse調(diào)度程序數(shù)據(jù)目錄+++++++++.虛擬化服務(wù)器對象存儲數(shù)據(jù)科學(xué)筆記本其他應(yīng)用程序本地?cái)?shù)據(jù)操作型操作型?2024DenodoTechnologies幾乎所有供應(yīng)商都提供緩存功能。緩存允許引擎重復(fù)使用之前計(jì)算的結(jié)果。大多數(shù)供應(yīng)商還提供更新緩存內(nèi)容的功能，以保持其時(shí)效性（通常通過增量更新實(shí)現(xiàn)，以避免全盤更新）。此外，De當(dāng)優(yōu)化器檢測到“緩存命中”時(shí)，無論是完全命中，還是部分命中，都會將引擎重定向到緩存系統(tǒng)，以檢索該數(shù)據(jù)，此外，Denodo還提供聚合感知加速，該技術(shù)將利用聚合產(chǎn)生的較小數(shù)據(jù)集，以及“分析查詢經(jīng)常聚合原始數(shù)據(jù)，產(chǎn)生最終結(jié)果”這一事實(shí)。例如，回想上一節(jié)中描述的“按國家/地區(qū)的總銷售額”查詢，聚合感知加速所基于的理念是：預(yù)聚合的中間結(jié)果可用作計(jì)算最終結(jié)果的基礎(chǔ)，比使用原始表快得多。這項(xiàng)技術(shù)有兩大優(yōu)勢，在分析領(lǐng)域極為有用：■不需要最終用戶的輸入。執(zhí)行引擎會自動檢測可加8使用Denodo平臺進(jìn)行聚合感知查詢加速的效果。所有查詢均利用基于人工智能推薦創(chuàng)建的單一加速結(jié)構(gòu)，執(zhí)行時(shí)間以秒為單位。864200?2024DenodoTechnologies最后，要讓這項(xiàng)技術(shù)有效發(fā)揮作用，關(guān)鍵在于熟練選擇應(yīng)進(jìn)行預(yù)計(jì)算和預(yù)聚合的數(shù)據(jù)，但這種決策并非易事。幸運(yùn)的是這方面，人工智能可以提供幫助，Denodo等供應(yīng)商提供了人定制推薦。關(guān)于這項(xiàng)功能的更深入解釋，可在這篇文章中找到，基于人工智能的推薦引擎在這篇文章中有描述。 15,000,000150,000,000600,037,90280,000,00020,000,0001,000,000255<<<<<<<<2555?2024Denodo123456此查詢量化了如果在給定年份消除特定百分比范圍內(nèi)的全公司折扣，將會帶來789?2024DenodoTechnologies對于數(shù)據(jù)湖引擎，我們使用了數(shù)據(jù)湖領(lǐng)域一家領(lǐng)先開源供應(yīng)商的最新版本（撰寫本文時(shí)的2024年2月版■20個工作器節(jié)點(diǎn)■?2024DenodoTechnologies在這個場景中，我們要模擬的查詢需要完全存儲在外部系統(tǒng)中的數(shù)據(jù)。例如，您可能需要使12349205.3330807845624604.5789252964948498826524.9918508624.5執(zhí)行時(shí)間以毫秒為單位。兩個引擎均成功完成了所有測試。然而很明顯，Denodo平臺的專用架構(gòu)能夠利用對外部企業(yè)數(shù)據(jù)倉庫（如Redshift）的訪問能力，其速度比數(shù)據(jù)湖引擎快幾個數(shù)量級。如上一節(jié)所述，為每張表使用一個工作器的數(shù)據(jù)湖策略需要在網(wǎng)絡(luò)上移動大量數(shù)據(jù)，因此即使有20個節(jié)點(diǎn)并行處理查詢，執(zhí)行時(shí)間也明顯高于Denodo平臺執(zhí)26.52秒26.52秒另外需要注意的是，一些數(shù)據(jù)湖供應(yīng)商在其商業(yè)產(chǎn)品中提供企業(yè)連接器，其下推邏輯比這些測試中使用的開源版本場景2：聯(lián)合兩個外部源26756354005.25720549.2533284488920478199063.58835578執(zhí)行時(shí)間以毫秒為單位。數(shù)據(jù)湖引擎采用的執(zhí)行計(jì)劃非常相似，即基于將工作器映射到數(shù)據(jù)源表。值得注意的是，在這次聯(lián)合測試中，一些查詢速度更快?？紤]到數(shù)據(jù)湖引擎中的執(zhí)行計(jì)劃幾乎完全相同，解釋為數(shù)據(jù)源的工作負(fù)載減少了，現(xiàn)在分成了兩個?2024DenodoTechnologies場景3：聯(lián)合數(shù)據(jù)湖和小型外部源數(shù)據(jù)湖引擎高度關(guān)注將數(shù)據(jù)湖作為生態(tài)系統(tǒng)核心部分的場景，測試部分?jǐn)?shù)據(jù)集位于數(shù)據(jù)湖中的場景也是合理的。本規(guī)格與其他數(shù)據(jù)湖供應(yīng)商完全相同。在本特定案例中，我們將大型事實(shí)表置于數(shù)據(jù)湖中，而較小的維度表則存放在237070.2556929.2523262.578024892047869454.25執(zhí)行時(shí)間以毫秒為單位。兩家供應(yīng)商均成功完成所有測試。這種場景正是數(shù)據(jù)湖的強(qiáng)項(xiàng)，在并行訪問事實(shí)表的情況下，可以并行處理大部分2分29秒?2024DenodoTechnologies場景4：聯(lián)合數(shù)據(jù)湖和大型外部源作為上述場景變體，我們修改了表的分布，使大型表格位于數(shù)據(jù)湖之外，代表了例如企業(yè)數(shù)據(jù)倉庫中大型表需要與