一、背景介紹

二、產(chǎn)品功能架構(gòu)

三、數(shù)據(jù)建設(shè)的“駕駛艙” - 數(shù)據(jù)研發(fā)套件

    1. 系統(tǒng)架構(gòu)解析

    2. 數(shù)據(jù)同步技術(shù)解析

    3. 數(shù)據(jù)研發(fā)套件任務(wù)遷移方案解析

    4. 功能建設(shè)與遷移進展

四、公司數(shù)據(jù)資產(chǎn)的“底盤” - 數(shù)據(jù)架構(gòu)技術(shù)

    1. Onedata數(shù)據(jù)架構(gòu)方法論及工具體系

    2. 統(tǒng)一ODS自動化采集入倉方案解析

    3. 規(guī)范數(shù)據(jù)建模與自動化指標(biāo)研發(fā)方案解析

    4. 當(dāng)前落地進展與效果

五、數(shù)據(jù)生產(chǎn)的“剎車片” - 數(shù)據(jù)質(zhì)量技術(shù)

    1. Galaxy的數(shù)據(jù)質(zhì)量工具體系

    2. 當(dāng)前落地進展與效果

六、數(shù)據(jù)研發(fā)之路的“輔助駕駛” - 智能化數(shù)據(jù)研發(fā)

    1. Galaxy的智能化演進路線

    2. 智能SQL代碼續(xù)寫方案解析

    3. 當(dāng)前落地進展與效果

七、后續(xù)規(guī)劃

    1. 長期規(guī)劃一：智能ETL Agent

    2. 長期規(guī)劃二：Data Fabric

    3. 長期規(guī)劃三：數(shù)據(jù)邏輯化

一、背景介紹

為什么得物需要自建大數(shù)據(jù)研發(fā)與管理平臺？

得物作為一家數(shù)據(jù)驅(qū)動型互聯(lián)網(wǎng)企業(yè)，數(shù)據(jù)使用的效率、質(zhì)量、成本，極大影響了公司的商業(yè)競爭力。而數(shù)據(jù)鏈路上最關(guān)鍵的系統(tǒng)是計算存儲引擎和數(shù)據(jù)研發(fā)平臺。其中計算存儲引擎決定了數(shù)據(jù)的使用成本，數(shù)據(jù)研發(fā)平臺則決定了數(shù)據(jù)的交付效率、數(shù)據(jù)質(zhì)量以及數(shù)據(jù)架構(gòu)合理性。

得物數(shù)據(jù)生產(chǎn)鏈路

過去整套大數(shù)據(jù)基礎(chǔ)設(shè)施我們都使用云上商業(yè)化產(chǎn)品（下文簡稱“云平臺”），但在各方面已遠無法匹配上得物長期的業(yè)務(wù)發(fā)展。目前得物大數(shù)據(jù)面臨著如下挑戰(zhàn)：

圖片

因此24年技術(shù)部正式啟動大數(shù)據(jù)系統(tǒng)自建，Galaxy數(shù)據(jù)研發(fā)與管理平臺為其中一個重要項目，負(fù)責(zé)面向參與數(shù)據(jù)生產(chǎn)的用戶，提供離線和實時數(shù)據(jù)的采集同步、研發(fā)運維、加工生產(chǎn)、數(shù)據(jù)資產(chǎn)管理以及安全合規(guī)的能力，滿足業(yè)務(wù)長期發(fā)展對于數(shù)據(jù)架構(gòu)、數(shù)據(jù)質(zhì)量、數(shù)據(jù)交付效率的訴求。

二、產(chǎn)品功能架構(gòu)

下圖為整體產(chǎn)品功能架構(gòu)，其中藍色部分為當(dāng)前已落地功能，灰色部分為規(guī)劃中的功能。

Galaxy數(shù)據(jù)研發(fā)與管理平臺產(chǎn)品功能架構(gòu)

24年立項開始至今，我們主要專注在4個最核心能力的建設(shè)，分別為：數(shù)據(jù)研發(fā)套件、數(shù)據(jù)架構(gòu)技術(shù)、數(shù)據(jù)質(zhì)量技術(shù)、智能化數(shù)據(jù)研發(fā)。如果把數(shù)據(jù)研發(fā)平臺比喻成一輛汽車，那么這四部分的定位如下圖所示：

圖片

下文會對這些關(guān)鍵技術(shù)實現(xiàn)、落地進展以及Galaxy數(shù)據(jù)研發(fā)平臺的架構(gòu)演進，進行解析。

三、數(shù)據(jù)建設(shè)的“駕駛艙” - 數(shù)據(jù)研發(fā)套件

系統(tǒng)架構(gòu)解析

數(shù)據(jù)研發(fā)套件包含數(shù)據(jù)研發(fā)IDE、數(shù)據(jù)資產(chǎn)系統(tǒng)、離線任務(wù)調(diào)度系統(tǒng)三部分，在平臺中的定位類似于“汽車的駕駛艙”，為數(shù)據(jù)工程師提供豐富的工具集，控制全公司的數(shù)據(jù)流動與計算。整體系統(tǒng)架構(gòu)如下圖所示：

圖片

