作為系列文章的第二篇，本文將首先來(lái)探討應(yīng)用層中的運(yùn)營(yíng)數(shù)據(jù)系統(tǒng)，因?yàn)檫\(yùn)營(yíng)數(shù)據(jù)幾乎是所有互聯(lián)網(wǎng)創(chuàng)業(yè)公司開(kāi)始做數(shù)據(jù)的起點(diǎn)，也是早期數(shù)據(jù)服務(wù)的主要對(duì)象。本文將著重回顧下我們做了哪些工作、遇到過(guò)哪些問(wèn)題、如何解決并實(shí)現(xiàn)了相應(yīng)的功能。

[[182935]]

早期數(shù)據(jù)服務(wù)

產(chǎn)品上線(xiàn)開(kāi)始推廣后不久，后臺(tái)研發(fā)人員便會(huì)經(jīng)常收到運(yùn)營(yíng)同事的私信：“能不能查一下有多少用戶(hù)注冊(cè)了，來(lái)自哪里?……..”。幾次之后，大家便覺(jué)得這樣的效率太低了：研發(fā)人員需要在繁忙的開(kāi)發(fā)任務(wù)中抽時(shí)間來(lái)做數(shù)據(jù)查詢(xún)、統(tǒng)計(jì)，而運(yùn)營(yíng)同事則需要等很久才能拿到數(shù)據(jù)。于是，大家開(kāi)始協(xié)商更好的方法，最終達(dá)成一致：由運(yùn)營(yíng)同事提供所需的數(shù)據(jù)模板，后臺(tái)研發(fā)人員根據(jù)模板將數(shù)據(jù)導(dǎo)入Excel文件，運(yùn)營(yíng)同事可根據(jù)自身需求自己分析統(tǒng)計(jì)。這便是早期的數(shù)據(jù)服務(wù)了，其組成結(jié)構(gòu)如下圖所示。

這樣的做法簡(jiǎn)單明了，后臺(tái)研發(fā)人員根據(jù)數(shù)據(jù)模板寫(xiě)一個(gè)Python腳本，從業(yè)務(wù)數(shù)據(jù)庫(kù)中將數(shù)據(jù)撈出來(lái)，做些分析、整合后，將結(jié)果輸出到一個(gè)Excel文件，然后發(fā)送郵件通知運(yùn)營(yíng)同事接收文件。然而，隨著需求的增加和細(xì)化、數(shù)據(jù)量的增加，暴露的問(wèn)題越來(lái)越多，這里先羅列出來(lái)，這些問(wèn)題有的會(huì)在本文提出解決方案，有的則會(huì)在后面的文章中陸續(xù)提出解決方案。

• Worker越來(lái)越多，分布在多個(gè)地方，存在很多重復(fù)的勞動(dòng)和代碼，某個(gè)邏輯的修改需要改很多文件。
• 由于使用ORM來(lái)訪(fǎng)問(wèn)數(shù)據(jù)庫(kù)，很多代碼只考慮邏輯，沒(méi)考慮到查詢(xún)數(shù)據(jù)的效率問(wèn)題，導(dǎo)致有些報(bào)告需要跑十幾個(gè)小時(shí)才能出結(jié)果(在循環(huán)查詢(xún)數(shù)據(jù)的性能問(wèn)題及優(yōu)化一文有講解)。
• 中間計(jì)算結(jié)果流失，數(shù)據(jù)沒(méi)有共享，每個(gè)Worker都要跑自己的邏輯去算一遍。
• Woker依靠crontab來(lái)控制觸發(fā)，沒(méi)有監(jiān)管，經(jīng)常由于臟數(shù)據(jù)導(dǎo)致中斷，需要等到運(yùn)營(yíng)同事發(fā)現(xiàn)后報(bào)過(guò)來(lái)才知道。

運(yùn)營(yíng)數(shù)據(jù)Dashboard

隨著業(yè)務(wù)的發(fā)展，以數(shù)據(jù)報(bào)表的形式來(lái)提供數(shù)據(jù)服務(wù)逐漸不能滿(mǎn)足需求了。一方面，高層期望每天一早便能看到清晰的數(shù)據(jù)，搞清楚最近的運(yùn)營(yíng)效果和趨勢(shì);另一方面，雖然數(shù)據(jù)報(bào)表提供了詳細(xì)的數(shù)據(jù)，但是還是需要手動(dòng)去過(guò)濾、統(tǒng)計(jì)一下才有結(jié)果，所有想看數(shù)據(jù)的人都需要做一遍才行，而業(yè)務(wù)人員處理Excel的水平層次不齊。

