騰訊分析系統架構解析

版權聲明：本文由楚大鵬原創文章，轉載請註明出處: 
文章原文連接：https://www.qcloud.com/community/article/262

來源：騰雲閣 https://www.qcloud.com/community

 

TA（Tencent Analyticis，騰訊分析）是一款面向第三方站長的免費網站分析系統，是騰訊海量數據分析能力對外的開放。騰訊分析在數據穩定性、及時性方面廣受站長好評，其秒級的實時數據更新頻率達到業界領先水平。本文將從實時數據處理、數據存儲等多個方面帶您深刻探尋TA的系統架構及實現原理。

騰訊分析業務簡介

網站分析(Web Analytics)主要指的是基於網站的用戶瀏覽行爲，對網站的點擊流數據和運營數據進行分析，以監控網站的運營情況，爲網站的優化提供決策依據。網站分析系統已成爲站長平常運營必不可少的工具，業界比較流行的網站分析系統主要有Google Analytics、CNZZ、百度統計等產品。

騰訊分析做爲網站分析產品的後起之秀在社區分析、用戶畫像、網站工具等多個方面造成了本身的特點，尤爲TA的秒級的實時數據更新頻率更是業界翹楚，在數據穩定性、準確性、及時性方面TA在站長圈也是享有良好的口碑。

隨着接入業務量的不斷髮展，TA日均須要處理、計算的數據量達到T級。如此龐大的數據量想要達到秒級實時而且保證系統的高可用並不是是容易的事情。騰訊分析的實時計算框架借鑑了業界一些業界流行的流式計算系統，在構建系統中遇到的一些問題，之於海量數據的實時處理、實時存儲具有必定的典型性與通用性，故將騰訊分析的解決方案分享出來，但願能夠帶給你們一些啓示。

騰訊分析基本原理及系統架構

騰訊分析的基本原理是經過嵌入站長網站的JS腳本「打點」收集用戶訪問行爲數據，併發送騰訊分析採集集羣，採集集羣收到數據後將其過濾、編碼、格式化後繼續後向分發。數據處理集羣負責按照業務邏輯計算數據，並將計算結果「寫入」到數據存儲集羣，最後將結果數據展示給廣大站長使用。基本原理以下圖所示：

騰訊分析後臺是一套完成的數據流處理系統：由JS採集的用戶行爲數據像川流不息的河水同樣流入騰訊分析後臺，通過清洗、計算後源源不斷地流出到騰訊分析存儲集羣，供用戶瀏覽、查詢。具體架構及核心部件以下圖：

騰訊分析的後臺分爲離線和實時兩個部分，實時部分負責系統的主要功能計算，數據更新頻率爲秒級；離線部分負責系統複雜的關聯分析及跨天計算，數據更新頻率爲天級。

n Http Access：主要負責http協議的解析，數據的清洗及格式化；

n ESC: Event Streaming Coder：主要負責將系統不可枚舉的數據類型編碼成爲整型，並將對應關係持久化；

n ESP: Event Streaming Processor：主要負責將數據按照站點、UID從新組織並計算PV、UV、停留時長、蹦失率等網站分析指標；

n ESA：Event Streaming Aggregator：主要負責將ESP計算後的數據按照站點彙總，並將接入寫入到redis中；

n Center：系統的中心節點，負責系統配置、數據路由的管理，並承擔容災切換功能；

n Logserver：負責將Access收集到的數據以字符串形式寫入文件，並上傳到TDCP上；

n TDCP：騰訊分佈式計算平臺，負責離線數據的計算，並由腳本將結果數據寫入到mysql中；

騰訊分析的實時解決方案

在介紹騰訊分析實時解決方案前，咱們先來了解下騰訊分析支撐的業務量。當前騰訊分析日均須要處理幾十萬網站的上T級數據，處理事後的url個數仍有上億條，系統存儲的key個數超過十億。如何高效、低延遲的處理如此大量的業務數據是騰訊分析實時系統面臨的主要挑戰。騰訊分析的解決主要思路能夠歸納爲數據全二進制化、計算全內存化、存儲nosql化。下面就實時計算和實時存儲這兩大子系統進行深刻的討論。

實時計算

對於計算子系統咱們參考了Hadoop， S4，Storm等開源項目，力圖設計爲一個較爲通用，擴展性較強的全內存實時Event處理系統（或者套用流行的術語稱爲流式實時Event處理系統）。對於這樣的一個系統，咱們設計支持的典型輸入輸出流程大體以下：

實時計算系統主要的設計要點在數據組織、協議以及增量計算模型上。

1.數據組織

萬物皆Int，考慮到內存以及計算過程的性能需求，咱們將全部非int的數據類型轉化爲int。能夠枚舉的數據類型將其配置化映射爲惟一int；不可枚舉的數據類型則利用MD5算法近似獲得惟一的int。例如頁面URL屬於不可枚舉的類型，則預處理經過MD5算法近似獲得惟一的int；UserAgent裏的瀏覽器類型字符串則屬於可枚舉的數據，則預先配置化映射爲int。這個方法節省了較多的內存，也提升了整個系統的計算性能。

2.協議

協議層面上，咱們首先設計實現了一種可擴展的Event結構，這種Event結構支持半自動化的序列化/反序列化機制（參考自msgpack的設計），緊湊的二進制編碼（基於Zigzag編碼，參考Protobuf的實現）。這種Event結構在流式高性能IO（網絡傳輸，持久化）方面表現的至關良好。實時計算子系統被設計爲能夠擴展支持任意的Event實現。

3.增量計算模型

