作者：盧榮斌

美圖擁有十億級(jí)用戶，每天有數(shù)千萬用戶在使用美圖的各個(gè)產(chǎn)品，從而積累了大量的用戶數(shù)據(jù)。

隨著 APP 的不斷迭代與用戶的快速膨脹，產(chǎn)品、運(yùn)營(yíng)、市場(chǎng)等越來越依賴于數(shù)據(jù)來優(yōu)化產(chǎn)品功能、跟蹤運(yùn)營(yíng)效果，分析用戶行為等，隨之而來的有越來越多的數(shù)據(jù)統(tǒng)計(jì)、分析等需求。

那么如何應(yīng)對(duì)和滿足不斷膨脹的數(shù)據(jù)統(tǒng)計(jì)與分析需求?業(yè)務(wù)的不斷發(fā)展又怎么推進(jìn)架構(gòu)實(shí)現(xiàn)的改造?

本文將介紹大數(shù)據(jù)業(yè)務(wù)與技術(shù)的碰撞產(chǎn)物之一：美圖大數(shù)據(jù)統(tǒng)計(jì)分析平臺(tái)的架構(gòu)演進(jìn)，希望通過這次分享能給大家?guī)硪恍┙鉀Q數(shù)據(jù)業(yè)務(wù)與架構(gòu)方面的思考。

如果有做過大數(shù)據(jù)相關(guān)開發(fā)的同學(xué)應(yīng)該知道數(shù)據(jù)統(tǒng)計(jì)是一個(gè)比較尷尬的事情，第一個(gè)它可能不是一個(gè)非常有技術(shù)含量的事情，對(duì)于技術(shù)人員的成長(zhǎng)來說不是非常好。第二它可能是一個(gè)比較重復(fù)工作的事，需要解決一些簡(jiǎn)單的需求的重復(fù)工作。

美圖其實(shí)有非常多的 APP，每個(gè) APP 基本上都會(huì)有相應(yīng)的產(chǎn)品運(yùn)營(yíng)、銷售以及數(shù)據(jù)分析的同學(xué)，這些同學(xué)會(huì)提各式各樣數(shù)據(jù)統(tǒng)計(jì)的需求，比如數(shù)據(jù)報(bào)表或者數(shù)據(jù)分析的需求。這么多的分析或者說數(shù)據(jù)統(tǒng)計(jì)的需求，在美圖是怎么解決的呢?

今天主要想介紹下在美圖的解決方案，內(nèi)容主要分三塊：

• 統(tǒng)計(jì)業(yè)務(wù)與技術(shù)碰撞。
• 美圖統(tǒng)計(jì)平臺(tái)架構(gòu)的實(shí)現(xiàn)。
• 正在做的事情以及未來的一些規(guī)劃。

統(tǒng)計(jì)業(yè)務(wù)與技術(shù)碰撞

這基本上是我自己親身的經(jīng)歷，剛開始一個(gè)人做這一塊的業(yè)務(wù)，會(huì)碰到一些有意思的點(diǎn)，可能分三個(gè)階段：

• 在項(xiàng)目的初期，我們?cè)趺礃尤?yīng)對(duì)一些產(chǎn)品的初期需求。
• 當(dāng)用戶量爆發(fā)以后，業(yè)務(wù)數(shù)據(jù)源上來以后，我們又是怎么迭代的。
• 作為一個(gè)有一點(diǎn)追求的技術(shù)人員來說，怎么讓自己去脫離一些業(yè)務(wù)，得到一些成長(zhǎng)。

01.項(xiàng)目初期

這個(gè)階段特點(diǎn)非常明顯：以美拍為例，初期整體的數(shù)據(jù)體量小;統(tǒng)計(jì)需求比較少，主要是一些基礎(chǔ)的統(tǒng)計(jì)指標(biāo);產(chǎn)品的迭代非常快，要求數(shù)據(jù)的統(tǒng)計(jì)指標(biāo)能夠快速地跟上產(chǎn)品的迭代速度。

圖1

這一階段的解決方案在現(xiàn)在看來非常的簡(jiǎn)陋：一個(gè)是業(yè)務(wù)的服務(wù)端可能會(huì)有多個(gè)節(jié)點(diǎn)，保證可用性，每個(gè)業(yè)務(wù)節(jié)點(diǎn)的服務(wù)會(huì)打相應(yīng)的日志到本地磁盤，然后會(huì)通過 rsync 的方式統(tǒng)一同步日志到一個(gè)數(shù)據(jù)存儲(chǔ)節(jié)點(diǎn)。