數(shù)據(jù)同步技術(shù)解析

數(shù)據(jù)同步也叫數(shù)據(jù)集成，它是Galaxy數(shù)據(jù)研發(fā)平臺的核心組件之一，主要用于公司各種異構(gòu)數(shù)據(jù)源與數(shù)據(jù)倉庫進行數(shù)據(jù)傳輸，打通數(shù)據(jù)孤島。它作為大數(shù)據(jù)鏈路加工的起點和終點，不僅用于數(shù)倉ODS層（Operational Data Store，保存原始數(shù)據(jù)）的入倉構(gòu)建，也負(fù)責(zé)將數(shù)倉數(shù)據(jù)回流（出倉）到消費側(cè)的各種數(shù)據(jù)源中。

離線數(shù)據(jù)同步

離線數(shù)據(jù)同步是最為主流的一種數(shù)據(jù)同步模式，以批量讀寫的形式將源表以全量或增量的形式周期性的寫入目標(biāo)表。目前Galaxy數(shù)據(jù)研發(fā)套件支持了多種類型數(shù)據(jù)源的離線同步，包括：

圖片

目前Galaxy數(shù)據(jù)研發(fā)套件的離線同步內(nèi)核基于Spark Jar進行實現(xiàn)，下圖為離線數(shù)據(jù)同步架構(gòu)：

Galaxy數(shù)據(jù)研發(fā)套件離線數(shù)據(jù)同步架構(gòu)

離線數(shù)據(jù)同步的具體實現(xiàn)執(zhí)行流程（以MySQL同步至得物自建離線存儲系統(tǒng)為例）：

MySQL離線同步至得物自建離線存儲系統(tǒng)的執(zhí)行流程

實時數(shù)據(jù)同步

離線數(shù)據(jù)同步存在著一些局限性，主要有：

• 對在線數(shù)據(jù)庫壓力大，即使是讀庫也可能影響線上部分業(yè)務(wù)的穩(wěn)定性。而如果單獨為數(shù)據(jù)入倉申請一個備庫，又會帶來較大的額外成本；
• 大表同步時間長（可達7小時）此類任務(wù)基本無法保障下游重要數(shù)據(jù)產(chǎn)出的SLA；
• 需要在短時間傳輸大量數(shù)據(jù)，對網(wǎng)絡(luò)帶寬依賴高；
• 數(shù)據(jù)時效差，最快也是T+H的延遲，無法滿足實時報表等對時效性敏感場景的需求。

因此需要實時數(shù)據(jù)同步的能力對此類場景進行補充。我們主要支持兩種實時同步方案：

1）基于業(yè)務(wù)庫binlog的的實時入倉

對比離線數(shù)據(jù)入倉，基于binlog的實時入倉可以避免對數(shù)據(jù)庫造成壓力，減少了對網(wǎng)絡(luò)帶寬的依賴，同時對于超大規(guī)模的表可以大幅縮短基線加工時長。但此方案依然需要（小時/天）將增量數(shù)據(jù)和全量數(shù)據(jù)做Merge處理和存儲，這會產(chǎn)生冗余的計算和存儲成本，且時效性也較差，因此本質(zhì)上只能為離線數(shù)倉場景服務(wù)。

圖片

2）實時鏡像同步

通過實時計算引擎Flink CDC將變更數(shù)據(jù)實時更新到存儲系統(tǒng)中，保持?jǐn)?shù)倉ODS表和來源數(shù)據(jù)庫表的增全量同步，整體架構(gòu)更加簡單，并減少ODS層的批計算和冗余存儲成本。目前規(guī)劃通過Paimon、Iceberg等開放Lakehouse能力來實現(xiàn)離線存儲系統(tǒng)的實時事務(wù)性更新。根據(jù)實際業(yè)務(wù)場景，也可以直接將數(shù)據(jù)實時寫入StarRocks等支持更新的OLAP數(shù)據(jù)庫中。

數(shù)據(jù)研發(fā)套件任務(wù)遷移方案解析

在過去得物的全部數(shù)據(jù)加工任務(wù)全部運行在云上數(shù)據(jù)平臺，因此除了對齊產(chǎn)品能力外，我們還需要將數(shù)據(jù)加工任務(wù)從云平臺“平滑”的遷移到Galaxy研發(fā)平臺。

