節假日最適合做的事，是從日常事務里跳出來，嘗試做一些抽象思考，例如說，紛繁複雜的互聯網數據工作，大體是怎樣一個架構，通俗地說，也就是內部結構和具體工作分布。

作為類比，先看看已經被佈道好多年的，相對成熟的互聯網產品流程：

需求產生的環節在業務，比如財務、市場，包括內外部；

需求翻譯到用例的環節是售前，產品，測試；

用例進入開發流程以後，對產品流程來說進入一個黑盒，圍繞實現，輔助職能分布在進度控制，性能優化，基礎運維，需大概了解；

需求實現以後，逆向走開發-測試-產品-業務去核驗和優化，循環這個過程，形成工作流。

互聯網數據工作流也可以這樣分，如下圖。概括一下職能分布，1是技術，2是業務模式，3是商業智能，4是學術。

1的環節是外部爬蟲和內部埋點

表面上看，這是一個」上帝說，要有光，於是就有了光「的業務步驟，實際這是一個純粹技術的領域，例如爬蟲的資源調度，埋點的性能平衡，後台海量存儲等等。

（創業公司基本都用第三方，因為自己做太奢侈了，有理想/有機會的大司CTO都會自己搭，很鍛煉團隊，同時大團隊會有人出去創業，形成技術溢出，福澤沒有能力的中小網站。）

為了方便表達，插一個例子，假如我們用溫度計測水溫，溫度計本身是涼的，那麼測出的水溫就可能偏低一丁點（量子力學裡更有所謂，看一眼，用來觀察的粒子影響被觀察粒子，狀態就變化的測不準原理。）

與此類似，互聯網數據最好玩的地方是，為了通過數據觀察一個應用的各方面表現，取數方法本身也是一個應用，因此如上所述的」觀察方法對觀察結果的干擾「就特別大。

我們經常聽到互聯網數據講座里，花n小時說ga的老版本js和新版本ua有什麼不同，或者各種tag manage工具的數據對接坑，做互聯網數據的人對此是習以為常的，你可以完全不知道如何寫代碼，但你必須知道一堆的同步非同步，cookie、uuid的術語。

具有諷刺意味的是，步驟1里的工程師往往不知道提數據需求的人到底想做什麼（有時候是真的沒人知道，埋著當買保險），他們接下去會在沒有使命感的情況下，煩惱性能和如何在混亂的版本合併里保持一切井井有條，而沒有使命感，對於代碼質量經常有致命的負面影響。（因為代碼質量無法用傳統方法qa，純靠良知操守和使命感）

小結一下，1的環節是純粹技術的、門檻很高的環節（索性有大量現成第三方，這也是為什麼說現在數據的時代來臨了，之前很痛苦），所有非技術的、要用到數據的同學都必須有1的基本知識，在下一步的數據清洗，異常識別和指標排障里有很大用處。

2的環節是把源數據洗乾淨，變成可以看的指標

按道理2是技術環節（比如cookie傳值和uv的對應規則），但是因為互聯網廣告的高度發達（都是燒錢燒太多搞出來的），這方面已經有很成熟的用來解釋和優化燒錢的數據指標體系，實際上2已經是純業務的環節。（例如，由於pv、uv、visit過於有知名度，很多人會忘記這些也只是一些自定義指標而已。）

這個步驟往往由業務部門的分析師進行，主要工作概括起來，是使常人能夠理解數據，將原始日誌/數據集，翻譯成一些比如轉化率，比如獨立訪客帶來的收入之類直觀的數字，進而形成一些簡單報表，基於對這些報表的使用，來支持拍腦袋（也叫決策）。

在水平較成熟的團隊里，會看到大量自定義指標，這些指標的建立原則很簡單，針對kpi，或者更時髦的okr（模糊版的kpi），比如視頻來說，基本的訪問量和播放量之外，可以有播放中拉條快進的比例（不要想歪）之類，來細緻考察用戶感興趣的程度。

這個」解釋和使用數據「的環節，是市面上絕大多數所謂做數據的人的日常工作（比如廣告公司，比如傳統公司市場部、信息部、電商部，第三方運營等等），雖然門檻很低，但由於大部分企業現在數據意識剛剛覺醒，需求大的驚人，完全供不應求。

3的環節開始小眾，是所謂用大數據解決實際問題

還是舉例，比如一個OTA經過1和2的步驟，有了客人預訂各區域酒店的數據，有了訂單量流量轉化率，也有自己的成本，有該區域的資源分布情況，以及爬蟲獲取的對手的大致資源情況-無非是價格啊庫存啊覆蓋啊，或許還有點評之類。

