導語：
隨著越來越多的企業認識到數據作為生產要素的價值，加快了企業數字化轉型，把完善企業級的數據治理體系作為企業數字化轉型的一個目標。長亮科技在大數據領域始終保持足夠的技術敏銳度，并積累了豐富的經驗與資產。為此，我們組織了一個系列專文，分期發表，與您一起探索更適合當下行業發展的數據觀，歡迎大家持續關注。
作者｜長亮科技大數據研究院 內容｜本篇共4694字，預計閱讀時間18分鐘
企業數據管理包含數據架構、數據集成、元數據、數據質量、數據建模、主數據與參考數據等多個管理職能領域，數據架構是管理數據的基礎。站在企業架構的高度，數據架構與企業應用架構、技術架構有緊密的關系，最終影響數據資產的質量。長期以來，一些組織沒有把數據當作產品來開發，沒有把數據當作資產來管理。幾乎每個組織的每個數據管理職能領域以及應用架構，都存在提升空間，但不要企圖短期內得到全面提升，應該梳理整個組織的數據管理生態系統，找出合適的某些領域先行優化，即使少量的投入，也可能很快產出價值。 01 盤點數據資產 數據的多樣性與數據量爆炸式增長使數據的管理日益復雜，數據需求的激增使數據服務的提供部門窮于應付，迫切需要盡早盤點存量數據資產。 l 盤點庫存資產及資產使用狀況 盤點組織范圍有哪些數據以及數據狀況，數據所代表的準確定義，有什么用途，梳理清楚數據資產起源于何處，如何在組織中移動，形成清晰的庫存資產目錄與資產分布地圖與血緣。 盤點跟蹤數據資產被不同用戶、不同需求使用的情況，包括使用的廣度、深度與頻度等，評估使用產生的價值，從而發現可重用的高價值數資產據，并質疑不被使用的數據資產的存在意義。 l 提高高價值資產的使用效率與重用率 盤點數據資產，發現有價值的數據資產，形成數據資產目錄，提高數據服務的質量、使用效率。在盤點過程中可能發現不同人員開發了相似或相同的數據資產，在沒有數據資產目錄的情況下，重復開發的現象是必然存在的。庫存中的數據資產，無論多少份重復的數據，只能算同一資產，除了備份之外，其它都是多余的，不僅占用存儲空間成本，還要付出管理維護成本。數據資產目錄可以提升資產重用率，從而避免資產無序增長。 l 數據資產目錄，應該包含問題資產目錄 盤點數據資產，目的不僅僅是為了得到一份可供使用的數據資產清單，還要為問題資產管理提供輸入。如果不是簡單地為了輸出資產目錄，在定義數據資產與以及數據資產之間關系的過程中必然會發現許多問題，諸如各種數據質量問題、數據流轉與分布不合理、信息孤島、煙囪式應用、使用了不合適的數據源（沒有使用權威數據，減少負資產的使用與影響）、數據使用不合規等等。 數據資產的“目錄”概念，弱化了數據資產的內在意義，代替不了數據架構的職能。數據資產的含義要比一般圖書目錄、商品目錄豐富得多，數據資產之間是有關系的，可以帶來更多潛在的衍生價值。 02 完善基礎元數據 盤點數據資產需要可靠的元數據對數據資產進行定義、歸類，建立數據之間關系與血緣關系。組織的運營取決于共享信息的能力，在大多數組織中，元數據管理方面的歷史欠賬太多。 l 缺乏元數據 啟動盤點數據資產工作，面臨的第一個問題是缺乏數據資產的元數據。許多業務系統只能從生產庫上導出沒有業務邏輯的物理庫表結構。銀行業務數據不是憑空產生的，應該先有數據的元數據后才能產生數據，不是先有雞還是先有蛋的問題。現實是一些業務系統設計時并沒有考慮到數據的使用，數據被當作業務系統的副產品，尤其是快速迭代的互聯網系統產生的各種大數據，一般沒有把元數據作為最終產品交付件。 l 元數據不可靠 即使在系統建設初期維護了部分元數據，也沒有納入配置管理中，投產之后更新不及時或再也沒有更新，不能保持一致且最新，不同文檔之間內容不一致。元數據發布也不到位，常常遺漏下游用戶，不同人員的版本不一樣。數據倉庫中的基礎數據元數據也不齊全，衍生數據的元數據也很少維護，所謂的統一指標，不是建立在統一的基礎之上的。混亂的元數據差異（數據結構、格式和值的使用差異）比簡單的數據錯誤影響嚴重得多。 數據生命周期前期階段工作的不負責任，沒有交付可靠的元數據，下游用戶無法比較與關聯數據，也就不能準確使用這些數據，更無法將數據作為資產進行管理，增加了數據使用成本與風險，拖延了數據項目實施周期，后期需要付出更大的補救代價。 因為元數據管理不善，也因此衍生出大量不一致的元數據。如一些銀行數十萬數據項，足以說明其數據與元數據管理的混亂。 需要及早梳理、補充完善基礎元數據，如最基本的數據庫設計說明書、每項數據資產的業務含義，關鍵數據元的定義與規則等等，無論代價多大，都無法回避這些工作。基礎元數據的完善一般應先于數據資產盤點或作為數據資產盤點項目的前期工作完成。 03 優化數據架構 很多數據資產問題可能因數據架構的缺陷導致的。企業數據架構描述數據應該如何組織與管理數據，作為企業架構的一部分，是管理數據資產的藍圖。數據架構的設計貫穿于數據全生命周期，沒有數據架構也就沒有數據管理的基礎，導致數據管理各種成本的大幅增加。 許多組織沒有設計數據架構，架構部門的職責范圍不包含對數據架構的管理，可能僅限于管理技術架構或部分應用架構，架構設計與管理的能力弱，也不具備對供應商方案的把控管理能力，整個組織概念混亂，數據分布與數據流轉混亂。 只有少量組織建立了數據架構，龐大的數據架構需要足量的高端架構師進行持續管控維護。架構本應該長期相對穩定的，某些組織卻每五年甚至兩到三年大幅度修改架構。一些從業人員試圖用業務領域來分類數據，把業務分類與數據分類混為一談。 某些組織意圖對某些主數據進行集中管理，但沒有配套的管理組織、人員、流程與措施，比如開發部署了ECIF系統，但僅能保證客戶三要素或四要素是企業一致的，保證鍵的唯一，不對主數據本質屬性管理，這些數據還是混亂的，產生不了客戶單一視圖。 與過去數據模型僅存在于數據倉庫的認知一樣，不少數據專業人員對數據架構的認知僅限于數據倉庫的分層。雖然對數據倉庫的分層仍有不同的理解，在數據倉庫實施過程中，確實倒逼了企業數據架構與應用架構的建設、提升優化。 隨著業務與產品的創新，業務與技術試圖突破已有的各種管理限制，使數據的管理日益混亂，成本日益增加。組織需要具備良好管理的數據架構，盡快形成企業的數據分類，開發概念數據模型，從對基本概念達成一致的認識開始，指導盤點資產、數據的產生與使用、數據標準等工作，及早實現數據資產管理的價值。 04 優化應用架構 應用架構是對實現業務能力、支撐業務發展的應用功能的結構化描述。應用架構重點回答業務功能在哪里實現的問題，數據架構重點回答數據在哪里產生又在哪里使用的問題。許多組織整體上缺少對業務、業務流程與信息數據的理解，沒有很好規劃應用架構。 一些應用系統由歷史演變而來，可能包羅原始所有的業務，設計擴展性差，已經不能適應不斷變化的業務需求，沒有一個大而全的應用系統能支撐大型組織所有的業務。應該從應用架構與技術架構上進行拆分。 有些業務應用系統的功能過于單一，開發不同的業務系統處理相同或相似的業務功能，除了導致概念不統一（如對私、個人、零售三個名稱不同但內涵相同的概念，“個人貸款借據表”中的業務主鍵的名稱是“零售貸款借據編號”，給使用者造成業務主鍵與表分別表達了不同業務的誤解），每個系統必須具備完整的業務操作與處理流程，無論設計開發，還是系統配置、運維人員配置，都造成資源浪費，導致昂貴的成本。可以想象一下，當兩個業務功能相似的系統整合為一個系統的時候，會帶來哪些收益。 流程關系緊密的業務功能分散在多個應用系統中實現被拆分為多個系統，如貸款業務申請、客戶評級、授信、擔保、押品、合同放款、貸后、核銷等所謂對公信貸全流程，業務功能分別在多個系統實現，從一個或2個集中的系統被過度拆分，數據集成與交互的復雜性指數級增加，同樣的數據在多個系統中存放，必然導致數據的不一致性，同時產生了混亂的概念，如貸款申請流程中沒有業務意義的技術主鍵，流轉到授信、合同放款等系統中時，被轉義為貸款申請編號，而用企業抽象通用的業務編號表示真正的貸款申請編號，還產生了貸款借據、貸款支用、貸款賬戶等概念。 應用架構影響數據架構與數據的集成。不合理的、混亂的應用架構編織了復雜的蜘蛛網，不但制造了混亂的概念，還造成數據集成的困難甚至集成了錯誤的數據，給業務管理與數據管理帶來困惑，增加數據管理成本與風險。 需要從企業視角優化整合各條線、部門應用，解決功能過于分散、功能交叉重疊與分工不清晰的問題。良好的數據資產管理，離不開業務架構、應用架構、數據架構以及技術架構頂層設計來降低數據資產總擁有成本，給業務提供高質量的數據。架構方面一項小的優化措施，可能帶來大的價值提升。 05 有效實施數據標準 一些組織已經實施了十多年數據標準，制定了包含數千或超萬的數據標準信息項，但是十多年過去，落地實施的標準并不多，即使最基本的數據項也大多沒有落地。比如某行建立了幣種、幣種代碼、幣種編碼、幣種碼、貨幣種類代碼、幣種類型代碼、幣種種類編碼、幣種種類代碼、貨幣代碼、幣種代碼值、幣種信息等近千名稱不同、數據類型不同的幣種代碼相關數據項。 數據標準本身定義不準確或不嚴謹，數據標準的內涵理解存在比較大的差異，合標要求不明確或不嚴謹，或多或少都存在一些問題，流于形式與表象，沒有抓住本質。比如： 分類是管理數據很關鍵的一項工作，有些數據標準，除了按照主題域分類外，沒有進一步的分類，比如產品分類、協議分類、事件分類，數據設計人員有了隨意發揮的空間。 l 有些標準術語/數據項甚至沒有定義，標準維護人員在沒有準確了解現存標準的情況下不斷新增標準術語與數據項，導致不斷膨脹。 l 屬性名稱只落標中文名，雖然建立了詞根中英文名稱對照，但是沒有通過工具強制執行，造成物理名稱與邏輯名稱的不一致。在物理建表時，即使提供了字段的中文說明，但Hive不支持將字段中文注釋顯示為查詢結果的標題，這種情況下的落標沒有起到作用。 l 客戶名稱的技術屬性標準，如定義為VARCHAR（80），標準的解釋為只要長度不超過80位即是合標的，但是如果某些業務系統的定義沒有遵循標準，在數據倉落標時常常被截斷。對于這些關鍵屬性，嚴謹的標準還應該限制最小長度，以確保數據質量。 l 沒有管理代碼類數據項的枚舉值，或數據項的碼值沒有經過嚴謹設計，僅是簡單的羅列，如設計了生命周期狀態數據項，用于各數據主題域相關實體的生命周期的狀態，包含數千個碼值，中文名稱為“正常”的碼值超過20多個，從而失去了使用價值。 數據標準應該是嚴謹的，標準應少而精，易于理解掌握，逐步推進工作。把實施寬泛的大而全的數據標準作為數據治理的切入點或啟動項目不是一個有效的選擇。數據標準所能表達的意義有限，數據標準僅是衡量數據質量的參考依據之一，并不能代替數據架構來管理數據。 06 及時解決數據質量問題 任何組織的數據都可能存在質量問題，包含大量冗余與垃圾數據。數據質量問題一經發現，應找到問題的根本原因及早解決，因為分析問題與解決問題都要付出成本，質量分析人員每天都需要分析質量問題，需要占用資源，成本隨著拖延的時間不斷增加。 盡量在上游解決數據質量問題，避免問題發散。因為同一個問題從源頭被傳到數據湖與數據倉庫，再進一步傳導到各個下游應用，相關人員都需要重復分析與解決問題，代價指數級增長，解決方案也可能不同，最終用戶看到的可能不一致。 數據質量問題內涵復雜，涉及跨部門、跨專業合作，對于數據質量問題的識別與處理往往依賴于質量分析人員的能力與組織執行力，應把質量問題的產生、解決時間與成本價值聯系起來，建立數據質量問題認責與考核機制，避免扯皮推卸責任現象。對于已經積累多年的陳年舊債，要分析分類，從架構出發，解決根本問題。 一些組織的治理和信息資產項目由合規性驅動，是被動型項目，而不是由數據作為資產所衍生的潛在價值驅動。由于各種歷史原因，各企業的數據管理存在很大的提升空間，基于成本收益基準，從優化現有的數據及數據管理生態開始，不懈地關注架構、標準、質量和流程等，打好數據價值基礎。
