---

本文主要從「用戶行為數據「角度介紹一整套的技術架構以及相關的技術要點。希望對你有所幫助。

閱讀指南

• 受眾人群：數據型產品經理、數據運營等初級崗位;
• 閱讀收穫：初步了解用戶行為分析數據類產品的大致架構、掌握4大環節的數據技術要點。

一、用戶行為分析系統

本文將從數據採集、數據接入、數據分析、數據展示等4個重要地方，分別介紹相關涉及的技術知識。這一節主要介紹整體概念。

1.1 概念

用戶行為分析系統其實是指用戶使用產品過程中，把產生的行為數據通過分析而成的報表工具。此類數據區別於業務數據，大多為公開、有許可權獲取的，比如一些設備信息、埋點信息等。

目前行業較為人熟知的有百度統計、友盟、神策等，而使用此類產品的主要是數據分析師、數據運營和產品經理等。目的是為了統計埋點、基礎指標分析(如PV、UV)等，從而對產品進行體驗優化或運營推廣。

1.2 數據系統框架

1.2.1 數據採集

一般用戶使用產品的時候，所填寫的信息會經由業務系統加密儲存。而行為數據是不會經由這些系統收集，而由專門的採集工具進行採集，這就是SDK。

1.2.2 數據接入

因為SDK採集的數據是非結構化的，所以數據都是以原始數據的方式按批次定期或實時上傳。服務端通過介面對這些數據進行解析、加工處理，初步形成結構化的日誌數據，並在資料庫按表進行存儲。

1.2.3 數據分析

當數據解析並存儲之後，即可通過離線和實時兩大方式進行分析。部分指標計算量大且實時要求不高，則會採取T+1、T+2(即第二天、第三天出結果)等離線計算方式。

有些指標時效性要求高，如關鍵指標、日常運營活動(如雙十一)等，就需要較高的實時計算方式，以便監測表現。兩大方式採用的系統框架會有所差別，後面詳解。

1.2.4 數據應用

當使用結構化數據進行分析時，就需要可視化的圖表進行展示，不管哪種方式，基本就是通過報表網站平台進行展示。比如折線圖、表格、柱狀圖等，甚至還需要提供更多維的分析指標支持用戶自主查詢。

二、數據採集層(SDK)

2.1 何為SDK?

2.1.1 定義

SDK是指一種軟體開發工具包，是數據採集的必備工具，英文為「Software Development Kit」。

本質上它其實是一些介面API的文件集合，為某個應用程序提供服務。也可以理解為應用開發者通過接入這些文件，並調用裡面的相關介面，即可採集相應數據。

因為SDK的大小一定程度上會影響應用程序性能，所以盡量輕量處理，占內存大多在幾百K和幾兆之間。

2.1.2 作用

不同業務下，SDK的應用性質是不同的。常見的就有數據行為類SDK、功能服務類SDK以及廣告營銷類SDK等。

其中功能服務類就是指應用通過接入SDK增加一些特殊的產品功能服務，而廣告營銷類則指專門做消息推送、營銷推廣等業務的SDK。而本文僅介紹數據行為類SDK。

2.2 SDK類型

主要分為客戶端SDK和服務端SDK，客戶端SDK是指這類SDK接入在應用的前端，比如iOS、安卓等。而服務端SDK是指接入在後端，更多的在後台底層。

2.2.1 客戶端SDK

iOS SDK：顧名思義，就是以iOS操作系統進行開發的SDK工具包;

Android SDK：同樣是以安卓操作系統進行開發的，可應用在所有安卓類軟體中;

H5 SDK：指以網頁操作系統為生的SDK，可應用在web網站、H5網頁、公眾號(功能實質是H5開發)等;

小程序 SDK：小程序是這兩年新興的產品應用，依賴於不同的軟體平台。所以需要基於不同的平台進行開發，比如微信小程序、支付寶小程序、百度小程序等，同時還需要分iOS和Android兩大系統進行開發。

2.2.2 服務端SDK

定義：服務端的sdk具體通過後端上報數據，即業務應用採集到數據後，通過自身的服務端傳到大數據系統的服務端，即「業務服務端-數據服務端」，而非客戶端SDK的「業務服務端-客戶端SDK-數據服務端「。

