一、數據架構的演變背景介紹

在探討數據架構演變之前，先來看一下當前數據使用的趨勢。

從多個數據研究機構（如 IDC、IDG、Gartner 等）的統計數據來看，數據量的膨脹是不可避免的趨勢。與此同時，數據種類也日益增多。在傳統的 ETL 時代，企業可能僅依賴少數幾種數據庫類型，但如今，分布式數據架構、云上數據等多種形式，使得大企業面臨著平均多達四百多種不同類型的數據源，以滿足企業分析需求。

另一個顯著趨勢是數據的民主化，也稱為自主服務，越來越多的客戶期望將數據交給業務單位（BU）進行自主分析。過去，數據倉庫（數倉）或商業智能（BI）項目大多由 IT 部門主導，但這種方式已逐漸難以滿足用戶需求，因為用戶期望能夠自主獲取和分析數據，而不僅僅依賴于預設的報表或有限的維度數據。

回顧數據架構的演變歷程，早期數據缺乏集中管理，直至 20 世紀 90 年代，進入數倉時代，ETL 開始在企業中發揮重要作用。進入 2000 年后，隨著數倉的建設成本及企業數據量、種類的不斷增加，如物聯網（IoT）數據的出現，數據湖等概念應運而生。盡管數據湖允許企業將數據以原始格式存儲在數據庫中，但這也導致了數據分散的問題，即使有數據倉庫、數據湖的存在，企業仍面臨跨系統數據整合的挑戰。到了 2010 年代，Gartner 提出了邏輯數據倉庫的概念，即未來的數據倉庫可以是邏輯上的概念，而不一定需要將所有數據實際存儲在一個物理存儲體中，這是數據管理模式的重大轉變。

當提及這一概念時，Denodo 提出一個簡潔的口號：“停止收集，開始連接”。以往企業致力于收集數據，將不同平臺、系統的數據匯聚至一個物理倉儲，用于分析，而無論采用數倉還是數據湖等方式，基本都需開展ETL工作。然而當邏輯數倉概念出現后，我們開始思考是否能夠轉變思路，不再執著于將所有數據收集整合，而是優先嘗試建立連接，至于為何如此，后續將進一步探討。

傳統 ETL 旨在解決數據孤島問題，即將不同系統的數據整合到一個統一的分析平臺。然而，ETL 在實際應用中存在一些問題。例如，在企業合并時，原有的 ETL 系統往往難以復用，需要重新構建。

無論是 ETL 還是 ELT，都有眾多工具可以實現高效的批量數據轉移，大多數企業都有能力在內部實施。但其也存在流程復雜，時間和人力成本較高等問題。

二、NoETL 的概念與架構

NoETL 概念的產生源于實際需求。

從數據使用困境來看，傳統的數倉和數據復制搬移集成方式在面對企業數字化轉型過程中的新需求時顯得力不從心。例如，業務部門提出的一次性問題或基于外部趨勢的臨時性分析需求，通過傳統 IT 方式響應時間過長且實際效用不大。此外，大量未知數據（如第三方或政府發布的一次性數據）難以通過傳統 ETL 方式整合，以及數據科學家在探索創新過程中所需的外部數據也難以融入傳統 ETL 架構。

在實際工作中，許多數據具有臨時性，有時并不需要持久存儲。面對臨時性需求以及探索性需求，采用 ETL 方式將數據加載到一個地方后用戶才能使用，這種做法極為繁瑣。此外，為滿足簡單或短暫需求而進行數據搬移時，所需的能力成本和維護成本相當高昂。例如，一個數倉可能包含數千甚至上萬張表，但實際上并不知道哪些數據正在被使用，可能為了每月僅查看一次的內容而每天搬運數據，合理性存疑。

“NoETL” 概念正是針對這一問題，通過數據虛擬化和實時處理等技術，避免傳統的加載流程，無需把大量數據復制到數倉或數湖。

