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

根據(jù)AZure的定義，數(shù)據(jù)治理是流程、策略、角色、指標和標準的集合，可確保有效和高效地使用信息。這還有助于建立數(shù)據(jù)管理過程，在整個數(shù)據(jù)生命周期內(nèi)保持數(shù)據(jù)安全、私密、準確且可用。

對于使用數(shù)據(jù)推動業(yè)務(wù)增長、改進決策并確保在競爭激烈的市場中獲得成功的任何組織而言，可靠的數(shù)據(jù)治理策略至關(guān)重要。在收集大量內(nèi)部和外部數(shù)據(jù)時，需要制定一種策略來有效管理風(fēng)險、降低成本和執(zhí)行業(yè)務(wù)目標。

根據(jù)GoogleCloud的定義，數(shù)據(jù)治理是指為確保數(shù)據(jù)安全、私有、準確、可用和易用所執(zhí)行的所有操作。它包括人們必須采取的行動、必須遵循的流程以及在整個數(shù)據(jù)生命周期中為其提供支持的技術(shù)。數(shù)據(jù)治理意味著設(shè)置適用于收集、存儲、處理和處置數(shù)據(jù)的內(nèi)部標準，即數(shù)據(jù)策略。它規(guī)定了誰可以訪問哪些數(shù)據(jù)以及哪些數(shù)據(jù)應(yīng)受治理。數(shù)據(jù)治理還涉及遵循行業(yè)協(xié)會、政府機構(gòu)和其他利益相關(guān)者設(shè)定的外部標準。 

收據(jù)治理的五個方面之一：元數(shù)據(jù)管理平臺

元數(shù)據(jù)，又稱為MetaData，是很多數(shù)據(jù)平臺、軟件系統(tǒng)的核心。如果你熟悉Mysql，那么Mysql中的庫、表、字段等信息，都可以認為是元數(shù)據(jù)。在大數(shù)據(jù)領(lǐng)域，元數(shù)據(jù)往往代表各個平臺中類似Mysql中庫、表、字段的信息，往往是通過SQL、Thrift、ProtoBuffer等格式進行定義，并通過相應(yīng)的平臺進行管理，這個平臺就是元數(shù)據(jù)管理平臺，有的公司會給這個平臺起一個名字，叫數(shù)據(jù)工廠。許多數(shù)據(jù)庫、數(shù)據(jù)平臺中都有相應(yīng)的元數(shù)據(jù)管理模塊，比如Hive、Es、Doris等等。

在小米大數(shù)據(jù)團隊分享的資料中（原文在https://blog.csdn.net/rlnlo2pnefx9c/article/details/121528248），我們可以看到元數(shù)據(jù)的另一種分類：從抽象來看，包括分為實體、實體的屬性以及實體與實體之間的關(guān)系三個方面來進行分類。實體主要指表元數(shù)據(jù)和作業(yè)元數(shù)據(jù)，來自于工程師在ETL的實際工作中所涉及到的系統(tǒng)。如：Hive、Doras、Kudu、MQ、ES、Iceberg，即傳統(tǒng)的數(shù)倉及上下游。

比如：實體包含了技術(shù)元數(shù)據(jù)和生產(chǎn)元數(shù)據(jù)。其中技術(shù)元數(shù)據(jù)用于支撐數(shù)據(jù)資產(chǎn)管理的資產(chǎn)地圖；生產(chǎn)元數(shù)據(jù)，主要是作業(yè)的一些調(diào)度信息和運行信息，用于支撐數(shù)據(jù)資產(chǎn)管理的數(shù)據(jù)質(zhì)量和成本治理的服務(wù)。

實體的屬性，包含業(yè)務(wù)元數(shù)據(jù)和衍生元數(shù)據(jù)。

業(yè)務(wù)元數(shù)據(jù)包括數(shù)倉分層、數(shù)據(jù)分類、指標關(guān)聯(lián)、應(yīng)用信息、隱私分級等內(nèi)容。內(nèi)容來源于建模規(guī)范、業(yè)務(wù)、指標系統(tǒng)、BI看板、數(shù)據(jù)報表，以及來自于業(yè)務(wù)的隱私分級定義等。業(yè)務(wù)元數(shù)據(jù)用于支撐資產(chǎn)管理的資產(chǎn)價值、安全治理以及規(guī)范治理。

