我們需要什么樣的數據架構？
在大數據和數據科學的新時代，對企業而言，一定要有與業務流程保持一致的中心化數據架構，該架構能隨業務增長而擴展，并隨技術進步而發展。
一個成功的數據架構可以使數據的各個方面清晰明了，從而使數據科學家能夠高效地處理可信的數據并解決復雜的業務問題。
架構還能幫助組織做好必要的準備，以利用新興技術迅速抓住新的商機，并通過管理整個企業中的復雜數據和信息交付來提高運營效率。
與信息架構、系統架構和軟件架構相比，數據架構相對較新。數據架構師的角色也很模糊，落在了高級業務分析師，ETL開發人員和數據科學家的肩膀上。盡管如此，在本文中，作者將用“數據架構師”(Data Architect)來指代那些為組織設計數據架構的專業數據管理人員。
說到架構，我們經常會想到與建筑架構做類比。傳統的建筑架構師會規劃、設計和審查建筑物的建造。設計過程包括與客戶充分溝通收集需求，了解當地的法律和環境限制，并與工程師、測量師及其他專家合作，以確保設計在預算之內可行。
這項工作的復雜性實際上與數據架構師的角色非常相似。但是，兩個架構師角色之間存在一些基本差異：
- 建筑物架構是自上而下的設計，而數據架構通常是將已存在的組件或系統集成。
- 建筑設計師在建造建筑物之前必須了解全部建筑要求并規劃建筑范圍。數據架構的范圍更為廣泛且易更改。因此，成功的數據架構設計應該是靈活的且有預見性的。
- 建筑架構師具有嚴格的教育和專業要求，并且應該在商業、藝術、結構物理和建筑材料方面有深入研究。而大多數數據架構師來自IT背景，在幾家公司或行業中具有專業經驗，并且對業務的接觸不多。因此，他們應該意識到自己的設計可能存在偏差，需要根據組織中業務和技術專家的反饋來調整設計。
- 建筑設計幾乎都是針對從頭開始建造的新建筑物的。因此，建筑架構師可以完全根據新要求和新材料進行規劃和設計。數據架構師沒有這種優勢。他們很少能從頭開始，但是在為未來進行設計時需要了解現有的平臺和數據庫。
雖然存在這些差異，但數據架構師仍然可以向建筑架構師學習，尤其是采用自上而下的方法來改進數據架構設計方面。很多機構都缺乏系統、集中的端到端的數據架構設計。下面列出了一些主要原因：
- 一個公司有多個IT部門，他們各自使用各自的數據標準和架構工作。
- 應用程序和流程是根據單個業務需求構建的，沒有可遵循的數據架構標準。
- 數據架構師的角色僅關注有限的技術領域，并且對數據業務知識的了解也有限。
- 管理IT項目時，在設計階段不考慮數據架構，數據科學家和工程師無需遵循一致的數據管理流程即可編寫代碼。
由于存在這些不足，所以我們經常會看到一家公司的數據系統脫節，并且團隊和部門之間存在差距。這些差異導致系統性能低下，需要進行大量交接工作，在生產數據出現問題時要花很長時間才能排除故障，缺乏在整個系統中找到正確解決方案的責任感，并且缺乏評估產品變化影響的能力。
最后，在遷移脫節的系統或重新設計下一代平臺時，可能要花費大量精力進行分析和研究。
考慮到所有這些因素，一個成功的企業需要具有以業務流程和運營設計為基礎的自上而下一致的數據架構。特別是，就像建筑架構師所做的那樣，企業數據架構師需要先在概念級和邏輯級構建藍圖，然后再將技術應用于詳細的應用程序設計和實現。
1.基于業務流程和運營的概念級數據架構設計
在現代IT中，業務流程是由數據實體，數據流和應用于數據的業務規則共同支持和驅動的。因此，數據架構師需要具有深入的業務知識，其中包括財務、市場營銷、產品以及業務流程(例如健康、保險、制造商和零售商)等特定行業的專業知識。
然后，他才能夠通過設計代表每個業務域的數據實體和分類法以及業務流程下的數據流，從而構建正確的企業級數據藍圖。在此概念階段尤其需要考慮和計劃以下幾個方面：
- 核心數據實體和數據元素，例如關于客戶、產品、銷售的數據。
- 客戶和顧客所需的輸出數據。
- 要收集、轉換或引用的源數據以生成輸出數據。
- 每個數據實體的所有權以及如何根據業務用例使用和分配它。
- 要應用于每個數據實體的安全策略。
- 數據實體之間的關系，例如參考完整性、業務規則、執行順序。
- 標準數據分類和分類法。
- 數據質量、操作和服務水平協議(SLA)的標準。
設計的概念級別由支持每個業務功能的基礎數據實體組成。藍圖對于成功設計和實施企業和系統架構及其未來的擴展或升級至關重要。
在很多機構中，這種概念設計通常被嵌入到由單個項目驅動的業務分析當中，而沒有從企業端到端解決方案和標準的角度進行指導的方法。
2.邏輯級數據架構設計
由于要考慮使用哪種類型的數據庫或數據格式，這種設計有時稱為數據建模。它將業務需求與基礎技術平臺和系統聯系到一起。但是，考慮到數據建模者的角色，大多數機構僅在特定數據庫或系統中設計數據建模。
通過考慮適用于每個數據庫或系統的標準以及這些數據系統之間的數據流，應采用集成方法開發成功的數據體系結構。特別是，以下五個領域需要以協同方式進行設計：
（1）命名約定和數據完整性
數據實體和元素的命名約定應一致地應用于所有數據庫。同樣，如果相同數據須駐留在多個數據庫中，則應加強數據源及其引用之間的完整性。最終，這些數據元素應屬于數據架構中概念設計中的數據實體，然后可以根據業務需求協同準確地對其進行更新或修改。
（2）數據歸檔/保留策略
如果在生產的最后階段才經常考慮或建立數據歸檔和保留策略的話，將會導致資源浪費，不同數據庫之間的數據狀態不一致，以及數據查詢和更新的表現不佳。為了加強數據完整性，數據架構師在以操作標準為基礎的數據架構中定義數據歸檔和保留策略。
（3）隱私和安全信息
隱私性和安全性成為了邏輯數據庫設計的重要考慮因素。雖然概念設計已經定義了哪個數據成分屬于敏感信息，但邏輯設計應在具有受限訪問權限、受限數據復制、特定數據類型和安全數據流的數據庫中保護機密信息，以保護信息安全。
（4）資料復制
數據復制是要顧及三個目標的關鍵因素：
1)高可用性。
2)避免通過網絡傳輸數據的性能。
3)低耦合性以最小化下游影響。
但是，過多的數據復制會導致混亂、數據質量差和性能下降的結果。任何數據復制都應由數據架構師檢查，并應遵循一定原則和紀律。
（5）數據流和管道
在此級別上，應明確定義數據在不同數據庫系統和應用程序之間的流動方式。同樣，此流程與業務流程和數據架構師概念級別中提到的流程一致。此外，應在邏輯設計的集成視圖中考慮數據攝取的頻率、流水線中的數據轉換以及針對輸出數據的數據訪問模式。例如，如果上游數據源是實時的，而下游系統主要被用于具有重索引的聚合信息的數據訪問(例如，對于頻繁更新和插入來說成本很高)，則需要在兩者之間設計數據管道，以優化性能。
持續治理是數據架構成功的關鍵
由于數據架構反映并支持著業務流程，因此當業務流程發生更改時，數據架構就可能會發生改變。隨著基礎數據庫系統的更改，數據架構也需要進行調整。因此，數據架構不是靜態的，而是需要進行連續管理、增強和審核的。因此，應采用數據治理來確保在啟動每個新項目時正確設計和實現企業數據架構。
結論
在成功的數據架構中，以業務流程為基礎的概念設計是最關鍵的要素，其次是邏輯設計，該邏輯設計強調所有數據庫和數據管道之間的一致性、完整性和效率。在建立起數據架構后，機構可以查看哪些數據駐留在何處，并確保數據的安全、有效存儲和正確處理。
同樣，當一個數據庫或組件發生更改時，數據架構可以幫助機構快速評估影響并指導所有相關團隊進行設計和實施。最后，數據架構是企業系統的實時文檔，要保證它是很新的，并提供清晰的端到端圖畫。
綜上所述，反映端到端業務流程和操作的整體數據架構對于保障公司在經歷重大變化(如收購、數字轉換或向下一代平臺遷移)時快速高效地前進至關重要。