所謂的增量計算模型，指的是基本計算過程被定義爲三個部分：

n Processor：負責具體業務邏輯的計算處理

n Data Holder：負責保存增量結果數據，以及計算依賴的中間狀態數據

n Emitter：負責按期輸出清空增量計算結果

具體到流程方面，則以下所示分三個步驟：

• n 接收Event，計算處理——Processor

• n 保存計算結果以及計算依賴中間數據——Data Holder

• n 定時觸發輸出時間片內計算結果，清空計算結果——Emitter
  

增量計算模型弱化了分佈式系統中單臺機器的事務狀態，相應地簡化了分佈式計算系統的實現，同時也提升了整個系統的性能。

實時存儲

在TA系統中，實時存儲的數據都是須要經過Web展現層讀取的統計數據。這類數據存在兩個典型特色：

• n 頻繁更新寫，更新頻度視系統實時性而定，每條統計結果更新頻度最快能夠達到1秒；

• n 少許讀取，「少許」是相對上述更新而言；

同時根據業務邏輯，咱們將統計數據劃分爲兩類：

• n 固定不變數據：主要是URL，搜索關鍵詞等數據，這一部分數據理論上是不停地增長，不會修改舊有數據；
• n 動態數據：主要是頻繁更新的結果統計數據，這一部分數據則須要不停地更新。好比QQ域名下的PV，UV統計結果；

考慮到上述的TA實時統計數據的特色，咱們選擇NoSQL實現咱們的存儲系統；同時，針對兩類不一樣的數據類型，分別選擇LevelDB，Redis存儲不一樣的類型數據。

• n Redis
  騰訊分析實時存儲的主要構件。考慮到騰訊分析系統自己就是一個比較完善的分佈式集羣系統，所以咱們須要的存儲構件是」not clustering, but sharding」。也就是說像Hbase、mogoDB這樣的「重武器」並不適合騰訊分析，而nosql數據庫中的「瑞士軍刀」redis憑藉其出色的性能走入咱們的視野。同時騰訊分析的結果數據類型也比較豐富，有像站點PV、UV、VV、IP等hash類型的數據，也有像用戶訪問軌跡這樣set類型的「動態數據」，而redis豐富的數據結構很好地完成了這項任務。
  另一個選擇redis的緣由是它足夠的簡單且易於擴展。在實際應用的過程當中，咱們發現的問題均可以經過擴展redis命令來解決。例如，騰訊分析中有這樣的一種應用場景：爲了消除ESA模塊的狀態，存儲在redis中的數據每每並非最終的結果數據，而是還須要進一步運算的中間數據。像bounce rate這個指標（bounce rate=bounce session數/total session數），須要前臺查詢兩次再作一次運算後最終展現給用戶。在高併發的狀況下，這無疑會影響系統的響應速度。本着「移動計算，而不是移動數據」的原則，咱們對redis的sort、hmget命令進行了擴展使其支持四則運算，成功地將原來的兩次查詢優化爲一次。擴展四則運算的另一個目的是能夠「經過計算換取存儲」，例如須要將兩種類型加總成總和的類型數據，能夠只存儲兩份，加總數據「經過計算換取」。除了數據讀取，數據的寫入也能夠進行相似合併數據的優化，例如，騰訊分析在寫入url的PV、UV、VV、IP、停留時長、bounce rate這6個指標時，須要調用6次redis命令，而實際上這6個指標是存儲在同一個hash內的，經過擴展hmincrby命令，支持將hash的全部field一次更改，將調用次數優化至一次。上線以後也取得了良好的效果，峯值時的CPU利用率幾乎降低了一半，同時也大幅提高了上層模塊ESA的吞吐量。

• n LevelDB
  Redis的有效補充，考慮到redis爲內存數據庫，而使用內存的成本要高於硬盤，所以選擇引入了基於磁盤存儲的LevelDB做爲補充。LevelDB的寫性能足夠好，而讀性能也遠遠超過目前「在線少許讀取」的需求的。所以咱們選擇LevelDB存儲「固定不變數據」。

在數據存儲的架構設計上，因爲實時數據服務與在線系統，可靠性要求較高，所以咱們主要採起雙寫複製+Sharding的設計：

1.雙寫複製

全部的數據存儲都會至少同步寫兩份，以此提升在線系統服務的可用性

2.數據分片Sharding

l 基於域名

n 全部的數據以域名爲單位組織分片；
n 任何域名能夠調整到任意分片中；
n 單個域名數據原則上存儲在一個分片中；

l 動態調整

n 只調整分片策略，不移動數據；
n 基於數據量計算分片負載；

此外，針對分片集羣數據的查詢，咱們主要作了三項工做：

n 實現了一個較爲完整的Redis協議棧做爲上層應用的基礎，設計是直接用redis協議做爲對外提供的查詢通用協議，這樣外部用戶能夠直接經過目前各類Redis Client實現來查詢訪問數據；

n 一個靈活的查詢引擎：可以根據規則智能的在多個Redis、LevelDB數據源中查詢，執行類join的操做；也簡單擴展支持其它的異構數據源如Mysql、Hbase等

n 一個實時查詢計算引擎：一些複雜的查詢，實時根據基礎查詢結果實時計算。引入此部分的主要目的在於減小Redis數據空間佔用。

將來展望

目前騰訊分析雖然在後臺上已經作到數據秒級更新，但展現方式仍爲傳統的靜態方式。後續騰訊分析會在數據的動態刷新上進行更多嘗試，讓站長能夠第一時間瞭解網站營銷效果，時刻感覺網站心跳。讓騰訊分析持續帶給站長價值！