者按：以前有個關于編程語言的段子是這么說的：寫C的看不起寫C++，寫C++的看不寫java的，寫java的看不起寫JS的，寫JS看不起美工，周末大家都在加班，美工帶著女朋友旅游去了。這么看來JavaScript已經落到編程語言鄙視鏈的最底端去了。但是這門長期位于十大編程語言行列的語言早已經發展到幾乎無所不能的地步了，不信可以看看Rapha?l Benitte、Sacha Greif與Michael Rambeau所做的2017年JavaScript現狀報告。

我最近公布了我們2017年版的JavaScript年度現狀調查報告的結果，這是23000位開發者的共同反饋。

從流行趨勢到工資明細，結果揭示了很多事情。如果你還沒有這么做的話最好自己進來看看。但是在所有這些數據當中，有10件事情是最重要的。

即便你還沒有看過這些結果，你可能也想看看我們剛剛增加的新的功能和觀點部分。

洞察#1：React站穩腳跟

今年的版本確認了去年的趨勢：React目前是占據主導地位的前端庫。

React擁有目前為止最快樂的用戶（深紫色條塊）

對React的早期指責（通常集中在React混合HTML與JS的方式上）現在似乎已成遙遠的記憶，Facebook還擱置了開發者今年最后一個主要的煩惱——取消了他們版權協議里面的專利條款。

隨著使用數量和開發者滿意度達到了有史以來的新高，完全可以說React已經站在了山頂上，至少目前是這樣。

洞察#2：Angular正朝著新的角色轉變

這并不意味著你就可以將Angular判負了。是，Angular的勢頭沒有像React那么強勁，但是它還有一些非常強的因素支撐。

首先，Angular背后有Google力量的支持。不管你怎么說，那都是業界最好的工程師之一，他們正在投入全職的時間來改進這個框架。

需要指出的重要一點還包括Angular仍然擁有龐大的用戶群。對于這股最新的熱潮，銀行、政府已經其他大型公司沒法像你們這些普通的自由職業者接受得那么快，出于這個原因他們往往有龐大的遺留Angular代碼庫需要維護。

“新”Angular（2+）于“老”Angular（AngularJS）對比：接受度更低，但開發者滿意度更高

不過最后一點也許是最關鍵的：Angular不再嘗試跟React硬碰硬了，而是相反把自己的焦點轉移到企業市場。只需要看看Angular對TypeScript的采用就知道了：盡管這也許會阻止了一些開發者，但這樣決定也帶來了企業應用所需的那種可靠性和安全性。

洞察#3：你再也不能忽視Vue.js了

Vue去年好像突然之間就冒了出來，并且在非常短的時間內為自己贏得了React最大威脅者的稱號。它也許沒有Angular的用戶規模或者Ember的長壽，但卻有著足以擊敗這兩個的東西：勢頭。

Vue & React：這兩個擁有最高的開發者滿意度（淺紫色 vs 深紫色）

盡管Vue擊敗React似乎仍然不大可能，但毋庸置疑的是，在提供全框架式體驗方面，Vue的確擁有更好的故事，而這要得益于由同一支核心團隊維護的官方路由和狀態管理庫。

洞察#4：了解一些庫的知識會幫你賺更多（但是原因不像你想的那樣）

通過收集和交叉引用工資數據，我們得以找出哪一項技術是最賺錢的。

不同的JavaScript技術，按照薪水從低（左）到高（右）排列

如結果表明那樣，往往是像Polymer或者Reason這樣的小眾技術跟最高薪水相關。

JavaScript前端庫，按照薪水從低（左）到高（右）排列

盡管Polymer獲得的薪水更高是可能的，但更資深的開發者（這些人往往賺得更多）往往嘗試更多不同的庫也是有可能的，而經驗不足的程序員更愿意把經理集中在一或兩種主流技術。

因此按照這份排行榜去學東西可能（只是可能）并不是賺得更多的關鍵。

洞察#5：2018年將成為GraphQL之年

如果你跟絕大部分的調查受訪者一樣的話，你應該已經聽說過GraphQL并且對它饒有興趣了，但其實你還沒有嘗試過。

