隨著大數(shù)據(jù)和數(shù)據(jù)湖的發(fā)展，數(shù)據(jù)建模似乎瀕臨滅亡。數(shù)據(jù)湖的開發(fā)者留下了大量數(shù)據(jù)沼澤，所以建?；顒舆€是必須的。那么為什么仍然存在關(guān)于數(shù)據(jù)建模的問題呢？當(dāng)然有各種各樣的原因。有些問題至少已有 30 年歷史，而最近人們更加認(rèn)為使用云數(shù)據(jù)平臺和分析數(shù)據(jù)架構(gòu)的 ELT 方法所致。下面我們看看常見的阻礙數(shù)據(jù)建模的原因：

1缺乏興趣——企業(yè)真的不在乎

盡管 CIO 和 CEO 宣傳“數(shù)據(jù)驅(qū)動”，但對于某些企業(yè)而言，數(shù)據(jù)的管理和利用并沒有放在主要日程上，至少在高層是這樣。這可能是可以理解的——并非每個企業(yè)都是“數(shù)據(jù)企業(yè)”；數(shù)據(jù)可能很重要，但僅在特定的獨立領(lǐng)域內(nèi)使用。有些組織從事采購和銷售產(chǎn)品、提供法律顧問等行業(yè)，這并不是說他們不使用數(shù)據(jù)，而是，就目前而言即使使用 Excel 這種處理工具也滿足使用了。

這可能發(fā)生在傳統(tǒng)的組織中，可能發(fā)生在行業(yè)領(lǐng)軍企業(yè)，也可能發(fā)生在技術(shù)初創(chuàng)企業(yè)中，在這些組織中，良好的數(shù)據(jù)是運營次要考慮因素。

解決方案：除非組織遭受足夠多的數(shù)據(jù)相關(guān)痛苦，或者高級管理層選擇支持戰(zhàn)略性數(shù)據(jù)支持業(yè)務(wù)方法，否則數(shù)據(jù)建模以及治理和其他數(shù)據(jù)內(nèi)容將主要在項目級別完成，以實現(xiàn)本地目標(biāo)。

2 缺乏“全局”——沒有全面的業(yè)務(wù)數(shù)據(jù)模型

數(shù)據(jù)建模通常被視為支持運營和分析產(chǎn)品開發(fā)的詳細活動，從數(shù)據(jù)策略中刪除，并且僅作為詳細業(yè)務(wù)分析的一部分影響業(yè)務(wù)用戶。但是，如果沒有組織數(shù)據(jù)分布的高級地圖，公司如何“數(shù)據(jù)驅(qū)動”，或者業(yè)務(wù)領(lǐng)域如何就數(shù)據(jù)所有權(quán)和責(zé)任達成一致？CDO 應(yīng)該如何合理跨越多個應(yīng)用程序或孤島的數(shù)據(jù)，每個應(yīng)用程序或孤島都有相互獨立的目標(biāo)，成為“客戶”的真正來源，或者了解特定數(shù)據(jù)流的原因？

90年代的情況是龐大、詳細的 3NF“企業(yè)數(shù)據(jù)模型”，通常會運行到 100 或 1000 個實體。有時，這是為特定行業(yè)“現(xiàn)成”購買的，但隨后需要在企業(yè)內(nèi)部進行驗證和調(diào)整。毫不奇怪，這些做法通常會陷入困境，被更緊迫的業(yè)務(wù)優(yōu)先事項所取代。

解決方案：高級“業(yè)務(wù)數(shù)據(jù)建?！被颉案拍顢?shù)據(jù)建?！钡乃囆g(shù)已經(jīng)存在超過 15 年。在經(jīng)驗豐富的從業(yè)者手中，對于中型企業(yè)或部門，應(yīng)該可以在 1-3 個月內(nèi)制作出良好的初稿，包括與企業(yè)所有部門的適當(dāng)互動。通常，這可以與針對更多高級管理人員和員工的數(shù)據(jù)素養(yǎng)練習(xí)一起完成。隨著從一個業(yè)務(wù)域更詳細的數(shù)據(jù)工作引發(fā)對概念或全新概念的差異化的需求，可以改進和擴展這樣的模型。

從“頂層”開始數(shù)據(jù)建模本身就非常有用，這是組織數(shù)據(jù)處理方法的基礎(chǔ)。

3數(shù)據(jù)作為應(yīng)用程序完成或事后的想法

