第十六章：數據治理之數據架構：數據模型和數據流轉關系

本章我們說一下數據架構，說到數據架構，就很自然的想到企業架構、業務架構、軟件架構，因為個人并沒有對這些內容進行深入了解，所以這里不做比對是否有相似或者共通的地方，僅僅來說一下我理解的數據架構。

1、什么是架構

要說數據架構，先說說什么是架構，怎么定義架構這個詞？

架構的本質是對復雜系統的解耦與重組。

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

提煉關鍵詞有三個：切分成不同的部分、不同部分之間相互溝通、完成整體所需的目標。

用日常生活中的"分工協作"思想來理解：當面對一個龐大整體（例如建造城市、設計操作系統）時，通過結構化拆分將整體分解為具有明確邊界的功能模塊（例如建筑中的地基/框架/管道，軟件中的前端/后端/數據庫），定義各模塊的職責范圍與交互規則，最終通過標準化接口實現模塊間的有機協作。

架構的價值體現在三個方面：

效率提升：通過專業化分工提升各模塊的執行效率。
風險隔離：單一模塊的變更不會導致系統性崩塌。
持續演進：模塊化設計使局部創新成為可能。

2、什么是數據架構

理解了架構，我們再說說數據架構。在說什么是數據架構之前，先說下為什么要有數據架構。

現實里某個事物的龐大復雜，所以需要架構，同樣，企業內不同業務產生的數據，特別龐大、復雜，就需要數據架構。

數據是由業務產生。在業務的運行過程產生的數據，被記錄到數據庫不同的表中，此時的數據已經相當于被打散了再進行的記錄，不能直觀的反應出數據對應的業務了。數據架構就需要將已經被打散的數據，重新進行劃分、組合來反映業務情況。

通過數據反映業務，自然也就能夠數字化的衡量業務、評估業務、優化業務、發現新的業務機會。也就是讓業務變的可量化了。

這個過程中，需要做兩件事情，一件就是這個業務有多少個模塊，也就是給切分成不同的部分。

第二件，就是不用模塊之間的聯系，也就是讓不同部分之間相互溝通。

使用數據領域的術語的話，第一件事就是確定數據模型。第二件事就是明確數據流轉。

所有，個人定義什么是數據架構？數據架構就是數據模型以及數據流轉關系。

3、數據架構設計需要的理論知識

要設計一個好的數據架構，需要兩方面的理論知識。

一方面是對于業務的理解，另一方面就是數據建模理論的知識了。

對于業務的理解：

對于業務的理解，在維度業務篇【業務：最熟悉的“陌生人”】中已經進行了介紹。里面詳細的介紹了業務的宏觀上的、和微觀上的理解。詳細的信息可以再回過頭去看一看。
數據建模理論的知識：

數據建模的理論知識，就有是一個比較大的領域了。這方面的知識也完全不是一兩句話能夠說清楚的。

不過，推薦一本相關書籍《Star Schema 完全參考手冊》，當然，數據倉庫建模相關的書很多，個人只參考過這個，覺得很好

4、數據架構的目的

在第一節【什么是架構】中，我們提煉了架構的第三個關鍵詞是“完成整體所需的目標”。

那么數據架構的目的是什么？

數據架構的目的是讓數據中臺加工好的數據，能夠更加高效、順暢的使用。

如果架構設置的不合理，數據能不能用，答案一定是可以的。數據都在，多關聯幾次，增加一些邏輯，可能最終結果也能實現。

如果架構合理那，就不需要復雜的關聯，可以快速的獲取到需要的數據，節省資源，提升效率，讓數據的運轉更加高效、順暢。

而且，不合理的架構，在效率提升、風險隔離、持續演進，這些好架構能夠獲得的優點，也都不存在了。

5、數據模型設計--如何有效切分

業務本身是復雜的，如何對這個復雜的業務進行切分，其實就是一個數據模型設計的過程，也就是數據建模的過程。

之前在五大維度【業務篇】中介紹了建模的四個步驟，第一步就是：確定業務流。

這個業務流切分最好做到，高內聚，低耦合。

