騰訊資料治理技術實踐

導讀 隨著公司業務方規模的增長，面對大量不同型別的資料，如何治理這些來源不同、資料量大的資料是一個值得思考的問題。

本次分享結合騰訊內部資料管理方法，圍繞資料治理技術實踐，展開介紹騰訊在資料治理領域中做的相關工作，本次分享圍繞以下三點展開：

1. 資料治理簡介

2. 騰訊資料治理體系簡介

3. 資料治理技術實踐

分享嘉賓｜趙磊 騰訊 騰訊後設資料系統負責人

編輯整理｜韓城 新浪微博

出品社群｜DataFun

---

01

資料治理簡介

首先介紹一下資料治理相關理論知識和概念，以便大家對資料治理有一定了解和認識。

1. 什麼是資料治理

個人理解的資料治理是整個資料相關組織架構以及各種活動能力的集合，因此，資料治理並不是單一組織或者系統能夠完成的事情。資料治理和資料管理是分不開的，資料治理的職能是指導其他資料管理職能的執行，資料治理是在高層上執行的資料管理。

2. 資料治理目的

資料治理的目的有很多，比如資料共享、提升資料資產價值、提升資料質量等等，從下圖中的某機構調查結果可以看到，提升資料質量是資料治理的最大動機。除此之外，國家對資料相關法律規定，各個公司也有相關的規範要求，資料合規也是資料治理需要考慮的問題。

3. 資料治理面臨的困難

資料治理面臨著諸多挑戰：比如資料多樣化缺乏統一標準、多種異構型別的資料來源、資料鏈路長、資料合規保障、資料價值如何評估等等。

4. 資料治理方法

瞭解了資料治理面臨的問題後，該如何解決這些問題？我們的方法就是知治管（先知後治再管）。

先知就是要知道治理的資料物件，知道資料的形式，儲存位置等；後治是使用相關技術進行治理比如規範化、標準化等處理；再管就是盡力去提升新資料的質量，這樣才算是真正把整個資料治理按體系做好。資料治理其實是一個閉環的體系，所以還需要將資料治理反饋到整個資料管理流程上。

5. 資料治理過程

資料治理由圖示的四個步驟構成：

一是現在盤點，理清楚資料現狀，確定歸屬和職能。

二是數倉建設，這裡的數倉包含了傳統意義上的數倉和後設資料數倉，對這些資料進行統一採集和儲存。

三是質量檢測，確定評估標準，輸出資料質量報告。

四是持續改進，根據資料質量報告推動資料持續改進，比如建立資料地圖、分析血緣關係、持續監控資料質量、最佳化資料使用流程。將資料的產生和治理相結合結合，形成閉環，從而保證資料的採集和資料治理變得更好。

02 

騰訊資料治理體系簡介

這部分主要介紹騰訊內部資料治理體系的建設思路和策略。

1. 組織管理體系

在騰訊內部，我們建立了統一組織，規劃和協調整個公司的資料治理、資料安全工作，以 OTeam 形式規劃和實施整個相關領域的平臺建設和規範協同；建立企業級標準，規範測評體系；構建平臺協同，建設開箱即用的一站式資料治理工具平臺；形成社群運營，透過分享或宣傳的方式，讓大家意識到資料治理以及資料質量的重要性。

2. 騰訊資料治理業務框架

騰訊這樣量級的公司，動輒幾千萬上億甚至百億級別的資料，資料的採集和儲存都是很大的問題。在上億量級的資料治理建設過程中，我們一步步實踐，踩過很多坑。透過制定資料治理標準，搭建了以資產建立、資產評估、資產運營、資產管控四部分構成的資料治理平臺，構建全域後設資料服務，形成了後設資料採集、儲存、數倉、資料血緣的整個資料生命週期鏈路，結合底層採用多種儲存方式，逐步建設了一個可以管理和區分優質資產與資料垃圾、相對較好的後設資料管理體系平臺。

3. 後設資料管理

我們從如何採、怎麼存、引導治出發，來思考和逐步完善後設資料的管理。

4. 資料資產管理

我們建立區分優質資產，減少垃圾資料的資料資產管理平臺，由四個部分組成：

