一、主動數(shù)據(jù)治理，數(shù)據(jù)治理新范式

1、新治理范式探索的背景

大多數(shù)管理過數(shù)倉的同學(xué)應(yīng)該都有一個普遍共識是數(shù)據(jù)倉庫建設(shè)時間越長，管理復(fù)雜度會越大。一是引入的數(shù)據(jù)技術(shù)越來越多，管理的集群會越來越多；二是參與數(shù)據(jù)生產(chǎn)和使用的角色和人員會越來越多；三是業(yè)務(wù)需要引入的數(shù)據(jù)會越來越多。最后會形成一個特別復(fù)雜的數(shù)據(jù)依賴網(wǎng)絡(luò)，而數(shù)據(jù)管理的目標(biāo)是要不斷滿足業(yè)務(wù)的效率、性能、質(zhì)量、成本、安全等方面不斷增長的需求。

在上述背景下，三個問題會越來越突出：

• 第一個問題是看不清。數(shù)據(jù)依賴網(wǎng)絡(luò)越來越復(fù)雜，我們想要去理解某一個數(shù)據(jù)字段口徑會越來越費時費力，一旦出現(xiàn)數(shù)據(jù)異常問題，想要去追溯到它的根因需要一層一層往上去找，一層一層去找人詢問，排查過程非常困難。另外，做模型變更的時候往往會出現(xiàn)一個問題，就是表血緣擴(kuò)散非常快，拉出兩三層之后數(shù)據(jù)完全沒法看，變更影響評估噪音非常多。
• 第二個問題是管不住。業(yè)務(wù)需求太急，應(yīng)用層無序建設(shè)膨脹嚴(yán)重，中間層空心化，導(dǎo)致很多質(zhì)量問題，成本問題，以及各種安全合規(guī)問題。
• 第三個問題是治理難。問題模型、重復(fù)數(shù)據(jù)等盤點困難，由于數(shù)據(jù)消費場景錯綜復(fù)雜，下游遷移工作量巨大，上下游協(xié)同成本高，新模型的切換難以推動。

面對上述問題，數(shù)據(jù)管理復(fù)雜度與日俱增，因此我們需要更加精細(xì)和更加智能的數(shù)據(jù)管理手段。

在2022年Gartner提出通過主動元數(shù)據(jù)管理概念，認(rèn)為數(shù)據(jù)管理的中心已經(jīng)開始從專注于數(shù)據(jù)內(nèi)容管理向元數(shù)據(jù)管理升級，主動元數(shù)據(jù)是實現(xiàn)智能數(shù)據(jù)管理最核心的基礎(chǔ)。

元數(shù)據(jù)治理相比于傳統(tǒng)的元數(shù)據(jù)管理平臺，有三大區(qū)別：

• 一是過去在管理元數(shù)據(jù)的時候，我們更多是去收集元數(shù)據(jù)，并把它呈現(xiàn)出來，主動元數(shù)據(jù)強(qiáng)調(diào)我們要對元數(shù)據(jù)做持續(xù)的分析和理解，不僅是理解庫表列schema等常規(guī)信息，更要理解這份數(shù)據(jù)背后的語義和它的加工口徑、業(yè)務(wù)主體、匯總粒度以及如何正確使用等。
• 二是主動元數(shù)據(jù)能夠更加面向行動、面向治理來解決實際的業(yè)務(wù)問題，主動元數(shù)據(jù)不再是等用戶碰到數(shù)據(jù)使用問題時去到一個數(shù)據(jù)目錄上去找它，而是給出一個設(shè)計建議或者一個可被系統(tǒng)執(zhí)行的指令。
• 三是更強(qiáng)調(diào)工具無縫集成，在數(shù)據(jù)生產(chǎn)、消費和協(xié)作的各個環(huán)節(jié)為用戶提供完整的元數(shù)據(jù)上下文以及智能建議，以實施更主動的數(shù)據(jù)管理策略。

因此，我們認(rèn)為它是實現(xiàn)智能數(shù)據(jù)管理的關(guān)鍵。

