一、數(shù)據(jù)治理簡介

首先介紹一下數(shù)據(jù)治理相關理論知識和概念，以便大家對數(shù)據(jù)治理有一定了解和認識。

1、什么是數(shù)據(jù)治理

個人理解的數(shù)據(jù)治理是整個數(shù)據(jù)相關組織架構(gòu)以及各種活動能力的集合，因此，數(shù)據(jù)治理并不是單一組織或者系統(tǒng)能夠完成的事情。數(shù)據(jù)治理和數(shù)據(jù)管理是分不開的，數(shù)據(jù)治理的職能是指導其他數(shù)據(jù)管理職能的執(zhí)行，數(shù)據(jù)治理是在高層上執(zhí)行的數(shù)據(jù)管理。

2、數(shù)據(jù)治理目的

數(shù)據(jù)治理的目的有很多，比如數(shù)據(jù)共享、提升數(shù)據(jù)資產(chǎn)價值、提升數(shù)據(jù)質(zhì)量等等，從下圖中的某機構(gòu)調(diào)查結(jié)果可以看到，提升數(shù)據(jù)質(zhì)量是數(shù)據(jù)治理的最大動機。除此之外，國家對數(shù)據(jù)相關法律規(guī)定，各個公司也有相關的規(guī)范要求，數(shù)據(jù)合規(guī)也是數(shù)據(jù)治理需要考慮的問題。

3、數(shù)據(jù)治理面臨的困難

數(shù)據(jù)治理面臨著諸多挑戰(zhàn)：比如數(shù)據(jù)多樣化缺乏統(tǒng)一標準、多種異構(gòu)類型的數(shù)據(jù)源、數(shù)據(jù)鏈路長、數(shù)據(jù)合規(guī)保障、數(shù)據(jù)價值如何評估等等。

4、數(shù)據(jù)治理方法

了解了數(shù)據(jù)治理面臨的問題后，該如何解決這些問題？我們的方法就是知治管（先知后治再管）。

先知就是要知道治理的數(shù)據(jù)對象，知道數(shù)據(jù)的形式，存儲位置等；后治是使用相關技術進行治理比如規(guī)范化、標準化等處理；再管就是盡力去提升新數(shù)據(jù)的質(zhì)量，這樣才算是真正把整個數(shù)據(jù)治理按體系做好。數(shù)據(jù)治理其實是一個閉環(huán)的體系，所以還需要將數(shù)據(jù)治理反饋到整個數(shù)據(jù)管理流程上。

5、數(shù)據(jù)治理過程

數(shù)據(jù)治理由圖示的四個步驟構(gòu)成：

一是現(xiàn)在盤點，理清楚數(shù)據(jù)現(xiàn)狀，確定歸屬和職能。

二是數(shù)倉建設，這里的數(shù)倉包含了傳統(tǒng)意義上的數(shù)倉和元數(shù)據(jù)數(shù)倉，對這些數(shù)據(jù)進行統(tǒng)一采集和保存。

三是質(zhì)量檢測，確定評估標準，輸出數(shù)據(jù)質(zhì)量報告。

四是持續(xù)改進，根據(jù)數(shù)據(jù)質(zhì)量報告推動數(shù)據(jù)持續(xù)改進，比如建立數(shù)據(jù)地圖、分析血緣關系、持續(xù)監(jiān)控數(shù)據(jù)質(zhì)量、優(yōu)化數(shù)據(jù)使用流程。將數(shù)據(jù)的產(chǎn)生和治理相結(jié)合結(jié)合，形成閉環(huán)，從而保證數(shù)據(jù)的采集和數(shù)據(jù)治理變得更好。

二、騰訊數(shù)據(jù)治理體系簡介

這部分主要介紹騰訊內(nèi)部數(shù)據(jù)治理體系的建設思路和策略。

1、組織管理體系

在騰訊內(nèi)部，我們建立了統(tǒng)一組織，規(guī)劃和協(xié)調(diào)整個公司的數(shù)據(jù)治理、數(shù)據(jù)安全工作，以 OTeam 形式規(guī)劃和實施整個相關領域的平臺建設和規(guī)范協(xié)同；建立企業(yè)級標準，規(guī)范測評體系；構(gòu)建平臺協(xié)同，建設開箱即用的一站式數(shù)據(jù)治理工具平臺；形成社區(qū)運營，通過分享或宣傳的方式，讓大家意識到數(shù)據(jù)治理以及數(shù)據(jù)質(zhì)量的重要性。

