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

什么是數據架構？

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

這包括三個(gè)方面：

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

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

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

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

1. 數據文化

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

與數據完全相同。必須優(yōu)先考慮數據問(wèn)題，這是通過(guò)讓每個(gè)人都遵守數據信條來(lái)賦予的。數據不再只是數據科學(xué)家的專(zhuān)利。

這是描述這一點(diǎn)的一種方式：

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

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

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

2. 整理數據

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

假設業(yè)務(wù)的兩個(gè)部分使用相似的數據，但一個(gè)只處理月度數據，而另一個(gè)只處理周度數據。如果可能的話(huà)，應該努力統一他們的數據，以便更容易和更快地進(jìn)行有意義的比較和關(guān)系評估?？绮块T(mén)對特定數據代表什么以及它引導組織的方向達成的共識越多，您的企業(yè)就越能從聯(lián)合部門(mén)的聯(lián)合思維中受益。

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

最后一點(diǎn)：確保您公司的數據的組織方式能夠保護其可訪(fǎng)問(wèn)性。例如，嘗試使其免受斷電的影響，以便優(yōu)化正常運行時(shí)間并保護客戶(hù)使用您的服務(wù)的能力。

3. 避免供應商鎖定

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

因此，任何技術(shù)采購都需要著(zhù)眼于未來(lái)。您需要考慮的不僅僅是這項技術(shù)在成為您業(yè)務(wù)的一部分時(shí)可以做出什么貢獻。您需要考慮如何通過(guò)輕松拋棄它來(lái)做出貢獻。

4. 安全

您如何將確保合法訪(fǎng)問(wèn)的需求與阻止未經(jīng)授權的訪(fǎng)問(wèn)的需求結合起來(lái)？數據架構通過(guò)根據數據項對其進(jìn)行分類(lèi)來(lái)確保這一點(diǎn)。敏感度以及誰(shuí)可以訪(fǎng)問(wèn)它們。以托管聯(lián)絡(luò )中心軟件為例，將制定一項規定，以確保只有那些有明確和允許使用該信息的目的的人才能訪(fǎng)問(wèn)客戶(hù)詳細信息。

例如，醫療保健數據架構將確保僅用于宏觀(guān)分析的任何數據都將被匿名化。數據架構將列出隱私控制保證機密性的方法?？梢栽跀祿軜嬛袠嫿ǘ鄬影踩?，以確保數據在任何階段都不會(huì )受到攻擊，無(wú)論是在存儲、處理還是應用程序中。

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

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

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

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

觀(guān)眾可能會(huì )或可能不會(huì )根據其建議接受服務(wù)。如果他們決定不這樣做，他們幾乎肯定會(huì )通過(guò)查看各種節目分組來(lái)尋找其他材料——戲劇、驚悚片、科幻片等。這是另一層策展，稱(chēng)為分類(lèi)法。

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

6. 靈活

商業(yè)中有一個(gè)不變的東西：變化。您對它的期望越高，甚至接受它，您的業(yè)務(wù)就會(huì )表現得越好?？紤]到這一點(diǎn)，您實(shí)施的任何數據架構都應該具有輕松發(fā)展的潛力。例如，模塊化就受到高度重視，它使組織有機會(huì )更新系統而無(wú)需大規模更換系統。

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

7. 減少數據副本

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

8. 反向 ETL

您可能已經(jīng)知道 ETL 是什么。以防萬(wàn)一，ETL（或提取、轉換、加載）是創(chuàng )建企業(yè)數據倉庫的常用方法。它是一種將來(lái)自多個(gè)來(lái)源的數據組合成一個(gè)連貫整體的方法。

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

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

9. 攝取問(wèn)題

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

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

10. 數據發(fā)現

您的數據架構中應該包含自動(dòng)數據發(fā)現會(huì )話(huà)的規定。這可以揭示有趣且有價(jià)值的數據模式，并突出顯示應用程序可以在哪些方面進(jìn)行更新。例如，云電話(huà)系統應執行定期數據發(fā)現掃描，以檢查過(guò)時(shí)或沖突的個(gè)人信息。

結論

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

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