從架構角度來看，以往要做一個分析系統，需要執行的ETL 操作可能涉及更多環節，如 Stage、Data Warehouse、Data Mart 等等，一直到前端呈現，整個流程頗為冗長。而虛擬化技術（它可視為 NoETL 的一種實現方式），其特點在于不再進行層層的數據搬移，前端使用者能夠實時查看數據并且進行整合操作。如前所述，“NoETL”的關鍵差異在于數據是否需要加載到存儲中，它也需要進行數據轉換（transformation），并且特別注重即時服務，這是該架構的核心需求。

接下來，將進一步介紹 Denodo 對數據虛擬化的實現，隨后也會探討不同廠商在“NoETL”技術應用方面存在的差異。

三、數據虛擬化

Denodo 是一個邏輯上的軟件平臺，其面向的數據消費者可通過各種 BI 工具或 API 進行操作，背后涉及龐雜的數據類型。Denodo 能夠連接 200 多種不同的數據源，這些數據源種類繁雜，隨地區、國家及產品而異。

在邏輯架構方面，所有實體可對應到邏輯上的一張視圖（view），其可能對應的是 Oracle表、SAP 的 API、Kafka 的主題或云上 API 等等。接著，類似于 ETL 中的抽取（extraction）環節，Denodo 會讀取這些數據，之后進行轉換（transform），多數 NoETL 工具廠商采用 SQL 進行開發，Denodo 本身也基于 SQL。相比傳統 ETL，NoETL 工具對技術能力的要求大大降低，因為熟悉 SQL 語法的人員較多。

Denodo 存在業務層與邏輯層，類似于數據倉庫中的各環節，如清洗層、轉換層、星型模式（star schema）直至報告層等等，在邏輯概念中同樣存在，只是表現為衍生的派生圖（derived view），通過建立視圖來滿足不同需求。

數據消費者下達 SQL 或 API 查詢后，Denodo 會解析 API 或 SQL，依據業務語義層確定所需數據源，解析邏輯語法后從不同數據庫抓取必要的數據并整合，消費者無需依賴 IT 整理業務需求。例如上圖案例中，涉及到營銷平臺上的營銷活動數據、數據倉庫中的消費數據，通過 Denodo 可以實現整合分析。

不過，在實際運營中，由于需從不同數據源獲取數據，可能面臨性能問題。為此，可根據業務需求設置緩存（cache），如日常報表可使用緩存提升性能，臨時緊急需求可通過指定參數直接獲取原始數據。在 AI 使用場景下，如數據科學家進行全量模式分析且數據量巨大時，可調用外部 MPP 引擎協助運算。

當前市場上虛擬化工具眾多，事實上，虛擬化技術并非近年才出現，就 Denodo 而言，公司自 1999 年起的 25 年來一直從事相關業務。只是近年來，傳統 ETL 相關需求發生了變化，使得虛擬化技術受到更多關注。

Gartner 指出，虛擬化主要由以下幾類廠商提供：其一為獨立廠商，專門打造相關機制；其二是傳統 ETL 即數據集成廠商，他們也具備提供部分此類能力；其三則是數據庫廠商，憑借數據庫連接能力擴展虛擬化功能；此外，部分報表工具和 API 工具也具備部分數據虛擬化能力。不同廠家產品各具優劣，具體取決于應用場景。例如，若企業已有 ETL，可根據自身需求選擇是否采用獨立的專門工具來實現虛擬化功能。

一般而言，提供部分虛擬化能力或擴展虛擬化能力的廠商，在安全、建模、數據目錄、自助服務等方面缺乏能力，或者缺乏基于 Presto 的 MPP 引擎，相對來說耗費資源、成本高昂、數據交付速度緩慢，無法在復雜的數據生態中高效運作。Denodo 是數據虛擬化當之無愧的全球領導者，多年蟬聯 Gartner 數據集成工具魔力象限領導者位置、Forrester 企業數據編織領導者位置。

ETL 與虛擬化在數據領域存在緊密關聯，二者均屬于數據集成范疇，在 Gartner 的分類中也有所體現。倘若當前需求側重于大量數據復制以及歷史數據累積，比如某些系統即便能連接原始數據，但交易數據存儲時長有限（如僅一兩年），仍需進行累積，并且涉及復雜的清洗轉換工作，例如執行數據質量檢查或復雜運算時，建議采用 ETL 架構來實施。

