2017 JavaScript 現(xiàn)狀報告：詢問了23000名開發(fā)者，他們給出了這樣的答案

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

我最近公布了我們2017年版的JavaScript年度現(xiàn)狀調(diào)查報告的結(jié)果，這是23000位開發(fā)者的共同反饋。

從流行趨勢到工資明細(xì)，結(jié)果揭示了很多事情。如果你還沒有這么做的話最好自己進(jìn)來看看。但是在所有這些數(shù)據(jù)當(dāng)中，有10件事情是最重要的。

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

洞察#1：React站穩(wěn)腳跟

今年的版本確認(rèn)了去年的趨勢：React目前是占據(jù)主導(dǎo)地位的前端庫。

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

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

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

洞察#2：Angular正朝著新的角色轉(zhuǎn)變

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

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

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

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

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

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

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

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

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

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

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

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

如結(jié)果表明那樣，往往是像Polymer或者Reason這樣的小眾技術(shù)跟最高薪水相關(guān)。

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

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

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

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

如果你跟絕大部分的調(diào)查受訪者一樣的話，你應(yīng)該已經(jīng)聽說過GraphQL并且對它饒有興趣了，但其實(shí)你還沒有嘗試過。

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

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

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

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

洞察#6：JavaScript != 前端

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

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

這臺烤面包機(jī)利用運(yùn)行Slack的桌面應(yīng)用產(chǎn)生的熱量來烤面包

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

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

洞察#7：微軟正在反擊

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

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

VS Code編輯器

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

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

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

當(dāng)我們討論JavaScript時，我們往往把它當(dāng)作一個統(tǒng)一的生態(tài)體系來討論。盡管重要趨勢不同地區(qū)都是一致的，但有趣的是不同的國家往往會給JavaScript添加一些自己的定西進(jìn)去。

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

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

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

TypeScript、GraphQL、Elm、Reason，這些之間有何共同點(diǎn)？首先，它們都是先進(jìn)技術(shù)，正在迅速發(fā)展。其次，它們都依賴于類型。

名字前正好有個“Type”。

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

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

洞察#10：百變JavaScript

再次地，這次的調(diào)查表明了JavaScript的生態(tài)體系已經(jīng)變得如何的豐富。

似乎經(jīng)過多年時而批斗時而無視JavaScript之后，開發(fā)者社區(qū)終于突然想到了第三個選項：改進(jìn)它。

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

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

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

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

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

Excel DNA

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

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

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;

}

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

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

</DnaLibary>

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

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

Excel DNA的其他優(yōu)點(diǎn)從名字就可以看出來，換句話說，該add-in可以充分利用微軟DNA架構(gòu)提供的便利，比如開發(fā)語言、開發(fā)工具、Excel集成、聯(lián)動調(diào)試等。

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

因為理論和實(shí)際是有差別的。

C#/F#/VB.net等語言缺乏結(jié)構(gòu)化計算類庫，即使最基本的運(yùn)算都要硬編碼實(shí)現(xiàn)，代碼因此非常繁瑣，并不適合做復(fù)雜的數(shù)據(jù)計算。

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

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

Excel JavaScript

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

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

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

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

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

唯一的問題是，界面控制并非數(shù)據(jù)計算add-ins的重點(diǎn)，不值得我們關(guān)注……

不錯，既然講的是數(shù)據(jù)計算add-ins，那數(shù)據(jù)計算能力才是關(guān)注重點(diǎn)，而不是界面控制能力。但遺憾的是，JavaScript依然沒有任何結(jié)構(gòu)化計算函數(shù)，用于做Excel都難以實(shí)現(xiàn)的數(shù)據(jù)計算也沒啥特別的優(yōu)勢，僅僅是讓Excel多了一種不同于VBA的腳本語言而已。

pyxll

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

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

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

上面核心代碼只有一行，其他代碼基本都是定式?？梢钥吹?，具備結(jié)構(gòu)化庫函數(shù)的pyxll，可以用非常簡潔的代碼實(shí)現(xiàn)分組匯總等簡單算法。

當(dāng)然，有時也會遇到較復(fù)雜或特殊的運(yùn)算，需要用多個函數(shù)組合實(shí)現(xiàn)，而不是單獨(dú)使用排序、過濾之類基本函數(shù)。遺憾的是，pyxll實(shí)現(xiàn)較復(fù)雜或特殊的運(yùn)算時不太方便。

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

