在數字化轉型的大潮中，企業面臨的數據環境日益復雜多變。滴普科技的 FastData DCT 產品應運而生，專注于高效的數據集成和管理，以應對多樣化的數據挑戰。這款產品結合了流批一體和湖倉一體架構，提供了從數據集成、分析到價值實現的全鏈路服務，極大地提升了數據處理的時效性和靈活性。FastData DCT 憑借在異構數據源實時融合和數據倉庫遷移方面的強大優勢，有效提高了數據利用率和管理效率，減少了數據浪費。本次分享將深入探討 FastData DCT 的架構演進和實際應用案例，展現其在推動各行業數字化轉型升級中的重要作用。

一、產品概述

1、Data Fabric 數據架構

自 2019 年起，高德納連續4年將數據編織(數據結構)列為年度數據和分析技術領域的十大趨勢之一。高德納認為“數據結構是數據管理的未來”。

數據架構是一種數據架構思想，包含 DataOps 數據工程，其中通過 AI、知識圖譜等智能技術，實現主動元數據治理。

2、DCT 簡介

DCT (Data Collection Transform，簡稱DCT)支持關系型數據庫、NoSQL、數據倉庫(OLAP)、數據湖(lceberg、Hudi)等數據源，可用于公有云之間、公有云與私有云之間的數據入湖入倉的結構遷移，存量數據同步和實時數據捕獲同步。為企業實現數據流通，提供簡單、安全和穩健的數據傳輸保障。

DCT 專注于數據的入湖入倉、出湖出倉場景，同時支持包括 PSC、Flink、Spark 在內的多引擎資源調度配置，支持批流一體以及故障轉移等復雜的數據傳輸機制。在復雜的網絡環境和業務背景下，DCT 提供了穩固的數據同步解決方案。

目前，DCT 已經發展到第四代。其第一代主要關注于參數配置；第二代引入了可視化界面，以簡化任務配置過程；第三代實現了對讀取與寫入功能的組件化；而最新一代則新增了流批一體的任務類型，以進一步優化數據處理效率和彈性。

3、產品定位：PB 級數據量下高效、穩定的數據傳輸高速公路

在大數據領域，特別是在 PB 級別的海量數據處理中，核心任務是確保數據傳輸的高效率和穩定性。DCT 的產品定位就是在PB級數據量下高效、穩定的數據傳輸高速公路。從源端到目標端，DCT 構建了一條能夠靈活適應不同數據源的可組合數據鏈路。在這一過程中，涉及 13 種主流的數據源類型，包括關系型數據庫、大規模并行處理系統（MPP）及數據湖和數據倉庫等。

系統的核心技術能力集中在任務配置、組件管理以及運維維護等關鍵環節。這些能力共同支持了離線數據采集、實時數據采集以及批處理與流處理一體化等多樣化的數據任務類型，確保了數據處理流程的靈活性和系統響應的及時性，滿足了復雜數據操作的需求。

4、產品價值

產品價值主要體現在三大方面：

• 異構數據源的實時融合
  專注于實現不同數據源如 Oracle、MySQL、Kafka 和 Iceberg 等的實時數據融合。包括支持數據的增量捕獲和異構數據的語義映射，以便實現數據的即時入湖。
• 整庫入湖入倉，出湖出倉
  支持 MySQL、Oracle 等數據源入湖入倉，出湖出倉。快速構建湖倉內數據，打通數據孤島，實現數據的統一管理和高效利用，為數據開發工程師和數據分析人員可以快速建立數據模型、構建應用提供數據來源。
• 降本增效
  降本：多種架構簡化場景，簡化軟件架構設計，降低異構數據融合成本。通過拖拉拽實現同步鏈路的創建，低代碼，降低學習和維護成本。
  增效：無代碼任務構建，提升數據集成敏捷性。支持組件自定義，提升客戶業務創新效率。分布式引擎、組件級高可用保障，實時鏈路穩定高容錯。

5、產品優勢

• 高性能多源異構數據采集
  支持從關系型數據庫、NoSQL、OLAP、數據湖等多樣的數據源進行結構化遷移、離線同步以及實時同步。
• 批流一體化數據采集
  采用統一的開發范式，同時實施大數據的流式和批量計算，確保數據處理的一致性，并簡化了批流采集任務的配置流程。
• 高可靠性與時效性
  通過變更數據捕獲（CDC）機制，實現日志級別的數據監聽，確保數據的時效性。同時，支持斷點續傳和故障轉移，保障數據傳輸的高可靠性。
