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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

二、基于算子級血緣的指標鏈路治理實踐

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

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

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

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

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

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

其次，對字段口徑進行跨層溯源，自動梳理指標體系。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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