首先是確定資料歸屬，如果資料歸屬都沒明確，則資料治理工作是很難展開，像騰訊這樣級別的大公司，經過多次組織架構的變更，資料歸屬問題尤其凸顯，比如說經過組織調整，單個 BG 的資料拆成了多個 BG 的資料導致，資料管理問題在組織架構變遷變得非常混亂，因此確定歸屬關係是資料治理一個非常關鍵的環節。

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

然後是資料清理，為了避免資料清理或者減少許可權變更影響的範圍，需要進行影響分析判斷，同時結合自動化清理工具完成整個資料清理或是許可權變更。只是做好資料清理工作是不夠，因為在實際運算元據過程中，可能會出現誤刪或故意刪除的情況；為了保證資料資料情況的可靠性，我們還建立一套資料可恢復的機制，從而保證出現上述情況時，能夠快速進行資料恢復，儘可能地降低影響範圍。

最後是生命週期，結合資料血緣和訪問頻次等學習，為使用者設定資料生命週期時，對該資料的生命週期進行智慧化推薦；當然，這只是推薦的生命週期，資料最終的生命週期要結合著人工稽核判斷，給定一個比較合理的週期。

5. 騰訊資料治理測評體系：後設資料管理成熟度

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

6. 資料安全治理

資料安全也是資料使用過程中一個非常重要的環節，在這過程中，我們首先對資料進行了分類分級處理，為資料確定安全等級和標記，並與資料資產進行關聯。其次在進行資料管控，根據資料的分類分級結果，定製不同資料級別的申請流程，比如動態或靜態資料，資料加密和脫敏，在資料使用中對資料進行管控。最後是安全審計，支援一些安全審計相關功能比如資料許可權訪問監控、訪問記錄、下載日誌等等，並可以輸出安全報告。

7. 騰訊資料治理測評特徵-安全管理能力成熟度

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

制定了資料安全管理能力標準後，資料治理透過 OTeam 進行統一組織和協調，各個部門自行申請或者參與到整個評測的工作中。

03

資料治理技術實踐

這部分是本次分享的最核心部分：騰訊內部後設資料管理、資料血緣相關技術和相關的後臺技術實現。

1. 技術架構

下圖是我們內部統一後設資料系統的技術架構。對外來說，上層可以支援不同型別後設資料，可以滿足各種分析引擎對後設資料相關的要求，同時對接各種自定義或者標準化的資料來源。這套底層統一的後設資料服務既要滿足公司內部的要求，同時也要滿足外部的使用者對整個資料治理的需求。目前這套後設資料管理除了內部使用外，也支援了騰訊雲上的產品比如 WeData 等，我們統一後設資料平臺目前對公司內外及相關產品都可以提供支援。

從下往上看，整個統一後設資料可分成兩個垂直的領域。 

左邊是資料治理體系，主要面向的是離線採集、儲存，然後做資料檢索、生命週期、資料安全、資料血緣和資料質量的管理，這些就是資料治理提供的基礎服務。線上後設資料是支援引擎側的實時後設資料寫入，比如大資料領域最典型的 Hive、RDBMS、Strom，透過 thrift 協議，將資料實時寫入到後設資料服務。離線資料治理和線上資料治理所面臨領域和技術的差異是比較大的，資料治理更關注的是大資料量基礎上，如何做好分析、檢索和工作。因此在底層儲存的選型方面結合了各種資料庫，比如 HBase、ES、圖資料庫以及關係型資料庫來支撐整個離線治理工作。線上後設資料服務因為有部分事務工作，比如建庫建表，實時寫入時，需要考慮到事務、資料一致性和高可靠等因素，因此，在底層儲存時，選擇了傳統的關係型資料庫進行儲存。需要事務和一致性、高可靠的方式去完成。像騰訊體量的公司，資料量是非常龐大的，單純的靠單機 MySQL、PQ 是很難支援這種海量資料儲存。因此，我們在這個基礎上進行分庫分表，並利用公司內部 TDSql 分散式資料庫儲存。

右邊在是統一後設資料服務基礎，提供公共的平臺能力，比如認證、鑑權、任務排程、使用者租戶以及運營監控。