在這個(gè)節(jié)點(diǎn)上寫一些簡(jiǎn)單的 shell 或者 PHP 腳本來實(shí)現(xiàn)統(tǒng)計(jì)邏輯，配置相應(yīng)的 crontab 來定時(shí)觸發(fā)統(tǒng)計(jì)任務(wù)，最終把數(shù)據(jù)結(jié)果存儲(chǔ)到 MySQL 供展示層調(diào)用呈現(xiàn)報(bào)表。

02.快速發(fā)展階段

當(dāng)用戶量突然爆發(fā)以后，數(shù)據(jù)量會(huì)不斷的增大，產(chǎn)品運(yùn)營(yíng)、數(shù)據(jù)分析的需求越來越多。

相應(yīng)第一個(gè)階段的解決方案會(huì)存在比較大的問題，主要有如下三個(gè)：

單點(diǎn)存儲(chǔ)的容量非常有限。

計(jì)算瓶頸很快就會(huì)遇上瓶頸，很多時(shí)候統(tǒng)計(jì)報(bào)表因?yàn)橛?jì)算瓶頸導(dǎo)致報(bào)表第二天延遲產(chǎn)出。

我們用 shell 或者 PHP 腳本來實(shí)現(xiàn)統(tǒng)計(jì)邏輯，整體后續(xù)的維護(hù)成本比較大，需要調(diào)整一個(gè)統(tǒng)計(jì)邏輯或者增加一些過濾條件等都比較不方便。

圖2

所以我們做了一些調(diào)整：

實(shí)現(xiàn)了一套數(shù)據(jù)采集的系統(tǒng)，負(fù)責(zé)做服務(wù)端日志的數(shù)據(jù)采集工作，將數(shù)據(jù)最終落地存儲(chǔ)到 HDFS。

前面有提到說存儲(chǔ)和計(jì)算的單點(diǎn)問題，所以我們自己搭建一個(gè) Hadoop 集群來解決單點(diǎn)的存儲(chǔ)和計(jì)算。

基于 Hive 來解決編寫過多統(tǒng)計(jì)邏輯相關(guān)的代碼。

03.有追求的程序員

當(dāng)需求不斷膨脹的時(shí)候，作為一個(gè)有追求的程序員會(huì)考慮到，重復(fù)的代碼量非常多，即使我們有架一層 Hive 來寫相應(yīng)的代碼，最后做一層數(shù)據(jù)的過濾或者一些聚合。

其實(shí)每一個(gè)統(tǒng)計(jì)需求我們都需要寫一個(gè)相應(yīng)的 Java 的實(shí)現(xiàn)，這個(gè)工作量非常的枯燥，也是不斷重復(fù)。

圖3

一個(gè)有追求的程序員的話，可能不會(huì)甘于每天做重復(fù)的工作。因?yàn)樵谄綍r(shí)接觸業(yè)務(wù)與實(shí)現(xiàn)過程中，深有體會(huì)統(tǒng)計(jì)業(yè)務(wù)邏輯的流程基本上是一致的。

所以考慮抽象出這樣一個(gè)相對(duì)通用的業(yè)務(wù)處理的流程，基本的流程是從數(shù)據(jù)源 Query 出數(shù)據(jù)，然后做一些業(yè)務(wù)方面的聚合或者過濾，最終把數(shù)據(jù)存儲(chǔ)到 DB。

那在代碼實(shí)現(xiàn)層面做了一層抽象，抽象一個(gè)統(tǒng)計(jì)的組件，包含 Query、Aggregator 以及 DBStore，然后分別有一些不同 Query 和 Store 場(chǎng)景的實(shí)現(xiàn)。

當(dāng)做了一層這樣的抽象以后，相比于前面的方案，生產(chǎn)力還是得到了比較大的提升。當(dāng)時(shí)我一個(gè)人，一天能夠做四五個(gè)統(tǒng)計(jì)需求，而抽象后一天從了解需求開始到實(shí)現(xiàn)大概能做七八個(gè)統(tǒng)計(jì)需求，整體效率有不錯(cuò)的提升。

