數據分析到底是什么?很多人都在嘴邊討論它們，卻沒有幾個人真正見過它。這是當下科技行業最為火爆的職位，今天就讓我們走進 Twitter 的數據分析世界，看看科技公司對于一個數據分析師的要求是什么?他們的實際工作內容究竟是哪些?

　　到了今年 6 月 17 日，Robert Chang 就在 Twitter 工作兩年了。根據他個人的工作經歷，Twitter 數據分析(以下簡稱為 DS)有了下面三個層面的變化：

　　1. 機器學習已經在 Twitter 多個核心產品中扮演越來越重要的角色，而這之前完全是「機器學習」的禁區。最典型的例子就是「當你離開時」這個功能。當用戶離開頁面或者電腦，去干別的事情后再次返回頁面，電腦會立刻給你推送出來某些由你關注的人所發出，而有可能被你錯過的「優質內容」。

　　2. 開發工具越來越優秀了。整個團隊擺脫了對 Pig 的依賴，全新的數據管道是在 Scalding 中寫出來的。

　　3. 從團隊組織上而言，Twitter 已經轉向了一個嵌入式的模型中。其中數據分析比以往更加緊密地與產品/工程團隊發生著聯系。

　　在 Twitter 的工作確實是令人興奮的，因為你能站在這個平臺上，引領目前世界最前沿的數據科技，打造最具競爭力的優勢。而同時，人們對于大數據的渴望也一天比一天高。

　　Dan Ariely 曾經有一句話說得特別好：

　　「大數據其實有點兒像青少年的性。每一個人都興致勃勃地談論它，但是沒有任何一個人真的知道該怎么做。每一個人都覺得身邊的人都在嘗試，為了不落人后，于是每個人都在外面宣城自己也已經有『伴兒』了」

　　現如今，有太多的人在如何成為一名優秀稱職的數據分析師上表達著看法，給出自己的建議。Robert Chang 毫無疑問也是受益者。但是他回過頭來再想想大家的討論，會覺得人們往往更加側重于去談「技術」、「工具」、「技能組合」，而在 Chang 看來，那些東西確實很重要，但是讓新人們知道數據分析師每一天的生活到底是什么樣子的，具體的工作內容都是什么，這也非常重要。

　　于是，Chang 憑借著自己在 Twitter 工作兩年的經歷，以自己作為例子，首次打開 Twitter 數據分析師這扇神秘的大門。

　　A 型數據分析師 VS B 型數據分析師

　　Chang 在沒來 Twitter 之前，總覺得數據分析師一定是在任何領域都能看堪稱「獨角獸」，不管是數據還是數學專業，都是頂尖人才。除了技術上很牛之外，書面寫作和口頭交流的能力也會特別強。更重要的是他們能夠分清楚當下工作的輕重緩急，領導和管理一個項目團隊。是啊，如今本身就是以數據為主導的文化，作為「數據分析師」，當然要給這個文化注入靈魂與活力啊!

　　在 Chang 加入 Twitter 的幾個月后，他逐漸意識到：符合上述形容的「獨角獸」確實存在，但是對于大部分人來說，上述的要求未免有點兒太不切實際了。人們沒有辦法做到面面俱到。后來，Chang 通過 Quora 中的一篇回答，更深刻地理解了數據分析師的角色。在那篇文章中，數據分析師分成了兩種類型：

　　A 型數據分析師： 他們主要負責「分析」。他們最關心數據背后的意義，往往使用統計等方式探知真相。其實他們的工作有點兒像「統計學家」，但是不一樣的地方是，統計學專業涉及的內容他們統統掌握，但是他們還會一些統計學課本里面壓根不曾出現的內容：比如數據清洗，如何處理超大數據組，數據視覺化，有關數據層面的報告撰寫等等。

　　B 型數據分析師：B 型負責「建造」。他們跟前一種分析師有著相似的統計學背景，但他們同時還是非常牛叉的程序員，又或者是訓練有素的軟件工程師。B 型數據分析師往往感興趣于「如何利用數據來生產」。他們建立一些能夠與用戶互動的模型，往往以「推薦/推送」的形式出現，比如「你也許會認識的人」，「廣告」，「電影」，「搜索結果」等等功能。

　　Chang 看到這樣清楚的劃分，非常后悔如果早幾年有這么清楚的概念認識該多好啊。這樣他就能夠有選擇性的發力，擇其一方向來繼續發展。這是數據分析師職場規劃首先要考慮的標準。