而數據虛擬化則可以簡化數據訪問。以往獲取數據可能需要訪問諸多數據源，且在 Hadoop 上的認證等設定極為復雜。而通過 Denodo，可以提供統一視圖，這類似于構建了企業整體的概念性業務模型，其背后可融合結構化與非結構化數據庫。如果企業中有實時性報表及分析需求，那么數據虛擬化技術將更具應用價值。

傳統 ETL 項目與數據虛擬化項目相比有諸多差異值得關注。

首先，傳統 ETL 所實施的項目穩定性相對較高，而虛擬化的優勢則體現在執行速度較快。從成本角度來看，無論是專業工程師人力成本還是應急投資成本等均是需要考量的因素。Forrester 曾進行分析，結果顯示采用數據虛擬化技術后，項目交付時間大幅縮短，約減少了 65%。同時，我們面臨著模型頻繁變動的情況。例如一個數據倉庫模型可能經過一兩年構建完成，但不久后便需再次調整，這凸顯了靈活性的重要性。而虛擬化項目在靈活性上更具優勢。另外，在跨國客戶場景中，還會遇到數據復制受限的問題，比如一些跨國企業就面臨此類情況。在可靠性方面，由于網絡因素影響，原始數據可能受到沖擊，若要確保虛擬化項目中數據可靠，存在一定難度。并且對于復雜的清洗工作，可能仍需借助 ETL 來完成。最后，數據的新鮮度也是一個要點，虛擬化項目中的數據更接近實時。

四、數據虛擬化的實際應用案例

接下來將簡要介紹一些案例，旨在讓大家了解如何運用 NoSQL 來解決問題。Denodo 本身具備諸多關鍵技術，有著廣泛的應用場景。這些案例展示了使用 Denodo 產品所達成的成果。在許多情況下，Denodo 所扮演的角色類似于商業智能工具，能夠為數據科學家和業務用戶等提供支持。

第一個案例是國內一家新能源車制造廠商，其業務涉及工廠的一次性扣料相關工作，由于擁有多個不同的工廠和庫房，在生產線上處理此類事務時面臨挑戰。過去，他們采用傳統的 ETL 方法，后續雖然使用了低代碼平臺，但仍需編寫代碼。而使用 Denodo 處理相同業務、整合不同數據時，完全采用無代碼的拖拉方式，就能實現跨數據源及不同數據種類的轉換。

這個案例是一家臺灣的工業電腦廠商。該廠商希望構建一個企業級數據庫，因為他們認為數據庫可集中存儲所有所需數據。他們的平臺連接了三十多種數據源，涵蓋 DB、MES 等生產線工廠數據以及外部 API 數據，并且還和臺灣、內地及國外的一些工廠相連。起初，這個廠商曾期望構建一個數據湖，但最終采用了通過 Denodo 進行連接的邏輯架構，這種架構如同中央廚房一般，可將各類數據源視作產地直售的產品，數據進入后進行業務名詞定義、產品分類（domain）以及其他業務分類，最終由數據消費者自主使用數據。

從全球領先的車輛租賃和車隊管理企業案例中可以看到其具備傳統 ETL 遷移數倉的特點，并且在整個企業與消費者之間，通過一種邏輯架構來實現數據編織。

數據編織對于集團型企業具有顯著優勢。如前文所述，對于大型企業，鑒于其在全球范圍內設有多個數據中心的情況，借助 Denodo 平臺能夠實現各數據中心的串聯。如此一來，企業內的任何業務單位，無論身處何地，均可訪問全球范圍內的數據。

某些政府單位會做得更復雜一些。如新加坡政府各個部門通過 Denodo 平臺將不同的數據進行串聯，實現了數據的即時整合與訪問，這種方式被稱為數據合并（Data Merge）。在這一過程中，并不需要將所有部門的數據物理地遷移至 Denodo 中存儲，而是在需要使用數據時，才從各自部門中調取所需信息。

五、未來發展與展望

在最后一個章節中，將探討對未來發展的展望。