美圖統(tǒng)計(jì)平臺(tái)的架構(gòu)實(shí)現(xiàn)

做了上面的抽象以后，還是有不少的痛點(diǎn)：

• 業(yè)務(wù)的依賴，指的是我們做一個(gè)統(tǒng)計(jì)需求最花時(shí)間成本的是去了解數(shù)據(jù)業(yè)務(wù)方的需求背景，了解他們的產(chǎn)品長(zhǎng)什么樣子或者他們的運(yùn)營(yíng)做了什么活動(dòng)，業(yè)務(wù)溝通背景的成本非常高。
• 即使做了抽象還是會(huì)有一些相應(yīng)的重復(fù)代碼的編碼量，還需要做一個(gè)統(tǒng)計(jì)的組件選擇相應(yīng)的 Query，相應(yīng)的業(yè)務(wù)邏輯的處理以及存儲(chǔ)層的 DBstore。
• 運(yùn)維成本高，當(dāng)時(shí)上線一個(gè)任務(wù)需要做一個(gè)包到線上，還需要改一些 shell 等腳本。
• 涉及到個(gè)人成長(zhǎng)方面，當(dāng)一個(gè)人長(zhǎng)時(shí)間在做這樣事情的話，對(duì)個(gè)人的技術(shù)成長(zhǎng)是有比較大的瓶頸。

圖4

基于上面的痛點(diǎn)，我們來介紹一下我們是如何解決這些事情的。我們考慮去做一個(gè)平臺(tái)，讓業(yè)務(wù)在我們這個(gè)平臺(tái)去使用，我們提供服務(wù)就好。

圖 4 是我們當(dāng)時(shí)做平臺(tái)化的大概思路，比如左邊這個(gè)業(yè)務(wù)方有非常多的報(bào)表數(shù)據(jù)需求，也可能有 APP 的數(shù)據(jù)場(chǎng)景、商業(yè)廣告等的數(shù)據(jù)需求。

我們希望能夠提供這樣的一個(gè)平臺(tái)，業(yè)務(wù)的數(shù)據(jù)需求方在這個(gè)平臺(tái)上面配置他們想要的數(shù)據(jù)指標(biāo)，而這個(gè)平臺(tái)負(fù)責(zé)數(shù)據(jù)的計(jì)算、存儲(chǔ)，以及最終吐出相應(yīng)的數(shù)據(jù)給數(shù)據(jù)應(yīng)用方。

更進(jìn)一步，在做這個(gè)平臺(tái)時(shí)，我們可能需要考慮以下幾個(gè)比較重要的點(diǎn)：

我們可能需要對(duì)統(tǒng)計(jì)任務(wù)有一個(gè)比較清晰的元數(shù)據(jù)描述，可以描述出這些統(tǒng)計(jì)任務(wù)的計(jì)算方式是什么樣子，算子是什么。

這個(gè)統(tǒng)計(jì)任務(wù)的數(shù)據(jù)源來自于哪里，以及數(shù)據(jù)需要存儲(chǔ)在什么地方更合適業(yè)務(wù)查詢。

需要有一個(gè)調(diào)度中心來統(tǒng)一調(diào)度所有統(tǒng)計(jì)任務(wù)的執(zhí)行。

要確保任務(wù)的最終正確執(zhí)行。

基于上面這幾個(gè)點(diǎn)，考慮需要有一些不同的模塊來負(fù)責(zé)上面說的幾大功能。

我們大概有設(shè)計(jì)三個(gè)模塊：

• JobManager 模塊，主要是提供平臺(tái)，供應(yīng)用方比較方便的配置，能管理任務(wù)元數(shù)據(jù)信息以及其他的數(shù)據(jù)倉庫、APP 信息的管理等。
• Scheduler 模塊，就是任務(wù)的調(diào)度中心，負(fù)責(zé)調(diào)度所有的統(tǒng)計(jì)任務(wù)。
• JobExecutor 任務(wù)執(zhí)行模塊，負(fù)責(zé)任務(wù)從查詢、聚合到最終的結(jié)果落地存儲(chǔ)。

接下來詳細(xì)介紹下這三個(gè)模塊大概的功能點(diǎn)以及實(shí)現(xiàn)的方式。

01.JobManager 模塊