于是，我們開(kāi)始籌劃Dashboard系統(tǒng)，以Web的形式提供數(shù)據(jù)可視化服務(wù)?？墒?，Dashboard要做成什么樣子?由于產(chǎn)品經(jīng)理和設(shè)計(jì)人員都忙于產(chǎn)品業(yè)務(wù)，所以只能自己考慮要做什么、怎么做。好在筆者之前用過(guò)百度統(tǒng)計(jì)，對(duì)那里面的一些統(tǒng)計(jì)服務(wù)比較清楚，結(jié)合公司的業(yè)務(wù)，形成了一些思路：

數(shù)據(jù)內(nèi)容上，包含：核心指標(biāo)數(shù)據(jù)和圖表分析兩部分。前者以曲線(xiàn)圖為主，要能快速顯示數(shù)量和趨勢(shì)，比如注冊(cè)日增量趨勢(shì)圖;后者使用各種圖表來(lái)展現(xiàn)某個(gè)時(shí)間段內(nèi)的分析結(jié)果，比如10月份的***0用戶(hù)感興趣品牌。

數(shù)據(jù)類(lèi)型上，包含：C端核心指標(biāo)、B端核心指標(biāo)、核心分析和專(zhuān)題活動(dòng)指標(biāo)與分析。前兩者是分別針對(duì)C端和B端的指標(biāo)數(shù)據(jù)，核心分析是一些綜合的分析，比如轉(zhuǎn)化率分析，專(zhuān)題活動(dòng)是針對(duì)一些特定的大型運(yùn)營(yíng)活動(dòng)。

數(shù)據(jù)維度上，包含：時(shí)間維度、城市維度和B端品牌維度。時(shí)間是最基本最重要的維度，城市維度可以分析各個(gè)運(yùn)營(yíng)大區(qū)的狀態(tài)，B端品牌維度主要是針對(duì)B端上的業(yè)務(wù)。

整理后便形成了下圖所示的Mockup(簡(jiǎn)化版)，基本涵蓋了上述的思路。雖然在美觀上相對(duì)欠缺，但是畢竟是內(nèi)部使用嘛，重要的數(shù)據(jù)顯示要能準(zhǔn)確、快速。

搞清楚了要做什么，接下來(lái)就是要將想法落地，考慮如何實(shí)現(xiàn)了。

整體架構(gòu)

系統(tǒng)的整體架構(gòu)如下圖所示，主要基于這么幾點(diǎn)考慮：

前后端分離。前端只負(fù)責(zé)加載圖表、請(qǐng)求數(shù)據(jù)并顯示，不做任何數(shù)據(jù)邏輯處理;后端負(fù)責(zé)產(chǎn)出數(shù)據(jù)，并提供REST API與前端交互。

離線(xiàn)與實(shí)時(shí)計(jì)算并存。為了提高數(shù)據(jù)獲取的速度，曲線(xiàn)指標(biāo)數(shù)據(jù)采用離線(xiàn)計(jì)算的方式，提供歷史數(shù)據(jù)供前端展示;圖表分析類(lèi)數(shù)據(jù)采用實(shí)時(shí)計(jì)算的方式，其速度取決于所選時(shí)間段內(nèi)的數(shù)據(jù)量，必要時(shí)進(jìn)行緩存。

前端實(shí)現(xiàn)

Dashboard系統(tǒng)的前端并不復(fù)雜，前面也提到我們不會(huì)做太多樣式上的工作，重點(diǎn)是數(shù)據(jù)的顯示。那么，***件事就是要尋找一款圖表庫(kù)。筆者這里選擇的是百度ECharts，其提供了豐富的圖表類(lèi)型，可視化效果很棒，對(duì)移動(dòng)端的支持很友好，重要的是有詳細(xì)的示例和文檔。事實(shí)證明ECharts確實(shí)很強(qiáng)大，很好的滿(mǎn)足了我們的各種需求。