盡管許多應(yīng)用程序產(chǎn)生并依賴于數(shù)據(jù)，但一直存在一種趨勢，尤其是程序開發(fā)中，忽視數(shù)據(jù)建模，而不是應(yīng)用程序設(shè)計中首要事情。這尤其體現(xiàn)在兩個方面：

a) 使用第三方程序加速業(yè)務(wù)能力

許多應(yīng)用程序都有自己的數(shù)據(jù)模型，該模型存在于“要么接受要么放棄”的基礎(chǔ)上——您可以調(diào)整數(shù)據(jù)需求，以適應(yīng)應(yīng)用程序的數(shù)據(jù)模型。另一方面，其他應(yīng)用程序積極鼓勵業(yè)務(wù)用戶進行本地定制，而不考慮數(shù)據(jù)模型是否真的有意義。

更廣泛的集成問題可能會被擱置一旁，只要應(yīng)用程序可以獲取或交換數(shù)據(jù)以滿足即時需求，也許是通過 API。一些應(yīng)用程序甚至積極阻止在其自身環(huán)境之外提取數(shù)據(jù)。

解決方案：僅購買能夠提供清晰數(shù)據(jù)模型和/或用于分析目的的精心構(gòu)建的提取/數(shù)據(jù)共享選項的應(yīng)用程序。建議將這部分作為采購必要條件，而不僅僅是“是/否”的回答。

b) 內(nèi)部應(yīng)用程序開發(fā)人員將數(shù)據(jù)建模視為事后的想法

這是企業(yè)內(nèi)部的問題，開發(fā)人員通常在時間壓力下工作，向內(nèi)部或外部用戶提供數(shù)據(jù)展示，這些用戶對數(shù)據(jù)的存儲方式?jīng)]有直接興趣。

解決方案：數(shù)據(jù)建模師應(yīng)該是任何應(yīng)用程序團隊的核心部分。數(shù)據(jù)模型初稿通常應(yīng)該是開始第一個真正的敏捷開發(fā)的先決條件。將產(chǎn)生的數(shù)據(jù)供下游使用，無論是出于操作目的還是分析目的，都應(yīng)該是整體框架的一部分。這是數(shù)據(jù)驅(qū)動開發(fā)的最佳實踐，數(shù)據(jù)網(wǎng)格模式強烈建議這種做法。

4 效率問題——建模只會減慢速度

模型就是這樣——對現(xiàn)實世界的簡化。在進行數(shù)據(jù)建模的情況下，通常會捕獲一些隱式規(guī)則和關(guān)系，希望能夠適應(yīng)企業(yè)管理其現(xiàn)實世界交互的方式。

90 年代的關(guān)系建模被認(rèn)為太慢了，識別實體、關(guān)系和屬性的視圖通常被業(yè)務(wù)變化和新數(shù)據(jù)源所取代，并且在捕獲和傳輸在線事件時未能增加價值。隨著組織從生產(chǎn)純物理產(chǎn)品轉(zhuǎn)向更多數(shù)字產(chǎn)品，定期更改成為常態(tài)，建模被視為阻礙或與保持最新所需相沖突。

解決方案：在在線應(yīng)用程序中，半結(jié)構(gòu)化“文檔模型”方法提供了事件封裝和可擴展模式的一定程度的靈活性。使用此類結(jié)構(gòu)的最佳實踐隱含地承認(rèn) 3NF 分析的原則。分析數(shù)據(jù)平臺轉(zhuǎn)而提供對 JSON 等格式的本地支持，并具有不同程度的承諾。

在分析領(lǐng)域，Data Vault 方法通過歸納關(guān)鍵實體之間的關(guān)系、識別來源的多樣性和高變化概率以及構(gòu)建歷史記錄來提供敏捷性。

數(shù)據(jù)網(wǎng)格建議將大部分建模留給本地域——盡管它也提倡雙時態(tài)建模方法，并談到需要通用標(biāo)準(zhǔn)、一種新的建模方法，甚至一種語言來實現(xiàn)跨域的“可組合性”。

最終，為用例或應(yīng)用構(gòu)建正確類型的模型是成功的最佳秘訣，無論是文檔、3NF、Data Vault 還是維度。雖然建模首先是一項邏輯活動，在底層數(shù)據(jù)平臺中支持一系列具有良好性能的數(shù)據(jù)建模方法可以顯著簡化邏輯到物理的映射。

5 直接獲取數(shù)據(jù)——數(shù)據(jù)沼澤遺留問題

