前言：想要寫一篇關(guān)于大數(shù)據(jù)平臺的發(fā)展變革，以及諸葛io自身架構(gòu)演變的文章，是因為在諸葛io上線的20個月里，我們經(jīng)歷了客戶量從0到10,000的突破。今天，諸葛io作為新一代數(shù)據(jù)分析平臺，累計了過萬的企業(yè)用戶，每月活躍客戶數(shù)2000+家，月有效行為數(shù)據(jù)處理量超過了100億。期間，我們的研發(fā)團隊面臨過許多難題與挑戰(zhàn)，同時，對于大數(shù)據(jù)平臺的發(fā)展與架構(gòu)也有更多的思考與沉淀。這些思考與實踐，正是本文中將要和大家分享的內(nèi)容。

一.大數(shù)據(jù)平臺的三次浪潮

在討論諸葛io這樣的新一代數(shù)據(jù)分析平臺之前，我們可以回顧一下1990年到2016年間，大數(shù)據(jù)平臺經(jīng)歷的三次浪潮。

1.第一波浪潮

第一波浪潮起源于90年代，當(dāng)時從計算機到軟件大多還是企業(yè)級的，而數(shù)據(jù)分析就已經(jīng)開始，這個時代也還是集中式軟件時代，存儲數(shù)據(jù)的成本也非常昂貴，所以大部分企業(yè)以KPI角度，抽取少量結(jié)構(gòu)化數(shù)據(jù)，采取特定數(shù)據(jù)。代表企業(yè)如MicroStrategy、Microsoft、Oracle，代表產(chǎn)品諸如Sybase、Congos。這個時代能產(chǎn)生的數(shù)據(jù)有限，能處理數(shù)據(jù)的能力有限。

圖1

2.第二波浪潮

發(fā)展到2000年左右，互聯(lián)網(wǎng)的興起，帶動了計算機和軟件從工具型走向消費級，由于互聯(lián)網(wǎng)基礎(chǔ)設(shè)施的發(fā)展，以下三點帶來了數(shù)據(jù)的爆發(fā)式增長。

1) 網(wǎng)絡(luò)帶寬的升級優(yōu)化，從2g到4g，從撥號上網(wǎng)到光纖入戶。

2) 圍繞互聯(lián)網(wǎng)信息化帶來大量的數(shù)據(jù)產(chǎn)生，如門戶網(wǎng)站，社交平臺，內(nèi)容和視頻平臺等。

3) 科技發(fā)展，從PC到移動設(shè)備到各種智能設(shè)備，都可以采集傳輸數(shù)據(jù)。

數(shù)據(jù)的存儲成本越來越低，數(shù)據(jù)的產(chǎn)生速度越來越快，數(shù)據(jù)量越來越大，第一波浪潮時的技術(shù)體系無法滿足需求，并且由于摩爾定律基礎(chǔ)硬件設(shè)備和條件也在優(yōu)化，處理數(shù)據(jù)的能力越來越強，此時帶來了大數(shù)據(jù)平臺第二波浪潮的發(fā)展:

圖2

面臨這樣的環(huán)境趨勢，第二波浪潮需要解決的核心技術(shù)問題包括三方面：

1) 越來越分散的數(shù)據(jù)需要集中采集處理

數(shù)據(jù)采集集中大多是“Pull”和“Push”兩種方式，由于收集方式，可擴展性，收集效率，消息隊列等都需要一些突破。

2) 計算的可擴展性

機器資源已經(jīng)不是瓶頸。如何能分布式計算，把計算的復(fù)雜度分散拆解是核心要解決的問題，比如算法上的“多項式拆分”到計算框架上的“批處理”

3) 存儲的可擴展性

越來越大量的數(shù)據(jù)，如果只是本地文件存儲或者數(shù)據(jù)庫存儲，效率越來越低下，所以保障訪問和提高效率，可以靈活擴展存儲數(shù)據(jù)也是要解決的問題。