• 組件化插拔式管理
  提供了組件插拔式管理，用戶可以自定義組件進行擴展，并支持拖拉拽的任務配置方式，降低了代碼編寫的需求，使系統易于學習和維護。
• 低成本高效率運行
  系統設計為單進程任務，最低僅需 1G 內存即可運行，降低了成本。同時，支持并行度設置，有效提高了數據傳輸效率。
• 云原生架構設計
  系統采用云原生架構，無需調整現有架構，具有強大的兼容性。基于日志的設計對源業務無侵入，保障原有業務庫的穩定運行。

二、功能介紹

1、產品功能架構圖

在產品功能架構的設計上，專注于數據湖和數據倉的高效數據處理流程，包括數據的導入與導出操作。Delink、EMR、MRS 等平臺能夠得到良好的支持，系統對于數據湖或湖倉一體化平臺有很好的兼容性。

• 基礎服務層面
  提供了數據源管理、資源組件管理等核心功能。
• 數據傳輸層面
  數據傳輸過程中，任務類型被細分為離線、實時和流批一體三種模式。數據采集模式涵蓋一對一、多對一和一對多三種類型。組件配置方面，將其劃分為讀取組件、轉換組件和寫入組件，數據映射時提供字段批量處理、整庫處理和大批量處理等映射規則。數據安全管理方面，實施了嚴格的分類分級、加解密措施，并對任務管理進行了優化，包括前置檢測、導入導出、斷點續傳和 DDL 變更等功能。
• 監控告警層面
  系統支持故障轉移，如通過檢查頻率來實現超時任務的故障遷移。任務執行過程中，監控大屏能夠實時顯示任務狀態、數據同步量和資源消耗情況。為確保數據質量，系統支持與源端進行數據質量校驗，并結合告警規則對超時任務和狀態進行監控。此外，系統支持多種消息提醒方式，如短信、釘釘電話、Webhook 等，從而快速為下游應用提供必要的數據支撐。

2、產品核心功能

• 資源管理
  支持界面配置多種計算、調度、存儲資源類型。
• 數據源管理
  支持界面配置多種類型數據源，測試連通性。
• 組件管理
  將 ETL 能力抽象為“組件”，支持界面管理讀取、轉換、寫入組件。
• 任務配置
  支持按項目空間 & 目錄進行任務管理。
  離線數據采集：支持根據源表生成目標表建表 SQL 等，快速創建目標表，支持按時間周期自動調度全量/增量數據采集。
  實時數據采集：支持通過訂閱數據源 Binlog 等方式，無侵入實現實時增量數據采集。
  批流一體數據入湖：支持通過一個任務實現批流一體數據入 lceberg 等數據湖。
• 運維監控
  實例日志：支持根據日志層級，分類查看日志信息，快速定位問題。
  監控告警：支持釘釘、郵箱、短信、電話等多種告警方式。
  數據質量：支持界面查看抽取總數、寫入總數、運行時長等指標進行數據質量管理。

3、多引擎調度

• DCT On Local
  這種調度方法基于我們自主研發的 PSC 調度引擎，利用本地資源進行資源調度，其資源消耗極低。
• DCT On Yarn
  這種調度方法通過隊列機制實現資源隔離，保證了調度的效率和安全性。
• Spark On Yarn
  這種調度方法采用 Spark 引擎。在這種情況下，任務實際上運行在 Yarn 集群中，確保了高效和穩定的運行環境。
• Delink
  這種調度方式是基于我們自研的實時湖倉 Delink。這種方式的任務運行在 Yarn 或 K8S 中，通常適用于批流一體的數據湖場景。高效的特征配置能力，可以應對大量的特征需求。

4、擴展性-自定義組件

DCT 統一了數據格式標準和組件開發規范，支持根據需求進行自定義組件開發，導入到管理界面后即可使用。

5、構建任務-組件化配置、零代碼開發

任務構建的過程也非常簡便，采用了模塊化的配置方法。用戶只需通過直觀的拖拽操作，將讀取組件、轉換組件和寫入組件按需串聯起來，即可完成任務配置。這種設計大大簡化了任務構建流程，提高了操作的便捷性和效率。

6、離線同步(全量&增量)

全量同步：指源表中所有數據都傳輸。

增量同步：全量同步過程中或同步完成之后，源庫產生的增量數據，支持通過自定義 SQL 引用變量獲取。