過去我們碰到過很多問題，難以用人治的方式來解決。所以，在這個背景下我們設(shè)計了BigMeta 主動數(shù)據(jù)治理平臺這一產(chǎn)品。其基于獨創(chuàng)的算子級血緣技術(shù)，將所有數(shù)據(jù)生產(chǎn)的計算邏輯能夠解析到最精細(xì)的程度，即算子粒度，通過精細(xì)的口徑刻畫，就可以有一個更加全面的理解，比如我們可以從用戶使用數(shù)據(jù)的行為去進(jìn)一步刻畫這份數(shù)據(jù)，分析它經(jīng)常被如何使用，它的重要性以及背后的業(yè)務(wù)語義是什么。可以建立數(shù)據(jù)與數(shù)據(jù)之間的關(guān)聯(lián)，不僅是血緣關(guān)聯(lián)，也可能是一個星型模型中維度表和事實表的關(guān)系。基于這樣一份精準(zhǔn)而全面的數(shù)據(jù)理解，就可以實現(xiàn)更智能的數(shù)據(jù)管理和治理。

這一能力是與我們的研發(fā)工具、數(shù)據(jù)工具以及協(xié)作工具無縫集成的，是伴隨著這些工具一起使用的。

算子級血緣相對于列血緣或者表血緣來說，具有如下特點：

（1）字段口徑一目了然：無需人工層層分析 SQL 代碼，算子級血緣能自動、精確地抽取兩個字段之間的加工口徑，讓字段口徑一目了然。

（2） 精細(xì)刻畫依賴關(guān)系：算子級血緣能精細(xì)刻畫字段與字段之間的依賴關(guān)系，不論是上游庫、表、列、schema變更還是加工口徑變更，都可將變更影響評估到行級別，從而大幅降低變更影響評估面。

（3） 端到端列級依賴可視：上至業(yè)務(wù)系統(tǒng)源端，下到BI、AI工具的每一個指標(biāo)和圖表，算子級血緣能更精細(xì)地刻畫每一條數(shù)據(jù)鏈路， 實現(xiàn)更精細(xì)的數(shù)據(jù)治理。我們目前已經(jīng)做到了99%的SQL解析準(zhǔn)確率。

我們目前已經(jīng)做到了99%的SQL解析準(zhǔn)確率，并且在特別復(fù)雜的陳年老數(shù)倉的客戶環(huán)境里面得到過驗證。我們的算子級血緣能做到實時的五分鐘內(nèi)的變更感知。很多新上線的任務(wù)，或者待上線的任務(wù)都可以實時地反映到這個血緣里面去，能夠更實時地實施數(shù)據(jù)管理策略。此外在構(gòu)建血緣的速度上能實現(xiàn)百萬級的表在一天內(nèi)完成血緣構(gòu)建。

二、基于算子級血緣的指標(biāo)鏈路治理實踐

基于算子級血緣，我們在兩個地方進(jìn)行了實踐，一個是指標(biāo)鏈路的盤點和治理，另一個是主動模型治理。首先來介紹一下指標(biāo)鏈路盤點上的實踐。

這里舉一個我們合作客戶的例子，這個客戶是一家頭部金融機(jī)構(gòu)，其數(shù)倉建設(shè)已有五年多時間。碰到的最大的問題是監(jiān)管報送數(shù)據(jù)經(jīng)常出現(xiàn)數(shù)據(jù)質(zhì)量問題。上游一旦變更，下游根本感知不到，就會導(dǎo)致監(jiān)管報送的數(shù)據(jù)口徑變化，造成數(shù)據(jù)質(zhì)量偏差，受到監(jiān)管處罰。

在這個背景下，他們希望能夠快速理清所有監(jiān)管指標(biāo)的上下游依賴，并且能夠把每一層鏈路的加工計算口徑都梳理出來，一旦上游發(fā)生變更，可以及時快速感知，以便重點保障監(jiān)管報送這條鏈路。由于數(shù)據(jù)鏈路非常復(fù)雜，并且只能做到表級血緣，很難看清楚數(shù)據(jù)的真正依賴，口徑也難以看清，只能通過人工逐層盤點，以其數(shù)據(jù)規(guī)模來看，要盤點清楚整個鏈路，可能需要30個人盤點一年才能完成，這對業(yè)務(wù)來說是不可接受的。

我們的算子級血緣，具備口徑自動抽取的能力，所以能夠幫助他們自動而且持續(xù)地完成指標(biāo)鏈路盤點。

首先我們實現(xiàn)了基于算子級血緣去對單獨列的計算口徑獨立抽取。

