諸葛io，面向數據智能時代的大數據實踐（下）

在上篇「諸葛io，面向數據智能時代的大數據實踐（上）」,我們講到大數據的三次浪潮下諸葛io是如何誕生的，本文為諸葛io的業務架構實踐篇。

1．圖1自下而上是諸葛io當前的主要業務架構：

圖1

1）數據採集端

諸葛io現在提供了Android、iOS、JS等SDK和REST的Http介面來採集數據，SDK和介面都提供一些面向用戶的方法或者數據規範，我們分析的數據主要來於此。

2） 數據接收服務

SDK和介面採集到的數據會發給我們的網關服務，我們的API會對數據進行簡單加工，添加一些環境信息的欄位之後，發給我們的消息隊列。

3） 消息隊列

消息隊列會成為數據的集中處理中心，我們對消息會進行統一的加工轉換和清洗，比如過濾垃圾數據，關聯用戶的id，加工用戶的狀態和標籤，加工行為數據等。

4） 多業務處理

數據進行統一的加工和處理完成之後，我們會有多個服務同時消耗和處理基礎數據。主要包括以下部分：

a. 實時統計。為了減少對數據倉庫的壓力以及提高數據處理的效率，對於一些基礎指標，比如新增、活躍、觸發各種行為的人數等我們會進行實時統計，寫入到內存資料庫中。

b. 數據倉庫。數據倉庫是諸葛提供的深入用戶行為、多維交叉分析以及行業分析模型的核心，所以底層的數據模型和加工的中間數據層主要是在這一步完成，完成後會寫入到數據倉庫底層的資料庫中。

c. 數據索引。為了提高數據查詢和檢索的效率，我們會對一些維度數據生成索引，會寫入到索引資料庫中。

d. 數據備份。我們對原始上傳數據以及中間清洗後的數據會做多重備份，達到一定程度的災難恢復保障，會寫入到文件中。

5） 數據訪問層

我們會由統一的數據訪問層來輸出數據，給應用層進行調用。這一層我們會封裝一些分析模型和業務邏輯，數據訪問層會分為內部介面和外部介面進行分發。

6） 數據應用系統

我們的數據應用主要包括以下部分：

a. 諸葛io網站。網站是http://zhugeio.com 提供給企業客戶互動式自助分析的平台，包括了豐富的功能。

b. 內部服務。主要是DevOps和業務監控平台需要調用一些介面進行狀態監控和跟蹤，保障服務質量以及穩定性。

c. 數據挖掘。諸葛io有演算法組和分析組兩支隊伍對數據進行一些複雜的挖掘和分析，包括：

i) 用戶行為路徑挖掘

ii) 行業模型和看板

iii) 流失和預測分析

iv) 自動化的分析報告

d. 開放API。我們提供給客戶的不僅僅是匯總統計的數據，還允許用戶直接訪問和導出自己的原始數據和加工後的數據，因此我們把一些查詢封裝成了API的邏輯，允許客戶進行二次開發或者調用，所以我們有一個開放的API平台。

諸葛io的架構經歷了兩次迭代，目前正在進行第三次的重構。我們重構的目的包含兩方面：第一次重構主要是技術方案的瓶頸突破，第二次重構主要是業務領域問題的延伸和拓展。

架構永遠是貼合業務的。諸葛io是新一代分析平台裡面最早上線的。我們從2014年10月開始研發，上線於 15年3月份。當時，我們需要讓產品快速上線，驗證想法，所以架構搭建的比較簡單，包括我在內的6個工程師，完成了整套從數據採集到數據處理到網站到前端 可視化的大數據架構。由於我們的研發團隊在大數據領域經驗比較豐富，能解決各種技術難題。當時我們搭建的簡單架構如圖2：

圖2：諸葛io第一次上線的架構實踐

初次上線的架構在剛開始的一段時間內一切正常。隨著業務發展，諸葛io的客戶量逐步增加，如暴走漫畫、小影、墨跡天氣等大體量的客戶陸續接入平台，這個時候也面臨著諸多考驗。

2.圖3是我們第一次上線架構數據處理流的架構圖，標出了三個問題點：

圖3：諸葛io第一次上線的數據處理流:

1）數據上傳延時高。上傳延時很高主要有兩方面：

a. HTTPS建立連接和加密驗證過於耗時。HTTPS比普通的Http的三次握手多一個SSL驗證過程，我們第一次上線使用的是比較老的Nginx，並且只有單Nginx的支撐，握手壓力過大。雖 然我們在系統參數調優上做了很多嘗試，但是本質還是需要一次架構優化，因此選擇了在Nginx前加了一個LVS，把Nginx升級到最新版，並且支持了 HTTP2的協議，擴展了Nginx的伺服器數量。

