內部資料治理

嘿哈布爾!

數據是公司最有價值的資產。幾乎所有專注於數位化的公司都宣稱這一點。無可辯駁的是:沒有一次大型 IT 會議不討論管理、儲存和處理資料的方法。

數據來自外部,也產生於公司內部,如果我們談論來自電信公司的數據,那麼對於內部員工來說,這是有關客戶、他的興趣、習慣和位置的資訊倉庫。透過適當的分析和細分,廣告優惠是最有效的。然而,在實踐中,並非一切都那麼美好。公司儲存的資料可能已經完全過時、冗餘、重複,或者除了一小部分用戶之外,任何人都不知道其存在。 ˙_(ツ)_/˙

內部資料治理
總之,數據必須有效管理,才能成為為企業帶來真正效益和利潤的資產。不幸的是,解決資料管理問題需要克服相當多的複雜性。其主要原因是系統“動物園”形式的歷史遺留問題以及缺乏統一的流程和管理方法。但「數據驅動」意味著什麼?

這正是我們將要討論的內容,以及開源堆疊如何幫助我們。

戰略資料管理資料治理(DG)的概念在俄羅斯市場已經廣為人知,並且企業透過實施其實現的目標是明確且明確的。我們公司也不例外,為自己設定了引入資料管理概念的任務。

那我們要從哪裡開始呢?首先,我們為自己設定了關鍵目標:

  1. 讓我們的數據易於存取。
  2. 確保資料生命週期的透明度。
  3. 為公司用戶提供一致、一致的數據。
  4. 為企業用戶提供經過驗證的數據。

如今,軟體市場上有十幾種資料治理類工具。

內部資料治理

但在對解決方案進行詳細分析和研究後,我們為自己記錄了一些批評:

  • 大多數製造商提供一套全面的解決方案,這對我們來說是多餘的並且重複現有的功能。另外,與當前 IT 環境的整合在資源方面也很昂貴。
  • 功能和介面是為技術人員設計的,而不是為業務最終用戶設計的。
  • 產品成活率低,在俄羅斯市場缺乏成功實施。
  • 軟體和進一步支援的成本很高。

上述關於俄羅斯公司軟體進口替代的標準和建議說服我們在開源堆疊上轉向我們自己的開發。我們選擇的平台是 Django,一個用 Python 寫的免費開源框架。因此,我們確定了有助於實現上述目標的關鍵模組:

  1. 報告登記冊。
  2. 商業術語表。
  3. 用於描述技術改造的模組。
  4. 用於描述從來源到 BI 工具的資料生命週期的模組。
  5. 數據品質控制模組。

內部資料治理

報告登記冊

根據大公司內部研究的結果,在解決與數據相關的問題時,員工花費40-80%的時間尋找數據。因此,我們給自己設定的任務是公開現有報告的訊息,這些資訊以前僅供客戶使用。因此,我們減少了產生新報告的時間並確保數據的民主化。

內部資料治理

檢舉登記冊已成為各地區、各部門、各部門內部使用者的單一檢舉窗口。它整合了公司多個企業儲存庫中創建的資訊服務訊息,Rostelecom 中有許多此類資訊。

但登記處不僅僅是一份枯燥的已開發報告清單。對於每份報告,我們都會提供使用者熟悉所需的資訊:

  • 報告的簡要說明;
  • 資料可用性的深度;
  • 客戶群;
  • 可視化工具;
  • 公司倉庫名稱;
  • 業務功能需求;
  • 報告連結;
  • 訪問申請的連結;
  • 實施情況。

使用等級分析可用於報告,並根據基於唯一使用者數量的日誌分析將報告排名在清單頂部。事實並非如此。除了一般特徵外,我們還透過值和計算方法的範例對報告的屬性組成進行了詳細描述。這樣的詳細資訊可以立即讓使用者知道該報告對他是否有用。

此模組的開發是資料民主化的重要一步,大大減少了尋找所需資訊所需的時間。除了減少搜尋時間外,向支援團隊提供諮詢的請求數量也減少了。我們不可能不注意到我們透過制定統一的報告登記冊所取得的另一個有用成果——防止為不同的結構單位制定重複的報告。