類型：由於每個業務的狀況不同，開發語言都不是唯一的，所以針對服務端類型的SDK都會基於不同的語言提供相應的開發版本，包括Java SDK、Pyhon SDK、PHP SDK、C SDK等等。

2.2.3 小結

不同的用戶有不同的業務訴求，客戶端和服務端各有優缺點，主要取決於業務訴求。整體而言，大多數產品應用使用客戶端SDK居多。

2.3 作用

SDK最大的任務就在於採集數據、識別數據和上報數據。

2.3.1 採集數據

由於SDK採集的數據較廣，涉及種類較多，主要分幾類：

設備數據：具體指終端硬體設備，如電腦設備、手機設備等，如果是手機可以具體到手機類型、品牌、網路環境等。如果是電腦，則是電腦型號、瀏覽器類型等;

程序數據：具體指應用程序的數據，比如是APP，則是此APP應用程序內的基礎數據，包括APP版本、渠道、安裝時間等等;

埋點數據：具體指用戶在某應用程序觸發產生的行為數據，比如點擊哪個頁面、停留時長、頁面曝光、啟動時間等等。主要是基於業務考慮進行埋點設計。

2.3.2 識別數據

由於採集的數據屬於原始數據，且SDK層基於原始數據的真實性和唯一性，基本是不會做結構化的邏輯處理，即不會做數據加工。所以SDK在這裡最多會進行識別數據的處理。

識別用戶ID：不管數據如何原始、混亂，有一個關鍵的就是需要識別產生這個數據的「用戶」是誰，所以就有用戶ID的說法。但這個用戶ID不同的產品和業務，各家不盡相同，生成ID的演算法也不同，有人用操作系統的IDFA和IMEI生成設備口徑的演算法，也有人直接用軟體的賬戶ID作為唯一用戶ID,這個是沒有規定的。 例子：「userid」：321990ddwsadnkiouf78hjh」;

識別程序ID：因為SDK是支持多個程序獨立使用的，但是數據最終是在同一個服務端和資料庫，那麼就需要做應用程序之間的區分。這個時候就有應用ID，每個獨立應用分配一個ID，且是唯一的。至於如何分配生成，也是看各家的業務訴求，並沒有唯一標準。例子：「productid」：「12321321321dasdasdas33213」

2.3.3 上報數據

由於SDK在嵌入應用程序前，就已經打通與服務端的介面並進行上報。所以此時SDK是已經界定了一系列的上報邏輯，以及需要傳什麼數據。

原始數據：其實就是一條條原始數據記錄，每條數據附帶那一刻採集的諸多信息，包括用戶ID、設備數據、埋點數據等，但這些數據並不是每條都必帶的，取決於當時的環境是否有提供這些信息.

Session：指某一次節會話信息，主要為了記錄用戶行為習慣。因為每個用戶操作習慣、時長都不同，有可能突然不再操作，又可能隔幾分鐘在操作，對於這樣的情況需要基於業務場景的訴求，定義這些session邏輯，並分別創建不同的sessionid去分割。比如停止操作幾分鐘後、程序退出或切換至後台等是否需要定義。

Cookie：主要是網站使用的一種識別用戶的數據集，一般存儲在用戶本地終端上，以便於用戶在不同時間操作時都可以快速調用且識別為同一個設備用戶。與session區別在於，Cookie存儲在瀏覽器內，數據量有限且相對沒那麼安全。

三、數據接入存儲層

從這一環節開始，就進入服務端運作的流程。這個環境涉及數據接入、解析和存儲等3方面。

前面提到，SDK只會採集原始數據(就好比綠色無污染的食品)，而這些非結構化數據其實不利於管理和使用的。這時候就需要在接入後進行數據解析、清洗加工再扔進資料庫。

3.1 接入層

這一層是服務端與SDK端之間聯繫的一層，所有的日誌數據就是通過這個接入層進行獲取，但獲取成功後是需要返回「成功」的信號給到SDK，證明是暢通的沒有報錯。

但大多數情況下，由於上報的數據較多，儘管是按批次上報，也是會出現類似「排隊」的情況，一個一個去等完成再返回數據效率十分之低。所以這時候就會借用「redis」手段。

redis：Remote Dictionary Server 遠程字典服務，實質是一個key-value存儲系統，一門開源的資料庫技術。簡單來說它就好像一個副伺服器，當主伺服器接收到諸多數據後，都可以扔到這裡來，讓它慢慢接收，並且無需等待返回「結果」信息，主服務就可以告知SDK我這邊「ok」了，請放心。

