面向數據智能時代的大數據架構實踐

諸葛io 在上線的不到 20 個月里，經歷了客戶量從 0 到 10,000 的突破，月有效行為數據處理量超過了 100 億。這期間，其研發團隊面臨過許多難題與挑戰，同時，對于大數據平臺的發展與架構也有許多的思考與沉淀。這些思考與實踐，正是本文中要與大家分享的內容。

第一部分：大數據平臺的三次浪潮

在正文開始之前，我們回顧一下 1990 年到 2016 年間，大數據平臺經歷的三次浪潮。

第一波浪潮

第一波浪潮起源于 90 年代，當時從計算機到軟件大多還是企業級的，而數據分析就已經開始。

這個時代還是集中式軟件時代，存儲數據的成本非常昂貴，所以大部分企業以 KPI 角度，抽取少量結構化數據進行數據分析。代表企業如 MicroStrategy、Microsoft、Oracle，代表產品也諸如 Sybase、Congos，這個時代能產生的數據有限，能處理數據的能力有限。

第二波浪潮

發展到 2000 年左右，互聯網的興起帶動計算機和軟件走向消費級，并且互聯網成為基礎設施，從以下三點帶來數據的爆發式增長。

• 網絡帶寬的升級優化，從 2G 到 4G，從撥號上網到光纖入戶；
• 圍繞互聯網信息化帶來大量的數據產生，例如門戶網站、社交平臺、內容和視頻平臺等等；
• 科技發展，從 PC 到移動設備到各種智能設備，都可以采集、傳輸數據。

數據的存儲成本越來越低，數據的產生速度越來越快，數據量越來越大，第一波浪潮時的技術體系已經滿足不了需求，并且由于摩爾定律基礎硬件設備和條件也在優化，處理數據的能力越來越強，這個時候帶來了大數據平臺第二波浪潮的發展。

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

1. 越來越分散的數據需要集中采集處理

數據采集集中大多是quot;Pullquot;和quot;Pushquot;兩種方式，但是收集方式、可擴展性、收集效率、消息隊列等等都需要一些突破。

2. 計算的可擴展性

機器資源已經不是瓶頸了，所以如何能分布式計算，把計算的復雜度分散拆解是要解決的核心問題，比如算法上的quot;多項式拆分quot;到計算框架上的quot;批處理quot;

3. 存儲的可擴展性

越來越大量的數據，導致效率越來越底下，所以為了保障訪問和利用效率，可靈活擴展存儲數據也是要解決的問題。

這個階段的大數據技術，陸續誕生了從 Facebook 早期開源的 Scribe、Cloudera 的 Flume、Linkedin 的 Kafka，還有后來的 Flink 等數據流處理框架，熟知的還有 Spark/Storm/Samza 等實時處理技術。

在這個階段似乎無人不提大數據，人人都喊 Hadoop，但是我們做到的是 數據流處理和實時處理以及存儲方式的突破和革新，而分析主體還是老的分析中心化方式 ，由 BI 團隊或者數據團隊驅動，集中式的制定 KPI，數據采集集中之后會按照 KPI 進行處理展現，如果遇到多樣化或者探索性的業務分析需求，還需要 On-Demand（按需）去編寫程序或者 SQL 來基于這些大數據平臺獲取結果。

第三波浪潮

發展到 2010 左右，互聯網發展也從信息化走向服務化，創業方向也從之前的quot;門戶時代quot;、“社交時代”、“垂直化門戶時代”、quot;內容視頻時代quot;走向了電商、出行、外賣、O2O 等本地服務升級。

如果說面向信息化的時代更多的是基于流量廣告的商業模式，面向服務化的時代更多的是直接面對客戶價值變現的商業模式，或者說消費者服務，所以從行業發展來看，服務類對分析的需求也要旺盛更多， 自古以來，電商游戲行業分析都做得比較好，不是嗎？

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