可以通過對用戶的ETL腳本進(jìn)行算子級解析，可以產(chǎn)出如上圖右側(cè)所示的結(jié)果。上圖左側(cè)的SQL是只跟這個列相關(guān)的SQL，是對原始SQL做了相關(guān)性裁剪之后得到的一個可真實運行的只產(chǎn)出這個列的SQL，這樣就能非常清晰地看到這個列的加工口徑。

其次，對字段口徑進(jìn)行跨層溯源，自動梳理指標(biāo)體系。

我們還經(jīng)常會碰到重復(fù)指標(biāo)或者相似指標(biāo)的問題。通過對所有字段進(jìn)行口徑溯源，再去對比字段口徑，就能夠知道數(shù)據(jù)之間的重復(fù)以及差別。

在上圖右側(cè)的例子中，有兩張表，里面有兩個字段很有可能是重復(fù)字段，一張表是走規(guī)范化建模上去，通過公共層DWS到ADM，而另外一張表可能沒那么規(guī)范，是直接從ODS和DWD抽數(shù)據(jù)做出來的。通過解析每一個字段的加工口徑，并且基于算子級血緣去做分層展開，最后一直追溯到貼源表，就會發(fā)現(xiàn)實際上兩張表的最大區(qū)別是過濾條件不一樣，一般來說這種過濾條件不一樣的情況，可以認(rèn)為這兩個指標(biāo)屬于同一個類別譜系。

我們可以通過這種方式對指標(biāo)進(jìn)行分類，分類之后再進(jìn)一步去做精細(xì)化的判定。精細(xì)判定時，要考慮更多的細(xì)節(jié)問題，比如多表之間join可能會引起數(shù)據(jù)的膨脹或者縮減，來界定那兩份指標(biāo)是不是真的精確一致。在此基礎(chǔ)上就可以把整個指標(biāo)體系快速梳理出來，這對指標(biāo)盤點的效率，是一個革命性的提升。

最后是精準(zhǔn)識別業(yè)務(wù)基線，精準(zhǔn)控制保障范圍。

在識別出來這些指標(biāo)之后要對其進(jìn)行精準(zhǔn)的保障。常規(guī)的做法是通過任務(wù)血緣去做上游追溯。在做指標(biāo)表的時候為了方便下游使用，常常會把很多指標(biāo)拼在一張表里，但一張表里面的指標(biāo)的重要等級實際上是不一樣的，它的保障等級也應(yīng)該不一樣。在這種情況下，如果把所有的任務(wù)保障全，以任務(wù)粒度去直接做上游穿透會發(fā)現(xiàn)要保障的面會非常寬，各種噪音也會特別多。有了算子級血緣管理之后，可以實現(xiàn)基于每一列去做上游穿透，能夠裁剪掉大量無關(guān)的表任務(wù)，從而做到精準(zhǔn)控制保障面。

三、基于算子級血緣的主動模型治理探索

如何實現(xiàn)更加智能的數(shù)據(jù)治理，是我們目前在做的一些實踐。在整個數(shù)據(jù)治理里面最難的事情就是模型治理。數(shù)倉建設(shè)過程中，越來越多的“壞味道”會引發(fā)數(shù)據(jù)無序膨脹、鏈路不斷加長、重復(fù)數(shù)據(jù)爆炸等問題。

比如同一個主體反復(fù)拼接維度形成套娃：一個用戶可能看到有一張表中很多數(shù)據(jù)是他需要的，但是少兩列，于是就自己拼兩列，并且裁剪掉那些他不需要的列。之后可能其他用戶又看到了這張新表，根據(jù)他的需要又繼續(xù)拼。最后發(fā)現(xiàn)這些數(shù)據(jù)其實是可以被一張表或者幾張表承載的。反復(fù)的拼接，就會導(dǎo)致數(shù)據(jù)重復(fù)和鏈路加長的問題。

另一個例子是重復(fù)計算，一份資產(chǎn)有多個相似的下游任務(wù)，我們建公共層的時候可能沒有預(yù)期到有一些相似的下游需求，可能少建了一個或幾個字段，其他同學(xué)就要基于這個字段進(jìn)行重復(fù)加工。

還有一些情況是多個團(tuán)隊各自為政，對相似的需求做了不同數(shù)據(jù)鏈路，就形成了煙囪模式。

另一個常見的問題就是不合理的下游節(jié)點依賴，用戶可能不知道數(shù)據(jù)倉庫里面有多少數(shù)據(jù)，隨便選張熟悉的表就開始依賴了，但實際上也許有更好的中間層可以被依賴，所以導(dǎo)致數(shù)據(jù)鏈路在不斷加長，帶來時效問題。