3.2 邏輯層

這一層的作用實際是指對數據進行解析、清洗加工處理，即日誌數據，因為數據的存儲是要按照明確的資料庫和表的結構來存儲。

日誌數據例子：{「userid」:」3213213hdhdhasjoiewq3321″,」productid」:」dadsadsad2321321″,」mobile」:」samsung:SM-G9008V」,」country」:」CN」}

3.3 數據存儲

提到數據存儲，就必須接觸到資料庫，那麼對於這樣的用戶行為數據，又會使用什麼樣的資料庫呢?目前關於資料庫，主要分為關係型和非關係型資料庫。

3.3.1 關係型資料庫

平常所接觸到諸如Oracle、Hive、PG等，其實這些都屬於關係型資料庫，本質上都是建立在SQL(結構化查詢語言)的基礎上，所以最大的特徵就是結構化。這些適合大量的數據查詢，統一提供增、刪、改、查、排序等多種查詢。

資料庫類型有很多，以下僅列舉常遇見的3種：

3.3.2 非關係型資料庫(NoSQL)

此類資料庫的存在是出於性能、速度等方面考慮，主要是因為關係型資料庫涉及數據較大、結構複雜，一些簡單、體量小的存儲和查詢不適合在這樣的資料庫進行運作，所以才有這樣的資料庫。

上面也提到，其中redis就是這麼一種，以及MongoD、Memcache。

優點：這類資料庫優點在於足夠快、結構單一、數據集中等;

缺點：結構相對沒那麼規範清晰、會有重複冗餘;

3.3.3 資料庫表

在使用SQL查詢的時候，一個關鍵地方就是需要知道表結構。所謂的表結構就是數據表與表之間的關係，以及具體表欄位的含義。所以資料庫表的設計十分重要，對後續SQL查詢計算、機器運行性能、任務執行等方面有很大的影響。

存在在資料庫中的就是一張張這樣的表，通過SQL語句查詢可以快速獲取所要的數據結果。所有原始數據經過解析清洗之後，就會像這樣以結構化的形式進行存儲，以便於管理和使用。

表設計：系統有諸多數據指標，而對於產品或運營而言，就是定義各個指標的統計邏輯和場景。那麼對於技術者來說，除了輸出固定的查詢語句之外，還需要進行合理的表設計。

所謂的表設計，就是根據指標體系把結構化的數據分拆成多張數據表，並進行有機關聯，從而提供合理的統計輸出。

比喻需要固定了解每天使用程序的用戶的某些設備信息(手機型號、品牌、網路環境等)，就可以放在同一張表，而無需跨表關聯影響效率，同時這樣的設計有利於性能。但具體如何設計，主要是基於業務的指標體系考慮。

四、數據分析層

在大數據分析開發當中，有諸如Spark、Hive、Hbase這些資料庫或計算引擎，但這些都基於一套核心的系統，就是Hadoop。要開發一套完整的大數據開發系統，大多數技術都是從Hadoop中獲取能力。

4.1 核心框架Hadoop

4.1.1 定義

Hadoop是大數據開發所使用的一個核心框架，是一個允許使用簡單編程模型跨計算機集群分散式處理大型數據集的系統。很多關於大數據開發的技術模塊都基於此基礎上，覆蓋了數據傳輸、數據存儲管理、數據計算等諸多方面。

4.1.2 作用

使用Hadoop可以方便地管理分散式集群，將海量數據分散式地存儲在集群中，並使用分散式並行程序來處理這些數據。

4.1.3 架構

一套完整的Hadoop框架涉及數據傳輸、存儲到計算等環節，並在這些基礎上提供種類較多的組件，為快速搭建大數據分析平台提供成熟的基礎能力。