b. 數據上傳模塊的設計缺陷。諸葛io之前的數據上傳模塊邏輯是：客戶端上傳數據到服務端，服務端接收後會解壓並且加入一些上傳的IP、上傳時間等欄位，然繼而寫入到Kafka消息隊 列中，然後返回給客戶處理結果。這個過程不需要客戶端等待處理過程，需要我們團隊進行優化，優化後的邏輯是客戶端上傳成功後即返回。我們之前的服務端是用 C++編寫的，我們直接參考一些秒殺的高並發架構進行了優化，在選擇了Nginx+Lua後，在沒有數據丟失的情況下，單節點每秒並發處理完成數提高了5 倍多。

2）數據處理流使用的是多java進程方式

我們在第一次架構過程中，對於各個子業務處理的都是獨立的java程序進行數據消費和處理，由於這種方式不利於我們後續的業務擴展和運維管理，有很大的隱患，我們將其改成了通過Samza平台的處理過程。選擇Samza的主要原因是，處理的輸入輸出都是Kafka，並且Samza的實時性也有保證。

3）數據倉庫不具有可伸縮性

我們的資料庫選型一開始用的是Infobright 的社區版，國內之前使用Infobright作為數據倉庫的比較有名的公司是豆瓣，雖然Infobright不是分散式的，我們考慮到大多數App或者網 站的DAU不會超過百萬，並且Infobright的壓縮和性能都不錯，對於我們這種SaaS的早期創業公司而言，成本也會有保障。當我們的數據越來越大 的時候，加了控制路由，會分發不同應用到不同的Infobright中。但是隨著我們業務發展的逐步突破越來越多的百萬甚至千萬DAU的產品找到我們，我 們還是要解決查詢性能和數據擴展的問題 。

從數據存儲可擴展性和計算資源的分散式調用來綜合考慮，我們選擇了Greenplum平台。

3.我們在數據處理上也做了一些技巧，包含兩部分：

圖5

1）預計算。對於互聯網用戶分析，大多數是分析特定行為，特定類型（新增/活躍），特定平台（Android/iOS/JS），特定渠道的用戶，所以這裡其實有一些集合計演算法則和技巧可以利用，我們基於這個寫了一個數據預處理的服務諸葛PreAg

2） 模型優化——業務維度分層。很多人在設計模型是過於去找邏輯對等以及對象關係，但是其實從應用場景來看，比如同是環境的維度或者同是業務的維度，其實在查詢場景上並不是同頻率的，有的時候為了一些極少數出現的複雜查詢我們做了過度的抽象設計，這一點我們做了很多的優化。

結合上面的問題，我們並進行了第一次架構調整。

圖6

架構V2比第一次架構更合理。除了上面提到的，我們把中間不易擴展的部分都替換成了一些支持分散式的技術組件和框架，比如Redis和SSDB我們都換成了Codis，比如文件我們換成了S3/HDFS

以上是我們前兩次架構的經驗分享，我們現在在進行第三次架構優化的過程中。這一次更多是業務領域的突破和延伸，在過去一年中，我們感受到了一個SaaS 公司面臨的各種挑戰—不同於私有部署的資源分散。SaaS公司滿足業務的同時也需要保障服務質量，任何一個小的更新和優化都需要多方面的檢查。上面提到的 只是一些我覺得能結合業務有共性的優化問題，我們團隊其實遇到的問題遠遠不止於此。底層技術上，從一開始底層硬碟的存儲優化，到系統參數調優，包括上傳服 務器、數據倉庫等底層涉及到的系統參數，如連接優化，UDP/TCP 連接優化等，再到開源平台的參數和配置測試和調優，例如Kafka的分區調整/參數配置，Greenplum的資源隊列，內存資源參數，查詢參數的測試優 化等，這些也希望大家在自己的架構設計和實踐中不要忽視，要多去結合自有的機器類型（IDC或者雲機器），機器配置，業務需要進行調整，後續我們也會有各 自負責的工程師給大家分享他們的經驗。

諸葛io 已經走過了一年有餘，目前有10,000+註冊企業，其中有百餘家付費客戶。我們正在為互聯網行業中的電商、金融、社交、內容、工具等多個領域提供用戶行 為分析的解決方案。光明牛奶隨心訂、優信二手車、羅輯思維、墨跡天氣、ENJOY、在行分答、暴漫、TheOne智能鋼琴等諸多優秀企業都在通過諸葛 io，去探索用戶特性，挖掘用戶價值。當然，我們還是一個初創的企業，技術上我們有過往的經驗，同時也希望能得到大家相關經驗指導和分享，需要更多的各種熱愛技術的小夥伴加入我們，與我們一同成長，我的郵箱是km@zhugeio.com。如果有興趣，環境加入我們，隨時應對更多的挑戰。

_______________________________________________________________________

諸葛io是國內領先的數據智能決策平台，致力於讓企業快速實現用戶行為數據的採集、分析與管理。諸葛io擁有用戶行為畫像、流失人群分析、行為路徑圖譜等多項功能，深度挖掘用戶價值、提升企業分析效率。

點擊進入諸葛io官網，可查看詳情

如需轉載，請聯繫諸葛io微信公號（ID：zhugeio），並註明出處。