用12年數據建模經驗告訴你如何3步走解決建模問題

導讀ID:TOP100case

導讀：我們在做數據倉庫、數據挖掘的過程中，經常遇到這樣的問題：在建設模型的過程中，因為需求變化或業務數據的發展無法做到模型的快速適應。於是就出現為建模型而建的一堆寬表和維度事實表。但依然無法快速響應業務的需求，反而帶來ETL工作量的快速增加，導致模型的臃腫、低效，更帶來ETL工程師的無奈和挫敗感，極大的影響到了項目進度及質量。本文以作者十多年的從業經驗，告訴你建模的正確姿勢。

（全文共5919字 預計閱讀時長：6分鐘）

建模工作如何快速響應變化的業務需求

我們在做數據倉庫、數據挖掘的過程中，經常遇到這樣的問題：在建設模型的過程中，因為需求變化或業務數據的發展無法做到模型的快速適應。於是就出現為建模型而建的一堆寬表和維度事實表。但依然無法快速響應業務的需求，反而帶來ETL工作量的快速增加，導致模型的臃腫、低效，更帶來ETL工程師的無奈和挫敗感，極大的影響到了項目進度及質量。

在從事數據模型建設12年的工作經歷里，剛開始我也跟許多人一樣，走過一些彎路。比如認為要建設好數據模型，只要把建模的方法論深入理解就行，有方法論就有想要的模型，或是側重於掌握對建模工具、高深的演算法及模型建設方法等。

實際上，這些看法都非常片面，數據建模絕對不是簡單的一個任務或一個流程中的小環節，它從數據源系統的調研開始，到實施每個環節都不能缺漏，確切的說建模就是一個系統性的工作。所以，要做好模型，先得把觀念擺正，這是一個系統，不是業務系統中的某個小環節，如果糾結於建模過程某個環節，必然無法把控好建設模型的整體性需求和目標。

要做好數據模型，最好把數據模型的建設關鍵點做深入剖析，擺脫只注重數據挖掘的基本理論和數據分析方法及數據挖掘中的關聯分析技術、分類和預測技術、聚類分析技術等，轉為注重業務的兼容和合并，同時，在建模過程中還需要考慮的成本、時間、質量。

數據中心建模工作實踐

2.1 分享目標

該數據中心建設需求分成3期，每期的任務和要達到的目標不一樣，主要的核心是數據中心的模型架構設計。下面的分享是我對一期建設過程中的探索和總結，分享的目標有兩個：

進一步認識在不同的應用場景中建設模型需要考慮的要素及問題；

結合案例掌握如何在需求變化、業務發展中調整建模的策略和工作思路。

2.2問題提出

該數據中心的一期需求簡要如下：

2個月完成數據建模，1個月完成數據中心的ETL建設，2個月完成108張報表的分析需求及3個數據挖掘分析需求。

一開始接到這個任務，首先想到的是領導打算給多少人？讓我帶什麼樣的團隊？是什麼樣層級的人。大家都知道，要做好數據模型，既要有業務專家，也要有資料庫設計、模型設計、ETL等方面的專家，還需要客戶的配合等眾多資源。

其次在想，領導要求的時間是否真是5個月？還是許多過程可以同步進行。因為數據建模和報表需求整理是可以分開同時進行，ETL建設也可以先把相應的基礎架構設計準備好…等等。

這些是我第一時間考慮的問題，是從自己的需求和問題出發想到的問題。其實，這是一個嚴重本末倒置的問題。因為當你都從自己身上找需求和問題的時候，就開始脫離問題的本質了。

比較合適的做法是要先問問：客戶在哪？用戶的需求在哪？用戶的問題在哪？用戶有什麼樣的應用場景？客觀存在的實際問題在哪？依據用戶的需求和問題，可以得到什麼樣的資源？如果得不到，能有什麼替代方案等等。

只有以客戶需求和問題為中心的數據模型建設才會有價值，也才能根據需求來配備相應的資源。

通過第一階段的調研，該數據中心的建設開始階段至少有以下3個問題，而這3個問題跟數據模型的建設息息相關：

用戶無法提出明確需求；

需求變化頻繁，意味著要分析的數據維度信息變化大；

臨時性報表查詢分析需求多。

面對這3個問題，我們有2方面思考：