大數(shù)據(jù)技術(shù)在這個階段陸續(xù)誕生了從Facebook早期開源的Scribe到Cloudera的Flume，到Linkedin的Kafka，以及后來的Flink等數(shù)據(jù)流處理框架，熟知的還有Spark/Storm/Samza等實時處理技術(shù)。這個階段，很多人都在提大數(shù)據(jù)和Hadoop，但是我們做到的是數(shù)據(jù)流處理和實時處理以及存儲方式的突破和革新，分析主體是分析中心化方式。由BI團隊或者數(shù)據(jù)團隊驅(qū)動，集中式的制定KPI，數(shù)據(jù)采集集中之后會按照KPI進行處理展現(xiàn)。如果遇到多樣化或者探索性的業(yè)務(wù)分析需求，還需要on-demand(按需)去編寫程序或者SQL來基于這些大數(shù)據(jù)平臺獲取結(jié)果。

3.第三波浪潮

發(fā)展到2010左右，互聯(lián)網(wǎng)發(fā)展從信息化走向了服務(wù)化，創(chuàng)業(yè)方向也從之前的“門戶時代”、“社交時代”，“垂直化門戶時代”，“內(nèi)容視頻時代”走向了電商、出行、外賣、O2O等本地服務(wù)。如果說面向信息化的時代更多的是基于流量廣告等商業(yè)模式，面向服務(wù)化時代更多的是直接面對客戶價值的變現(xiàn)商業(yè)模式，或者說消費者服務(wù)，所以從行業(yè)發(fā)展來看，服務(wù)類對分析的需求也要旺盛很多。

我們可以用破木桶蓄水過程來類比，到處都是水源的時候，并且外部水源流入率大于自身流失率的時候，更多的思考的是抓緊圈水源而不是找短板。從2000年到2014年，流量勢頭猛進，到處都是用戶，對于企業(yè)而言更多的思考是如何圈用戶，而不是如何留住用戶并去分析流失原因。

當(dāng)外部沒有更多水源進入并且四處水源有限的時候，我們需要的是盡可能修復(fù)木桶，并且找到木桶的短板。在2014到2015年之間，互聯(lián)網(wǎng)流量紅利也初現(xiàn)消退之勢，國內(nèi)的經(jīng)濟下行壓力也逐漸增大，就好比水源有限一樣，企業(yè)更多的需要分析自身原因了，去提高各種轉(zhuǎn)化率，增加用戶的忠誠度和黏性，減少用戶的流失。因此分析需求開始逐步提升，各個業(yè)務(wù)部門也都需要自我分析優(yōu)化成本，提高產(chǎn)出和利潤。

過去企業(yè)更多面臨的是由上而下的KPI中心化式分析，形成了分析中心化體系，基本上整個公司有統(tǒng)一關(guān)注的指標(biāo)和數(shù)據(jù)看板，但是各業(yè)務(wù)部門的分析需要單獨處理。

數(shù)據(jù)分析從行業(yè)、角色、部門和場景而言，都是差異化的。比如行業(yè)上，電商關(guān)注的是購買相關(guān)指標(biāo)，內(nèi)容關(guān)注的是閱讀相關(guān)指標(biāo)，社交關(guān)注的是參與度相關(guān)指標(biāo)，工具關(guān)注的是功能使用情況。角色上，CEO關(guān)注的是整體、財務(wù)各部門的KPI;市場VP關(guān)注的是營銷相關(guān)的子項目KPI;銷售VP關(guān)注的是銷售階段狀態(tài)和結(jié)果相關(guān)的指標(biāo);如部門上，市場關(guān)注的是投放轉(zhuǎn)化率等指標(biāo);產(chǎn)品關(guān)注的是功能留存率等指標(biāo)。如果要更充分的滿足分析需求，需要從KPI中心化分析轉(zhuǎn)向分析去中心化，也就面臨著又一次大數(shù)據(jù)平臺的技術(shù)革新，也因此推動了大數(shù)據(jù)平臺第三波浪潮的變革。

第一第二波浪潮更多解決的還是技術(shù)問題，第三波浪潮最重要的是要解決分析問題，但是分析的問題主要有三點：

1) 分析由于行業(yè)經(jīng)驗的積累和行業(yè)經(jīng)驗的信息不對稱而誕生

2) 大多數(shù)公司缺少專業(yè)分析經(jīng)驗的人和能構(gòu)建數(shù)據(jù)分析平臺的團隊

3) 依賴數(shù)據(jù)分析團隊集中分析的方式效率低下，需求排隊。