雖然大數(shù)據(jù)運動是由互聯(lián)網(wǎng)生成的龐大數(shù)據(jù)驅(qū)動的，但它也是對復(fù)雜性和數(shù)據(jù)變化率問題的回應(yīng)。隨著一些組織開始通過利用一切數(shù)據(jù)產(chǎn)生巨大收益，人們越來越不愿意丟棄任何數(shù)據(jù)。而且數(shù)據(jù)湖從業(yè)者認(rèn)為，建模已經(jīng)過時了?，F(xiàn)在，當(dāng)連接大型數(shù)據(jù)集或多表模型的數(shù)據(jù)很痛苦時，創(chuàng)建大量非規(guī)范化數(shù)據(jù)集的動力就非常強烈，通常會導(dǎo)致大量重復(fù)。對數(shù)據(jù)安全的忽視也進一步助長了這一趨勢。

受此經(jīng)驗的影響，基于云的“現(xiàn)代數(shù)據(jù)堆棧”中出現(xiàn)的兩個互補趨勢出現(xiàn)了一些阻力：“廉價”存儲和“轉(zhuǎn)換(ELT) 模式”。

許多云數(shù)據(jù)平臺參與者至少在某種程度上將存儲與計算分開。云對象存儲具有彈性且相對成本低。大量數(shù)據(jù)出于未知原因被保留，原始數(shù)據(jù)或建模不佳的數(shù)據(jù)被直接使用并且從未正確集成。雖然存儲很便宜，但不斷增長的數(shù)據(jù)量推高了按消費定價的計算，使平臺提供商有鼓勵客戶不要在乎數(shù)據(jù)建模。

這筆費用不能完全回避——即使是廉價存儲的數(shù)據(jù)有時也應(yīng)該被刪除，無論是為了減少混亂、降低濫用風(fēng)險還是讓地球更輕盈。

許多組織已經(jīng)轉(zhuǎn)向分層數(shù)據(jù)建模方法，其中第一層采用“原始”數(shù)據(jù)，無論是直接匹配 OLTP 系統(tǒng)上的表格，還是未經(jīng)提煉的 JSON Web 和 IoT 日志。這種 ELT 模式并不新鮮，例如在 Teradata 等平臺上的數(shù)據(jù)倉庫模式和實施中很常見，已有十年或更長時間。理想的目標(biāo)是原始層饋送到更多層，通常是反映某些規(guī)范模型（例如 3NF 或 Data Vault）的一致性層和針對最終用戶的表示或交付層（通常按維度建模）。

將數(shù)據(jù)保存更長時間是有正當(dāng)理由的——監(jiān)管（證明你五年前所做的是合法的）、網(wǎng)絡(luò)安全（攻擊模式可以發(fā)展數(shù)月）、數(shù)據(jù)科學(xué)和長期分析（將原始數(shù)據(jù)轉(zhuǎn)化為新功能）、或者僅僅是利用直接的內(nèi)置歷史從舊數(shù)據(jù)重構(gòu)下游新產(chǎn)品的能力。與此相反的是隱私法規(guī)和違規(guī)風(fēng)險，以及將半衰期短的數(shù)據(jù)保存太久的環(huán)境成本。最終，這又回到了數(shù)據(jù)所有權(quán)和“為什么”的問題上。

解決方案：僅僅因為可以忽視，并不意味著應(yīng)該這樣。具有可靠治理、良好的數(shù)據(jù)高級模型和可靠數(shù)據(jù)架構(gòu)的組織可以受益于更便宜的存儲和易于使用的平臺支持的數(shù)據(jù)底座和轉(zhuǎn)換模式。不急于對數(shù)據(jù)進行詳細的過度建模并在其價值確定之前花費大量的計算周期和工程師時間進行轉(zhuǎn)換可能是有價值的。

同樣，讓我們現(xiàn)實地看待數(shù)據(jù)的“半衰期”，尤其是原始數(shù)據(jù)——很少有法規(guī)要求保留超過 7 年的歷史，而 ML 模型則更少，除非著眼于長期的事件。您的數(shù)據(jù)平臺在捕獲依賴關(guān)系和訪問歷史記錄方面有多好？這有助于識別那些從未或很少使用的數(shù)據(jù)集，并避免因擔(dān)心下游后果而保留數(shù)據(jù)。

總之…

就像數(shù)據(jù)中的許多好東西一樣，良好的建模源于組織承諾、適當(dāng)應(yīng)用良好實踐和模式的技能、精心設(shè)計的流程以及設(shè)計師的優(yōu)秀技能。在大多數(shù)數(shù)據(jù)平臺上，不進行建模是災(zāi)難性的。

審核編輯：郭婷