自己的 彩信 解決 size 期望 缺少 拖拉 自己 比較

數據分析平臺的目標 產品上線有一定流量後都會有數據分析的需求，分析運營狀態、用戶行為、應用運行情況等等，為產品改進提供數據支撐。但是數據分析可大可小：既可做到只提供概覽，也可做到對每條數據的分析；既可只分析業務指標像用戶增長情況等，也可能要分析用戶行為或者系統參數等。因此，搭建一個數據分析平臺之前一定要了解自己的需求才知道要做到什麽程度。 筆者在本文搭建的數據分析平臺，主要想達到5個目標：

1. 了解產品狀態：包含業務指標、應用指標和系統指標三大部分。業務指標比如用戶增長情況，新增訂單情況；也有應用指標，比如用戶的搜索次數，登陸次數，應用運行狀態等；還會有系統指標，比如nginx,mysql,redis運行情況，系統使用率等等;（見效果圖1）
2. 異常行為的詳細分析：當從第1步中發現有異常指標時，可能需要抽取出某一天，某個用戶，某個IP產生的所有記錄對它們分析；（見效果圖2）
3. 集中對多個產品的分析：我們自己的產品就超過有近10個，要了解產品狀態需要登陸每個產品後臺顯然是太費勁了，所以需要集中管理；
4. 靈活擴展：當需要對多個產品做數據分析時，不可能去指望每個產品的數據指標都一樣，而是數據分析平臺要能夠針對不同產品快速創建指標，比如免費的產品就沒有訂單相關的指標，而收費產品就有這些指標。
5. 權限管理：業務指標和行為指標通常是給運營和產品人員看的，而運營人員和產品人員要看的產品可能不是同一個，應該要有權限管理才能確保不同角色只看到屬於他們的內容。

解決方案 最初我們想在各個產品集成數據分析功能，然後做一個集中式的數據分析平臺管理各個項目，實際分析後自己開發工作量過大，並不現實。轉而思考使用開源產品或者第三方平臺。但是單個數據分析平臺通常難以完全滿足我們的所有目標，因此在思路上轉為考慮將多個數據分析平臺組合在一起。 在測試了多個開源產品和平臺以後，最終引入Grafana+ELK作為數據分析的平臺。為方便討論，我們將數據分析分成三大場景：概覽、分析和監控。解決方案之所以需要多個產品組合在一起，是因為不同的產品對於不同角色，不同場景的側重點不同，一款產品要同時覆蓋運營、產品、開發這些角色對數據分析的需求不太現實 ，因此通過組合的方式解決此問題。 （圖片來源：《騰訊好文！如何設計內容精確、體驗友好的Dashboard？（上篇）》） 解決方案分為三個部分：

1. 產品自身後臺：只支持業務指標的概覽，不實現分析和監控功能。該部分並沒有解決目標問題，但是這個觀念可以防止投入過多資源到產品後臺的開發上。
2. Grafana：業務指標、應用指標以及系統指標的概覽和監控，和比較弱的分析功能。該平臺解決目標1，3，4，5。
3. ELK：對異常行為做詳細分析。盡管ELK也可以支持概覽和監控，但是只適合開發人員，而Grafana已經能解決目標問題，所以ELK主要承擔分析的職責。該平臺解決目標2。

效果圖 1.Grafana快速呈現業務指標和用用戶行為指標效果圖： 2.異常行為分析效果圖： 擴展閱讀：Grafana、ELK、七牛雲日誌智能管理平臺、BDP的區別 在調研各個數據分析平臺時，測試比較多的Grafana、ELK、七牛雲、BDP這幾個平臺。前兩個是開源平臺，後兩個是第三方平臺。為什麽最終采用Grafana+ELK的組合呢？而不是采用BDP代替Grafana，七牛雲代替ELK呢，這就需要對它們之間的區別做個比較。 在比較不同的數據分析平臺時，借用下圖，從監控源、數據彩信、數據存儲、數據分析、數據展現（預警本文不討論）去分析它們的區別。 （圖片來自《建設DevOps統一運維監控平臺，先從日誌監控說起》一文）

• Grafana：Grafana的數據存儲可來自MySQL，也可以是ElasticSearch或者Prothemous等各種類型的數據源。對這些數據源的支持使得Grafana可以直接覆蓋各種監控源，采集業務指標、應用指標和系統指標自然就不在話下。再加上它本身的鑒權系統完善，如果只選擇一個可視化平臺，它會是首選。Grafana缺點在於數據分析上不夠強大，比如全日誌檢索等，當發現異常需要對數據深入分析時，就不方便了，這時就需要ELK了。
• ELK：ELK是日誌分析系統的開源方案，它在上面的各個方面都很強大。但是它的定位既決定了它的優點，也決定了它的不足。它在數據分析非常強大，適合對異常行為做深入分析；但是用它做業務指標的呈現就顯得太過復雜了，比如只是統計有多少用戶和對用戶做分類，在Grafana中直接讀取MySQL數據庫即可，在ELK中就需要繞很長的路。另外，它沒有鑒權系統。這些缺點其實是ELK的目標人群是開發者決定的，它正好補了單純用Grafana的短板。
• 七牛雲日誌智能管理平臺：七牛雲是ELK的替代品，一開始我是想直接使用不搭建ELK。但是在調研了3天，由於2個原因放棄了:1.反復配置後沒有得到期望的效果 2.想要接入Grafana，發現只能使用官方提供的服務，不能接入自行搭建的Grafana。如果使用中有較多問題，那我會傾向於使用開源方案，ELK碰到問題時可以通過上網搜索自行解決；但是使用第三方平臺就只能依賴於官方支持了。但是對於缺少開發資源的公司，采用第三方平臺會是更好選擇。
• BDP：BDP是第三方的數據分析平臺，分析它是想確認它是否能夠代替Grafana，或者部分代替Grafana。由於BDP主要解決業務層面的數據分析，於是這裏從業務指標和非業務指標兩方面去比較。
• • 業務指標：BDP主要定位就是處理業務數據，主要目標人群是非IT，以及對外呈現。所以它在處理純業務數據上功能上是強於Grafana的，比如多來源的數據合並、報表十分豐富、導出精美排版的PDF等等。如果要做對外宣傳的報表，或者將多個來源的業務數據並在一起，我認為它比Grafana更合適。但是在大部分情況下，我們主要還是使用單個產品分析，或多產品的重疊比較。這個時候，對於開發者而言，BDP需要先導入表、對表拼接（SQL語法弱導致的，比如SELECT *不支持，更不用說JSON_VALUE等新特性）、以及過濾項的拖拉並不如模板變量好用，所以在大部分的業務指標上，它並不如Grafana有效率。
  • 非業務指標：比如ES中的nginx日誌、監控mysql運行數據、系統運行時的CPU等等，在監控源上BDP並不支持，Grafana則支持多種類型的時序數據庫。所以非業務指標的話，BDP並不適合與Grafana比較。
  • 綜上，我把BDP當成對Grafana的補充，而不是替代關系。

參考

• 《騰訊好文！如何設計內容精確、體驗友好的Dashboard?（上篇)》
• 《建設DevOps統一運維監控平臺，全面的系統監控你做好了嗎？》
• 《日誌分析方法概述 & WEB日誌挖掘分析的方法》
• 《OLTP和OLAP區別》

快速搭建產品的數據分析平臺——思路篇