所以也就意味著第三波浪潮帶來的更多不是通用的技術(shù)平臺，而是更多深入的行業(yè)分析應(yīng)用，所以在數(shù)據(jù)模型和數(shù)據(jù)倉庫這一層的變革會更大，當(dāng)然少不了的還是Google這樣大鱷的弄潮，開源了BigTable帶來的是以Hadoop為核心的第二波浪潮興起，而Google的BigQuery是第三波浪潮的代表。

圖3

第三波浪潮帶來了一個新的概念——DI(數(shù)據(jù)智能)。不同于BI的是：DI關(guān)注的是數(shù)據(jù)對各個業(yè)務(wù)部門的決策驅(qū)動和應(yīng)用，而BI關(guān)注的是基于業(yè)務(wù)收集數(shù)據(jù)處理數(shù)據(jù)的過程。

第三波浪潮下的大數(shù)據(jù)平臺，會從分析看板開始，有各個行業(yè)下各個業(yè)務(wù)部門所關(guān)注的指標(biāo)，并且業(yè)務(wù)人員可以靈活的配置，同時對于復(fù)雜的分析下鉆和數(shù)據(jù)探索的過程而言，業(yè)務(wù)人員也無需SQL或者代碼，可以直接通過交互式的查詢組件進行自助式分析和配置。大數(shù)據(jù)分析的基礎(chǔ)技術(shù)已經(jīng)逐漸成熟，而挑戰(zhàn)就是基于行業(yè)理解下構(gòu)建合理的數(shù)據(jù)模型，以及多維下復(fù)雜查詢的效率。

諸葛io就是在第三波浪潮下誕生的一款數(shù)據(jù)分析產(chǎn)品，最大的特點就是快速直接給各個業(yè)務(wù)部門的人呈現(xiàn)他們需要的目標(biāo)，無需借助專業(yè)人士，指標(biāo)的可視化，一目了然。

二.諸葛io的業(yè)務(wù)架構(gòu)實踐

1.圖4自下而上是諸葛io當(dāng)前的主要業(yè)務(wù)架構(gòu)：

1)數(shù)據(jù)采集端

諸葛io現(xiàn)在提供了Android、iOS、JS等SDK和REST的Http接口來采集數(shù)據(jù)，SDK和接口都提供一些面向用戶的方法或者數(shù)據(jù)規(guī)范，我們分析的數(shù)據(jù)主要來于此。

2) 數(shù)據(jù)接收服務(wù)

SDK和接口采集到的數(shù)據(jù)會發(fā)給我們的網(wǎng)關(guān)服務(wù)，我們的API會對數(shù)據(jù)進行簡單加工，添加一些環(huán)境信息的字段之后，發(fā)給我們的消息隊列。

3) 消息隊列

消息隊列會成為數(shù)據(jù)的集中處理中心，我們對消息會進行統(tǒng)一的加工轉(zhuǎn)換和清洗，比如過濾垃圾數(shù)據(jù)，關(guān)聯(lián)用戶的id，加工用戶的狀態(tài)和標(biāo)簽，加工行為數(shù)據(jù)等。

4) 多業(yè)務(wù)處理

數(shù)據(jù)進行統(tǒng)一的加工和處理完成之后，我們會有多個服務(wù)同時消耗和處理基礎(chǔ)數(shù)據(jù)。主要包括以下部分：

a. 實時統(tǒng)計

為了減少對數(shù)據(jù)倉庫的壓力以及提高數(shù)據(jù)處理的效率，對于一些基礎(chǔ)指標(biāo)，比如新增、活躍、觸發(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ù)會做多重備份，達(dá)到一定程度的災(zāi)難恢復(fù)保障，會寫入到文件中。

5) 數(shù)據(jù)訪問層

我們會由統(tǒng)一的數(shù)據(jù)訪問層來輸出數(shù)據(jù)，給應(yīng)用層進行調(diào)用。這一層我們會封裝一些分析模型和業(yè)務(wù)邏輯，數(shù)據(jù)訪問層會分為內(nèi)部接口和外部接口進行分發(fā)。

6) 數(shù)據(jù)應(yīng)用系統(tǒng)

我們的數(shù)據(jù)應(yīng)用主要包括以下部分：

a. 諸葛io網(wǎng)站

網(wǎng)站是zhugeio.com 提供給企業(yè)客戶交互式自助分析的平臺，包括了豐富的功能

b. 內(nèi)部服務(wù)

