乾貨 | 這是一份你急需的數據分析的職業規劃

作者：秦路 公眾號：秦路（tracykanc）

配套七周成為數據分析師系列文章： 如何七周成為數據分析師

配套七周成為數據分析師視頻教程：磨劍之作，七周成「師」！秦路主講，七周成為數據分析師

最近有不少同學在後台問我數據分析的職業發展相關，這裡先列一個簡易大綱。它更多是以我所在的互聯網行業展開的。

入門和職業規劃應該從兩個角度考慮：領域和路線。

領域是不少新人常忽略的要素，其實數據分析不會脫離業務存在。你進入哪個行業，很大程度會決定你初期的技能樹和技能點。譬如金融領域的風控模型、營銷領域的生命周期、廣告領域的點擊率預估等，各有各的特色。

如果是一位應屆生，不妨多了解自己感興趣的領域，和專業相關是最好的，並且積累相關的經驗，為面試做準備。

如果已經有一定行業履歷，只是想要轉崗數據分析師，那麼跨崗不跨行，避免跳到一個陌生的領域。

領域經驗太寬泛，我給不了太多的指點，主要也就三點：1.自己感興趣的，2.自己擅長的，3.有錢途的。從職場生涯看，成為某領域的數據專家，會是一個更好的籌碼。

而路線大致可以劃分成四大方向：

數據分析，數據挖掘，數據產品，數據工程。

數據分析/數據運營/商業分析

這是業務方向的數據分析師。

絕大部分人，都是從這個崗位開始自己的數據之路，也是基數最大的崗位。

因為基數大，所以這類崗位通常魚龍混雜。有些雖然叫數據分析師，但是每天只需要和Excel打交道，完成leader布置的表格整理工作就行。混個幾年，成為一位數據分析主管，給下面的新人繼續布置Excel任務。

又有一種數據分析師，崗位職責要求你掌握常用的機器學習演算法，面試首先推導一個決策樹或者邏輯回歸。入職後也是各類代碼，和分析打交道的情況不多。

都叫數據分析師，其實天差地別。

這裡更多指互聯網行業，偏業務的數據分析師，一般屬於運營部門。不少公司也稱數據運營或者商業分析。

這類崗位的職位描述一般是：

• 負責和支撐各部門相關的報表；
• 建立和優化指標體系；
• 監控數據的波動和異常，找出問題；
• 優化和驅動業務，推動數據化運營；
• 找出可增長的市場或產品優化空間；
• 輸出專題分析報告；

實際情況是，不少業務端的數據分析師，主要工作只做第一點。別管它用匯總、分析、數據支持什麼修飾詞，基本是跑SQL，做報表。硬生生活成了業務端的表哥。

這是很常見的情況，也是入門新人的第一個坑。因為從頭到尾，這類分析師，都沒有解決問題。

業務部門往往更關心，某個指標為什麼下跌或者上升。產品的用戶是什麼樣的？怎麼能更好的完成自己的KPI。

以活躍指標的下跌舉例：

• 活躍指標下跌了多少？是屬於合理的數據波動，還是突髮式？
• 什麼時候開始的下跌？
• 是整體的活躍用戶下跌，還是部分用戶？
• 為什麼下跌？是產品版本，還是運營失誤？
• 怎麼解決下跌的問題

這是一套標準的解決思維。分別對應what、when、who、why、how，每一部分都不是三言兩語可以解釋清楚。不要看它簡單，例如你通過多維分析，發現某個地區的活躍下跌了，不要急著把它作為分析的結論，這是不合格的數據分析。某地區的活躍下跌，只是現象，不是原因，把它作為結論提交，肯定會被罵的。

你要解決的是，為什麼這個地區的活躍下跌了。是該地渠道，是該地競爭對手，是該地市場環境？這些問題都是細化深入的範疇。並且，它們要能以量化解釋，而不是我認為。

做好了這點，才是一個真正的業務端的數據分析師。

當然，這一點看的是leader。leader能否帶你進入業務分析的大門，決定你將來是不是成為一個表哥。新人切記切記。