需求變化頻繁，如何把握好？數據模型設計經常變化，ETL建設必然會因設計變化頻繁，導致ETL相關代碼的頻繁改動而增加，沒有意義的工作量。

臨時性報表需求多，不加以引導和管理控制一方面可能會影響團隊的整體工作進度，另一方面很容易因為了臨時需求，建了一堆的業務表和中間處理過程的臨時表，數據「增長」額外增加，對數據模型的對象維護也增加了負擔，從而引發了模型的不穩定性和可擴展性差。

這些問題很容易就導致：或是進度無法完成，或是人力資源不夠，亦或是模型質量極差等。針對這些問題怎麼辦？

2.3「三步走」解決問題

處理上面遇到的問題方法多樣，在工作中我主要通過以下三個工作思路來解決大部分問題。

深入理解和挖掘客戶需求，即要深入考慮如何做好業務需求分析。

在了解需求後結合自己的資源，制定出數據模型建設計劃甘特圖，即計劃綱要，主要體現在什麼時間節點、什麼樣的資源投入、完成什麼樣的任務，任務節點之間的關聯優先順序等信息。尤其需要重點把握里程碑的節點，這個節點一旦確定最好不隨便變更，如果需要變更，需要跟客戶、領導及自己團隊及時溝通彙報，以便能在計劃內控制整體項目進展。

甘特圖設計如圖1所示。

圖1 甘特圖設計

結合工具進行數據模型的框架構建。有了整體業務域的規劃後，在此範圍內規劃數據，形成一個個相對獨立又有關聯性的比較穩定的業務體系，這樣就能更好的讓數據為業務服務。

如何高效地做好業務需求分析

3.1方向思路

提高用戶參與意識

改變用戶參與度不夠的問題。許多項目負責人或開發人員，對用戶的參與經常懷有抵觸心理，認為用戶啥都不懂，還愛瞎指揮等。

我們自己要先從意識上確立這樣的觀念：這項工作不只是我們的事情，也是用戶的事情，雙贏的才是最好的。樹立雙贏的意識，在對待客戶參與的問題時，才能有積極的態度，那樣用戶才會真心理解和支持我們在模型建設過程中的困難和問題，才能得到他們更多的認可和資源支持。最好是把成就感給用戶，把成就留給自己。讓用戶覺得這個產品是自己親手做得。

需求也要建模

建立業務領域模型之間的關係，超越「功能需求」，做好開發與用戶對實際問題的抽象。只有先抽象功能，才不至於最後做的是一堆功能性的開發和設計。有抽象就如如同業務有根據地一樣，這樣新的需求要實現才有立足之地。抽象只是為了歸類和功能方便拓展。

用工匠精神，打造精細化的產品。是用心去做，不只是認真做完。

模型建設是持續迭代循環的過程，不能以做臨時性項目的方式來設計應付，這樣後患無窮。

3.2具體措施

積极參与用戶訪談、調查調研，加強雙向溝通，注重用戶和軟體開發人員的有效溝通，尤其在業務需求分析方面需要更加註意，否則容易閉門造車。

與用戶一起梳理業務使用場景，明確問題在哪裡？在場景中抽象出業務之間的關係，而且能更精確的知道需求涉及到哪些業務模塊？業務問題是怎麼發生的？理順了場景流程，就要抓重點，理順優先順序，做好對用戶需求的痛點分析，尤其在趕進度，投入少的情況下，我們要重點解決業務的痛點問題，才能產生最大的價值。

利用原型法來確定或引導用戶需求，評估項目中可能出現的問題，並進一步確認客戶的真實需求。

3.3舉例：對用戶使用場景梳理的抽象（業務領域模型之間的關係）

這些梳理不僅僅需要用戶在業務上的提醒和指導，也需要我們在抽象出關係圖後及時跟用戶確認，是否包含他們大部分的主體業務。只有這樣，業務領域概念模型設計才能符合用戶需求，做好這項工作的目的是將來有新任務、新需求、新的內容進來時可以快捷的劃分到相應的業務領域，從而不會破壞業務的整體性。

我所理解的好，最好是既能滿足客戶的需求，也要綜合考慮後續模型建設的穩定性、可擴展性及我們團隊的可實現性，也就是雙贏。

圖2 用戶業務場景抽象關係圖

按圖2抽象關係後，對每個對象進行描述。