• HDFS：能夠提供高吞吐量的分散式文件系統。
• YARN：用於任務調度和集群資源管理。就好比是一個項目的PMO，產品提需求，根據現有的資源、時間、成本等快速分配任務，調動機器資源來支持。
• MapReduce：基於YARN之上，用於大型數據集並行處理的系統。也是初代的計算引擎。Hive就是基於這個系統之上。
• Flume：一個日誌收集系統，作用在於將大量日誌數據從各數據源進行收集、聚合，並最終存儲。
• Sqoop：用於底層數據傳輸的工具。
• Kafka：一種高吞肚量的分散式消息隊列系統。
• Hbase：一個可伸縮的分散式資料庫，支持大型表的結構化數據存儲，底層使用HDFS存儲數據。
• Hive：基於Hadoop的數據倉庫工具，可以將結構化的數據文件映射為一張張資料庫表，並提供簡單的SQL查詢功能，可以將SQL語句轉換為MapReduce任務運行。更多支持離線任務。
• Spark：一個快速通用的Hadoop數據計算引擎，適用於實時任務。同時也應用於機器學習、流處理等。

4.2 計算類型

4.2.1 離線計算

離線計算就是在計算開始前已知所有輸入數據，輸入數據不會產生變化，且在解決一個問題後就要立即得出結果的前提下進行的計算。時間上按天來算，就是T+1、T+2甚至T+7等，主要看指標的時效性優先順序要求。

4.2.2 實時計算

實時計算是相對離線而言，就是指查詢條件不固定、目標不明確，但又對數據需求的時效有較大要求，所以需要實時查詢進行分析。

優點是自定義條件多，能滿足多維分析的數據需求，缺點是考驗查詢引擎，由於處理數據量大短時間輸出結果會有所偏差，且等待時間長。

4.3 計算引擎

按照目前行業的發展，關於計算引擎已經發展到了第4代，第1代是MapReduce，而在這裡重點介紹5種。

• Hive：前面介紹到這種查詢引擎，其實它屬於第2代流行的引擎，目前仍有大量企業使用這個，主要是十分成熟，能滿足大部分的基礎需求場景。但由於數據量大，依賴不少組件，導致數據量一大查詢速度就相對較慢。
• Spark：目前十分流行的第3代查詢引擎，能夠承擔批數據處理，和Hive兼容，相比它查詢速度更快一些，擴展性高。
• Flink：是最近流行的第4代查詢引擎，主要是同時支持流數據和批量式數據處理，相較於Spark有較大得提升。但目前技術相對新一些，應用得還不算多。
• Druid：一種高效實時、迅速的分散式數據查詢系統，它採用不是前3者依賴得hadoop框架。主要支持聚合查詢、實時查詢，且靈活。但有些數據分析指標不一定能支持。
• Impala：一種數據查詢引擎，優點在於高性能、低延遲(准實時)。相比hive繞過底層MapReduce,所以更快。同時也支持複雜的互動式查詢。

整體來說，不同的業務場景採用不同的計算架構，沒有優劣之分，只有合不合適。

五、數據應用層

很多時候，大家常接觸的都是數據可視化平台，比如常見的BI報表平台、數據大屏等，都是充分使用了數據可視化技術進行呈現。

那麼實現這些效果，又用到了哪些技術手段?

5.1 數據平台

在介紹可視化技術前，不得不先說數據報表平台，因為這是大多人常接觸的，如那些圖表、網路圖譜、3D城市模型等。拋開單個而言，它是一個平台化的產品。

目前第三方應用較多的就有百度統計、阿里、友盟、神策等。

5.2 可視化技術

實現數據可視化，除採用前端的基本技術外，還包括相關的圖形技術組件

5.2.1 web前端基礎技術

大多數情況下，前端使用的技術框架離不開這關鍵的3種語言，即CSS、HTML、JavaScript。

CSS：英文全稱Cascading Style Sheets，是一種文本樣式的語言，主要針對文本的位置、色值、字體、字型大小等方面的控制。

HTML：英文全稱 Hypertext Marked Language，即超文本標記語言。主要是通過指令控制文字、圖形、動畫、聲音、表格、鏈接等形式的文本。

JavaScript：對於前端而言，不管是文字、還是視頻，還是其他圖形，都是一種文本。都可以通過以上2點實現。而JavaScript的作用就是在這些「文本」基礎上增加動效功能，也就是我們產品常說的「交互」，這方面的功底體現了這個產品能給用戶提供多好的體驗效果。

5.2.2 可視化技術應用

可視化技術主要是針對數據層面而言的一些技術手段。因為這方面的技術已經十分成熟，且大部分場景下的需求樣式是比較固定的，所以這樣的技術大多開發成為組件，並普遍開源。而這裡則主要介紹前端常見的3種。

