如何與高權重網站進行互動

Intetix Foundation（英明泰思基金會）由從事數據科學、非營利組織和公共政策研究的中國學者發起成立，致力于通過數據科學改善人類社會和天然環境。通過聯絡、動員中美最頂尖的數據科學家和社會科學家，以及分布在全球的志愿者，我們創造性地踐行著我們的使命：為夸姣糊口洞見數據價值。

原作者: Robert Chang

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 的縮寫，用來描述將數據從來源端經由抽?。╡xtract）、轉換（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測試時，那種翻手為云覆手為雨的上帝姿態也非常有樂趣。數據科學家這條路有苦又累，沿途九九八十一難，但智慧努力的人會迅速克服的。

任重而道遠，同道仍需努力。Good luck各位，更為重要的是享受這其中的樂趣！