由于調(diào)度系統(tǒng)的故障風(fēng)險極大，一旦異常很可能由于依賴錯亂導(dǎo)致數(shù)據(jù)異?；蛲Ｖ拐{(diào)度導(dǎo)致的數(shù)據(jù)產(chǎn)出延遲。因此我們將Galaxy研發(fā)套件的平臺層遷移和調(diào)度層遷移進行解耦，以便將調(diào)度系統(tǒng)的遷移節(jié)奏放緩。

首先進行風(fēng)險較低的研發(fā)平臺層遷移，讓業(yè)務(wù)可以盡快上線，便于優(yōu)化數(shù)據(jù)研發(fā)流程和數(shù)據(jù)資產(chǎn)管理能力。此階段任務(wù)的調(diào)度依然運行在云平臺。之后再進行調(diào)度層的遷移，這個階段用戶基本無感，完成后則徹底不再依賴云平臺。

圖片

因此架構(gòu)上一套研發(fā)平臺需要同時適配兩套調(diào)度系統(tǒng)（云任務(wù)調(diào)度+Galaxy自研調(diào)度系統(tǒng) ），并支持逐步往自研Galaxy調(diào)度的平滑演進。

為了讓調(diào)度遷移的過程需要如同“數(shù)據(jù)庫主備切換”一樣，盡量讓用戶無感，我們使用了影子節(jié)點的方案，以實現(xiàn)遷移流程的業(yè)務(wù)無感、可灰度、可回滾。影子節(jié)點本質(zhì)是一個Shell任務(wù)，當(dāng)調(diào)度系統(tǒng)啟動它后，它會通過Rest API檢測對方調(diào)度系統(tǒng)中實體節(jié)點的狀態(tài)，并與它保持狀態(tài)同步。通過影子節(jié)點，我們可以實現(xiàn)按照任意調(diào)度任務(wù)id進行灰度遷移，調(diào)度遷移本質(zhì)就是將云平臺的實體節(jié)點替換為影子節(jié)點。如下所示：

基于“影子節(jié)點”的雙調(diào)度互通方案

功能建設(shè)與遷移進展

1）功能對齊與優(yōu)化

目前Galaxy研發(fā)套件已完成與原云數(shù)據(jù)研發(fā)平臺的主鏈路功能對齊，具備數(shù)據(jù)研發(fā)與資產(chǎn)管理的全套流程，同時還針自建Spark引擎查詢和運維、在線數(shù)據(jù)入倉等方面進行定向優(yōu)化。提效成果：

臨時SQL查詢性能優(yōu)化

通過簡化調(diào)用鏈路+Spark Driver預(yù)啟動等查詢加速技術(shù)，平均每個Query可以比原云數(shù)據(jù)研發(fā)平臺固定節(jié)約35s+。

減少查詢等待時間：290+人日/月

在線數(shù)據(jù)入倉自動化提效

通過工單申請即可實現(xiàn)MySQL數(shù)據(jù)入倉。自動幫用戶創(chuàng)建同步數(shù)據(jù)源、增/全量ODS表、同步任務(wù)、增量Merge任務(wù)，并自動賦權(quán)以及數(shù)據(jù)初始化。根據(jù)用戶調(diào)研和埋點分析，每個數(shù)據(jù)入倉需求可提效30min+。

提效效果：20+人日/月

2）業(yè)務(wù)遷移進展

目前我們已完成數(shù)據(jù)平臺、數(shù)據(jù)挖掘、數(shù)據(jù)分析團隊的全部任務(wù)遷移（占得物全域的44%），并完成了算法團隊的POC。同時還將上述團隊的臨時取數(shù)業(yè)務(wù)遷移到了自建Spark引擎，從而實現(xiàn)云上商業(yè)版計算引擎的DEV資源縮容400+cu，總計可節(jié)省臨時取數(shù)計算成本約2萬+/月。

四、公司數(shù)據(jù)資產(chǎn)的“底盤”-數(shù)據(jù)架構(gòu)技術(shù)

目前，公司業(yè)務(wù)用數(shù)越來越敏捷和頻繁，而數(shù)據(jù)資產(chǎn)卻沒有做到“好找敢用”，大量的重復(fù)數(shù)據(jù)和數(shù)據(jù)煙囪也隨之出現(xiàn)。這不僅導(dǎo)致大量數(shù)據(jù)二義性問題，同時也使計算存儲成本難以控制。以離線數(shù)倉社區(qū)&交易的試點域為例，重復(fù)冗余表達到了54%，重復(fù)指標(biāo)達到了35%。這本質(zhì)上是缺乏數(shù)據(jù)架構(gòu)體系的建設(shè)，數(shù)據(jù)架構(gòu)是公司數(shù)據(jù)管理的“骨架”和“路線圖”，它如同“汽車的底盤”，忽視數(shù)據(jù)架構(gòu)可能導(dǎo)致數(shù)據(jù)的無序增長以及業(yè)務(wù)的決策錯誤。

Onedata數(shù)據(jù)架構(gòu)方法論及工具體系

Galaxy數(shù)據(jù)研發(fā)平臺基于“Onedata”的數(shù)據(jù)架構(gòu)方法論，建立了統(tǒng)一的數(shù)據(jù)采集和生產(chǎn)規(guī)范，使數(shù)據(jù)的新增更加合理、易用，提高數(shù)據(jù)的復(fù)用度、研發(fā)效率、交付質(zhì)量，降低使用成本。這是一種“內(nèi)啡肽”式的數(shù)據(jù)建設(shè)，前期需要花費一定時間進行數(shù)據(jù)模型的設(shè)計并遵守數(shù)據(jù)研發(fā)規(guī)范，但從業(yè)務(wù)的長遠發(fā)展來看，這是必須要走的一步。

目前我們已在數(shù)據(jù)采集入倉和數(shù)據(jù)研發(fā)兩個環(huán)節(jié)完成了數(shù)據(jù)架構(gòu)能力建設(shè)，確保數(shù)據(jù)的入口（ODS）以及數(shù)據(jù)倉庫的規(guī)范性，并再后續(xù)通過旁路數(shù)據(jù)治理的手段進行存量數(shù)據(jù)的規(guī)范化。如下圖所示：

Onedata數(shù)據(jù)架構(gòu)工具體系

融入了Onedata數(shù)據(jù)架構(gòu)技術(shù)體系（紅色部分）后的Galaxy數(shù)據(jù)研發(fā)平臺架構(gòu)如下圖所示：

圖片

融入Onedata規(guī)范數(shù)據(jù)生產(chǎn)能力（紅色部分）的Galaxy研發(fā)平臺技術(shù)架構(gòu)

下文主要對兩個關(guān)鍵模塊，統(tǒng)一ODS自動化入倉平臺、Onedata數(shù)據(jù)建模的實現(xiàn)方案進行解析。

統(tǒng)一ODS自動化采集入倉方案解析

ODS（Operational Data Store），為操作數(shù)據(jù)層，是整個數(shù)倉最基礎(chǔ)的一層，是原始數(shù)據(jù)采集入倉的第一個環(huán)節(jié)。Onedata的核心理念之一是所有的數(shù)據(jù)采集有統(tǒng)一的規(guī)范和入口。因為隨意的從在線庫進行采集同步會導(dǎo)致大量重復(fù)的數(shù)據(jù)存儲，以及過長浪費的表存儲生命周期。

由于數(shù)據(jù)的采集入倉本身沒有過度復(fù)雜的業(yè)務(wù)邏輯，因此Galaxy數(shù)據(jù)研發(fā)平臺實現(xiàn)了自動化數(shù)據(jù)采集入倉能力，提供在線數(shù)據(jù)源到數(shù)倉ODS層的標(biāo)準(zhǔn)化采集和管理能力。無需研發(fā)代碼的同時，產(chǎn)生的數(shù)據(jù)都是嚴(yán)格滿足架構(gòu)規(guī)范的。具體價值有：

• 避免重復(fù)ODS數(shù)據(jù)存儲
• 通過庫owner+數(shù)倉owner雙重審批，避免不合理的數(shù)據(jù)入倉
• 控制ODS表生命周期，避免存儲成本浪費
• 全流程自動化，提高ODS層數(shù)據(jù)研發(fā)效能

目前支持MySQL和TiDB的全量采集同步和增量采集同步。同時，開啟自動更新模式的入倉任務(wù)，還會訂閱來源MySQL表的變更消息，并自動更新同步任務(wù)。關(guān)鍵流程如下：

規(guī)范數(shù)據(jù)建模與自動化指標(biāo)研發(fā)方案解析

Onedata在數(shù)據(jù)研發(fā)環(huán)節(jié)，核心采用維度建模的理論。它構(gòu)建了公司級的一致性維度、標(biāo)準(zhǔn)化的事實表以及可靈活分析的匯總表和無二義性的指標(biāo)。并將數(shù)據(jù)進行清晰的分層，將公司內(nèi)部分散、異構(gòu)的數(shù)據(jù)整合成一套可信、可復(fù)用、可分析的數(shù)據(jù)資產(chǎn)。其主要價值有：

• 保證維度和指標(biāo)一致性：通過維度和業(yè)務(wù)過程的概念建模，確保維度表和事實表的全局唯一性；同時通過原子要素的指標(biāo)建模，確保指標(biāo)口徑的全局無二義性。
• 提升開發(fā)效率：數(shù)據(jù)工程師無需重復(fù)構(gòu)建維度表和基礎(chǔ)事實表，直接復(fù)用數(shù)倉公共層的成果；同時指標(biāo)原子要素定義完成后，指標(biāo)和匯總表的代碼全部可以系統(tǒng)自動化生成和優(yōu)化，大幅提高效率，也減少出錯的可能性。
• 增強數(shù)據(jù)可解釋性：明確的表業(yè)務(wù)描述以及字段關(guān)聯(lián)的指標(biāo)和維度，以及清晰的星型/雪花模型關(guān)系，使數(shù)據(jù)的消費側(cè)更方便的使用數(shù)據(jù)。
• 事前治理：嚴(yán)格根據(jù)架構(gòu)規(guī)范進行數(shù)據(jù)研發(fā)，禁止重復(fù)表的新增，約束數(shù)據(jù)表的生命周期、數(shù)據(jù)依賴等，避免事后運動式治理。

Onedata核心概念、建模流程以及配合工具如下圖所示：

Onedata的數(shù)據(jù)建模流程

其中最為關(guān)鍵部分為“指標(biāo)建模”。我們將指標(biāo)的口徑組成拆成了三部分組成：原子指標(biāo)、業(yè)務(wù)限定、統(tǒng)計周期，同時在其物化到表上的時候再確定統(tǒng)計粒度。通過原子要素的組合定義指標(biāo)可以確保同樣的指標(biāo)在公司全局只會有一個，以及標(biāo)識出不同的匯總表、應(yīng)用表中的指標(biāo)是否為同一個。另外當(dāng)原子口徑發(fā)生了變化，系統(tǒng)也可以根據(jù)血緣關(guān)系找到受影響的指標(biāo)和表，讓owner進行握手確認(rèn)，確?？趶阶兏恢滦?。例如下圖所示：

圖片

1個原子指標(biāo)口徑變更，影響了7個關(guān)聯(lián)指標(biāo)、2張表的同步變更

從上圖我們也可以看到，原子口徑的變更影響非常大，即使可以基于血緣進行變更握手管控，人工修改邏輯也容易改錯或遺留。因此我們實現(xiàn)了自動化指標(biāo)代碼生成的能力，基于原子口徑自動化生成指標(biāo)及其物化表的加工邏輯。

指標(biāo)代碼自動化生成方案：

將指標(biāo)按來源表分組，并將其的組成原子要素（原子指標(biāo)+業(yè)務(wù)限定+統(tǒng)計周期+統(tǒng)計粒度）進行SQL邏輯的組裝、優(yōu)化、方言翻譯，具體流程為：

圖片

數(shù)據(jù)建模與指標(biāo)SQL生成案例：

1.數(shù)據(jù)建模

圖片

圖片

2.代碼生成

圖片

圖片

圖片

3.代碼優(yōu)化 - 指標(biāo)SQL優(yōu)化規(guī)則

圖片

圖片

圖片

圖片

圖片

圖片

當(dāng)前落地進展與效果

1）統(tǒng)一自動化ODS采集入倉

目前已實現(xiàn)通過工單申請的方式一鍵完成MySQL和TiDB的數(shù)據(jù)進行增/全量自動化采集入倉能力，無需人工編寫代碼即可實現(xiàn)規(guī)范的數(shù)據(jù)入倉。產(chǎn)品效果如下：

圖片

業(yè)務(wù)成果：

• 業(yè)務(wù)域落地：目前已在得物內(nèi)部各域全面落地統(tǒng)一ODS入倉能力。2025年Q3，得物全域新增的入倉任務(wù)93.6%是通過Galaxy自動化采集入倉平臺自動化生成的；
• 表生命周期規(guī)范：25年新增ODS表生命周期定義率較24年Q4提升7.4倍，節(jié)約了大量離線存儲；
• ODS存儲增量控制：通過源頭規(guī)范數(shù)據(jù)入倉，配合數(shù)據(jù)治理團隊使數(shù)倉ODS層存儲季度增幅降低：32%->8%

2）規(guī)范建模與自動化指標(biāo)代碼生成

目前已完成數(shù)倉規(guī)劃->概念建模->明細(xì)表維度建模->指標(biāo)建模->指標(biāo)代碼自動化生成->匯總表代碼自動化生成的Onedata規(guī)范建模研發(fā)全流程，產(chǎn)品效果如下：

圖片

圖片

圖片

圖片

業(yè)務(wù)成果：

• 商家域數(shù)倉Onedata一期落地效果：完成了40+數(shù)據(jù)資產(chǎn)沉淀與規(guī)范化汰換改造，以及190+應(yīng)用指標(biāo)定義與上架，同時沉淀了100+公共派生指標(biāo)。通過數(shù)據(jù)規(guī)范化重構(gòu)、二義性問題的解決以及自動化代碼生成的能力，可實現(xiàn)商家數(shù)據(jù)需求數(shù)倉開發(fā)效率提升40+%，每迭代線上需求吞吐量提升75%->90%。
• 社區(qū)域數(shù)倉Onedata一期落地效果：完成1200+應(yīng)用指標(biāo)的定義與上架，實現(xiàn)100%無二義性。通過精品資產(chǎn)的規(guī)范建設(shè)與切換，通過復(fù)用公共層數(shù)據(jù)，實現(xiàn)5+萬/月的成本下降。由于數(shù)據(jù)二義性的解決以及資產(chǎn)規(guī)范度的提高，實現(xiàn)數(shù)倉和分析師用于口徑oncall和業(yè)務(wù)取數(shù)的人力成本減少約10+人日/月。

五、數(shù)據(jù)生產(chǎn)的“剎車片” - 數(shù)據(jù)質(zhì)量技術(shù)

得物數(shù)倉發(fā)展至今，不僅用于高管決策以及數(shù)據(jù)報表的場景，同時和得物線上業(yè)務(wù)做了非常強的耦合，各域均存在P0級資損風(fēng)險場景，例如：社區(qū)數(shù)倉的運營投放、算法數(shù)倉的新品商業(yè)化、交易數(shù)倉的費率折扣、營銷域、用戶域等等。這些數(shù)據(jù)直接應(yīng)用于線上業(yè)務(wù)，任何的數(shù)據(jù)質(zhì)量問題都可能導(dǎo)致公司、商家、用戶的利益受損，以及業(yè)務(wù)對數(shù)倉的信心丟失。

然而過往數(shù)倉的數(shù)據(jù)交付只是停留在快速提供數(shù)據(jù)以發(fā)揮業(yè)務(wù)價值這一步，業(yè)務(wù)和研發(fā)對數(shù)據(jù)質(zhì)量和穩(wěn)定性保障重視度嚴(yán)重不夠，并且沒有明確生產(chǎn)變更和數(shù)據(jù)質(zhì)量校驗的SOP，同時也沒有健全的工具體系支撐，全靠數(shù)據(jù)工程師的自我修養(yǎng)，導(dǎo)致歷史上很多核心數(shù)據(jù)加工任務(wù)沒有保障或者保障不全面，不斷引發(fā)P級故障。

Galaxy的數(shù)據(jù)質(zhì)量工具體系

數(shù)據(jù)質(zhì)量的相關(guān)工具就如同“汽車的剎車片”，可以想象沒有剎車在路上行駛是如何的危險。因此我們在Galaxy數(shù)據(jù)研發(fā)平臺建設(shè)之初就同步進行了數(shù)據(jù)質(zhì)量工具的開發(fā)。目前所建立起來的離線數(shù)倉質(zhì)量加固SOP及配合的工具如下：

離線數(shù)倉質(zhì)量加固SOP

目前重點建設(shè)的2個核心功能，分別為：數(shù)據(jù)質(zhì)量校驗規(guī)則，用于監(jiān)控生產(chǎn)數(shù)據(jù)質(zhì)量并進行及時阻斷止血，避免下游數(shù)據(jù)污染；以及數(shù)據(jù)變更管控流水線，在數(shù)據(jù)生產(chǎn)變更的環(huán)節(jié)嵌入消費場景打標(biāo)、自動化風(fēng)險掃描、code review、自動化數(shù)據(jù)測試、發(fā)布審批等功能，以全面保障數(shù)據(jù)質(zhì)量。融入了數(shù)據(jù)質(zhì)量技術(shù)體系（紅色部分）后的Galaxy數(shù)據(jù)研發(fā)平臺架構(gòu)如下圖所示：

融入數(shù)據(jù)質(zhì)量能力（紅色部分）后的Galaxy數(shù)據(jù)研發(fā)平臺架構(gòu)

當(dāng)前落地進展與效果

數(shù)據(jù)質(zhì)量校驗規(guī)則

Galaxy數(shù)據(jù)研發(fā)平臺已經(jīng)實現(xiàn)了完善的數(shù)據(jù)質(zhì)量規(guī)則校驗?zāi)芰?，用戶在Galaxy數(shù)據(jù)研發(fā)IDE上面向數(shù)據(jù)標(biāo)準(zhǔn)進行高效的質(zhì)量規(guī)則定義，系統(tǒng)會自動生成校驗SQL隨著任務(wù)的發(fā)布一起下發(fā)到調(diào)度系統(tǒng)中執(zhí)行。同時支持了強規(guī)則（主路執(zhí)行，數(shù)據(jù)異常阻斷任務(wù)執(zhí)行）和弱規(guī)則（旁路執(zhí)行，數(shù)據(jù)異常進行告警）兩種規(guī)則運行場景，應(yīng)對不同的場景訴求。產(chǎn)品效果如下所示：