REST希望自己也有個這么酷的logo

如結果表明那樣，這是一個非常常見的情況。在這次調查提到的所有技術里面，GraphQL是引起興趣最大的一個——盡管目前它的用戶數量還很少。

大大的黃色條代表的是14000位對GraphQL感到好奇的開發者

說到當前用戶，值得指出的是透明總體上都對GraphQL感到高度滿意。有了這里的高度興趣和高度滿意的結合，如果2018年成為GraphQL超越鴻溝進入成為主流技術之年的話不要感到吃驚。

洞察#6：JavaScript != 前端

我們知道JavaScript不僅僅能用在瀏覽器里面已經不是一天兩天的事情了。畢竟，Node就是一種非常流行的后端選擇，已經流行了好幾年了。

但2017年JavaScript又開始了進一步的擴張：像AWS Lambda這樣的平臺讓你可以在沒有后端的情況下編寫后端代碼，而物聯網設備的日益流行意味著不久之后，你的烤面包機也很有可能最終跑的是JavaScript。

這臺烤面包機利用運行Slack的桌面應用產生的熱量來烤面包

如果這聽起來很荒謬，記住今年最熱門的文本編輯器，VS Code本身就是用JavaScript編寫并且作為Electron應用運行的。

JavaScript從作為展示橫幅廣告的工具發展成文本編輯器的編寫工具，這一切都是在幾年之內發生的的事。相信我，JavaScript烤面包機的出現也許比你想象的要早。

洞察#7：微軟正在反擊

說到VS Code，這絕對是今年的一大驚喜。在Sublime Text和Atom正在為文本編輯器的王座爭得不可開交時，新進入者VS Code破窗而入，偷走了它們額午餐。

過去Sublime Text往往有速度上的優勢，但卻被不直觀的UI抵消掉了，而Atom有著很好的UI但是往往給人很慢的感覺。

VS Code編輯器

結果表明VS Code也許已經找到了這兩者的適當平衡。盡管還是在類似Atom這樣的Electron基礎上開發出來的，但微軟的工程師在改進性能方面做了很好的工作。就像Sublime一樣，它支持范圍很廣的各種插件和定制化，盡管一個更為用戶友好的軟件包“剛好能用”。

再加上TypeScript的崛起，看起來微軟終于把自己玩的web工具湊到一起了，并且證明了自己可以做出開發者用的東西了，而且開發者用是因為自己想用而不僅僅是因為他們只能用這個。

洞察#8：世界各地的JavaScript都不一樣

當我們討論JavaScript時，我們往往把它當作一個統一的生態體系來討論。盡管重要趨勢不同地區都是一致的，但有趣的是不同的國家往往會給JavaScript添加一些自己的定西進去。

比方說，你知道Vue在中國極其流行嗎？這是說得過去的，因為Vue的開發者Evan You就講中文，而且Vue已經為多家中國的主流技術公司如阿里和百度所采用。

印度另一方面似乎特別鐘愛Angular。這也許至少部分是由于印度活躍的外包業所推動，而外包往往盯住那種Angular所應用的大型企業項目。

洞察#9：類型化JavaScript正在崛起

TypeScript、GraphQL、Elm、Reason，這些之間有何共同點？首先，它們都是先進技術，正在迅速發展。其次，它們都依賴于類型。

名字前正好有個“Type”。

盡管JavaScript開發者很久以來一直在享受著不用理會編譯器對你的吼叫隨心所欲寫代碼的自由，但是這種自由是一把雙刃劍：這也意味著不那么可靠問題更多的開發者體驗。

但到了2017年，情況終于開始改變。TypeScript獲得更廣泛的認同并不僅僅是個巧合，開發者也開始朝著VSCode之類的IDE式文本編輯器遷移，從而更好地利用類型提供的額外功能。

洞察#10：百變JavaScript

再次地，這次的調查表明了JavaScript的生態體系已經變得如何的豐富。

似乎經過多年時而批斗時而無視JavaScript之后，開發者社區終于突然想到了第三個選項：改進它。