衍生元數(shù)據(jù)包含元數(shù)據(jù)的存儲計量和訪問計量。存儲計量是服務(wù)于存儲層面的成本治理；訪問計量用于描述數(shù)據(jù)的使用情況，從技術(shù)角度去衡量資產(chǎn)的價值。衍生元數(shù)據(jù)來源于ETL工作中涉及的HDFS-Image、Doris、Kudu、MQ、ES以及HDFS-Log、SQL-Log。

描述實體的關(guān)系，包括血緣元數(shù)據(jù)，用于描述元數(shù)據(jù)之間的關(guān)聯(lián)關(guān)系，用于支撐數(shù)據(jù)資產(chǎn)管理中的影響分析和資產(chǎn)地圖服務(wù)。

關(guān)于元數(shù)據(jù)平臺和相應(yīng)技術(shù)架構(gòu)，我們后續(xù)再單獨講解

收據(jù)治理的五個方面之二：數(shù)據(jù)血緣

數(shù)據(jù)血緣，有時候又叫數(shù)據(jù)全景，解決的是數(shù)據(jù)之間依賴關(guān)系的收集、存儲和查詢、分析的問題。說一個常見的場景，某業(yè)務(wù)發(fā)現(xiàn)自己的表里有個字段要下線，但是不知道有哪些業(yè)務(wù)、哪些下游數(shù)據(jù)依賴這個字段，那么通過數(shù)據(jù)血緣一般就能回答這個問題。

依托數(shù)據(jù)血緣模塊，往往還可以發(fā)現(xiàn)數(shù)據(jù)元數(shù)據(jù)的搜索、上下游依賴關(guān)系的確認以及數(shù)據(jù)變更的全鏈路追蹤等功能。

收據(jù)治理的五個方面之三：數(shù)據(jù)質(zhì)量

數(shù)據(jù)質(zhì)量，在大數(shù)據(jù)領(lǐng)域是一個大問題。典型的場景例如，命名數(shù)據(jù)生產(chǎn)的POI在北京，但是實際存儲后發(fā)現(xiàn)數(shù)據(jù)的POI點到了成都，這對數(shù)據(jù)后期的使用，尤其是一些基于LBS的廣告業(yè)務(wù)來說是完全無法忍受的。

數(shù)據(jù)質(zhì)量治理就是要解決這個問題。往往通過幾個方面進行：

組建專業(yè)的數(shù)據(jù)質(zhì)量保障團隊

提出、發(fā)布數(shù)據(jù)規(guī)范，通過基礎(chǔ)SDK、數(shù)據(jù)流平臺準入等多種基礎(chǔ)架構(gòu)平臺的管理和技術(shù)手段確保規(guī)范的落地

基于數(shù)據(jù)血緣等既有元數(shù)據(jù)平臺，打造數(shù)據(jù)質(zhì)量自動回歸測試平臺

收據(jù)治理的五個方面之四：數(shù)據(jù)ROI

最后一部分是數(shù)據(jù)ROI。眾所周知，大數(shù)據(jù)海量數(shù)據(jù)的采集存儲分析計算等工作，需要大量的人力算力。舉個小例子，有些日志平臺，每天產(chǎn)生幾百上千T日志數(shù)據(jù)，供業(yè)務(wù)方檢索分析，往往需要耗費上百臺服務(wù)器來搭建ES集群才能支撐，加上數(shù)據(jù)平臺多副本存儲等技術(shù)需求，一個需求，就要花費每個月上百萬的服務(wù)器成本。但是這些日志如果只拿來分析技術(shù)故障、定位技術(shù)問題，顯然ROI就有點低了。

中大型企業(yè)中往往有大量的這類場景。這個時候，結(jié)合元數(shù)據(jù)，準確評估每份數(shù)據(jù)的需求、生產(chǎn)采集存儲計算成本、產(chǎn)生的價值，甚至是在不同的數(shù)據(jù)項目之間，合并同類項，就顯得非常必要。數(shù)據(jù)ROI解決的就是這類問題。

總結(jié)

最后，數(shù)據(jù)治理往往不是一帆風(fēng)順的，往往要觸動很多技術(shù)部門和業(yè)務(wù)部門的既有利益和做法，需要有很強的資源協(xié)調(diào)能力，且無法一蹴而就。低代碼平臺打破了傳統(tǒng)的軟件開發(fā)模式，一切開發(fā)從元數(shù)據(jù)建模開始，具有原生數(shù)據(jù)治理、原生數(shù)據(jù)血緣等諸多優(yōu)勢，如有需要基于低代碼平臺開展數(shù)字化業(yè)務(wù)，歡迎聯(lián)系我們

• 上一篇：OCR是什么意思？
• 下一篇：RBAC權(quán)限模型