主要是DevOps和業(yè)務(wù)監(jiān)控平臺需要調(diào)用一些接口進行狀態(tài)監(jiān)控和跟蹤，保障服務(wù)質(zhì)量以及穩(wěn)定性。

c. 數(shù)據(jù)挖掘

諸葛io有算法組和分析組兩支隊伍對數(shù)據(jù)進行一些復(fù)雜的挖掘和分析，包括：

i) 用戶行為路徑挖掘

ii) 行業(yè)模型和看板

iii) 流失和預(yù)測分析

iv) 自動化的分析報告

d. 開放API

我們提供給客戶的不僅僅是匯總統(tǒng)計的數(shù)據(jù)，還允許用戶直接訪問和導(dǎo)出自己的原始數(shù)據(jù)和加工后的數(shù)據(jù)，因此我們把一些查詢封裝成了API的邏輯，允許客戶進行二次開發(fā)或者調(diào)用，所以我們有一個開放的API平臺。

圖4

諸葛io的架構(gòu)經(jīng)歷了兩次迭代，目前正在進行第三次的重構(gòu)。我們重構(gòu)的目的包含兩方面：第一次重構(gòu)主要是技術(shù)方案的瓶頸突破，第二次重構(gòu)主要是業(yè)務(wù)領(lǐng)域問題的延伸和拓展。

架構(gòu)永遠(yuǎn)是貼合業(yè)務(wù)的。諸葛io是新一代分析平臺里面最早上線的。我們從2014年10月開始研發(fā)，上線于 15年3月份。當(dāng)時，我們需要讓產(chǎn)品快速上線，驗證想法，所以架構(gòu)搭建的比較簡單。包括我在內(nèi)的6個工程師，完成了整套從數(shù)據(jù)采集到數(shù)據(jù)處理到網(wǎng)站到前端可視化的大數(shù)據(jù)架構(gòu)。由于我們的研發(fā)團隊在大數(shù)據(jù)領(lǐng)域經(jīng)驗比較豐富，能解決各種技術(shù)難題。當(dāng)時我們搭建的簡單架構(gòu)如圖5：

圖5：諸葛io第一次上線的架構(gòu)實踐

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

2.下圖是我們第一次上線架構(gòu)數(shù)據(jù)處理流的架構(gòu)圖，標(biāo)出了三個問題點：

圖6：諸葛io第一次上線的數(shù)據(jù)處理流:

1) 數(shù)據(jù)上傳延時高。

上傳延時很高主要有兩方面：

a. HTTPS建立連接和加密驗證過于耗時

HTTPS比普通的Http的三次握手多一個SSL驗證過程，我們第一次上線使用的是比較老的Nginx，并且只有單Nginx的支撐，握手壓力過大。雖然我們在系統(tǒng)參數(shù)調(diào)優(yōu)上做了很多嘗試，但是本質(zhì)還是需要一次架構(gòu)優(yōu)化，因此選擇了在Nginx前加了一個LVS，把Nginx升級到最新版，并且支持了HTTP2的協(xié)議，擴展了Nginx的服務(wù)器數(shù)量。

b. 數(shù)據(jù)上傳模塊的設(shè)計缺陷

諸葛io之前的數(shù)據(jù)上傳模塊邏輯是：客戶端上傳數(shù)據(jù)到服務(wù)端，服務(wù)端接收后會解壓并且加入一些上傳的IP、上傳時間等字段，然繼而寫入到Kafka消息隊列中，然后返回給客戶處理結(jié)果。這個過程不需要客戶端等待處理過程，需要我們團隊進行優(yōu)化，優(yōu)化后的邏輯是客戶端上傳成功后即返回。我們之前的服務(wù)端是用C++編寫的，我們直接參考一些秒殺的高并發(fā)架構(gòu)進行了優(yōu)化，在選擇了Nginx+Lua后，在沒有數(shù)據(jù)丟失的情況下，單節(jié)點每秒并發(fā)處理完成數(shù)提高了5倍多。

2)數(shù)據(jù)處理流使用的是多java進程方式

