一、什么是 Data Fabric 與數據虛擬化

1. 集中式數倉面臨的困境

在正式介紹 Data Fabric 之前，先來看一下現有數倉體系面臨的問題。提到數倉，很多做數據的同學都會想到 ETL，以及 Hive、Hadoop、Spark 這些技術。但很多數倉使用者，包括數據的生產者、消費者、甚至是老板，都對數倉有著各種不滿。

從數據生產者的角度來看，他們每天會面臨大量的分析、取數需求，從前端提出的需求各種各樣，甚至一個需求還會不斷變化。從數據消費者的角度來看，比如分析師、運營同學，他們常常覺得需求難以得到滿足，可能要等候排期，或者是數據還沒有等等。

再站在老板的視角，數倉跟物理世界的倉庫類似，都是用來存放東西的，只不過數倉存儲的是數據，數據搬進去之后，還需要分門別類去維護，以便在要用的時候能快速找到并拿出來。但是它跟物理倉庫有一個很大的差別，那就是物理倉庫是有進有出的，而數據倉庫卻只進不出，隨著業務的快速增長，數據倉庫也會急劇增長，但數據倉庫能解決的問題卻不是成比例增長的，其業務價值不但沒有成比例增加，反而由于數倉規模的增大導致投入和維護成本成急劇增加，進而導致很多數倉建設有一定時間的公司都急需數據治理。

其實數據治理本質就是通過人為手段去解決數倉業務價值不能匹配的問題，因此，站在老板視角來看，數倉的投入產出比是極低的。所以傳統數倉有兩個很嚴重的矛盾：第一個是生產者跟消費者供需的矛盾，第二個是數倉整體投入產出比的矛盾。

對于用戶來講，可能有些數據在數倉里面，有些數據在 MySQL 里面，有些數據甚至是一個文件，他會希望拿到這些數據就可以直接去分析，而不是還得先把這個數據入倉，再轉換一下，最后才能用。這就是傳統數倉與實際需求之間的 GAP。

總結來講，傳統集中式數倉面臨著三個方面的挑戰：第一個方面是成本；第二個方面是合規，因為大家對數據隱私方面的要求越來越高，企業、政府以及法律法規上也越來越嚴格；第三個方面是效率。

2. Data Fabric，新一代數據架構的思想

接下來看一下 Data Fabric。Gartner 發布的《2021 年十大數據和分析技術趨勢》中，Data Fabric 被列在首位，它是一項加速變革的技術。作為一項顛覆性的技術，Data Fabric 的出現是有它的原因的。首先，Data Fabric 認為哪怕企業有成熟的數倉，甚至有數據湖，仍然需要 Data Fabric。因為在現實世界中我們無法把所有的數據物理集中到一個地方給用戶使用，過去數十年無數企業和技術方案都驗證過，這是一條很難實現并只能停留在理想世界中的方案，這是其最基本的理念。

Data Fabric 到底是什么？Data Fabric 中文翻譯成數據網格。而數據的虛擬化是實現數據網格化很關鍵的一項技術。當然 Data Fabric 還有一些其他的相關概念，比如 Data Ops、主動元數據等等。本文主要介紹數據虛擬化這一部分。如果大家對其他 Data Fabric 概念感興趣，可以通過上圖中的二維碼來獲取我們的 Data Fabric 白皮書。

3. 數據虛擬化讓數據隨手可得、按需計算

我們將數據虛擬化定義為三層。第一層是連接層，最主要的作用是為各種各樣的異構存儲介質，不同的物理層定義一個統一的訪問接入模型層，將異構數據的訪問標準化。第二層是真正做數據處理加工的地方，叫合并層。第三層是消費層，將加工后的數據提供給消費端使用，接下來會借助案例詳細展開各層的作用。

二、數據虛擬化在數據集成場景落地實踐

前文中介紹了 Data Fabric 以及數據虛擬化的概念。接下來通過一個真實案例，來介紹如何將數據虛擬化技術應用到實際場景中。

1. 在某券商應用案例

這是一個券商的案例。在用我們的方案之前，他們是沒有數倉的，報表是通過寫 Java 程序去實現的。客戶經過調研發現所有的同行都在使用 Hadoop 這一套大數據體系，去構建一套完整的數據倉庫，但對他們來講這種方案投入成本太多，而且方案也太重了，因此他們急需更加輕量化的數據解決方案。