在這樣的背景下，如果想實現(xiàn)整個模型治理的自動化或者說持續(xù)性治理，最關(guān)鍵的是要讓模型治理更加主動，而不是等到問題出現(xiàn)之后再去做重構(gòu)。

我們希望實現(xiàn)的第一個目標(biāo)是主動識別鏈路中的壞味道；第二個是基于這個壞味道自動生成一些模型重構(gòu)的建議；第三個是做出來這個模型上線之后能持續(xù)保持健康，能在一些錯誤用數(shù)的場景下，給用戶更好的建議，保證用戶可以正確地使用模型。

首要問題是如何識別數(shù)據(jù)鏈路中的問題。在規(guī)模特別大的數(shù)據(jù)網(wǎng)絡(luò)中，要去逐一匹配工程浩大。所以，我們把問題分成兩個步驟。由于大多數(shù)壞味道的關(guān)鍵特征是重復(fù)，所以我們基于字段口徑以及溯源口徑，做了一個自動的判重掃描算法。核心是基于一個給定的起點或者一批給定的起點去做多層的上下游擴(kuò)散，去擴(kuò)散出一批相似表，這批相似表的核心判斷依據(jù)是字段口徑的重復(fù)度。判斷出來之后，就可以把這些相似表進(jìn)行分組，再去還原其數(shù)據(jù)血緣，進(jìn)行子圖匹配。

以一個套娃為例，一旦發(fā)現(xiàn)這批相似資產(chǎn)，還原出它的數(shù)據(jù)血緣結(jié)構(gòu)如上圖所示，那么就認(rèn)為其疑似套娃，接下來對它做進(jìn)一步的確認(rèn)和分析，去發(fā)現(xiàn)數(shù)據(jù)重構(gòu)或者數(shù)據(jù)模型治理的機(jī)會，在這個階段靠血緣就不夠了，我們需要對整個圖結(jié)構(gòu)做算子展開。在算子展開之后，我們就能夠發(fā)現(xiàn)這份數(shù)據(jù)的加工過程中先做了兩表join，然后做了過濾等步驟之后，拿到了這張表，我們發(fā)現(xiàn)這些表最后是可以被合并的。合并依據(jù)是可以基于這個算子鏈路去做一個算子變換，我們可以有一個預(yù)設(shè)，就是把所有的數(shù)據(jù)都合并到頂端這張表里面來，那意味著要把一定的算子下推下去，比如過濾條件和匯總條件。下推下去之后就會有一張c表，就是完整的所有數(shù)據(jù)。原來的下游表t2和t3表，需要補(bǔ)上過濾條件。

模型治理完后，為時效和成本帶來了哪些改變，我們可以基于算子去做代價評估,讓評估結(jié)果做為治理的依據(jù)。

要保證模型的長治久安，關(guān)鍵就是下游后續(xù)的數(shù)據(jù)使用不會出現(xiàn)重復(fù)建設(shè)，或者使用到已下線的數(shù)據(jù)，最后導(dǎo)致模型要么被空心化，要么沒有被真正用起來。我們目前正在探索的一件事情，就是把前述技術(shù)用在更實時或者更前置的階段：當(dāng)新的公共層模型建設(shè)出來之后，系統(tǒng)在下游用戶編寫SQL腳本時，能夠自動分析用戶的腳本編寫邏輯，同時把它的算子數(shù)據(jù)去做展開，與已有數(shù)據(jù)模型去做對比。一旦發(fā)現(xiàn)已有非常相似的表存在，或者是用了一些即將下線的表，那么在代碼編寫過程中就直接給出建議，并且更進(jìn)一步地，對他的代碼能夠進(jìn)行改寫。這樣能夠使得模型切換過程更加順滑，它的保鮮能力也會更強(qiáng)。

最后，進(jìn)行一下總結(jié)，我們認(rèn)為一個主動元數(shù)據(jù)治理平臺要解決三個問題，第一個問題是如何把全域元數(shù)據(jù)聚合起來，并形成相互聯(lián)通的元數(shù)據(jù)圖譜；第二個是精準(zhǔn)地理解和刻畫每份數(shù)據(jù)的計算口徑和背后的業(yè)務(wù)語義；第三個是在數(shù)據(jù)治理、管理以及模型建設(shè)過程中，能夠提供更加智能的建議。