圖片

場景覆蓋方面已經(jīng)實現(xiàn)了表非空校驗、表波動校驗、字段主鍵校驗、字段非空校驗、字段波動校驗、字段枚舉校驗、自定義SQL校驗等15種規(guī)則，覆蓋了離線數(shù)倉100%的校驗場景。

同時通過批量導(dǎo)入、弱轉(zhuǎn)強等提效工具幫助離線數(shù)倉團隊在25年Q3新增了1200+質(zhì)量規(guī)則，全量P0任務(wù)質(zhì)量規(guī)則覆蓋率達到96%，非P0任務(wù)86%。并結(jié)合發(fā)布管控流水線能力，實現(xiàn)了P0場景任務(wù)100%變更覆蓋表級規(guī)則，且金額等高風(fēng)險字段100%變更覆蓋字段級規(guī)則。

數(shù)據(jù)變更流水線

目前已經(jīng)完成了完整的變更管控流水線的能力，主要功能包括：消費場景打標(biāo)、靜態(tài)風(fēng)險掃描、Code Review、冒煙測試、數(shù)據(jù)探查、數(shù)據(jù)比對、發(fā)布審核。產(chǎn)品效果如下所示：

圖片

其中，場景打標(biāo)方面，離線數(shù)倉末端任務(wù)（ADS和回流）98.3%打標(biāo)了數(shù)據(jù)消費場景，對于全鏈路分析數(shù)據(jù)重要性和消費場景起到了巨大的作用；變更管控方面，靜態(tài)掃描節(jié)點已實現(xiàn)了48個風(fēng)險掃描規(guī)則，覆蓋了94%的已知風(fēng)險場景，當(dāng)前系統(tǒng)自動化風(fēng)險識別率98%（剩余為人工CR發(fā)現(xiàn)的問題），平均每雙周可事前攔截600+起風(fēng)險事件。

