隨著大數據和數據湖的發展，數據建模似乎瀕臨滅亡。數據湖的開發者留下了大量數據沼澤，所以建模活動還是必須的。那么為什么仍然存在關于數據建模的問題呢？當然有各種各樣的原因。有些問題至少已有 30 年歷史，而最近人們更加認為使用云數據平臺和分析數據架構的 ELT 方法所致。下面我們看看常見的阻礙數據建模的原因：

1.缺乏興趣——企業真的不在乎

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

這可能發生在傳統的組織中，可能發生在行業領軍企業，也可能發生在技術初創企業中，在這些組織中，良好的數據是運營次要考慮因素。

解決方案：除非組織遭受足夠多的數據相關痛苦，或者高級管理層選擇支持戰略性數據支持業務方法，否則數據建模以及治理和其他數據內容將主要在項目級別完成，以實現本地目標。

2.缺乏“全局”——沒有全面的業務數據模型

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

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

解決方案：高級“業務數據建模”或“概念數據建模”的藝術已經存在超過 15 年。在經驗豐富的從業者手中，對于中型企業或部門，應該可以在 1-3 個月內制作出良好的初稿，包括與企業所有部門的適當互動。通常，這可以與針對更多高級管理人員和員工的數據素養練習一起完成。隨著從一個業務域更詳細的數據工作引發對概念或全新概念的差異化的需求，可以改進和擴展這樣的模型。

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

3.數據作為應用程序完成或事后的想法

盡管許多應用程序產生并依賴于數據，但一直存在一種趨勢，尤其是程序開發中，忽視數據建模，而不是應用程序設計中首要事情。這尤其體現在兩個方面：

a) 使用第三方程序加速業務能力

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

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

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

b) 內部應用程序開發人員將數據建模視為事后的想法

這是企業內部的問題，開發人員通常在時間壓力下工作，向內部或外部用戶提供數據展示，這些用戶對數據的存儲方式沒有直接興趣。

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

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

模型就是這樣——對現實世界的簡化。在進行數據建模的情況下，通常會捕獲一些隱式規則和關系，希望能夠適應企業管理其現實世界交互的方式。

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

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

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

數據網格建議將大部分建模留給本地域——盡管它也提倡雙時態建模方法，并談到需要通用標準、一種新的建模方法，甚至一種語言來實現跨域的“可組合性”。

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

5.直接獲取數據——數據沼澤遺留問題

雖然大數據運動是由互聯網生成的龐大數據驅動的，但它也是對復雜性和數據變化率問題的回應。隨著一些組織開始通過利用一切數據產生巨大收益，人們越來越不愿意丟棄任何數據。而且數據湖從業者認為，建模已經過時了。現在，當連接大型數據集或多表模型的數據很痛苦時，創建大量非規范化數據集的動力就非常強烈，通常會導致大量重復。對數據安全的忽視也進一步助長了這一趨勢。

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

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

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

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

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

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

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

總之…

就像數據中的許多好東西一樣，良好的建模源于組織承諾、適當應用良好實踐和模式的技能、精心設計的流程以及設計師的優秀技能。在大多數數據平臺上，不進行建模是災難性的。