7、實時同步

采用基于日志的增量數據秒級獲取技術（CDC），為數據倉庫、大數據平臺提供實時、準確的數據變化，從而使得客戶可以根據最新的數據進行運營管理與決策制定。

• MySQL，通過 Binlog 方式獲取準確的數據，支持 5.x 及以上多版本，支持只讀庫權限的同步；支持斷點續傳。
• PostgreSQL，支持邏輯流復制，通過 wal2json 解析日志獲取準確的數據；支持斷點續傳。
• Oracle，支持 LogMiner 讀取數據庫日志獲取準確的數據；支持斷點續傳。

8、批流一體

使用同一套開發范式來實現大數據的流計算和批計算，進而保證處理過程與結果的一致性。降低批流采集任務配置復雜度，一次配置，程序自動進行批和流的數據采集，便于任務管理；批流自動切換，可降低資源消耗。

9、豐富的監控運維

系統提供了全面的監控功能，包括對每個實例的輸入和輸出數據量進行實時監控。這不僅限于單個實例，還涵蓋了平臺級和項目級的任務。監控內容包括數據同步趨勢、資源消耗等關鍵指標，所有這些監控數據都通過一個可視化界面展現。這種可視化監控系統使監控過程更加直觀和全面，支持實例級的輸入、輸出條數記錄，平臺級和項目級任務狀態監控、數據同步趨勢監控以及資源消耗監控。

通過這種直觀的方式呈現監控數據，監控人員能夠更清晰地理解和分析監控場景，及時發現和響應任何異常情況，從而保證系統的高效和穩定運行。

10、智能調度

新一代分布式任務調度平臺，提供定時、任務編排、分布式跑批等功能，具有高可靠、海量任務、秒級調度及可運維等能力。

• 工作流調度方面，平臺支持可視化工作流進行任務編排，以及支持 Cron 表達式和 API。
• 資源調度方面，平臺能夠監控和分配 CPU、內存和 IO 資源，同時設置任務的優先級，以智能方式分配任務資源。
• 分布式跑批方面，主要應用于離線場景，通過數據分片和將任務分配到不同的工作節點運行，以提高數據任務傳輸的效率。
• 任務監控方面，包括監控任務狀態、執行結果，并支持任務的重跑設置。通過這些功能，平臺確保了任務的高效、穩定執行，同時提升了數據處理的效率和可靠性。

11、斷點續傳

基于 WAL 架構，通過定期保存 CKP 的設計，即使出現斷網情況，當網絡恢復，也可基于斷網的定期保存檢查點實現斷點續傳，保證數據傳輸的穩定性。

當出現故障，數據傳輸中斷，可基于 CKP 快速恢復傳輸任務的數據，高效解決數據質量問題。當然這有一個前提就是需要數據源支持斷點續傳機制。

三、技術架構演進

1、DCT 1.0 技術架構

DCT 1.0 的核心功能包括：

• 支持離線和實時數據同步；
• 讀寫組件插件化；
• 命令行的方式，單進程運行；
• 支持 MySQL、 Oracle、 SQLServer、Kafka、Hive 等數據源。

2、DCT 2.0 技術架構

DCT 2.0 架構在 1.0 的基礎之上，進行了如下提升：

• 任務創建和配置支持界面化操作，以拖拉拽的方式進行任務開發；
• 支持數據源管理、讀寫組件和轉換組件的上傳與下載；
• 支持多任務并行運行。

3、DCT 3.0 技術架構

DCT 3.0 架構介紹

• Manger 管理端
  控制創建任務以及啟動停止；
  可實時監控 MasterNode 是否在線。
• MasterNode 主節點
  負責 WorkNode 注冊上線，監控，狀態維護；對提交的任務進行節點分配，任務下發，狀態監控。
• WorkNode 工作節點
  負責 MasterNode 上報所在服務器節點的資源相關信息，接收來自 MasterNode 下發的任務；
  負責 PSC 啟動，監控上報，結束、異常處理等整個完整生命周期。
• PSC 可編程調度容器
  執行數據同步任務的最小管理單元，包含讀取、轉換、寫入組件，共同組成一個同步任務；
  由 WorkNode 負責管理整個任務的生命周期。
