我們搞數據的，按道理對數據架構應該比較熟悉吧，但自己最近卻越來越迷糊了，因為發現很多講數據管理的書，對數據架構的定義并不一致，有些出入還比較大。

自己趕緊去找權威的定義，發現搜出來的信息也是一地雞毛，因此特意寫這篇文章來探個究竟，即耳熟能詳的數據架構到底是什么？

一、業界看法

首先我們來看看DAMA、華為、工業界、DCMM及央行等各領域對于數據架構的具體描述：

1、DAMA：《DAMA數據管理知識體系指南 第二版》

定義：

識別企業的數據需求，并設計和維護總藍圖以滿足需求，使用總藍圖來指導數據集成、控制數據資產、并使數據投資與業務戰略保持一致。

目標：

識別數據存儲和處理要求；設計結構和計劃以滿足企業當前和長期的數據需求；戰略性地位組織做好準備，快速的發展其產品、服務和數據，以利用新興技術中固有的商機。

構成：

（1）數據模型：企業數據模型是一個整體的、企業級的、獨立實施的概念或邏輯數據模型，為企業提供通用的、一致的數據視圖。企業數據模型包括數據實體（如業務概念），數據實體間的關系、關鍵業務規則和一些關鍵屬性，它為所有數據和數據相關的項目奠定了基礎。

（2）數據流設計：定義數據庫、應用、平臺和網絡（組件）之間的需求和主藍圖。這些數據流展示了數據在業務流程、不同存儲位置、業務角色和技術組件間的流動。

2、工業大數據應用技術國家工程實驗室：《數據治理：工業企業數字化轉型之道》

定義：

講企業業務實體抽象為信息對象，將企業的業務運作模式抽象為信息對象的屬性和方法，建立面向對象的企業數據模型，數據架構實現從業務模式向數據模型的轉變，業務需求向信息功能的映射，企業基礎數據向企業信息的抽象。

構成：

（1）數據分布：包括數據目錄、數據資源全景圖、數據地圖分布應用。

數據目錄：作為數據共享交換的基礎數據，對促進企業內部數據共享與交換、對外上報和公示相關信息都非常重要；

數據資源全景圖：是企業全部數據資產的總體視圖，既包括分布、流向和交互關系，又包括數據治理、數據服務和數據后期應用的完整視圖。

數據地圖分布應用：是指站在數據資產全景圖的視角查看企業各數據域，在每一個數據域下，可以識別企業各項業務的核心數據主題，明確各個主題間的交互關系，將數據實體分類、形成企業級數據地圖。

（2）數據主題域：是最高層級的、以各個主題概念及其之間的關系為基本構成單元的數據主題集合。企業應劃分統一的數據主題域，形成統一的企業數據視圖。

（3）數據關聯關系：首先包括實體、屬性、主鍵、外鍵、關系及基數，其次包括數據血緣關系，最后包括數據流轉關系。

（4）數據模型：包括概念數據模型、邏輯數據模型及物理數據模型。

3、華為：《華為數據之道》

定義：

是指以結構化的方式描述在業務運作和管理決策中所需要的各類信息及其關系的一套整體組件規范。

目標：

定義好整個運作過程中涉及的各種人、事、物資源，并實施有效的治理，從而確保各類數據在企業各業務單元間高效、準確地傳遞，上下游流程快速地執行和運作。

構成：

（1）數據資產目錄：通過分層結構的表達，實現對數據的分類和定義，建立數據模型的輸入，形成完善的企業資產地圖，也在一定程度上為企業數據治理、業務變革提供了指引。基于數據資產目錄可以識別數據管理責任，解決數據問題爭議，幫助企業更好地對業務變革進行規劃設計，避免重復建設。

（2）數據標準：數據標準定義公司層面需共同遵守的屬性層數據含義和業務規則，是公司層面對某個數據的共同理解，這些理解一旦確定下來，就應作為企業層面的標準在企業內被共同遵守。

（3）數據模型：是從數據視角對現實世界特征的模擬和抽象，根據業務需求抽取信息的主要特征，反映業務信息（對象）之間的關聯關系。數據模型不僅能比較真實地模擬業務（場景），同時也是對重要業務模式和規則的固化。

（4）數據分布：定義了數據產生的源頭及在各流程和IT系統間的流動情況。

4、國標：《DCMM數據管理成熟度模型》及央行：《金融業數據能力建設指引》

定義：

通過組織級數據模型定義數據需求,指導對數據資產的分布控制和整合，部署數據的共享和應用環境，以及元數據管理的規范。

構成：

（1）數據模型：使用結構化的語言將收集到的組織業務經營、管理和決策中使用的數據需求進行綜合分析,按照模型設計規范將需求重新組織。從模型覆蓋的內容粒度看，數據模型一般分為主題域模型、概念模型、邏輯模型和物理模型。

