在數據分析領域下，總會被提及諸如SQL、Hive，甚至Hardoop、Druid、Spark等這些技術上的詞匯。那么作為一名數據領域的產品經理，聽著這些不是很常見的產品知識，又應該具備怎樣的技術知識呢？本文主要從“用戶行為數據“角度介紹一整套的技術架構以及相關的技術要點。

閱讀指南

1. 受眾人群：數據型產品經理、數據運營等初級崗位；
2. 閱讀收獲：初步了解用戶行為分析數據類產品的大致架構、掌握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采集的數據較廣，涉及種類較多，主要分幾類：

1. 設備數據：具體指終端硬件設備，如電腦設備、手機設備等，如果是手機可以具體到手機類型、品牌、網絡環境等。如果是電腦，則是電腦型號、瀏覽器類型等；
2. 程序數據：具體指應用程序的數據，比如是APP，則是此APP應用程序內的基礎數據，包括APP版本、渠道、安裝時間等等；
3. 埋點數據：具體指用戶在某應用程序觸發產生的行為數據，比如點擊哪個頁面、停留時長、頁面曝光、啟動時間等等。主要是基于業務考慮進行埋點設計。

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查詢計算、機器運行性能、任務執行等方面有很大的影響。

（樣例：usertable_01）

存在在數據庫中的就是一張張這樣的表，通過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種。

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

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

五、數據應用層

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

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

5.1 數據平臺

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

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

（樣例：報表平臺）

（樣例：可視化屏）

5.2 可視化技術

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

5.2.1 web前端基礎技術

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

1. CSS：英文全稱Cascading Style Sheets，是一種文本樣式的語言，主要針對文本的位置、色值、字體、字號等方面的控制。
2. HTML：英文全稱 Hypertext Marked Language，即超文本標記語言。主要是通過指令控制文字、圖形、動畫、聲音、表格、鏈接等形式的文本。
3. JavaScript：對于前端而言，不管是文字、還是視頻，還是其他圖形，都是一種文本。都可以通過以上2點實現。而JavaScript的作用就是在這些“文本”基礎上增加動效功能，也就是我們產品常說的“交互”，這方面的功底體現了這個產品能給用戶提供多好的體驗效果。

5.2.2 可視化技術應用

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

組件：英文名Component。所謂組件其實就是指一種可用“復用”的功能模塊。因為產品開發到了一定程度，很多時候設計較為接近的，那么開發往往會基于效率開發成一套可復用的組件，這樣每次遇到同類型的需求，即可快速調用。

比如一個柱狀圖，可以定義相關的位置、圖形形狀及布局。通過復用組件化之后，就可以任意改變里面的參數，比如色值、大小、字號等，比較靈活，也省事。

1. Echarts：一個基于 JavaScript 實現的開源可視化庫，能夠應用在PC、移動終端等設備上，分別提供常規的圖表（折線圖、柱狀圖之類），地理數據的地圖，社交關系型的圖譜、旭日圖，以及一些特殊的圖形。Echarts提供了大量豐富的數據可視化圖表，并支持較高定制化，是前端在進行可視化開發中使用較為普遍的工具庫；（網址：https://www.echartsjs.com/zh/index.html）
2. D3.js：全稱為Data Driven Documents，本質是一個 JavaScript 的函數庫，通過它來實現數據可視化的，所以它實際是一個通過函數操作數據的文檔。與JavaScript不同的是，D3把一些復雜流程進行精簡成幾個的函數樣式，能夠夠快實現更酷炫的圖形可視化，在原有常規的圖形可以做得更多元化。（網址：https://d3js.org）
3. three.js：簡單來說，three其實就是指3D的意思，聽到3D就知道是做立體模型的，同時它同樣基于JavaScript而建立的，所以就有three.js。通過它可實現三維圖形的需求，比如一些城市建筑模型、人體模型等。但是由于目前還不算十分成熟，國內相關資料較少，英文文檔的學習成本較高。（網址：https://threejs.org/）

5.3 應用產品

1. 數據分析型：百度統計、友盟、神策、Growing IO等
2. BI報表類：Tableau、Quick Bi等
3. 可視化類：阿里云Data V、百度Sugar等

總結

1. 一整套完整的數據系統，涉及方方面面。參與其中的PM，承擔責任也不同。每個人應該基于核心工作，做相關的延伸，不一定都需要掌握。
2. 一名合格的數據分析型產品，數據指標設計、數據庫、SQL查詢、計算引擎，都是必須掌握了解。
3. 其實各大廠都有一套自身的數據技術體系，多關注CSDN、騰訊云或阿里云等社區，會有所裨益。

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

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

作者：A.D，世界TOP50強公司產品一枚；公眾號：吾某

本文由 @A.D. 原創發布于人人都是產品經理，未經作者許可，禁止轉載。

題圖來自Unsplash，基于CC0協議。