這個(gè)模塊主要是抽象統(tǒng)計(jì)任務(wù)，對(duì)任務(wù)的元數(shù)據(jù)做統(tǒng)一的配置管理。

如圖 5，主要需要提供一個(gè)應(yīng)用方在這個(gè)平臺(tái)上去配置他們想要的數(shù)據(jù)，另外一個(gè)點(diǎn)是我們需要有整合數(shù)據(jù)倉庫。整合數(shù)據(jù)倉庫主要是為了業(yè)務(wù)方能夠查看到他相應(yīng)業(yè)務(wù)表的信息。

圖5

右邊這一塊主要是對(duì)于元數(shù)據(jù)統(tǒng)計(jì)任務(wù)的描述，主要包含這幾個(gè)大塊，比如說數(shù)據(jù)的來源，統(tǒng)計(jì)的算子是什么以及存儲(chǔ)的介質(zhì)或者特殊場(chǎng)景的數(shù)據(jù)過濾器、維度聚合以及任務(wù)與任務(wù)之間的依賴關(guān)系描述。

02.任務(wù)調(diào)度模塊 Scheduler

當(dāng)前的實(shí)現(xiàn)方式比較簡(jiǎn)單，是單點(diǎn)的方式。當(dāng)前有實(shí)現(xiàn)的幾個(gè)點(diǎn)：

• 能夠根據(jù)任務(wù)的優(yōu)先級(jí)來調(diào)度。
• 能夠根據(jù)任務(wù)定時(shí)的策略進(jìn)行調(diào)度。
• 能夠調(diào)度工作流，就是依賴關(guān)系的調(diào)度。

圖6

03.任務(wù)執(zhí)行模塊 JobExecutor

如圖 6，根據(jù)任務(wù)的源信息從插件池里組裝出具體的 Query 組件，然后到具體的 Query 層(比如 Hive)跑相應(yīng)的數(shù)據(jù)，出來后的數(shù)據(jù)做一些過濾、維度方面的聚合。

圖7

最終根據(jù)任務(wù)的信息來組裝數(shù)據(jù)的存儲(chǔ)層的組件，把統(tǒng)計(jì)數(shù)據(jù)結(jié)果寫入到存儲(chǔ)層。

講完三個(gè)模塊以后，我們來回顧一下這個(gè)統(tǒng)計(jì)平臺(tái)的基礎(chǔ)架構(gòu)。左邊有一個(gè) JobManager 管理元數(shù)據(jù)，根據(jù)元數(shù)據(jù)去做統(tǒng)計(jì)任務(wù)的整體標(biāo)準(zhǔn)流程：查詢、過濾、維度聚合、存儲(chǔ)。

有了這樣基礎(chǔ)的框架以后，可以滿足一部分的基礎(chǔ)數(shù)據(jù)統(tǒng)計(jì)的場(chǎng)景，但如果是要支持更多的數(shù)據(jù)統(tǒng)計(jì)的業(yè)務(wù)場(chǎng)景的話，需要做更多的功能的拓展(圖8)。

圖8

這里面有四個(gè)大方向的功能拓展。

針對(duì)臨時(shí)取數(shù)的場(chǎng)景

不一定所有的業(yè)務(wù)都需要常規(guī)例行跑，有非常多的臨時(shí)跑數(shù)場(chǎng)景，比如分析人員需要臨時(shí)看一個(gè)相應(yīng) APP 的功能數(shù)據(jù)或者是說運(yùn)營(yíng)需要看一個(gè)臨時(shí)組織活動(dòng)的數(shù)據(jù)指標(biāo)等等，平時(shí)會(huì)遇到比較多的臨時(shí)取數(shù)相應(yīng)的需求。

對(duì)于解決臨時(shí)取數(shù)這一塊的需求，我們做的功能有兩個(gè)，一個(gè)是有提供直接填寫 SQL 的功能，支持有 SQL 基礎(chǔ)的用戶臨時(shí)提取數(shù)據(jù)。

這塊是擴(kuò)展 Hive 自集成的 antlr 來做 HOL 語法解析，解析出來以后，需要校驗(yàn) HOL 的合法性，主要是排除一些類似 Insert、Delete 操作，以及限定跑數(shù)的時(shí)間范圍以免長(zhǎng)時(shí)間占用集群計(jì)算資源。

