建模流程
業務建模
根據業務部門進行划分，理清部門之間的關系，然后將各個部門的具體業務程序化，與業務部門開會協商出需求的指標、保存年限、維度等等。總體來講，就是要知道他們需要哪些指標以及他們能提供哪些數據。業務建模的時間最長，而且與公司實際的業務環境息息相關，因此在這里需要根據實際生產環境和業務需求確認好數據倉庫使用的工具和平台。
概念建模
將業務模型抽象化，分組合並類似的概念，細化概念，抽象出實體與實體之間的聯系，理清各組概念之間的聯系。說白了就是畫圖，把指標需要的哪些數據封裝到一個實體里，實體與實體之間的關聯等等用ER圖表示出來。先畫出局部ER圖，最后再綜合畫出全局ER圖。
邏輯建模
將概念模型實體化，具體考慮概念對應的屬性，事件考慮事實屬性，維度考慮維度屬性。總體來說就是建表，前面已經畫出了關系圖，這里只要將表里頭有哪些字段考慮出來就可以，如果是事實表就考慮事實字段和業務主鍵，如果是維度表就考慮維度屬性，SCD策略等等。在這里需要確定數據粒度，如果多個指標都用到一個字段，則取粒度最小的指標。如果不確定指標的量度，則取毫秒級作為粒度。
物理建模
綜合現實的大數據平台、采集工具、etl工具、數倉組件、性能要求、管理要求等多方面因素，設計出具體的項目代碼，完成數倉的搭建。
7.4.2 數據模型
星型模型
數倉（具體說是dwd層）中只有一張包含歷史數據且不冗余的事實表和一組附屬維度表，每個維度一張。事實表與維度表之間通過外鍵和主鍵關聯。星型模型的維度表可能存在冗余，因此是反三范式的，這種模型在數據維護上較麻煩，但是性能更高，業界普遍使用星型模型。星型模型的難點在於拉鏈表的維護，拉鏈表一般不能有冗余。
雪花模型
針對星型模型的維度表進行擴展的模型，將維度表拆解成維度表+說明表，說明表又可以進一步拆分，最終形成事實表-維度表-說明表的多次連接。雪花模型的表一般遵循三范式，在數據的維護上會很方便，但是多表join影響性能。
星系模型
多個事實表采用星型模型共享維度表，就形成了一個星系。
Data Vault模型
從上述模型中我們不難看出，如果解決了拉鏈表的維護問題，星型模型的缺陷就已經可以忽略。Data Vault模型由中心表、鏈接表、附屬表、PIT表組成，這里的中心表，事實上就是維度表，鏈接表就是事實表、附屬表是拉鏈表。Data Vault模型就是通過將拉鏈表從維度表中分離出來，來達到方便維護的目的。首先，中心表是一組業務生命周期內絕不會變的維度表，打個比方就是java里頭的常量，常量再怎么冗余也不會有影響。鏈接表則是保存流水類數據的事實表，它通過外鍵與多張中心表連接，但不會連接附屬表。附屬表則是從維度表中抽出來的可能會發生變化的字段或表，這一部分就采用拉鏈表的方式創建，中心表則通過外鍵關聯附屬表的主鍵。
從同一維度表拆出來的字段根據變化維度不同可能還要分成多表存儲，為了避免時效不一致，所以還會建立一張PIT表，用於維護附屬表的變化歷史。中心表通過外鍵與PIT表相連，而PIT表則為每個附屬表的主鍵都准備了一個時間字段保存數據的更新時間。