2、騰訊數(shù)據(jù)治理業(yè)務框架

騰訊這樣量級的公司，動輒幾千萬上億甚至百億級別的數(shù)據(jù)，數(shù)據(jù)的采集和存儲都是很大的問題。在上億量級的數(shù)據(jù)治理建設過程中，我們一步步實踐，踩過很多坑。通過制定數(shù)據(jù)治理標準，搭建了以資產(chǎn)創(chuàng)建、資產(chǎn)評估、資產(chǎn)運營、資產(chǎn)管控四部分構(gòu)成的數(shù)據(jù)治理平臺，構(gòu)建全域元數(shù)據(jù)服務，形成了元數(shù)據(jù)采集、存儲、數(shù)倉、數(shù)據(jù)血緣的整個數(shù)據(jù)生命周期鏈路，結(jié)合底層采用多種存儲方式，逐步建設了一個可以管理和區(qū)分優(yōu)質(zhì)資產(chǎn)與數(shù)據(jù)垃圾、相對較好的元數(shù)據(jù)管理體系平臺。

3、元數(shù)據(jù)管理

我們從如何采、怎么存、引導治出發(fā)，來思考和逐步完善元數(shù)據(jù)的管理。

4、數(shù)據(jù)資產(chǎn)管理

我們建立區(qū)分優(yōu)質(zhì)資產(chǎn)，減少垃圾數(shù)據(jù)的數(shù)據(jù)資產(chǎn)管理平臺，由四個部分組成：

首先是確定數(shù)據(jù)歸屬，如果數(shù)據(jù)歸屬都沒明確，則數(shù)據(jù)治理工作是很難展開，像騰訊這樣級別的大公司，經(jīng)過多次組織架構(gòu)的變更，數(shù)據(jù)歸屬問題尤其凸顯，比如說經(jīng)過組織調(diào)整，單個 BG 的數(shù)據(jù)拆成了多個 BG 的數(shù)據(jù)導致，數(shù)據(jù)管理問題在組織架構(gòu)變遷變得非常混亂，因此確定歸屬關系是數(shù)據(jù)治理一個非常關鍵的環(huán)節(jié)。

其次是價值分析，通過業(yè)務屬性和數(shù)據(jù)訪問這兩個維度對數(shù)據(jù)進行評估數(shù)據(jù)的價值，業(yè)務屬性也即是公司在各個領域的業(yè)務比如賬號體系等等。如數(shù)據(jù)訪問的量或者訪問頻次越高，就認為該數(shù)據(jù)重要或者具有更高的價值。

然后是數(shù)據(jù)清理，為了避免數(shù)據(jù)清理或者減少權(quán)限變更影響的范圍，需要進行影響分析判斷，同時結(jié)合自動化清理工具完成整個數(shù)據(jù)清理或是權(quán)限變更。只是做好數(shù)據(jù)清理工作是不夠，因為在實際操作數(shù)據(jù)過程中，可能會出現(xiàn)誤刪或故意刪除的情況；為了保證數(shù)據(jù)數(shù)據(jù)情況的可靠性，我們還建立一套數(shù)據(jù)可恢復的機制，從而保證出現(xiàn)上述情況時，能夠快速進行數(shù)據(jù)恢復，盡可能地降低影響范圍。

最后是生命周期，結(jié)合數(shù)據(jù)血緣和訪問頻次等學習，為用戶設置數(shù)據(jù)生命周期時，對該數(shù)據(jù)的生命周期進行智能化推薦；當然，這只是推薦的生命周期，數(shù)據(jù)最終的生命周期要結(jié)合著人工審核判斷，給定一個比較合理的周期。

5、騰訊數(shù)據(jù)治理測評體系：元數(shù)據(jù)管理成熟度

我們對元數(shù)據(jù)管理制定了測評體系，用于對公司整個數(shù)據(jù)管理和評估，可以看到圖中從下到上分為五個等級，一二級是一些初始或基本管理方法，第三級則是相對來說已經(jīng)比較成熟，但是完全不夠的，還需要將數(shù)據(jù)驅(qū)動和數(shù)據(jù)治理與數(shù)據(jù)使用形成閉環(huán)，以便做好元原數(shù)據(jù)的管理，此時已經(jīng)是第四級，是比較優(yōu)秀的程度。第五級則是比較卓越管理體系，需要具備自我完善和自我改進的功能，同時能夠在公司內(nèi)或業(yè)界有一定影響力，元數(shù)據(jù)管理真正能做到這個級別的少之又少 。

