數據治理是指從使用零散數據變為使用統一主數據、從具有很少或沒有組織和流程治理到企業範圍內的綜合數據治理、從嘗試處理主數據混亂狀況到主數據井井有條的一個過程。數據治理是一種數據管理概念，涉及使組織能夠確保在數據的整個生命周期中存在高數據質量的能力。一個數據管家是確保數據治理流程遵循，指導執行，並建議改進數據治理流程的作用。
企業高層必須制定一個基於價值的數據治理計畫，確保董事會和股東可以方便、安全、快速、可靠地利用數據進行決策支持和業務運行。
數據治理對於確保數據的準確、適度分享和保護是至關重要的。有效的數據治理計畫會通過改進決策、縮減成本、降低風險和提高安全合規等方式，將價值回饋於業務，並最終體現為增加收入和利潤。
國際上此方面的研究協會比較多，但截止2014年底中國只有ITSS WG1國際化小組展開了正式研究，並向ISO正式提交和發布了數據治理的研究白皮書。
基本介紹
- 中文名：數據治理
- 外文名：Data governance
- 套用範圍：企業
- 技術要求：大數據分析
數據治理內容,數據治理類型,應對型治理,主動型治理,應避免問題,最適合領域,何時開始,元數據管理,作用及其管理,定義,重要性,驅動因素,大數據與治理,INFA產品,
數據治理內容
以企業財務管理為例，會計負責管理企業的金融資產，遵守相關制度和規定，同時接受審計員的監督；審計員負責監管金融資產的管理活動。數據治理扮演的角色與審計員類似，其作用就是確保企業的數據資產得到正確有效的管理。
由於切入視角和側重點不同，業界給出的數據治理定義已經不下幾十種，到目前為止還未形成一個統一標準的定義。
ITSS WG1認為數據治理包含以下幾方面內容
（1）確保信息利益相關者的需要評估，以達成一致的企業目標，這些企業目標需要通過對信息資源的獲取和管理實現；
（2）確保有效助力業務的決策機制和方向；
（3）確保績效和合規進行監督。
數據治理過程
從範圍來講，數據治理涵蓋了從前端事務處理系統、後端業務資料庫到終端的數據分析，從源頭到終端再回到源頭形成一個閉環負反饋系統（控制理論中趨穩的系統）。從目的來講，數據治理就是要對數據的獲取、處理、使用進行監管（監管就是我們在執行層面對信息系統的負反饋），而監管的職能主要通過以下五個方面的執行力來保證——發現、監督、控制、溝通、整合。
數據治理類型
應對型治理
應對型數據治理是指通過客戶關係管理 (CRM) 等“前台”應用程式和諸如 企業資源規劃 (ERP) 等“後台”應用程式授權主數據，例如客戶、產品、供應商、員工等。然後，數據移動工具將最新的或更新的主數據移動到多領域 MDM 系統中。它整理、匹配和合併數據，以創建或更新“黃金記錄”，然後同步回原始系統、其它企業應用程式以及數據倉庫或商業智慧型分析系統。
缺點：
批量集成和應對型數據治理方法引入的時間延遲可能導致業務部門繼續操作重複、不完整且不精確的主數據。因此，這會降低多領域 MDM 方案實現在正確的時間向正確的人員提供正確數據這一預期業務目標的能力。在期望被設定為數據將變得乾淨、精確且及時之後，批量集成引入的時間延遲讓人感到沮喪。應對型數據治理（下游數據管理員小組負責整理、去重複、糾正和完成關鍵主數據）可能導致讓人認為“數據治理官僚化”。
應對型數據治理還會導致最終用戶將數據管理團隊看做“數據質量警察”，並產生相應的官僚化和延遲以及主數據仍然不乾淨的負面認識。這還將使得 MDM 方案更難實現它的所有預期優勢，並可能導致更高的數據管理總成本。此方法的風險是組織可能以“兩個領域中的最差”而告終，至少部分上如此 – 已在 MDM 方案中投資，但是只能實現一些潛在優勢，即在整個企業內獲得乾淨、精確、及時以及一致的主數據。
改進方法：
有三個方法可超越應對型數據治理。
1. 用戶將數據直接輸入到多領域 MDM 系統中：用戶使用界面友好的前端將數據直接輸入到多領域 MDM 系統中，但是他們的新記錄和現有記錄的更新留在暫存區域或保留區域，直到數據管理員審核和認證為止。這之後 MDM 系統才接受插入或更新，以便進行完整的整理、匹配、合併，並將“最佳記錄”發布到企業的所有其他應用程式。此方法好過將一個完全不同的應用程式（例如 CRM 或 ERP 系統）作為
“錄入系統”，但是它仍然會出現延遲和效率低下。儘管存在這些缺點，使用暫存區域確實解決了大部分問題，例如不用強制執行重要屬性的錄入或在創建前不必進行徹底搜尋。此外，由於我們並不受傳統應用程式或現代 CRM 或 ERP 應用程式如何處理數據錄入功能的影響，通過不對應對方法進行批量數據移動，我們還大大縮短了時間安排。
2. 用戶輸入直接傳送到多領域 MDM 系統中的數據：在外面輸入新記錄或更新，但是會立即傳送到 MDM 系統，以便自動整理、匹配和合併。異常或例外傳送到數據管理員的佇列，幾個管理員便可支持更多最終用戶。這是第一個主動方法的改進，因為我們利用 MDM 系統的業務規則、數據整理和匹配功能，只要求管理員查看作為整理、匹配和合併流程的例外而彈出的插入或更新。
3. 用戶使用特定於數據治理的前端輸入數據：第三個方法是允許最終用戶直接錄入到多領域 MDM 系統中，但是應使用專為主動數據治理方法而設計的前端。可專門為最終用戶數據錄入設定螢幕，您可利用功能齊全的 MDM 系統允許的自動化、數據整理、業務規則、搜尋和匹配等所有功能。因此，不必首先將數據輸入到 MDM 系統的暫存區域中，並且您不需要系統外的單獨工作流應用程式。
主動型治理
主動數據治理的第一個優勢是可在源頭獲得主數據。具有嚴格的“搜尋後再創建”功能和強大的業務規則，確保關鍵欄位填充經過批准的值列表或依據第三方數據驗證過，新記錄的初始質量級別將非常高。
如果 MDM 系統中的數據質量初始級別非常高，並且如果您不會通過從 CRM 或 ERP 源系統中傳入不精確、不完整或不一致的數據來連續污染系統，則主數據管理的“保持它乾淨”方面非常容易。
主動數據治理還可有效消除新主記錄的初始錄入和其認證以及通過中間件發布到企業其餘領域之間的所有時間延遲。由用戶友好的前端支持的主動數據治理可將數據直接錄入到多領域 MDM 系統中，可套用所有典型的業務規則，以整理、匹配和合併數據。當初始數據錄入經過整理、匹配和合併流程後，此方法還允許數據管理員通過企業匯流排將更新發布到組織的其它領域。
主動數據治理方法消除了“數據治理官僚化”這一認識，因為主數據的授權已推給上游的業務用戶，使數據管理員處於很少被打擾的角色，他們將不會成為諸如訂單管理或出具發票等關鍵業務流程的瓶頸。
銷售和行銷均受益，因為可更迅速且經濟有效地完成行銷活動，在啟動活動之前無需前期數據糾正。財務上也受益，因為將一次性捕獲新客戶需要的所有數據元素，添加新客戶的流程包括提取第三方內容並計算信貸限額，然後將該信息傳回 ERP 系統。
沒有直接訪問 MDM 系統許可權的客戶服務代表通常必須搜尋幾個系統，找到他們需要的信息，從而採取措施。當通話中的客戶沒有耐心時，很難提供高級別的服務。當所有信息存儲在 MDM 系統中並可通過有效、用戶友好的前端進行訪問時，客戶服務代表將能夠訪問每個客戶互動需要的所有數據，並能夠在需要時授權新數據。
通過使 MDM 成為錄入系統及記錄系統，您能從本質上將數據維持在“零延遲”狀態，它在這種狀態下適合企業中的任何預期使用場景，同步到 CRM 和 ERP 系統的數據的清潔性、精確性、時效性以及一致性應當處於最高級別。
應避免問題
關係管理
MDM 應當成為不僅是主數據而且是主數據間的關係的記錄系統。它成為全方位了解不同系統的數據如何互相關聯的中心位置。例如，多領域 MDM 系統將來自訂單管理系統的銷售訂單和應收帳款中的發票關聯在一起。這些關係或層次結構顯示在與 MDM 系統數據直接互動的用戶界面中。用戶界面還可用於查看主數據間的關係並在 MDM 系統中直接編輯它們。因此，MDM 還成為關係的錄入系統。
歷史記錄
當您從諸如 CRM 系統等外部系統中接受新記錄或更新後的記錄時，可能會限制您跟蹤該記錄的歷史記錄，因為外部應用程式作出了一些限制。當 MDM 為錄入系統和記錄系統時，審計歷史記錄的複雜跟蹤和數據的沿襲成為可能。隨著時間的推移，它甚至可顯示核心主記錄的更改，按照各種用戶和流程在動態時間視圖中顯示插入和更新，可跟蹤和顯示每個屬性中的每個更改。工作流使用可配置的前端可設計和執行基本工作流功能，因此最終用戶可輸入新主記錄。但是，這些新記錄可能需要數據管理員的批准步驟，然後才能將它們完全接受到多領域 MDM 系統中並發布到企業的其它領域。另外一個工作流應用程式在數據管理員的任務佇列中。匹配或自動合併重複記錄遇到的例外傳送到相應的數據管理員。高級功能允許將問題提交給相應的人員，當用戶在休假時可自動重新傳送給後備人員。通過直接查看特定工作流步驟和這些流程的經過時間，減少了花費在查詢新記錄或更改後的記錄狀態的時間。
安全性
用戶界面應當是可配置的，並且不同的工作角色具有不同的訪問和許可級別。幫助數據管理員解決差異的一些數據元素可能不適合企業中的每個人查看。此外，即使在一個工作角色內，例如數據管理員，您可能需要不同的安全性級別，同時更高級別的人員能夠對更廣泛的記錄集執行更多操作。而且，您可能需要分離訪問許可權，例如德國的數據管理員不能查看法國客戶記錄。
使用 MDM 外部的 CRM 或 ERP 系統作為錄入系統時，該應用程式的安全模型可能會在誰有權對哪些記錄進行哪些操作方面強加一些限制。將主記錄的錄入和維護直接移到 多領域 MDM 系統之後，您可更加詳細地控制數據的安全性，可具體到每個屬性或欄位級別。
最適合領域
什麼因素阻止公司採用主動數據治理方法？總的來說，問題在於它們在數據治理成熟度等級中處於什麼位置。一家公司很難從成熟度模型的最左側 — 它們在其中沒有中央多領域 MDM 系統並且沒有數據治理組織或流程 —直接跳到該等級的最右側，它們在其中擁有強大的數據治理流程外加最新 MDM 系統和集成架構。通常，隨著時間的推移，組織會改進它們的數據治理方法。例如，當初始 MDM 系統開啟並運行之後，一些預期的優勢需要較長時間才能實現，或應對方法的局限性變得顯而易見，您可計畫以便在原始源系統中取消授權記錄的功能，並將該功能直接遷移到 MDM 系統中。
升級公司的集成或中間件功能（例如，添加一個能處理實時更新的集成工具）之後，可切換到主動數據治理方法，或作為現有 CRM 或 ERP 系統重大升級的一部分，因為這可能是引進需要的業務流程變更的最佳時機。
· 何時從“應對型”遷移為“主動型”
度量標準將推動業務案例從應對型數據治理遷移到主動數據治理。
問您自己以下問題，並嘗試量化時間、精力和費用投資方面的答案：
· 吸納一個新客戶需要多長時間？
· 涉及多少個不同步驟？
· 在普通新記錄被接受到多領域 MDM 系統之前會接觸它多少次？
· 由於這些源系統的局限性，仍在源系統中創建多少個重複記錄（然後在 MDM 系統中
· 合併）？
· 需要多少個數據管理員支持該企業？
· 主記錄是否進入了“更改，改回”循環，因為兩個不同的用戶組試圖強制執行兩個不
· 同的業務規則集？
· 主記錄的重要方面是否因源系統和 MDM 系統之間的“裂縫而失敗”？
· 維護各個源系統和 MDM 系統之間的集成的流程是否成為一種負擔？
· 在 CRM 系統中輸入新記錄後，必須等待才能在 ERP 系統中變得可用，用戶是否有所
· 抱怨？
· 是否存在數據治理的資金問題，因為它被看做是管理費用或一種官僚作風？
回答這些問題之後，應當明顯看出您是否將能夠遷移到更主動的數據治理方法。您可詳細計畫遷移流程，將它設立為一個獨立的項目或將它集成到另一個相關項目中。
何時開始
一些情況要求立即開始主動數據治理，例如當您獲得多個 CRM 系統和 ERP 系統，它們要求與多領域 MDM 系統集成，以便讓它們繼續充當錄入系統，或當您的當前源系統非常脆弱或很難維護或修改。
在這些情況下，要忍受困難並從一開始便為主動數據治理作出計畫。一些組織擁有成千上萬個直接在 MDM 系統中授權主數據的最終用戶，並且有一個數據管理員團隊支持他們、發現異常、解決低質量匹配、在需要時手動合併重複記錄等等。另一種套用情況是當您發現自己最終會選擇主動數據治理方法 — 何必再為建立源系統到多領域 MDM 系統的雙向集成而爭論？您或許不妨直接授權最終用戶來編寫主數據。
元數據管理
獨立企業數據集成軟體提供商Informatica公司（納斯達克代碼：INFA）認為：數據治理成功的關鍵在於元數據管理，即賦予數據上下文和含義的參考框架。經過有效治理的元數據可提供數據流視圖、影響分析的執行能力、通用業務辭彙表以及其術語和定義的可問責性，最終提供用於滿足合規性的審計跟蹤。元數據管理成為一項重要功能，讓 IT 部門得以監視複雜數據集成環境中的變化，同時交付可信、安全的數據。因此，良好的元數據管理工具在全局數據治理中起到了核心作用。
作用及其管理
Informatica將數據治理定義為“在組織範圍內，對流程、政策、標準、技術和人員進行職能協調和定義來將數據作為公司資產管理，從而實現對準確、一致、安全且及時的數據的可用性管理和可控增長，以此制定更好的業務決策，降低風險並改善業務流程”。
數據治理著重於交付可信、安全的信息，為制定明智的業務決策、有效的業務流程並最佳化利益相關方互動提供支持。因此，數據治理本身並非是結果，而僅僅是方法：即通過數據治理來支持最關鍵的業務目標。
定義
元數據為數據提供了一個參考框架。Forrester Research將元數據定義為“用於描述數據、內容、業務流程、服務、業務規則以及組織信息系統的支持政策或為其提供上下文的信息”。譬如，蘋果公司旗下的App Store在網上銷售軟體應用程式。在此情況下的數據是應用程式。元數據則是關於這些應用程式的信息，包括應用程式描述、價格、用戶評級、評論和開發公司。
重要性
正如某家大型銀行的高管所言：“如果沒有數據治理，任何元數據管理方案注定會失敗。”元數據管理可作為一項重要功能，讓IT部門得以管理複雜數據集成環境中的變化，同時交付可信、安全的數據。當業務利益相關方參與這一進程並接受對數據參考框架的責任，其優勢將變得更有說服力。此時，企業就能將業務元數據與基層的技術元數據進行關聯，為全公司範圍內的協作提供辭彙表和背景資料。
例如，當業務用戶要求其在 IT 部門的搭檔在報告或分析中顯示“淨收入”，就無需再提問“哪種淨收入——財務、銷售還是市場行銷？”除提供其他優勢外，良好的元數據管理還可通過免除此類重要問題，促進數據治理：
· 這個業務術語的含義是什麼？
· 在（幾個相似的）業務術語中應當使用哪一個？
· 該術語的來源是什麼？
· 該數據從數據源轉移到目標時是如何進行轉換的？
· 由誰負責該術語的定義、記錄和管理？
· 誰修改過該術語？如何及何時進行修改？
· 哪些政策和規則適用於該術語？
· 修改環境中的某一特定數據對象會對其他數據對象產生哪些影響？
· 在不對可能使用相同數據對象的其他報告和分析造成影響的前提下，需要多長時間來實施環境變更？
驅動因素
一系列公司方案推動了數據治理的進展，也由此帶動了元數據管理。這些方案包括：
· 通用業務辭彙表（簡單的數據管理）。這種“小規模試水”方法著重於某一特定問題或業務部門的通用業務辭彙表。
· 全面數據治理（或數據管理策略）。這是一種更近似由上至下的方式，通常用於涉及企業內一系列業務部門的較大規模計畫，並以按多個階段（如果不是更長時間）進行管理的計畫中的多個商機為目標。
· 合規。此類方案的推動因素是為遵守國際、國家、當地或行業法規的需求。合規——通常由一個治理、風險與合規性（GRC）職能部門進行管理，顯然與數據治理唇齒相依。在發現、分析和記錄企業的多項內部數據治理要求的同時，還必須與適用外部法規的相關特定要求進行統籌協調。其中部分示例包括：
· 銀行業：Basel II、Basel III、多德弗蘭克法案（Dodd Frank）、洗錢法案
· 保險業：償付能力監管標準II（Solvency II ）
· 醫療保健：HITECH Act、HIPAA
· 一般金融服務：薩班斯—奧克斯利法案
· 元數據管理。這是更上一層樓的做法，將元數據管理和數據治理作為“最佳實踐”與各個新的業務方案掛鈎。該方案對業務案例和項目範圍進行定義。在多家未能成功實施較大型數據治理方案的公司中，這一方法則取得了成功。
大數據與治理
幾乎所有企業都面臨著管理數據量、速度和種類的挑戰。Hadoop/MapReduce 技術在複雜數據分析能力以及按相對低廉的成本實現最大數據擴展性方面提供了一些有趣的優勢。Hadoop 在不久的將來取代關係性DBMS的可能性不大，這兩項技術更有可能並存，因為它們各有獨到之處。雖然用於管理和分析數據的技術可能不同，元數據管理和數據治理的目標應始終保持不變：為支持良好的業務決策提供可信、及時且相關的信息。不存在所謂的“大數據治理”或“大數據元數據管理”——相反，這是一個將全局企業數據治理和元數據管理活動加以擴展來包容全新數據類型和數據源的問題。
Hadoop帶來的挑戰之一就是元數據管理。如果沒有良好的元數據管理和數據治理，Hadoop將會缺乏透明度、可審計性以及數據的標準化與重複利用能力。企業仍將需要對數據相關關鍵信息的可見性，例如其來源、質量和所有權，否則就必須承受Hadoop變成環境內的又一個數據孤島的風險。在該領域湧現的 HCatalog 和Hive /HiveQL等新技術將使得從非結構化和半結構化數據中收集元數據變得更加簡易，從而實現Hadoop上的數據沿襲。這些功能對於將Hadoop集成入總體數據集成框架，以防止大數據在企業中遭到孤立隔絕，可如同任何其他數據源一樣進行治理至關重要。
INFA產品
Informatica（納斯達克代碼：INFA）可提供功能齊全而又穩健可靠的工具，具備交付可信、安全的數據和啟動成功的元數據管理方案所需的全部精確功能。Metadata Manager & BusinessGlossary可提供獨一無二的多項優勢，讓IT經理能夠儘量降低在實施變更時對關鍵業務數據造成損害的業務風險。
InformaticaMetadata Manager & Business Glossary是 InformaticaPowerCenter Standard Edition的關鍵組件之一。它可提供為數據治理方案奠定基礎所需的核心元數據管理工具。Metadata Manager & Business Glossary是一項單個產品，配備一個共享的元數據信息庫。它具備兩個用戶界面，供兩類截然不同的用戶使用：
· MetadataManager 可讓 IT 人員處理技術元數據。
· Business Glossary 可讓業務和 IT 管理員協同管理業務元數據。
ITSS WG1發布的白皮書表明
數據治理模型包括三個框架:範圍，促成因素和執行及評估。他們每個方面都包含許多組件來進行展示和描述它們是如何工作的。該框架顯示數據治理內部的邏輯關係。範圍展示了我們應該關注什麼，促成因素展示了數據治理的推動因素，執行和評估展示了如何實現治理的方法。該DG模型可以通過三個框架幫助我們理解數據治理。
數據治理的範圍包括四個層次的內容。首先，應該有一個治理要素負責管理其它管理要素，保證治理與管理的一致性。其次，下面的三個層次分別列示了需要治理的數據管理要素，其中價值創造層列示了通過數據治理所創造的價值服務。價值保證層描述了一個組織治理數據時重要保證服務。基礎數據服務層描述了一個數據治理的基礎數據服務。
