2015年6月17日是我在Twitter工作兩周年的紀念日。回想起來，兩年間，數據科學在Twitter的應用方式和范圍發生了很大變化：
· 工具的智能化上，Pig已經過時了，現在的數據流水線都是用Scalding(建立在串聯之上的Scala領域特定語言，便于詳細描述Hadoop MapReduce任務——譯者注)編譯的。
· 組織結構上，數據科學家和產品經理、工程師的工作環環相嵌，合作之密切史無前例。
以上只是眾多改變中的一小部分。拿我來說，我的研究領域最近從Growth延伸到PIE (Product產品, Instrumentation實施, and Experimentation實驗) ，工作是研究Twitter自家開始的A/B測試平臺上的統計學方法。
在Twitter工作真的很刺激。在這里，我能直接觀察學習一個大型科技公司是如何使用數據與數據科學來創造競爭優勢的。
與此同時，人們對于數據科學的需求與渴望在不斷攀升。
“大數據就像青春期的性：每個人都在討論，但鮮有人在行，大家覺得所有人都在做，所以大家都聲稱自己在做。”——Dan Ariely（行為經濟學大牛，著有《怪誕行為學》—譯者注）
關于如何成為一名數據科學家的討論有很多很多。盡管這些探討信息量都很大（我便是眾多受益者之一），人們總是傾向于過分強調技術、工具和技巧的重要性。我以為，對于那些有志成為數據科學家的人來說，充分了解數據科學家的實戰操作是怎樣一番體驗，是同等重要的。
因此，在我在Twitter工作兩周年之際，我希望以這次回顧為契機來分享我的個人經歷，同時希望數據科學行業的同事們也能加入到這個行列中！
來Twitter之前，我以為數據科學家都是“珍稀動物”——做數學/統計/計算機/機器學習/ 算法/數據可視化等等出身。另外，寫作技巧和溝通能力與專業技能同等重要。進一步講，在執行任務的過程中，理清項目環節中的輕重緩急、領導團隊、管理項目的能力是最最重要的。除此以外，你還應該向大眾傳播一下由數據驅動的文化是多么美好。Good luck!
在Twitter工作了幾個月后，我發現“珍稀動物”們確實存在，但對于大多數努力躋身于“珍稀動物”行列的數據工作者來說，一下子掌握那么多學科是不現實也不可能的。也就是說，幾乎所有和數據沾邊的東西都和“數據科學”這個概念是相關的。那時，還是菜鳥一枚的我，尋找自己定位的時候感覺怯生生的。
久而久之，我意識到數據科學家可以被分為對立的兩類。這種分類有些過于簡單粗暴，卻十足精準。Quora用戶Michael Hochster將我想表達的這種分類方法漂亮地總結如下：
A型數據科學家：A，即Analysis（分析）。分析型數據科學家主要致力于尋找數據背后的含義，或是以一種靜態的方式使用這些數據。分析型數據科學家類似于統計學家（他們很可能本來就是搞統計的），但他們還懂得統計課程里不涉及的與數據工作相關的具體的實際操作，比如數據清理、大型數據集、數據可視化、對某一領域的深度了解和如何用數據講一個漂亮的故事，等等。
B型數據科學家：B，即Building（構建）。構建型數據科學家和分析型分局科學家的共同點是都有統計學背景，但前者還是編程高手，抑或是訓練有素的軟件工程師。構建型數據科學家的關注點是把數據“投入生產”。他們建立的模型通常以“推薦”的方式與用戶互動，比如產品、你可能認識的人、廣告、電影、搜索結果等。
真希望自己早些知道這兩種數據科學家的分別。如果你想成為一名數據科學家，留意這種分別——這對你選擇職業道路以及做取舍是非常有幫助的。
個人而言，我是學數學、操作研究和統計出身的。我認為我是一名分析型數據科學家，但我非常享受用到編程設計的構建型項目！
在初期創業公司、成長期創業公司和具有一定規模的公司擔任數據科學家，工作異同有哪些？
技術型人才找工作時往往要考慮，是去大企業任職，還是加入小型企業。雖然關于這種選擇的討論有很多，但針對數據科學家的討論就很少了——即，企業的發展階段與規模各有不同，那么數據科學家在這些企業里扮演的角色會有什么不同呢？
處于不同發展階段的企業所產生的數據的速度、種類和量級是不同的。對于一個正在探索產品定位的創業公司，他們多半用不到Hadloop這樣的軟件，因為這種公司并沒有那么多數據可處理。成長性創業公司通常會產生更密集的數據，但對他們來講，PostgreSQL和Vertica這樣的數據庫管理系統就足夠了。但是像Twitter這種規模的公司，就必須使用Hadoop和MapReduce來處理數據了。
我在Twitter學到了重要的一課——數據科學家從數據中提煉、創造價值的能力與企業數據平臺的成熟度是高度相關的。如果你想保證達到企業和個人之間雙向選擇的最優化，做到以下是機智而關鍵的：搞清自己到底想做什么類型的數據科學工作，然后下功夫衡量這個企業的體制設施能不能幫你實現你的目標。
發展初期的創業公司：數據分析主要致力于執行記錄(log)，建立ETL過程（Extract-Transform-Load 的縮寫，用來描述將數據從來源端經過抽取（extract）、轉換（transform）、加載（load）至目的端的過程——譯者注），模擬數據，設計一個框架來追蹤并儲存數據。這種公司的工作重點在于打好分析數據的基礎，而不是分析數據本身。
發展中期的創業公司：企業在成長，相應地，企業的數據也會增長。數據平臺需要適應增長的數據，但由于數據的“地基”已經建好了，公司會自然地從單純收集數據轉向從數據中形成觀點、提煉價值。除非這個企業本來對數據的戰略用途就是非常規的，大多數分析型工作主要涉及定義關鍵績效指標、促進業績增長、尋找增長的下個契機。
達到一定規模的公司：企業規模增長，數據規模會跟著增長。這時，企業需要利用數據創造或保持它的競爭優勢，比如：搜索結果要更加優化、推薦內容的相關性要更高、物流與企業運作要更加高效。機器學習工程師、企業運營優化專家、實驗設計者之類的專家能夠有效幫助企業實現以上各種訴求。
我入職的時候，Twitter的數據平臺已經非常成熟了，基礎設施也非常穩定。數據倉庫干凈而穩定，ETL過程可以日常性、毫無壓力地處理無數MapReduce任務。最重要的是，在這里，有一群優秀的數據科學家們致力于數據平臺、產品的洞悉、Growth、實驗、檢索/相關性以及許許多多其他方面的工作。
我是第一個專攻Growth的數據科學家。告訴你一個真實的故事：產品部門、工程部門和數據科學部門花了好幾個月才共同認識到數據科學在Growth中扮演著至關重要的角色。根據與產品部門密切合作的經歷，我的工作內容可以分為以下四大類：
產品洞見
數據流水線
A/B測試
建模
下面我會分別我做這幾類工作的經歷與心得。
產品洞見在消費者技術公司做數據科學有個獨特之處：我們可以利用數據來理解并推測用戶的意見和偏好。當用戶與產品互動時，我們能記錄到有價值的數據與元數據（描述其他數據并提供相關信息的數據集），把它們儲存起來以便日后分析。
這個過程叫做“記錄日志”或“測量”，而且在不斷升級。數據科學家們經常會因為數據不正常、數據不匹配或數據缺失而難以開展某一項分析。這時候，和工程師建立良好的工作關系就顯得很重要了：數據科學家可以幫助工程師識別系統中的bug和意外行為。反過來，工程師可以幫數據科學家縮小數據斷層，讓數據變得更豐富、相關性更強、更精確。
以下是我在Twitter做的幾個典型的產品分析：
推送消息分析——多少用戶適用推送消息？這個比例是用戶組維度的嗎？還是客戶端維度？各種類型的推送消息點擊率是多少？
短信投放率——如何計算不同移動運營商下Twitter的短信投放率？新興國家用戶的投放率更低嗎？如何提高這一比率呢？
多個賬戶——為什么某些國家的用戶擁有多個Twitter號的比例更高？人們使用多個Twitter號的動機是什么？
具體分析形式多種多樣——對簡單的數據行為（推送分析）給出直白的解釋；創造新生（卻重要的）業務指標的計算方法；最后，你可能會負責深入分析用戶行為（小號）。
通過產品分析進而形成洞見是一個迭代過程。想做到這一點，你需要質疑以上問題的答案，理解產品所處的業務環境，找到合適的數據集來解決問題。久而久之，你將能夠熟練地定位你需要的那組數據并對其含義了如指掌。你將能夠準確地估算做一項分析需要多長時間。更重要的是，你會逐漸從被動轉為主動，提出新穎有趣的分析角度——產品負責人可能都沒想到，因為他們根本不知道某組數據的存在，抑或是不知道截然不同的數據源可以以某種方式互補結合。
涉及的技能：
記錄日志和測量。識別數據斷層。與工程師建立良好的工作關系。
定位、識別并使用相關數據集。
理解類型的分析，準確估算各種分析的耗時或難易程度。
玩轉查詢語言。能用R或Python做典型的數據處理。
數據流水線雖然分析型數據科學家不怎么寫直接面對用戶的代碼，為了處理數據流水線，我們還是會經常向代碼庫貢獻一些代碼。
如果你對Unix公司的Pipe（一個運行一系列指令的操作）有所耳聞，數據流水線就很好理解了——不過是一系列操作，整合在一起以后能夠自動捕捉數據，循環地處理并整合數據。
我在Twitter以前的公司任職時，所做的分析工作大多是Ad-Hoc(Ad-Hoc結構是一種省去了無線中介設備AP而搭建起來的對等網絡結構)。我一般只在自己的電腦上跑程序，也就跑個一兩次、兩三次。幾乎沒有人來檢查我的代碼寫的怎么樣；運行的時候也不會控制代碼的版本。寫數據流水線的時候，一系列問題就出現了：依賴關系管理、計劃安排、資源配置、監測、錯誤報告，甚至還有警報。
下面是創建數據流水間的典型過程示例：
首先，你認識到，循環性地生產數據集將會是一件功德無量的事。
確認了這個需求以后，你先設計出最終產品，例如設計輸出數據集的數據架構。
根據數據所在環境用Pig, Scalding或SQL寫代碼。
把代碼提交至code review（代碼評審），準備改代碼。也許你的商業邏輯有問題，或者你的代碼沒能做到速度與效率的最優化。
也許你需要測試程序，空運行（不帶數據跑代碼——譯者注）一下，看看代碼是否運行正常。
整合代碼。把代碼配置好，安排好每一個事項。
設置監控、錯誤報告、警報機制，以防代碼運行出錯。
數據流水線顯然比臨時性分析復雜得多，但數據流水線的好處是，它可以自動運轉，生產出來的數據可以被儀表板所利用，這樣更多的用戶就可以使用你的數據或結果。更重要（但往往被忽視）的一點是，簡歷數據流水線的過程是個軟件工程實操的絕佳機會。你可以為日后建立專業化流水線打好基礎，比如機器學習模型（本文最后一部分會對此進行詳細說明）、A/B測試平臺。
涉及的技能：
版本控制。一般來講，最常用的工具是Git（軟件開發時用到的源代碼管理系統——譯者注）。
學會做code review，迅速地給出反饋。
程序出錯時，知道該怎么測試、空運行、找bug。
掌握依賴管理、計劃安排、資源配置、監測、錯誤報告，以及給出提示信息。
A/B測試此時此刻，你用的Twitter APP很有可能和我的有所不同，很可能你有的功能我沒有。從內部工作人員的角度講，Twitter的用戶非常多，因此Twitter可以抽出一小部分流量來體驗尚未面世的新功能，以便將這部分實驗組用戶對新功能的反饋情況與控制組用戶（即未體驗新功能的用戶——譯者注）作對比——這就是A/B測試，即用來測試變量A與變量B哪個效果更好。
個人認為，A/B測試是在大型消費者技術公司工作的特殊福利。數據科學家可以通過使用真實隨機樣本的控制實驗來研究因果關系（用觀測值是很難做到這一點的）。在Twitter，“幾乎每天都要做至少一個實驗——Alex Roetter，高級工程師”。A/B測試已經深深烙在Twitter的數據科學家心里，也是產品開發環節不可或缺的一環。
典型的A/B測試過程是這樣的：收集樣本-用戶分組-開始測試-衡量結果-對比分析。聽上去很簡單對吧？然而，我認為A/B測試是最被低估、相當棘手的分析工作，而且學校一般不教你這種技能。為了說明這一點，讓我們來回顧一下一上五個步驟以及實戰過程中的常見問題：
收集數據：樣本量需要多少？每組應該分配多少用戶？能不能保證實驗效果足夠明顯？
用戶分組：哪些用戶適用于這個測試？應該在程序的哪個階段開始分組并對用戶展示測試的新功能？這種分組是否會造成數據稀釋（比如某些測試組的用戶在使用過程中根本用不到我們測試的新功能）？
開始測試：有沒有其他項目組和我們用同一批樣本做測試？如果和他們發生樣本沖突，如何確保我們的數據沒有被污染？
衡量結果：實驗結果的預期是什么？衡量實驗成功與否的標準是什么？衡量標準可追蹤嗎？如何追蹤？需要額外記錄哪些信息？
對比分析：假如在線用戶激增，這是來自其他變量的干擾嗎？如何判斷結果是否統計顯著？如果確實是統計顯著的，實際上用戶組之間的差別真的明顯嗎？
處理好以上問題需要很強的統計學功底。即使你自己設計實驗的時候思維足夠嚴謹，你的隊友也有可能掉鏈子。產品經理會比較喜歡對數據先睹為快，或者挑幾個自己想要的結果（這是人的天性）。工程師可能會忘記記錄數據科學家用來計算成敗指標的某些數據，或者實驗代碼“姿勢”不對，造成偏誤。
對于數據科學家來說，故意唱唱反調、幫助團隊完善實驗是極其重要的，因為浪費在運行設計不合理的測試上的時間會一去不復返。更有甚者，根據不良數據做出的不良決策會造成非常嚴重的后果。
涉及的技能：
假設檢驗：統計檢驗、p值、統計顯著、統計力、效應值、多重檢驗
實驗缺陷：滯后效應、指標選擇、數據稀釋、分組異常
預測模型與機器學習我在Twitter做的第一個大型項目是對現有的郵箱通知產品增設一套繁瑣的規則，進而減少對用戶的騷擾。雖然這一舉措十分圣母，我們其實也清楚郵件通知是留住用戶的最有效的手段之一（我們曾對此進行試驗，驗證了這一點），所以找到一個合適的度是關鍵。
針對這個關鍵點，我旋即決定研究觸發性郵件——當用戶在Twitter上有活動時，這種郵件會像雪片一樣飛進用戶的郵箱。作為一個正在努力證明自己的價值的野心勃勃的新晉數據科學家，我決定建立一個高端機器學習模型來預測用戶水平上的郵件點擊率。我用Pig收集了一大堆用戶特征，建立了隨機森林模型來預測郵件點擊率。我的思路是，如果一個用戶的點擊率長期保持在很低的值，我們就可以安心撤銷該用戶的觸發性郵件。
其他的都好說，只有一個問題——我的程序都是用本地電腦上的R寫的。別人承認我很努力，但他們無法利用我的模型來創造價值，因為我的沒有被產品化，公司的組織架構無法和我的局部模型交互。多么慘痛的教訓！
一年后，我得到了與兩名來自Growth的數據科學家一起建立顧客流失預測模型的寶貴機會。這一次，有了足夠的建立數據流水線的經驗，我知道建立機器學習流水線其實是類似的——在訓練階段，我們可以用Python在線下做循環模型更新；在預測部分，我們可以每日收集用戶特征，用預測公式（大多數只是“點產品”）生成每個用戶的流失率評分。
我們花了幾個禮拜建起來流水線，確認其具有良好的預測能力，全面部署，將用戶流失率評分輸入到Vertica、Hadoop文件分散系統，以及我們的內部鍵值存儲“Manhattan”。我們把這些scores涉及的非常便于分析師、數據科學家和工程師查詢。這一點大大幫助我們宣傳并促進這個模型的使用。這是我在建造生產模型時學到的最重要的一課。
我故意沒有提及建立機器學習模型的步驟——建立問題框架，定義標簽，手機訓練數據，設計特征，建立樣品，客觀地測試模型的可行性。這些步驟顯然都很重要，但我認為這些步驟前人都已經講得很明白了，無需我來提供相關建議。
我覺得大多數優秀的數據科學家，特別是分析型數據科學家，都不存在不會建模的問題。他們的困惑在于，知道該怎么建模，但不清楚怎么把自己的模型融入到整體生態環境里。我對此的建議是，多和經驗豐富的構建型數據科學家交流，搞清你需要掌握什么技能，潛心修煉，屆時自然能得心應手地接管相關項目。 請用許我引用以下這段話來為本章畫上句號：
“機器學習并不等同于R編程。機器學習是以數學為根基，用代碼表達，整合到軟件里的。你需要掌握電腦工程師的技能，學著寫可讀、可重復使用的代碼：別人讀你的代碼的次數將遠遠多于你自己，所以你要寫得能讓別人看懂。”——Ian Wong，于哥倫比亞大學數據科學課程客座講座
說得非常好。
這里所涉及的技能：
模式識別：識別可以用模型解決的問題。
建模和機器學習的基本功：探索式數據分析、簡歷特征、特征選擇、模型選擇、訓練/驗證/測試、模型評估
生產化：掌握上文提到和數據流水線相關的一切知識。建立索引標志以便他人查詢。
一些感想
數據科學家的工作確實非常令人興奮，那種忽然窺到天機的興奮感堪比腎上腺素爆發。從零開始構建數據管道和機器學習模型會令你成就感滿滿，做A/B測試時，那種翻手為云覆手為雨的上帝姿態也非常有樂趣。數據科學家這條路有苦又累，沿途九九八十一難，但聰明努力的人會迅速克服的。
京公網安備 11010502049343號