盡量豐富數(shù)據(jù)源

在平時(shí)的需求中，會(huì)越來越多遇到需要導(dǎo)入業(yè)務(wù)方的 MySQL 的數(shù)據(jù)來做簡(jiǎn)單的數(shù)據(jù)統(tǒng)計(jì)或者 Join 計(jì)算。

所以這一塊我們是有基于 Sqoop 開發(fā)的一個(gè)插件，來支持導(dǎo)入業(yè)務(wù) MySQL 庫表到 Hadoop。

第三就是 Bitmap，這是我們美圖自研的一套系統(tǒng)，主要是為了便于多維度去重以及做新增、留存等相應(yīng)的計(jì)算，其原理主要是基于位 bit 之間的操作。

多存儲(chǔ)

當(dāng)前大部分的數(shù)據(jù)是存儲(chǔ)在 MongoDB，介于傳統(tǒng)關(guān)系型數(shù)據(jù)庫以及 NoSQL 之間，既能大部分滿足業(yè)務(wù)的查詢場(chǎng)景，又能保證分布式的數(shù)據(jù)存儲(chǔ)。

第二就是有臨時(shí)比較大的數(shù)據(jù)導(dǎo)出情況，業(yè)務(wù)方需要獲取批量比較大的數(shù)據(jù)，他們能夠?qū)氲?HDFS 上面，然后業(yè)務(wù)使用方從 HDFS 導(dǎo)出數(shù)據(jù)用于不同的業(yè)務(wù)應(yīng)用。

第三也支持一些普通文本，比如 csv 等。第四就是 MySQL，這個(gè)當(dāng)前有支持一些分表的策略的存儲(chǔ)。最后一塊就是要豐富統(tǒng)計(jì)算子，當(dāng)前有實(shí)現(xiàn)一些去重、數(shù)組、TopN 等統(tǒng)計(jì)算子。

數(shù)據(jù)可視化

如圖 9，因?yàn)榇鎯?chǔ)層是多樣多樣，原來的方式是我們的存儲(chǔ)層直接暴露給應(yīng)用的數(shù)據(jù)后臺(tái)，他們從我們的存儲(chǔ)層查詢數(shù)據(jù)解析。

圖9

這個(gè)方式有一些不太好的地方，第一個(gè)是數(shù)據(jù)臺(tái)如果不去透明化這個(gè)存儲(chǔ)層的話，展示層開發(fā)需要學(xué)習(xí) Hbase、MySQL、Mongo 等，有比較大的學(xué)習(xí)成本。

第二是數(shù)據(jù)安全方面的考慮，或者對(duì)數(shù)據(jù)存儲(chǔ)的統(tǒng)一的管理，都是有比較不好的地方，所以后面整了一套統(tǒng)一通用的 API，有定制一套統(tǒng)一數(shù)據(jù)的協(xié)議，方便展示層統(tǒng)一對(duì)接數(shù)據(jù)做展示。

但接下來還會(huì)有一些問題，我們需要去考慮平臺(tái)化的數(shù)據(jù)安全，如圖 10。

圖10

比如通常情況下，美拍的后臺(tái)只能夠獲取到美拍相關(guān)的數(shù)據(jù)，而不允許美拍后臺(tái)能獲取到其他 APP 商業(yè)廣告的數(shù)據(jù)。

所以我們有實(shí)現(xiàn)一個(gè)統(tǒng)一的認(rèn)證中心 CA，就是業(yè)務(wù)方后臺(tái)需要先去 CA 獲取相應(yīng)的授權(quán) Token，然后去請(qǐng)求統(tǒng)一通用 API 時(shí)都會(huì)帶上 acess token。

通用 API 作為一個(gè)通用服務(wù)方，會(huì)去 CA 認(rèn)證這個(gè) Token 是不是合法，合法的話才會(huì)在存儲(chǔ)層查詢相應(yīng)的數(shù)據(jù)，最后返回給應(yīng)用方。

美圖統(tǒng)計(jì)平臺(tái)的整體架構(gòu)

有一個(gè)統(tǒng)一的任務(wù)調(diào)度中心調(diào)度所有的統(tǒng)計(jì)任務(wù)，然后是 JobExecutor 負(fù)責(zé)從插件池來找相應(yīng)的插件，做一些查詢、過濾等。