解決問題是一方面工作，另外一方面，數據分析師的職責是將業務數據體系化，建立一套指標框架。活躍下跌的問題，本質上也是指標問題。什麼時候開始下跌，哪部分下跌，都能轉化成對應指標，如日活躍用戶數，新老用戶活躍數，地區活躍數。

你不能衡量它，就無法增長它，指的就是指標體系。指標體系可以是業務部門建立，但數據分析師也挺合適。一方面他們比數據挖掘這類技術崗位更貼合業務，一方面不像業務崗位對數據抓瞎。

兩者結合，這崗位也能稱為數據運營。

指標體系如果工程化自動化，也就是BI，所以數據分析師可以算半個BI分析師，這裡不包括BI報表開發。BI如果採購第三方，數據分析師負責BI沒問題，如果自有開發，那麼BI崗技術的色彩更濃厚。

數據分析思維和業務的理解，是分析師賴以生存的技能。很多時候，工具是錦上添花的作用。掌握Excel+SQL/hive，了解描述統計學，知道常見的可視化表達，足夠完成大部分任務。機器學習這類能力，對此類數據分析師不是必須的，Python也一樣，只是加分項。畢竟為什麼下跌，你無法用數據挖掘解答。

數據分析師是一個基礎崗位，如果專精於業務，更適合往管理端發展，單純的工具和技巧很難拉開差距。數據分析的管理崗，比較常見的有數據運營經理/總監，數據分析經理等，相對應的能力是能建立指標體系，並且解決日常的各類「為什麼」問題。

商業/市場分析是另外一個方向，更多見於傳統行業。你要開一家超市，你得考慮哪裡開，這就要考慮居民密度，居民消費能力，競爭對手的多寡，步行交通距離，開車交通距離等。這些數據是宏觀的大指標，往往靠搜索和調研完成，這是和互聯網數據分析師最大的差異。

若往其他分支發展，比如數據挖掘工程師，則要繼續掌握Python和機器學習等。從業務型發展上來的好處是接地氣，具備商業洞察力（天天搞報表，怎麼可能不熟），這點是直接做數據挖掘，或者程序員轉崗，所不具備的。

新人，比較普適的發展路線是先成為一位數據分析師。積累相關的經驗，在一兩年後，決定往後的發展，是數據挖掘，還是專精數據分析成為管理崗。

學習資料：

這裡對學習資料不再多做推薦，看歷史文章：如何七周成為數據分析師

及七周成為數據分析師視頻教程：磨劍之作，七周成「師」！秦路主講，七周成為數據分析師

數據挖掘/演算法專家

這是技術向的數據崗，有些歸類在研發部門，有些則單獨成立數據部門。

數據挖掘工程師要求更高的統計學能力、數理能力以及編程技巧。

從概念上說，數據挖掘Data mining是一種方式，機器學習Machine Learning是一門方法/學科。機器學習主要是有監督和無監督學習，有監督又可劃分成回歸和分類，它們是從過去的歷史數據中學習到一個模型，模型可以針對特定問題求解。

數據挖掘的範圍則大得多，即可以通過機器學習，而能藉助其他演算法。比如協同過濾、關聯規則、PageRank等，它們是數據挖掘的經典演算法，但不屬於機器學習，所以在機器學習的書籍上，你是看不到的。

除此之外，還有一個領域，屬於最優化問題的運籌學。現實中的問題往往有很多約束，比如護士排班，一共有三班（早、中、晚），現在要求每班滿足最低護士人數，每位護士盡量不能連班，每位護士不能連續工作5天。每位護士的夜班數要均衡，每位護士每月的班數要均衡…這些問題很難用機器學習的方法完成，而在最優化領域，則有遺傳演算法、模擬退火演算法、蟻群演算法等。

實際的應用場景中，如外賣行業，如何尋找騎手效率最大化的最優路徑，同樣屬於最優化，也是數據挖掘的工作範疇。

數據挖掘工程師，除了掌握演算法，同樣需要編程能力去實現，不論R、Python、Scala/Java，至少掌握一種。模型的實施，往往也要求Hadoop/Spark的工程實踐經驗，精通SQL/Hive是必須的。

常見數據挖掘項目的閉環如下：

• 定義問題
• 數據抽取
• 數據清洗
• 特徵選取/特徵工程
• 數據模型
• 數據驗證
• 迭代優化