這也許是為什么大多數開發者同意盡管有缺陷，但這門語言總體而言正在朝著正確的方向前進的原因：

編譯組出品。編輯：郝鵬程。

xcel 中遇到較復雜的運算，數據分析師常會用 add-ins 輔助解決。本文考察了一些常見的 add-ins，從部署難度、開發難度、流暢程度等方面進行深度對比，并著重考察了數據計算能力，esProc 在這些 add-ins 中的表現相對出色。點擊輔助 Excel 的數據計算 add-ins了解詳情。

對于大多數簡單運算，Excel都提供了方便的實現手段，有時是易用的函數，有時是直觀的按鈕或菜單。但我們還是會遇到的一些較復雜或特殊的運算，依靠Excel本身很難實現。Excel提供了add-in接口，可以通過這個接口執行外部程序，從而借助外部語言或腳本實現這些較復雜或特殊的運算，達到輔助Excel的目的。

下面，讓我們深入了解一些Excel的常見數據計算add-ins，并評估它們的計算能力。

Excel DNA

Excel DNA是早期出現的一款Excel add-in，它可以把程序員寫好的動態庫函數放到Excel里使用，動態庫可以使用C#/F#/VB.net等語言等編寫。

具體用法上，Excel DNA和其他所有add-ins都類似，首先要編寫自定義函數。比如下面C#編寫的代碼中（引自Excel DNA官網），MyFunction是自定義函數名。

using System;

using System.Collections.Generic;

using System.Linq;

using System.Text;

using System.Threading.Tasks;

using ExcelDna.Integration;

namespace MyLibrary

{

public class Class1

{

[ExcelFunction(Description="few people use this way!")]

public static string MyFunction(string name)

{

return "Bonjour" + name;

}

}

}

上面的代碼須編譯成動態庫，之后才能在Excel中使用。

接下來，一般要配置自定義函數和add-in的關系。比如下面的DnaSample.dna文件，表明本add-in的名字是"My name"，對應的動態庫是Mylibrary.dll（含有多個自定義函數）。

<DnaLibrary Name="My name" RuntimeVersion="v4.0">

<ExternalLibrary Path="Mylibrary.dll" />

</DnaLibary>

最后在Excel中配置該add-in，就可以在單元格中調用MyFunction這個函數了，如下：

應該注意到，上述過程有個編譯的動作，因為編譯過的程序可直接執行，且與Excel集成緊密，因此執行效率非常高。這便帶來了Excel DNA最大的優點：順滑無卡頓。

Excel DNA的其他優點從名字就可以看出來，換句話說，該add-in可以充分利用微軟DNA架構提供的便利，比如開發語言、開發工具、Excel集成、聯動調試等。

還應該注意到，C#/F#/VB.net等語言的通用性很強，理論上是無所不能的，但官網的代碼例子卻只是字符串輸出，體現不出哪怕絲毫的能力，這到底是為什么呢？

因為理論和實際是有差別的。

C#/F#/VB.net等語言缺乏結構化計算類庫，即使最基本的運算都要硬編碼實現，代碼因此非常繁瑣，并不適合做復雜的數據計算。

除了不適合數據計算，還應注意到C#/F#/VB.net是編譯型語言，而不是解釋型語言，這就要求用戶必須維護一套編譯環境，以備修改算法后編譯所用，而微軟的編譯環境配置較復雜，桌面數據分析師不易掌握。事實上，C#/F#/VB.net等語言本身的技術門檻就很高，這就導致Excel DNA更適合專業程序員作為接口使用，并不適合大多數桌面數據分析師直接使用。

除了Excel DNA，還有其他一些add-ins同樣缺乏結構化計算類庫，比如基于JAVA語言的JINX。很容易就能判斷出，JINX也不適合數據計算。事實上，Excel自帶的VBA在語言能力上和Excel DNA/JINX相當（都不適合數據計算），但VBA免集成免編譯，比Excel DNA/JINX更有競爭優勢。

Excel JavaScript

顯而易見，無論什么add-ins，至少要比VBA方便好用，才值得我們學習研究。微軟也發現了這個問題，所以2013年推出了Excel JavaScript，一種比VBA更方便的add-ins專用語言。

