接上一篇業務洞察——從人貨場提煉電商數據指標

數據指標體系已經提煉好了，接著就是想辦法落地實現。現在數據中臺是個流行詞匯，在技術思維里，重復的邏輯會被抽象為組件、服務或者系統，系統這個層級都包不住的，可以上升為中臺。數據中臺，顧名思義，是要對外(也就是多個使用方)提供統一的數據服務。我把數據中臺的建設簡單的劃分為數據建模、數據采集、ETL以及數據分析四個階段，這四個階段形成良性的迭代循環，推動整個數據中臺的持續進化。

數據建模里的模型通常指的是多維模型，多維模型由事實表和維度表組成，我們要建的第一個多維模型是商品訂單模型，事實表里添加銷售額、毛利額、銷售件數這三個度量，毛利率作為計算指標可以在數據分析階段再做處理。維度表精選了商品、用戶、渠道、場景、時間、訂單這6個，很顯然，訂單作為維度表是不合理的，膨脹的速度太快，需要把是否首單這類有價值的數據合并到事實表中。在前面提煉指標的時候，我把渠道和場景放在了一起，實際上渠道和場景之間是并列的關系，不是隸屬關系，在這里需要拆分成兩個維度表。

我們要建的第二個多維模型是商品流量模型，事實表里添加商品展示次數、單品頁PV、加車次數、下單次數、支付次數、支付金額這6個度量，UV、點擊率、轉化率、客單價作為計算指標放到數據分析階段再做處理。維度表與商品訂單模型一樣，精選了商品、用戶、渠道、場景、時間這5個。

多維模型建好之后，需要盡快確認上游數據是否存在，在這兩個模型里，需要的上游數據主要有訂單交易流水、流量日志、商品配置數據、商品成本數據、運營費用數據、渠道配置數據、場景配置數據以及用戶畫像數據。在這些上游數據里，訂單交易流水、商品配置數據、商品成本數據一般都會比較齊全，流量日志、渠道配置數據、場景配置數據、以及運營費用數據通常會比較散亂或者缺失，用戶畫像數據則可能根本就沒有。在這種情況下，我們需要對模型進行精簡，先實現能找到上游數據的度量和維度，同時開啟支線任務去推動完善上游數據建設，這就是前面提到的迭代循環。

找到了上游數據源，接下來就到了秀技術能力的時候，先不講技術細節，我們繼續抽象，上游數據源和目標數據模型之間的差異很大，直接用ETL一步到位，很容易被噎著，還會犧牲系統的穩定性和模型的可復用性，基本上每新建一個模型都得從源頭上開始全程來一遍。所以需要在中間添加一些處理層，按照標準的數據倉庫建設流程，一般會在中間抽象出兩層，ODS層和DW層，ODS層會把各個異構數據源中的相關業務數據都抽取上來，一般不做清洗和轉換，以保持與源數據的一致性。ODS層的數據經過各種清洗、轉換和計算后，按照多維模型的形式進入到DW層，俗稱的大寬表就在這一層，像每筆訂單中每個商品的成本計算結果、費用計算結果和毛利計算結果都在這一層存著。在DW層之上再進行匯總和處理，就進到了目標數據模型層，這一層一般被叫做DM層或者APP應用層，到了這一層之后，為了方便后續的數據分析，也可以把這一層的數據存儲到關系型數據庫中。在之后就是數據分析，在數據分析這個環節，可以使用成熟的商業產品，像觀遠的BI就非常好用。

簡單的總結，我們可以把數據中臺簡化為這個四層結構，越往下就越穩健，越往上就越靈活可變。這個層級結構可以把整個數據中臺的維護成本降到最低，在數據分析層，借助像觀遠BI這樣的成熟商業產品，只需要極少數的數據分析師，就能夠支持業務部門絕大部分的日常數據需求。維護成本降低后，就可以把數據組從之前繁瑣的報表開發工作中解放出來，投入到能產生更大價值的工作中，比如可以去持續的改進數據模型，優化集群性能，將更多的業務數據源納入到數據中臺，同時還可以去推動上游數據從源頭上加強建設。(技術實現后面展開講)

總結

以上是生活随笔為你收集整理的事实表和维度表是怎么造数据_从电商数据指标到电商数据中台的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。