參與者主題域：是指系統的所有用戶，覆蓋政府、社區管理者、志願者、電信/運營商、商家、居委會/物業、居民等；

服務主題域：是指由參與者提供的所有服務，覆蓋服務、商品、產品等；

內容主題域：是指系統內的所有內容信息，覆蓋新聞、通知公告、文檔、圖片、媒體等；

交互主題域：是指參與者之間所關聯的事件，覆蓋交易、共享、溝通、信息推送等；

地域主題域：是指自然要素與人文因素作用形成的綜合體，包括地域空間。

這樣設計後，基本確定了整個業務模型建設的模塊，也方便後續的數據梳理、需求規劃、開發、設計和實施等。

維度建模的技巧

這裡簡要介紹2種技巧，為數據模型的可擴展性、可實施性留有餘地。

4.1保留歷史信息應對歷史記錄分析

許多時候，用戶對於數據要保留多久合適，無法提出具體的要求，甚至會根據當下的需要，沒有考慮長遠，進而用語言誤導我們設計。而我們需要考慮用戶潛在的需求。

比如，對於地址方面，用戶想的是要保留當前的地址信息，過去的信息暫時沒用，不需要保存。這時，我們要考慮數據建模及數據中心對將來的數據挖掘的需求並結合業務應用場景，這類信息有保留歷史記錄的需要。

比如，運營商要對客戶的地址變更信息追溯，做深入挖掘，對於經常變換地址的人群挖掘出潛在的商機。我們提供了相應的資訊服務或與第三方合作，就可以提升智慧社區服務的品質。

針對這種緩慢變化維設計，主要有下面3種方法：

覆蓋：把新的地址直接覆蓋到舊的地址上，舊的地址無法被保存，無法進行歷史追溯，如圖3所示。

圖3 覆蓋

另一種方法是在程序中，加入一個欄位，有新的地址，原來的地址就放到Old Address欄位上。這樣的做法最多只能保存最近2次的，如果有第3、4、5次地址變更呢？如圖4所示。

圖4 添加欄位

結合業務場景和數據中心建模設計經驗，推薦這種比較實用的設計，如圖5所示。

圖5 實用的設計

即添加一條新的記錄，同時把失效時間 Effective End Date 的值改成當前時間，然後添加一條最新的Addr2的信息，這樣保留了歷史，也記錄了最新的信息，失效的歷史記錄既可以單獨存放在一張獨立表中，也可以不用獨立一張表，直接跟原表放一起，因為有時間失效標識，就可統計分析出歷史數據信息。

4.2預留擴展設計，應對維度應用擴展，保證模型關係完整性

業務需求不可能都是靜態的，大都是動態變化的。我們不能都在實施階段才想到業務要變化，要提前考慮預留變化，因此需要結合業務前景規劃和場景應用綜合考慮，預留擴展設計，以保證模型的完整性。

例如在做參與人概念模型設計過程中，不僅僅要考慮這個人所在的關係、許可權、還有以後要使用的多樣化的登陸平台等等，那我們可以提前準備好擴展設計。

在如圖6抽象的基礎上，建立模型。圖7是一小部分工作實例模型。

圖6 參與人概念模型圖設計

這樣，我們就把可能擴展的要素事先幫用戶規劃好了，一旦客戶需要通過不同的平台來登陸我們的系統，我們可以理直氣壯的答覆：支持。是否還能支持不同平台的積分活動呢？是否能跟多個第三方支付業務合作呢？這些都已在圖7中體現出來了。

圖7 部分工作實例E-R模型

結合應用，設計好維的層次

維的層次要考慮數據是否可累計。比如：年、月、日就有時間層次性，要得到月的數據，可以通過日數據來匯總，要得到年的數據，可以通過月或日的數據來匯總，又如：公司，事業部，部門，項目組等也有機構維的層次。

維的層次性設計需要根據應用場景和實際情況，因地制宜的選擇策略，內容包括：

是否以最小粒度來存儲就夠了？可否減少上一級、或更上一級的數據存儲？是在意存儲空間還是訪問頻率？是在意後面的匯總層次維的多方應用還是小範圍的最小粒度的應用？這些都需要結合業務場景需求設計。