　　Chang 的個人專業背景是「數學」、「運營研究」、「統計學」。所以他更傾向于把自己定位于 A 型數據分析師，但是與此同時他對 B 型分析師能夠涉及那么多的工程開發工作而向往不已。

　　初創公司早期、快速發展的初創公司、以及實現規?；l展的初創公司中的數據分析師職位區別

　　在選擇投身于科技行業的時候，最經常遇到的一個問題就是到底是加入一個大的科技公司好呢?還是加入一個小的科技公司好。在這個話題上已經有很多爭論了，但是在「數據分析」上面的爭論并不是很多。所以在本章節要具體談到的是，不同公司的規模、發展階段中，數據分析師不同的角色定位。

　　處于不同發展階段的科技公司生產數據的量與速度都是不一樣的。一個還在嘗試著尋找到「產品市場契合點」的初創公司完全不需要 Hadoop，因為公司本身就不存在多少的數據需要處理;而一個處在快速發展中的初創公司往往會遭遇更頻密的數據沖擊，也許 PostgreSQL 或者 Vertica 更適合這家公司的需要;而像 Twitter 這樣的公司如果不借助 Hadoop 或者 Map-Reduce 框架，就完全無法有效地處理所有數據。

　　Chang 在 Twitter 學到的最有價值的一點內容就是：數據分析師從數據中提取出價值的能力，往往跟公司本身數據平臺的成熟度有著密不可分的關系。如果你想要明白自己從事的是哪種類型的數據分析工作，首先去做做調研，看看你意向中的這家公司的底層系統架構能夠在多大程度上支持你的目標，這不僅僅對你好，也對公司好，借此看你個人的職業發展目標是否跟公司的需要契合起來。

　　在初創公司早期，最主要的分析重點是為了實現 ETL 進程，模塊化數據，并且設計基模架構，將數據記錄應用到上面。這樣數據就能夠追蹤并存儲。此處的目標是打下分析工具的基礎，而不是分析本身。

　　在快速發展的初創公司的中期，因為公司在快速發展，那么數據也在不斷的增長。數據平臺需要適應不斷發展的新形勢，新條件，在已經打好基礎的前提下，開始逐漸實現向分析領域的過渡。一般來說，此時的分析工作主要圍繞著制定 KPI，推動增長，尋找下一次增長機會等工作展開。

　　實現了規模增長的公司。當公司實現了規?；鲩L，數據也開始呈幾何倍數的增長。此時公司需要利用數據來創造，或者保持某種競爭性優勢，比如更好的搜索結果，更加相關的推薦內容，物流或者運營更加的高效合理。這個時候，諸如 ML 工程師，優化專家，實驗設計師都可以參與進來一展拳腳了。

　　在 Chang 加入 Twitter 的時候，Twitter 已經有了非常成熟的平臺以及非常穩定的底層結構。整個數據庫內容都是非常干凈，可靠的。ETL 進程每天輕松處理著數百個「任務調度」工作。(Map-Reduce)。更重要的是，在數據分析領域的人才都在數據平臺、產品分析、用戶增長、實驗研究等多個領域，多個重點工作齊頭并進一起展開。

　　關于 Chang 本人的經歷

　　他是在用戶增長領域安排的第一名專職數據分析師。事實上，這花了他們好幾個月來研究產品、工程、還有數據分析到底該如何融合，才能實現這樣一個崗位角色。Chang 的工作與產品團隊緊密連接，根據這方面的工作經驗，他將自己的工作職責劃分成為了下面幾類內容：

1. 產品分析

2. 數據傳輸通道

3. 實驗(A/B 測試)

4. 建模

　　下面將會按照排列次序逐一解釋

　　產品分析

　　對于一家消費級科技公司來說，產品分析意味著利用數據來更好地理解用戶的聲音和偏好。不管什么時候用戶與產品進行著互動，Twitter 都會記錄下來最有用的數據，存儲好它們，以待未來某一天分析之用。

　　這個過程被稱之為「記錄」(logging)或者「工具化」(instrumentation)，而且它還不斷地自我演進。通常情況下，數據分析往往很難實現某個具體的分析，因為數據要么是不太對，要么是缺失，要么是格式錯誤的。在這里，跟工程師保持非常好的關系非常有必要，因為數據分析能夠幫助工程師確認 bug 的位置，或者系統中一些非預期的行為。反過來，工程師可以幫助數據分析彌補「數據鴻溝」，使得數據內容變得豐富，彼此相關，更加準確。