目前，通過使用 Denodo 平臺，我們能夠實現實時數據訪問，減少數據復制，并擴大數據覆蓋范圍。同時，還可以建立一套完整且嚴格的數據安全治理體系。這是當前數據虛擬化的現狀，那么未來的發展趨勢是怎樣的呢？

首先，我們必須繼續強化實時數據處理的能力。隨著數據種類和類型的日益增多，我們面臨的需求也更加復雜，因此需要實施更長期的數據生命周期管理和推進數據自主化。當然，也會有更多的人工智能技術被引入，以支持非技術用戶也能輕松訪問和理解數據。特別是檢索增強生成技術（RAG）的應用將成為重要趨勢。在臺灣，一些企業客戶已經開始探索這一領域，例如，用戶可以通過以自然語言與聊天機器人對話的方式來獲取所需數據。

綜上所述，ETL 與 NoETL 的主要區別在于數據的實時性和靈活性。展望未來，Denodo 的發展方向將逐步轉向利用 AI 技術提供輔助。值得注意的是，NoETL 并非旨在完全取代傳統的 ETL 方法，而是提倡企業在數據管理實踐中結合兩者的優點，靈活運用實時數據處理與批處理技術，以實現更加高效的數據管理策略。我個人認為，NoETL 的概念并不是否定 ETL 的重要性，而是強調在數據整合領域，除了 ETL 之外，還有其他方法和技術可以利用，以適應不斷變化的數據環境和業務需求。

感謝各位的聆聽，謝謝！

六、Q&A

Q1：請問在 Denodo 中跨多種數據源的復雜關聯查詢是如何實現并保證查詢性能的？

A1：在 Denodo 長達 25 年的技術積累中，有一個在本次分享中未詳細討論的重要技術點，即查詢優化。在之前的介紹中，我們提到了一張說明圖，該圖展示了如何將業務語義層的請求優化至不同的數據源中提取數據。這是 Denodo 的一大核心優勢所在。面對海量數據，如果沒有高效的優化機制，在數據源層面進行必要的整理和轉換后再在平臺上進行整合，往往會成為性能的瓶頸，導致大量不必要的數據遷移。

得益于在該領域多年的深耕細作，Denodo 的獨特之處在于其強大的查詢優化器，能夠確保在分布式數據架構中快速獲得所需結果，而無需大規模移動數據。

Q2：展望未來，您更看好傳統的 ETL 還是更加靈活的 NoETL 方向的發展？在整體主流趨勢上，您認為將更偏向于哪一方？

A2：我強調選擇 ETL 或 NoETL 應基于具體的業務需求場景。正如之前提到的，包括 Denodo 在內的許多現有客戶都在使用 ETL。我認為 ETL 是企業基礎架構的一部分，是不可或缺的。然而，隨著業務需求的多樣化和創新，NoETL 的應用場景將會逐漸增加。但是，對于那些不需要通過數據創造更多價值和收入的機構來說，它們可能不會強烈感受到采用 NoETL 的必要性，比如一些政府部門只需要制作日報、月報。

Q3：請問在語義管理過程中需要大量的人工進行配置嗎？

A3：以臺灣某客戶的項目為例，該項目并未擴大團隊規模，而是完全依靠現有的IT 人員完成。Denodo 憑借其在該領域近二十年的經驗，不僅提供了強大的工具支持，還帶來了一系列成熟的產品方法論。例如，在構建不同的域和應用層時，Denodo 提供了一套實施架構指導，幫助用戶高效完成項目。在這個過程中，確實需要進行一些業務定義工作，這部分工作通常需要人工完成，因為在早期階段，系統中往往未保存這些信息，且相關信息可能分散在多個業務系統中，需要手動收集。值得一提的是，Denodo 現已通過 AI 技術的整合，能夠對表結構或 SQL 查詢提供初步建議。這意味著，用戶不必從零開始構建語義層，而是可以通過 AI 快速獲得基礎建議，之后再根據具體情況進一步討論和調整。這種方式大大減少了初期的工作量，尤其是在數據治理方面，盡管最終仍需人工審核和確認，但 AI 的介入顯著提升了效率和準確性。