數據架構就像常規架構一樣。在這兩個領域，都應該遵守良好架構的基本原則。當然，有些設計適用于廣泛的應用程序和其他更小眾的設計，但無論結構的確切性質如何，你可以打賭，如果它是成功的，建筑師會厭煩牢記要點。

什么是數據架構？

數據架構可能會變得復雜。但是沒有必要馬上把這個復雜化。大多數架構方法都是從基礎開始的，這就是我們要在這里闡述的內容。數據架構可以描述為實體如何組織其數據。

這包括三個方面：

• 數據是如何存儲的？
• 數據是如何處理的？
• 數據如何使用？

我們將看到這些問題出現在數據架構問題中，有時會同時出現兩個或所有三個問題。但是，為了依次處理每一個問題，存儲包括準確性、訪問、控制和可擴展性等因素。這是原始數據的“數據湖”。處理包括安全性、與外圍資源之間的數據傳輸以及靈活性。處理后的數據形成“數據倉庫”。

用途包括接口、數據共享和應用程序。有些公司對數據架構的這三個方面有非常正式的方法，有些則更少。但是所有公司都應該以某種方式覆蓋它們。這樣，他們可以確保數據管理得到應有的優先級。

這就是對數據粗心大意的處罰（2021 年，因數據泄露而被判有罪的美國公司的平均罰款為 424 萬美元），這是組織對自己、客戶和任何聯系人的責任數據。數據是寶貴的，因此企業需要將其視為資本，如果不是更高的話。我們將首先轉向這種對數據的必要尊重。

1. 數據文化

對于任何范式轉變，如果您想要進行重大變革，那么孤立地關注公司的一個方面是沒有好處的。例如，工作場所的性別歧視正在受到挑戰（盡管速度很慢），但并非只專注于招聘或任何其他單一領域。為了確保所需的根本和分支變化，有必要解決工作場所的整個環境和心理問題。換句話說，它的文化。

與數據完全相同。必須優先考慮數據問題，這是通過讓每個人都遵守數據信條來賦予的。數據不再只是數據科學家的專利。

這是描述這一點的一種方式：

公司犯的最大錯誤之一是招募數據員工團隊，給他們一個配備所有最新設備的高檔辦公室，然后坐下來，認為數據工作已經完成。問題是，您的新部門正在為您處理的數據將被許多其他人訪問，包括內部團隊和公司以外的人。如果其他人不那么注意數據問題，您可能會遇到麻煩。

這些其他人最終可能會將數據傳播給無權訪問它的人。我們已經提到了數據安全和訪問治理價值的重要性。幾乎同樣糟糕的是，他們可能不會將它提供給需要它的人，并且工作流程可能會受到影響。

所有員工都有責任確保數據絕對到達需要它的每個人，絕對沒有其他人。您的工作是將這一點灌輸給他們，以便他們開始看到有價值商品的數據，而不僅僅是可能會或可能不會被誰知道誰搶奪的東西。分享的需要引導我們得出下一個原則。

2. 整理數據

因此，員工應該在任務需要的地方相互提供數據。但它比這更進一步。應該注意讓數據以同樣的方式為每個人服務。其中一個非常突出的方面是指標。特定指標在營銷中的含義應與對銷售團隊的含義相同。必須有一個共同的詞匯，沒有晦澀的辦公室方言。

假設業務的兩個部分使用相似的數據，但一個只處理月度數據，而另一個只處理周度數據。如果可能的話，應該努力統一他們的數據，以便更容易和更快地進行有意義的比較和關系評估。跨部門對特定數據代表什么以及它引導組織的方向達成的共識越多，您的企業就越能從聯合部門的聯合思維中受益。

首先，在分享方面，您優秀的數據專家可能需要一點鼓勵。通常情況下，數據工作人員可以將自己視為監護人，而他們應該真正將自己視為促進者。這種便利的一部分歸結為減少行話。在這方面，從真正意義上講，應該努力讓每個人都說一種共同的語言。

最后一點：確保您公司的數據的組織方式能夠保護其可訪問性。例如，嘗試使其免受斷電的影響，以便優化正常運行時間并保護客戶使用您的服務的能力。

3. 避免供應商鎖定

供應商鎖定是當您獲得一項技術時發生的情況，由于它不容易從您的架構中換出，您最終會被卡住。例如，當一家公司從一系列托管 PBX 提供商中進行選擇時，它應該尋找一條簡單的退出路線，就像一個誘人的入口一樣。否則，它的通信可能由未來發展可能被證明不適合的服務運行。

因此，任何技術采購都需要著眼于未來。您需要考慮的不僅僅是這項技術在成為您業務的一部分時可以做出什么貢獻。您需要考慮如何通過輕松拋棄它來做出貢獻。

4. 安全

您如何將確保合法訪問的需求與阻止未經授權的訪問的需求結合起來？數據架構通過根據數據項對其進行分類來確保這一點。敏感度以及誰可以訪問它們。以托管聯絡中心軟件為例，將制定一項規定，以確保只有那些有明確和允許使用該信息的目的的人才能訪問客戶詳細信息。

