在大數據和數據科學的新時代，企業擁有一個與業務流程保持一致的集中式數據架構至關重要，該架構可以隨著業務增長而擴展，并隨著技術進步而發展。一個成功的數據架構可以清晰地展示數據的各個方面，從而使數據科學家、數據分析師、業務人員能夠高效地處理可信賴的數據并解決復雜的業務問題。它還使組織能夠通過利用新興技術快速應對新的商業機會，并通過管理整個企業的復雜數據和信息交付來提高運營效率。

與信息架構、系統架構和軟件架構相比，數據架構相對較新。數據架構師的角色也一直模糊不清，落在了高級業務分析師、ETL 開發人員和數據科學家的肩上。盡管如此，Data Architect 主要指那些為組織設計數據架構的數據管理專業人員。

在談論架構時，我們通常會想到與建筑架構的類比。傳統的建筑架構師計劃、設計和審查建筑物的建造。設計過程涉及與客戶合作以充分收集要求，了解當地的法律和環境限制，并與工程師、測量師和其他專家合作以確保設計切合實際并在預算范圍內。這項工作的復雜性確實與數據架構師的角色非常相似。但是，這兩個架構師角色之間存在一些根本差異：

• 建筑架構是自上而下設計的，而數據架構通常是可能已經存在的組件或系統的集成過程。
• 建筑架構師在建造建筑之前必須了解全部要求并定義整個范圍。數據架構的范圍可以很廣并且很容易改變。因此，一個成功的數據架構應該被設計成靈活的并且能夠預測未來的變化。
• 建筑架構師具有精確的教育和專業要求，應具備商業、藝術、結構物理和建筑材料方面的深入知識。大多數數據架構師來自 IT 背景，在少數公司或行業擁有專業經驗，對業務的接觸有限。因此，他們應該意識到他們的設計可能存在偏差，并且他們需要根據組織中業務和技術專業知識的反饋對其進行調整。
• 建筑設計幾乎總是針對從頭開始建造的新建筑。因此，建筑設計師可以完全根據新要求和新材料進行規劃和設計。數據架構師沒有這種奢侈。他們很少能從頭開始，而是在為未來設計時需要了解現有的平臺和數據庫。

盡管有這些差異，數據架構師仍然可以向建筑架構師學習，特別是采用他們自上而下的方法來改進數據架構設計。在許多組織中，一直缺乏系統的、集中的、端到端的數據架構設計。下面列出了一些主要原因：

• 一家公司有多個 IT 部門，他們使用自己的數據標準和架構在孤島中工作。
• 應用程序和流程是根據個人業務需求構建的，沒有可遵循的數據架構標準。
• 數據架構師的角色只關注有限的技術領域，并且數據業務知識有限。
• IT 項目的管理沒有將數據架構作為設計階段的一部分；數據科學家和工程師在沒有一致的數據管理流程的情況下按照自己的方式進行編碼。

由于存在這些不足，我們經常會看到一家公司的數據系統脫節，團隊和部門之間存在差距。這些差異導致系統性能不佳，有很多交接，出現生產數據問題時需要很長時間進行故障排除，缺乏跨系統達成正確解決方案的責任感，以及缺乏評估影響的能力變化。最后，當遷移或重新設計到下一代平臺時，脫節的系統可能會導致分析和研究的巨大努力。

鑒于所有這些，一個成功的企業需要有一個基于業務流程和操作設計的自上而下的連貫數據架構。特別是，就像建筑架構師所做的那樣，企業數據架構師需要先在概念和邏輯層面構建藍圖，然后再將技術應用到詳細的應用程序設計和實現中。

1. 基于業務流程和運營的概念級數據架構設計

在現代 IT 中，業務流程由數據實體、數據流和應用于數據的業務規則來支持和驅動。因此，數據架構師需要具備深入的業務知識，包括財務、營銷、產品以及業務流程的行業特定專業知識，例如健康、保險、制造商和零售商。然后，可以通過設計代表每個業務領域的數據實體和分類法以及業務流程下的數據流，在企業級別正確構建數據藍圖。特別是，在這個概念階段需要考慮和規劃以下領域：