這個券商客戶那邊有很多業務庫，并且這些業務庫沉淀了很多年，有些放在 MySQL 里面，有些放在 Oracle 里面，也有些在 SQL Server，甚至還有一些網上爬下來的數據。他們希望通過這些數據匯集在一起來實現企業的信息化大屏，包括資產管理、數據管理月報、數據分析等等，為管理層及各個業務部門清晰地展示企業關鍵業務經營情況。

我們提供的解決方案是，首先這些數據源通過虛擬化邏輯層連接，這一層映射成最原始的 PDS(Physical Dataset)，只邏輯定義，不做物理數據的遷移。基于這層邏輯映射的 PDS 之上，再去定義各層，與數倉的分層架構類似，只不過這里的 DWD、DWS、ADS 都是虛擬化的 VDS（Virtual Dataset）。消費端的報告、報表直連到虛擬化引擎，像訪問傳統數據庫里面的普通物理表一樣使用任一層里面的 VDS 數據。

其中有兩個比較關鍵的策略。

第一個策略是客戶希望能保留數倉的功能。首先，保留數倉數據的歷史性，所以我們為他們構建的第一個策略就是在 DWD 明細這一層，統一按照天去保留歷史快照，與傳統數倉一樣，只不過是基于虛擬化技術去做，引擎會在這一層統一構建物理作業。

第二個策略是 DWD 之上的這一層，按需去做物理作業的構建。

有了這兩個策略之后，通過我們的策略引擎去生成真正的作業。當用戶查詢視圖或虛擬表時，虛擬化引擎會根據用戶的查詢 SQL 路由到真正的物理數據上去做查詢（底層會基于不同物理作業產生的數據做關聯和合并）。

2. 在某券商應用效果

通過上述方案，發現沒有采用傳統的數據體系，也能把常見、典型的用戶場景實現出來。客戶連到邏輯數據平臺里面的庫有一百多個，PDS 層虛擬映射的表有兩萬多張。但實際上完成所有關注的看板、報表，真正用到的表還不到 1%。所以有大量的表對這些經營報表是沒有用處的。實際的物理作業也不多，不超過 100 個，支撐其一百多個核心指標。

如果采用傳統數倉的方案，因為其數據散落在各個業務庫，如果把兩萬多張表都同步過來，而且是在數倉里面去寫 ODS 的話，那么成本和代價是完全不一樣的。而我們的方案在以下三個方面帶來了顯著的提升：

• 首先，整個交付效率相對于以前的 Java 開發提升了至少十倍。即使與傳統數倉方案對比，也是有明顯優勢的。
• 第二，整個研發鏈路的管理工作量減少了 30%。因為在我們的方案中傳統 ETL 中的 E 和 L 層都虛擬化掉了。
• 第三，減少了計算存儲的成本。因為兩萬多張表里面，用到的物理作業很少。所以整體的成本相對于傳統方案來講，是有巨大節省的。

3. 數據虛擬化應用架構

上圖中展示了兩種典型的數據虛擬化應用架構，適用于不同的場景。

前面的券商案例中，用的是典型的單層虛擬化架構，通過一個虛擬化層，把公司所有源的數據連接在一起。

多層虛擬化架構，更多用于集團性公司，或者分地域的公司。因為各種各樣的原因（比如權限、安全、合規、數據歸屬和管理權等等），如果企業不希望這些數據從各個地域或者分公司物理拷貝出來，如果上層還要使用這些數據，那么多層虛擬化非常適合去解決這類問題。

三、數據虛擬化同傳統方案的差異

1. 數據虛擬化讓 ETL 專注于 T(Transform)

接下來看一下虛擬化方案與傳統方案的差別。

數據虛擬化并不是突然冒出來的一個概念，而是經歷了一系列的發展過程。早期的數據倉庫，是 ETL 的模式，隨著各種非結構化數據的出現，慢慢演變成了數據湖的解決方案。數據湖中最大的變化是把 transform 這個階段放到了最終使用數據的時候去執行，也就是變成了 ELT。但是不管是數據倉庫還是數據湖，都是集中化的物理數據存儲方案。而邏輯數倉是基于虛擬化技術的數據解決方案。在邏輯數倉里面，更強調讓用戶只聚焦在 transform，而不需要關注 E 和 L。