主題域模型是最高層級的、以主題概念及其之間的關系為基本構成單元的模型，主題是對數據表達事物本質概念的高度抽象。

概念模型是以數據實體及其之間的關系為基本構成單元的模型，實體名稱一般采用標準的業務術語命名。

邏輯模型是在概念模型的基礎上細化，以數據屬性為基本構成單元。

物理模型是邏輯模型在計算機信息系統中依托于特定實現工具的數據結構。

（2）數據分布：針對組織級數據模型中數據的定義，明確數據在系統、組織和流程等方面的分布關系，定義數據類型，明確權威數據源，為數據相關工作提供參考和規范。通過數據分布關系的梳理，定義數據相關工作的優先級，指定數據的責任人，并進一步優化數據的集成關系。

（3）數據集成和共享：是建立起組織內各應用系統、各部門之間的集成共享機制，通過組織內部數據集成共享相關制度、標準、技術等方面的管理，促進組織內部數據的互聯互通。

（4）元數據管理：元數據管理是關于元數據的創建、存儲、整合與控制等一整套流程的集合。

二、架構的本質

可以看到，業界各方對于數據架構都給出了自己的解釋，似乎都有道理，但又有不一致的地方，為什么呢？

我覺得這些都是表象，關鍵是還是要能深入數據架構概念的本質，看看它的底層邏輯到底是什么，然后才能給出更好的解答，雖然1000個人心中有1000個哈姆雷特，但一定有穩定不變的東西在那里，這就是我們需要掌握的東西，否則人云亦云，學到什么時候才是個頭呢？

首先來理解架構這個概念。

先舉一個例子：

在最早期，每個人都完全獨立生活，衣、食、住、行等等全部都自己搞定，這個時候效率不是很高，但一旦出現了分工，力量就強大多了，因為分工后，每個人可以做最為擅長的事情，但這個時候必須要通過某些機制合在一起，讓每個人能交易到自己不擅長生產的東西。

在每個人都必須自己完成所有生活必須品的生產的時候，是沒有架構的，一旦產生的分工，就把所有的事情，切分成由不同角色的人來完成，最后再通過交易，使得每個個體都擁有生活必須品，這實際上就形成了社會的架構。

那么怎么定義架構呢？

把一個整體（完成人類生存的所有工作）切分成不同的部分（分工），由不同角色來完成這些分工，并通過建立不同部分相互溝通的機制，使得這些部分能夠有機的結合為一個整體，并完成這個整體所需要的所有活動，這就是架構。

再拿建筑來舉例加強一下理解。

最開始人類是住在山洞里，住在樹上的，主要是為了躲避其他猛獸的攻擊，以及減少自然環境的變化。為了完成這些目標，人類開始學會在平地上用樹木和樹葉來建立隔離空間的設施，這就是建筑的開始。但是完全隔離也有很多壞處，慢慢就產生了門窗等設施。建筑的本質就是從自然環境中，劃出一塊獨占的空間，但是仍然能夠通過門窗等和自然環境保持溝通。這個時候架構就已經開始了。

人們對建筑的需求慢慢的越來越多，空間的切分也會變成很多種，組合的方式也會有很多種，比如每個人住的房子，需要區分廚房、洗手間、書房、臥室等等，這個時候人們就開始有意識的去設計房子，架構師就慢慢的出現了。一切都是為了滿足人的越來越高的需求，提升質量，減少時間，更有效率的切分空間，并且讓空間之間更加有機的進行溝通。這就是建筑的架構以及建筑的架構的演變。

總結一下，什么是架構，就是：

（1）根據要解決的問題，對目標系統的邊界進行界定。

（2）并對目標系統按某個原則的進行切分。切分的原則，要便于不同的角色，對切分出來的部分，并行或串行開展工作，一般并行才能減少時間。

（3）并對這些切分出來的部分，設立溝通機制。

（4）根據（3），使得這些部分之間能夠進行有機的聯系，合并組裝成為一個整體，完成目標系統的所有工作。

看了上面的例子，你就能完全理解DAMA對架構做的一個更抽象的定義，即架構是對組件要素的設計，旨在優化整個結構或系統的功能、性能、可行性、成本和用戶體驗。在國際標準ISO/IEC/IEEE 42010:2011中，將架構定義為：“系統的基本結構、具體體現在架構構成的組件、組件之間的相互關系以及管理其設計和演變的原則”。

三、數據架構的本質

1、數據是業務的映射