Excel JavaScript的用法和其他add-ins類似，這里以及后續都不再贅述。值得強調的是，Excel JavaScript是解釋型語言，可以隨時修改并立即執行，而無需編譯，這一點和Excel DNA區別較大。既然是解釋型語言，一般就會存在卡頓問題，但Excel JavaScript是Excel內置的語言，可以在同一個進程中執行，因此實際效果非常順滑，執行效率僅次于Excel DNA。

內置于Excel還會的帶來其他好處，比如無需下載，可直接開發，這便省去了繁瑣的部署過程。再比如Excel JavaScript繼承了Excel跨平臺的能力，只需編寫一次，就可以在單機版、網頁版、Mac版上無縫遷移。另外，Excel JavaScript可直接訪問workbook、sheet、cell等Excel對象，開發效率顯著提升。

等一下，上面說的雖然都是Excel JavaScript的優勢，但好像VBA也具備同等的優勢，所以，說好的“更方便”到底體現在哪里？

比VBA更方便，體現在Excel JavaScript的界面控制能力上。換句話說，Excel JavaScript可以用更簡單的語法訪問Excel菜單欄、面板按鈕、彈出框，可以在JS文件中直接定義add-ins界面，比VBA方便太多了。

唯一的問題是，界面控制并非數據計算add-ins的重點，不值得我們關注……

不錯，既然講的是數據計算add-ins，那數據計算能力才是關注重點，而不是界面控制能力。但遺憾的是，JavaScript依然沒有任何結構化計算函數，用于做Excel都難以實現的數據計算也沒啥特別的優勢，僅僅是讓Excel多了一種不同于VBA的腳本語言而已。

pyxll

顯然，只有具備結構化計算類庫，才算是合格的數據計算add-ins，比如這里要講的pyxll。Pyxll是基于Python語言的add-in，而Python擁有結構化計算類庫Pandas。

既然是合格的數據計算add-in，pyxll實現簡單算法時自然無需硬編碼，比如對指定區域分組匯總：選中Excel中的一批員工記錄，傳給自定義函數groupEmp，由pyxll執行分組匯總算法，并返回計算結果，只需編寫如下代碼：

import pandas as pd

import numpy as np

from pyxll import xl_func

@xl_func("dataframe<index=False, columns=True>")

def groupEmp(df):

df=df.groupby("deptid")['salary'].agg([len, np.sum, np.mean]) #核心代碼：分組匯總

return df

上面核心代碼只有一行，其他代碼基本都是定式。可以看到，具備結構化庫函數的pyxll，可以用非常簡潔的代碼實現分組匯總等簡單算法。

當然，有時也會遇到較復雜或特殊的運算，需要用多個函數組合實現，而不是單獨使用排序、過濾之類基本函數。遺憾的是，pyxll實現較復雜或特殊的運算時不太方便。

比如規范化數據并分組匯總的例子：針對Excel中的住戶戶型明細表（A-E列），自定義函數需按STYLE和BEDROOMS分組，統計SQFEET、BATHS、PRICE的平均值，其中PRICE列原本是字符串，需去掉$符號，轉為數值再計算。

處理前數據

處理后的數據在新sheet中。

實現上述算法的自定義函數如下（只保留核心代碼）：

for i in range(1, len(b)):

b[i][4] = b[i][4].replace(“$”,‘ ‘)

b[i][4] = b[i][4].replace(“,”,‘ ‘)

for i in range(1, len(b)):

for j in [1, 2, 3, 4]:

b[i][j] = eval(b[i][j])

data = pandas.DataFrame(b[1:],columns=b[0])

out = data.groupby([‘STYLE’,‘BEDROOMS’]).mean()

return out

分組還是只有一句，但前面的預處理卻要6行，有點麻煩。

再比如一行分多行的例子：A列存儲ID，B列存儲ID對應的列表List，List有多個成員，以空格為分隔符。自定義函數需將List按空格拆分，使每個ID對應一個成員。

處理前的數據

處理后的數據在新sheet中：

實現上述算法的自定義函數如下：