6、數(shù)據(jù)安全治理

數(shù)據(jù)安全也是數(shù)據(jù)使用過程中一個非常重要的環(huán)節(jié)，在這過程中，我們首先對數(shù)據(jù)進行了分類分級處理，為數(shù)據(jù)確定安全等級和標記，并與數(shù)據(jù)資產(chǎn)進行關聯(lián)。其次在進行數(shù)據(jù)管控，根據(jù)數(shù)據(jù)的分類分級結(jié)果，定制不同數(shù)據(jù)級別的申請流程，比如動態(tài)或靜態(tài)數(shù)據(jù)，數(shù)據(jù)加密和脫敏，在數(shù)據(jù)使用中對數(shù)據(jù)進行管控。最后是安全審計，支持一些安全審計相關功能比如數(shù)據(jù)權(quán)限訪問監(jiān)控、訪問記錄、下載日志等等，并可以輸出安全報告。

7、騰訊數(shù)據(jù)治理測評特征-安全管理能力成熟度

我們對數(shù)據(jù)安全能力管控也制定了評測體系，即安全管理能力成熟度，包含了 12 個管理域以及 86 個控制項。數(shù)據(jù)安全管理能力從低到高分成五個等級。

制定了數(shù)據(jù)安全管理能力標準后，數(shù)據(jù)治理通過 OTeam 進行統(tǒng)一組織和協(xié)調(diào)，各個部門自行申請或者參與到整個評測的工作中。

三、數(shù)據(jù)治理技術實踐

這部分是本次分享的最核心部分：騰訊內(nèi)部元數(shù)據(jù)管理、數(shù)據(jù)血緣相關技術和相關的后臺技術實現(xiàn)。

1、技術架構(gòu)

下圖是我們內(nèi)部統(tǒng)一元數(shù)據(jù)系統(tǒng)的技術架構(gòu)。對外來說，上層可以支持不同類型元數(shù)據(jù)，可以滿足各種分析引擎對元數(shù)據(jù)相關的要求，同時對接各種自定義或者標準化的數(shù)據(jù)源。這套底層統(tǒng)一的元數(shù)據(jù)服務既要滿足公司內(nèi)部的要求，同時也要滿足外部的用戶對整個數(shù)據(jù)治理的需求。目前這套元數(shù)據(jù)管理除了內(nèi)部使用外，也支持了騰訊云上的產(chǎn)品比如 WeData 等，我們統(tǒng)一元數(shù)據(jù)平臺目前對公司內(nèi)外及相關產(chǎn)品都可以提供支持。

從下往上看，整個統(tǒng)一元數(shù)據(jù)可分成兩個垂直的領域。 

左邊是數(shù)據(jù)治理體系，主要面向的是離線采集、存儲，然后做數(shù)據(jù)檢索、生命周期、數(shù)據(jù)安全、數(shù)據(jù)血緣和數(shù)據(jù)質(zhì)量的管理，這些就是數(shù)據(jù)治理提供的基礎服務。在線元數(shù)據(jù)是支持引擎?zhèn)鹊膶崟r元數(shù)據(jù)寫入，比如大數(shù)據(jù)領域最典型的 Hive、RDBMS、Strom，通過 thrift 協(xié)議，將數(shù)據(jù)實時寫入到元數(shù)據(jù)服務。離線數(shù)據(jù)治理和在線數(shù)據(jù)治理所面臨領域和技術的差異是比較大的，數(shù)據(jù)治理更關注的是大數(shù)據(jù)量基礎上，如何做好分析、檢索和工作。因此在底層存儲的選型方面結(jié)合了各種數(shù)據(jù)庫，比如 HBase、ES、圖數(shù)據(jù)庫以及關系型數(shù)據(jù)庫來支撐整個離線治理工作。在線元數(shù)據(jù)服務因為有部分事務工作，比如建庫建表，實時寫入時，需要考慮到事務、數(shù)據(jù)一致性和高可靠等因素，因此，在底層存儲時，選擇了傳統(tǒng)的關系型數(shù)據(jù)庫進行存儲。需要事務和一致性、高可靠的方式去完成。像騰訊體量的公司，數(shù)據(jù)量是非常龐大的，單純的靠單機 MySQL、PQ 是很難支持這種海量數(shù)據(jù)存儲。因此，我們在這個基礎上進行分庫分表，并利用公司內(nèi)部 TDSql 分布式數(shù)據(jù)庫存儲。