選好了圖表庫(kù)，接下來(lái)的問(wèn)題是如何優(yōu)雅的加載幾十個(gè)圖表，甚至更多。這就需要找到圖表顯示共性的地方(行為和屬性)，進(jìn)行抽象。通常，使用ECharts顯示一個(gè)數(shù)據(jù)圖表需要四步(官方文檔)：***步，引入ECharts的JS文件;第二步，聲明一個(gè)DIV作為圖表的容器;第三步，初始化一個(gè)echart實(shí)例，將其與DIV元素綁定，并初始化配置項(xiàng);第四步，加載圖表的數(shù)據(jù)并顯示?？梢园l(fā)現(xiàn)，行為上主要分為初始化和更新數(shù)據(jù)兩個(gè)，屬性上主要是初始配置項(xiàng)和數(shù)據(jù)。

基于此，筆者使用“Pattern+Engine”的思想來(lái)實(shí)現(xiàn)前端數(shù)據(jù)加載。首先，在JS中使用JSON對(duì)每個(gè)圖表進(jìn)行配置，即寫(xiě)Pattern。例如，下面的配置便對(duì)應(yīng)了一個(gè)圖表，elementId是DIV的id，title是圖表的標(biāo)題，names是圖表的曲線(xiàn)名稱(chēng)，url提供了獲取數(shù)據(jù)的API，loader表示要加載的圖表Engine。而一個(gè)頁(yè)面的圖表便由一組這樣的配置項(xiàng)組成。

頁(yè)面加載時(shí)，根據(jù)Pattern中的配置項(xiàng)生成相應(yīng)的Loader Engine實(shí)例，用來(lái)初始化圖表和更新數(shù)據(jù)。每個(gè)Loader對(duì)應(yīng)一個(gè)ECharts圖表類(lèi)型，因?yàn)椴煌瑘D表類(lèi)型的初始化和加載數(shù)據(jù)的方法不同。程序類(lèi)圖如下所示。

后端實(shí)現(xiàn)

前面提到在早期的數(shù)據(jù)服務(wù)中，存在很多重復(fù)勞動(dòng)和代碼，因此在Dashboard系統(tǒng)的后端實(shí)現(xiàn)中，筆者開(kāi)始考慮構(gòu)建數(shù)據(jù)分析的公共庫(kù)，這塊占據(jù)了很大一部分工作量。底層公共庫(kù)不針對(duì)任何特殊業(yè)務(wù)需求，主要負(fù)責(zé)三件事：***，封裝數(shù)據(jù)源連接方法;第二，封裝時(shí)間序列的生成方法，產(chǎn)生以天、周、月為間隔的時(shí)間序列;第三，封裝基礎(chǔ)的數(shù)據(jù)查詢(xún)、清洗、統(tǒng)計(jì)、分析方法，形成格式化的數(shù)據(jù)，這部分是最重要的。

完成了底層公共庫(kù)的構(gòu)建后，整個(gè)代碼結(jié)構(gòu)一下子就清爽了很多。在其基礎(chǔ)上，開(kāi)始構(gòu)建上層的Analyzer。Analyzer用于完成具體的數(shù)據(jù)分析需求，每個(gè)Analyzer負(fù)責(zé)一個(gè)或多個(gè)數(shù)據(jù)指標(biāo)的產(chǎn)出，每個(gè)曲線(xiàn)圖/圖表的數(shù)據(jù)由一個(gè)Analyzer來(lái)負(fù)責(zé)。離線(xiàn)計(jì)算與實(shí)時(shí)計(jì)算，則是分別在Schedule和Web請(qǐng)求的觸發(fā)下，調(diào)用對(duì)應(yīng)的Analyzer來(lái)完成數(shù)據(jù)產(chǎn)出。因此，整個(gè)后臺(tái)系統(tǒng)分為三層來(lái)實(shí)現(xiàn)，如下圖所示。

***談一談離線(xiàn)數(shù)據(jù)的問(wèn)題。目前離線(xiàn)計(jì)算是由Schedule來(lái)觸發(fā)，每日零點(diǎn)計(jì)算前一日的數(shù)據(jù)，數(shù)據(jù)按照“每個(gè)指標(biāo)在不同維度上每天一個(gè)數(shù)據(jù)點(diǎn)”的原則來(lái)生成，由上述的Analyzer來(lái)負(fù)責(zé)產(chǎn)出格式化的數(shù)據(jù)，存入MongoDB中。由于查詢(xún)規(guī)則簡(jiǎn)單，只需建立一個(gè)組合索引就可以解決效率問(wèn)題了。目前數(shù)據(jù)量在500W左右，暫時(shí)沒(méi)有出現(xiàn)性能問(wèn)題，后期可以考慮將部分歷史數(shù)據(jù)遷移，當(dāng)然這是后話(huà)。