split_dict = df.set_index('ID').T.to_dict('list')

split_list = []

for key,value in split_dict.items():

anomalies = value[0].split(' ')

key_array = np.tile(key,len(anomalies))

split_df = pd.DataFrame(np.array([key_array,anomalies]).T,columns=['ID','ANOMALIES'])

split_list.append(split_df)

df = pd.concat(split_list,ignore_index=True)

return df

可以看到，即使只保留核心運算功能，pyxll的代碼仍然有點復雜。這就是pyxll缺點之一：不擅長實現較復雜或特殊的運算。

pyxll還有一個缺點：Excel要調用外部解釋器來解釋Python腳本，因此頓挫感較強烈，會嚴重影響用戶體驗。當然，頓挫并非pyxll獨有的問題，而是所有外部解釋型腳本共通的問題，比如XLwings、Bert和RExcel。其中XLwings與pyxll同樣是基于Python的add-ins，優缺點基本一樣。Bert和RExcel是基于R的add-ins，R專注于科學模型算法，其結構化計算類庫不夠專業，因此這兩款add-ins的計算能力還不如pyxll，頓挫感也會更強。

當然，解釋型語言也有優點，最大的優點是無需編譯即可執行，維護修改都很方便。

esProc

esProc是專業的數據計算引擎，也提供了一個Excel add-in，可以使用esProc的SPL語言編寫計算腳本。它與pyxll有很多相似之處，比如兩者都有豐富的結構化計算函數，因此可以輕松實現簡單算法，比如對指定區域分組匯總，只需編寫腳本groupEmp.dfx:

核心代碼只有A2一行，非常簡潔。之后就可以在Excel單元格中引用自定義函數groupEmp，形如=dfx("groupEmp",A1:D20)。

其他基本算法也可以輕松實現（只留核心代碼）：

通過了解之前的add-ins，我們已經可以得出結論：是否能方便地實現較復雜或特殊的運算，才是判斷一款add-in的數據計算能力的真正指標。

esProc能夠方便地實現較復雜或特殊的運算，這是它比pyxll更有優勢的地方。

比如規范化數據并分組匯總，前面用pyxll時顯得很麻煩，但esProc就簡單多了：

再比如一行分多行，esProc代碼更簡單：

再舉個邏輯更復雜的例子：計算分期貸款明細。Excel單元格記錄著貸款信息，包括貸款ID，貸款總額、按月分期數、年利率，示意如下：

自定義函數的目的是計算出各期明細，包括：當期還款額、當期利息、當期本金、剩余本金。計算結果在新sheet 中應當如下：

上面的算法用pyxll實現會很麻煩，但esProc就很方便：

看起來esProc的數據計算能力確實很強大，但是，非常遺憾的是，esProc也是基于外部解釋器的add-in，還需要JVM來執行，它同樣存在卡頓的問題。

esProc through clipboard

有沒有辦法既能利用esProc強大的計算能力，還能順滑地操作esProc？

用剪貼板代替自定義函數！

比如求各科前3名的學生：A列是學生姓名，B-D列分別是數學、英語、物理成績，需要求出每學科成績前3名的學生，并追加到本科成績之后。

處理前數據

選中這些單元格，先用ctrl+C復制到剪貼板，再在esProc腳本中執行如下代碼：

執行上述腳本后，只需在Excel的B11格用ctrl+V，即可將剪切板中的數據復制到B11-D13，達到和自定義函數相同的效果，如下：

類似的，大多數自定義函數都可以用剪切板簡單代替，除非遇到一些特殊情況，比如多片區域參與運算。

應該注意到，上述過程雖然可以到達順滑操作的目的，也可以利用到esProc強大的計算能力，但并沒有使用add-in協議。事實上，如果愿意使用剪切板，就沒必要部署復雜的add-ins，這對數據分析師來說，難道不是一件減輕負擔的好事嗎？

還應該注意到，不僅esProc可以利用剪貼板來解決卡頓的問題，pyxll等add-ins理論上也完全可以，只要它們在將來的版本中提供類似的函數（從剪切板獲取數據并轉換成內部的結構化數據類型）。