例如，醫療保健數據架構將確保僅用于宏觀分析的任何數據都將被匿名化。數據架構將列出隱私控制保證機密性的方法。可以在數據架構中構建多層安全性，以確保數據在任何階段都不會受到攻擊，無論是在存儲、處理還是應用程序中。

這是一個來自傳統建筑領域的有趣統計數據，發現一半的受訪建筑師因擔心數據安全而不愿使用他們的 BIM（建筑信息模型）團隊軟件。因此，很多有價值的合作并沒有發生，因為參與其中的員工感覺環境不夠安全。您需要提供這種安全性。

5. 成為更出色的數據策展人

現在到處都有更多的數據。有時我們幾乎沉浸在其中。當它處于原始和/或雜亂無章的狀態時，數據的有用性可能會受到損害。在達到其功效潛力之前，需要進行一定的梳理。

例如，我們擁有的電視比我們知道的要多得多。有時，剛開始決定當晚要看什么可能會令人困惑。這就是為什么電視服務通常具有策展人模式的原因，根據之前的觀看和其他數據，某些電影或連續劇被突出顯示為觀眾可能更可能感興趣。

觀眾可能會或可能不會根據其建議接受服務。如果他們決定不這樣做，他們幾乎肯定會通過查看各種節目分組來尋找其他材料——戲劇、驚悚片、科幻片等。這是另一層策展，稱為分類法。

對于工作場所的數據，同樣的原則也適用。為確保為您的員工提供最適合其任務的材料，數據架構必須使信息以易于理解和易于訪問的模式顯示。精選數據必須對業務用戶有所幫助，因此應定期進行質量檢查。出于這個原因，數據架構應該包括測試自動化的最佳實踐。

6. 靈活

商業中有一個不變的東西：變化。您對它的期望越高，甚至接受它，您的業務就會表現得越好。考慮到這一點，您實施的任何數據架構都應該具有輕松發展的潛力。例如，模塊化就受到高度重視，它使組織有機會更新系統而無需大規模更換系統。

另一個靈活性領域在于員工訪問數據的方式。將您的數據架構設計為允許多種格式的訪問請求是有意義的。這樣，您的系統將能夠處理例如非結構化的電子郵件以及結構化的 CSV 文件。這種應對非技術人員投入的能力將消除對可能耗時且昂貴的培訓的需求。

7. 減少數據副本

您的數據架構應以減少不斷復制數據的需要的方式安排。生產無休止的數據副本在處理空間和財務方面都是浪費的。這本身也是一種安全風險。數據虛擬化可以消除傳輸和復制數據的需要。使用 Azure Synapse Analytics 等工具，無需傳輸即可對所有數據運行查詢。

8. 反向 ETL

您可能已經知道 ETL 是什么。以防萬一，ETL（或提取、轉換、加載）是創建企業數據倉庫的常用方法。它是一種將來自多個來源的數據組合成一個連貫整體的方法。

因此，反向 ETL 是一種從數據倉庫中獲取數據并更改其格式的方法。為了使數據與來自 Salesforce、Hubspot 或 Marketo 等第三方來源的應用程序兼容，需要將其從存儲位置取出并轉換為更合適的形狀。

因此，您的數據架構必須允許這樣做。有一些反向 ETL 工具已預先安裝了 API 集成，從而簡化了使用和維護。但是，即使您不使用實際的反向 ETL，您也必須意識到需要一個流程，通過該流程可以訪問數據以供各種應用程序使用。應根據業務的性質和所存儲的數據實現標準化接口，例如 SQL、RESTful API 或 OLAP。這種標準化將確保檢索到的數據以可預測并因此立即可用的格式到達。

9. 攝取問題

您的攝取工具是將數據從攝取堆棧加載到數據倉庫的方法。這些數據將以多種形式來自大量來源，因此您的數據架構需要一個可以處理盡可能多的攝取工具。

與許多單一來源的攝取工具相比，擁有一些通用的攝取工具更好。必須在工具之間進行交換會浪費時間，并且會影響您的數據性能。因此，您需要做的是確定您需要支持哪些攝取形式，例如 FTP、Batch、CDC、API），并確保您的數據架構是圍繞可以處理它們的攝取工具構建的。

10. 數據發現

您的數據架構中應該包含自動數據發現會話的規定。這可以揭示有趣且有價值的數據模式，并突出顯示應用程序可以在哪些方面進行更新。例如，云電話系統應執行定期數據發現掃描，以檢查過時或沖突的個人信息。

結論

因此，數據架構主要是關于確保您已經考慮過您的信息持有結構。它是否具有符合要求的輸入方式？輸出格式是否符合您的業務需求？任何系統規劃方法都必須包括這些問題的答案。

回到我們最初的存儲、處理和使用模式，很明顯，您的數據架構的大多數部分影響的不僅僅是這些領域中的一個。在這方面，良好的數據架構通常與良好的操作系統設計有很多共同之處。雖然通過分解事物進行分析通常很好，但有時必須有一個整體的觀點才能看到結構是如何工作的。這種觀點將對數據架構帶來好處。