我們在第一次架構(gòu)過程中，對于各個子業(yè)務(wù)處理的都是獨立的java程序進行數(shù)據(jù)消費和處理，由于這種方式不利于我們后續(xù)的業(yè)務(wù)擴展和運維管理，有很大的隱患，我們將其改成了通過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è)公司而言，成本也會有保障。當(dāng)我們的數(shù)據(jù)越來越大的時候，加了控制路由，會分發(fā)不同應(yīng)用到不同的Infobright中。但是隨著我們業(yè)務(wù)發(fā)展的逐步突破越來越多的百萬甚至千萬DAU的產(chǎn)品找到我們，我們還是要解決查詢性能和數(shù)據(jù)擴展的問題。

從數(shù)據(jù)存儲可擴展性和計算資源的分布式調(diào)用來綜合考慮，我們選擇了Greenplum平臺。

圖7

3.我們在數(shù)據(jù)處理上也做了一些技巧：包含兩部分：

圖8

1)預(yù)計算

對于互聯(lián)網(wǎng)用戶分析，大多數(shù)是分析特定行為，特定類型(新增/活躍)，特定平臺(Android/iOS/JS)，特定渠道的用戶，所以這里其實有一些集合計算法則和技巧可以利用，我們基于這個寫了一個數(shù)據(jù)預(yù)處理的服務(wù)諸葛PreAg

2) 模型優(yōu)化——業(yè)務(wù)維度分層

很多人在設(shè)計模型是過于去找邏輯對等以及對象關(guān)系，但是其實從應(yīng)用場景來看，比如同是環(huán)境的維度或者同是業(yè)務(wù)的維度，其實在查詢場景上并不是同頻率的，有的時候為了一些極少數(shù)出現(xiàn)的復(fù)雜查詢我們做了過度的抽象設(shè)計，這一點我們做了很多的優(yōu)化。

結(jié)合上面的問題，我們并進行了第一次架構(gòu)調(diào)整。

圖9

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

以上是我們前兩次架構(gòu)的經(jīng)驗分享，我們現(xiàn)在在進行第三次架構(gòu)優(yōu)化的過程中。這一次更多是業(yè)務(wù)領(lǐng)域的突破和延伸，在過去一年中，我們感受到了一個SaaS公司面臨的各種挑戰(zhàn)—不同于私有部署的資源分散。SaaS公司滿足業(yè)務(wù)的同時也需要保障服務(wù)質(zhì)量，任何一個小的更新和優(yōu)化都需要多方面的檢查。上面提到的只是一些我覺得能結(jié)合業(yè)務(wù)有共性的優(yōu)化問題，我們團隊其實遇到的問題遠(yuǎn)遠(yuǎn)不止于此。底層技術(shù)上，從一開始底層硬盤的存儲優(yōu)化，到系統(tǒng)參數(shù)調(diào)優(yōu)，包括上傳服務(wù)器、數(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)化等，這些也希望大家在自己的架構(gòu)設(shè)計和實踐中不要忽視，要多去結(jié)合自有的機器類型(IDC或者云機器)，機器配置，業(yè)務(wù)需要進行調(diào)整。

作者介紹

孔淼，前 37degree CTO，畢業(yè)于華中科技大學(xué)軟件工程專業(yè)。曾受邀擔(dān)任李開復(fù)博士的技術(shù)助理，負(fù)責(zé)處理工場各部門以及李開復(fù)的技術(shù)需求。后加入 37degree 團隊開始創(chuàng)業(yè)。在 37degree 期間，曾帶領(lǐng)團隊服務(wù)過 CCTV、海爾、寶馬等知名企業(yè)。2014 年底，孔淼開始打造諸葛 io，目前正在為 Intel、聯(lián)想、光明乳業(yè)、墨跡天氣、羅輯思維、在行、暴走漫畫等 9000+ 企業(yè)提供數(shù)據(jù)智能分析服務(wù)?？醉当焕铋_復(fù)博士欽點為「最具潛力的技術(shù)人才」，并獲評 2015 年創(chuàng)業(yè)邦「30 歲以下創(chuàng)業(yè)新貴」。-- 我們需要更多的各種熱愛技術(shù)的小伙伴加入我們，與我們一同成長，我的郵箱是 km@zhugeio.com

注：本文由 諸葛io 投稿數(shù)據(jù)猿發(fā)布。

歡迎更多大數(shù)據(jù)企業(yè)、愛好者投稿數(shù)據(jù)猿，來稿請直接投遞至：tougao@datayuan.cn

來源：數(shù)據(jù)猿