　　下面舉出來了 Chang 在 Twitter 展開的幾項與產品有關的分析案例：

　　推送通知分析：有多少用戶能用得到「推送通知」?不同類型的推送通知具體的點擊率都分別是多少?

　　SMS 發送率：在不同的數字載體上，Twitter 的 SMS 發送率都是怎么計算的?是不是在發展中國家這個發送率相對比較低?我們該怎樣提升這個數字?

　　多賬戶：為什么在某些國家，一個人持有多個賬戶的比例會相對較高?背后是什么動機讓一個人持有多個賬戶?

　　分析會以多種形式展開。有些時候公司會要求你對一次簡單的數據拉取進行最直白的解讀，又或者你需要想出一些新的方式方法來機選一個全新，且重要的運營指標。(比如 SMS 發送率)，最后你會更加深刻地理解用戶的行為。(比如一個人擁有多個賬戶)

　　在產品分析中不斷研究，得到真知灼見，這是一個不斷迭代演進的過程。它需要不斷地提出問題，不斷地理解商業情境，找出最正確的數據組來回答相應的問題。隨著時間的累積，你將成為數據領域的專家，你會正確地估計出來執行一次分析大概得花多長時間。更重要的是，你將逐漸從一個被動響應的狀態，逐漸過渡到主動采取行動的狀態，這其中會牽連出來很多有趣的分析，這些內容都是產品負責人曾經壓根沒有考慮過的，因為他們不知道這些數據存在，又或者不同類型的數據以某種特殊的方式組合到一起竟然會得出如此驚人的結論。

　　此處需要的技能：

　　保存和工具化：確認數據鴻溝。與工程部門建立良好的協作關系;

　　有能力引導和確認相關的數據組，知道正確使用它們的方式;

　　理解不同形式的分析，能夠在不同的分析執行之前就正確地估算出難易程度，所需時間長短;

　　掌握你的查詢語言。一般來說是利用 R 或者 Python 來實現數據再加工;

　　數據管道

　　即使 A 型數據分析師不太可能自己編寫代碼，直接應用到用戶那里，但是出乎很多人意料的是，包括 Chang 在內的很多 A 型數據分析師確實在給代碼庫寫東西，目的只有一個：為了數據管道處理。

　　如果你從 Unix 那里聽說過「對一系列命令的執行」，那么一個數據管道就意味著多個系列命令的執行，我們能夠不斷周而復始地自動捕捉，篩選，集合數據。

　　在來到 Twitter 之前，Chang 的分析絕大部分都是點對點的。在 Chang 的本地機器上，代碼執行上一次或者幾次。這些代碼很少得到審查，也不太可能實現版本控制。但是當一個數據通道出現的時候，一系列的功能就浮出水面：比如「依賴管理」、「調度」、「源頭分配」、「監控」、「錯誤報告」以及「警告」。

　　下面介紹了創建一個數據管道的標準流程：

　　你忽然意識到，如果一個數據組能夠周而復始地自我重新產出，那么這個世界估計會因此受益;

　　在確認了需求之后，你開始設計「生產數據組」的「數據架構」;

　　開始編寫你的代碼，不管是在 Pig，Scalding，或者 SQL 中。這取決于你的數據環境是什么;

　　提交代碼，進行代碼審查(code review)，準備后得到回饋，并做相應額外的修改。要么是因為你的設計邏輯不太對，要么是你的代碼出于速度和效率的目的并沒有優化到位;

　　應該有一個「測試」和「試運轉」的環境，確保所有的運行都在既定的軌道上。

　　將你的代碼融合到主庫中

　　建立「監控」、「錯誤報告」以及「警告」等功能，以防止未來出現預期之外的狀況。

　　很顯然，數據通道比一個點對點的分析工具來說更加復雜，但是優勢也非常明顯，因為它是自動化運行著的，它所產出的數據能夠進一步強化面板，這樣更多的用戶能夠消費你的數據/結果。

　　另外，更加重要但是往往被人忽略的一點結果是，對于如何打造最優化的工程設計，這是一個非常棒的學習過程。如果你在日后需要開發一個特別定制的數據通道，比如機器學習，之前所做的工作就成為了扎實的基礎。