六、數(shù)據(jù)研發(fā)之路的“輔助駕駛”- 智能化數(shù)據(jù)研發(fā)

過去10年，通過開源大數(shù)據(jù)組件的興起，大幅度降低了企業(yè)構(gòu)建大數(shù)據(jù)Infra的難度，在一定程度上實現(xiàn)了企業(yè)間的“數(shù)據(jù)平權(quán)”。而在企業(yè)內(nèi)部，由于數(shù)據(jù)同步、ETL研發(fā)調(diào)度、資產(chǎn)管理、數(shù)據(jù)治理等復(fù)雜的技術(shù)導(dǎo)致找數(shù)和用數(shù)門檻非常高，因此大部分場景都是提需求給數(shù)倉團隊進行數(shù)據(jù)加工，那么數(shù)據(jù)團隊的交付效率就變成了公司各業(yè)務(wù)線數(shù)據(jù)化經(jīng)營決策的瓶頸。

Galaxy的智能化演進路線

我們計劃分3個階段（L1～L3）建設(shè)Galaxy數(shù)據(jù)研發(fā)平臺的智能化能力，來提升數(shù)據(jù)研發(fā)效率，降低業(yè)務(wù)自主進行數(shù)據(jù)研發(fā)的門檻，實現(xiàn)公司內(nèi)部不同部門和崗位間的“數(shù)據(jù)平權(quán)”。如下所示：