單看環節，數據挖掘對分析能力沒有業務型那麼高。這不代表業務不重要，尤其在特徵選取方面，對業務的理解很大程度會影響特徵怎麼選取，進而影響模型質量。用戶流失是一個經典的考題，如何選取合適的特徵，預測用戶會否流失，能夠考察對業務是否深刻洞察。

數據挖掘的業務領域一樣可以細分。金融行業的信用模型和風控模型/反欺詐模型、廣告模型的點擊預估模型、電商行業的推薦系統和用戶畫像系統。從需求提出到落地，數據挖掘工程師除了全程跟進也要熟悉業務。

因為要求高，所以數據挖掘的平均薪資高於數據分析師。

一個分工明確的團隊，數據分析師負責將業務需求抽象成一個具體的數據假設或者模型。比如，運營希望減少用戶流失，那麼設立一個流失指標，現在需要預測用戶流失率的模型。模型可以是數據分析師完成，也能是數據挖掘工程師。最終由數據挖掘團隊部署到線上。

在一些公司，高級數據分析師會等價於數據挖掘工程師（其實行業內，對Title並沒有嚴格的標準），只是工程能力可以稍弱，模型部署由專門的工程團隊完成。

數據挖掘工程師，往後發展，稱為演算法專家。後者對理論要求更嚴苛，幾乎都要閱讀國外的前沿論文。方向不局限於簡單的分類或者回歸，還包括圖像識別、自然語言處理、智能量化投顧這種複合領域。這裡開始會對從業者的學校和學歷提出要求，名校+碩士無疑是一個大優勢，也有很多人直接做數據挖掘。

深度學習則更前沿，它由神經網路發展而來，是機器學習的一個子集。因為各類框架開枝散葉，諸多模型百花齊放，也可以算一個全新的分支。除了要求熟悉TensorFlow, Caffe, MXNet等深度學習框架，對模型的應用和調參也是必備的，後者往往是劃分普通人和大牛的天塹。

演算法專家和深度學習專家，薪資level會更高一級，一般對應於業務型的數據運營/分析總監。

數據科學家是上述崗位的最終形態之一，要麼理論能力非常強，往往擔任研究院的一把手。要麼工程能力突出，上述的系統都能完成平台化的部署。

學習資料：

這類崗位對基礎知識要求紮實，所以書籍需要比較大的閱讀量，而且要保持領域新論文的吸收。

統計知識，除了「商務與經濟統計」外，國外有一本「The Elements of Statistical Learning」，評價不錯。

機器學習的入門，李航的「統計學習方法」，周志華的「機器學習」都是好書，英文好也能看PRML。

Python入門書籍的推薦太多，略過。「用Python進行數據分析」是必備的，當然這本書有點老，活用官網最新文檔和stackoverflow，基本無礙。Python可視化查閱文檔也夠了，不用看書。

再進一步，則是機器學習的代碼實現，比較知名的有「集體智慧編程」，「機器學習實戰」等。其實最近還有不少新書，「Python DataScience Handbook」等，我當然不可能都看過，所以也不好推(hu)薦(you)。

除了基礎，行業領域的也別落下，諸如推薦系統實戰、計算廣告…按需學習。如果你們公司對於人才有較高的挑戰（一個人當兩個人用），大概Spark/Hadoop機器學習相關的框架也得了解。

數據產品經理

這個崗位比較新興，它有兩種理解，一種是具備強數據分析能力的PM，一種是公司數據產品的規劃者。

前者，以數據導向優化和改進產品。在產品強勢的公司，數據分析也會劃歸到產品部門，甚至運營也屬於產品部。這類產品經理有更多的機會接觸業務，屬於順便把分析師的活也幹了，一專多能的典型。

他們會運用不同的數據源，對用戶的行為特徵分析和挖掘，達到改進產品。最典型的場景就是AB測試。大到頁面布局、路徑規劃、小到按鈕的顏色和樣式，均可以通過數據指標評估。

下圖的案例，就是弱化心愿單按鈕的存在感，讓用戶更多的聚焦在直接購買而不是收藏，最終讓銷售額提高了35%。

俗話說，再優秀的產品經理也跑不過一半AB測試。此類數據產品經理，更多是注重數據分析能力，擅長用分析進行決策。數據是能力的一部分。