• DCT 3.0 架構先進性
  支持分布式部署，Manager 節點和 WorkNode 節點實現了無狀態化，能夠獨立的橫向擴展，支持高可用和彈性擴縮容；
  實時查看 CPU、內存、I/O 等資源使用情況；
  設定任務優先級，智能分配資源；
  優化 PSC，使得能快速地支持自定義組件擴展。

4、DCT 4.0 技術架構

DCT 4.0 架構更進一步：

• 優化掉了調度單點瓶頸的 MasterNode 節點，降低系統復雜度，提升了系統的可靠性；
• 自主研發基于 Manager 結合 PSC 作為資源調度引擎，實現任務分片調度；
• WorkNode 節點與 PSC 任務支持故障轉移，使得系統具有更優的穩定性；
• DCT 支持多種資源調度模式，能和大數據集群共享調度資源，降低硬件成本。
  DCT-on-Local 模式：Local 模式支持以工作節點作為任務運行的資源，不需要依賴外部資源；
  DCT-on-Yarn 模式：支持在 Yarn 集群運行；
  DCT-on-Spark 模式：使用 Spark 引擎，以 Yarn 作為資源調度運行任務；
  DCT-on-DLink 模式：使用 DLink 湖倉引擎，以 Yarn 或 K8S 作為資源調度運行任務。

四、應用場景

接下來將通過整庫入湖場景，來介紹 DCT 的應用。

將業務庫 MySQL 中的數據入湖，快速構建湖倉一體。僅需簡單的四步，即可完成從基礎配置到實例運維的全流程閉環。

1、配置數據源

• 配置數據源
  這一步驟相對簡單，主要通過直觀的拖拽操作來完成。用戶需要填寫相關的數據源連接信息，如數據庫地址、端口、用戶名和密碼等。
• 連接驗證和預檢測
  配置完數據源后，下一步是驗證連接信息。包括檢查提供的連接信息是否正確，以及驗證相應的權限。系統會進行一系列預檢測，確保數據源連接的有效性和安全性。

2、配置資源

• 選擇 DLink 資源作為采集的資源調度引擎。
• 湖內 Catalog 信息獲取，作為目標端。
• 運維文件上傳（CDC jar 上傳）。

3、新建入湖任務

• 選擇讀取組件，MySQL 作為采集源端，寫入組件 Iceberg_DLink 作為目標端。
• 配置任務基礎信息，例如：Flink 重啟策略配置、Checkpoint、并行度、日志存儲等。
• 分別配置批資源、流資源，實例運行自動切換。
• 可根據源表結構，自動生成目標表結構，支持預覽、編輯、批量創建。
• 前置檢測通過后，啟動任務。

4、實例運維

• 支持查看實例狀態、同步數量、異常記錄等。
• 通過查看實例配置，二次檢驗是否符合同步配置。

五、成功案例

1、某能源企業：集成滴普實時湖倉，油田數據服務時效性大幅提升

• 客戶背景
  某能源公司是以油氣業務、工程技術服務、石油工程建設、石油裝備制造等為主營業務的綜合性國際能源公司，是中國主要的油氣生產商和供應商之一。勘探開發平臺是國內油氣行業首個智能云平臺，其依托數據湖和 PaaS 技術實現勘探開發生產管理、協同研究、經營管理及決策的一體化運營，支撐勘探開發業務的數字化、自動化、可視化、智能化轉型發展。
• 客戶需求——由離線數倉升級為新一代實時湖倉
  提升油田勘探開發數據的服務時效性，原有數據需要 T+1 才能從數據源端到達數據服務端。
  全量油田數據入湖，油田邊緣計算設備的時序數據需要實時上傳入湖，原有離線數倉不支持數據快速去重能力，導致時序入湖性能達不到要求。
• 滴普服務
  統一數據集成工具：滴普 DCT 提供統一的多源異構數據庫實時同步+離線同步工具，支持結構化數據、半結構化數據實時匯聚。
  實時湖倉架構升級：滴普 DLink 實時湖倉引擎集成到勘探開發云平臺，提供數據實時計算、聯邦查詢等高級特性。
• 解決方案
  數據源分類：項目涵蓋了 11 大類油田數據源，這些數據源多樣化，涉及油氣行業的多個關鍵領域。
  數據同步和調度：所有這些數據源通過 DCT 進行統一調度和集成。DCT 在這里起到了核心的數據同步和集成工具的作用，確保了不同數據源之間的有效對接。
  數據同步至開發云平臺：通過 DCT 工具，數據被同步到一個專門的開發云平臺。這個平臺作為數據處理和分析的核心，支持大規模數據集的處理和分析。
  數據量和應用場景：這個項目處理了大約 5PB 的數據量，這一規模體現了其處理大數據的強大能力。最終，這些數據用于支持 8 大油氣數據應用場景，提供實時的數據服務。