• 核心數據實體和數據元素，例如有關客戶、產品、銷售的數據。
• 客戶和顧客需要的輸出數據。
• 要收集和轉換或引用以生成輸出數據的源數據。
• 每個數據實體的所有權以及如何根據業務用例使用和分配它。
• 應用于每個數據實體的安全策略。
• 數據實體之間的關系，如引用完整性、業務規則、執行順序。
• 標準數據分類和分類法。
• 數據質量、操作和服務水平協議 (SLA) 的標準。

此概念設計級別由支持每個業務功能的底層數據實體組成。藍圖對于企業和系統架構的成功設計和實施及其未來的擴展或升級至關重要。在許多組織中，這種概念設計通常嵌入到由單個項目驅動的業務分析中，而沒有從企業端到端解決方案和標準的角度進行指導。

2. 邏輯層數據架構設計

通過考慮使用哪種類型的數據庫或數據格式，這種設計級別有時稱為數據建模。它將業務需求連接到底層技術平臺和系統。然而，考慮到數據建模者的孤立角色，大多數組織只在特定的數據庫或系統中設計數據建模。一個成功的數據架構應該通過綜合方法開發，考慮適用于每個數據庫或系統的標準，以及這些數據系統之間的數據流。特別是以下5個領域需要協同設計：

命名約定和數據完整性

數據實體和元素的命名約定應該一致地應用于每個數據庫。此外，如果相同的數據必須駐留在多個數據庫中，則應強制執行數據源及其引用之間的完整性。最終，這些數據元素在數據架構的概念設計中應該屬于一個數據實體，然后可以根據業務需求進行協同和準確的更新或修改。

數據歸檔/保留政策

數據歸檔和保留策略往往直到生產的每個后期才考慮或建立，這造成了資源浪費、不同數據庫之間的數據狀態不一致以及數據查詢和更新性能不佳。為了加強數據完整性，數據架構師應根據操作標準在數據架構中定義數據歸檔和保留策略。

隱私和安全信息

隱私和安全成為邏輯數據庫設計的重要方面。雖然概念設計已經定義了哪些數據組件是敏感信息，但邏輯設計應該在數據庫中保護機密信息，并通過有限訪問、受限數據復制、特定數據類型和安全數據流來保護信息。

數據復制

數據復制是實現三個目標需要考慮的一個關鍵方面：1) 高可用性；2) 避免數據通過網絡傳輸的性能；3) 解耦以最小化對下游的影響。但是，過多的數據復制會導致混亂、數據質量差和性能差。任何數據復制都應由數據架構師檢查并應用原則和紀律。

數據流和管道

數據如何在不同的數據庫系統和應用程序之間流動應該在這個層次上被明確定義。同樣，此流程與業務流程和數據架構師概念級別中說明的流程一致。此外，數據攝取的頻率、管道中的數據轉換以及針對輸出數據的數據訪問模式應在邏輯設計的集成視圖中加以考慮。例如，如果上游數據源是實時進來的，而下游系統主要用于聚合信息的數據訪問，索引繁重（例如，頻繁更新和插入的代價高昂），則需要在兩者之間設計數據管道以優化性能。

3. 數據治理是數據架構持續成功的關鍵

由于數據架構反映并支持業務流程和流程，因此只要業務流程發生變化，它就會發生變化。隨著底層數據庫系統的改變，數據架構也需要調整。因此，數據架構不是靜態的，而是需要持續管理、增強和審計。因此，應采用數據治理來確保在啟動每個新項目時正確設計和實施企業數據架構。

結論

在成功的數據架構中，基于業務流程的概念設計是最重要的組成部分，其次是強調所有數據庫和數據管道的一致性、完整性和效率的邏輯設計。建立數據架構后，組織可以查看哪些數據駐留在何處，并確保數據安全、高效存儲和準確處理。此外，當一個數據庫或組件發生變化時，數據架構可以讓組織快速評估影響并指導所有相關團隊進行設計和實施。最后，數據架構是企業系統的實時文檔，保證是最新的，并提供清晰的端到端視圖。