第十四章：數據治理之數據源：數據源的數據接入、業務屬性梳理及監控

本章開始，將進入9大模塊的介紹。第一個模塊我們先介紹：數據源。數據源是整個數據中臺數據的來源，是一個起點。更好的管理好數據源這個起點，是數據治理的一個好的開始。

在【數據：業務生數據，數據生“萬物”】中提到，“數據的產生來源于業務”。而數據源就是“業務”和“數據”中間的一個連接點。如果連接點的左邊是“業務”，那么連接點的右邊就是“數據”，通過中間一個小小的連接點，將無限的數據資源釋放出來。

在傳統的數據源管理中，數據源模塊主要提供數據接入的能力，并沒有業務屬性梳理以及監控的能力。

數據源的數據接入能力，僅僅可以滿足數據開發的需求。數據源的業務屬性梳理和監控能力，才能滿足數據治理的需求。

1、數據源的數據接入

在所有的數據開發平臺、數據集成等等產品中，數據源管理一定是一個必備的模塊。在這個模塊中能夠創建各種不同類型的數據源，可以是傳統的MySQL、Oracle等，也可以是大數據的HIVE，MPP等。在創建不同類型的數據源時，除了通用的IP、端口、用戶名、密碼，還根據數據源類型的不同，設置不同的個性化項，目標就是能夠對各種類型的數據源進行穩定的連通，成功將數據接入到數據中臺中。（暫時不考慮數據導出去的情況。）

保證數據源穩定的連通，僅僅技術屬性就足夠了，不需要業務屬性。

但是缺少了業務屬性信息，就會丟失掉這個數據源屬于什么業務系統？屬于什么領域？這個業務系統是不是核心系統？這個業務系統的聯系人是誰，報錯了聯系誰？對應的數據中臺的聯系人是誰？

同時，也沒有辦法回答更加宏觀的統計數據。如：公司一共有多少的業務系統已經接入數據中臺？接入的表的比例是多少？核心系統是不是都已經入湖了？等等。

所以，在數據源中不僅僅需要技術屬性來保證連通性，滿足數據接入的需求，還需要對數據源的業務屬性進行梳理。

2、數據源的業務屬性梳理

業務屬性的梳理，可以分層兩個方面，一方面是各種業務信息的梳理，一方面是來源準確性的梳理。

業務信息梳理

數據源的業務信息梳理，就是盡可能多的將與數據源相關的業務信息梳理出來。數據源是“業務”和“數據”中間的一個連接點，通過對數據源的“業務”信息梳理，能夠讓“數據”在“出生”時就更加清楚的知道出身。

這些業務信息包括：屬于什么領域？屬于什么系統？系統運行狀態？是否核心系統？系統業務負責人？系統IT負責人？等等。這些業務系統信息，如果內部有業務系統清單的話，可以抽取已有的業務系統清單，在清單的基礎上進行信息維護。如果沒有業務系統清單，那么這些信息梳理清楚，其實就是一個公司內部的業務系統清單了。

除了上面的業務信息，還有一些數據源的業務信息：數據源權限負責人、數據源連接狀態（能夠周期性的監測）、數據源入湖狀態、數據源表入湖比例、schema更新狀態、連接信息統一搜索信息等等。這些信息的來源又和后面的數據源的監控有關。

通過這些信息的維護，就有效的補全了數據源的業務屬性，也就能夠回答上面提到的問題了。
來源準確性梳理

前文也提到，數據源是整個數據中臺數據的來源。如果確定不了這個數據來源的準確性，那數據的準確性就更無從談起了，這是保證數據質量的一個關鍵起點，后續在數據質量模塊的時候也會提到，數據質量不僅僅和數據質量模塊有關，會和數據治理的方方面面都有關聯。

在保證來源準確性時，需要遵循一個原則“數據第一次產生原則”。同一份數據可能會在不同業務系統內流轉多次，存在不同業務的數據源中，我們只以數據第一次產生的業務系統為準。

數據從哪里第一次產生，我們就從哪里取。當然，后續對應的業務系統也會對相應的數據負責。這也是“誰產生的數據，誰負責”。

數據源業務屬性的梳理，可以讓數據源在數據接入的基礎能力上，增加更多的業務信息梳理的功能。但是不能保證接入進來的數據源就一直穩定，一直不變。業務在不斷的發展，數據源也會不斷在變化，所以我們就需要數據源的第三個部分“數據源的監控”。

3、數據源的監控

對數據源的監控，又可以分成主動監控和被動監控（入湖數據信息查詢）。

這里的主動和被動，均以數據中臺（數據治理實施方）為視角。數據中臺能夠發起的就是主動監控，由非數據中臺的其他方發起的就是被動監控。

主動監控

主動監控，是說數據中臺能夠對數據源的連通性，數據表、字段的變化等進行主動的監控。如果發生了變化，能夠在監控的周期粒度下通知相關人員。

一般連通性監控，會是一個周期性的監控，比如說設置一個定時調度，多長時間進行一次聯通性測試，如果不通，則進行告警。數據表、字段的監控會是實時的監控，主要是監聽業務數據庫的日志信息，發現相應的變化，則進行實時告警。

主動的監控，有一個很大的問題，就是滯后性。我們監控的都是業務系統的生產環境，當通過監控發現連通性異常，或者數據表、字段的變化時，對于數據中臺來說，其實已經晚了。因為業務系統生產環境的上線時間點一般會放在晚上，這種時候監控到變化，即使收到了通知，也沒有時間進行數據中臺任務調整。能做的，只有提前于數據消費者知道數據可能出現異常，進行提前告知。