圖11

最終數(shù)據(jù)存儲(chǔ)到 DB，會(huì)有一個(gè)統(tǒng)一的 API 封裝存儲(chǔ)層，然后處于一些安全方面考慮有接入 CA，最終各個(gè)數(shù)據(jù)后臺(tái)對(duì)接通用 API 來做數(shù)據(jù)展示。

正在做的事情以及未來小階段的規(guī)劃

圖12

當(dāng)前正在做的事情有兩塊，還沒有正式上線或者接入。

01.分布式調(diào)度

第一塊是我們自己開發(fā)一套分布式調(diào)度，這套調(diào)度主要偏一套通用調(diào)度平臺(tái)，不僅調(diào)度統(tǒng)計(jì)的任務(wù)，后續(xù)可以調(diào)度所有的離線計(jì)算的任務(wù)以及離線統(tǒng)計(jì)的任務(wù)。

接下來所有的統(tǒng)計(jì)任務(wù)都會(huì)遷移到這個(gè)通用分布式調(diào)度平臺(tái)上做統(tǒng)一的任務(wù)調(diào)度，替代當(dāng)前單點(diǎn)的簡(jiǎn)單版本的調(diào)度中心。后續(xù)也會(huì)去支持資源方面的隔離和資源方面的調(diào)度。

02.數(shù)據(jù)可視化

第二塊就是數(shù)據(jù)可視化。我們剛剛看到的前面那一塊，業(yè)務(wù)方的所有數(shù)據(jù)后臺(tái)需要一遍遍重復(fù)地接入我們的統(tǒng)一通用 API，是有比較多的重復(fù)工作，另外一個(gè)痛點(diǎn)是確實(shí)是涉及到一些比較大的 APP。

比如美拍他們整體的統(tǒng)計(jì)報(bào)表非常多，后臺(tái)基本上可能是成百上千這樣的數(shù)據(jù)，如果一個(gè)數(shù)據(jù)需求方想看到他們自己的數(shù)據(jù)，那么他們從成百上千個(gè)數(shù)據(jù)指標(biāo)去定位到自己的數(shù)據(jù)指標(biāo)是非常困難的。

數(shù)據(jù)可視化這么一個(gè)平臺(tái)就是解決這樣的問題，我不需要所有的業(yè)務(wù)方都接入這個(gè)通用 API，在同一個(gè)平臺(tái)可以選擇想要的數(shù)據(jù)源或者自己可視化的報(bào)表，然后呈現(xiàn)自己個(gè)性化的數(shù)據(jù)指標(biāo)，不需要再去跟所有應(yīng)用的數(shù)據(jù)后臺(tái)去對(duì)接我們的 API。

然后做一些圖形方面的展示。所以數(shù)據(jù)可視化這一塊主要是做統(tǒng)計(jì)以及提供定制化、個(gè)性化的數(shù)據(jù)報(bào)表，有點(diǎn)類似于網(wǎng)易的 bdp 或者阿里的 dataV 等平臺(tái)。

另外兩塊是接下來一段時(shí)間，我們規(guī)劃要做的事情：

• 第一是數(shù)據(jù)分析人員經(jīng)常抱怨說這個(gè)數(shù)據(jù)能不能有更快的查詢方式，所以考慮搭建一個(gè) OLAP 服務(wù)，比如基于 kylin 等來構(gòu)建。
• 第二個(gè)是實(shí)時(shí)統(tǒng)計(jì)方面，剛剛前面講的要么是定時(shí)的常規(guī)的統(tǒng)計(jì)需求，要么就是臨時(shí)的統(tǒng)計(jì)需求，沒有實(shí)時(shí)。所以這一塊考慮說后面這個(gè)平臺(tái)也能對(duì)接實(shí)時(shí)的統(tǒng)計(jì)需求，能更快速地對(duì)接滿足實(shí)時(shí)統(tǒng)計(jì)的需求場(chǎng)景。

End.

轉(zhuǎn)載請(qǐng)注明來自36大數(shù)據(jù)（36dsj.com)： 36大數(shù)據(jù) ? 日活躍數(shù)千萬，10億級(jí)APP大數(shù)據(jù)統(tǒng)計(jì)分析平臺(tái)的架構(gòu)演進(jìn)