創業公司做數據分析(二)運營數據系統
作為系列文章的第二篇，本文將首先來探討應用層中的運營數據系統，因為運營數據幾乎是所有互聯網創業公司開始做數據的起點，也是早期數據服務的主要對象。本文將著重回顧下我們做了哪些工作、遇到過哪些問題、如何解決并實現了相應的功能。
早期數據服務
產品上線開始推廣后不久，后臺研發人員便會經常收到運營同事的私信：“能不能查一下有多少用戶注冊了，來自哪里?……..”。幾次之后，大家便覺得這樣的效率太低了：研發人員需要在繁忙的開發任務中抽時間來做數據查詢、統計，而運營同事則需要等很久才能拿到數據。于是，大家開始協商更好的方法，最終達成一致：由運營同事提供所需的數據模板，后臺研發人員根據模板將數據導入Excel文件，運營同事可根據自身需求自己分析統計。這便是早期的數據服務了，其組成結構如下圖所示。
這樣的做法簡單明了，后臺研發人員根據數據模板寫一個Python腳本，從業務數據庫中將數據撈出來，做些分析、整合后，將結果輸出到一個Excel文件，然后發送郵件通知運營同事接收文件。然而，隨著需求的增加和細化、數據量的增加，暴露的問題越來越多，這里先羅列出來，這些問題有的會在本文提出解決方案，有的則會在后面的文章中陸續提出解決方案。
- Worker越來越多，分布在多個地方，存在很多重復的勞動和代碼，某個邏輯的修改需要改很多文件。
- 由于使用ORM來訪問數據庫，很多代碼只考慮邏輯，沒考慮到查詢數據的效率問題，導致有些報告需要跑十幾個小時才能出結果(在循環查詢數據的性能問題及優化一文有講解)。
- 中間計算結果流失，數據沒有共享，每個Worker都要跑自己的邏輯去算一遍。
- Woker依靠crontab來控制觸發，沒有監管，經常由于臟數據導致中斷，需要等到運營同事發現后報過來才知道。
運營數據Dashboard
隨著業務的發展，以數據報表的形式來提供數據服務逐漸不能滿足需求了。一方面，高層期望每天一早便能看到清晰的數據，搞清楚最近的運營效果和趨勢;另一方面，雖然數據報表提供了詳細的數據，但是還是需要手動去過濾、統計一下才有結果，所有想看數據的人都需要做一遍才行，而業務人員處理Excel的水平層次不齊。
于是，我們開始籌劃Dashboard系統，以Web的形式提供數據可視化服務。可是，Dashboard要做成什么樣子?由于產品經理和設計人員都忙于產品業務，所以只能自己考慮要做什么、怎么做。好在筆者之前用過百度統計，對那里面的一些統計服務比較清楚，結合公司的業務，形成了一些思路：
數據內容上，包含：核心指標數據和圖表分析兩部分。前者以曲線圖為主，要能快速顯示數量和趨勢，比如注冊日增量趨勢圖;后者使用各種圖表來展現某個時間段內的分析結果，比如10月份的***0用戶感興趣品牌。
數據類型上，包含：C端核心指標、B端核心指標、核心分析和專題活動指標與分析。前兩者是分別針對C端和B端的指標數據，核心分析是一些綜合的分析，比如轉化率分析，專題活動是針對一些特定的大型運營活動。
數據維度上，包含：時間維度、城市維度和B端品牌維度。時間是最基本最重要的維度，城市維度可以分析各個運營大區的狀態，B端品牌維度主要是針對B端上的業務。
整理后便形成了下圖所示的Mockup(簡化版)，基本涵蓋了上述的思路。雖然在美觀上相對欠缺，但是畢竟是內部使用嘛，重要的數據顯示要能準確、快速。
搞清楚了要做什么，接下來就是要將想法落地，考慮如何實現了。
整體架構
系統的整體架構如下圖所示，主要基于這么幾點考慮：
前后端分離。前端只負責加載圖表、請求數據并顯示，不做任何數據邏輯處理;后端負責產出數據，并提供REST API與前端交互。
離線與實時計算并存。為了提高數據獲取的速度，曲線指標數據采用離線計算的方式，提供歷史數據供前端展示;圖表分析類數據采用實時計算的方式，其速度取決于所選時間段內的數據量，必要時進行緩存。
前端實現
Dashboard系統的前端并不復雜，前面也提到我們不會做太多樣式上的工作，重點是數據的顯示。那么，***件事就是要尋找一款圖表庫。筆者這里選擇的是百度ECharts，其提供了豐富的圖表類型，可視化效果很棒，對移動端的支持很友好，重要的是有詳細的示例和文檔。事實證明ECharts確實很強大，很好的滿足了我們的各種需求。
選好了圖表庫，接下來的問題是如何優雅的加載幾十個圖表，甚至更多。這就需要找到圖表顯示共性的地方(行為和屬性)，進行抽象。通常，使用ECharts顯示一個數據圖表需要四步(官方文檔)：***步，引入ECharts的JS文件;第二步，聲明一個DIV作為圖表的容器;第三步，初始化一個echart實例，將其與DIV元素綁定，并初始化配置項;第四步，加載圖表的數據并顯示。可以發現，行為上主要分為初始化和更新數據兩個，屬性上主要是初始配置項和數據。
基于此，筆者使用“Pattern+Engine”的思想來實現前端數據加載。首先，在JS中使用JSON對每個圖表進行配置，即寫Pattern。例如，下面的配置便對應了一個圖表，elementId是DIV的id，title是圖表的標題，names是圖表的曲線名稱，url提供了獲取數據的API，loader表示要加載的圖表Engine。而一個頁面的圖表便由一組這樣的配置項組成。
頁面加載時，根據Pattern中的配置項生成相應的Loader Engine實例，用來初始化圖表和更新數據。每個Loader對應一個ECharts圖表類型，因為不同圖表類型的初始化和加載數據的方法不同。程序類圖如下所示。
后端實現
前面提到在早期的數據服務中，存在很多重復勞動和代碼，因此在Dashboard系統的后端實現中，筆者開始考慮構建數據分析的公共庫，這塊占據了很大一部分工作量。底層公共庫不針對任何特殊業務需求，主要負責三件事：***，封裝數據源連接方法;第二，封裝時間序列的生成方法，產生以天、周、月為間隔的時間序列;第三，封裝基礎的數據查詢、清洗、統計、分析方法，形成格式化的數據，這部分是最重要的。
完成了底層公共庫的構建后，整個代碼結構一下子就清爽了很多。在其基礎上，開始構建上層的Analyzer。Analyzer用于完成具體的數據分析需求，每個Analyzer負責一個或多個數據指標的產出，每個曲線圖/圖表的數據由一個Analyzer來負責。離線計算與實時計算，則是分別在Schedule和Web請求的觸發下，調用對應的Analyzer來完成數據產出。因此，整個后臺系統分為三層來實現，如下圖所示。
***談一談離線數據的問題。目前離線計算是由Schedule來觸發，每日零點計算前一日的數據，數據按照“每個指標在不同維度上每天一個數據點”的原則來生成，由上述的Analyzer來負責產出格式化的數據，存入MongoDB中。由于查詢規則簡單，只需建立一個組合索引就可以解決效率問題了。目前數據量在500W左右，暫時沒有出現性能問題，后期可以考慮將部分歷史數據遷移，當然這是后話。
數據報表
Dashboard上線后，我們開始考慮將早期的數據報表服務逐步停下來，減少維護的成本。而運營同事希望能繼續保留部分報表，因為Dashboard雖然提供了很多數據指標和分析，但是有些工作需要更精細的數據信息來做，比如給帶來微信注冊的校園代理結算工資、對新注冊用戶電話回訪等等。經過一番梳理和協商，最終保留了六個數據報表。另一方面，B端的商家期望能在后臺導出自己的相關數據。綜合兩方面需求，筆者構建了新的數據報表系統。
新的數據報表系統，按照流程來劃分為三部分：觸發、執行與通知。內部數據報表依舊由Schedule觸發，啟動相應的Worker進程來執行;而提供給外部的報表由Web前端通過REST API來觸發，將相應的任務加入Celery任務隊列中執行。執行體由一組Exporter來完成，Exporter負責獲取數據、生成適合寫入Excel的數據格式、寫Excel文件，數據獲取部分依賴前面所述的底層公共庫。***，統一發送郵件通知。
考慮到早期數據服務中經常遇到異常導致生成報表失敗的問題，筆者在新的數據報表系統中做了兩點與異常相關的處理：
使用Airflow對Schedule觸發的任務進行監控(后續文章會有詳細介紹)，手動觸發的任務則由Celery進行監控，遇到異常便發送郵件通知到開發人員。
如果一個Excel數據文件由多個Sheet組成，當某個Sheet出現異常時，通常由兩種處理方法：一是丟棄整個文件，二是保留其他Sheet信息繼續生成Excel文件。這里，內部報告使用了第二種處理方法，外部報告相對嚴謹，使用了***種。
以上便是筆者所在公司的運營數據系統的發展歷程和現狀，目前Dashboard與數據報表兩個系統已經趨于穩定，基本提供了90%以上的運營數據服務。當然，隨著數據量的增長、業務需求的發展，一定會面臨更多新的挑戰。
點擊查看：
創業公司做數據分析(三)用戶行為數據采集系統
創業公司做數據分析(四)ELK日志系統
創業公司做數據分析(五)微信分享追蹤系統
創業公司做數據分析(六)數據倉庫的建設