後者，是真正意義上的數據產品經理。在公司邁大邁強後，數據量與日俱增，此時會有不少數據相關的產品項目：包括大數據平台、埋點採集系統、BI、推薦系統、廣告平台等。這些當然也是產品，自然需要提煉需求、設計、規劃、項目排期，乃至落地。

我們不妨看幾個數據產品經理要求：

• 負責大數據產品的設計，輸出需求文檔、產品原型；
• 負責推薦演算法的產品策略，完成相關推薦及個性化推薦產品的需求分析；
• 負責分析和挖掘用戶消費內容的行為數據，為改進演算法策略提供依據；
• 負責客戶端數據需求的對接，制定相關埋點規範及口徑，相關業務指標驗證；
• 報表展示工具的落地和應用；

和C端注重用戶體驗不同，數據產品，更注重整體的分析能力和邏輯。除了產品經理最基礎的Axure、Visio、MindManager等工具。往往還需要很多技術型的能力。比如了解BI/DW原理和實施、了解常用的推薦演算法、了解機器學習模型等。這也很容易理解，C端要求你了解用戶需求，而在數據端，主要用戶就是數據。

這當然不是說，用戶體驗不重要，拿推薦演算法來說，除了滿足用戶最基本的感興趣，也要考慮時效性，考慮新興趣的挖掘，考慮無數據時的冷啟動問題…這些一樣是用戶體驗，只是解決方案也得從數據出發。再多思考一步，模型是離線還是實時，實時怎麼實現它？技術細則不用多考慮，但你要知道會有這些坑。後端的數據產品，如報表，用戶往往是你隔壁工位的小秦或小路，設計得丑一點不要緊，要是數據指標口徑不統一，那才會分分鐘罵街。

雖然數據PM需要熟悉各類數據模型、指標、數據挖掘和數據工程的實現，但是聚焦點是把它作為一個項目去實現，故而不用精通。

數據產品經理是一個比較新興的崗位，所以有豐富經驗的從業者並不多，我個人認為，還是存在比較大的職業缺口。當然也有其他問題，一是因為新興，部門負責人本身也沒有想好他們能幹什麼，不少數據PM還從事表哥的工作。二是數據產品本身可借鑒的經驗不多，像APP產品，可以下載體驗，總歸有一個學習的過程。然而用戶畫像、BI、演算法策略，都是其他公司的內部機密，無從參考，我就遇到不少對用戶畫像實現非常感興趣的數據PM。

從職業發展上看，數據分析師做數據產品經理更合適。普通的產品經理，對前端、後端的技術棧尚未熟悉，何況日新月異的數據棧。這個崗位，適合對數據特別感興趣，但是數理天賦不高的職場人，那麼以溝通、項目管理和需求規劃為能力，也不錯。

學習資料：

數據產品經理，如果有數據挖掘經驗，那麼技術相關的書籍倒不重要，別落伍就行，更關注產品經理本身的能力，包括Axure，各類文檔的編寫、項目管理、需求整理等，市面上資料比較多。

這裡再補充兩本，「數據挖掘與數據化運營實戰」，沒啥高深技術，但是能夠了解體系的初步建立。「數據挖掘技術—應用於市場營銷、銷售與客戶關係管理」，這本書我推薦它是糾結的，它的知識點比較豐富，業務人員也能看懂，但是翻譯的實在太糟糕了……

更多書籍參考其他崗位即可。

數據工程師

數據工程師其實更偏技術，從職業道路上看，程序員走這條路更開闊。

在很多中小型的公司，一方面數據是無序的、缺失的、原始的，另外一方面各種業務報表又嗷嗷待哺。沒辦法，分析師只能自己擼起袖子，一個人當三個人用。兼做數據清洗+ETL+BI。

經歷過的大概都懂，數據分析踏上數據工程的不歸路如下：