經過前面的比較，我們可以得出這樣的結論：流暢的add-ins計算能力差；計算能力強的add-ins存在卡頓現象。配合剪切板使用esProc可以彌補卡頓的缺點，更適合桌面分析師使用。

何解讀從數據需求到數倉構建的整體流程？這篇文章里，作者結合實際案例，從需求分析、可視化看板設計、數據采集、數倉規劃、維度建模等方面進行了描述和拆解，不妨來看一下，或許會對你有做幫助。

一、背景

最近發文章，發現在文章中有插入廣告功能，假設廣告插入為新上線的新功能。

1. Web端鏈路

曝光環節：每次刷新，都會有不同的內容。如下圖所示：

具體落地頁，大家可以自己點擊看看。

2. 業務需求

功能上線一個月后，老板想看看該功能帶來了多少營收？

運營人員希望分析廣告投放、廣告曝光、落地頁曝光、支付頁、支付成功轉化鏈路的轉化情況？

本文以此為背景，從需求分析、可視化看板設計、數據采集、數倉規劃、維度建模等幾個階段去描述數據需求到數倉構建的整體流程。

二、需求分析階段

1. 目的

了解清楚業務問題和目標后，搞清楚數據怎么定義和描述這個問題？列出結果指標和過程指標，確定指標的展現形式。

2. 業務過程調研

需要整體分析各角色之間存在的各類要素流動關系。

3. 需求調研

根據業務調研及業務目標，使用不同的數據分析分析方法列出指標體系，最終大致遵循常用指標分類方式。

需求調研可以從以下角度出發：

1）根據與分析師、業務運營人員的溝通獲知需求。

2）了解以前的報表，對現有報表系統中的報表進行研究分析，了解關鍵性指標。

4. 確定指標

5. 確定指標統計含義及口徑

在篩選指標時，需要考慮指標的數據來源、數據質量、數據可靠性等因素。在此過程中，需要補充數據來源系統，來源表，來源字段，計算方式等。

三、可視化看板設計階段

1. 根據指標需求設計可視化看板

2. 確定展示內容和篩選條件

1）卡片展示內容：指標名稱、統計口徑、指標值、指標單位、統計日期、同比值、環比值、更新時間。

篩選條件：日期、支持選擇今日、昨日、本周、上周、本年、去年、最近7天、最近30天等等。不能選擇今天及以后。

2）支付情況日變動趨勢圖

篩選條件：日期范圍。支持選擇今日、昨日、本周、上周、本年、去年、最近7天、最近30天等等。不能選擇今天及以后，支持按日、按月、按年去對比。

3）下單轉化漏斗

篩選條件：日期范圍，支持選擇今日、昨日、本周、上周、本年、去年、最近7天、最近30天等等。不能選擇今天及以后。

可選統計方式：次數/人數

四、數據采集階段

數據采集前需要考慮以下兩點。

1）熟悉業務數據：明確業務過程與表之間的關系，表與表之間的關系，字段之間的關聯關系。

2）調研數據源情況：是否具備采集條件，數據庫類型，存儲格式，通過什么方式采集。對缺失的用戶行為數據進行埋點。

埋點時需根據不同埋點類型以及業務情況選擇合適的埋點方案和前后端采集方案。

1. 埋點需求分析

2. 自定義埋點方案設計

標準埋點方案一般由 4 張表組成：

• 埋點說明 – 埋點實施參考
• 事件&屬性 – 記錄事及相關信息;
• 用戶屬性 – 記錄用戶與相關信息
• 默認采集事件屬性 – 默認采集的事件屬性說明

公共屬性：

自定義事件&屬性：

在設計埋點前，可做一些埋點文檔和埋點評審的規范定義，方便文檔的維護和工作的開展。

比如：事件命名由 4 部分組成：類型_流程_頁面_功能。

• 類型：點擊、進入、停留、指標
• 流程：事件所屬的業務流程，填寫規則是[流程名稱 +“流程”]
• 頁面：事件所在的頁面，填寫規則是[頁面名稱 + “頁面”]
• 功能：可以是按鈕或功能的名稱