Galaxy數(shù)據(jù)研發(fā)智能化演進路徑

當(dāng)前我們處于L1的Copilot階段，通過在數(shù)據(jù)研發(fā)流程中，旁路嵌入基于專家經(jīng)驗規(guī)則和大模型的智能SQL代碼續(xù)寫、智能任務(wù)診斷、智能SQL代碼糾錯與優(yōu)化、 智能質(zhì)量規(guī)則推薦等應(yīng)用，輔助用戶進行高效數(shù)據(jù)研發(fā)。嵌入Copilot后的Galaxy研發(fā)平臺整體架構(gòu)如下，主要關(guān)注紅色部分：

數(shù)據(jù)智能化L1階段的Galaxy研發(fā)平臺技術(shù)架構(gòu)

下文主要對當(dāng)前較為成熟的功能，智能SQL代碼續(xù)寫的實現(xiàn)方案進行解析。

智能SQL代碼續(xù)寫方案解析

SQL代碼續(xù)寫的重點在于工程鏈路，大模型上我們選擇適合代碼生成的小參數(shù)模型，當(dāng)前使用了Qwen-2.5-coder，后續(xù)會進行其他模型的實驗。系統(tǒng)流程如下：

智能SQL代碼續(xù)寫系統(tǒng)流程

關(guān)鍵模塊功能描述：

