本文來自諸葛io創(chuàng)始人孔淼的《諸葛io避咆，面向數(shù)據(jù)智能時代的大數(shù)據(jù)實踐》之下篇—諸葛io的業(yè)務架構實踐查库。
在上篇「諸葛io，面向數(shù)據(jù)智能時代的大數(shù)據(jù)實踐（上）」适荣，我們講到大數(shù)據(jù)的三次浪潮下諸葛io是如何誕生的够吩，本文為諸葛io的業(yè)務架構實踐篇周循。
1．圖1自下而上是諸葛io當前的主要業(yè)務架構：
1）數(shù)據(jù)采集端
諸葛io現(xiàn)在提供了Android湾笛、iOS闰歪、JS等SDK和REST的Http接口來采集數(shù)據(jù)嚎研，SDK和接口都提供一些面向用戶的方法或者數(shù)據(jù)規(guī)范，我們分析的數(shù)據(jù)主要來于此库倘。
2） 數(shù)據(jù)接收服務
SDK和接口采集到的數(shù)據(jù)會發(fā)給我們的網(wǎng)關服務临扮，我們的API會對數(shù)據(jù)進行簡單加工，添加一些環(huán)境信息的字段之后教翩，發(fā)給我們的消息隊列杆勇。
3） 消息隊列
消息隊列會成為數(shù)據(jù)的集中處理中心，我們對消息會進行統(tǒng)一的加工轉換和清洗饱亿，比如過濾垃圾數(shù)據(jù)蚜退，關聯(lián)用戶的id闰靴，加工用戶的狀態(tài)和標簽，加工行為數(shù)據(jù)等。
4） 多業(yè)務處理
數(shù)據(jù)進行統(tǒng)一的加工和處理完成之后凡伊，我們會有多個服務同時消耗和處理基礎數(shù)據(jù)。主要包括以下部分：
a. ?實時統(tǒng)計蛹疯。為了減少對數(shù)據(jù)倉庫的壓力以及提高數(shù)據(jù)處理的效率，對于一些基礎指標，比如新增、活躍、觸發(fā)各種行為的人數(shù)等我們會進行實時統(tǒng)計，寫入到內(nèi)存數(shù)據(jù)庫中。
b. ? ?數(shù)據(jù)倉庫。數(shù)據(jù)倉庫是諸葛提供的深入用戶行為、多維交叉分析以及行業(yè)分析模型的核心狂魔，所以底層的數(shù)據(jù)模型和加工的中間數(shù)據(jù)層主要是在這一步完成籽孙，完成后會寫入到數(shù)據(jù)倉庫底層的數(shù)據(jù)庫中胎挎。
c. 數(shù)據(jù)索引。為了提高數(shù)據(jù)查詢和檢索的效率，我們會對一些維度數(shù)據(jù)生成索引，會寫入到索引數(shù)據(jù)庫中。
d. 數(shù)據(jù)備份。我們對原始上傳數(shù)據(jù)以及中間清洗后的數(shù)據(jù)會做多重備份，達到一定程度的災難恢復保障啤咽，會寫入到文件中。
5） 數(shù)據(jù)訪問層
我們會由統(tǒng)一的數(shù)據(jù)訪問層來輸出數(shù)據(jù)，給應用層進行調(diào)用。這一層我們會封裝一些分析模型和業(yè)務邏輯剃斧，數(shù)據(jù)訪問層會分為內(nèi)部接口和外部接口進行分發(fā)根蟹。
6） 數(shù)據(jù)應用系統(tǒng)
我們的數(shù)據(jù)應用主要包括以下部分：
a. 諸葛io網(wǎng)站蕉堰。網(wǎng)站是zhugeio.com 提供給企業(yè)客戶交互式自助分析的平臺，包括了豐富的功能约计。
b. 內(nèi)部服務筒占。主要是DevOps和業(yè)務監(jiān)控平臺需要調(diào)用一些接口進行狀態(tài)監(jiān)控和跟蹤，保障服務質(zhì)量以及穩(wěn)定性。
c. 數(shù)據(jù)挖掘屈扎。諸葛io有算法組和分析組兩支隊伍對數(shù)據(jù)進行一些復雜的挖掘和分析，包括：
i) ? 用戶行為路徑挖掘
ii) ? 行業(yè)模型和看板
iii) ?流失和預測分析
iv) 自動化的分析報告
d. 開放API哩牍。我們提供給客戶的不僅僅是匯總統(tǒng)計的數(shù)據(jù)纬朝，還允許用戶直接訪問和導出自己的原始數(shù)據(jù)和加工后的數(shù)據(jù)堂竟，因此我們把一些查詢封裝成了API的邏輯，允許客戶進行二次開發(fā)或者調(diào)用酣胀，所以我們有一個開放的API平臺刁赦。
諸葛io的架構經(jīng)歷了兩次迭代，目前正在進行第三次的重構闻镶。我們重構的目的包含兩方面：第一次重構主要是技術方案的瓶頸突破甚脉，第二次重構主要是業(yè)務領域問題的延伸和拓展。
架構永遠是貼合業(yè)務的铆农。諸葛io是新一代分析平臺里面最早上線的牺氨。我們從2014年10月開始研發(fā)，上線于 15年3月份墩剖。當時猴凹，我們需要讓產(chǎn)品快速上線，驗證想法岭皂，所以架構搭建的比較簡單郊霎，包括我在內(nèi)的6個工程師，完成了整套從數(shù)據(jù)采集到數(shù)據(jù)處理到網(wǎng)站到前端 可視化的大數(shù)據(jù)架構爷绘。由于我們的研發(fā)團隊在大數(shù)據(jù)領域經(jīng)驗比較豐富书劝，能解決各種技術難題进倍。當時我們搭建的簡單架構如圖2：
圖2：諸葛io第一次上線的架構實踐
初次上線的架構在剛開始的一段時間內(nèi)一切正常。隨著業(yè)務發(fā)展购对，諸葛io的客戶量逐步增加猾昆，如暴走漫畫、小影骡苞、墨跡天氣等大體量的客戶陸續(xù)接入平臺垂蜗，這個時候也面臨著諸多考驗。
2.圖3是我們第一次上線架構數(shù)據(jù)處理流的架構圖烙如，標出了三個問題點：
圖3：諸葛io第一次上線的數(shù)據(jù)處理流:
1）數(shù)據(jù)上傳延時高么抗。上傳延時很高主要有兩方面：
a. HTTPS建立連接和加密驗證過于耗時。HTTPS比普通的Http的三次握手多一個SSL驗證過程亚铁，我們第一次上線使用的是比較老的Nginx蝇刀，并且只有單Nginx的支撐，握手壓力過大徘溢。雖 然我們在系統(tǒng)參數(shù)調(diào)優(yōu)上做了很多嘗試吞琐，但是本質(zhì)還是需要一次架構優(yōu)化，因此選擇了在Nginx前加了一個LVS然爆，把Nginx升級到最新版站粟，并且支持了 HTTP2的協(xié)議，擴展了Nginx的服務器數(shù)量曾雕。
b. ?數(shù)據(jù)上傳模塊的設計缺陷奴烙。諸葛io之前的數(shù)據(jù)上傳模塊邏輯是：客戶端上傳數(shù)據(jù)到服務端，服務端接收后會解壓并且加入一些上傳的IP剖张、上傳時間等字段切诀，然繼而寫入到Kafka消息隊 列中，然后返回給客戶處理結果搔弄。這個過程不需要客戶端等待處理過程幅虑，需要我們團隊進行優(yōu)化，優(yōu)化后的邏輯是客戶端上傳成功后即返回顾犹。我們之前的服務端是用 C++編寫的倒庵，我們直接參考一些秒殺的高并發(fā)架構進行了優(yōu)化，在選擇了Nginx+Lua后炫刷，在沒有數(shù)據(jù)丟失的情況下擎宝，單節(jié)點每秒并發(fā)處理完成數(shù)提高了5 倍多。
2）數(shù)據(jù)處理流使用的是多java進程方式
我們在第一次架構過程中浑玛，對于各個子業(yè)務處理的都是獨立的java程序進行數(shù)據(jù)消費和處理认臊，由于這種方式不利于我們后續(xù)的業(yè)務擴展和運維管理，有很大的隱患锄奢，我們將其改成了通過Samza平臺的處理過程失晴。選擇Samza的主要原因是剧腻，處理的輸入輸出都是Kafka，并且Samza的實時性也有保證涂屁。
3）數(shù)據(jù)倉庫不具有可伸縮性
我們的數(shù)據(jù)庫選型一開始用的是Infobright 的社區(qū)版书在，國內(nèi)之前使用Infobright作為數(shù)據(jù)倉庫的比較有名的公司是豆瓣，雖然Infobright不是分布式的拆又，我們考慮到大多數(shù)App或者網(wǎng) 站的DAU不會超過百萬儒旬，并且Infobright的壓縮和性能都不錯，對于我們這種SaaS的早期創(chuàng)業(yè)公司而言帖族，成本也會有保障栈源。當我們的數(shù)據(jù)越來越大 的時候，加了控制路由竖般，會分發(fā)不同應用到不同的Infobright中甚垦。但是隨著我們業(yè)務發(fā)展的逐步突破越來越多的百萬甚至千萬DAU的產(chǎn)品找到我們，我 們還是要解決查詢性能和數(shù)據(jù)擴展的問題 涣雕。
從數(shù)據(jù)存儲可擴展性和計算資源的分布式調(diào)用來綜合考慮艰亮，我們選擇了Greenplum平臺。
3.我們在數(shù)據(jù)處理上也做了一些技巧挣郭，包含兩部分：
1）預計算迄埃。對于互聯(lián)網(wǎng)用戶分析，大多數(shù)是分析特定行為兑障，特定類型（新增/活躍）侄非，特定平臺（Android/iOS/JS），特定渠道的用戶流译，所以這里其實有一些集合計算法則和技巧可以利用逞怨，我們基于這個寫了一個數(shù)據(jù)預處理的服務諸葛PreAg
2） 模型優(yōu)化——業(yè)務維度分層。很多人在設計模型是過于去找邏輯對等以及對象關系先蒋，但是其實從應用場景來看，比如同是環(huán)境的維度或者同是業(yè)務的維度宛渐，其實在查詢場景上并不是同頻率的竞漾，有的時候為了一些極少數(shù)出現(xiàn)的復雜查詢我們做了過度的抽象設計，這一點我們做了很多的優(yōu)化窥翩。
結合上面的問題业岁，我們并進行了第一次架構調(diào)整。
架構V2比第一次架構更合理寇蚊。除了上面提到的笔时，我們把中間不易擴展的部分都替換成了一些支持分布式的技術組件和框架，比如Redis和SSDB我們都換成了Codis仗岸，比如文件我們換成了S3/HDFS
以上是我們前兩次架構的經(jīng)驗分享，我們現(xiàn)在在進行第三次架構優(yōu)化的過程中。這一次更多是業(yè)務領域的突破和延伸攀例，在過去一年中盗迟，我們感受到了一個SaaS 公司面臨的各種挑戰(zhàn)—不同于私有部署的資源分散。SaaS公司滿足業(yè)務的同時也需要保障服務質(zhì)量突倍，任何一個小的更新和優(yōu)化都需要多方面的檢查。上面提到的 只是一些我覺得能結合業(yè)務有共性的優(yōu)化問題，我們團隊其實遇到的問題遠遠不止于此低散。底層技術上，從一開始底層硬盤的存儲優(yōu)化骡楼，到系統(tǒng)參數(shù)調(diào)優(yōu)熔号，包括上傳服 務器、數(shù)據(jù)倉庫等底層涉及到的系統(tǒng)參數(shù)鸟整，如連接優(yōu)化引镊，UDP/TCP 連接優(yōu)化等，再到開源平臺的參數(shù)和配置測試和調(diào)優(yōu)吃嘿，例如Kafka的分區(qū)調(diào)整/參數(shù)配置祠乃，Greenplum的資源隊列，內(nèi)存資源參數(shù)兑燥，查詢參數(shù)的測試優(yōu) 化等亮瓷，這些也希望大家在自己的架構設計和實踐中不要忽視，要多去結合自有的機器類型（IDC或者云機器）降瞳，機器配置嘱支，業(yè)務需要進行調(diào)整。
