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

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

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

在上述背景下，三個(gè)問題會(huì)越來越突出：

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

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

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

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

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

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

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

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

算子級(jí)血緣相對(duì)于列血緣或者表血緣來說，具有如下特點(diǎn)：

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

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

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

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

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

基于算子級(jí)血緣，我們?cè)趦蓚€(gè)地方進(jìn)行了實(shí)踐，一個(gè)是指標(biāo)鏈路的盤點(diǎn)和治理，另一個(gè)是主動(dòng)模型治理。首先來介紹一下指標(biāo)鏈路盤點(diǎn)上的實(shí)踐。

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

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

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

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

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

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

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

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

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

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

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

三、基于算子級(jí)血緣的主動(dòng)模型治理探索

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

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

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

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

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

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

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

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

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

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

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

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