那我們要解決問題，比如我希望將市場區域分成諮詢公司常說的各種動物的分類，不同分類對應不同競爭階段（或動物），不同階段有不同增長預期，同時可以輔助各渠道預算分配，和2不同的是，2隻要有個報表參考，3可以給出基於一定概率的結果。

3的環節是商業智能BI出場的時候（遺憾的是大部分BI還在2的世界裡，甚至1的世界裡）。

這裡主要的任務和1很像，克服性能瓶頸。只不過不是爬蟲和埋點的性能，我們這次並不會爬的競爭對手網站癱瘓，或者搞得用戶在app點擊下一步的時候為了傳輸他選的增值產品而卡死在中間，這次可能卡死的是後續的分析模型，為了能反覆迭代，必須在進入挖掘之前，找出少數主要特徵。

傳統經驗模式，講究靠老師傅從幾千個可能出問題的地方指出最可能的幾個，數據規約就是通過對幾千個指標的相似度/信息量/不確定性的計算，來將這類老師傅經驗變成一個可復用的函數。

舉例子來說，如果研究肥胖，有四個數據，一是每天吃幾頓飯，二是每頓吃幾碗，三是每天攝入的卡路里量，四是每天運動消耗卡路里量。老師傅會說，你傻啊，前三個可以合併一個，而數據規約是通過指標選擇演算法（比如lasso）給重複指標打很大的懲罰分，也可以得到前三個指標只需留一個的結論。

3的世界是反反覆復和業務方（2的人們）聊需求到底是什麼，目標是翻譯成數學語言；同時反反覆復和數據來源方（1的人們）聊異常值，目標是理性對待奇怪的看似是誤差的數據，不要為了預測而預測（過度擬合和擬合不足）。

在充分了解的基礎上，下面就可以把數據往聚合分類、多階（說人話，比如斜率）等各種複合方向，套業務需求形成二次計算過的專門指標，儘可能減少數據維數（好吧用人話來說，就是列數），只留下最關鍵的優化過的複合維度，並且儘可能合理地處理（或解釋）源數據的瑕疵。

這時會發現當一切準備好以後（花了95%的時間），現成的一堆模型和驗證打分工具，直接去跑，對比結果就好了。後續整合發布到生產（實時推薦之類）等等的工作，已經不算數據工作流，而是進入傳統互聯網產品流程，雙方對彼此來說都是黑盒。

回過神來，你可能會說，那這些現成的模型靠譜么？

我們進入4的世界，桃花源里的學術世界

學術世界的仙人們其實和1一樣，遠離整個數據工作的對於企業來說的初衷，他們既不考慮數據怎麼來的，也不考慮某種生活現象為什麼要服從某種分布，這裡只關心模型本身的數學特徵（和流派），對123世界的凡塵俗世的人來說，也許剛畢業的時候還期待大數據應該是玩4，工作一段時間以後才發現2才是真相。

只有很少的人能一直留在學術道路上，雖然統計學是數學裡很low的分支，但是卻是最接地氣的分支，比如，你能把圖片的模糊和精細，往顏色值的矩聯想么?統計學家會告訴你這是常識，根本不用解釋。可見概率的思考方式，會導致比程序員思考模式更大地有異與常人。

那麼圖上4為啥能回到1呢?

我們回到3的BI工程師隊伍里，如果建模以後，發現運氣不太好，無論參數怎麼調，匹配的程度都並不好，那麼有兩個方向：

一個是比較PR比較酷的方向，例如不斷嘗試學術世界4的新模型，或者乾脆搞kaggle這樣的數據大賽，徵集學生的突發奇想，避免數據規約中的"歷史經驗『』路徑依賴，時髦的說法叫產學研聯動；

另一個更契合實際的方向，是把匹配失敗的例子抽樣出來，看看是不是漏掉特徵，沒洗乾淨，或者需要額外維度之類，總之去步驟2和步驟1里補，這個方向很苦，一點也不酷。

注意大部分PR文章說的大數據」不需要理解為什麼，只需扔進去所有數據，然後看結果「，就是指預期的匹配失敗，反而發現一些意外結果的情況。

實際上絕大多數進入建模分析的都是精挑細選過的維度，是經過反覆認真的調研和理解的，只是結果有偶然發現而已。不可能是隨意亂看，性能不允許。

這樣一來，4就回到了1，經過這樣一個循環，越來越多的數據被採集，被指標化，和被用來建立老師傅經驗函數，以解決實際問題（而且老師傅函數可以嵌套迭代，這對現實世界的老師傅來說就有難度了）。

作為結尾

全局看工作流可能並不解決實際問題，但是經常定位自己和周邊，是不錯的習慣。

而且這個簡單的圓圈1234圖也可以作為一個所謂職業規劃的大體方向，畢竟現在查詢如何轉行大數據的關鍵字流量是越來越高了。

謝謝閱讀。

推薦閱讀：