右邊在是統(tǒng)一元數(shù)據(jù)服務基礎，提供公共的平臺能力，比如認證、鑒權(quán)、任務調(diào)度、用戶租戶以及運營監(jiān)控。

2、微服務劃分

上圖是我們整個元數(shù)據(jù)治理服務后臺微服務劃分，上層是元數(shù)據(jù)產(chǎn)品、計算引擎、數(shù)據(jù)源，第二層是在第一層基礎上提供后臺能力，比如數(shù)據(jù)地圖、元數(shù)據(jù)采集、數(shù)據(jù)血緣和資產(chǎn)管理等功能，最底層就是整個支撐這套體系的技術服務。

后臺的技術服務又分成了兩層：第一層是數(shù)據(jù)層或接入層，主要由databus、center、metastores 組成，其中 hybirs 是元數(shù)據(jù)服務內(nèi)部代號。databus 的作用是統(tǒng)一消費經(jīng)過 MQ 轉(zhuǎn)發(fā)的消息并落庫，http 服務和 Thrift 服務經(jīng)過接入層服務后，通過 RPC 協(xié)議進入基礎服務層并在基礎服務層進行業(yè)務邏輯處理，最后寫入到底層存儲。

接入層分為兩層是為了底層存儲能夠提供通用的服務能力。接入層的第二層更靈活，可以支持不同產(chǎn)品和引擎，以及不同數(shù)據(jù)源對接和適配。從圖中可以看到，databus 有一條直通底層數(shù)據(jù)庫的鏈路。考慮到 databus 的職責所在,因為 databus 是對 mq 消息進行統(tǒng)一消費，考慮到數(shù)據(jù)量，databus 對寫入效率的要求非常高。http 服務和 Thrift 服務的數(shù)據(jù)量相比而言就少 很多，為了減少數(shù)據(jù)消費的延遲，我們將 databus 消費的數(shù)據(jù)直接落庫，減少 http/Thrift 服務中的 RPC 調(diào)用，縮短鏈路，進一步提升數(shù)據(jù)入效率，從而將采集的數(shù)據(jù)及時地存儲底層存儲中。

3、數(shù)據(jù)采集

首先是統(tǒng)一元數(shù)據(jù)的數(shù)據(jù)采集，數(shù)據(jù)采集可以分成兩個方向：定時采集和實時采集。

定時就是通過定時任務或調(diào)度定期連接數(shù)據(jù)源，對上游的元數(shù)據(jù)進行采集。采集的過程又分為增量采集和全量采集。因此定時采集可以分為定時增量采集和定時全量采集；定時增量就是每次只采最近一段時間的數(shù)據(jù)，通過積累采集全部歷史數(shù)據(jù)。定時全量就是每次將全部數(shù)據(jù)一次性采集完，然后落地。

在實際工作中，往往是將增量采集和全量采集結(jié)合使用。數(shù)據(jù)采集并不是最初就進行全量采集，而是待數(shù)據(jù)積累到一定量后才對元數(shù)據(jù)采集或治理工作。首次采集時，通常是使用全量采集的方式將歷史數(shù)據(jù)采集，后續(xù)的數(shù)據(jù)往往是通過定時增量的方式采集。

對于那些必須要定時增量的數(shù)據(jù)，為了減少后續(xù)鏈路的壓力，我們做了針對性的優(yōu)化：通過 redis 對定時增量做了過濾處理，比如采集周期內(nèi)，對庫信息、表信息以及分區(qū)信息計算 md5 值并存儲在 redis，然后對采集的元數(shù)據(jù)進行 md5 計算，再與 Redis 中對應的值進行比對，在源頭過濾掉沒有差異的數(shù)據(jù)，從而減少重復數(shù)據(jù)的發(fā)送。

面臨的另一個問題就是全量采集時全量刪除和全量覆蓋。在增量化處理時，數(shù)據(jù)刪除是面臨問題的：上一次是全量處理，后續(xù)則是增量處理，比如在某個周期內(nèi)，有五個庫，這一次采集，需要刪了一個庫(表),增量采集的方式是沒辦法直接找到要刪除的庫(表) ，也即是刪除些信息沒辦法透徹到下游。