　　在此處需要用到的技能：

　　版本控制，目前最流行的就是 Git;

　　知道如何去做「代碼審核」，并且知道如何有效地給予反饋;

　　知道如何去測試，如何去試運行，當出現錯誤的時候知道如何「debug」;

　　「依賴管理，調度，資源分配，錯誤報告，警告」功能的設置。

　　實驗(A/B 測試)

　　此時此刻，非常有可能你現在使用的 Twitter App 跟我手機上裝的 App 是有一點小小的不同的，并且很有可能你在用著一個我壓根沒有見到過的功能。鑒于 Twitter 的用戶很多，它可以將其中很小的一部分流量(百分之幾)導入到一次實驗中，去測試這個尚未全面公開的功能，去了解這些被選中的用戶如何跟這個全新的功能互動，他們的反響跟那些沒有見到這個功能的用戶進行對比。

　　這就是 A/B 測試，去讓我們方便測試各種變量，通過 A 和 B 到底哪個方案更好。

　　Chang 個人的看法是：為一些較大的科技公司做事，能夠享受到的一點優勢，就是能夠從事開發和掌握業界最神秘的技能：「A/B 測試」。作為一名稱職的數據分析師，你必須利用可控制的實驗，在其中進行隨機測試，得到某種確定的因果關系。而根據 Twitter 負責工程部分 A/B 測試的副總 Alex Roetter 的話來說，「Twitter 的任何一天中，都不可能在沒有做一次實驗的前提下就草率放出某個功能?！笰/B 測試就是 Twitter 的 DNA，以及產品開發模式的基礎。

　　A/B 測試的循環周期是這樣的：取樣-> 分組->分別對待-> 評估結果-> 作出對比。這聽上去是不是覺得挺簡單的?其實事實完全相反。A/B 測試應該是天底下最難操作的分析之一，也是最容易被人低估難度的一項工作。這方面的知識基本上學校是不教的。為了更好的闡述觀點，分了下面五點內容，分別是五個階段，其中一些部分有可能是你從事 A/B 測試時會遇到的一些困難和挑戰。

　　取樣— 我們需要多少的樣本?每一組分多少個用戶?我們是否能夠讓實驗具有足夠的可信度和說服力?

　　分組— 哪些人適用于出現在這次實驗中?我們從代碼的哪一處開始起手，分出兩個版本?是否會出現數據稀釋的情況?(數據稀釋的意思就是，有些用戶被納入到了新改動的版本測試中，但是實際上他們卻壓根不打開這個 App，見不到這個新變動的功能。)

　　區別對待-整個公司中是否還有其他的團隊在做其他的測試，瞄準的用戶是否跟此時我們鎖定的用戶群發生重疊?我們該怎樣應對「測試沖突」這種情況，保證我們的數據沒有被「污染」?

　　評估結果-測試的假設前提是什么?實驗成功或者失敗的指標是哪些?我們是否能做到有效的追蹤?我們是否要增加一些其他方面的數據存儲?

　　做出比較-假設某個條件下的用戶數量發生了激增，它是不是因為其他的一些因素?我們是如何確保這些統計具有實際的意義?就算具有實際的意義，這個意義對于下面的產品改良又具有多大的指導作用?

　　不管回答上述的哪一個問題，都需要對統計學很好的掌握才能辦到。就算你一個人能力很強，但是團隊其他同事還是有可能給這個 A/B 實驗添亂子。

　　一個產品經理有可能特別心急，沒等試驗結束就要偷窺數據，又或者想當然地，按照他們想象的方式挑選自己想要的結論。(這是人性，別怪他們)。一個工程師有可能忘記存儲某個特殊的信息，又或者錯誤的寫出測試用的代碼，實驗結果出現了非常離譜的偏差。

　　作為數據分析師，這個時候不得不對自己和他人嚴厲一些，讓整個團隊都能高效、準確地運轉，在實驗的每一個細節上面都不能有任何的差池。時間浪費在一次徒勞無功，設計錯誤的實驗中，這些時間是找不回來的。甚至還會出現更糟糕的情況，依據一次錯誤的實驗結論形成錯誤的決策，最終給整個產品帶來極大的風險。

　　在此處所需要用到的技能：

　　假設條件測試： 統計學測試，統計數據可信度，多重測試。

　　測試中有可能出現的偏差： 按照自己想要的結果去推斷結論，延滯效應，數據稀釋，分組異常