高內聚的目的就是為了專業化，這樣子業務域的運作效率就高，松耦合的目的是子業務域之間的溝通成本最好低一點，這樣整體的運作效率就越高。

至于，如何做到“高內聚，低耦合”，就需要基于對業務的了解，不同的人有不同的劃分形式了。

6、數據流轉關系--如何有效流轉

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

1、明確數據實體在哪個源頭產生。這個確定數據在哪個源頭，我們在【數據源】模塊介紹的時候，也說過。 2、數據實體出現在業務流的哪個環節 3、數據實體出現在哪個流轉系統

在模型層面，如果想讓數據有效流轉，還有一點比較關鍵就是粒度的選擇，確定好不同劃分的部門的粒度，才能確保數據的順暢關聯流動。

7、數據架構和業務需求的先后關系

上面說了那么多數據架構的好處，但是回到實際中，馬上會讓你有一種“理想很豐滿，現實很骨感”的感覺。

我們理想的狀態是，對業務數據進行一個完整的數據架構設計，模型設計完整合理，數據流轉方便高效，實際上這里面有兩個變量。

第一個變量：業務的變化

假如我們做好了數據架構，先不說是一個完整的數據架構還是局部的。此時業務大調整。原本的業務數據庫里面的數據記錄邏輯都調整了。這時候，架構怎么辦？再調整架構。業務再變那？這就變成一個永遠追逐的過程了。

應對這個變量沒有什么好辦法。只能說數據架構適用于業務相對穩定，系統不會有大調整的公司。如果是新興公司，就不要提穩定架構了。
第二個變量：需求的先后

拋開第一點變量，假設我們業務穩定了，就可以完全做一個全局的數據架構了嗎？

這時候就又有一個需求先后的變量，或者說投入產出的問題。

建立完整的全局數據架構一定是耗時、耗力的。這么大的消耗暫時沒有需求，而且也不明確什么時候能有需求。而完全按照需求來一個，做一個那？那么勢必會將模型做的比較零散。

應對這個問題，個人認為就是先將核心的業務進行完整建模，邊緣的業務隨著需求來不斷的增加。這個過程需要架構足夠強壯，也需要建模發布有完善的審核流程。

8、五大維度說明

組織：

組織需要注意的是，一個領域的數據架構，需要有一個領域的審核，確定新的數據模型能夠合理。這個角色一般也是數據BP來負責。
政策：

政策主要是需要讓業務部門能夠配合數據中臺的人進行業務的了解和梳理。明確業務流程，和表對應關系等等信息。為架構設計提供業務信息。
工具：

搭建架構的過程就是一個建模的過程。雖然市面上又各種建模工具，但是個人認為沒有紙筆+Excel好用。

可能也是我在做數倉建模的時候，主要就是按照這種形式來的。沒有辦法想象出來一個更好的工具了，看這就是局限性。沒有辦法知道，自己不知道的東西。

數據建模的過程就是業務信息梳理的過程，梳理業務之后的四步建模：條線劃分，粒度選擇、維度確認、事實確認。以及不同模型間的數據流轉，等等信息都以個人經驗，線下文檔等形式保留。數據庫表都是最終產物，中間的過程沒有記錄，一方面沒有辦法做知識沉淀，知識誰人走，很容易變成從頭再來。另一方面，沒辦法有效升級迭代。所以，需要有一個系統將這些數據中臺的潛在的巨大信息、知識能夠給保留、記錄出來。供后續的學習，以及架構升級做參考。
業務：

“數據是業務的映射”。將已經被打散的數據，重新映射會業務，首先需要知道，你的業務是什么樣子，所以在數據架構，這個模塊，業務的理解是尤為重要的。沒有深入的業務理解，自然也就不會有好的模塊切分。沒有好的模塊切分，模塊間的流轉關系也就不會自然順暢了。
數據：?在架構領域，就不像前兩個模塊【數據源】【數據目錄】一樣完全不需要了解數據。這里就需要對數據進行探查，關聯了。因為在數據流轉過程中，需要能夠明確流轉是的關聯關系是否合理。