針對數(shù)據(jù)刪除無法發(fā)現(xiàn)，我們對數(shù)據(jù)源所在庫和表做了緩存，在后續(xù)的數(shù)據(jù)采集時，與 redis 中緩存數(shù)據(jù)做全量對比取交集和差集，從而判斷數(shù)據(jù)的修改情況比如刪除、新增或修改，在源頭去掉重復的數(shù)據(jù)，同時有又能發(fā)現(xiàn)刪除的情況，最后把過濾處理后的數(shù)據(jù)發(fā)到消息中間件。經(jīng)過后續(xù)的消費、分發(fā)(采集的數(shù)據(jù)源是有多種多樣的，因此會有分發(fā)器來識別和和處理不同類型元數(shù)據(jù))最終分發(fā)不同的數(shù)據(jù)存儲的流程。比如血緣信息、元數(shù)據(jù) DDL 信息、審計日志信息的數(shù)據(jù)，針對不同類型信息數(shù)據(jù)有不同的處理鏈路，根據(jù)數(shù)據(jù)特點落入不同的存儲，比如血緣信息數(shù)據(jù)寫入圖數(shù)據(jù)庫，元數(shù)據(jù) DDL 信息存儲到 HBase。

數(shù)據(jù)治理產(chǎn)品前端交互是通過 ES 完成，打上寬表滿足前端交互和數(shù)據(jù)發(fā)現(xiàn)以及數(shù)據(jù)管理的需求。數(shù)據(jù)審計的日志流水，則使用內(nèi)部 hermes ，hermes 是一個類似 ES 的產(chǎn)品，但在存儲方面做了針對性優(yōu)化。

傳統(tǒng)關系數(shù)據(jù)庫都有唯一的主鍵，根據(jù)這個主鍵就可以增刪改查等處理。但是在元數(shù)據(jù)管理中，對于非采用非關系數(shù)據(jù)庫，該如何處理呢？比如上游采集好的一條元數(shù)據(jù)信息傳遞過來，我們需要對數(shù)據(jù)進行判斷，比如是否存在或者是否修改。首先是查詢，根據(jù)庫(表)名查詢是否存在，若存在則是更新操作；不存在則是新增操作。這個過程會與數(shù)據(jù)庫發(fā)生兩次交互，對整個鏈路會產(chǎn)生較大的影響 。

為了處理這個問題，我們引入了 guid 生成器（guid generator），將庫和表的信息和數(shù)據(jù)源信息輸入到 guid 生成器，生成一個統(tǒng)一編碼的 guid，作為底層存儲的唯一標識。然后用生成的 guid 對數(shù)據(jù)庫進行一個類似叫 replace into 的方式，從而實現(xiàn)通過一次跟數(shù)據(jù)庫的交互就能新增或修改操作。這樣處理對整個寫入流程是一個很大的提升。比如 hbase，直接使用 upsert，將新數(shù)據(jù)寫入數(shù)據(jù)庫，無需關心是新增還是修改。為了保證數(shù)據(jù)的最終一致性，我們將實時與周期性全量或增量的方式結(jié)合，去實現(xiàn)數(shù)據(jù)的最終一致性。在發(fā)生數(shù)據(jù)實時采集不及時或者鏈路有問題的情況下，通過全量采集的方式進行補漏處理。 

4、統(tǒng)一元數(shù)據(jù)-血緣采集分析

血緣分析對整個數(shù)據(jù)價值體驗是非常重要的，如何做血緣分析呢？首先是血緣的來源，最直接的方式就是用戶通過執(zhí)行引擎的客戶端或者直連執(zhí)行引的 server 提交的 sql。比如基于 hive 或者騰訊內(nèi)部的 thive 提交 sql 后，我們通過 hook 或者 spark 的 listener 或者 hbase 的協(xié)處理器的方式攔截到具體 query plan，query plan里面記錄了用戶提交的 sql 以及整個執(zhí)行過程中 context 的上下游信息，包括 intoput、output 等信息。對 query plan 進一步解析，從而形成了數(shù)據(jù)血緣的 mode，然后寫到 MQ，最后獲取 sql 數(shù)據(jù)進行解析，將血源信息落到圖數(shù)據(jù)庫。

另外一種就是通過定時調(diào)度產(chǎn)生的血緣，感知到用戶提交的 sql 表信息之外。還需要將用戶調(diào)度任務信息與庫和表的關系進行一個呈現(xiàn)。同時會將通過其他方式提交的歷史任務記錄的日志消息存儲在 HDFS。我們會定時抓取這些日志并對日志做統(tǒng)一分析處理，比如 mr 、spark、sql 分析，形成血緣模型，發(fā)送到 mq，最終寫入數(shù)據(jù)庫。

