//
如何實(shí)現(xiàn)分析去中心化的客戶行為分析平臺(tái) - 極牛 - SegmentFault
https://segmentfault.com/a/1190000007921028
數(shù)據(jù)收集架構(gòu)核心就是LVS+Nginx+Lua，我們沒有用比較重的后端語(yǔ)言來(lái)采集鞠苟，而是選擇了比較輕的Lua腳本語(yǔ)言乞榨，在nginx中集成就能完成高并發(fā)的復(fù)雜
Lua是一種輕型的腳本語(yǔ)言，直接在nginx配置中嵌入偶妖，在很多游戲的服務(wù)端架構(gòu)以及電商秒殺的架構(gòu)中使用姜凄。我們服務(wù)端接收到上傳數(shù)據(jù)之后，Lua會(huì)進(jìn)行解析趾访，并且添加上傳時(shí)一些信息（ip态秧，服務(wù)端時(shí)間，User-Agent）等等扼鞋，然后push到Kafka的集群申鱼。我們這套架構(gòu)也是在諸葛io的日上傳數(shù)據(jù)量逐步上漲過(guò)程中愤诱，逐步演化出來(lái)的。
模型倉(cāng)庫(kù)捐友，Redshift和Greenplum都是基于PostgreSQL的淫半。我們加上自定義函數(shù)，在數(shù)據(jù)訪問(wèn)層保持一致
實(shí)時(shí)數(shù)據(jù)和關(guān)系緩存匣砖，我們用的是Codis以及SSDB科吭，Codis是分布式的Redis實(shí)現(xiàn)框架（由前豌豆莢團(tuán)隊(duì)開源）我們會(huì)用來(lái)做分布式的消息以及狀態(tài)存儲(chǔ)，而SSDB是基于Redis協(xié)議的硬盤實(shí)現(xiàn)（作者是懶投資的CTO吳總）我們會(huì)存儲(chǔ)一些鍵值比較大或者多的數(shù)據(jù)猴鲫，例如實(shí)時(shí)數(shù)據(jù)以及數(shù)據(jù)緩存对人。
基礎(chǔ)存儲(chǔ)剛剛講過(guò)了主要是S3，索引用的是Elasticsearch拂共，比如查詢時(shí)的提示等等牺弄，在線多維實(shí)時(shí)數(shù)據(jù)處理查詢就是Redshift和Greenplum了
<本期主題>
如何實(shí)現(xiàn)分析去中心化的客戶行為分析平臺(tái)
<大綱>
1.大數(shù)據(jù)平臺(tái)的通用架構(gòu)
2.諸葛io的技術(shù)架構(gòu)
- 數(shù)據(jù)采集端
- 服務(wù)端收集
- 消息中心
- 數(shù)據(jù)清洗
- 數(shù)據(jù)模型
- 數(shù)據(jù)存儲(chǔ)
<講師介紹>
孔淼，諸葛io 創(chuàng)始人/CEO
連續(xù)創(chuàng)業(yè)者宜狐，畢業(yè)于華中科技大學(xué)势告，前37degree CTO。曾帶領(lǐng)團(tuán)隊(duì)打造過(guò)脈搏網(wǎng)抚恒、知客數(shù)據(jù)等知名大數(shù)據(jù)平臺(tái)咱台，并服務(wù)中國(guó)電信、奧美、九陽(yáng)集團(tuán)等企業(yè)。2014年底列赎，開始打造諸葛io团甲。被李開復(fù)博士欽點(diǎn)為“最具潛力的技術(shù)人才”，并獲評(píng)2015年創(chuàng)業(yè)邦“30歲以下創(chuàng)業(yè)新貴”祥诽。
歡迎來(lái)到極牛線上技術(shù)分享會(huì)譬圣，請(qǐng)各位小伙伴注意以下事項(xiàng)。
*本群梅花系技術(shù)分享交流私密群雄坪，請(qǐng)大家把群昵稱更新為“名字@公司”厘熟，分享開始前會(huì)把沒有備注的同學(xué)請(qǐng)出哦_
1 提問(wèn)請(qǐng)勿使用語(yǔ)音
2 請(qǐng)務(wù)必不要打開實(shí)時(shí)對(duì)講
3 群分享階段，請(qǐng)勿開啟無(wú)關(guān)本主題的話題
4 為了確保講解流暢维哈，問(wèn)題請(qǐng)?jiān)谟懻摥h(huán)節(jié)提問(wèn)
5 關(guān)于分享方式和形式的建議绳姨，請(qǐng)私下接洽我
先簡(jiǎn)單介紹下，諸葛io是一款精細(xì)化的用戶行為分析平臺(tái)阔挠，為互聯(lián)網(wǎng)企業(yè)提供一站式的用戶行為采集智能分析以及決策方案飘庄，于2015年3月上線，至今已經(jīng)超過(guò)累計(jì)萬(wàn)家企業(yè)注冊(cè)試用购撼，并且有過(guò)百家的付費(fèi)客戶跪削，包括優(yōu)信二手車谴仙，ENJOY，在行分答碾盐，羅輯思維得到等產(chǎn)品晃跺。
今天晚上主要的話題比較技術(shù)，主要是聊聊我們背后的大數(shù)據(jù)平臺(tái)設(shè)計(jì)
從本質(zhì)上來(lái)講毫玖，大數(shù)據(jù)平臺(tái)的目標(biāo)都是完成掀虎，對(duì)數(shù)據(jù)的采集，清洗付枫，加工涩盾，加載，建模分析励背，可視化的過(guò)程春霍。
先說(shuō)說(shuō)數(shù)據(jù)采集
采集是指集中企業(yè)待分析的原始數(shù)據(jù)的過(guò)程，例如可能是包含但不限于以下：
- 企業(yè)服務(wù)器的日志
- 企業(yè)各種信息系統(tǒng)的數(shù)據(jù)（CRM/ERP/數(shù)據(jù)庫(kù)）
- 企業(yè)的網(wǎng)站/App/小程序等客戶端的用戶行為記錄
- 使用的第三方系統(tǒng)（客服叶眉、IM址儒、HR）提供的API
采集的方式基本上分為兩種：PUSH（推）和PULL（拉）
PUSH模式：企業(yè)的數(shù)據(jù)一般來(lái)講都是散落在很多地方，各種系統(tǒng)或者各種服務(wù)器衅疙，所以有一個(gè)數(shù)據(jù)采集中心莲趣，然后在各個(gè)數(shù)據(jù)產(chǎn)生的位置都有一個(gè)agent（可以認(rèn)為是采集程序）然后朝數(shù)據(jù)采集中心發(fā)送數(shù)據(jù)的過(guò)程就是PUSH，比如在App或者網(wǎng)站植入了SDK饱溢，定期發(fā)送采集到的用戶行為數(shù)據(jù)到服務(wù)端的過(guò)程就是PUSH模式
PULL模式：企業(yè)有數(shù)據(jù)采集中心喧伞，從采集中心去訪問(wèn)獲取各個(gè)數(shù)據(jù)產(chǎn)生點(diǎn)的數(shù)據(jù)，這個(gè)過(guò)程就是PULL绩郎，比如從企業(yè)的數(shù)據(jù)中心去調(diào)用第三方系統(tǒng)的API獲取數(shù)據(jù)潘鲫，就是PULL模式
再說(shuō)說(shuō)數(shù)據(jù)的清洗
數(shù)據(jù)清洗的過(guò)程是指對(duì)數(shù)據(jù)進(jìn)行一些處理，過(guò)濾無(wú)用的信息肋杖，規(guī)范得到我們能用到的數(shù)據(jù)溉仑。包括但不限于以下情況：
- 過(guò)濾SPAM垃圾數(shù)據(jù)，例如被攻擊/造假/BUG產(chǎn)生的大量數(shù)據(jù)
- 抽取有用字段状植，例如上傳的數(shù)據(jù)包含的信息很多浊竟，我們只用到一小部分
- 原始數(shù)據(jù)有很多格式不規(guī)范，要統(tǒng)一格式
然后就是數(shù)據(jù)的加工
數(shù)據(jù)加工是指清洗后的數(shù)據(jù)津畸，還需要補(bǔ)充一些信息振定，可能是通過(guò)數(shù)據(jù)庫(kù)查詢出來(lái)的，也可能是通過(guò)計(jì)算規(guī)則計(jì)算出來(lái)的肉拓，或者算法技術(shù)加工出來(lái)的新字段后频。
例如，數(shù)據(jù)里面有個(gè)ip地址帝簇，需要計(jì)算出用戶的地理位置徘郭，那么地理位置就是加工出來(lái)的字段靠益。
一般來(lái)講，對(duì)于大多數(shù)大數(shù)據(jù)分析平臺(tái)而言残揉，加工是很重要的過(guò)程胧后，基本上最后可用來(lái)進(jìn)行分析的數(shù)據(jù)，要通過(guò)這一步充分完成加工計(jì)算抱环。
數(shù)據(jù)加工完成之后壳快，就是數(shù)據(jù)加載
數(shù)據(jù)加載是指把加工后的數(shù)據(jù)加載到合適的存儲(chǔ)，可能是Hadoop集群的HDFS上镇草，也可能是某個(gè)數(shù)據(jù)庫(kù)眶痰，有可能是文件等等其他存儲(chǔ)類型。
加載完成后就是建模分析
建模分析是指在查詢前需要把數(shù)據(jù)進(jìn)行處理梯啤，以優(yōu)化查詢竖伯，例如一下：
- 數(shù)據(jù)倉(cāng)庫(kù)建好了倉(cāng)庫(kù)模型，要把數(shù)據(jù)加載到數(shù)據(jù)倉(cāng)庫(kù)中
- 需要做數(shù)據(jù)索引因宇，把數(shù)據(jù)進(jìn)行索引優(yōu)化
數(shù)據(jù)模型很重要七婴，也是整個(gè)數(shù)據(jù)處理分析的核心之一，每個(gè)企業(yè)都有自己的核心業(yè)務(wù)察滑，以及核心目標(biāo)打厘，并且也有各自的數(shù)據(jù)源以及數(shù)據(jù)類型，所以也就意味著每一家企業(yè)的數(shù)據(jù)模型多少都會(huì)有些差異贺辰，也就是最個(gè)性化的一個(gè)地方户盯，數(shù)據(jù)倉(cāng)庫(kù)就是這個(gè)數(shù)據(jù)模型的載體，一般來(lái)講數(shù)據(jù)就是數(shù)據(jù)庫(kù)技術(shù)饲化，例如常見數(shù)據(jù)庫(kù)之外莽鸭，還有Infobright，Greenplum滓侍，Vertica蒋川，也有基于Hadoop技術(shù)的牲芋，用HDFS作為基礎(chǔ)的存儲(chǔ)撩笆，然后使用的查詢引擎，包括Imapla缸浦，Presto夕冲，SparkSQL等等。
通常而言裂逐，數(shù)據(jù)團(tuán)隊(duì)要進(jìn)行復(fù)雜的查詢和分析歹鱼，都是在此基礎(chǔ)之上，通過(guò)SQL語(yǔ)言或者代碼查詢來(lái)實(shí)現(xiàn)的卜高。
最后就是可視化了
可視化是最終分析結(jié)果要展示的過(guò)程弥姻，例如“雙十一”酷炫的圖表南片，一般企業(yè)都有自己的數(shù)據(jù)看板等等。
可視化背后主要是執(zhí)行SQL或者運(yùn)行代碼得到的數(shù)據(jù)結(jié)果庭敦，可能是一維疼进，也可能是二維，還有可能是多維秧廉，然后選擇合適的圖表類型進(jìn)行展示伞广，例如“線狀圖”、“柱狀圖”疼电、“餅狀圖”嚼锄、“雷達(dá)圖”、“中國(guó)地圖”等等蔽豺。
剛剛講的主要是通用的大數(shù)據(jù)平臺(tái)整個(gè)數(shù)據(jù)處理的方式区丑，不知道是否講的通俗易懂，接下來(lái)我就從諸葛io與通用的數(shù)據(jù)平臺(tái)的差異入手修陡，然后帶入我們的技術(shù)設(shè)計(jì)了
首先諸葛io的整套技術(shù)能夠做到的是刊苍，對(duì)企業(yè)分析流程的效率提升
大多數(shù)企業(yè)的分析現(xiàn)狀：自建或者第三方統(tǒng)計(jì)平臺(tái)（百度統(tǒng)計(jì)/友盟/Talkingdata）+ 數(shù)據(jù)BI團(tuán)隊(duì)（早期團(tuán)隊(duì)人數(shù)很少，甚至是一兩個(gè)工程師兼任）
- 自建或者第三方統(tǒng)計(jì)平臺(tái)：大多都是匯總統(tǒng)計(jì)指標(biāo)平臺(tái)濒析。對(duì)通用指標(biāo)（例如PV正什、UV、DAU号杏、留存）的計(jì)算婴氮，對(duì)企業(yè)設(shè)定好的業(yè)務(wù)行為（打車、訂單盾致、參與主经、金額）等匯總統(tǒng)計(jì)人數(shù)或者次數(shù)，數(shù)據(jù)平臺(tái)存儲(chǔ)的都是指標(biāo)的匯總結(jié)果庭惜。指標(biāo)的選擇和下鉆分析都需要數(shù)據(jù)團(tuán)隊(duì)的支撐罩驻。
- 數(shù)據(jù)BI團(tuán)隊(duì)：完成基礎(chǔ)數(shù)據(jù)平臺(tái)的搭建，并且梳理核心業(yè)務(wù)分析目標(biāo)护赊，對(duì)基礎(chǔ)數(shù)據(jù)進(jìn)行采集建模惠遏，并完成各個(gè)部門的分析需求。
所以大家可以看到最開始上面那張圖就是大多數(shù)企業(yè)現(xiàn)在的分析現(xiàn)狀
基本上先統(tǒng)一由大數(shù)據(jù)部門整理輸出各部門日常固定的數(shù)據(jù)指標(biāo)骏啰，然后做個(gè)可視化节吮，比如一個(gè)簡(jiǎn)單的頁(yè)面
如果有新的分析需求，已經(jīng)建模好的判耕，那么數(shù)據(jù)團(tuán)隊(duì)就需要根據(jù)業(yè)務(wù)去寫SQL然后得到結(jié)果透绩，如果沒有建模好的，就需要開始采集原始數(shù)據(jù)，然后重新開始清洗帚豪，這樣一個(gè)過(guò)程碳竟，往往都比較反復(fù)耗時(shí)，分析效率很低
主要原因是狸臣，這樣一種分析流程瞭亮，是由固定的業(yè)務(wù)指標(biāo)驅(qū)動(dòng)數(shù)據(jù)的采集和處理，然后數(shù)據(jù)處理的過(guò)程基本上都是多維匯總的統(tǒng)計(jì)和計(jì)算
所以也就造成了問(wèn)題：各個(gè)業(yè)務(wù)部門的分析需求需要依賴數(shù)據(jù)團(tuán)隊(duì)專業(yè)的數(shù)據(jù)分析能力進(jìn)行問(wèn)題建模固棚，并且依賴他們SQL語(yǔ)言或者代碼能力完成分析目標(biāo)统翩。但數(shù)據(jù)部門往往也有核心的分析需求和任務(wù)，所以公司變大過(guò)程中很多問(wèn)題變得很低效此洲。
相比而言厂汗，諸葛io數(shù)據(jù)分析工具的優(yōu)勢(shì)，諸葛io的整個(gè)數(shù)據(jù)處理也是符合上面的整個(gè)流程呜师，我們和其他數(shù)據(jù)分析平臺(tái)娶桦，尤其是傳統(tǒng)數(shù)據(jù)平臺(tái)，按照處理過(guò)程抽象的差異主要如下：
諸葛io的分析能力遠(yuǎn)遠(yuǎn)大于目前大多數(shù)的統(tǒng)計(jì)平臺(tái)汁汗，我們把很多深入的分析場(chǎng)景衷畦，依賴數(shù)據(jù)團(tuán)隊(duì)進(jìn)行建模以及SQL/代碼等專業(yè)能力，變成了可視化的分析組件知牌。這樣極大的提高了企業(yè)的數(shù)據(jù)分析效率祈争，并且我們還有專業(yè)的數(shù)據(jù)分析看板，輔助企業(yè)梳理了解分析需求和目標(biāo)角寸。諸葛io的亮點(diǎn)如下：
例如以前需要SQL完成的查詢菩混，現(xiàn)在只需要如下：
第二個(gè)：豐富的分析組件，支持市場(chǎng)/產(chǎn)品/運(yùn)營(yíng)部門的大多數(shù)場(chǎng)景分析
根據(jù)用戶的新增情況扁藕，觸發(fā)行為沮峡，用戶字段篩選待分析的用戶（用戶群）
對(duì)某個(gè)業(yè)務(wù)行為的參與情況（事件分析）
用戶的轉(zhuǎn)化情況（漏斗分析）
用戶的行為路徑（用戶行為路徑）
某個(gè)功能或者某個(gè)業(yè)務(wù)用戶的持續(xù)參與（自定義留存）
分析API和數(shù)據(jù)API，完全掌控您的數(shù)據(jù)亿柑，基于諸葛io靈活擴(kuò)展
除此之外邢疙，細(xì)致入微的產(chǎn)品設(shè)計(jì)，貫穿分析過(guò)程
例如：
- 點(diǎn)擊數(shù)字到用戶畫像的洞察
- 漏斗的無(wú)序和有序
- 用戶群“新增后X天”
- 還有更多的場(chǎng)景望薄，可以去感受和體驗(yàn)
這樣一來(lái)疟游，回到剛剛的圖片
所以我們的流程如上圖
我們?cè)诮r(shí)非常抽象，并且基于獨(dú)立用戶跟蹤了整個(gè)業(yè)務(wù)的流程式矫，所以不只是指標(biāo)任意的配置可視化乡摹，很多以前依賴于SQL和清洗代碼的邏輯，也變成了交互式的查詢組件采转，所以能提高效率，那我們是怎么做到的呢？
先來(lái)看看我們整體的架構(gòu)
首先看看數(shù)據(jù)采集端
首先看看數(shù)據(jù)采集端
我們提供豐富的接口和SDK故慈，能夠采集到企業(yè)各個(gè)有用戶行為數(shù)據(jù)的地方板熊，目前來(lái)講，主要分為以下：
Android客戶端 —— Android SDK
iOS客戶端 —— iOS SDK
網(wǎng)站或微站H5 —— Javascript SDK
小程序 —— 小程序SDK
日志 —— 服務(wù)端Restful接口
CRM數(shù)據(jù)庫(kù) —— 導(dǎo)入工具
也就是采用了“PUSH”模式察绷，各個(gè)端采集用戶的行為干签，然后再按照規(guī)則發(fā)送給我們的數(shù)據(jù)收集中心，各個(gè)端也就寫了一些SDK拆撼，讓開發(fā)者調(diào)用采集
然后就是我們的數(shù)據(jù)收集端
上圖是我們的數(shù)據(jù)收集架構(gòu)
核心就是LVS+Nginx+Lua容劳，我們沒有用比較重的后端語(yǔ)言來(lái)采集，而是選擇了比較輕的Lua腳本語(yǔ)言闸度，在nginx中集成就能完成高并發(fā)的復(fù)雜竭贩，LVS做解析服務(wù)器的負(fù)載均衡，后面是多個(gè)Nginx莺禁，然后Nginx本身就是高性能高并發(fā)服務(wù)器留量，所以并發(fā)的承載能力非常強(qiáng)
諸葛io采用的是HTTPS加密傳輸，以及支持HTTP2協(xié)議
- 采用HTTPS的原因是哟冬，防止數(shù)據(jù)在傳輸過(guò)程中被抓包截獲
- 采用HTTP2協(xié)議楼熄，服務(wù)端的處理性能能夠極大的提升，連接也有優(yōu)化
使用LVS的原因是浩峡，雖然Nginx的性能很高可岂，但是在高并發(fā)壓力情況下，我們能夠快速添加Nginx節(jié)點(diǎn)翰灾，再加上數(shù)據(jù)采集是異步青柄，所以大流量情況下，LVS+Nginx基本上都能保證不會(huì)出現(xiàn)連接等待的情況了预侯。
Lua是一種輕型的腳本語(yǔ)言致开，直接在nginx配置中嵌入，在很多游戲的服務(wù)端架構(gòu)以及電商秒殺的架構(gòu)中使用萎馅。我們服務(wù)端接收到上傳數(shù)據(jù)之后双戳，Lua會(huì)進(jìn)行解析，并且添加上傳時(shí)一些信息（ip糜芳，服務(wù)端時(shí)間飒货，User-Agent）等等，然后push到Kafka的集群峭竣。
我們這套架構(gòu)也是在諸葛io的日上傳數(shù)據(jù)量逐步上漲過(guò)程中塘辅，逐步演化出來(lái)的。
簡(jiǎn)單來(lái)講皆撩，數(shù)據(jù)采集具有以下特點(diǎn)：
- 高并發(fā)
- 高伸縮性性
- HTTPS安全傳輸
然后就是數(shù)據(jù)清洗
諸葛io采集到的數(shù)據(jù)會(huì)有以下幾個(gè)問(wèn)題需要處理：
- 垃圾數(shù)據(jù) —— 亂碼或者埋點(diǎn)錯(cuò)誤產(chǎn)生的數(shù)據(jù)
- 作弊數(shù)據(jù) —— 惡意進(jìn)行注入偽造的數(shù)據(jù)
- 淘汰數(shù)據(jù) —— 已經(jīng)棄用的SDK版本數(shù)據(jù)
所以我們會(huì)完成對(duì)于上述數(shù)據(jù)的清洗扣墩。
清洗完的數(shù)據(jù)哲银，諸葛io還會(huì)進(jìn)行一些信息加工，包括但不限于以下：
- 識(shí)別用戶和設(shè)備的身份關(guān)系
- 加工字段：地理位置呻惕、UTM推廣信息荆责、設(shè)備、系統(tǒng)版本（網(wǎng)站或者微站根據(jù)UA）
- 事件行為匹配系統(tǒng)id
加工信息之后亚脆，我們還會(huì)對(duì)數(shù)據(jù)按照我們的數(shù)據(jù)模型進(jìn)行格式轉(zhuǎn)化和預(yù)計(jì)算處理做院，得到我們所需要的最優(yōu)于查詢的數(shù)據(jù)。
關(guān)于數(shù)據(jù)清洗加工部分濒持，我們和其他大數(shù)據(jù)技術(shù)還有一些差異：
- 獨(dú)立的用戶行為跟蹤
- 基于用戶身份的數(shù)據(jù)整合
- 精準(zhǔn)的用戶和設(shè)備關(guān)系識(shí)別
- 事件的標(biāo)簽化
接下來(lái)是數(shù)據(jù)加載
數(shù)據(jù)加載的過(guò)程键耕，就是把我們數(shù)據(jù)處理后的結(jié)果寫入存儲(chǔ)，這里柑营，諸葛io主要加載的目標(biāo)位置有以下：
原始數(shù)據(jù)備份：
—— AWS S3
—— HDFS（私有部署）
加工后的數(shù)據(jù)
—— AWS S3
—— HDFS（私有部署）
模型數(shù)據(jù)倉(cāng)庫(kù)
—— Redshift
—— Greenplum（私有部署）
因?yàn)橹T葛io同時(shí)支持SaaS和私有部署屈雄，私有部署我們采用的方案會(huì)有差異，S3和HDFS都是文件訪問(wèn)由境，所以業(yè)務(wù)層基本是一致棚亩，S3是因?yàn)榇鎯?chǔ)成本低，HDFS是大多數(shù)企業(yè)的Hadoop平臺(tái)
加工后的數(shù)據(jù)同上
模型倉(cāng)庫(kù)虏杰，Redshift和Greenplum都是基于PostgreSQL的
我們加上自定義函數(shù)讥蟆，在數(shù)據(jù)訪問(wèn)層保持一致
然后在建模分析的過(guò)程，建模分析的核心是諸葛io的數(shù)據(jù)模型纺阔，也就是我們的數(shù)據(jù)倉(cāng)庫(kù)設(shè)計(jì)瘸彤，諸葛io現(xiàn)在的核心數(shù)據(jù)模型，分為以下主題：
用戶
—— 用戶的屬性信息
事件（行為）
—— 事件的屬性信息
—— 事件的觸發(fā)環(huán)境
行為發(fā)生平臺(tái)
—— 平臺(tái)（設(shè)備）的基礎(chǔ)信息
諸葛io的數(shù)據(jù)模型底層都已經(jīng)對(duì)用戶和行為進(jìn)行建模笛钝，我們從上層指標(biāo)的計(jì)算质况，可以直接下鉆用戶群體，并且對(duì)于用戶的行為歷史也有完整的還原和實(shí)時(shí)的洞察玻靡。
傳統(tǒng)的數(shù)據(jù)分析平臺(tái)都以設(shè)備進(jìn)行統(tǒng)計(jì)结榄，我們是基于用戶的，所以用戶和設(shè)備的關(guān)系我們能精準(zhǔn)還原
諸葛io的數(shù)據(jù)查詢和訪問(wèn)囤捻，主要分為兩部分：
數(shù)據(jù)訪問(wèn)層臼朗，是諸葛io把基于數(shù)據(jù)倉(cāng)庫(kù)的SQL查詢?cè)L問(wèn)抽象了一層服務(wù)，分為對(duì)內(nèi)和對(duì)外兩部分蝎土，用以控制對(duì)數(shù)據(jù)訪問(wèn)的統(tǒng)一管理视哑。
—— 對(duì)內(nèi)是通過(guò)統(tǒng)一的API服務(wù)來(lái)進(jìn)行訪問(wèn)
—— 對(duì)外是有Open API的開放平臺(tái)
可視化查詢?cè)谥T葛主要是通過(guò)諸葛io的網(wǎng)站進(jìn)行完成，并且在技術(shù)上也是基于數(shù)據(jù)訪問(wèn)層實(shí)現(xiàn)誊涯。
可視化在諸葛主要分為兩部分：
—— 數(shù)據(jù)指標(biāo)展現(xiàn)的可視化
—— 查詢操作的可視化
指標(biāo)展現(xiàn)可視化挡毅，包括不限于表格、柱狀圖暴构、線圖跪呈、漏斗段磨。
回到整個(gè)架構(gòu)上
可以看到有消息中心
諸葛io的消息中心是以Kafka為中心進(jìn)行設(shè)計(jì)的
消息中心主要處理包含以下業(yè)務(wù)消息的匯集和分發(fā)：
—— 各種SDK或者工具上傳的數(shù)據(jù)
—— 數(shù)據(jù)清洗產(chǎn)生的中間的數(shù)據(jù)
—— 模型結(jié)果數(shù)據(jù)
—— 備份數(shù)據(jù)
—— 其他流式處理數(shù)據(jù)
Kafka具有多消費(fèi)組的特點(diǎn)，也就意味著庆械，我們可以在不同應(yīng)用場(chǎng)景下對(duì)統(tǒng)一數(shù)據(jù)進(jìn)行多種處理薇溃，并產(chǎn)生多種應(yīng)用菌赖，例如下面場(chǎng)景：
我們收集到各種數(shù)據(jù)缭乘，并會(huì)添加到Kafka消息中心，然后會(huì)有以下不同消費(fèi)應(yīng)用：
—— 進(jìn)行元數(shù)據(jù)統(tǒng)計(jì)管理
—— 進(jìn)行備份
—— 進(jìn)入數(shù)據(jù)倉(cāng)庫(kù)模型前的清洗
—— 進(jìn)行實(shí)時(shí)的統(tǒng)計(jì)計(jì)算
實(shí)時(shí)計(jì)算中心琉用，我們用的是Spark Streaming進(jìn)行處理堕绩，也有其他套件輔助我們進(jìn)行一些數(shù)據(jù)挖掘
實(shí)時(shí)數(shù)據(jù)和關(guān)系緩存，我們用的是Codis以及SSDB邑时，Codis是分布式的Redis實(shí)現(xiàn)框架奴紧，由前豌豆莢團(tuán)隊(duì)開源，我們會(huì)用來(lái)做分布式的消息以及狀態(tài)存儲(chǔ)晶丘，而SSDB是基于Redis協(xié)議的硬盤實(shí)現(xiàn)黍氮，作者是懶投資的CTO吳總，我們會(huì)存儲(chǔ)一些鍵值比較大或者多的數(shù)據(jù)浅浮，例如實(shí)時(shí)數(shù)據(jù)以及數(shù)據(jù)緩存沫浆。
基礎(chǔ)存儲(chǔ)剛剛講過(guò)了主要是S3
索引用的是Elasticsearch
比如查詢時(shí)的提示等等
在線多維實(shí)時(shí)數(shù)據(jù)處理查詢就是Redshift和Greenplum了
然后我們統(tǒng)一了整個(gè)數(shù)據(jù)訪問(wèn)層以及API，并且分為內(nèi)部和外部API滚秩，對(duì)外就是網(wǎng)站和開放平臺(tái)了
時(shí)間差不多了专执，以上就是我今天的分享，希望對(duì)大家有啟發(fā)和價(jià)值
Q1：業(yè)界現(xiàn)在流行一種不需要埋點(diǎn)的數(shù)據(jù)統(tǒng)計(jì)服務(wù)郁油，和需要埋點(diǎn)的服務(wù)相比有什么樣的差別本股？
A1：各有優(yōu)劣，場(chǎng)景不太一樣桐腌，之前不少文章和行業(yè)小伙伴都寫過(guò)文章對(duì)比了拄显，可以搜索一下。簡(jiǎn)單概括一下案站，無(wú)埋點(diǎn)在數(shù)據(jù)采集上會(huì)比較方便快速躬审，但是采集數(shù)據(jù)準(zhǔn)確率很容易出現(xiàn)數(shù)據(jù)丟失以及時(shí)機(jī)失誤的情況，并且采集到的數(shù)據(jù)也基本上只能是頁(yè)面上的顯示元素嚼吞，分析的時(shí)候也都是零散的指標(biāo)盒件，以及瀏覽量和點(diǎn)擊量的統(tǒng)計(jì)
有埋點(diǎn)的服務(wù)則在采集上不會(huì)那么的便利，但是采集數(shù)據(jù)會(huì)更精確以及豐富舱禽，比如后臺(tái)的業(yè)務(wù)數(shù)據(jù)炒刁，而且也能轉(zhuǎn)換成業(yè)務(wù)指標(biāo)進(jìn)行分析
Q2：如果只有一個(gè)產(chǎn)品經(jīng)理，能通過(guò)可視化埋點(diǎn)工具自己埋點(diǎn)嗎誊稚？就是有沒有可能在沒有IT投入的情況下翔始，變更數(shù)據(jù)采集規(guī)則
A2：可視化埋點(diǎn)的前提也是要IT來(lái)協(xié)助接入SDK的罗心，在代碼結(jié)構(gòu)不變的情況下，可以快速去看不同頁(yè)面元素的瀏覽和訪問(wèn)情況
Q3：有沒有這種可能城瞎，針對(duì)數(shù)據(jù)A進(jìn)行用戶行為分析渤闷，再把這個(gè)用戶群體關(guān)聯(lián)到另外一個(gè)數(shù)據(jù)B中，進(jìn)行用戶分析脖镀。比如：購(gòu)買商品A的用戶飒箭，是否會(huì)瀏覽商品B
A3：于企業(yè)而言，肯定是要統(tǒng)一數(shù)據(jù)A和數(shù)據(jù)B的用戶關(guān)聯(lián)性蜒灰，統(tǒng)一標(biāo)示體系下的用戶弦蹂，“購(gòu)買商品A的用戶，是否會(huì)瀏覽商品B”强窖，就是進(jìn)行交叉查詢就OK凸椿，如果是“購(gòu)買商品A的用戶，還可能會(huì)購(gòu)買商品B嗎翅溺？”脑漫，就是常見的個(gè)性化推薦了
找用戶和用戶，或者用戶和物品或者物品和物品之前的關(guān)系
Q4：多少數(shù)據(jù)量（比如年1000萬(wàn)條數(shù)據(jù)）的情況下咙崎，比較適合使用第三方數(shù)據(jù)分析工具优幸？
當(dāng)然有一定基礎(chǔ)數(shù)據(jù)，超過(guò)可以調(diào)研的基礎(chǔ)之上叙凡，另外我個(gè)人的主觀建議是劈伴，都需要數(shù)據(jù)分析，但如果細(xì)分領(lǐng)域的流量紅利還在握爷，就趕緊圈地跛璧，如果沒有流量紅利了，就需要更多分析來(lái)決策驅(qū)動(dòng)
Q5：是否在服務(wù)端進(jìn)行PULL或者PUSH的數(shù)據(jù)采集方式新啼，支持的話需要做數(shù)據(jù)格式清洗嗎追城？有SDK支持嗎？需要多少開發(fā)量燥撞？
Q6：當(dāng)業(yè)務(wù)在快速變化時(shí)座柱，是否意味著要不斷更新App埋點(diǎn)邏輯，以期得到新的統(tǒng)計(jì)結(jié)果物舒？有什么方式不更新APP就得到統(tǒng)計(jì)結(jié)果色洞？
A6：后端日志分析+app主業(yè)務(wù)路徑跟蹤分析+變化業(yè)務(wù)的埋點(diǎn)跟蹤分析，多數(shù)據(jù)源整合分析