數(shù)據(jù)報(bào)表

Dashboard上線(xiàn)后，我們開(kāi)始考慮將早期的數(shù)據(jù)報(bào)表服務(wù)逐步停下來(lái)，減少維護(hù)的成本。而運(yùn)營(yíng)同事希望能繼續(xù)保留部分報(bào)表，因?yàn)镈ashboard雖然提供了很多數(shù)據(jù)指標(biāo)和分析，但是有些工作需要更精細(xì)的數(shù)據(jù)信息來(lái)做，比如給帶來(lái)微信注冊(cè)的校園代理結(jié)算工資、對(duì)新注冊(cè)用戶(hù)電話(huà)回訪(fǎng)等等。經(jīng)過(guò)一番梳理和協(xié)商，最終保留了六個(gè)數(shù)據(jù)報(bào)表。另一方面，B端的商家期望能在后臺(tái)導(dǎo)出自己的相關(guān)數(shù)據(jù)。綜合兩方面需求，筆者構(gòu)建了新的數(shù)據(jù)報(bào)表系統(tǒng)。

新的數(shù)據(jù)報(bào)表系統(tǒng)，按照流程來(lái)劃分為三部分：觸發(fā)、執(zhí)行與通知。內(nèi)部數(shù)據(jù)報(bào)表依舊由Schedule觸發(fā)，啟動(dòng)相應(yīng)的Worker進(jìn)程來(lái)執(zhí)行;而提供給外部的報(bào)表由Web前端通過(guò)REST API來(lái)觸發(fā)，將相應(yīng)的任務(wù)加入Celery任務(wù)隊(duì)列中執(zhí)行。執(zhí)行體由一組Exporter來(lái)完成，Exporter負(fù)責(zé)獲取數(shù)據(jù)、生成適合寫(xiě)入Excel的數(shù)據(jù)格式、寫(xiě)Excel文件，數(shù)據(jù)獲取部分依賴(lài)前面所述的底層公共庫(kù)。***，統(tǒng)一發(fā)送郵件通知。

考慮到早期數(shù)據(jù)服務(wù)中經(jīng)常遇到異常導(dǎo)致生成報(bào)表失敗的問(wèn)題，筆者在新的數(shù)據(jù)報(bào)表系統(tǒng)中做了兩點(diǎn)與異常相關(guān)的處理：

使用Airflow對(duì)Schedule觸發(fā)的任務(wù)進(jìn)行監(jiān)控(后續(xù)文章會(huì)有詳細(xì)介紹)，手動(dòng)觸發(fā)的任務(wù)則由Celery進(jìn)行監(jiān)控，遇到異常便發(fā)送郵件通知到開(kāi)發(fā)人員。

如果一個(gè)Excel數(shù)據(jù)文件由多個(gè)Sheet組成，當(dāng)某個(gè)Sheet出現(xiàn)異常時(shí)，通常由兩種處理方法：一是丟棄整個(gè)文件，二是保留其他Sheet信息繼續(xù)生成Excel文件。這里，內(nèi)部報(bào)告使用了第二種處理方法，外部報(bào)告相對(duì)嚴(yán)謹(jǐn)，使用了***種。

以上便是筆者所在公司的運(yùn)營(yíng)數(shù)據(jù)系統(tǒng)的發(fā)展歷程和現(xiàn)狀，目前Dashboard與數(shù)據(jù)報(bào)表兩個(gè)系統(tǒng)已經(jīng)趨于穩(wěn)定，基本提供了90%以上的運(yùn)營(yíng)數(shù)據(jù)服務(wù)。當(dāng)然，隨著數(shù)據(jù)量的增長(zhǎng)、業(yè)務(wù)需求的發(fā)展，一定會(huì)面臨更多新的挑戰(zhàn)。

點(diǎn)擊查看：

創(chuàng)業(yè)公司做數(shù)據(jù)分析(一)開(kāi)篇

創(chuàng)業(yè)公司做數(shù)據(jù)分析(三)用戶(hù)行為數(shù)據(jù)采集系統(tǒng)

創(chuàng)業(yè)公司做數(shù)據(jù)分析(四)ELK日志系統(tǒng)

創(chuàng)業(yè)公司做數(shù)據(jù)分析(五)微信分享追蹤系統(tǒng)

創(chuàng)業(yè)公司做數(shù)據(jù)分析(六)數(shù)據(jù)倉(cāng)庫(kù)的建設(shè)