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

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

盡管 CIO 和 CEO 宣傳“數(shù)據(jù)驅(qū)動(dòng)”，但對于某些企業(yè)而言，數(shù)據(jù)的管理和利用并沒有放在主要日程上，至少在高層是這樣。這可能是可以理解的——并非每個(gè)企業(yè)都是“數(shù)據(jù)企業(yè)”；數(shù)據(jù)可能很重要，但僅在特定的獨(dú)立領(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ù)是運(yùn)營次要考慮因素。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4 效率問題——建模只會(huì)減慢速度

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

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

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

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

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

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

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

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

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

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

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

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

將數(shù)據(jù)保存更長時(shí)間是有正當(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)險(xiǎn)，以及將半衰期短的數(shù)據(jù)保存太久的環(huán)境成本。最終，這又回到了數(shù)據(jù)所有權(quán)和“為什么”的問題上。

解決方案：僅僅因?yàn)榭梢院鲆暎⒉灰馕吨鴳?yīng)該這樣。具有可靠治理、良好的數(shù)據(jù)高級模型和可靠數(shù)據(jù)架構(gòu)的組織可以受益于更便宜的存儲(chǔ)和易于使用的平臺(tái)支持的數(shù)據(jù)底座和轉(zhuǎn)換模式。不急于對數(shù)據(jù)進(jìn)行詳細(xì)的過度建模并在其價(jià)值確定之前花費(fèi)大量的計(jì)算周期和工程師時(shí)間進(jìn)行轉(zhuǎn)換可能是有價(jià)值的。

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

總之…

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

審核編輯：郭婷