2. 微服務劃分

上圖是我們整個後設資料治理服務後臺微服務劃分，上層是後設資料產品、計算引擎、資料來源，第二層是在第一層基礎上提供後臺能力，比如資料地圖、後設資料採集、資料血緣和資產管理等功能，最底層就是整個支撐這套體系的技術服務。

後臺的技術服務又分成了兩層：第一層是資料層或接入層，主要由databus、center、metastores 組成，其中 hybirs 是後設資料服務內部代號。databus 的作用是統一消費經過 MQ 轉發的訊息並落庫，http 服務和 Thrift 服務經過接入層服務後，透過 RPC 協議進入基礎服務層並在基礎服務層進行業務邏輯處理，最後寫入到底層儲存。

接入層分為兩層是為了底層儲存能夠提供通用的服務能力。接入層的第二層更靈活，可以支援不同產品和引擎，以及不同資料來源對接和適配。從圖中可以看到，databus 有一條直通底層資料庫的鏈路。考慮到 databus 的職責所在,因為 databus 是對 mq 訊息進行統一消費，考慮到資料量，databus 對寫入效率的要求非常高。http 服務和 Thrift 服務的資料量相比而言就少 很多，為了減少資料消費的延遲，我們將 databus 消費的資料直接落庫，減少 http/Thrift 服務中的 RPC 呼叫，縮短鏈路，進一步提升資料入效率，從而將採集的資料及時地儲存底層儲存中。

3. 資料採集

首先是統一後設資料的資料採集，資料採集可以分成兩個方向：定時採集和實時採集。

定時就是透過定時任務或排程定期連線資料來源，對上游的後設資料進行採集。採集的過程又分為增量採集和全量採集。因此定時採集可以分為定時增量採集和定時全量採集；定時增量就是每次只採最近一段時間的資料，透過積累採集全部歷史資料。定時全量就是每次將全部資料一次性採集完，然後落地。

在實際工作中，往往是將增量採集和全量採集結合使用。資料採集並不是最初就進行全量採集，而是待資料積累到一定量後才對後設資料採集或治理工作。首次採集時，通常是使用全量採集的方式將歷史資料採集，後續的資料往往是透過定時增量的方式採集。

對於那些必須要定時增量的資料，為了減少後續鏈路的壓力，我們做了針對性的最佳化：透過 redis 對定時增量做了過濾處理，比如採集週期內，對庫資訊、表資訊以及分割槽資訊計算 md5 值並儲存在 redis，然後對採集的後設資料進行 md5 計算，再與 Redis 中對應的值進行比對，在源頭過濾掉沒有差異的資料，從而減少重複資料的傳送。

面臨的另一個問題就是全量採集時全量刪除和全量覆蓋。在增量化處理時，資料刪除是面臨問題的：上一次是全量處理，後續則是增量處理，比如在某個週期內，有五個庫，這一次採集，需要刪了一個庫(表),增量採集的方式是沒辦法直接找到要刪除的庫(表) ，也即是刪除些資訊沒辦法透徹到下游。

針對資料刪除無法發現，我們對資料來源所在庫和表做了快取，在後續的資料採集時，與 redis 中快取資料做全量對比取交集和差集，從而判斷資料的修改情況比如刪除、新增或修改，在源頭去掉重複的資料，同時有又能發現刪除的情況，最後把過濾處理後的資料發到訊息中介軟體。經過後續的消費、分發(採集的資料來源是有多種多樣的，因此會有分發器來識別和和處理不同型別後設資料)最終分發不同的資料儲存的流程。比如血緣資訊、後設資料 DDL 資訊、審計日誌資訊的資料，針對不同型別資訊資料有不同的處理鏈路，根據資料特點落入不同的儲存，比如血緣資訊資料寫入圖資料庫，後設資料 DDL 資訊儲存到 HBase。

資料治理產品前端互動是透過 ES 完成，打上寬表滿足前端互動和資料發現以及資料管理的需求。資料審計的日誌流水，則使用內部 hermes ，hermes 是一個類似 ES 的產品，但在儲存方面做了針對性最佳化。