• 每天都要從五六張表上join，那麼不妨加工成一張中間表；
• ETL的依賴關係越來越複雜，嘗試用kettle/airflow等框架搞定，弄個DAG美滋滋；
• 運營部門的周報次次都要這幾個指標，看看能否做一個自動化BI；
• 數據量逐日增多，最近T+1的日報需要幾個小時完成，研究下查詢語句的優化；
• 查詢語句的優化空間也不大了，開始遷移到Hadoop/Spark分散式平台，新技術棧的學習；
• 新平台，原有的工具也不管用了，某大牛說apache上有工具能解決這個問題，於是閱讀文檔；
• 公司部署了私有化的埋點採集，數據缺失比較厲害，業務部門天天罵娘，繼續埋Flume/Kafka的坑；
• 等等…

如果分析師在技術方面的靈性不錯，那麼技能點會往技術棧方向遷移。從最初的SQL，到了解Hadoop集群、了解presto/impala/spark、了解ELK、了解分散式存儲和NoSQL……

這也是一個不錯的發展方向，因為數據挖掘需要了解演算法/模型，理論知識要求過高，不少碩士和博士還過來搶飯碗，自己不擅長容易遇到天花板。選擇更底層的工程實現和架構，也是出路，薪資也不會低於數據挖掘/演算法專家。

部分歸屬到技術部的數據分析師，雖然Title叫數據分析（其實應該叫數據分析開發工程師），很多工作也是圍繞ETL/DW/BI進行，那麼這就是標準的數據工程路線。

部分公司會將機器學習模型的部署和實現交給數據工程團隊，這要求數據工程師熟悉sparkMLlib、Mahout此類框架。

數據工程師，可以從數據分析師的SQL技能，往數據的底層收集、存儲、計算、運維拓展。往後發展則是數據總監、或者數據架構師。因為數據分析出身，與純技術棧的程序員比，思考會更貼合業務，比如指標背後的數據模型，但是技術底子的薄弱需要彌補。

另外，DBA、BI這些傳統的資料庫從業者，也是能按這條路線進階，或者選擇數據產品經理方向。

學習資料：

數據工程類的書籍，我看的不多，給不了建議。主要按各類名詞搜索吧，什麼linux、數據倉庫、Hadoop、Spark、Storm、Elasticsearch等。這類崗位發展，技術更新速度比較快，所以需要保持吸收以及活用開源。

最後

以上四個崗位就是數據分析的發展方向，它們互有關聯，如果從整個架構圖來看（一篇歷史舊文有更詳細的描述：從零開始，構建數據化運營體系）。

我們可以將其劃分為數據收集—數據加工—數據運營—數據觸達。

數據收集負責收集各種各樣的原始數據，比如用戶何時何地做了什麼事情。它依賴於埋點採集系統，而埋點採集，需要收集什麼類型數據，往往由數據產品經理確定規範（還是看公司，數據運營和數據分析師也能負責）。

收集上來的數據需要存儲，往往因為高吞吐量，需要保證數據和日誌的穩定性，會採用Flume+Kafka，如果有實時統計要求，也得考慮流數據。這塊則是數據工程的範疇，包括原始數據的再加工，數據清洗，都是專門的數據團隊完成。

當獲得數據後，首先第一點是講各種明細數據加工業務指標，沒有指標不成方圓，這裡由數據分析師定義的。有了指標，配合各種數據產品輸出，如用戶畫像用戶標籤、BI報表，這些數據產品都由數據PM統籌排期…另外一方面，數據挖掘工程師和演算法專家則憑各種數據建立模型，進行實時或離線運算。

模型可能會預測用戶會不會購買某個商品，可能是做出一系列的推薦，可能是判斷用戶屬於哪個類型，不一而足。

更上面一層是業務相關，數據分析師會監控和分析BI上指標的波動、數據挖掘工程是通過用戶反饋數據，衡量演算法的優劣、數據PM按AB測試的結果改進產品。數據工程師保證系統的穩定。

所有層次一環扣一環，每個崗位在其中都發揮特有的作用。數據工程偏底層技術，數據分析偏上層業務，數據挖掘和數據產品處於中間形態。不同公司雖然業務形態不一致，架構會有差異，但是職責不會偏差太大。這也是數據分析為什麼會有四個方向。

講到這裡，你大概對數據分析的職業規劃有了明晰的了解。當然，它們彼此間並不完全獨立，到後期，很多界限會變得模糊。所以規劃是一方面，是否願意執行、學習和吃透，才是職業真正的道路呀。