最近有不少同學向大講臺老師諮詢有關資料分析職業發展的問題，由此可見，隨著大資料的飛速發展，資料分析職業也成為很多同學關注的目標。不要急，大講臺老師這就給大家介紹資料分析的職業發展。

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

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

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

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

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

而路線大致可以劃分成四大方向：資料分析，資料探勘，資料產品，資料工程。

（一）資料分析/資料運營/商業分析

這是業務方向的資料分析師。

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

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

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

都叫資料分析師，其實天差地別。

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

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

負責和支撐各部門相關的報表；

建立和優化指標體系；

監控資料的波動和異常，找出問題；

優化和驅動業務，推動資料化運營；

找出可增長的市場或產品優化空間；

輸出專題分析報告；

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

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

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

以活躍指標的下跌舉例：

活躍指標下跌了多少？是屬於合理的資料波動，還是突發式？

什麼時候開始的下跌？

是整體的活躍使用者下跌，還是部分使用者？

為什麼下跌？是產品版本，還是運營失誤？

怎麼解決下跌的問題

這是一套標準的解決思維。分別對應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會更高一級，一般對應於業務型的資料運營/分析總監。

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

（三）資料產品經理

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

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

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

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

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

我們不妨看幾個資料產品經理要求：

負責大資料產品的設計，輸出需求文件、產品原型；

負責推薦演算法的產品策略，完成相關推薦及個性化推薦產品的需求分析；

負責分析和挖掘使用者消費內容的行為資料，為改進演算法策略提供依據；

負責客戶端資料需求的對接，制定相關埋點規範及口徑，相關業務指標驗證；

報表展示工具的落地和應用；

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

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

雖然資料PM需要熟悉各類資料模型、指標、資料探勘和資料工程的實現，但是聚焦點是把它作為一個專案去實現，故而不用精通。

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

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

（四）資料工程師

資料工程師其實更偏技術，從職業道路上看，程式設計師走這條路更開闊。

在很多中小型的公司，一方面資料是無序的、缺失的、原始的，另外一方面各種業務報表又嗷嗷待哺。沒辦法，分析師只能自己擼起袖子，一個人當三個人用。兼做資料清洗+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這些傳統的資料庫從業者，也是能按這條路線進階，或者選擇資料產品經理方向。

（五）總結：

以上四個崗位就是資料分析的發展方向，它們互有關聯，如果從整個架構來看，

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

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

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

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

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

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

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