處理前數(shù)據(jù)

處理后的數(shù)據(jù)在新sheet中。

實(shí)現(xiàn)上述算法的自定義函數(shù)如下（只保留核心代碼）：

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

分組還是只有一句，但前面的預(yù)處理卻要6行，有點(diǎn)麻煩。

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

處理前的數(shù)據(jù)

處理后的數(shù)據(jù)在新sheet中：

實(shí)現(xiàn)上述算法的自定義函數(shù)如下：

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

可以看到，即使只保留核心運(yùn)算功能，pyxll的代碼仍然有點(diǎn)復(fù)雜。這就是pyxll缺點(diǎn)之一：不擅長實(shí)現(xiàn)較復(fù)雜或特殊的運(yùn)算。

pyxll還有一個缺點(diǎn)：Excel要調(diào)用外部解釋器來解釋Python腳本，因此頓挫感較強(qiáng)烈，會嚴(yán)重影響用戶體驗。當(dāng)然，頓挫并非pyxll獨(dú)有的問題，而是所有外部解釋型腳本共通的問題，比如XLwings、Bert和RExcel。其中XLwings與pyxll同樣是基于Python的add-ins，優(yōu)缺點(diǎn)基本一樣。Bert和RExcel是基于R的add-ins，R專注于科學(xué)模型算法，其結(jié)構(gòu)化計算類庫不夠?qū)I(yè)，因此這兩款add-ins的計算能力還不如pyxll，頓挫感也會更強(qiáng)。

當(dāng)然，解釋型語言也有優(yōu)點(diǎn)，最大的優(yōu)點(diǎn)是無需編譯即可執(zhí)行，維護(hù)修改都很方便。

esProc

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

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

其他基本算法也可以輕松實(shí)現(xiàn)（只留核心代碼）：

通過了解之前的add-ins，我們已經(jīng)可以得出結(jié)論：是否能方便地實(shí)現(xiàn)較復(fù)雜或特殊的運(yùn)算，才是判斷一款add-in的數(shù)據(jù)計算能力的真正指標(biāo)。

esProc能夠方便地實(shí)現(xiàn)較復(fù)雜或特殊的運(yùn)算，這是它比pyxll更有優(yōu)勢的地方。

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

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

再舉個邏輯更復(fù)雜的例子：計算分期貸款明細(xì)。Excel單元格記錄著貸款信息，包括貸款I(lǐng)D，貸款總額、按月分期數(shù)、年利率，示意如下：

自定義函數(shù)的目的是計算出各期明細(xì)，包括：當(dāng)期還款額、當(dāng)期利息、當(dāng)期本金、剩余本金。計算結(jié)果在新sheet 中應(yīng)當(dāng)如下：

上面的算法用pyxll實(shí)現(xiàn)會很麻煩，但esProc就很方便：

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

esProc through clipboard

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

用剪貼板代替自定義函數(shù)！

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

處理前數(shù)據(jù)

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

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

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

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

還應(yīng)該注意到，不僅esProc可以利用剪貼板來解決卡頓的問題，pyxll等add-ins理論上也完全可以，只要它們在將來的版本中提供類似的函數(shù)（從剪切板獲取數(shù)據(jù)并轉(zhuǎn)換成內(nèi)部的結(jié)構(gòu)化數(shù)據(jù)類型）。

經(jīng)過前面的比較，我們可以得出這樣的結(jié)論：流暢的add-ins計算能力差；計算能力強(qiáng)的add-ins存在卡頓現(xiàn)象。配合剪切板使用esProc可以彌補(bǔ)卡頓的缺點(diǎn)，更適合桌面分析師使用。

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

一、背景

最近發(fā)文章，發(fā)現(xiàn)在文章中有插入廣告功能，假設(shè)廣告插入為新上線的新功能。

1. Web端鏈路

曝光環(huán)節(jié)：每次刷新，都會有不同的內(nèi)容。如下圖所示：

具體落地頁，大家可以自己點(diǎn)擊看看。

2. 業(yè)務(wù)需求

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

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

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

二、需求分析階段

1. 目的

了解清楚業(yè)務(wù)問題和目標(biāo)后，搞清楚數(shù)據(jù)怎么定義和描述這個問題？列出結(jié)果指標(biāo)和過程指標(biāo)，確定指標(biāo)的展現(xiàn)形式。