通過上圖中的對比，可以看到邏輯數倉與傳統數倉的差別。首先邏輯數倉完全縮減掉了數據抽取過程，它只是一個邏輯映射，相當于把所有庫連的元數據爬進來，數據就可用了。第二個差異是在消費端，在邏輯數倉中不需要把數據導到 OLAP 引擎里去，直接就能給 BI、報表或其它工具用。E 和 L 這兩層去掉之后，用戶可以將重心放在中間 transform 這一層，專注于處理數據、加工數據。

真正做到這個技術可用，有兩個關鍵點。第一個是自動化生成 ETL 作業。其實讓用戶聚焦在 transform 里面，通過虛擬化的技術去實現他的需求，不代表沒有 ETL 作業，ETL 還是在的，只不過這個過程自動化了。第二個是因為用戶不會感知到物理作業，所以當有作業產生物理數據時，這些查詢的改寫、構建，都由虛擬化引擎完成了，對用戶是透明的。

2. 數據虛擬化=Presto？

大家可能會有兩個疑問，一是這個虛擬化方案與傳統的 Presto 方案有什么差別，二是這里的 ETL job，是不是類似于物化視圖，接下來解答一下這兩個問題。

首先絕大部分用 Presto 的場景都是放在ETL的最末端，當然這跟 Presto 的架構也有關系。因為 Presto 就是一個 MPP 引擎，它本身是面向 OLAP 查詢的，只不過支持跨源查詢的能力。如果想延伸到數據倉庫這一層的話，就意味著需要支持大規模數據穩定且低成本的構建能力，而這是 Presto 這類純 OLAP 引擎架構所支持不了的，因為 OLAP 引擎的設計就是追求最大化的利用所有計算和內存資源將每個查詢的性能拉到極致。所以數據虛擬化不等于 Presto，因為它可以解決一部分類似于虛擬化的問題，但是解決不了傳統數倉的困境。Aloudata 的數據虛擬化是可以解決全場景的。最關鍵的部分在于 RP 技術的突破。

RP 與物化視圖的差別在哪里呢？舉個簡單的例子，傳統的物化視圖，是為了加速一些大的 SQL 而誕生的，其實更多的是一種加速緩存，也就意味著數據丟掉了是沒關系的。但是在 RP 這一層，因為 RP 是對標 ETL 研發的作業，如果作業有問題，或者是數據有問題，查詢不會繞過它。所以 RP 的定位與物化視圖有著很大的不同，也正因為此，兩者在技術設計方案上也存在很大的差別。

首先，RP 會支持多層的構建和調度，與真實的物理上生成的 ETL 作業沒有差別，也會有強弱依賴，也會有分區對齊，也會有跨周期依賴等等。只不過這些是自動生成的，而不是人工去配置的。同時，RP 也支持大規模數據量構建，也支持自動推導是全量構建、增量構建，還是分區構建。

另外，在物化視圖中，數據一旦構建出錯就失效了，數據就丟了。但在 RP 里面是不會的，因為數據有多個版本，這是很重要的一個能力。

RP 同物化視圖一樣也會基于算子實現 SPJG 的查詢改寫能力，但同時它也極大增強了物化改寫能力。在傳統物化改寫中，對于 SQL 的復雜性是有一定限制的。例如：在 VDS 多層嵌套的場景，多層視圖展開后會生成一個極其龐大的算子樹，傳統物化改寫算法在這類規模的算子樹上改寫，性能和準確性都存在極大的限制。

最后，RP 技術根據用戶的查詢歷史以及資產的關系構建了智能加速方案。并且能夠自動回收。在數據倉庫里面，作業越來越多，很多沒有用的作業無人負責下線，必然要去人肉治理，以降低計算、存儲成本。在虛擬化之后，因為消費端對作業是否在用是有感知的，所以能做到自動回收。這也是相對于傳統數據治理一個很重要的差別。

3. 傳統數倉VS邏輯數倉

邏輯數倉與傳統數倉的區別可以總結為以下幾個維度：

• 成本方面，邏輯數倉的實施成本更低，因為只需要部署一套虛擬化引擎，所以也比較輕巧。同時，存算成本也比較低，因為是按需計算的，數據隨時可用。另外，自動數據治理，可以將重復資源自動合并、復用，并基于一定策略自動回收。
• 安全合規方面，數據邏輯集中，可以更好地控制其訪問策略、安全策略等。
• 效率方面，因為它省略掉了很多過程，所以整個研發效率更高，而且門檻也會比較低。
• 整體技術方案簡單，一套方案就可以很好地滿足主流數據報表和分析場景。

