目錄
文 | 秦路
這篇文章主要介紹數據分析該如何做好職業規劃,附有一些學習指導。如果你還想通過一些學習資源提升自己的資料技能,推薦你瀏覽這篇文章:
資料人必備:資料庫,SQL,Tableau,FineReport,Power BI教學資源大全
最近有不少同學在後台問我數據分析的職業發展相關,這裡先列一個簡易大綱。它更多是以我所在的互聯網行業展開的。
入門和職業規劃應該從兩個角度考慮:領域和路線。
領域是不少新人常忽略的要素
其實數據分析不會脫離業務存在,你進入哪個行業,很大程度會決定你初期的技能樹和技能點。譬如金融領域的風控模型、行銷領域的生命周期、廣告領域的點擊率預估等,各有各的特色。
如果是一位準備畢業的大學生,不妨多了解自己感興趣的領域,和專業相關是最好的,並且積累相關的經驗,為面試做準備。
如果已經有一定行業履歷,只是想要轉崗數據分析師,那麼跨崗不跨行,避免跳到一個陌生的領域。
領域經驗太寬泛,我給不了太多的指點,主要也就三點:
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 Python資料科學學習手冊」等,我當然不可能都看過,所以也不好推(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測試的結果改進產品。數據工程師保證系統的穩定。
所有層次一環扣一環,每個崗位在其中都發揮特有的作用。數據工程偏底層技術,數據分析偏上層業務,數據探勘和數據產品處於中間形態。不同公司雖然業務形態不一致,架構會有差異,但是職責不會偏差太大。這也是數據分析為什麼會有四個方向。
講到這裡,你大概對數據分析的職業規劃有了明晰的了解。當然,它們彼此間並不完全獨立,到後期,很多界限會變得模糊。所以規劃是一方面,是否願意執行、學習和吃透,才是職業真正的道路呀。
喜歡這篇文章嗎?歡迎分享按讚,給予我們支持和鼓勵!