一、Data Fabric 介紹
首先，讓我們來看一下 Data Fabric 的定義。
Data Fabric 是一種新興的數據管理設計理念，起源于美國。根據 Gartner 的定義，Data Fabric 可以實現跨異構數據源的增強、數據集成和共享。這意味著以前在構建數據倉庫時需要進行大量的ETL工作，將不同業務關系數據庫中的數據加載到數據倉庫中，并通過各種鏈路進行數據同步。然后，在數據倉庫中進行分層加工，最終生成各種指標，供用戶進行分析和生成報表。
Data Fabric 的理念與傳統的數據倉庫有所不同。在某些情況下，分析師可能并不需要將整個數據完全搬移到自己的工作環境中，而只需要進行簡單的數據探查。因此，Data Fabric 的概念就應運而生。簡單來說，Data Fabric 就是一種對企業內部數據進行輕量級探查的編織概念。
基于Data Fabric 的理念，我們可以進行更加靈活和高效的數據分析。自2019年起，Gartner 已經連續三年將 Data Fabric 技術列入十大數據分析技術趨勢之一。這表明 Data Fabric 技術正在逐漸成為數據管理和分析領域的重要趨勢。在2022年，Gartner 將 Data Fabric 技術列為數據管理和分析領域的排名第一的技術趨勢，它的出現為企業提供了更加靈活和高效的數據管理和分析解決方案，因此備受關注和追捧。
Data Fabric 的價值主要體現在降低成本和提高效率方面。它可以幫助用戶減少在數據開發、分析和管理過程中的工作量，避免頻繁的數據遷移和復制。那么，Data Fabric 實際上解決了什么問題呢？最主要的問題是打破數據孤島。通過將數據接入到統一的平臺中，企業可以獲得對整個企業內所有數據的高級視圖，了解企業內部的數據在哪里、做什么用途。此外，用戶還可以進行簡單的數據探查，而無需將數據全部遷移到數據倉庫或數據湖中。這樣一來，Data Fabric 為企業提供了更加綜合和靈活的數據管理和探索方式，從而提高了數據分析的效率和準確性。
現在硅谷流行一個概念——Lakehouse 數據湖。數據湖和 Data Fabric 的理念密切相關。數據湖強調存儲的易用性，與傳統的數據倉庫不同，它對數據的存儲和拉取要求不那么嚴格，數據的結構和格式也不需要遵循傳統的范式結構化數據的要求。這與數據倉庫的要求有所不同，數據倉庫要求數據必須遵循嚴格的范式結構，并需要進行各種加工處理。因此，數據湖和Data Fabric的理念是密不可分的。
目前，硅谷的一些頭部互聯網公司都推出了基于 Data Fabric 概念的產品。例如微軟在今年五月份推出了 Microsoft Fabric 和 OneLake 兩款產品，它們共同組成了整個數據平臺。IBM 也在5月9日發布了基于 Data Fabric 理念的產品 Watsonx.data lakehouse，與其另一款產品 Cloud Pak for Data 相互關聯，構建了一個從底層到開發應用的全數據加工平臺。微軟的 Fabric 理念是"All your data, all your teams, all in one place"，意味著所有數據都可以在一個平臺上進行查看，但并不一定要將所有數據都搬到一個地方。
二、FastData 實時智能湖倉平臺介紹
滴普科技基于 Data Fabric 理念打造了一款產品，名為FastData。該產品定位為一站式的實時智能數據湖平臺，主要包含三個層次。
首先是我們的 DLink 引擎，解決了在各種云基礎設施上的存儲和計算問題。它有效地組織和存儲數據，并提供了針對不同工作負載的計算能力。在這一層之上，有開發套件和分析套件。開發套件類似于數據開發中的工具箱，提供了調度、編輯器和工作流編排等功能。而分析套件主要解決指標管理問題，更加面向業務，幫助管理各種非 SQL 方式的指標。
湖倉部分是數據倉庫架構中的一個重要組成部分，主要解決數據存儲和計算的問題。在數據倉庫中，數據通常以表格形式存儲，湖倉管理需要考慮如何存儲和管理不同格式的數據表格，以及如何提供加速和管理源數據。在存算分離的情況下，湖倉管理需要提供高效的數據訪問和查詢功能，以便用戶能夠快速獲取所需的數據。
基于 Data Fabric 架構，數據可以分布在不同的位置和系統中，因此湖倉管理需要持有各種數據的源數據，以便能夠更好地管理和查看數據。這樣可以提供更高階的 view 視圖，使用戶能夠更好地了解數據的整體情況。
湖倉管理還提供了一些計算能力和開發套件，用于建模、數據質量、數據治理、調度和數據集成等方面。例如，用戶可以使用開發套件來建立模型、評估數據質量、制定數據治理策略、調度數據處理任務以及實現數據集成。這些工具可以幫助用戶更好地管理和利用數據資源。
最高層的分析層主要解決如何建立各種指標，并通過自己的模型語言來管理這些指標，從而形成企業的數據資產。用戶可以使用分析層來定義和計算各種指標，例如銷售額、用戶增長率、市場份額等。這些指標可以幫助企業更好地了解自己的業務狀況，并制定相應的決策和戰略。
現代數據棧（MDS）是一個全流程架構的概念，它是可組裝的而不是整體式的。每個客戶在使用平臺時，并不需要使用所有的套件，因此 MDS 采用了可插拔的插件形式，根據客戶的需求進行組裝，實現了一種非大而全的平臺。這種可組裝的方式可以降低企業的成本，并簡化平臺架構。
MDS 的整個平臺架構從數據源的數據拉取開始，包括實時和離線的數據采集和集成部分，然后將數據集成到數據湖和數據倉庫中，形成湖倉一體的架構。這個架構實現了數據的整合和統一管理，使得企業能夠更好地利用數據資源。
總的來說，MDS 是一個靈活可組裝的數據架構，通過插件形式提供所需的功能，覆蓋從數據源到數據湖和數據倉庫的整個數據流程，幫助企業降低成本并簡化平臺架構。
在存儲底座中使用 DLink 套件時，數據開始進行開發，并在開發界面中進行相應的開發工作。在數據開發過程中，數據治理是一個重要的環節，確保數據質量的高標準。然后，數據進入到數據的分析與應用層，這是分析套件所要解決的問題。分析套件提供了一系列工具和功能，幫助用戶進行數據分析和應用開發。
最底層是控制臺，這是另一款產品，其主要解決的問題是對基礎設施的計算資源和存儲資源進行管理。它還提供了監控和告警功能，以及對數據源的統一管理。這個產品被稱為 DCE（Data Control Engine），它的主要目標是管理和優化基礎設施資源，確保系統的高效運行。
產品的核心優勢可以簡單概括為四個方面。首先是低成本，因為它可以完全分離地部署在各種公共云的對象存儲上，同時也支持私有云的部署，比如在 IDC 里面可以對接傳統的 HDFS 等。其次是易用性，它提供了敏捷的數據開發能力，包括低代碼指示和低代碼開發等工具。第三是可組裝性，即根據需求選擇自己的鏈路，這是基于現代數據棧（MDS）的思想，可以根據客戶需求進行定制化部署。最后是簡單擴展性，它是從 Hadoop 生態的大數據平臺向互聯網一體的新一代大數據平臺演進，同時也支持國產化新創，為用戶提供更多的選擇。
概括而言，FastData 具有低成本、易用性、可組裝和易擴展等核心優勢，可以幫助企業更好地管理和利用數據資源，提高數據分析和應用的效率。
FastData 分析套件主要用來處理指標，它采用了統一 ML（Model Language）模型語言來定義、管理和加工指標。一旦指標加工好了，我們就可以將其存儲在各種不同的存儲介質中，包括開源存儲和我們自己的湖倉引擎等。這個分析套件主要關注指標層的存儲和管理，而不關心指標具體存儲在哪里。
為了更好地服務于客戶，我們還提供了各種各樣的服務，包括對接各種 BI 工具、提供數據企業產品 API link 等?？蛻艨梢酝ㄟ^這些服務來查詢指標數據，進行各種數據分析和應用。此外，我們還提供了 AI link 服務，客戶可以通過數據科學和 Jupyter 等工具來訪問指標數據，實現數據應用的開發和部署。
FastData 分析套件統一的指標管理和加工方案，以及豐富的服務和工具，可以幫助客戶更好地利用和應用數據資源，提高數據分析和應用的效率。
分析套件的功能架構主要包括指標語言的建設和指標加速兩個方面。首先，指標語言的建設是指如何定義和管理功能指標。用戶可以使用統一 ML 模型語言來定義復雜的指標邏輯，包括指標的計算、聚合和過濾等操作。這樣可以幫助用戶更好地理解和描述業務需求。
其次，指標加速是非常重要的一點。由于用戶建立的指標邏輯可能非常復雜，我們需要在用戶查詢時能夠快速地找到指標數據。為了實現指標的快速查詢，我們采用了一系列優化技術，包括數據索引、緩存和并行計算等。通過這些加速技術，可以大大提高指標查詢的效率，使用戶能夠快速獲取所需的數據。
分析套件的價值在于提供了無門檻的數據洞察能力，即使不懂 SQL 的人也能夠建立指標。用戶只需要進行簡單的配置，比如配置一些原子指標和修飾詞，然后指定一些加工公式，就能夠計算出所需的指標。通過儀表盤等工具，用戶可以洞察到隱藏在數據背后的業務見解。
另外，統一指標服務是通過模型語言提供各種對外的 API，如 JDBC 和 SDK 等。這樣可以方便用戶通過外部工具訪問和查詢指標數據。此外，CubeLess 是用于構建數據立方體的一種技術。它通過底層的預計算能力和緩存技術，事先計算好指標并加速查詢。同時，分析套件還可以輕松對接各種流行的BI工具，提供加速查詢的能力。
下面重點介紹開發治理套件。開發治理套件是一個相對傳統的數據開發和管理工具，按照常規的數據鏈路進行數據開發。首先，進行數據標準化和建立模型，然后進行數據開發，其中涉及到數據的血緣關系和調度。這個過程涉及到元數據，然后發布到生產環境中進行運行。在這個過程中，還需要進行質量校驗、數據集成和數據安全（如加密和脫敏）等處理，最終對外提供服務。整個流程比較標準化。
最底層的存和算引擎是湖倉引擎，主要解決高效存儲和計算的問題。在存儲方面，我們采用了表格式，主要使用了 Apache 的 Iceberg，并進行了大量的二次開發。在計算方面，我們為不同的工作負載提供了三種內置的算力引擎。對于離線工作負載，提供了 Spark；對于實時工作負載，提供了Flink；而對于機器查詢和分析工作負載，則提供了內置的 Trino 組件。這樣，能夠滿足不同場景下的高效存儲和計算需求。
湖倉引擎的價值主要在于：
首先，能夠提供多工作負載，并能夠以云化方式提供數據服務，也就是它的工作負載。不同的工作負載有不同的內置組件來支撐。
另外，它的架構是存算分離的，它的存儲底座可以對接各種對象存儲，可以提供 PB 乃至 EB 級的海量數據存儲。
分布式數據湖架構，企業可以建立多個數據湖，包括總公司和各個分公司的數據湖。然而，如何實現不同數據湖之間的有效數據共享是一個需要解決的問題。
邏輯入湖與物理入湖是數據管理和分析領域的兩種不同方法。物理入湖是將傳統的數據完全搬遷到數據湖中，并在數據湖上構建數據倉庫或進行數據分析。在物理入湖的過程中，通常會采用批流一體的方式，將離線和實時數據處理合并為一條數據流，以提高數據處理效率。此外，還需要對整個數據集成過程進行管理，包括處理數據結構變更的問題，以確保數據湖中的數據與源數據保持同步。
邏輯入湖是一種基于 Fabric 架構的實踐方法。它的主要技術要求是統一元數據，包括已經入湖的數據和未入湖的數據。邏輯入湖并不涉及將數據搬遷到數據湖中，而是通過管理元數據的方式，將元數據撈取過來并進行管理。數據仍然保留在原始位置。在數據倉庫層進行數據加工和分析時，可以直接使用SQL進行操作，無需關心數據的具體存儲位置。
分布式數據湖是一個多湖的概念，它可以解決大型企業中總公司和分公司之間數據交換的問題。以中國移動為例，總公司和各個省分公司都有自己的數據倉庫和數據湖。為了實現數據交換，可以采用分布式多湖聯邦查詢的能力來解決。具體做法是，分公司可以將自己的數據湖注冊到總公司，并提供一個注冊賬號來管理權限。這個注冊賬號可以控制總公司對分公司數據的訪問權限，可以隨時擴大或縮小權限，甚至收回權限。這樣就實現了有限制的數據分享，不需要將所有權限開放給總公司。例如，可以只開放讀權限而不開放寫權限。分布式數據湖的架構主要解決這種情況下的數據交換問題。
分布式數據湖中的核心理念是 Fabric，它能夠實現統一的數據視圖，而這是通過統一的元數據服務來實現的。這個元數據服務不僅可以管理數據湖內的數據，還可以管理企業內其他各種數據存儲的元數據。此外，權限管控也非常重要，因為如果源數據管理沒有權限控制，數據的安全性就無法得到保障。
在 FastData 團隊中負責構建近實時的數倉，是我們的一個重要工作。我們采用了 Apache 的 Iceberg 來做底層的表格式存儲。從數據源到 ODS 層，我們使用 Flink CDC 技術將數據源拉進來，之后從 ODS 層到下面的 DWD 層或 DWS 層，需要讓數據快速地流動起來。為了實現這個目標，我們需要Iceberg這一層支持 CDC 技術，也就是說通過使用Flink這種流式讀取 Iceberg 的 Connector，可以快速地感知上游 Iceberg 表的數據變化和schema變化，并將這些變化及時地同步給下一層。這樣，數據和 DML 就可以不需要人工操作便自動地流動起來。除了 Append 數據之外，還有 delete 數據和 update 數據，這些數據都需要通過整個鏈路不停地往下游流動，以便產生的指標能夠跟著業務數據的變化而變化。我們已經做到了這一點，但是 Iceberg 的 changlog 產生是依賴于上游表的 commit 操作。commit 的頻率越高，時效性越好，但是會產生更多的雜亂無章的文件，對后臺的自動化運維提出了較高的要求。commit 的時間越長，拉的時間越長，對文件是更好，但是時效性就差了一些。因此，我們需要根據業務的實際時效要求做出合理的配置。
自動化表運維方面，因為數據湖與傳統的 Hive 表格有所不同，數據湖支持行級別和列級別的更新，因此會產生各種各樣的刪除文件和小文件。同時，數據湖也支持實時寫入，這會導致更多的小文件和刪除文件。如果不及時整理這些文件，直接查詢的效果將非常差。為了解決這個問題，我們使用了異步合并和讀時合并 MOR 等技術來提高性能。在后臺，我們必須確保這些工作得到良好的處理。
在 FastData 內部，我們致力于讓用戶完全無需關心這些工作。就像使用傳統的 Hive 表格一樣，用戶只需要專注于他們的數據業務，寫入和讀取數據即可。后續的維護工作由系統自動完成，用戶無需進行操作。
物化視圖是一種常見的空間換時間的策略，通常在 MPP 中也會使用，例如 StarRocks 也使用了這種策略。物化視圖的一個特點是對于那些查詢相對固定的query，查詢加速的效果比較好，因為它的命中率較高。
在 Fastdata 內部，我們基于 Trino 實現了物化視圖。然而，社區版的物化視圖基本上無法使用。首先，它的刷新需要手動刷新數據，全量刷新是不可行的。例如，如果我的基表有上億條數據，如果我做了一個聚合查詢生成一個物化視圖，如果要全量刷新，代價太大了。因此，我們在這個基礎上做了一些優化工作。例如，我們現在可以自動刷新，第二刷新可以做增量刷新。增量刷新意味著，當基表發生任何變更時，例如添加了一行或刪除了某一行數據，這種變更很快就能體現在物化視圖中。在后臺，我們通過使用 Iceberg 的CDC 技術來實現實時監控基表的變化。一旦感知到變化，就會觸發增量計算。我們使用Flink 來進行增量計算，然后將結果同步到物化視圖中。
三、FastData 實時智能湖倉平臺實踐案例
FastData 已經在多個行業中積累了一些客戶案例。尤其在能源和商品流通領域，特別是新零售方面，得到了廣泛應用，并取得了一定的成果。
在能源領域，我們的平臺主要解決兩個核心問題。首先，利用 Hadoop 技術來處理各個油田的數據。由于油田分布廣泛，每個油田都有自己的數據管理系統，因此我們的平臺能夠將這些數據整合起來，并提供更快速的數據采集速度，從T+1天級別提升到分鐘級別。
其次，我們通過建立分布式數據湖（Lakehouse）來解決數據管理的問題。以前，各個油田的數據是相互獨立的，沒有統一的管理方式。現在我們的平臺允許各個油田建立自己的數據湖，并將數據注冊到總部。這樣，總部就可以隨時進行數據分析，了解各個油田當天的生產經營情況。同時，數據仍然保留在各個油田的本地存儲中，實現了數據的集中管理和分散存儲，解決了這兩個核心痛點問題。
FastData 平臺不僅提供結構化數據倉庫和數據湖倉庫的能力，還能處理半結構化和非結構化數據。對于零售客戶來說，這是一個重要的功能。在過去的 Hadoop 時代，處理結構化和非結構化數據通常需要使用完全獨立的技術棧和平臺。但通過 FastData 平臺，可以實現半結構化數據和非結構化數據的統一存儲和管理，解決了企業內部存在的各種非結構化數據的問題。這樣，客戶可以在一個統一的平臺上處理和管理不同類型的數據，提高數據處理的效率和一致性。
這個案例是一家新能源汽車企業的數字化轉型。他們主要面臨以下問題：營銷不精準、被動式服務、缺乏用戶價值的運營，以及數據管理混亂，難以發現數據背后的價值。
我們的產品在這個案例中的重點是分析套件，通過它來幫助企業構建數據資產并發現業務價值。FastData 分析套件能夠幫助企業進行數據分析，提升營銷精準度，改善服務質量，并發現潛在的業務價值。通過這個案例，我們能夠看到企業在數字化轉型中取得了顯著的進展。
四、FastData 實時智能湖倉平臺未來規劃
FastData 平臺的未來規劃包括以下幾個方向：
首先，我們將繼續致力于構建高性能、低成本、易使用的大數據平臺。
其次，我們將提升數據湖內部的數據服務性能。目前我們的數據服務在高并發情況下仍有待提高。
第三，我們計劃統一 Gateway 服務，以提供一致的用戶體驗。不同的工作負載和引擎可能有不同的使用方式，我們希望能夠統一這些工作方式，使用戶能夠像使用 MySQL 一樣方便地使用我們的平臺。
第四，我們計劃支持更多的云環境。目前我們已經適配了一些主流的云平臺，但對于一些較冷門的云平臺，仍需要增加適配能力。
最后，我們將通過大模型技術來解決數據資產變現的問題。傳統的數據處理鏈路需要人工參與，從數據集成、開發、指標加工到決策，都需要人工操作。通過大模型技術，我們希望能夠降低重復勞動，并實現自然語言翻譯和直接生成 SQL 等功能，以提升效率。
