編者按：
隨著數字化轉型、數據要素市場化、高質量發展等宏觀導向，數據價值愈發得到重視。從最基礎的數據架構到上層的數據應用，無論是金融機構還是金融科技廠商，都有著各自的理解與實踐。長亮科技在大數據領域始終保持足夠的技術敏銳度，將以本篇關于“數據架構”的探討為始，后續推出系列文章，與您一起探索更適合當下行業發展的數據觀，歡迎大家持續關注。
作者｜長亮科技大數據研究院
內容｜本篇共3170字，預計閱讀時間10分鐘
很久以來，數據架構一詞的影響一直局限于很狹小的專業領域范圍之內，國內的數據治理工作基本都圍繞著數據標準開展。2021年2月9日人民銀行發布《金融業數據能力建設指引》，對數據架構的認識正式提升到了行業高度，而把數據標準改為數據規范，也算是各歸其位了。
數據架構是什么
按照ISO/IEC/IEEE 42010:2011的架構定義：系統的基本組織，體現在其組件、它們之間的關系和環境，以及管理其設計和演變的原則。
架構一詞來源于建筑行業。如果說杜甫當年蓋茅屋不需要設計，那么建造現代廣廈不可能沒有設計圖就開工了。
管理數據也需要架構。數據架構定義管理數據資產的藍圖，描述應該如何組織與管理數據，內容包括數據模型、數據定義、數據映射規范、數據流、結構化數據應用接口規范（DAMA DMBOK2）。數據架構需要持續動態地維護，并不比建筑架構設計簡單。
國家標準GB/T36073—2018《DCMM數據管理能力成熟度評估模型》關于數據架構的描述為：通過組織級數據模型定義數據需求，指導對數據資產的分布控制和整合，部署數據的共享和應用環境，以及元數據管理的規范。
那么如何解讀數據架構？有哪些組件？組件之間的關系是什么？與哪些環境有關系？
數據架構有哪些組件
企業數據架構設計包括企業數據模型設計以及數據流設計（DAMA DMBOK2），這也是數據架構比較經典的內容。從零開始設計企業數據架構需要很長的時間、很大的資金投入，并存在潛在的失敗風險。在企業數據架構實踐中，業界已有一些成熟的行業數據模型可以參考， 因此，一般情況下，最詳細的數據架構設計文件是一個正式的企業數據模型。物理數據模型也是數據架構文件，但物理數據模型是數據建模和設計的產物，而不是數據架構。
DCMM的數據架構能力域包括數據模型、數據分布、元數據管理、數據集成與共享能力項，DCMM把在DAMA數據管理知識體系中獨立的元數據管理、數據集成兩個領域也包含進去了。DCMM標準已被廣泛認可，一些領先的機構獲得了數據管理能力成熟度四級或五級認證。
如何理解DCMM定義的數據架構組件關系
數據架構的核心組件是數據模型，指導數據分布與數據集成。
數據分布也是數據集成的必要輸入。為提升數據集成與交互的效率，數據集成反過來對數據分布提出要求。
企業的數據模型、數據分布以及數據集成的設計文檔都是元數據，如果沒有這些元數據，組件之間的關系無法展現，用戶就無法使用數據。
數據架構與應用架構、技術架構的關系
數據架構不能獨立存在，站在企業架構的高度，與企業應用架構、技術架構有緊密的環境關系。
應用架構是數據架構的輸入。數據的分布是數據在業務應用與數據應用系統中的分布，這些系統的業務功能決定了將產生哪些數據以及需要哪些數據，因此，應用架構設計決定了數據的分布，指導數據架構中數據定義、數據集成與交互等規劃和管控工作。數據架構設計對應用架構的輸入不應照單全收，應用系統中的數據模型設計應遵循企業數據架構，數據分布與集成的原則要求影響應用系統的功能分布。
數據架構是技術架構的輸入。數據的集成交互與存儲規劃的需求是對技術架構提出的要求。技術架構是數據架構的落實基礎支撐，基于可靠性、性能·、實施的復雜性、成本等考慮的數據庫軟件、數據存儲等技術選型可能反過來制約應用架構與數據架構。
數據管理領域的反思
自金標委成立三十多年以來，在推動金融數據標準化方面取得了巨大成就，金融行業的數據管理水平一直處于領先地位。回顧數據管理領域具體實踐歷程，仍有一些問題值得反思。
數據架構管理簡單粗放
因為有便宜的存儲設備可以選擇，過度強調應采盡采（甚至有些企業主張實時采集全域數據，數據采集無差別“大而全” ），過度強調非結構化數據的價值，沒有對數據進行精細化區別管理，沒考慮過其中大部分數據可能沒有任何價值，沒有考慮TCO與ROI，放任數據的膨脹。
數據管理與治理沒有建立在企業數據架構基礎之上
有些企業數據架構的管理不包括數據模型，僅限于數據分析平臺（數據倉庫或數據中臺）的分布流轉，數據集成僅限于從數據采集開始到數據應用。
在數據模型設計與數據集成過程中，忽視了企業數據分布（應用架構）的輸入，可能導致所用數據并非權威數據源，甚至可能使用了錯誤的數據，無法保證數據質量。
數據治理體系化與深度有待提升
有些企業數據的治理停留在建章立制方面，有些企業建立了數據標準但沒有落地，意識到“同義不同名、同名不同義”，要統一術語概念，但沒有上升到數據架構體系層面，很難取得實質性進展。
許多企業花大力氣打通數據應用“最后一公里”，而不關注數據生產“最前十公里”。如果忽視數據問題產生的源頭，事倍功半，最后一公里的應用很難有高質量的數據基礎。
強調可用性，質量被忽略
有些金融企業在引入互聯網解決方案時忽視了行業差異，為了提高可用性，不斷提高數據不一致性等質量問題容錯率。互聯網行業許多業務場景對數據質量的要求不高，從統計角度只要滿足一定程度的相似性。而金融行業財務報表、合規監管等需求對數據質量的要求遠高于互聯網行業。
應該怎么做：
以企業級的架構視角來管理與使用數據
許多企業有數據，無數據架構。數據架構處于無感的被動地位，技術選型后才談數據架構，應用系統不考慮數據架構基本要求。當技術平臺窮于應付，不能給客戶帶來好的體驗時，不從數據架構、應用架構方面進行反思。
架構設計的本質是企業級頂層視角與體系化設計
清晰理解企業數據架構的本質，無論是數據治理或數據資產管理，還是數據倉庫、數據中臺或數字化轉型，都應該站在企業級頂層視角，進行架構層面的體系化設計。
數據生命周期每個階段的生產者、加工者都應該對自己設計的數據產品負責，對自己的用戶負責。設計者的眼光不但要向前看，還要注意到左右的應用架構與技術架構，還要向后看，認識到自己的設計工作是非常重要的環節。
穩定的架構來自抽象思維
架構應該是穩定的。解決“同義不同名、同名不同義”的問題只是數據架構管理萬里長征的第一步。即使數據模型的設計遵循數據標準，仍解決不了本質問題，只有采用抽象的思維，剝離數據的噪聲，抽象出業務的本體，才能產生穩定的框架，并以結構化、體系化來表達或展現。
與數據治理協同
數據治理是數據架構的另一關鍵環境因素。數據架構的目標最終需要通過與數據治理的協調一致才能實現，數據架構負責正確地做事，數據治理確保（按照數據架構）做正確的事。
把企業數據模型作為數據治理工作的產出物
從建立企業概念數據模型入手，讓各干系人認識到企業數據模型的重要性，在數據建模中體系化治理數據，在數據治理中逐步完善形成企業數據模型，指導數據在企業各系統的分布與集成，支持應用系統的數據重用與敏捷開發。
管理數據資產的全生命周期
建立數據即資產的數據資產觀，在日常工作中建立成本與收益意識，從數據的產生開始管理，使數據的設計者、生產者、加工者與管理者都認識到在數據的全生命周期中都投入了成本，優化數據管理生態，實現企業級的數據集成，驅動數據資產價值的最大化。
建立數據分析生態體系
結構化與非結構化數據有不同的價值密度，需要不同的處理技術與流程。數據不同的生命周期，價值密度也不一樣。需要建立完善的數據分析生態體系 ，有效管理各種不同形態、不同生命周期的數據，為不同用戶提供高質量的數據以及友好的體驗。
結語
企業數據的管理是一項持續的工作，不可能畢其功于一役。業務在發展變化中，數據架構也要同步更新。許多企業實施數據中臺并沒有帶來數據管理能力的提升，也沒能給用戶提供高質量的數據，如果不站在企業的架構視角，數據治理與數據架構脫鉤，各行其是，再換個馬甲也無用。