• 組件：英文名Component。所謂組件其實就是指一種可用「復用」的功能模塊。因為產品開發到了一定程度，很多時候設計較為接近的，那麼開發往往會基於效率開發成一套可復用的組件，這樣每次遇到同類型的需求，即可快速調用。
• 比如一個柱狀圖，可以定義相關的位置、圖形形狀及布局。通過復用組件化之後，就可以任意改變裡面的參數，比如色值、大小、字型大小等，比較靈活，也省事。
• Echarts：一個基於 JavaScript 實現的開源可視化庫，能夠應用在PC、移動終端等設備上，分別提供常規的圖表(折線圖、柱狀圖之類)，地理數據的地圖，社交關係型的圖譜、旭日圖，以及一些特殊的圖形。Echarts提供了大量豐富的數據可視化圖表，並支持較高定製化，是前端在進行可視化開發中使用較為普遍的工具庫;(網址：https://www.echartsjs.com/zh/index.html)
• D3.js：全稱為Data Driven Documents，本質是一個 JavaScript 的函數庫，通過它來實現數據可視化的，所以它實際是一個通過函數操作數據的文檔。與JavaScript不同的是，D3把一些複雜流程進行精簡成幾個的函數樣式，能夠夠快實現更酷炫的圖形可視化，在原有常規的圖形可以做得更多元化。(網址：https://d3js.org)
• three.js：簡單來說，three其實就是指3D的意思，聽到3D就知道是做立體模型的，同時它同樣基於JavaScript而建立的，所以就有three.js。通過它可實現三維圖形的需求，比如一些城市建築模型、人體模型等。但是由於目前還不算十分成熟，國內相關資料較少，英文文檔的學習成本較高。(網址：https://threejs.org/)

5.3 應用產品

數據分析型：百度統計、友盟、神策、Growing IO等

BI報表類：Tableau、Quick Bi等

可視化類：阿里雲Data V、百度Sugar等

總結

一整套完整的數據系統，涉及方方面面。參與其中的PM，承擔責任也不同。每個人應該基於核心工作，做相關的延伸，不一定都需要掌握。

一名合格的數據分析型產品，數據指標設計、資料庫、SQL查詢、計算引擎，都是必須掌握了解。

其實各大廠都有一套自身的數據技術體系，多關注CSDN、騰訊雲或阿里雲等社區，會有所裨益。

推薦閱讀：《大數據平台演進之路 | 淘寶 滴滴 美團》https://cloud.tencent.com/developer/article/1506317

註：本期的文章涉及較多技術術語，建議反覆閱讀。以上的系統框架圖僅幫助閱讀理解，並不是完整的架構圖。

• 作者：A.D，世界TOP50強公司產品一枚;公眾號：吾某
• 本文由 @A.D. 原創發佈於人人都是產品經理，未經作者許可，禁止轉載。
• 題圖來自Unsplash，基於CC0協議。

---

大家期待已久的《數據產品經理實戰訓練營》終於在起點學院（人人都是產品經理旗下教育機構）上線啦！

本課程非常適合新手數據產品經理，或者想要轉崗的產品經理、數據分析師、研發、產品運營等人群。 課程會從基礎概念，到核心技能，再通過典型數據分析平台的實戰，幫助大家構建完整的知識體系，掌握數據產品經理的基本功。 學完後你會掌握怎麼建指標體系、指標字典，如何設計數據埋點、保證數據質量，規劃大數據分析平台等實際工作技能～點擊官網了解詳情：起點學院-產品經理培訓 | 產品經理培訓課程 | 致力於為IT從業者提供專業、系統的產品經理學習服務，目標成為產品經理黃埔軍校?

www.qidianla.com

---

隨著大數據時代的來臨，最近幾年流行了數據產品經理這個職位，數據產品經理， 廣義上講就是推動業務建立一套數據採集、分析、使用的規則，基於數據的聯通， 推動「一切數據標準化」，進一步促進業務發展。下面就來講一下數據產品經理必備技能之一，也就是把業務數據標準化的基礎：業務指標字典。

指標字典的目標

1）規範維度和量度命名，命名規則要盡量做到明確、通用、易懂；

2）對確認維度或量度，統一計算口徑，避免歧義；

3）涵蓋儘可能多的關注的核心維度和量度，以此為基礎推動數據建設，確保指標字典里覆蓋的維度都可區分，指標都可統計；

4）基於指標字典，將核心維度和量度注入元數據中心，接入指標提取工具，後續實現不需要寫sql即可完成自助查詢及分析需求，可見，指標字典的建立，是搭建數據平台的基礎。

指標字典的基本概念

1.指標

定義：衡量目標的方法。

構成要素：維度＋匯總方式＋量度

• 維度－回答從哪些角度去衡量的問題？
• 匯總方式－回答用哪些方法去衡量的問題？
• 量度－回答目標是什麼的問題？

2.量度

定義：量度是對一物理量的測定，通常以數字單位累表示。比如：金額、份額、次數、率。

讓我們做一個相關思考：

提問：數據是什麼？

腦洞時刻

請看問題：你有沒有「1」？

第一反應：「1」什麼？「1」是指：你有沒有1塊錢？你有沒有1次愛上過我？還是你有沒有1張火車票？

回答：數據＝數字＋計量單位

3.維度

定義：維度是看待事物的視角與方向。

讓我們做一個相關思考：

提問：怎麼去衡量一個人？

腦洞時刻

請看問題：你認為哥哥我是個什麼樣的人？

脫口而出：從性別的角度看，男人；從顏值的角度看，帥到地球爆炸的人；從高考成績的角度看，考了800分的人；從高考中數學成績的角度看，考了150分的人。

回答：從不同的角度去衡量一個人。不同的角度，衡量一個人的方法是不一樣的。

指標定義的規範

指標的口徑

一個指標一經錄入，它的命名和所有下鑽維度的口徑都已確定（默認口徑），這叫做指標的一義性。如「團購交易額」這個註冊指標默認的時間口徑是支付時間，默認城市口徑是下單，等等。如果需要按下單時間口徑看訂單金額，我們定義了一個新的指標「團購下單交易額」。一個在某些維度上口徑不確定的」指標「是不能被使用的，在業務場景中是毫無意義的。

指標的分類

基礎指標

例如：「團購交易額」，作為一個基於單純實體的屬性的簡單計算，它沒有更上游的指標了，或者說它的父指標是它自身。我們稱這樣的指標為基礎指標。

普通指標

也叫派生指標，所謂普通指標，即在單一父指標的基礎上通過一些維度上面的取值限定可以定義的指標。

例如，團購PC首次購買用戶數 ［限制條件：團購訂單.下單平台(二)=PC］

計算指標

也叫複合指標，主要是指可以在若干個註冊指標之上通過四則運算、排序、累計或匯總定義出的指標，我們稱做計算指標。

建設指標字典的方法

量度維度都考慮好了，在構建一個指標字典時應該考慮哪些要素呢？如下表格為你提供一個參考：

讓我們來看一個指標字典維度示例：

再來看一個指標字典量度示例：

通過以上步驟和方法，相信你應該可以根據業務，建議一個指標字典了。

總結

指標字典建立以後，要經過各個業務線PM們的評審，糾正描述不明確或者有分歧的指標，達成一致後，由數據產品經理推廣供大家參考使用。一個好的指標字典分析框架，就像剝洋蔥一樣，先從單維度、粗維度分析，再細拆維度，自外而內的看問題，透過現象發現事物本質。

---

題主你好，對於數據產品經理需要學習哪些內容，這個是要看你從哪一個角度去學習的，我把我的產品經理經驗分享給你，希望對你有所幫助。

除數據分析外，實際上是 bi，還需要數據挖掘，更多建議寫爬蟲和訓練模型，尋找數據，清理數據。

結合自己8年的BAT產品工作經驗和輔導很多人成功轉產品的經驗，寫了一篇文章，萬字乾貨，分享一個【最優的0基礎拿到產品經理offer的方法】，祝大家求職順利！

產品一哥：萬字乾貨！0基礎如何拿到產品經理offer?

zhuanlan.zhihu.com

《0基礎如何拿到產品經理offer-資料分享》，資料提取碼【z8nr】

0基礎如何拿到產品經理offer-資料分享?

pan.baidu.com

產品經理求職-面經分享

產品經理求職-面經分享?

zhuanlan.zhihu.com

---

除了需要數據分析之外，其實就是bi，還需要數據的挖掘，更多推薦寫爬蟲和訓練模型，找數據，清洗數據

---

產品經理的基礎技能。

另外可能需要sql，大數據技術架構的了解。處理實時和離線數據的方式。部分ai能力，excel要好。

---

推薦閱讀：