//
如何實現分析去中心化的客戶行為分析平臺 - 極牛 - SegmentFault
https://segmentfault.com/a/1190000007921028
數據收集架構核心就是LVS+Nginx+Lua，我們沒有用比較重的后端語言來采集，而是選擇了比較輕的Lua腳本語言，在nginx中集成就能完成高并發的復雜
Lua是一種輕型的腳本語言，直接在nginx配置中嵌入，在很多游戲的服務端架構以及電商秒殺的架構中使用。我們服務端接收到上傳數據之后，Lua會進行解析，并且添加上傳時一些信息（ip，服務端時間，User-Agent）等等，然后push到Kafka的集群。我們這套架構也是在諸葛io的日上傳數據量逐步上漲過程中，逐步演化出來的。
模型倉庫，Redshift和Greenplum都是基于PostgreSQL的。我們加上自定義函數，在數據訪問層保持一致
實時數據和關系緩存，我們用的是Codis以及SSDB，Codis是分布式的Redis實現框架（由前豌豆莢團隊開源）我們會用來做分布式的消息以及狀態存儲，而SSDB是基于Redis協議的硬盤實現（作者是懶投資的CTO吳總）我們會存儲一些鍵值比較大或者多的數據，例如實時數據以及數據緩存。
基礎存儲剛剛講過了主要是S3，索引用的是Elasticsearch，比如查詢時的提示等等，在線多維實時數據處理查詢就是Redshift和Greenplum了
<本期主題>
如何實現分析去中心化的客戶行為分析平臺
<大綱>
1.大數據平臺的通用架構
2.諸葛io的技術架構
- 數據采集端
- 服務端收集
- 消息中心
- 數據清洗
- 數據模型
- 數據存儲
<講師介紹>
孔淼，諸葛io 創始人/CEO
連續創業者，畢業于華中科技大學，前37degree CTO。曾帶領團隊打造過脈搏網、知客數據等知名大數據平臺，并服務中國電信、奧美、九陽集團等企業。2014年底，開始打造諸葛io。被李開復博士欽點為“最具潛力的技術人才”，并獲評2015年創業邦“30歲以下創業新貴”。
歡迎來到極牛線上技術分享會，請各位小伙伴注意以下事項。
*本群梅花系技術分享交流私密群，請大家把群昵稱更新為“名字@公司”，分享開始前會把沒有備注的同學請出哦_
1 提問請勿使用語音
2 請務必不要打開實時對講
3 群分享階段，請勿開啟無關本主題的話題
4 為了確保講解流暢，問題請在討論環節提問
5 關于分享方式和形式的建議，請私下接洽我
先簡單介紹下，諸葛io是一款精細化的用戶行為分析平臺，為互聯網企業提供一站式的用戶行為采集智能分析以及決策方案，于2015年3月上線，至今已經超過累計萬家企業注冊試用，并且有過百家的付費客戶，包括優信二手車，ENJOY，在行分答，羅輯思維得到等產品。
今天晚上主要的話題比較技術，主要是聊聊我們背后的大數據平臺設計
從本質上來講，大數據平臺的目標都是完成，對數據的采集，清洗，加工，加載，建模分析，可視化的過程。
先說說數據采集
采集是指集中企業待分析的原始數據的過程，例如可能是包含但不限于以下：
- 企業服務器的日志
- 企業各種信息系統的數據（CRM/ERP/數據庫）
- 企業的網站/App/小程序等客戶端的用戶行為記錄
- 使用的第三方系統（客服、IM、HR）提供的API
采集的方式基本上分為兩種：PUSH（推）和PULL（拉）
PUSH模式：企業的數據一般來講都是散落在很多地方，各種系統或者各種服務器，所以有一個數據采集中心，然后在各個數據產生的位置都有一個agent（可以認為是采集程序）然后朝數據采集中心發送數據的過程就是PUSH，比如在App或者網站植入了SDK，定期發送采集到的用戶行為數據到服務端的過程就是PUSH模式
PULL模式：企業有數據采集中心，從采集中心去訪問獲取各個數據產生點的數據，這個過程就是PULL，比如從企業的數據中心去調用第三方系統的API獲取數據，就是PULL模式
再說說數據的清洗
數據清洗的過程是指對數據進行一些處理，過濾無用的信息，規范得到我們能用到的數據。包括但不限于以下情況：
- 過濾SPAM垃圾數據，例如被攻擊/造假/BUG產生的大量數據
- 抽取有用字段，例如上傳的數據包含的信息很多，我們只用到一小部分
- 原始數據有很多格式不規范，要統一格式
然后就是數據的加工
數據加工是指清洗后的數據，還需要補充一些信息，可能是通過數據庫查詢出來的，也可能是通過計算規則計算出來的，或者算法技術加工出來的新字段。
例如，數據里面有個ip地址，需要計算出用戶的地理位置，那么地理位置就是加工出來的字段。
一般來講，對于大多數大數據分析平臺而言，加工是很重要的過程，基本上最后可用來進行分析的數據，要通過這一步充分完成加工計算。
數據加工完成之后，就是數據加載
數據加載是指把加工后的數據加載到合適的存儲，可能是Hadoop集群的HDFS上，也可能是某個數據庫，有可能是文件等等其他存儲類型。
加載完成后就是建模分析
建模分析是指在查詢前需要把數據進行處理，以優化查詢，例如一下：
- 數據倉庫建好了倉庫模型，要把數據加載到數據倉庫中
- 需要做數據索引，把數據進行索引優化
數據模型很重要，也是整個數據處理分析的核心之一，每個企業都有自己的核心業務，以及核心目標，并且也有各自的數據源以及數據類型，所以也就意味著每一家企業的數據模型多少都會有些差異，也就是最個性化的一個地方，數據倉庫就是這個數據模型的載體，一般來講數據就是數據庫技術，例如常見數據庫之外，還有Infobright，Greenplum，Vertica，也有基于Hadoop技術的，用HDFS作為基礎的存儲，然后使用的查詢引擎，包括Imapla，Presto，SparkSQL等等。
通常而言，數據團隊要進行復雜的查詢和分析，都是在此基礎之上，通過SQL語言或者代碼查詢來實現的。
最后就是可視化了
可視化是最終分析結果要展示的過程，例如“雙十一”酷炫的圖表，一般企業都有自己的數據看板等等。
可視化背后主要是執行SQL或者運行代碼得到的數據結果，可能是一維，也可能是二維，還有可能是多維，然后選擇合適的圖表類型進行展示，例如“線狀圖”、“柱狀圖”、“餅狀圖”、“雷達圖”、“中國地圖”等等。
剛剛講的主要是通用的大數據平臺整個數據處理的方式，不知道是否講的通俗易懂，接下來我就從諸葛io與通用的數據平臺的差異入手，然后帶入我們的技術設計了
首先諸葛io的整套技術能夠做到的是，對企業分析流程的效率提升
大多數企業的分析現狀：自建或者第三方統計平臺（百度統計/友盟/Talkingdata）+ 數據BI團隊（早期團隊人數很少，甚至是一兩個工程師兼任）
- 自建或者第三方統計平臺：大多都是匯總統計指標平臺。對通用指標（例如PV、UV、DAU、留存）的計算，對企業設定好的業務行為（打車、訂單、參與、金額）等匯總統計人數或者次數，數據平臺存儲的都是指標的匯總結果。指標的選擇和下鉆分析都需要數據團隊的支撐。
- 數據BI團隊：完成基礎數據平臺的搭建，并且梳理核心業務分析目標，對基礎數據進行采集建模，并完成各個部門的分析需求。
所以大家可以看到最開始上面那張圖就是大多數企業現在的分析現狀
基本上先統一由大數據部門整理輸出各部門日常固定的數據指標，然后做個可視化，比如一個簡單的頁面
如果有新的分析需求，已經建模好的，那么數據團隊就需要根據業務去寫SQL然后得到結果，如果沒有建模好的，就需要開始采集原始數據，然后重新開始清洗，這樣一個過程，往往都比較反復耗時，分析效率很低
主要原因是，這樣一種分析流程，是由固定的業務指標驅動數據的采集和處理，然后數據處理的過程基本上都是多維匯總的統計和計算
所以也就造成了問題：各個業務部門的分析需求需要依賴數據團隊專業的數據分析能力進行問題建模，并且依賴他們SQL語言或者代碼能力完成分析目標。但數據部門往往也有核心的分析需求和任務，所以公司變大過程中很多問題變得很低效。
相比而言，諸葛io數據分析工具的優勢，諸葛io的整個數據處理也是符合上面的整個流程，我們和其他數據分析平臺，尤其是傳統數據平臺，按照處理過程抽象的差異主要如下：
諸葛io的分析能力遠遠大于目前大多數的統計平臺，我們把很多深入的分析場景，依賴數據團隊進行建模以及SQL/代碼等專業能力，變成了可視化的分析組件。這樣極大的提高了企業的數據分析效率，并且我們還有專業的數據分析看板，輔助企業梳理了解分析需求和目標。諸葛io的亮點如下：
例如以前需要SQL完成的查詢，現在只需要如下：
第二個：豐富的分析組件，支持市場/產品/運營部門的大多數場景分析
根據用戶的新增情況，觸發行為，用戶字段篩選待分析的用戶（用戶群）
對某個業務行為的參與情況（事件分析）
用戶的轉化情況（漏斗分析）
用戶的行為路徑（用戶行為路徑）
某個功能或者某個業務用戶的持續參與（自定義留存）
分析API和數據API，完全掌控您的數據，基于諸葛io靈活擴展
除此之外，細致入微的產品設計，貫穿分析過程
例如：
- 點擊數字到用戶畫像的洞察
- 漏斗的無序和有序
- 用戶群“新增后X天”
- 還有更多的場景，可以去感受和體驗
這樣一來，回到剛剛的圖片
所以我們的流程如上圖
我們在建模時非常抽象，并且基于獨立用戶跟蹤了整個業務的流程，所以不只是指標任意的配置可視化，很多以前依賴于SQL和清洗代碼的邏輯，也變成了交互式的查詢組件，所以能提高效率，那我們是怎么做到的呢？
先來看看我們整體的架構
首先看看數據采集端
首先看看數據采集端
我們提供豐富的接口和SDK，能夠采集到企業各個有用戶行為數據的地方，目前來講，主要分為以下：
Android客戶端 —— Android SDK
iOS客戶端 —— iOS SDK
網站或微站H5 —— Javascript SDK
小程序 —— 小程序SDK
日志 —— 服務端Restful接口
CRM數據庫 —— 導入工具
也就是采用了“PUSH”模式，各個端采集用戶的行為，然后再按照規則發送給我們的數據收集中心，各個端也就寫了一些SDK，讓開發者調用采集
然后就是我們的數據收集端
上圖是我們的數據收集架構
核心就是LVS+Nginx+Lua，我們沒有用比較重的后端語言來采集，而是選擇了比較輕的Lua腳本語言，在nginx中集成就能完成高并發的復雜，LVS做解析服務器的負載均衡，后面是多個Nginx，然后Nginx本身就是高性能高并發服務器，所以并發的承載能力非常強
諸葛io采用的是HTTPS加密傳輸，以及支持HTTP2協議
- 采用HTTPS的原因是，防止數據在傳輸過程中被抓包截獲
- 采用HTTP2協議，服務端的處理性能能夠極大的提升，連接也有優化
使用LVS的原因是，雖然Nginx的性能很高，但是在高并發壓力情況下，我們能夠快速添加Nginx節點，再加上數據采集是異步，所以大流量情況下，LVS+Nginx基本上都能保證不會出現連接等待的情況了。
Lua是一種輕型的腳本語言，直接在nginx配置中嵌入，在很多游戲的服務端架構以及電商秒殺的架構中使用。我們服務端接收到上傳數據之后，Lua會進行解析，并且添加上傳時一些信息（ip，服務端時間，User-Agent）等等，然后push到Kafka的集群。
我們這套架構也是在諸葛io的日上傳數據量逐步上漲過程中，逐步演化出來的。
簡單來講，數據采集具有以下特點：
- 高并發
- 高伸縮性性
- HTTPS安全傳輸
然后就是數據清洗
諸葛io采集到的數據會有以下幾個問題需要處理：
- 垃圾數據 —— 亂碼或者埋點錯誤產生的數據
- 作弊數據 —— 惡意進行注入偽造的數據
- 淘汰數據 —— 已經棄用的SDK版本數據
所以我們會完成對于上述數據的清洗。
清洗完的數據，諸葛io還會進行一些信息加工，包括但不限于以下：
- 識別用戶和設備的身份關系
- 加工字段：地理位置、UTM推廣信息、設備、系統版本（網站或者微站根據UA）
- 事件行為匹配系統id
加工信息之后，我們還會對數據按照我們的數據模型進行格式轉化和預計算處理，得到我們所需要的最優于查詢的數據。
關于數據清洗加工部分，我們和其他大數據技術還有一些差異：
- 獨立的用戶行為跟蹤
- 基于用戶身份的數據整合
- 精準的用戶和設備關系識別
- 事件的標簽化
接下來是數據加載
數據加載的過程，就是把我們數據處理后的結果寫入存儲，這里，諸葛io主要加載的目標位置有以下：
原始數據備份：
—— AWS S3
—— HDFS（私有部署）
加工后的數據
—— AWS S3
—— HDFS（私有部署）
模型數據倉庫
—— Redshift
—— Greenplum（私有部署）
因為諸葛io同時支持SaaS和私有部署，私有部署我們采用的方案會有差異，S3和HDFS都是文件訪問，所以業務層基本是一致，S3是因為存儲成本低，HDFS是大多數企業的Hadoop平臺
加工后的數據同上
模型倉庫，Redshift和Greenplum都是基于PostgreSQL的
我們加上自定義函數，在數據訪問層保持一致
然后在建模分析的過程，建模分析的核心是諸葛io的數據模型，也就是我們的數據倉庫設計，諸葛io現在的核心數據模型，分為以下主題：
用戶
—— 用戶的屬性信息
事件（行為）
—— 事件的屬性信息
—— 事件的觸發環境
行為發生平臺
—— 平臺（設備）的基礎信息
諸葛io的數據模型底層都已經對用戶和行為進行建模，我們從上層指標的計算，可以直接下鉆用戶群體，并且對于用戶的行為歷史也有完整的還原和實時的洞察。
傳統的數據分析平臺都以設備進行統計，我們是基于用戶的，所以用戶和設備的關系我們能精準還原
諸葛io的數據查詢和訪問，主要分為兩部分：
數據訪問層，是諸葛io把基于數據倉庫的SQL查詢訪問抽象了一層服務，分為對內和對外兩部分，用以控制對數據訪問的統一管理。
—— 對內是通過統一的API服務來進行訪問
—— 對外是有Open API的開放平臺
可視化查詢在諸葛主要是通過諸葛io的網站進行完成，并且在技術上也是基于數據訪問層實現。
可視化在諸葛主要分為兩部分：
—— 數據指標展現的可視化
—— 查詢操作的可視化
指標展現可視化，包括不限于表格、柱狀圖、線圖、漏斗。
回到整個架構上
可以看到有消息中心
諸葛io的消息中心是以Kafka為中心進行設計的
消息中心主要處理包含以下業務消息的匯集和分發：
—— 各種SDK或者工具上傳的數據
—— 數據清洗產生的中間的數據
—— 模型結果數據
—— 備份數據
—— 其他流式處理數據
Kafka具有多消費組的特點，也就意味著，我們可以在不同應用場景下對統一數據進行多種處理，并產生多種應用，例如下面場景：
我們收集到各種數據，并會添加到Kafka消息中心，然后會有以下不同消費應用：
—— 進行元數據統計管理
—— 進行備份
—— 進入數據倉庫模型前的清洗
—— 進行實時的統計計算
實時計算中心，我們用的是Spark Streaming進行處理，也有其他套件輔助我們進行一些數據挖掘
實時數據和關系緩存，我們用的是Codis以及SSDB，Codis是分布式的Redis實現框架，由前豌豆莢團隊開源，我們會用來做分布式的消息以及狀態存儲，而SSDB是基于Redis協議的硬盤實現，作者是懶投資的CTO吳總，我們會存儲一些鍵值比較大或者多的數據，例如實時數據以及數據緩存。
基礎存儲剛剛講過了主要是S3
索引用的是Elasticsearch
比如查詢時的提示等等
在線多維實時數據處理查詢就是Redshift和Greenplum了
然后我們統一了整個數據訪問層以及API，并且分為內部和外部API，對外就是網站和開放平臺了
時間差不多了，以上就是我今天的分享，希望對大家有啟發和價值
Q1：業界現在流行一種不需要埋點的數據統計服務，和需要埋點的服務相比有什么樣的差別？
A1：各有優劣，場景不太一樣，之前不少文章和行業小伙伴都寫過文章對比了，可以搜索一下。簡單概括一下，無埋點在數據采集上會比較方便快速，但是采集數據準確率很容易出現數據丟失以及時機失誤的情況，并且采集到的數據也基本上只能是頁面上的顯示元素，分析的時候也都是零散的指標，以及瀏覽量和點擊量的統計
有埋點的服務則在采集上不會那么的便利，但是采集數據會更精確以及豐富，比如后臺的業務數據，而且也能轉換成業務指標進行分析
Q2：如果只有一個產品經理，能通過可視化埋點工具自己埋點嗎？就是有沒有可能在沒有IT投入的情況下，變更數據采集規則
A2：可視化埋點的前提也是要IT來協助接入SDK的，在代碼結構不變的情況下，可以快速去看不同頁面元素的瀏覽和訪問情況
Q3：有沒有這種可能，針對數據A進行用戶行為分析，再把這個用戶群體關聯到另外一個數據B中，進行用戶分析。比如：購買商品A的用戶，是否會瀏覽商品B
A3：于企業而言，肯定是要統一數據A和數據B的用戶關聯性，統一標示體系下的用戶，“購買商品A的用戶，是否會瀏覽商品B”，就是進行交叉查詢就OK，如果是“購買商品A的用戶，還可能會購買商品B嗎？”，就是常見的個性化推薦了
找用戶和用戶，或者用戶和物品或者物品和物品之前的關系
Q4：多少數據量（比如年1000萬條數據）的情況下，比較適合使用第三方數據分析工具？
當然有一定基礎數據，超過可以調研的基礎之上，另外我個人的主觀建議是，都需要數據分析，但如果細分領域的流量紅利還在，就趕緊圈地，如果沒有流量紅利了，就需要更多分析來決策驅動
Q5：是否在服務端進行PULL或者PUSH的數據采集方式，支持的話需要做數據格式清洗嗎？有SDK支持嗎？需要多少開發量？
Q6：當業務在快速變化時，是否意味著要不斷更新App埋點邏輯，以期得到新的統計結果？有什么方式不更新APP就得到統計結果？
A6：后端日志分析+app主業務路徑跟蹤分析+變化業務的埋點跟蹤分析，多數據源整合分析
