資料分析到底是什麼？很多人都在嘴邊討論它們，卻沒有幾個人真正見過它。這是當下科技行業最為火爆的職位，今天就讓我們走進 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 型分析師能夠涉及那麼多的工程開發工作而嚮往不已。
初創公司早期、快速發展的初創公司、以及實現規模化發展的初創公司中的資料分析師職位區別
在選擇投身於科技行業的時候，最經常遇到的一個問題就是到底是加入一個大的科技公司好呢？還是加入一個小的科技公司好。在這個話題上已經有很多爭論了，但是在「資料分析」上面的爭論並不是很多。所以在本章節要具體談到的是，不同公司的規模、發展階段中，資料分析師不同的角色定位。
處於不同發展階段的科技公司生產資料的量與速度都是不一樣的。 一個還在嘗試著尋找到「產品市場契合點」的初創公司完全不需要 Hadoop，因為公司本身就不存在多少的資料需要處理；而一個處在快速發展中的初創公司往往會遭遇更頻密的資料衝擊，也許 PostgreSQL 或者 Vertica 更適合這家公司的需要；而像 Twitter 這樣的公司如果不借助 Hadoop 或者 Map-Reduce 框架，就完全無法有效地處理所有資料。
Chang 在 Twitter 學到的最有價值的一點內容就是：資料分析師從資料中提取出價值的能力，往往跟公司本身資料平臺的成熟度有著密不可分的關係。如果你想要明白自己從事的是哪種型別的資料分析工作，首先去做做調研，看看你意向中的這家公司的底層系統架構能夠在多大程度上支援你的目標，這不僅僅對你好，也對公司好，藉此看你個人的職業發展目標是否跟公司的需要契合起來。
在初創公司早期，最主要的分析重點是為了實現 ETL 程式，模組化資料，並且設計基模架構，將資料記錄應用到上面。這樣資料就能夠追蹤並儲存。此處的目標是打下分析工具的基礎，而不是分析本身。，
在快速發展的初創公司的中期，因為公司在快速發展，那麼資料也在不斷的增長。資料平臺需要適應不斷髮展的新形勢，新條件，在已經打好基礎的前提下，開始逐漸實現向分析領域的過渡。一般來說，此時的分析工作主要圍繞著制定 KPI，推動增長，尋找下一次增長機會等工作展開。
實現了規模增長的公司。當公司實現了規模化增長，資料也開始呈幾何倍數的增長。此時公司需要利用資料來創造，或者保持某種競爭性優勢，比如更好的搜尋結果，更加相關的推薦內容，物流或者運營更加的高效合理。這個時候，諸如 ML 工程師，優化專家，實驗設計師都可以參與進來一展拳腳了。
在 Chang 加入 Twitter 的時候，Twitter 已經有了非常成熟的平臺以及非常穩定的底層結構。整個資料庫內容都是非常乾淨，可靠的。ETL 程式每天輕鬆處理著數百個「任務排程」工作。（Map-Reduce）。更重要的是，在資料分析領域的人才都在資料平臺、產品分析、使用者增長、實驗研究等 多個領域，多個重點工作齊頭並進一起展開。
關於 Chang 本人的經歷
他是在使用者增長領域安排的第一名專職資料分析師。事實上，這花了他們好幾個月來研究產品、工程、還有資料分析到底該如何融合，才能實現這樣一個崗位角色。Chang 的工作與產品團隊緊密連線，根據這方面的工作經驗，他將自己的工作職責劃分成為了下面幾類內容：
產品分析
資料傳輸通道
實驗（A/B 測試）
建模
下面將會按照排列次序逐一解釋
產品分析
對於一家消費級科技公司來說，產品分析意味著利用資料來更好地理解使用者的聲音和偏好。不管什麼時候使用者與產品進行著互動，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」；
「依賴管理，排程，資源分配，錯誤報告，警告」功能的設定。
來源：Medium 譯文由 TECH2IPO/創見 花滿樓 編譯