2. 業(yè)務(wù)過程調(diào)研

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

3. 需求調(diào)研

根據(jù)業(yè)務(wù)調(diào)研及業(yè)務(wù)目標(biāo)，使用不同的數(shù)據(jù)分析分析方法列出指標(biāo)體系，最終大致遵循常用指標(biāo)分類方式。

需求調(diào)研可以從以下角度出發(fā)：

1）根據(jù)與分析師、業(yè)務(wù)運(yùn)營人員的溝通獲知需求。

2）了解以前的報表，對現(xiàn)有報表系統(tǒng)中的報表進(jìn)行研究分析，了解關(guān)鍵性指標(biāo)。

4. 確定指標(biāo)

5. 確定指標(biāo)統(tǒng)計含義及口徑

在篩選指標(biāo)時，需要考慮指標(biāo)的數(shù)據(jù)來源、數(shù)據(jù)質(zhì)量、數(shù)據(jù)可靠性等因素。在此過程中，需要補(bǔ)充數(shù)據(jù)來源系統(tǒng)，來源表，來源字段，計算方式等。

三、可視化看板設(shè)計階段

1. 根據(jù)指標(biāo)需求設(shè)計可視化看板

2. 確定展示內(nèi)容和篩選條件

1）卡片展示內(nèi)容：指標(biāo)名稱、統(tǒng)計口徑、指標(biāo)值、指標(biāo)單位、統(tǒng)計日期、同比值、環(huán)比值、更新時間。

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

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

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

3）下單轉(zhuǎn)化漏斗

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

可選統(tǒng)計方式：次數(shù)/人數(shù)

四、數(shù)據(jù)采集階段

數(shù)據(jù)采集前需要考慮以下兩點(diǎn)。

1）熟悉業(yè)務(wù)數(shù)據(jù)：明確業(yè)務(wù)過程與表之間的關(guān)系，表與表之間的關(guān)系，字段之間的關(guān)聯(lián)關(guān)系。

2）調(diào)研數(shù)據(jù)源情況：是否具備采集條件，數(shù)據(jù)庫類型，存儲格式，通過什么方式采集。對缺失的用戶行為數(shù)據(jù)進(jìn)行埋點(diǎn)。

埋點(diǎn)時需根據(jù)不同埋點(diǎn)類型以及業(yè)務(wù)情況選擇合適的埋點(diǎn)方案和前后端采集方案。

1. 埋點(diǎn)需求分析

2. 自定義埋點(diǎn)方案設(shè)計

標(biāo)準(zhǔn)埋點(diǎn)方案一般由 4 張表組成：

埋點(diǎn)說明 – 埋點(diǎn)實(shí)施參考
事件&屬性 – 記錄事及相關(guān)信息;
用戶屬性 – 記錄用戶與相關(guān)信息
默認(rèn)采集事件屬性 – 默認(rèn)采集的事件屬性說明

公共屬性：

自定義事件&屬性：

在設(shè)計埋點(diǎn)前，可做一些埋點(diǎn)文檔和埋點(diǎn)評審的規(guī)范定義，方便文檔的維護(hù)和工作的開展。

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

類型：點(diǎn)擊、進(jìn)入、停留、指標(biāo)
流程：事件所屬的業(yè)務(wù)流程，填寫規(guī)則是[流程名稱 +“流程”]
頁面：事件所在的頁面，填寫規(guī)則是[頁面名稱 + “頁面”]
功能：可以是按鈕或功能的名稱

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

五、數(shù)倉規(guī)劃階段

在構(gòu)建數(shù)倉前，需要對數(shù)倉進(jìn)行整體規(guī)劃，包括：

技術(shù)架構(gòu)設(shè)計：數(shù)據(jù)存儲技術(shù)的選擇、ETL工具選擇、任務(wù)調(diào)度工具選擇；
分層架構(gòu)：數(shù)倉分層規(guī)劃；
主題域規(guī)劃：主題域確定；
數(shù)據(jù)開發(fā)規(guī)范指定：命名規(guī)范、開發(fā)規(guī)范、各種流程規(guī)范；
元數(shù)據(jù)管理方法等等。

1. 數(shù)倉分層規(guī)劃

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