建筑架構的目的是讓人們住的更舒服，那數據架構的目的當然是讓存儲和使用數據的應用或系統能夠更順暢的運轉，因此，無論是DAMA還是《華為數據之道》都在強調這一點，特別是華為，直接點出了數據架構的目的就是“確保各類數據在企業各業務單元間高效、準確地傳遞，上下游流程快速地執行和運作”。

企業為實現價值創造，從輸入客戶要求開始到交付產品及服務給客戶獲得客戶滿意并實現企業自身價值的E2E（端對端）業務過程就是業務流。

業務對象是指業務流中涉及的人、事、物，業務對象承載了業務運作和管理涉及的重要信息，業務對象會隨著事件的驅動在業務流中流轉，業務對象的載體是數據，流動的信息也是數據，這些數據只有滿足下游的要求，業務流才能順暢流動起來，否則價值創造過程就會受阻或停滯。

IT承載的是業務流以及數據，IT支撐每一個作業以及作業輸出的數據，通過IT實現數據之間的集成，流程的自動化。

可以這么說，業務是由業務對象和業務流構成的，數據則是業務的映射。

2、數據如何有效切分

業務一般是非常復雜的，為了方便管理業務，首先需要切分業務，每個切分的子業務域最好是高內聚，松耦合。高內聚的目的就是為了專業化，這樣子業務域的運作效率就高，松耦合的目的是子業務域之間的溝通成本最好低一點，這樣整體的運作效率就越高，現在DDD（領域驅動的設計）本質就是為了達成這個目標。

子業務域是專業化的業務對象的集合，對業務的要求自然映射到了對業務對象的要求，那如何實現業務對象“高內聚，松耦合”的設計呢？

這自然是數據模型要完成的事情，數據模型代表了業務切分的結果。

因此，數據模型是數據架構的核心構件，國標DCMM對于數據模型的描述非常到位，分為四個層級，主題域模型、概念模型、邏輯模型和物理模型，這些模型的設計體現了切分的思維，也體現了切分的粒度變化。

3、數據如何有效流轉

切分只是完成了數據架構的第一步，切分后還需要確保各子領域能夠高效的溝通，這依賴數據流的合理設計，數據流可以用于描述不同層級模型的映射關系，無論是主題域、業務實體、乃至屬性層面的映射關系，體現了數據在流程和IT系統上流動的全景視圖，其至少需要達成以下目標：

（1）明確數據實體在哪個源頭產生

（2）數據實體出現在業務流的哪個環節

（3）數據實體出現在哪個流轉系統

數據流設計要確保數據語言的一致性，促進業務流能夠順利的運轉，就好比人類分工了以后，需要通過統一貨幣才能促進交易一樣。現在數據治理特別強調數據源的一致性，要求業務數據必須認證數據源，在公司范圍內統一發布，目的就是統一語言。

因此，無論是叫數據流還是數據分布，都屬于數據架構的核心構件，這是業界的共識。

我認為數據模型和數據流（或叫數據分布）是數據架構最本質的東西，其讓業務切分的合理并且切分后溝通順暢。

四、數據架構的衍生

DCMM將數據集成和共享納入數據架構的范疇，我覺得主要是業務流的內涵擴大導致的結果，因為以前的業務流僅局限在OLTP系統內部，OLAP起來后，通過集成多方業務流的數據，可以產生更有價值的數據。

這些價值數據通過共享手段反哺到業務流，可以促進業務流的進一步優化，從這個角度來講，數據集成和共享應該納入數據架構，因為它起到了提升溝通效率的作用，這是與時俱進的結果。

隨著數據被納入生產要素，這個趨勢估計會越來越明顯吧，當然，這僅是我的一個猜測，畢竟只有DCMM一家這么做。

華為把數據資產目錄和數據標準當成數據架構的組件，應該是管理提升的需要，但并不是數據架構必需的。

以前數據模型的設計都是一堆亂七八糟的PDM，PDM實例化后，其數據架構已經在系統實現了，但如果你要去修改完善，會發現這些數據模型的設計信息沒人管、找不到、看不懂，這阻礙了數據架構的進一步優化，因此搞個數據資產目錄作為指引。現在數據資產目錄作用越來越大，因為數據集成和共享的時候特別需要。

數據標準的制定則讓各環節數據流上的數據可以更好的保持一致性，它是數據流的增強。

DCMM將元數據管理納入數據架構的范疇，估計跟華為也類似，只是范圍進一步擴大了。

工業大數據的數據主題域屬于數據模型的一部分，數據關聯關系的實體、屬性等屬于數據模型一部分，數據血緣關系和流轉關系則屬于數據流一部分。

因此，雖然DAMA、華為、工業、DCMM及央行對于數據架構的構成有不同的描述，但都包括了數據架構最本質的東西，即數據模型和數據流，至于其它的東西，那就見仁見智了。