【果汁出品】不要快進、不要划走！都是乾貨！
小白轉行大數據開發如何準確評估一個大數據培訓項目能夠滿足自己的需求？能夠符合企業真實工作流？
點擊上方關注「果汁說數據」
【果汁出品】不要快進、不要划走！都是乾貨！
小白轉行大數據開發如何準確評估一個大數據培訓項目能夠滿足自己的需求？能夠符合企業真實工作流？
+
目錄：
1、背景
2、個人定位
2.1、大數據生態崗位深度解讀
2.1.1、背景
2.1.2、大數據概念
2.1.3、大數據發展歷程
1、大數據運維工程師
2、大數據平台開發工程師
3、 數據倉庫工程師
4、數據測試工程師
5、數據分析師
6、算法工程師
7、數據產品經理
8、數據可視化
3、 市場狀況
3.1、低代碼又火了？數據產品早就開始低代碼了？你個**還死磕技術呢？
4、 體系化+靈魂
4.1、課程體系化
4.2、師傅體系化
4.3、學習方法體系化
4.4、實操體系化
4.5、簡歷+面試體系化
4.6、試用期度過思路體系化
4.7、成長路線體系化
5、 面試場景題
1、背景
2、個人定位
2.1、大數據生態崗位深度解讀
2.1.1、背景
最近粉絲們關於大數據的問題非常多，看到很多問題都是問「我想從事大數據，應該怎麼準備？」，「如何入門大數據」等類似的問題？以前在面試的時候包括校招和社招，也經常碰到說今後的職業規劃想做大數據，面對這樣的回答，我表示很無語。
我對大數據定位成一個生態體系，像後端開發，人事崗、營銷崗一樣，其實背後是有好幾個細分崗位劃分的，在求職的時候需要有一個明確的目標定位的，目標定位越明確，準備越充分，成功率也越高。
2.1.2、大數據概念
百度百科 : 大數據是指無法在一定時間範圍內用常規軟體工具進行捕捉、管理和處理的數據集合，是需要新處理模式才能具有更強的決策力、洞察發現力和流程優化能力的海量、高增長率和多樣化的信息資產。
Volume：海量的數據規模，數據體量達到PB甚至EB級別，這裡的數據量主要來源於網絡日誌，多媒體數據等。
Variety：異構的數據類型，不僅僅包含結構化的數據、還包括半結構化和非結構化數據，比如日誌文件、圖像、音視頻等。
Velocity：快速的數據流轉，數據的產生和處理速度非常快。
Value：價值密度低，有價值的數據占比很小，需要用到人工智慧等方法去挖掘新知識。
2.1.3、大數據發展歷程
通過一張圖來簡單看一下發展歷程，可以看出來大數據的鼻祖是數據倉庫，所以現在做大數據比較資深都是從數據倉庫、數倉架構師、數倉模型師轉型過來的，隨著計算機技術的發展，計算成本、存儲成本大幅降低，逐漸產出了數據湖、數據中台這樣的解決方案和概念。
2.1.4、大數據崗位生態體系
這也是本篇分享的重點，也是能夠解開很多想入門大數據行當初學者的關鍵所在。
大數據崗位生態體系嚴格來說可以細分成下面9個崗位，當然這9個崗位並不是在每個公司都會劃分的這麼細，越是重視數據、越是財大氣粗的公司劃分的越細，很多公司的數據人員會身兼數職，比如大數據運維和大數據平台開發，數據倉庫與數據測試等，都是同一個人兼著。
這9個崗位有什麼
關係呢？哪個更高大上呢？其實他們也是有生態鏈(鄙視鏈)的。
大數據要在業務端發揮價值，一定要有數據產品經理(數據分析師某種程度上也兼職這個角色)、數據可視化工程師將數據呈現出來給到老闆、業務方、用戶。
但是數據產品不像其他業務型產品在一定用戶需求基礎上衍生出來，產品經理在能力則決定著產品的受歡迎程度，但是數據產品經理如果只在用戶的需求基礎衍生是遠遠不夠的，因為普通用戶根本不知道背後還有數據這回事，裡面的價值是需要有數學功底和業務功底的才能探索出來的，僅僅靠數據產品經理就有點力不從心了，所以這個時候數據分析師、算法工程師、數據挖掘工程師就登場了，他們在研究挖掘海量數據之後（這裡數據低價值密度的特性大幅提高了門檻），會提出概率更高的價值點交給產品經理進行調研、設計、上線。估計這個時候會有很多人不同意我的觀點，實際工作流程大部分不是這樣的，實際情況確實也是這樣，這是因為目前的數據產品經理大都是從有數據經驗的人轉過來的，所以本身已經具備了這樣的能力。這也是為什麼數據產品經理比業務線產品經理更難的原因之一。
再往前看，數據量這麼大，類型又這麼多樣，數據分析師、算法工程師、數據挖掘工程師每個人都直接從原始數據進行計算、分析顯然是及其低效的，另外如果數據質量太差的話，分析或者挖掘出來的價值點可能是負面的，這個時候數據倉庫工程師、數據測試隆重登場（大部分公司這兩個角色是二合一的，包括頭部網際網路公司分開的都不多），前面的髒活、累活我們全包了，你們只管挖掘價值就好了，價值出來了，我們也是功勞的，所以數倉工程師更側重的是底層數據清洗和建模。
再往前看，前面說了現在數據最大特點BIG，在哪裡存儲和計算呢，並且計算時效性比以前還高，各種實時大盤數據需求，最上游的運維和大數據開發工程師終於出場了，帶寬、內存、時效性都不是事，我們來搞定。這裡就要點名一下大數據開發工程師（簡稱大數據工程師）了，是被網上的轉行者點名最多，也是被崇拜最多的，雖然很多人都不熟悉你，真是令其他幾位兄弟姐妹羨慕。
下面就每個崗位都逐一解釋一下，主要是通過工作內容來認識他們
從上帝視角來看他們其實就是數據中台這個大家庭中分工不同的工作者
業務價值（業務創新，形成核心壁壘）
1、以用戶為中心，用洞察驅動企業穩健行動
2、以數據為基礎，直系大規模商業模式創新
3、盤活全量數據，構築堅實壁壘已持續領先
技術價值（成本低、能力多、應用廣）
1、應對多數據處理的需求
2、豐富標籤數據，減低管理成本
3、數據價值能體現業務系統效果而不僅是準確度
4、支持跨主題域訪問數據
5、數據可以快速復用、不僅是複製
總結：數據中台是把業務生產資料轉變為數據生產力，同時數據生產力反哺業務，不斷疊代循環的閉環過程——數據驅動決策、運營
1、大數據運維工程師 （運開）
負責溝通協調數據開發團隊，實時監控調度腳本的執行效率，確保平台資源的高效合理使用
負責Hadoop生態組件的部署升級、擴容縮容、性能和管理優化、問題排查等,包括但不限於CDH、HDFS、YARN、hive、HBase、Spark和Flink等
2、大數據平台開發工程師
參與大數據平台工具鏈(元數據、開發平台、調度系統、資源控制等)的設計、開發、維護與優化
參與報表系統、數據分析系統、數據產品等功能設計開發
業內最有名的是阿里的ODPS
3、數據倉庫工程師
數據倉庫之離線/實時ETL開發及優化
數據倉庫之模型設計
數據可視化開發
推動大數據應用技術與平台
典型產出如下圖
4、數據測試工程師
負責數倉計算邏輯正確性測試
負責數據產品數據的準確性
保證數據埋點的可靠性與準確性
負責數據自動化測試策略和系統建設
這個崗位現在大數據領域裡面是最被忽視的，數據質量也是目前大家最頭疼的問題之一
5、數據分析師
建設管理報表體系，並進行報表的開發維護與檢測
搭建業務KPI指標體系，並進行監測與分析，為公司產品運營優化提供建議；
撰寫數據分析報告，為業務問題原因排查提供數據支持及解決方案；
給業務部門提供運營、產品、活動數據，根據數據問題，提出相應的解決建議
主要產出
6、算法工程師
語音、圖像、自然語言處理、深度學習等機器學習算法開發及優化；
推薦、搜索、廣告系統的算法開發及優化
挖掘並推進算法在業務中應用
機器學習平台開發及優化
抖音推薦
7、數據產品經理
負責BI產品、數據可視化規劃、設計、疊代工作 ，通過數據為業務賦能
負責協助公司各業務⽅向⼤數據應⽤產品調研、規劃、執⾏
負責梳理業務需求，甄別業務場景和價值，制定研發優先級，跟蹤研發流程，確保價值交付
負責數據產品的開發項目管理工作，確保項目按照需求如期完成
8、數據可視化
負責大數據項目/產品前端展示模式規劃構思和創意設計
負責常規圖表組件的封裝、地圖組件技術的疊代與維護、頁面元素動效的維護等；
負責報表平台輸出可視化顯示及疊代
數據可視化可以分為2種，一種是通過BI工具（Tableau、SuperSet等）或者Excel/PPT實現。
還有一種是前端開發工程師實現。
一個數據產品生產鏈路
這裡給大家說一下一款數據產品是如何生產上線的，比如下面這個實時駕駛艙看板，包含了交易明細，各種不同程度的匯總數據，有離線數據，有實時數據。
一般生產流程可以通過下圖來說明，如果需求當中包括一些預測之類的數據，這個時候算法工程師也會介入進來。
上面重點從崗位的生態系統鏈、崗位的主要工作內容，以及典型的數據產品生產流程，詳細介紹了大數據崗位家族中的9個崗位，其目的就是希望在校大學生或者想轉入大數據行當的同學，對大數據有一個整體和全貌的認知。
當有了這個認知之後，希望再問問題的時候或者說跟面試官說自己的規劃的時候，不是直接說想做大數據，或者如何準備大數據，而是希望直接問具體的某個崗位如何準備或者選擇，當有了這樣比較具體的目標之後，自己準備起來也會更加高效和聚焦，如果能對大家有了這樣的幫助，我的目的也就達到了。
3、市場狀況
3.1、低代碼又火了？數據產品早就開始低代碼了？你個**還死磕技術呢？
低代碼開發平台是通過少量代碼就可以快速生成應用程式的開發平台。最近許多技術峰會都出現低代碼，低代碼是中台之後，又一個熱門話題和名詞了。
今年在阿里雲棲大會、架構師峰會等很多技術峰會上都看到了低代碼的專場，低代碼可以說是中台之後，又一個熱門話題和名詞。2018年至2021年上半年，中國低代碼無代碼賽道熱度持續升高。
一、低代碼是怎麼火起來的?
1. 什麼是低代碼
百度百科：低代碼開發平台（LCDP）是通過少量代碼就可以快速生成應用程式的開發平台。通過可視化進行應用程式開發的方法，使具有不同經驗水平的開發人員可以通過圖形化的用戶界面，使用拖拽組件和模型驅動的邏輯來創建網頁和移動應用程式。
2. 信息社會的發展階段
縱觀網際網路以及信息社會的發展軌跡，可以劃分為以下幾個階段：
網際網路時代：從早期搜狐、網易開始的網際網路新聞資訊改變紙質新聞，到淘寶、攜程各種B2C、O2O、OTA商業模式的逐步成熟，再到網際網路+一切，不到十年的時間，網際網路快速發展。
移動時代：智能終端的由探索到普及，Java客戶端轉向塞班系統，Android系統，以及賈伯斯對蘋果的革新，移動化成了新的增長點。各企業紛紛推出手機端XX。
數據化時代：隨著移動網際網路的滲透，網際網路到了下半場，人口紅利散去，用戶增長遇到了瓶頸，企業紛紛開始數位化轉型，期望利用數據化、精細化的運營手段，挖掘新的業務增長點。
中台時代：2019年被很多人稱之為中台元年，中台之所以被當作數位化轉型的救命稻草，本質是因為中台的復用能力，數據快速服務化輸出的能力，可以更快的實現數據賦能。
如果大廠可以搞中台，那資本、技術、人才短缺的中小企業，也想數位化轉型，數據化運營，該何去何從呢?於是，出現了很多企業服務公司，專門為其他公司提供數字型所需的產品和服務，也就是現在比較火的SAAS產品。例如，阿里雲、騰訊雲等雲廠商除了提供基礎的雲計算資源外，還輸出雲上的數據開發、數據分析產品。
而神策、GrowingIO則是聚焦為企業用戶行為分析產品及解決方案。採購現成的產品通用性強，但業務適配的度不高，定製化的支撐響應周期長或成本高。那麼除了買別人的產品，還有沒有其他方案呢?答案就是低代碼。
二、低代碼的基本原理
問卷類產品應該是最早應用低代碼思想的產品之一了吧。問卷的題目類型相對固定，單選、多選、文本輸入，加上題目之間的跳轉邏輯設置，無任務技術基礎的人都可以快速創建一個問卷進行投放。
低代碼的基本原理是：將業務流程的實現代碼封裝成一個組件，像樂高的積木塊，或者PPT的各種圖形元素，使用者只需要按照自己的需求或者想像，在畫布上進行設計即可，各個模塊拼接完成發布後，即可完成一個產品的開發。可以做到低代碼的前提是，業務流程涉及的模塊可以進行抽象，形成通用的組件。
三、低代碼解決了什麼問題
試想，一個新公司成立，需要OA系統、人事系統、財務系統、數據系統等各種各樣的系統，純自研不僅需要大量的資源投入，時間周期可能也很長。直接外采，人家又不是為你的業務量身定製的，例如人事單據的審批流程，採購合同管理等業務屬性強的功能，無法支撐怎麼辦，要麼忍，要麼滾?一句話描述低代碼，其實就是用最短的時間上線一款更符合業務需求數位化產品。
從傳統的軟體開發流程和低代碼平台的軟體開發流程對比可以看出，低代碼平台主要解決了開發效率、人力成本、靈活擴展性等問題。
縮短開發周期：
圖形化界面拖拉拽的方式搭建業務流程，後台進行代碼生成，減少前端和後端代碼工作，縮短開發時間;
業務人員可以跳過開發，直接從需求到產品;
集成了雲計算等基礎資源的低代碼平台，還可以節省環境搭建工作。
降低成本：
低代碼平台一旦建設完成，新增應用對開發依賴的低，初級開發人員和業務人員也可以利平台快速開發應用軟體，降低軟體開發的人力成本
組件、功能的復用，避免重複造輪子;
開發流程簡化周期縮短，應用軟體開發的其他各類支出同時減少
靈活擴展性：
應用開發達到了所見即所得的效果，便於產品快速試錯
業務流程變化，只需更新配置發布即可，無需開發介入發布版本
體驗一致性：
傳統前端開發，一般是多端多團隊開發，UI自定義程度較高，容易導致UI界面不一致，造成用戶體驗感下降。
低代碼平台內置統一的交互和設計風格，生成應用軟體UI高度統一
相對穩定性：
軟體開發中，最常見的問題來源於開發人員的代碼Bug，低代碼平台封裝流程引擎、統一接口、抽象通過組件，減少人的參與，系統更穩定。
平台層面可以進行統一的安全管理措施。例如權限管理，防黑客攻擊等，從整體保障軟體安全，使用者無需過多關注。
四、數據產品演進過程的低代碼思想
數據產品是為了降低數據的處理、應用流程而生，其實本身就自帶低代碼的基因。例如，數據開發平台，將ETL流程配置化，通過頁面的參數配置，實現任務的智能以來和自動化調度，取代過去利用cron表達式進行任務的周期執行操作。
數據可視化產品從前後端的定製化開發，到自助分析、可視化門戶的自助化配置。用戶畫像標籤生產和營銷應用，從開發casebyCase的處理，到基於CDP&DMP的封裝，實現業務自助營銷。
數智化應用中的推薦接口，也可以利用機器學習平台實現模型特徵的復用、推理服務的系統化配置。只不過，很多數據產品誕生之初是聚焦於企業內部用戶，缺少以低代碼概念的包裝對外輸出。在商業化數據產品領域中，BI產品應該算是低代碼在數據領域的最早實踐吧。
五、總結
每一個新的技術概念流行的時候，可能很多企業都已經深耕實踐多年。低代碼的風雖然這兩年才再度興起，但是數據產品一直在做的事情就是低代碼，這也是為什麼數據中台在2019年會爆火。
不管低代碼這個行業如何發展，不斷地抽象業務流程，提升組件化的復用能力也是每個數據人的追求。
降本增效！！！
4、體系化+靈魂
4.1、課程體系化
業務理解能力
需求拆解能力
模型設計能力
架構設計能力
全鏈路優化能力
數據治理能力
時間管理能力
復盤能力
結構化思維
4.2、師傅體系化
4.3、學習方法體系化
4.4、實操體系化
根據自己在實際工作中的處理步驟,給大家整理了一下數倉在接手一個新業務時應該如何處理。這是一個長遠考慮的步驟,要看自己所在公司給多少時間來做。也有一開始就讓你接需求且要的比較急的,你就不太可能從第一步循規蹈矩的做到最後一步了。大家可以根據具體場景靈活變通。
1、業務調研
1.1、主要是了解你負責這塊業務的總體情況是怎樣的。
1.2、該業務主要解決公司的什麼問題。
1.3、該業務從流程最開始到結束整個是如何流轉的.有條件去輪崗是最好的。
1.4、這個業務涉及到哪些系統,系統之間是如何交互的。
2、數據調研
2.1、有哪些數據源,分布在什麼地方?業務庫?接口?
2.2、整理數據源中的表?我們需要將表與實際業務對應起來?
這塊我一般會帶著表去問研發幾個問題:這張表的作用是什麼?發生怎樣的業務場景就會往該表中寫一條數據?哪些重要欄位會隨著業務的推進發生變更?如何確定表中唯一一條數據？
3、需求調研
3.1、主要是指標的分析和拆解指標.其實就是一堆指標的定義和口徑的確定。
3.2、需求的產出形式.比如推到指定的報表庫,還是以接口形式發布。
4、ADS層的表設計
4.1、主要設計ads層表有哪些欄位。
5、數倉建模
5.1、按照建模方法論,設計其事實表和維度表。
6、數據ETL並落物理模型
6.1、數據的ETL過程.清洗數據(數據類型變換,時間格式處理,空值處理,單位處理等等),按照設計的模型表欄位進行ETL加工。
7、數據測試
8、上線調度
9、數據質量校驗
4.5、簡歷+面試體系化
4.6、試用期度過思路體系化
4.7、成長路線體系化
5、面試場景題
5.1、到了新公司或者目前公司數倉準備新接入一個新的業務系統的數據，一般需要做那些準備？
1、了解業務，找這條業務線(部門)的業務人員或者業務系統開發多溝通，多看一些業務相關文檔
2、找運營、產品聚焦一下這條業務線的核心指標，對核心指標做一個拆解，比如，拆解網際網路金融行業-業務收入規模：
第一層功力之指標拆解思路
業務收入規模 = 借貸業務收入規模 + 其他模塊收入規模
第二層功力之運營目標拆解思路
借貸業務收入規模 = 新用戶日活 * 授信通過率 * 首借申請率 * 首借申請金額 + 老用戶日活 * 復借申請率 * 復借申請金額
其他模塊收入規模 = 分期商城 + 生活服務 + 增值會員 + .....
第三層功力之目標群體拆解思路
新用戶 = 新引入 + 新註冊 + 新授信 + 首借款
老用戶 = 復借款 + 沉默用戶 + 流失用戶
存量用戶 = 商城用戶 + 福利用戶 + 會員用戶 + .......
第四層功力之業務場景拆解思路
新用戶：
調整渠道分配（應用市場、信息流等）提升授信申請率 /首借申請率
設計多個節點（註冊直跳、額度誘導、活動誘導）引導用戶進入授信流程
授信流程斷點運營策略（退出時攔截、斷點後觸達）
首借激勵政策（基於風險分層制定減息券）
首借斷點電銷觸達
老用戶：
日常任務機制（提額任務、積分任務）
活動促活（參與得免息、福利）
周期性復借權益下發
業務服務消息通知（如借款狀態變更）
周邊業務路徑引導（福利、電商）
沉默、流失用戶召回
存量用戶：
會員權益激活引導（激活體驗期、首月低價）
福利業務激活引導（新人抵價券）
分期商城商品運營（首頁、聚合頁貨架選品）
價值分層運營（累積價值*風險水平*可用額度交叉分層）
偏好分層運營（偏好內容觸達）
第五層功力之全鏈路數據運營思路(數據產品設計思路)
新用戶：
渠道質量綜合評估（成本、風險、收益）
授信引導路徑AB Testing
首借分層激勵策略
授信、首借斷點自動化觸達與分析
老用戶：
日常任務提醒自動化
周期性復借權益自動化與診斷優化
活動設計ABTesting
沉默、流失原因診斷與觸達策略設計
存量用戶：
商城、福利、會員板塊引導入口歸因
用戶分層策略設計落地（價值分層、偏好分層）
會員權益-界面價值主張AB Testing
會員權益-激活策略AB Testing
3、構建總線矩陣，宏觀，梳理業務過程、維度、核心指標
4、根據業務過程抽象主題、事實表、粒度
5、維度建模方法，自下而上的
構建dwd明細層(重點)、dws輕度匯總層、ads應用層、dim維度層。
設計星型、雪花模型、星座模型等
6、入倉文檔設計好、開始實施
7、邊干邊調整、小步疊代
5.2、19年統招普本畢業的，專業是電子信息的，但是學的一塌糊塗轉行的大數據。由於是轉行，當初面試不是很理想，迫於現實情況就進了外包公司，到現在對這個行業有了一點了解才知道我做的事情是比較雜，然後接觸不到核心業務，技術提升也比較慢。期間用過spark、hbase、hive等，但是都停留在完成需求的階段，會用而已。就是那種別人叫幹嘛就幹嘛的，打雜的。不知道是不是因為外包，我們建模一般也是有公司的建模專家建模，我只是寫sql的.我覺得不能再這樣混下去了，現在公司還是用的阿里雲的dataworks一站式傻瓜操作的，也不知道怎麼寫上簡歷。我想趁今年四月份公司合同到期就換家自研，應該要做哪些方面的準備呢？目前感覺算法是來不及學習了，現在每天背調優和組件原理，你推薦的那本《大數據之路》我看了幾十頁，感覺好像對我面試也沒有太大的幫助，更多的是加深了我對整個大數據系統的認識，等下份工作穩定了會讀完。我想請教果哥，對於我這種經歷，你有什麼建議嗎？如果是你，會怎麼利用剩下的兩個月時間準備四月的跳槽呢？
1、定位
2、數據倉庫工程師重點是4個思維：業務思維，產品思維，技術思維，復盤思維。
業務思維：學習業務知識，積累業務經驗，體現業務價值
產品思維：
工程師思維關注技術至上，技術水平代表實力，向於在產品中使用先進、流行的技術，因為掌握先進主流的技術可以提高他的身價。
產品思維關注的是，這技術能給用戶帶來什麼價值？有什麼商業價值？
所以我需要跳出這個怪圈，學會用產品的思維去思考問題，這樣也能夠開拓自己的眼界，無論是技術還是其他的路，都可以走的更遠。
技術思維：技術廣度/深度，基於技術的解決方案
復盤思維：把業務理解能力、產品思維、技術能力結合數據沉澱成可復用的綜合能力。
這上面4個方向，前3個是硬實力，後1個是軟實力。正常的開發多多少少都會涉及上面的內容，抓住一個作為自己的亮點，業務和產品以及復盤可能你並沒有太大的真實感受，前三個不是一時半會能說清楚的，相當複雜，我主要說技術。
技術廣度，作為數據倉庫工程師
數據流轉全鏈路 : 在每個鏈路應用哪些組建，比如數據入倉用datax或者sqoop，數倉構建需要的模型、數據質量、元數據管理；
技術深度，必須對某個技術棧有比較深入的了解，比如離線的hive，實時的flink；解決方案，基於廣度和深度，對於一些企業的需求文檔設計對應的解決方案的能力。
發現問題->解決問題->優化問題，就是可以說出去的亮點！
阿里dataworks本身就是為了讓數據開發能快速輸出結果
主動思考為什麼？
5.3、自學完電商數倉這個項目能夠找到一份1.5-2w的工作？