事實(shí)明細(xì)層：DWD(Data Warehouse Detail)：DWD 層是在ODS層基礎(chǔ)上，根據(jù)業(yè)務(wù)過程建模出來的事實(shí)明細(xì)層。

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

應(yīng)用數(shù)據(jù)層：ADS(Application Data Store)：存放數(shù)據(jù)產(chǎn)品個性化的統(tǒng)計指標(biāo)，根據(jù)明細(xì)層、匯總層及維表數(shù)據(jù)加工生成。

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

2. 主題域規(guī)劃

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

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

六、數(shù)倉設(shè)計階段

1. 構(gòu)建業(yè)務(wù)總線矩陣

在數(shù)據(jù)倉庫領(lǐng)域中，業(yè)務(wù)總線矩陣是一種用于設(shè)計和組織數(shù)據(jù)倉庫的業(yè)務(wù)模型的工具。它是基于業(yè)務(wù)需求和業(yè)務(wù)過程的分析，明確業(yè)務(wù)過程與維度的關(guān)系。它幫助將業(yè)務(wù)需求轉(zhuǎn)化為數(shù)據(jù)模型，并指導(dǎo)數(shù)據(jù)倉庫的建模和設(shè)計過程。

從該業(yè)務(wù)矩陣中，我們可以得知需要建設(shè)哪些DIM層維度表，DWD層的事實(shí)表。

2. 指標(biāo)拆分

指標(biāo)的拆分是運(yùn)算過程的拆分，維度模型里的指標(biāo)拆分是一種思路，是模型設(shè)計很重要的一環(huán)。想了解更多可看《原子指標(biāo)、派生指標(biāo)、復(fù)合指標(biāo)》。

原子指標(biāo)：不可再分的指標(biāo)。

派生指標(biāo)：派生指標(biāo)是由原子指標(biāo)、時間周期、修飾詞構(gòu)成，用于反映企業(yè)某一業(yè)務(wù)活動在指定時間周期及目標(biāo)范圍中的業(yè)務(wù)狀況。

復(fù)合指標(biāo)：由派生指標(biāo)直接運(yùn)算而來，通常是比率型指標(biāo)。比如最近七天廣告點(diǎn)擊率，他的特點(diǎn)就是產(chǎn)生了新的原子指標(biāo)。

3. 維度表設(shè)計

根據(jù)業(yè)務(wù)總線矩陣，可構(gòu)建用戶維度表、時間維度表、地理位置維度表等等。

日期維度表示例：

4. 事實(shí)表設(shè)計

此處拓展事實(shí)表構(gòu)建流程。

事實(shí)表說明：

事實(shí)表包括：事務(wù)型事實(shí)表、周期快照事實(shí)表、累積快照事實(shí)表。

1）選擇業(yè)務(wù)過程及確定事實(shí)表類型

業(yè)務(wù)過程定義：業(yè)務(wù)過程是從企業(yè)的經(jīng)營收益、成本出發(fā)，價值鏈條上有影響力的用戶需求事情或者事件。而且，這樣的過程非常多，我們要分析當(dāng)中的核心關(guān)鍵過程，不斷細(xì)分。

核心內(nèi)容：企業(yè)活動事件、不可拆分原則。

2）聲明粒度：定義事實(shí)表的每一行所表示的業(yè)務(wù)含義，盡量選擇最細(xì)級別的原子粒度，以確保事實(shí)表的應(yīng)用具有最大的靈活性。

3）確定維度：選擇能夠描述清楚業(yè)務(wù)過程所處的環(huán)境的維度信息。

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

5）冗余維度：考慮更多的是提高下游用戶的使用效率，降低數(shù)據(jù)獲取的復(fù)雜性，減少關(guān)聯(lián)的表數(shù)量。

文章閱讀事實(shí)表：

頁面瀏覽事實(shí)表：

下單累計快照事實(shí)表：

交易域每日支付匯總表：

流量域每日曝光匯總表：

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

在線咨詢

上一篇：CSS Float(浮動)
下一篇：解密權(quán)限管理：使用位運(yùn)算在JavaScript中權(quán)限控制（面試題）

您的項目需求

*請認(rèn)真填寫需求信息，我們會在24小時內(nèi)與您取得聯(lián)系。

整合營銷服務(wù)商

2017 JavaScript 現(xiàn)狀報告：詢問了23000名開發(fā)者，他們給出了這樣的答案