圖片

當(dāng)前落地進展與效果

目前Galaxy研發(fā)平臺已經(jīng)落地了智能代碼續(xù)寫、智能任務(wù)診斷、智能SQL糾錯與優(yōu)化3個Copilot應(yīng)用，具體業(yè)務(wù)效果如下：

圖片

其中高活用戶的智能代碼續(xù)寫功能開啟率為98.5%，整體采納率趨勢和我們做的優(yōu)化動作如下：

智能SQL續(xù)寫采納率趨勢

（2025年04月25日～2025年09月09日）

七、后續(xù)規(guī)劃

后續(xù)Galaxy數(shù)據(jù)研發(fā)平臺會持續(xù)完善現(xiàn)有功能提升產(chǎn)品體驗，同時在智能ETL Agent、Data Fabric、數(shù)據(jù)邏輯化三個前沿方向進行探索，通過技術(shù)先進性為公司數(shù)據(jù)業(yè)務(wù)帶來更多的價值。

長期規(guī)劃一：智能ETL Agent

核心目標(biāo)：數(shù)據(jù)研發(fā)提效，并降低數(shù)據(jù)研發(fā)門檻

ETL Agent核心能力是需要將用戶的自然語言業(yè)務(wù)需求翻譯成數(shù)據(jù)表的SQL加工邏輯，其本質(zhì)上就是“NL2SQL”的傳統(tǒng)命題。然而，如果讓大模型直接分析用戶的問題，那么它需要嘗試從底層混亂的物理表結(jié)構(gòu)中生成目標(biāo)SQL，這會將業(yè)務(wù)語義的復(fù)雜性完全壓給大模型，導(dǎo)致同一指標(biāo)因表結(jié)構(gòu)理解偏差或字段映射錯誤而產(chǎn)生不同結(jié)果。

Galaxy的ETL Agent會采用“NL2Metric2SQL”的方案。通過大模型進行自然語言的解析，結(jié)合向量數(shù)據(jù)庫的相似度匹配實現(xiàn)NL2Metric的能力，然后基于Onedata數(shù)據(jù)模型和指標(biāo)語義層，將自然語言的用數(shù)需求準(zhǔn)確翻譯為指標(biāo)原子要素（原子口徑、業(yè)務(wù)限定、統(tǒng)計周期、統(tǒng)計維度），并自動構(gòu)建ETL加工鏈路。如下圖案例：

智能ETL Agent用戶流程案例

這也是Galaxy智能化的L2階段，這個階段將數(shù)據(jù)研發(fā)分成了專家數(shù)據(jù)研發(fā)以及智能數(shù)據(jù)研發(fā)。專家模式依然按傳統(tǒng)SQL任務(wù)進行數(shù)據(jù)研發(fā)。而智能研發(fā)則以自然語言形式的數(shù)據(jù)需求作為輸入，通過提前將Onedata數(shù)據(jù)模型存儲在RAG的向量數(shù)據(jù)庫中，然后根據(jù)數(shù)據(jù)需求內(nèi)容進行分詞，按相似度從RAG中匹配出相關(guān)的指標(biāo)要素構(gòu)建出提示詞，并請求大模型獲得正確的指標(biāo)要素。