sql 解析是血緣解析過程的關鍵技術，業(yè)界有很對 sql 解析和開源的技術，我們內(nèi)部是基于 Druid 進行封裝和改進構(gòu)建了sql guru，并進行 sql 解析。相比于 hive 的 antlr 解析器，通過實際效果對比，我們選擇了在性能穩(wěn)定性以及支持的場景更有優(yōu)勢的 Druid。Druid 處理廣泛使用的連接池之外，它數(shù)據(jù) sql 解析方面也是比較強悍的。除了常見的血緣解析能力之外，我們還擴展了一些比如像物化視圖、像臨時表 with as，join 等復雜 sql 的解析。基于相對全面元數(shù)據(jù)采集，結(jié)合強悍的 sql 解析能力以及語法支持，我們將血緣分析的場景盡可能做得完善。

5、數(shù)數(shù)據(jù)血緣存儲

圖數(shù)據(jù)庫是血緣存儲的常見方式，因此圖數(shù)據(jù)庫也作為了我們內(nèi)部血緣存儲的一種方式。當數(shù)據(jù)量級比較小時，圖數(shù)據(jù)庫并不是血緣存儲的唯一方式，基于傳統(tǒng)的關系數(shù)據(jù)庫可以表達出來血緣的關系，血緣無非就是各種實體以及它們之間關系的記錄。

以圖中的 case 所示，圖中有兩個調(diào)度任務，第一個調(diào)度任務里面有兩段 sql，執(zhí)行第一個 task 是會執(zhí)行兩個獨立的 sql，第一個 sql 是 a 和 b 的關系，第二個 sql 是 d 和 c 的關系。第二個 task 只有一個 sql，它是 a 和 b 的關系，那這個時候就會有一個問題：數(shù)據(jù)血緣圖數(shù)據(jù)庫里面怎么呈現(xiàn)的呢？

圖數(shù)據(jù)庫存儲的無非就是點和邊以及中間的線，橫向來看，我們把表和任務作為點來存儲，可以看到左邊這種情況 那我們看 比如像 task A 把 a 和 b 關聯(lián)，同時將 c 和 d 關聯(lián)。因此，它們的血緣關系如圖左上角所示。因為是通過同一個 task 關聯(lián)，當我們?nèi)ふ遗c c 有關聯(lián)的血緣時，會找到 b 和 d 都找到了。從圖中可以看到 task A 一個特性里面看到有兩段的 sql，但 a 和 b 才有真正但血緣關系，c 和 b 之間是沒血緣關系的。c 與 b 之間有血緣關系是因為錯亂導致的。

因此我們做了針對性優(yōu)化，如右上圖所示，可以看到右邊這種情況。將任務節(jié)點拆成兩個節(jié)點，雖然兩個節(jié)點輸入同一個任務，但是每個節(jié)點都有唯一的標識記錄，這樣就可以區(qū)分出來，建立關系清晰的血緣鏈路。從 a 出發(fā)，就只會知道與它有血緣關系的 b，這樣就解決了上面所說的錯亂的問題。

另一種思路就是將表作為點,任務去作為邊,那這種情況會有什么問題呢？可以看到 a 和 b 通過 task A 和 taskB 分別建立這個血緣關系。除了這個表的血緣關系之外還需要體現(xiàn)任務的血緣關系。而在圖數(shù)據(jù)庫中兩個相同的點之間，只能有唯一的一條邊，按這種方式處理前面提到的情況，是首先是 a 和 b 建立血緣關系，后面 b 則會再和 a 建立血緣關系。這樣就會將出現(xiàn)任務信息覆蓋的情況，導致整個血緣關系的不完整。結(jié)合在血緣關系處理過程中可能出現(xiàn)的各種情況以及它們帶來的問題，我們最終選擇圖數(shù)據(jù)庫的方式將表和任務均作為點，然后用邊建立血緣關系，記錄整個血緣。

以上就是本次分享的內(nèi)容。本次分享主要是我們騰訊內(nèi)部數(shù)據(jù)治過程遇到的問題以及處理方法。希望通過本次分享能夠給在做數(shù)據(jù)治理和建設的同學一些指導，幫助大家規(guī)避一些在日常工作中可能出現(xiàn)的問題。