既然邏輯數倉有這么多優點，那么有了邏輯數倉，傳統數倉就不再需要了嗎？顯然不是。因為傳統數倉經過多年的發展，有其自己的理論、技術體系、人才的沉淀。傳統數倉最大的問題是無法適應非穩定的、臨時性的或者創新性的需求，這些業務需求有個共同的訴求就是取數、用數的敏捷化，這是傳統數倉架構天然無法具備的。所以邏輯數倉更像是傳統數倉的補充，通過傳統數倉加上邏輯數倉，可以滿足更多的場景。

四、總結

在本次分享中講到了很多概念，包括 Data Fabric、數據虛擬化、邏輯數倉以及 RP。下圖中展示了它們之間的關系。

首先 Data Fabric 是一個理念，數據虛擬化是 Data Fabric 理念下數據網格化能力的具體實現。有了數據虛擬化技術，我們去構建了一個虛擬化的數據倉庫，叫做邏輯數倉。而真正的突破，是因為有了 RP 這樣的技術，才讓數據虛擬化能夠真正去落地，從而實現邏輯數倉的能力。

本文的兩個主要觀點為：

• 因為數據虛擬化的技術，讓數據集成不等于數據同步。這與傳統的解決方案有很大的差別。因為不等于數據同步，反而讓數據可以隨時可用。
• 邏輯數倉讓數據的使用更經濟、便捷、高效。

以上就是本次分享的內容，謝謝大家。

五、問答環節

Q1：怎么保證在查詢時不影響業務庫的穩定或業務系統的正常使用。

A1：這是被問到最多的一個問題。回顧文中的案例，其實在 DWD 這一層做了一個物理作業的映射，因此對于所有 DWD 上的這些查詢，是不會打到業務庫內存的。有些訪問如果是直接查詢，比如說繞過了這一層，直接查詢 PDS 這一層，查詢引擎有做一部分的限流控制。根據不同的業務庫的容量，我們可以針對數據源做一些容量的限流。

Q2：RP 本身是什么？能否解釋一下？

A2：RP 全稱是關系投影。以前是 ETL 自己去寫物理作業，寫 SQL，最后把數據插到一張物理表中。現在我們把這個過程簡化成了 ETL 同學去寫真正生成數據的邏輯，不用管這個邏輯是不是插到一張物理表中。當定義了很多視圖之后，我們發現比如說它這兩個視圖合在一起去生成一個物理作業更高效的情況下，就會把它的代碼合在一起去生成真正的物理作業。所以 RP 與視圖之間的差別就是用戶定義了視圖之后，RP 其實是視圖底層物理作業的一個映射。

Q3：采集的數據時效性如何？

A3：采集的實時性取決于不同的場景。有些場景是有實時采集需求的，而有些場景虛擬化之后，數據的時效性能夠得到提升。當然這種時效性的提升取決于幾個方面的能力。第一個方面是，如果查詢下推能力足夠強，用戶原始的 SQL，原始的那個庫，能支撐這樣的查詢的話，可能很多地方就不會去采集過來，而是盡量在源端庫進行計算，這是一個方案。另外一個是，有些采集，如果源端庫不允許訪問，或者性能很差的情況下，可以在 PDS 層建 RP，也可以在 DWD 層建 RP。進入這個 RP 之后，跑的作業就分兩層，一層是定時去跑，或者說依據調度系統的調度周期去跑，比如說可以調度到小時級，這是一類。另外一類是如果在 PDS 層建，這種加速作業的采集是可以更實時化的。比如通過定義 bin log 的方式生成 RP。RP 就是一個訂閱 bin log 的實時采集作業了。

Q4：Data Fabric 的核心是建立一套映射關系嗎？

A4：首先，Data Fabric 的基礎是虛擬化。但是 Fabric 不僅僅是這一個概念，其實它上面還有很多，比如主動元數據，是很關鍵的一個點。虛擬化數據的來源是因為有主動元數據的能力，才讓用戶無感知，不用去操心怎樣用他所有的庫。更多的概念，可以參考我們的白皮書。