　　預測型建模以及機器學習

　　Chang 在 Twitter 負責開發的第一個重大項目是將一組「疲勞標準」添加到 Twitter 目前的郵件通知產品中，這樣能夠降低郵箱過濾機制將 Twitter 的信息視為垃圾信息的概率，從而實現讓用戶更頻繁在收件箱中看到 Twitter 發來的電子郵件。

　　盡管郵件過濾機制不失為使一次偉大的發明，但是郵件通知也確實是提升客戶留存率的特別有效的辦法之一。(這個結論是 Twitter 曾經做的一次實驗中無疑中發現的)。所以，Chang 的目標就是在這其中取得平衡。

　　在基于上述的觀察和思考之后，Chang 想到了一個點子：觸發式的郵件發送機制。也就是只有在用戶與產品之間發生了某種互動的情況下，這封郵件才會發送到用戶的電子郵箱。作為剛剛加入團隊的數據分析師，Chang 特別想要通過這個項目來證明自己的價值，于是決定利用非常棒的機器語言模型來預測電子郵件的 CTR(點擊率)。他將一大堆用戶級別的功能集合在 Pig 工具中，并建立了一個隨機預測模型來預測郵件點擊。這背后的想法是，如果用戶在過去很長一段時間內都對電子郵件有著低點擊率，那么 Twitter 就會保留這封郵件，不再給他發送。

　　上述的想法都很好，但是只有一個問題，所有的工作都是放在本地機器的 R 中處理的。人們都很贊賞 Chang 的工作成果，但是他們不知道如何利用這個模型，因為它是無法進一步轉化成產品的。Twitter 的系統底層是無法與 Chang 的本地模型展開對話的。

　　這一課帶來的教訓讓 Chang 終生難忘。

　　一年之后，Chang 和增長團隊中的兩個人共同捕捉到了一個全新的機會，能夠打造一個用戶流失率預測模型。這一次，Chang 已經在開發數據管道上有了非常充足的經驗。這一次他們做的非常好，模型能夠針對每一個用戶自動的生成一個用戶流失概率!

　　幾個星期之后，他們開發了數據管道，并且確認它真的具有很有效的預測能力，他們通過將分數寫入到 Vertica，HDFS，以及 Twitter 內部一個稱之為「曼哈頓」的關鍵價值商店。這樣大家都知道了它的存在。公司無數分析師，數據分析師，工程服務部門都過來試用，進行查詢，幫其宣傳，評價非常好。這是 Chang 在 Twitter 最值得驕傲的一件事，真正把預測模型納入到了產品當中。

　　Chang 認為絕大部分杰出的數據分析師，尤其是 A 型的數據分析師都存在這樣一個問題，他們知道怎樣去建模，但是卻不知道怎樣把這些模型嵌入到產品系統當中。Chang 的建議是好好跟 B 型數據分析師聊聊吧，他們在這個話題上有著足夠豐富的經驗，發現 A 型和 B 型數據分析師職能重合的那一部分，想想接下來需要的一些技能組合是什么，這樣才能讓自己在數據分析師的道路上走的更深更遠，更加寬廣。

　　「機器學習并不等同于 R 腳本。機器學習起源于數學，表達在代碼中，最后組裝在軟件中。你需要是一名軟件工程師，同時需要寫一點可讀的，重復使用的代碼。你的代碼將被更多人重新讀取無數次-來自 Ian Wong 在哥倫比亞數據學課堂上的講座節選。

　　在這里所用到的技能：

　　模式確認：確認哪些問題是可以通過建模的方法來加以解決的

　　建模以及機器語言的所有基礎知識：探索型數據分析，開發功能，屬性選擇，模型選擇，模型評估，練習/確認/測試。

　　產品化：所有上面的內容有關于數據管道的建立，使得不同的人都能夠在上面執行查詢

　　最后的一些話：

　　成為一個數據分析師確實是一件挺讓人激動的事。你能從別人根本無法達到的角度獲取真相，這足夠酷炫了。從底層開始開發數據管道或者機器語言模型，會給人帶來深層次的滿足感，當執行 A/B 測試的時候，有太多時刻會給你一種當「上帝」的趣味。即便這條路充滿了曲折以及不確定性，有很多挑戰擺在眼前，但是走在這條路上的人永遠不會退縮。任何一個聰明，有想法的年輕人都應該考慮成為一名數據分析師。