圖片

實現(xiàn)智能ETL Agent后的智能化L2階段Galaxy研發(fā)平臺架構(gòu)（紅色部分為Agent相關(guān)模塊）

長期規(guī)劃二：Data Fabric

核心目標(biāo)：減少非必要的離線數(shù)據(jù)存儲成本

傳統(tǒng)的數(shù)據(jù)集成（數(shù)據(jù)入倉）方案是通過離線或?qū)崟r數(shù)據(jù)同步工具將公司內(nèi)部各數(shù)據(jù)源的數(shù)據(jù)全量或增量地抽取、清洗、加載到一個中心化的數(shù)據(jù)倉庫中。但這種方案在技術(shù)上存在三個問題：

• 離線存儲成本大：傳統(tǒng)的數(shù)據(jù)集成方式，離線數(shù)倉的ODS層會拷貝全部所需在線數(shù)據(jù)的副本。然而其中很大一部分的數(shù)據(jù)僅用于短期分析，或用于對RT不敏感的查詢場景，這些數(shù)據(jù)在離線數(shù)倉中物化存儲的ROI極低，造成了大量存儲成本浪費。
• 數(shù)據(jù)搬遷成本大：隨著業(yè)務(wù)的發(fā)展，公司的數(shù)據(jù)源可能分布在不同地域、不同云環(huán)境。周期性的將海量數(shù)據(jù)同步至中心化數(shù)倉，將產(chǎn)生巨大的網(wǎng)絡(luò)帶寬成本和入倉等待時間。同時入倉需要與數(shù)倉工程師進行需求溝通，也存在大量協(xié)作成本。
• 數(shù)據(jù)一致性問題：數(shù)據(jù)同步有顯著延遲，在離線同步的場景下，分析的數(shù)據(jù)會有天級延遲。

Data Fabric（數(shù)據(jù)編織）是一種全新的數(shù)據(jù)集成架構(gòu)方案，核心理念是 “不移動數(shù)據(jù)，移動計算”。 技術(shù)實現(xiàn)方案上以外表的形式來封裝源端表，通過統(tǒng)一的元數(shù)據(jù)系統(tǒng)，將源端表（外表）和離線表（內(nèi)表）統(tǒng)一管理起來，使用起來對用戶無感。在執(zhí)行計算時，通過Spark引擎的跨源聯(lián)邦查詢能力，直接從各源端數(shù)據(jù)庫（一般為備庫或抽數(shù)庫）將數(shù)據(jù)查詢回來后進行分布式計算。下圖展示了Data Fabric與傳統(tǒng)數(shù)據(jù)集成的區(qū)別：

圖片

長期規(guī)劃三：數(shù)據(jù)邏輯化

核心目標(biāo)：計算存儲成本降低，數(shù)據(jù)研發(fā)與運維提效

通過視圖或參數(shù)化視圖進行整條數(shù)據(jù)鏈路的構(gòu)建，那么整條鏈路就完全不需要任何存儲成本，計算成本也僅在視圖查詢時才發(fā)生。但這樣會導(dǎo)致一個問題，當(dāng)視圖邏輯復(fù)雜，嵌套層級多時，查詢效率非常低，且對相同視圖的查詢都需要重新計算。因此我們需要對一些關(guān)鍵的視圖進行物化，物化后的視圖，在查詢時可以直接訪問其物化表，實現(xiàn)查詢性能的大幅提升。

數(shù)據(jù)邏輯化架構(gòu)，會存在兩層，上層為由用戶定義的物理表以及虛擬視圖組成的邏輯層，對用戶感知；下層為物理表和系統(tǒng)自動生成的視圖物化表組成的物理層，對用戶不感知，具體如下圖所示：

數(shù)據(jù)邏輯化的架構(gòu)分層

數(shù)據(jù)邏輯化的關(guān)鍵技術(shù)之一為視圖物化表的命中。當(dāng)某個視圖存在物化表時，需要將對應(yīng)查詢范圍的數(shù)據(jù)直接翻譯成物化表的查詢，而不去展開視圖查詢，以提升查詢性能。技術(shù)鏈路如下圖所示：

數(shù)據(jù)邏輯化的視圖物化命中改寫鏈路

另一項關(guān)鍵技術(shù)為視圖的物化策略與回收策略。系統(tǒng)需要定期通過算法識別出在滿足產(chǎn)出時效的前提下，整體計算和存儲成本最低的物化方案。例如下方案例：

數(shù)據(jù)邏輯化的視圖物化與回收策略

目前全域優(yōu)化場景簡單且有效的算法有遺傳算法、模擬退火算法等。通過評估在一定存儲成本限制下，哪些視圖的物化組合，可以使用整體計算cost最低。

將數(shù)據(jù)虛擬化技術(shù)和ETL Agent能力結(jié)合，我們可以實現(xiàn)系統(tǒng)自托管的智能數(shù)據(jù)研發(fā)，即Galaxy智能化的L3階段。