（1）勘探開發云平臺：勘探開發云平臺新架構

• 數據集成：從各種業務系統中提取數據，通過 DCT 實現數據的統一集成。
• 數據入湖：采用批流一體的方式，具體是通過 Flink CDC 機制將數據同步到 Kafka 集群，然后再利用 Flink 將數據實時寫入數據湖。同時，也支持使用聯邦查詢技術進行批處理數據的入湖。
• 實時計算與離線分析：數據入湖后，在數據湖內部進行實時計算及離線分析，實現數據的深度處理。
• 數據同步與調度：處理完成的數據通過調度策略，使用 Trinor 進行離線同步到 ClickHouse（CK）。
• 數據服務 API：最終，通過 API 將同步到 ClickHouse 的數據提供給下游應用，供進一步的業務應用和數據分析使用。

（2）成果：異構多模數據通過統一數據采集架構入湖，優化運維成本

新架構相較于原架構，實現了數據同步流程的簡化和統一，并通過實時數據湖的引入，提升了數據處理的實時性和全面性，為更快速、更有效的數據分析提供了支持。

• 原架構特點：在原有的數據架構中，實時數據同步和離線數據同步是分開的，使用不同的工具鏈進行處理。
• 新架構優化：新架構通過 DCT 實現了數據采集的統一，將實時和離線數據同步集成在同一條數據鏈路中，優化了入湖過程。
• 數據湖轉變：在原架構中，數據湖主要面向離線數據存儲，而新架構升級為實時數據湖，提供了更高的時效性和全鏈路數據處理的能力。
• 時效性提升：新架構顯著提高了數據處理的時效性，使得實時數據分析成為可能，同時還支持在實時數據湖中進行全鏈路的數據處理。

（3）成果：數據入湖、湖倉內模型處理速度大幅提升，時效升級為 T+0

• 原架構處理方式：原架構依賴于離線跑批處理數據，并將數據同步到數據集市（data mart）層，同樣采用離線跑批的方法。
• 新架構的優化：新架構采用了流批一體的處理鏈路，從數據入湖到最終寫入數據集市，整個應用層都采用了流處理和批處理的結合方式。
• 時效性提升：新架構將數據處理的時效性從原來的 T+1（次日處理）提升到了 T+0（實時處理），顯著提高了數據處理的即時性。
• 資源消耗優化：新架構能夠在資源消耗上實現顯著節省，提高了整體的數據處理效率。
• 性能提升：在數據同步性能上，從原來的每秒同步 1100 條數據提升到實時入湖監測到的每秒 25000 條數據，性能提高了超過 20 倍。

2、某零售企業：構建圍繞“貨”“店”數據智能運營體系

• 技術應用：該零售企業采用了 FastData 平臺，輔以數據集成工具，以優化其貨店數據智能運營體系。
• 成本下降：通過這些技術的應用，企業的硬件成本降低了 25%。
• 數據量和性能提升：在數據鏈方面，企業管理著大約 2.5 到 3PB 的數據規模，每天數據新增量約為 500GB。數據查詢性能提高了 30%。
• 架構升級：企業的數據處理架構從原來的批處理架構升級到了實時處理架構，時效性也隨之提升到了 T+0 級別，即數據可以實時處理和分析。

（1）某零售企業：基于 FastData 湖倉一體架構優化成本，性能和效率

• 數據源集成：我們將內部及外部的多樣化數據源通過 DCT 進行集成，整合到 FastData 平臺。
• 數據處理與分析：在數據集成之后，在 FastData 的基礎設施上進行了必要的數據處理和分析。
• 指標與模型：處理和分析的過程中涉及到指標標簽的構建和應用模型分析。
• 業務閉環形成：通過這些步驟，實現了針對特定業務場景的閉環，從而支撐了數據驅動的決策過程。

（2）某零售企業：數據中臺聯合共創，全面提升業務效率

• 問題
  客戶擁有多個業務系統，并使用多種數據庫類型；底層需接入多個組件實現數據離線、實時同步，技術復雜度高，穩定性差，采購多套商業軟件，費用高，資源消耗大。