如果出現這種情況影響了數據正常產出，大部分時候都會吐槽業務系統上線不通知數據中臺，因此才造成了，比如表結構變化情況下，任務運行失敗，影響了數據中臺的任務運行，影響了數據的穩定性。

但是，說實話這種指責多少有點“找借口”。即使發布一個政策，規定業務系統每次上線都必須通知數據中臺，那么沒有工具落地的這個政策，個人也認為是走不長遠的。

一方面如果所有的業務上線都通知數據中臺，數據中臺就需要花費大量人力、精力去判斷，本次上線是否影響數據中臺。這還先不論是否有這個通暢的通知渠道建立了。另一方面，就是數據中臺的人在頻繁接到通知，但是發現大部分都不會影響之后，緊迫性也相應降低了。

還有就是，數據穩定的第一責任人是數據中臺，這種情況的出現應該找辦法給解決掉。而不是明知可能有這個問題隱患，還將所有希望寄托在別人的通知上面。

所以，我們需要另一種更加提前的被動監控。
被動監控（入湖數據信息查詢）

被動監控，或者叫入湖數據信息查詢。這里的被動是對數據中臺來說的，主動方是業務系統。業務系統主動的進行入湖數據信息查詢，數據中臺被動的接受入湖數據信息查詢。

實現被動監控，有兩個關鍵點，一個關鍵點就是數據中臺提供一個接口，能夠查詢出來入湖的業務數據哪些是不能變的，變了就會對數據中臺的每日任務運行產生影響。這樣就能夠讓業務系統上線前，通過調用這個接口，知道本次上線如果有表的修改，這些表的修改是否會對數據中臺的任務運行產生影響。如果是大的變更，甚至可以提前調用接口，在業務系統開發的過程中，就通過調用接口，從而提醒數據中臺進行相應的任務調整。

另一個關鍵點，就是需要能夠在業務系統上線發布流程中，嵌入這個環節，即如果修改的表結構有影響已入湖的表，則觸發一個告警，通知數據中臺人員，中臺人員審批通過之后，才允許審批繼續。如果不影響，則自動跳過這個環節，繼續業務系統的上線發布。

這樣，通過主動監控和被動監控，就可以將業務系統變更對數據中臺任務運行的影響降到最低了。甚至，有了被動監控，主動監控中的數據表、字段的變更監控都不需要了。

4、五大維度說明

在5大維度的章節中，也多次說明，5個維度是服務于每一個模塊的。通過5個維度讓每個模塊更好的有計劃的、可執行的推進實施。下面說下在數據源上，需要的維度設置。在每個模塊章節中，只對維度的個性化部分進行說明，詳細了解各個維度，可以看之前的維度介紹章節。

組織?組織的設置是相對穩定的，或者說在實現一個階段目標之前是穩定的。所以，組織維度對各個模塊相對通用，不需要針對不同的模塊，對組織維度進行調整，均采用以聯邦式為基礎的三層組織架構即可。（后續模塊如果對于組織維度沒有特殊要求，不會再單獨列舉此模塊）

重點關注的是，數據源作為一個數據接入的起點，在這個階段需要確定好組織架構中第三層：執行層，中角色的具體人選，主要就是數據管家（也叫數據BP），和數據合伙人。為不同業務領域和數據源確定好對應的具體人選。

這兩個角色也呼應在文章開頭我們提到的【數據源就是“業務”和“數據”中間的一個連接點。如果連接點的左邊是“業務”，那么連接點的右邊就是“數據”，通過中間一個小小的連接點，將無限的數據資源釋放出來。】其中的，數據合伙人負責這個連接點左側，數據管家負責這個連接點右側。

政策

在三層政策：總則-規范-操作手冊中，需要給不同模塊分別制定的是“規范-操作手冊”這兩層。

政策并不一定是越多越好，在不同模塊在進行執行過程中依據具體的情況，來決定是否需要制定具體政策，也主要針對跨組織的、有爭議的進行政策制定。

在數據源模塊中，有兩點需要在政策中明確出來。

第一點是，一定需要明確統一入湖的規范要求，將入湖這件事情和不同的業務系統達成共識：如何入湖？怎么配合？核心系統是否必須入湖？需要進行入湖業務信息的統計收集、梳理有多少業務系統？入湖是否有一個入湖標準？針對入湖的獎懲是什么？這一點也主要對應上面第二小節的【數據源的業務屬性梳理】。

第二點是，針對數據表和字段的變化，能夠整合到現有的系統發布流程中，進行被動的數據源監控。讓業務系統進行變更前能夠提前通知到數據中臺。這個即涉及到跨系統，又涉及到修改現有發布流程。這一點主要對應上面第三小節的【數據源的監控】。
工具?關于工具，我們已經在維度部分進行了說明了。工具的重要性，工具尷尬的位置等等。在具體的不同模塊中時，我們著重的介紹不同模塊中需要準備的工具的特性。一個工具如果要詳細說清楚，最好有一個原型，這里僅僅是對不同模塊工具進行概況說明。

在數據源模塊，工具需要支持第一小節的【數據源的數據接入】的一些常規能力設置，支持不同的類型的數據源的創建、編輯、刪除，連通測試，等等。

需要支持第二小節【數據源的業務屬性梳理】中的不同的業務屬性的記錄、保存、查詢。這個過程中，需要能夠對政策第一點中明確需要的規范進行落地執行，并能夠統計有多少不符合政策的業務系統，從而提供獎懲依據。

需要支持第三小節【數據源的監控】中需要的接口能夠，供業務系統，或者上線發布流程進行調用。來滿足數據源的監控需求。