當外部沒有更多水源進入，并且四處的水源有限時，企業需要的是盡可能修復木桶，并且找到木桶的短板。在 2014 到 2015 年左右，互聯網流量紅利也初現消盡之勢，國內的經濟下行壓力也逐漸增大，就好比水源有限一樣，企業需要更多的分析自身原因，提高各種轉化率，增加用戶的忠誠度和黏性，減少用戶流失。所以分析需求開始逐步提升，各個業務部門都需要自我分析優化成本，提高利潤和產出。

過去企業更多面臨的是由上而下的 KPI 中心化式分析，所以形成的是分析中心化的體系，基本上整個公司有統一關注的指標和數據看板，但是各業務部門的分析就需要單獨處理了。

數據分析其實從行業、角色、部門以及從場景而言，都是差異化的。

行業上：

• 電商關注的是購買相關；
• 內容關注的是閱讀相關；
• 社交關注的是參與度相關；
• 工具關注的是使用情況。

角色上：

• CEO 肯定關注的是整體、財務各部門的 KPI；
• 市場 VP 肯定是營銷相關的子項目 KPI；
• 銷售 VP 關注的是銷售階段狀態和結果相關的指標。

部門上：

• 市場關注的是投放轉化率等指標；
• 產品關注的是功能留存率等指標。

所以要更充分的滿足分析需求，就需要從 KPI 中心化分析轉向分析去中心化，也就面臨著又一次大數據平臺的技術革新，這也推動了大數據平臺第三波浪潮的變革。

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

• 分析其實是行業經驗的積累和行業經驗的信息不對稱；
• 大多數公司缺少專業分析經驗的人和能構建數據分析平臺的團隊；
• 依賴數據分析團隊集中分析的方式效率低下，需求會排隊。

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

第三波分析浪潮帶來了一個 DI 的概念，就是數據智能，不同于 BI 的是，BI 更關注基于業務收集數據、處理數據的過程，而 DI 更多關注的是數據對各個業務部門的決策驅動和應用。

第三波浪潮下的大數據平臺，會從分析看板開始，有各個行業下各個業務部門所關注的指標，并且業務人員可以靈活的配置，同時對于復雜分析下鉆和數據探索過程而言，業務人員也無需 SQL 或者代碼就可以直接通過交互式的查詢組件進行自助式分析和配置。

大數據分析的基礎技術已經逐漸成熟，而挑戰就是基于行業理解下構建合理的數據模型，以及多維下復雜查詢的效率。

第二部分：諸葛io 的業務架構實踐

先自下而上再來看一下我們當前諸葛主要的業務架構：

1. 數據采集端

諸葛io 現在提供了 Android、iOS、JS 等 SDK 和 REST 的 HTTP 接口來采集數據，SDK 和接口都提供一些面向用戶的方法或者數據規范，其分析的數據主要來于此。

2. 數據接收服務

SDK 和接口采集到的數據會發給網關服務， 通過 API 對數據進行簡單加工，添加一些環境信息的字段之后，發給消息隊列。

3. 消息隊列

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

4. 多業務處理

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

• 實時統計

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

• 數據倉庫

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

• 數據索引

  為了提高數據查詢和檢索的效率，需要對一些維度數據生成索引，會寫入到索引數據庫中。

• 數據備份

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

5. 數據訪問層

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

6. 數據應用系統

數據應用主要包括以下：

• 諸葛io 網站

  網站就是 zhugeio.com 提供給企業客戶交互式自助分析的平臺，包括了豐富的功能。

• 內部服務

  主要是 DevOps 和業務監控平臺需要調用一些接口進行狀態監控和跟蹤，保障服務質量和穩定性。

• 數據挖掘

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

• • 流失與預測分析
    • 行業模型和看板
    • 自動化的分析報告
    • 用戶行為路徑挖掘

• 開放 API

  把一些查詢封裝成 API ，允許客戶進行二次開發或者調用。

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

架構永遠是貼合業務的，從 2014 年 10 月開始研發，15 年 3 月份上線。當時需要讓產品快速上線，驗證想法，所以架構搭的比較簡單粗暴。6 個工程師，完成了整套從數據采集到數據處理到網站到前端可視化的大數據架構。所以當時畫的比較簡單的架構如下：

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