是否可以直接用視圖來快速解決高層級查詢？比如，只存儲日數據，月和年的數據，直接用視圖通過group by 匯總的方式來解決。這個策略要根據用戶是否需要經常匯總數據，是否會經常更新數據，是否需要對月或年的數據進行分析和應用等來取捨。

還需要考慮層級是否能累加，不能累加的層級要特別注意不能放在一個表中。比如：有時間維的數據包含 季度、月、旬、周，這幾個層次的數據放一起容易亂，旬和周數據未必可以疊加，季度和周的數據一般也是很少可累加的。

還要考慮高層次的維數據是否需要實例化落地。實例化既要維護，又會增加存儲空間，還可能導致I/0的性能壓力。但若是高級層次的維度分析較多，並經常需要變化條件與其他關係表關聯，那僅作視圖是肯定不行的，就要考慮數據，實例化落地。

當然需要考慮的要素還有許多，但根本的還是在於對維度分析需求的把握要結合應用場景，機械套用或搞一刀切都是不切合實際的做法。

經驗教訓

從業多年，教訓有很多，其中以下3個教訓相對影響較多，而改正和規範的時間卻相對較長。

6.1見招拆招

需求多變，不考慮新增需求與過去需求的業務關聯性，建一堆的表來應對新的業務需求，「理由」是用戶永遠都那麼急，昨天提出的需求，幾乎今天就要實現，為了趕進度，只能見招拆招。

6.2自以為是

不願更多地與用戶深入溝通、調查和確認，忽略業務專家和數據分析專家的建議來建模，以開發方便快捷為出發解決問題，「理由」是用戶又不懂模型，問那麼多只會增加負擔。

6.3整體的核心問題

當實施過程出現問題以用戶的問題為借口，在規劃階段以自己的需求和困難為理由，為了建模而趕模型，為了進度而趕進度，忽略了建模過程中的設計策略。

這些錯誤造成了投入了不少時間精力、人工成本，但最後付出了高成本、低質量、無法滿足後續的擴展性需求，表面上事情做好了，簡單了，實際是複雜了後續的業務需求，也讓後續的維護時間、維護成本及開發工作量成倍增加。

案例ROI分析

7.1建模效率

以用戶業務問題為核心，構建模型，先慢後快，模型的穩定性和可讀性和完整性二期比一期好，模型設計效率比一期快了近40%。

7.2ETL成本

一期遇到的問題在形成了規範並做了經驗和教訓總結，在第二期的改進中，ETL的開發成本節省了50%。

7.3響應速度

新增用戶需求的響應效率，二期比一期的響應速度提升200%，滿意度提高到90%以上。

7.4團隊成長

完善協同流程管理和業務領域歸類，避免協同雙方相互推諉的現象；規範業務規劃及應急機制，減少不必要的工作內耗，提升團隊戰鬥力。

面向需求進行系統建模

8.1盯速度及成本更重質

數據建模中，許多人都過分關注建模的速度及建模技術，而缺少對需求建模，需求也是需要建模的，可以利用需求分析的原型和用戶使用場景來引導建模規範性、可擴展性及靈活性。

8.2ETL物理模型適應業務

在ETL建設過程中，工程師最怕的就是數據模型經常變化，改代碼，返工等重複勞動費時費力。其實，ETL也可以建模。比如通過ETL技術元數據和業務元數據的抽象，把一些程序參數化，並通過輸入變數來減少ETL的重複編程。而且ETL的模型建設的好，可以快速適應業務模型的變化，甚至許多時候在業務模型變化的時候，我們只需要控制ETL的輸入變數來管理，有效的節省ETL的工作量。

8.3避開三怕讓模型有思想

數據建模過程中，有時是因為主動性不夠，怕溝通流程牽涉眾多生產線麻煩，怕跟領導同事溝通被批評，怕團隊無法在有限的資源里完成目標，在三怕的基礎上，又被要求在極短的時間內要做好數據分析、要有數據挖掘的價值體現，於是許多模型就做得不叫模型，沒有思想和業務靈魂，純粹為了迎合當下緊急的需求和問題而建了一堆沒用的表或是為解決一個小問題，從大模塊中單獨複製，浪費資源。

8.4引導需求分階段完成

滿足用戶的需求，要抓用戶重點、痛點，而不是難點，並在使用上去引導用戶。同時，也要明確不是所有需求都能在模型中實現，要考慮分階段，分期實現的可能性。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！