傳統關聯式資料庫都有唯一的主鍵，根據這個主鍵就可以增刪改查等處理。但是在後設資料管理中，對於非採用非關聯式資料庫，該如何處理呢？比如上游採集好的一條後設資料資訊傳遞過來，我們需要對資料進行判斷，比如是否存在或者是否修改。首先是查詢，根據庫(表)名查詢是否存在，若存在則是更新操作；不存在則是新增操作。這個過程會與資料庫發生兩次互動，對整個鏈路會產生較大的影響 。

為了處理這個問題，我們引入了 guid 生成器（guid generator），將庫和表的資訊和資料來源資訊輸入到 guid 生成器，生成一個統一編碼的 guid，作為底層儲存的唯一標識。然後用生成的 guid 對資料庫進行一個類似叫 replace into 的方式，從而實現透過一次跟資料庫的互動就能新增或修改操作。這樣處理對整個寫入流程是一個很大的提升。比如 hbase，直接使用 upsert，將新資料寫入資料庫，無需關心是新增還是修改。為了保證資料的最終一致性，我們將實時與週期性全量或增量的方式結合，去實現資料的最終一致性。在發生資料實時採集不及時或者鏈路有問題的情況下，透過全量採集的方式進行補漏處理。 

4. 統一後設資料-血緣採集分析

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

另外一種就是透過定時排程產生的血緣，感知到使用者提交的 sql 表資訊之外。還需要將使用者排程任務資訊與庫和表的關係進行一個呈現。同時會將透過其他方式提交的歷史任務記錄的日誌訊息儲存在 HDFS。我們會定時抓取這些日誌並對日誌做統一分析處理，比如 mr 、spark、sql 分析，形成血緣模型，傳送到 mq，最終寫入資料庫。

sql 解析是血緣解析過程的關鍵技術，業界有很對 sql 解析和開源的技術，我們內部是基於 Druid 進行封裝和改進構建了sql guru，並進行 sql 解析。相比於 hive 的 antlr 解析器，透過實際效果對比，我們選擇了在效能穩定性以及支援的場景更有優勢的 Druid。Druid 處理廣泛使用的連線池之外，它資料 sql 解析方面也是比較強悍的。除了常見的血緣解析能力之外，我們還擴充套件了一些比如像物化檢視、像臨時表 with as，join 等複雜 sql 的解析。基於相對全面後設資料採集，結合強悍的 sql 解析能力以及語法支援，我們將血緣分析的場景儘可能做得完善。

5. 數資料血緣儲存

圖資料庫是血緣儲存的常見方式，因此圖資料庫也作為了我們內部血緣儲存的一種方式。當資料量級比較小時，圖資料庫並不是血緣儲存的唯一方式，基於傳統的關聯式資料庫可以表達出來血緣的關係，血緣無非就是各種實體以及它們之間關係的記錄。

以圖中的 case 所示，圖中有兩個排程任務，第一個排程任務裡面有兩段 sql，執行第一個 task 是會執行兩個獨立的 sql，第一個 sql 是 a 和 b 的關係，第二個 sql 是 d 和 c 的關係。第二個 task 只有一個 sql，它是 a 和 b 的關係，那這個時候就會有一個問題：資料血緣圖資料庫裡面怎麼呈現的呢？

圖資料庫儲存的無非就是點和邊以及中間的線，橫向來看，我們把表和任務作為點來儲存，可以看到左邊這種情況 那我們看 比如像 task A 把 a 和 b 關聯，同時將 c 和 d 關聯。因此，它們的血緣關係如圖左上角所示。因為是透過同一個 task 關聯，當我們去尋找與 c 有關聯的血緣時，會找到 b 和 d 都找到了。從圖中可以看到 task A 一個特性裡面看到有兩段的 sql，但 a 和 b 才有真正但血緣關係，c 和 b 之間是沒血緣關係的。c 與 b 之間有血緣關係是因為錯亂導致的。

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

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

以上就是本次分享的內容。本次分享主要是我們騰訊內部資料治過程遇到的問題以及處理方法。希望透過本次分享能夠給在做資料治理和建設的同學一些指導，幫助大家規避一些在日常工作中可能出現的問題。