任務治理篇 | 規范性治理都規范些什么
“任務規范性治理,保障平臺高效運行?!?在數據管理領域,任務治理至關重要。規范性治理究竟涵蓋哪些內容?又如何有效實施?
在本篇開始的時候,提到任務治理可以從兩個方面來做,一個是通過端到端的任務血緣鏈路來了解平臺任務,從而進行治理。另一個就是建立一些規范性的任務,來進行主動治理。這里就介紹一下主動的任務治理。
這里的規范性治理治理的內容都是些什么那?這個產品功能僅僅提供一些思路,設計的過程中,也并無覺得特別的通順。好多地方也感覺并不是特別好的形式,但是有沒有思路想出更好的形式。
在主動治理時,治理的對象是:任務、表、數據服務API??梢源蟾欧殖伤念悾捍鎯χ卫怼⒂嬎阒卫?、規范性治理、數據服務API治理。
一、存儲治理
存儲治理的對象主要針對表,通過治理的規則,識別出來可以被下線的表,從而將表的進行下線。來節省存儲空間。
在進行治理的時候,主要是通過治理的規則,來對具體的空間,建立治理任務,從而識別出來需要治理的任務。
治理規則有哪些,舉例說幾個:近180天讀取次數為0、近180天無更新表、表創建180天仍為空,等等。這里面的數值都是用戶可配置的,通過一個規則模版,來配置自己需要的規則。通過這些規則創建的任務,周期性運行之后來識別出來可以被下線的表,從而實現表的主動治理。
二、計算治理
計算治理的邏輯也是相同的,他的治理對象是任務,通過計算治理規則來創建治理任務,從而識別出來需要被下線的任務,將任務下線。從而實現任務的主動治理。
計算治理的規則都有哪些,這里也舉些例子:無下游依賴、近90天無運行、產出目標表為空、近七日資源消耗TOP30、近七日運行耗時TOP30。
通過諸如此類的規則,來創建規則任務,從而實現任務的主動治理。
三、規范治理
規范治理針對的對象仍舊是表,只不過相較于存儲治理監控的表里面的內容,這里更多的是對表的建表規范做監控。
舉些例子來看一下:
單一事實表建模
建模的時候只使用了一張上游表,這個時候是不是需要考慮建模的合理性。如果多張包的使用同一個單一表上游,是不是這多張下游表數據是重復的。這個規則從模型層面,來進行一個任務治理。
表描述或表中文名缺失、表層級信息缺失、表負責人缺失
這些均是一些表的屬性信息缺失,能夠明確將信息缺失的表給掃描出來,然后進行治理。從而完全表的描述。
臨時表名稱、命名不符合規范
這個事從表命名規范上來進行規范治理,確定這些臨時表名稱位置是否合理,正式的表是不是符合了表的命名規范。
跨層級取數、反向依賴、環狀鏈路
這些主要是從數據流向的角度進行的規范化,當然,這種數據的流向可能并不一定能夠這個明顯的發現,比如環狀鏈路,幾個節點形成環,才算環狀。這些在具體實現的時候都需要依據技術的實現程度來進行具體分析了。
四、數據服務API治理
數據服務的規則,相對簡單,目前只想到一個,就是通過常時間沒有調用的來找到可以下線的數據服務API。
近90天調用次數為0
90天了API仍舊沒有人調用,是不是需要統計出來進行下線了。
五、發現待治理任務之后更加復雜
上面說的通過這種類型的規則,來發現待治理或者待規范化的表、任務,這個過程可能不復雜。復雜的是,發現了之后怎么辦?
如果某張表下線之后,下游影響了誰,不會造成大范圍的問題?誰依賴了將下線的任務,真的下線是否會影響第二天任務運行?
對于雖然識別出來了,但是明確表示仍然被使用,不需要下線的,是否需要有白名單功能,來讓下次掃描時,不進行掃描?如果有了白名單如何避免,一加白名單了之的粗暴操作?
是不是需要一個暫時下線能力,如果第二天發現影響其他任務,再立即恢復?
搜描之后為了敦促開發人員進行治理操作,是不是需要有一個報表能力,定期進行排名、打分,推進治理的落地。
所以說,發現了待治理任務之后更加復雜,這一部分如何能夠流暢的操作,是需要好好考慮設計下的。
而且,在這個過程中也需要端到端的任務血緣鏈路,來更好的進行全局的了解。為下線操作提供依據。
六、在什么階段做
在規則中的90天、30天等等數量都是可配置的,可以根據具體的條件,設置為180天、365天等等。但是不管多少天,都是系統已經運行了一段時間,已經有大量的表、大量的任務,需要進行優化,提升平臺資源利用率的時候了。所以這個模塊可以在平臺運行一段時間之后再進行啟動。
七、和數據質量間的關系
似乎提交表的治理,很容易讓人想到數據質量,是不是在功能上和數據質量重疊了那。
其實,細分一下來看這里的表的治理是對于表本身的,表的名稱、備注,表是不是被使用,加工過程是不是符合數據正向流向。但是數據質量治理是針對的表里面數據內容本身。這樣細品起來,是不是就能發現這是兩個層面的了。當然,如果真要柔和在一起,也是沒問題的。這些產品本身不是目標,能夠解決數據問題,是一個目標。而且產品也是分久必合,合久必分的。慢慢進化。
八、總結
主動的任務規范性治理,在一個平臺后期階段是必要的,防止不斷膨脹的平臺表、任務對于資源的浪費是一方面,另一方面,一個干凈清爽的表、任務資產,也是開發能夠基于此,進行很好迭代升級的基礎。
本文由人人都是產品經理作者【數據小吏】,微信公眾號:【數據小吏】,原創/授權 發布于人人都是產品經理,未經許可,禁止轉載。
題圖來自Unsplash,基于 CC0 協議。
- 目前還沒評論,等你發揮!