記得一個(gè)笑話, 說(shuō)北大的保安見(jiàn)到陌生人會(huì)問(wèn)三個(gè)極富人生哲學(xué)的問(wèn)題:
- 你從哪里來(lái)
- 你來(lái)干什么
- 你到哪里去
對(duì)應(yīng)數(shù)據(jù)平臺(tái)來(lái)說(shuō), 也可以問(wèn)三個(gè)類似的問(wèn)題:
- 數(shù)據(jù)從哪里來(lái)
- 數(shù)據(jù)如何處理
- 數(shù)據(jù)到哪里去
1.數(shù)據(jù)來(lái)源
數(shù)據(jù)平臺(tái)是數(shù)據(jù)的消費(fèi)端. 作為數(shù)據(jù)鏈條的最底層, 數(shù)據(jù)的來(lái)源通常有一下幾種:
1.1 業(yè)務(wù)數(shù)據(jù)庫(kù)數(shù)據(jù)
業(yè)務(wù)數(shù)據(jù)庫(kù)中的數(shù)據(jù)是數(shù)據(jù)平臺(tái)的重要數(shù)據(jù)來(lái)源, 基本上在不引入開(kāi)發(fā)額外工作的情況下, 將業(yè)務(wù)數(shù)據(jù)庫(kù)導(dǎo)入到數(shù)據(jù)倉(cāng)庫(kù)便可以獲得業(yè)務(wù)的最新?tīng)顟B(tài), 性價(jià)比絕佳.
- 從數(shù)據(jù)庫(kù)的類型來(lái)說(shuō), 常用的有MySQL/Redis/MongoDB
- 從數(shù)據(jù)獲取的方式來(lái)說(shuō), 分為全量和增量?jī)煞N:
1.2 用戶行為打點(diǎn)/埋點(diǎn)
大多數(shù)產(chǎn)品都會(huì)使用打點(diǎn)的方式, 在用戶發(fā)生某些行為的時(shí)候記錄日志, 上傳到服務(wù)端供后續(xù)用戶行為分析.
有人會(huì)問(wèn)既然有了業(yè)務(wù)的數(shù)據(jù)庫(kù)數(shù)據(jù), 為何還要引入耗時(shí)費(fèi)力的打點(diǎn)方式收集用戶行為? 因?yàn)闃I(yè)務(wù)數(shù)據(jù)庫(kù)僅僅存儲(chǔ)用戶的寫操作的狀態(tài), 無(wú)法獲知用戶讀操作行為. 例如, 查看商品詳情這一動(dòng)作不涉及到任何數(shù)據(jù)的變化(Counter類型除外), 從業(yè)務(wù)數(shù)據(jù)庫(kù)無(wú)法獲知用戶瀏覽了哪些商品, 哪類商品.
做用戶行為采集, 最大的挑戰(zhàn)是如何保證數(shù)據(jù)質(zhì)量.
- 數(shù)據(jù)采集 SDK 要考慮到各個(gè)平臺(tái)的各種 Corner Case, 保證數(shù)據(jù)能夠上傳到服務(wù)器.
- 每次打點(diǎn)需求如何管理, 如何做數(shù)據(jù)驗(yàn)證. 移動(dòng)產(chǎn)品最大的問(wèn)題是無(wú)法像 Web 一樣隨時(shí)發(fā)布, 因此一旦等分析數(shù)據(jù)時(shí)發(fā)現(xiàn)打點(diǎn)是錯(cuò)誤的, 心中定會(huì)
萬(wàn)馬奔騰. 要修復(fù)也只能等下次產(chǎn)品發(fā)布.
我的感受是:數(shù)據(jù)質(zhì)量就好比鍛煉身體, 一定要持之以恒的堅(jiān)持才行.
這次版本發(fā)布數(shù)據(jù)打點(diǎn)沒(méi)有 bug, 不保證下次不會(huì)有 bug
1.3 用戶訪問(wèn)日志
通俗來(lái)講就是應(yīng)用系統(tǒng)前端 Web 服務(wù)器的 Access Log. 通過(guò)收集 Access Log 就可以減少很多打點(diǎn)的操作.
那打點(diǎn)和Access Log的區(qū)別是什么? 一個(gè)簡(jiǎn)單的比喻, 比如一個(gè)人在走路
- 打點(diǎn)就是時(shí)不時(shí)的問(wèn)他: 你過(guò)去的1分鐘里走了多少步? 因此他要自己邊走邊數(shù)數(shù), 一旦數(shù)錯(cuò)了, 你獲得的結(jié)果也必然是錯(cuò)誤的.
- Access Log 就是他盡管走他的路, 你在后面數(shù)他的腳印. 隨便按照你的規(guī)則數(shù), 基本不會(huì)錯(cuò). 而走路的人全然不管這個(gè)事兒.
還有一個(gè)問(wèn)題是: 既然已經(jīng)有了Access Log, 為何還要耗時(shí)費(fèi)力的打點(diǎn)? 因?yàn)楝F(xiàn)在基本上都是移動(dòng)端 App, 為了優(yōu)化性能, 經(jīng)常會(huì)客戶端拉取一批數(shù)據(jù)后緩存在本地, 用戶是否查看數(shù)據(jù), 從 Access Log 根本無(wú)從分析.
1.4 第三方數(shù)據(jù)采集
- SaaS大行其道的今天, 基本上沒(méi)有哪家公司會(huì)從0開(kāi)始構(gòu)建自己所有的系統(tǒng), 因此會(huì)引入第三方服務(wù). 而在評(píng)估這些第三方服務(wù)的時(shí)候, 可以考慮是否支持導(dǎo)出所有用戶的行為日志, 以供后續(xù)分析.
- 有些業(yè)務(wù)需要在用戶授權(quán)的情況下抓取用戶其他平臺(tái)的數(shù)據(jù)
1.5 非結(jié)構(gòu)化數(shù)據(jù)
用戶的語(yǔ)音/圖片等非結(jié)構(gòu)化數(shù)據(jù), 也是一個(gè)數(shù)據(jù)平臺(tái)的重要來(lái)源. 比如做圖片鑒黃服務(wù), 語(yǔ)音分析等. 感興趣的可以參見(jiàn)之前文章 SQL Over S3 構(gòu)建 SQL 查詢非結(jié)構(gòu)化數(shù)據(jù)的系統(tǒng)
2. 數(shù)據(jù)如何處理
辛辛苦苦搞來(lái)那么多數(shù)據(jù), 第一個(gè)問(wèn)題就是數(shù)據(jù)放在哪里, 然后就想這些數(shù)據(jù)如何處理, 轉(zhuǎn)變成對(duì)業(yè)務(wù)有價(jià)值的東西.
2.1 數(shù)據(jù)存儲(chǔ)
數(shù)據(jù)庫(kù)可以分兩種: OLAP 和 OLTP. 對(duì)于采集來(lái)的數(shù)據(jù)來(lái)說(shuō), 大多數(shù)情況下是要作為 OLAP 系統(tǒng)使用的. 因此存儲(chǔ)也基于 OLAP 的思路來(lái)選擇. 首先想到的就是 HDFS, 一個(gè)非常成熟的分布式文件系統(tǒng). 基于 HDFS 的生態(tài)也非常完備, 大多數(shù)情況下使用 Hive. 不過(guò) HDFS 也是要維護(hù)的, NameNode 雖然支持了 HA 一旦運(yùn)維不好丟數(shù)據(jù)了也不能怨政府不是. 如果使用了云平臺(tái), 可以考慮類似 Amazon S3/Aliyun OSS 等存儲(chǔ)服務(wù), 降低運(yùn)維成本.
不過(guò)后面會(huì)聊到數(shù)據(jù)平臺(tái)的產(chǎn)出, 也會(huì)根據(jù)需求用到一些 OLTP 的產(chǎn)品, 比如 MySQL 用來(lái)存儲(chǔ)報(bào)表數(shù)據(jù)等.
2.2 數(shù)據(jù)計(jì)算
終于到了數(shù)據(jù)計(jì)算這一節(jié). 前面搞來(lái)的數(shù)據(jù)好比買回家的生菜, 需要通過(guò)加工才能變成桌上的滿漢全席. 數(shù)據(jù)計(jì)算就是'廚房里的廚具'
籠統(tǒng)來(lái)說(shuō), 數(shù)據(jù)計(jì)算可以用 Spark/Hive/Hadoop/Storm/Presto/Druid..... 眼花繚亂. 分類總結(jié)一下, 可以分成如下幾種:
- 批量計(jì)算(Batch): 通常是大數(shù)據(jù)量計(jì)算, 用于ETL等離線計(jì)算. 可以慢, 但要吃得下大數(shù)據(jù)量. 常用的有Hadoop MapReduce/Hive/Pig/Spark
- 實(shí)時(shí)計(jì)算(Realtime): 通常適用于對(duì)延遲要求低的場(chǎng)景, 例如實(shí)時(shí)統(tǒng)計(jì). 現(xiàn)在基本上都是數(shù)據(jù)接入 Kafka 然后使用 Spark Streaming 或者 Storm
- 交互式查詢: 對(duì)現(xiàn)有數(shù)據(jù)進(jìn)行統(tǒng)計(jì)分析, 查詢速度直接決定使用者的工作效率. Hive 太慢. 可選的有開(kāi)源的 Druid, Presto, Impala, 商業(yè)產(chǎn)品可以選擇Amazon的Redshift等
- 計(jì)算就要一堆服務(wù)器, 因此計(jì)算資源的調(diào)度就需要考慮. 常用的 Yarn 可以調(diào)度 Mapreduce 任務(wù), 也可以調(diào)度 Spark 任務(wù).
2.3 調(diào)度系統(tǒng)
有了那么多"廚具", 想要完成業(yè)務(wù)功能, 開(kāi)發(fā)了一大堆計(jì)算, 最后發(fā)現(xiàn)一堆計(jì)算任務(wù)的依賴關(guān)系非常復(fù)雜, 例如A 任務(wù)要等 B 和 C 任務(wù)都完成才可以啟動(dòng), 而 B 任務(wù)又依賴 C, D, E 任務(wù). 一開(kāi)始可以使用 crontab 啟動(dòng)任務(wù), 預(yù)估每個(gè)任務(wù)的完成時(shí)間, 錯(cuò)峰啟動(dòng). 但一旦中間一個(gè)任務(wù)失敗或者延遲完成, 會(huì)導(dǎo)致后續(xù)任務(wù)計(jì)算由于沒(méi)有前置數(shù)據(jù)輸入而計(jì)算結(jié)果錯(cuò)誤. 因此一個(gè)調(diào)度系統(tǒng)是必不可少的, 可以選擇 Airbnb 開(kāi)源的 Airflow , Linkedin 開(kāi)源的 Azkaban
3.數(shù)據(jù)到哪里去
這里才是前面折騰的最終目的: 數(shù)據(jù)用來(lái)干嘛.
3.1 決策支撐
- Dashboard
- A/B Testing
- 分析報(bào)告
第一個(gè)想到的肯定就是各種業(yè)務(wù)的報(bào)表. 每個(gè)產(chǎn)品功能上線肯定會(huì)有一些指標(biāo)衡量功能. Lean Startup 的經(jīng)典圖里面 Measure 的過(guò)程不就是我們數(shù)據(jù)采集后計(jì)算報(bào)表的過(guò)程.
除了報(bào)表, 還有 A/B Test 系統(tǒng), 各種分析報(bào)告. 但總結(jié)來(lái)說(shuō), 這些都是為了做決策支撐.
3.2 基于數(shù)據(jù)的產(chǎn)品功能
有時(shí)也需要基于現(xiàn)有數(shù)據(jù)構(gòu)建一些用戶可以看到的產(chǎn)品功能.
- 產(chǎn)品功能: 比如推薦系統(tǒng)
- 運(yùn)營(yíng)活動(dòng): 有些運(yùn)營(yíng)活動(dòng)會(huì)展現(xiàn)一些用戶歷史行為的統(tǒng)計(jì)數(shù)據(jù), 比如過(guò)去你來(lái)了幾天, 買了哪些東西等.
總結(jié)
之所以啰嗦這么多, 是讀了一本大數(shù)據(jù)日知錄 的書, 感覺(jué)思考一定要系統(tǒng)化, 才可以針對(duì)現(xiàn)狀琢磨今后要在哪個(gè)比較弱的地方發(fā)力, 做到更好.
-- EOF --
