談一談阻礙資料建模的5大藉口

　　隨著大資料和資料湖的發展，資料建模似乎瀕臨滅亡。資料湖的開發者留下了大量資料沼澤，所以建模活動還是必須的。那麼為什麼仍然存在關於資料建模的問題呢？當然有各種各樣的原因。有些問題至少已有 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 模型則更少，除非著眼於長期的事件。您的資料平臺在捕獲依賴關係和訪問歷史記錄方面有多好？這有助於識別那些從未或很少使用的資料集，並避免因擔心下游後果而保留資料。

　　 總之…

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