初次上線的架構在剛開始的一段時間內沒有碰到什么問題。但是隨著業務發展，諸葛io 的客戶量逐步增加，甚至像暴走漫畫、小影、墨跡天氣等大體量的客戶也陸續接入平臺，這個時候考驗就來了。

下圖是我們當時數據處理流的架構圖，標出了三個問題點：

諸葛io 第一次上線的數據處理流

1. 數據上傳延時很高。

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

• HTTPS 建立連接和加密驗證的耗時。

  HTTPS 比普通的 HTTP 的三次握手還要多一個 SSL 驗證的過程，我們上線時使用的是比較老的 Nginx，并且只有單 Nginx 的支撐，所以握手壓力就會很大，所以雖然在系統參數調優上做了很多嘗試，但是本質還是需要一次架構優化，所以選擇了在 Nginx 前加了一個 LVS，把 Nginx 升級到最新版，并且支持了 HTTP2 的協議，并且擴展了 Nginx 的服務器數量。

• 數據上傳模塊的設計缺陷。

  諸葛io 之前的數據上傳模塊邏輯是：客戶端上傳數據，服務端接收后會解壓并且加入一些上傳 IP、上傳時間等字段，然后寫入到 Kafka 消息隊列中，然后返回給客戶處理結果。

其實這個過程是沒必要客戶端等待處理過程的，所以優化后的邏輯就是客戶端上傳成功后即返回。諸葛io 之前的服務端是 C 編寫，優化后直接參考一些秒殺的高并發架構，選擇了 Nginx Lua，在無數據丟失情況下，單節點每秒并發處理完成數提高了 5 倍多。

2. 數據處理流使用的是多JAVA進程方式

諸葛io 在第一次架構過程中，對于各個子業務處理的都是獨立的 JAVA 程序進行數據消費和處理，顯然這種方式不利于后續的業務擴展和運維管理，有很大的隱患，所以改成了通過 Samza 平臺的處理過程，選擇 Samza 的主要原因是，處理的輸入輸出都是 Kafka，并且 Samza 的實時性也有保證。

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

諸葛io 的數據庫選型一開始用的是 Infobright 的社區版，國內之前使用 Infobright 作為數據倉庫的比較有名的公司是豆瓣，雖然 Infobright 不是分布式的，考慮到大多數 App 或者網站的 DAU 不會超過百萬，并且 Infobright 的壓縮和性能都不錯，對于 SaaS 的早期創業公司而言，成本也會有保障。當數據越來越大的時候，加了控制路由，會分發不同應用到不同的 Infobright 中。

但是隨著業務發展的逐步突破越來越多的百萬甚至千萬 DAU 的產品開始使用時，自身還是要解決查詢性能和數據擴展的問題 。

從數據存儲可擴展性和計算資源的分布式調用來綜合考慮，諸葛io 選擇了 Greenplum 平臺。

同時諸葛io 在數據處理上也做了一些技巧，包含兩部分：

1. 預計算

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

2. 模型優化–業務維度分層

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

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

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

寫在最后

上面是前兩次架構的經驗分享，諸葛io 現在也在第三次架構優化的過程中，這一次更多是業務領域的突破和延伸。

在過去一年中，作為一個 SaaS 公司，諸葛io 面臨著各種挑戰，不同于私有部署的資源分散，SaaS 公司滿足業務的同時也需要保障服務質量，任何一個小的更新和優化都需要多方面的檢查和合適。上面提到的只是一些能結合業務有共性的優化的問題，團隊其實遇到的問題要遠遠不止于此。

底層技術上，從一開始底層硬盤的存儲優化，到系統參數調優，包括上傳服務器、數據倉庫等底層涉及到的系統參數，如連接優化，UDP/TCP 連接優化等等，再到開源平臺的參數和配置測試和調優，例如 Kafka 的分區調整/參數配置，Greenplum 的資源隊列，內存資源參數，查詢參數的測試優化等等。這些也希望大家在自己的架構設計和實踐中不要忽視，要多去結合自有的機器類型（IDC 或者云機器），機器配置，業務需要進行調整。

• FIN-