業務術語表

大家都知道,即​​使在同一家公司內,業務也有不同的語言。是的,他們使用相同的術語,但含義完全不同。商業術語表就是為了解決這個問題而設計的。

對我們來說,商業術語表不僅僅是一本描述術語和計算方法的參考書。這是一個成熟的環境,用於開發、商定和批准術語,在術語和公司其他資訊資產之間建立關係。在進入業務術語表之前,術語必須經過業務客戶和資料品質中心批准的所有階段。只有在此之後才可以使用。

正如我在上面所寫的,該工具的獨特之處在於它允許從業務術語層級到使用該工具的特定使用者報告以及實體資料庫物件層級的連接。

內部資料治理

這是透過在註冊表報告的詳細描述和實體資料庫物件的描述中使用術語表術語標識符來實現的。

目前,術語表中已定義並商定了 4000 多個術語。它的使用簡化並加快了公司資訊系統中傳入的更改請求的處理。如果所需的指標已在任何報告中實現,則使用者將立即看到一組使用該指標的現成報告,並且能夠決定有效重複使用現有功能或其最小修改,而無需啟動對編寫新報告的新要求。

用於描述技術轉換和 DataLineage 的模組

您問這些模組是什麼?僅僅實現報告註冊和詞彙表是不夠的;還需要將所有業務術語建立在實體資料庫模型的基礎上。這樣,我們就能夠透過資料倉儲的各個層完成從來源系統到BI視覺化的資料生命週期的形成過程。換句話說,建立一個 DataLineage。

我們根據公司之前使用的格式開發了一個接口,用於描述資料轉換的規則和邏輯。與以前一樣透過介面輸入相同的訊息,但業務術語表中術語標識符的定義已成為先決條件。這就是我們在業務層和實體層之間建立連結的方式。

誰需要它?您使用了幾年的舊格式有什麼問題?產生需求的勞動成本增加了多少?我們在實施該工具的過程中不得不處理這樣的問題。這裡的答案非常簡單 - 我們都需要這個,我們公司的資料辦公室和我們的用戶。

確實,員工必須適應;起初,這導致準備文件的勞動力成本略有增加,但我們解決了這個問題。實踐、識別和優化問題領域已經完成了他們的工作。我們已經取得了主要成就——我們提高了所開發需求的品質。必填欄位、統一參考書、輸入掩碼、內建檢查——所有這些使得顯著提高轉換描述的品質成為可能。我們放棄了將腳本作為開發需求移交的做法,並分享只有開發團隊才能使用的知識。產生的元資料資料庫顯著減少了進行迴歸分析所需的時間,並提供了快速評估變更對 IT 環境任何層(展示報告、聚合、來源)的影響的能力。

這與報表的一般使用者有什麼關係,對他們來說有什麼好處?由於能夠建立 DataLineage,我們的用戶,即使是那些遠離 SQL 和其他程式語言的用戶,也可以快速接收有關生成特定報告的來源和物件的資訊。

數據品質控制模組

如果不了解我們提供給用戶的數據是正確的,我們上面討論的確保數據透明度的所有內容都不重要。我們資料治理概念的重要模組之一是資料品質控制模組。

在目前階段,這是針對選定實體的檢查目錄。產品開發的近期目標是擴大檢查範圍並與報告登記處整合。
它將給予什麼以及給誰?註冊表的最終用戶將可以存取有關報告準備就緒的計劃和實際日期的資訊、已完成的動態檢查結果以及有關加載到報告中的來源的資訊。

對我們來說,整合到我們工作流程中的資料品質模組是:

  • 迅速形成客戶期望。
  • 就進一步使用數據做出決定。
  • 在工作的初始階段獲得一組初步的問題點,以建立定期品質控制。

當然,這些都是建立成熟的資料管理流程的第一步。但我們相信,只有有目的地做這項工作,積極將資料治理工具引入工作流程,我們才能為客戶提供資訊內容、對資料的高度信任、接收的透明度並提高啟動速度新功能。

數據辦公室團隊

來源: www.habr.com

添加評論