未了保障數據的準確性，需注意觸發時機和規則定義：比如什么樣的曝光是有效的？商品停留時間超過2s，卡片至少漏過50%。商品曝光重復：如果之前已經可見且上報了，那么不做二次上報等規則。

五、數倉規劃階段

在構建數倉前，需要對數倉進行整體規劃，包括：

• 技術架構設計：數據存儲技術的選擇、ETL工具選擇、任務調度工具選擇；
• 分層架構：數倉分層規劃；
• 主題域規劃：主題域確定；
• 數據開發規范指定：命名規范、開發規范、各種流程規范；
• 元數據管理方法等等。

1. 數倉分層規劃

操作數據層：ODS(Operational Data Store)：把操作系統數據幾乎無處理地存放在數據倉庫系統中。

事實明細層：DWD(Data Warehouse Detail)：DWD 層是在ODS層基礎上，根據業務過程建模出來的事實明細層。

公共匯總層：DWS(Data Warehouse Summary)：一般根據維表數據和明細事實數據加工生成，作為通用的數據模型使用。

應用數據層：ADS(Application Data Store)：存放數據產品個性化的統計指標，根據明細層、匯總層及維表數據加工生成。

想了解更多數倉分層可查閱上篇文章《帶你輕松理解數倉為啥分層？》https://www.woshipm.com/share/5892372.html

2. 主題域規劃

我們選擇按照業務過程劃分主題域：劃分的前提，先理清業務過程，根據業務過程去抽象出主題，比如瀏覽，曝光，點擊，都屬于用戶行為的業務過程，就可以劃分成流量主題。

想了解更多主題域規劃可查閱《如何理解主題域？》。

六、數倉設計階段

1. 構建業務總線矩陣

在數據倉庫領域中，業務總線矩陣是一種用于設計和組織數據倉庫的業務模型的工具。它是基于業務需求和業務過程的分析，明確業務過程與維度的關系。它幫助將業務需求轉化為數據模型，并指導數據倉庫的建模和設計過程。

從該業務矩陣中，我們可以得知需要建設哪些DIM層維度表，DWD層的事實表。

2. 指標拆分

指標的拆分是運算過程的拆分，維度模型里的指標拆分是一種思路，是模型設計很重要的一環。想了解更多可看《原子指標、派生指標、復合指標》。

原子指標：不可再分的指標。

派生指標：派生指標是由原子指標、時間周期、修飾詞構成，用于反映企業某一業務活動在指定時間周期及目標范圍中的業務狀況。

復合指標：由派生指標直接運算而來，通常是比率型指標。比如最近七天廣告點擊率，他的特點就是產生了新的原子指標。

3. 維度表設計

根據業務總線矩陣，可構建用戶維度表、時間維度表、地理位置維度表等等。

日期維度表示例：

4. 事實表設計

此處拓展事實表構建流程。

事實表說明：

事實表包括：事務型事實表、周期快照事實表、累積快照事實表。

1）選擇業務過程及確定事實表類型

業務過程定義：業務過程是從企業的經營收益、成本出發，價值鏈條上有影響力的用戶需求事情或者事件。而且，這樣的過程非常多，我們要分析當中的核心關鍵過程，不斷細分。

核心內容：企業活動事件、不可拆分原則。

2）聲明粒度：定義事實表的每一行所表示的業務含義，盡量選擇最細級別的原子粒度，以確保事實表的應用具有最大的靈活性。

3）確定維度：選擇能夠描述清楚業務過程所處的環境的維度信息。

4）確定事實：事實有可加性、半可加性、非可加性三種類型 需要將不可加性事實分解為可加的組件。

5）冗余維度：考慮更多的是提高下游用戶的使用效率，降低數據獲取的復雜性，減少關聯的表數量。

文章閱讀事實表：

頁面瀏覽事實表：

下單累計快照事實表：

交易域每日支付匯總表：

流量域每日曝光匯總表：

根據需求，匯總表還需要統計每月、每年、近7天、近30天等數據匯總情況，此處不做過多表格展示。需要注意命名規范以及事實是否可加。