• 價值
  統一數據入湖工具可以降低數據集成過程的復雜度，減少維護成本，資源使用大幅減少。該工具采用集群架構，高可用，支持故障轉移，能進一步提升容錯性和可靠性。同時數據入湖速度、湖倉內模型處理速度大幅提升，數據服務時效從 T+1 升級為 T+0。
• 運行情況：
  DCT 任務 2000+，并發任務 500+，平日數據量約為 1億+；峰值 3 萬條/秒；
  DCT 生產環境運行 2 年，運行穩定，無數據丟失；
  DCT 扛住 618、雙 11、雙 12 的壓力（數據量為平日 3-5 倍）， 無崩潰，無數據丟失，數據延遲 <2 秒；
  DCT 實時同步速率約 80MB/s，日最高承受數據量達 20TB。

六、Q&A

Q1：DCT 數據集成是如何保證數據一致性的？

A1：實時任務同步的一致性保證：對于實時數據同步任務，我們采用了 checkpoint 機制。這一機制能夠在任務因異常中斷時創建保存點，以便在網絡或系統恢復后，能夠從上一個已知的良好狀態重新開始數據同步。這樣做的好處是，即使在出現故障的情況下，也能確保數據不會丟失，并且可以根據業務時間或數據偏移量進行精確地重置和消費。此外，如果目標端存在主鍵，我們還可以利用數據的冪等性質來避免重復，確保數據的一致性。

離線任務同步的一致性保證：在離線數據同步方面，特別是在處理大數據量場景下，我們同樣實施了故障轉移策略，并記錄了數據的偏移量。當任務發生異常時，可以從記錄的偏移量處開始重新同步。這種機制保證了即使在離線狀態下，數據同步也能夠在故障后繼續進行，而不會造成數據的不一致。

綜上，無論是實時同步還是離線同步，DCT 都通過先進的機制確保了數據的一致性和完整性，以支持企業的數據集成和分析需求。

Q2：DCT-on-Yarn 跟 DCT-on-Spark 有什么區別？他們的應用場景是什么？

A2：DCT-on-Yarn 是一種基于 Yarn 進行資源調度的數據集成工具。它能夠高效地利用企業現有的 Yarn 集群資源，避免了在工作節點上部署額外的機器資源。這種方式適合于企業已經擁有大數據集群，并希望在現有集群中實現批處理和流處理相結合，或是實現數據湖與數據倉庫一體化的任務調度。簡而言之，DCT-on-Yarn 可以直接借用企業現有的資源來執行數據集成任務。

相比之下，DCT-on-Spark 專注于數據湖的入湖場景，特別是在使用企業自有的湖倉引擎時。DCT-on-Spark 采用了 SeaTunnel 引擎，旨在提升從源端到實時湖倉引擎 Dlink 的數據處理效率。雖然 Spark 引擎也運行在 Yarn 集群中，與 DCT-on-Yarn 在技術基礎上有所相似，但 DCT-on-Spark 通過特定的數據處理引擎優化了入湖過程的性能。

總結來說，DCT-on-Yarn 更適合那些希望在現有大數據集群內優化資源利用的企業，而 DCT-on-Spark 則更適用于需要高效數據入湖處理的場景。兩者雖然在技術實現上有所交叉，但都旨在提高企業數據處理的效率和效能。

Q3：數據大量入倉入湖后能用到業務端的數據占比有多少？另外怎么解決數據浪費的問題？

A3：業務應用占比：這個問題高度依賴于業務需求。一種常見的方法是自上而下的數據入湖，即先將企業內所有系統的數據庫數據統一入湖，然后進行數據建模和治理。但這種方法可能導致一部分數據并不符合實際業務需求。因此，更推薦的做法是結合企業具體業務進行自下而上的數據分析，明確哪些數據需要入湖并加以加工，最終形成有用的主題域。這樣做可以更好地對接業務需求，提升數據在業務端的應用率。

解決數據浪費問題：數據浪費主要集中在存儲空間占用和計算資源上。對于存儲來說，我們可以采用冷熱數據分離的策略：對冷數據進行壓縮和歸檔，以減少存儲空間占用；而熱數據則重點保存和加速處理，以便快速分析。在計算引擎方面，采用存算分離的架構既能提升性能，又能保證在不同場景下選擇最合適的引擎，避免不必要的資源堆積和浪費。通過這種方式，可以靈活地調整或下架不再使用的計算引擎，進一步優化資源利用。