背景介紹

 

對于騰訊龐大的大數(shù)據(jù)分析業(yè)務(wù)，幾千臺的 Hadoop 集群，近百 P 級的存儲總量，每日產(chǎn)生萬億的消息數(shù)據(jù)入庫，需要針對幾十億 IMEI 手機設(shè)備去重，并關(guān)聯(lián)數(shù)千億的歷史全表，進行曝光、點擊、PV、UV、日活、新增、留存等統(tǒng)計指標(biāo)分析，當(dāng)前所有業(yè)務(wù)的 ETL 清洗、統(tǒng)計計算、用戶畫像都全部依賴離線 m/r 和 Hive SQL，給集群造成很大壓力，系統(tǒng)負載高任務(wù)積壓重，計算耗時久業(yè)務(wù)響應(yīng)慢(t+1)，難以及時反饋市場信息的變化，不僅是技術(shù)上的巨大挑戰(zhàn)，同時業(yè)務(wù)的迅速增長變化也在挑戰(zhàn)著當(dāng)前技術(shù)團隊的工作模式和流程。如何突破現(xiàn)有大數(shù)據(jù)分析架構(gòu)瓶頸?

本文內(nèi)容將帶來騰訊大數(shù)據(jù)技術(shù)的新發(fā)展和架構(gòu)實踐，介紹基于自研 bitmap 技術(shù)的大數(shù)據(jù)系統(tǒng)“鋒刃”，以及 OLAP 全新驅(qū)動模式的架構(gòu)戰(zhàn)略，真正做到秒級實時查看每分鐘指標(biāo)、全維度的用戶 OLAP 自助分析、閉環(huán)的動態(tài)運營體系。

講鋒刃大數(shù)據(jù)方案之前，我們先整體看看大數(shù)據(jù)平臺架構(gòu)，有諸形于內(nèi)必形于外，很多局部狀況的問題，需要從整體來看，為此，我們按照集群狀況，典型業(yè)務(wù)流程和數(shù)據(jù)流、系統(tǒng)架構(gòu)瓶頸點的思路順序，以表知里的進行一下梳理。

一、集群狀況的反饋

當(dāng)前 Hadoop 集群系統(tǒng)性能繁忙(3 大區(qū)域 7 大機房)，1000 多存儲機器對應(yīng) 4000 多計算機器，cpu 平均值 70%-80%(晚 20 點到 0 點較低)，5 分鐘負載很高，任務(wù)積壓重;ech1 幾百兆，峰值幾個 g;磁盤 io 約幾百兆，峰值幾 g，讀寫 iops3000。存儲計算比為 1：2，業(yè)務(wù) job 還在增長之勢，1：3 到 1：4 將達到集群瓶頸。

很多時候我們看到集群繁忙，只當(dāng)作運維問題去解決，擴容集群機器，調(diào)整機房部署，優(yōu)化調(diào)度能力和虛擬化，增強任務(wù)監(jiān)控管理等。卻很少關(guān)心集群上跑的都是些什么任務(wù)，為什么會給集群造成這么大的壓力，我們接下來通過梳理業(yè)務(wù)流程和數(shù)據(jù)流來搞清楚這個問題。

二、典型業(yè)務(wù)流程和數(shù)據(jù)流

手機瀏覽器業(yè)務(wù)場景典型流程：從手機瀏覽器的資訊日志數(shù)據(jù)，統(tǒng)計每板塊的 PV，并挖掘用戶瀏覽咨訊的內(nèi)容提取標(biāo)簽，并計算標(biāo)簽權(quán)重，進行推薦，再將推薦結(jié)果反饋到日志。

 

 

三、貫穿業(yè)務(wù)場景的數(shù)據(jù)流

多份業(yè)務(wù) log 和產(chǎn)品如燈塔 sdk 產(chǎn)生多份數(shù)據(jù)日志，分別有各自的通道和 hdfs 數(shù)據(jù)模型，對集群存儲和計算有很大重復(fù)，也造成各自數(shù)據(jù)的不完整，目前尚未在“通道采集—基礎(chǔ)數(shù)據(jù)—集市數(shù)據(jù)——高級畫像”數(shù)據(jù)流鏈路上形成統(tǒng)一數(shù)據(jù)模型，這樣即能優(yōu)化節(jié)省資源，又能數(shù)據(jù)建模標(biāo)準(zhǔn)化，所有統(tǒng)計計算和算法挖掘都基于統(tǒng)一數(shù)據(jù)標(biāo)準(zhǔn)進行，上層可以提供大量工具化用戶產(chǎn)品。

 

 

四、系統(tǒng)架構(gòu)瓶頸全鏈路分析

綜上所述，我們通過對集群、采集、通道、統(tǒng)計、存儲、數(shù)據(jù)治理、idc、業(yè)務(wù)場景的全鏈路架構(gòu)分析，歸納出以下瓶頸點：

♦ Hadoop 集群的繁忙壓力

♦ 所有業(yè)務(wù)全部依賴離線 m/r 計算和 Hive SQL

♦ log 采集的大量重復(fù)內(nèi)容

♦ MQ 集群每日消息總量萬億但無法提供內(nèi)容過濾

♦ 冷熱存儲、短期存儲(天內(nèi))、長期存儲(T+1，周、月、年)混一起

♦ 做到小時和分鐘級別統(tǒng)計很難。

♦ 沒有一個統(tǒng)一精簡的數(shù)據(jù)模型形成標(biāo)準(zhǔn)。

♦ 業(yè)務(wù)的存儲和計算還在迅速增長…

但是不可能所有的架構(gòu)瓶頸都能在短時間內(nèi)進行優(yōu)化改進，我們需要尋找一個最合適的切入點，先解決最迫切的問題。

五、遷入實時計算的優(yōu)化和問題

(一)從業(yè)務(wù)流程和數(shù)據(jù)處理的邏輯，反思當(dāng)前架構(gòu)和處理方式：

1、采集源頭的 log 生成：如應(yīng)用寶產(chǎn)生 6000 多 log，其中 30%-40% 的內(nèi)容是重疊(設(shè)備信息、身份信息等)，開發(fā)人員根據(jù)需要自定義新的 log，每個 log 產(chǎn)生后續(xù)一系列存儲表，以及新的工作流 job，不斷累加。對于每個 log，有的超過 100 個字段，支持很多種統(tǒng)計任務(wù)，但是每種統(tǒng)計只需要其中很少字段即可完成。

(1)、Log 進行重新梳理和合并，減少冗余，制定 log 規(guī)則

(2)、考慮從源頭進行 log 梳理和分流，以統(tǒng)計業(yè)務(wù)維度接收局部消息內(nèi)容：

 

 

2、通過大量 hdfs 存儲表實現(xiàn)數(shù)據(jù)流處理：以手機瀏覽器業(yè)務(wù)，每個 log 表會產(chǎn)生多個清洗結(jié)果表，多張清洗結(jié)果表匯合清洗統(tǒng)計表，完成統(tǒng)計計算后，還需要匯合多張統(tǒng)計結(jié)果表，形成通過大量的 hdfs 中間存儲表，來實現(xiàn)統(tǒng)計和集市的數(shù)據(jù)處理邏輯。如果考慮用實時流取代存儲表處理流，可以帶來很大的資源節(jié)省和效率提升：

 

 

3、當(dāng)前離線處理方式，以燈塔為例，每 10 分鐘接收 MQ 通道的日志數(shù)據(jù)，在 HDFS 建立一個分區(qū)，一天共 144 個分區(qū)，每個分區(qū)建立 3600 個幾 K 到 10M 的小文件不等，再提交 144 個離線 JOB 去執(zhí)行清洗任務(wù)，產(chǎn)生 1500 個解析表，再按照小時、天、月建立統(tǒng)計統(tǒng)計任務(wù)，反復(fù)關(guān)聯(lián)全表熱表操作，完成新增用戶等典型統(tǒng)計。離線處理方式計算和磁盤耗用嚴(yán)重，解決 1 天內(nèi)的實時需求難以滿足。除燈塔外，其他的業(yè)務(wù)也按照這種方式源源不斷產(chǎn)生大量的離線任務(wù)進行統(tǒng)計，除計算外還會產(chǎn)生大量數(shù)據(jù)存儲冗余，現(xiàn)在我們終于明白集群為什么如此繁忙的癥結(jié)所在了。

(二)遷入實時計算進行優(yōu)化的考慮：

1、經(jīng)過分析了燈塔、應(yīng)用寶、手機瀏覽器和手機管家，業(yè)務(wù)的相似主線模式如下，更適合實時處理;

 

 

2、清洗部分實時處理 DEMO 驗證：相對于離線計算 MAP/REDUCE 的時間消耗換算，耗用機器數(shù)從 84 臺降低到 15 臺 m10，完成了 90% 的數(shù)據(jù)量進行流式清洗，包括：從 kafka 拉數(shù)據(jù) -> 解包 ->byte2string-> 清洗 ->string2byte->，5 分鐘處理 10 億消息數(shù)據(jù)，333w/s，接近 mq 純拉取消費的 360w/s;

3、清洗轉(zhuǎn)換步驟，采用實時流處理架構(gòu)如 Storm，通過 spout 從 MQ 獲取輸入流，自定義多個 bolt 并行處理輸入流，再依此組合設(shè)計;

 

 

4、業(yè)務(wù)遷移計劃，以燈塔廣告監(jiān)測 CASE 為切入逐步安排計劃遷移。

(三)實時計算框架選型問題：

其實我們的技術(shù)團隊當(dāng)時也考慮過通過實時計算來優(yōu)化，但是基于傳統(tǒng)流處理實時計算方案 Storm、Spark Streaming、Flink 框架進行實施時，面臨一系例問題阻礙，導(dǎo)致無法大范圍推行：

當(dāng)時團隊現(xiàn)狀：Storm 和 Spark Streaming 研發(fā)支持和運維能力較成熟，原始 Flink 還需要優(yōu)化，尚不具備直接大規(guī)模工程化實施的條件。

Storm 的算子封裝和開發(fā)成本較大，但是能很好解決 1 分鐘到 1 小時實時計算和離線資源釋放，SQL 支持弱，業(yè)務(wù)分析團隊更習(xí)慣寫 SQL 做清洗和統(tǒng)計。

Spark Streaming 開發(fā)成本低，能解決 5 分鐘 10 分鐘實時批量計算，但是 1 小時計算無法釋放離線資源，統(tǒng)計 1 分鐘級結(jié)果會產(chǎn)生大量調(diào)度任務(wù)。

Flink 提供流式和批量結(jié)合的實時處理和完善 SQL 支持，適合完成清洗和 count 計算，但其有限時間窗口并不太適合大批量用戶去重和統(tǒng)計。

六、鋒刃大數(shù)據(jù)架構(gòu)方案

到目前為止，我們需要尋找一種新的大數(shù)據(jù)架構(gòu)方案，針對海量大數(shù)據(jù)的實時統(tǒng)計場景進行專門設(shè)計，得到更先進的解決辦法。我們把業(yè)務(wù)場景簡化一下如下表述，按照因果關(guān)系，我們通過手機設(shè)備獲取到一些 app 維度的 log 數(shù)據(jù)，經(jīng)過大數(shù)據(jù)平臺的統(tǒng)計處理，最后得到用戶相關(guān)的結(jié)果和一些 count 類結(jié)果(pv,uv, 金額，數(shù)量等)，現(xiàn)在我們想在內(nèi)存中按照維度組合來實時計算這些結(jié)果，削峰填谷把離線累積的數(shù)據(jù)統(tǒng)計變成每分鐘實時流處理。

 

 

(一)BitMap 位存儲和位計算

為了解決海量用戶的去重問題，我們發(fā)現(xiàn)使用 bitmap 有兩個非常顯著的優(yōu)勢：位存儲占用空間低，位計算效率高。

1、將需要做統(tǒng)計計算的 id 轉(zhuǎn)換成數(shù)字序號，每個只占 1 個 bit，對于 20 億的用戶 id，只需要 20 億 bit 約 238m 大小，壓縮后占用空間更小，最少只要 200k;

 

 

2、通過單個 bitmap 可以完成去重操作，通過多個 bitmap 的且、或、異或、反等位操作可以完成日活、月活、小時分鐘活躍、重度用戶、新增用戶、用戶流向等絕大部分的統(tǒng)計計算，而且能在單機毫秒級完成，真正做到實時計算出結(jié)果，同比 Hadoop/Hive 離線計算執(zhí)行“select distinct count…from…groupby join…”類似 SQL 的方式統(tǒng)計，往往需要幾百臺機器，耗用 30 分鐘才能完成，對比非常懸殊，而且容易形成大量 SQL 任務(wù)調(diào)度和大表 join 給集群帶來繁重壓力。

(二)BitMap 聚合計算

通過多個不同維度的 bitmap 聚合計算，來解決離線統(tǒng)計里復(fù)雜的 join 問題，幾乎可以涵蓋所有用戶統(tǒng)計相關(guān)的場景：

♦ 去重用戶：求 1 的總數(shù)

♦ 活躍用戶: 取或 bitmap1 | bitmap2

♦ 非活躍用戶：取反：～bitmap1

♦ 重度用戶：取且：Bitmap1 & bitmap2

♦ 留存用戶：取且再求百分比：Bitmap1 & Bitmap2 相對于 Bitmap1 的百分比

♦ 新增用戶：取或加異或：(Bitmap1 | bitmap2)^bitmap1

♦ 流失用戶： Bitmap1 相對于 bitmap2 的新增用戶

♦ 用戶流向：app1time1 的流失用戶 &app2time2

♦ 多種指標(biāo)組合：Bitmap1 & bitmap2 & bitmap3 &…

♦ 等等

 

 

按照不同維度生成用戶 bitmap 后，會得到如下面表格描述的數(shù)據(jù)結(jié)構(gòu)：

 

 

我們可以看到，這個數(shù)據(jù)結(jié)構(gòu)是個大的 0,1 矩陣，每一行代表某維度取值的用戶 bitmap，把 1 累計可以求的此維度取值的用戶指標(biāo)，比如 hw 機型有多少用戶在使用。每一列實際上可以獲取到該用戶的畫像，比如 u6 用戶用 oppo 機型、經(jīng)常在北京和深圳等等，維度越多，畫像信息越詳細。另外，全盤用戶的矩陣結(jié)構(gòu)還有更深遠的意義，我們在機器學(xué)習(xí)推薦中，基于特征處理后的 01 矩陣，可以完成大量的算法訓(xùn)練。

實際上，bitmap 的維度組合還有一些復(fù)雜性問題需要權(quán)衡，比如維度 A(共 10 個取值) 和維度 B(共 10 個取值)，如果聚合 AB，有兩種方式：

第 1 種，An&Bn，共 10+10=20 個 bitmap;

第 2 種，An_Bn，共 10*10=100 個 bitmap。

第 1 種存在數(shù)據(jù)疊加的影響，第 2 種不存在;

第 1 種消耗更少的空間，第 2 種消耗更多空間，但是根據(jù)業(yè)務(wù)實際數(shù)據(jù)出現(xiàn)建立 bitmap，實際占用空間小于理論組合全部值(比如 mi_kashi 不存在)。

(三) Bitmap 壓縮分析

對于 bitmap 數(shù)量很多的場景，壓縮有利于節(jié)省大量空間，對于 20 億的用戶 id，需要 20 億 bit 約 238m 大小，壓縮后占用空間最少只要 200k。

按照燈塔當(dāng)前業(yè)務(wù)流量，42 億范圍的 id 不會全部來，去重后 1-2 億進入 bitmap，按照 2:42 的數(shù)據(jù)分布，壓縮后還是能省很多空間。

如果業(yè)務(wù)流量單位時間內(nèi)(10 秒)，42 億用戶全部來或者來 30 多億，這時 bitmap 大部分為 1，壓縮率反而很高，空間耗用不大。反而，對于只來 10-20 億去重用戶，這是要面臨極端最壞的情況，數(shù)據(jù)分布廣且稀疏，壓縮有限，空間耗用很大。

不同的壓縮算法壓縮率和耗時成反比，考慮實時性和空間節(jié)省，選用壓縮率和耗時比較平衡的 gzip 壓縮。

(四)流式處理 +Bitmap 實時計算框架

將離線批量處理改成消息流式實時處理，并按照上面基于 bitmap 做去重和聚合的思路，我們得到下面新的架構(gòu)：借助 flink 的 SQL 能力做清洗邏輯，并提供基于 SQL 的去重和統(tǒng)計 udf 的封裝給到業(yè)務(wù)分析人員使用，構(gòu)建一個分布式的 bitmap 集群服務(wù)來提供 bitmap 的計算引擎支持，統(tǒng)計結(jié)果的數(shù)據(jù)實時寫到數(shù)據(jù)庫里提供報表展示。

 

 

注意到，上面的架構(gòu)里增加來一個 ID 查詢服務(wù)的模塊，它用來負責(zé)將手機 IMEI 號在線查詢轉(zhuǎn)換為數(shù)字 ID。

1、初始化：通過離線任務(wù)，按照最后活躍時間初始化用戶 ID 的數(shù)字序號，很久沒來的用戶放前面，最近的用戶放后面，新增的用戶在后面加 1，這樣直接從 bitmap 的數(shù)字 ID 范圍知道是大致什么時間的用戶，目前約 50 億范圍的用戶 id，除去虛假用戶和僵尸用戶，還有 20 億左右正常用戶。結(jié)果：僅通過數(shù)字序號可以區(qū)別最近的用戶還是很久以前的。

2、運行時：

 

 

未來：手機設(shè)備上，燈塔 sdk 直接攜帶設(shè)備 ID 的數(shù)字序號進入通道，逐步減少 id 查詢，也就是說，未來對市場上幾十億手機設(shè)備，騰訊都能有一個除 imei 外自己的數(shù)字編號，這樣會極大提升后臺的大數(shù)據(jù)統(tǒng)計分析能力。

(五)BitMap 的空間耗用

1、大范圍數(shù)字的空間浪費問題，如果不分區(qū)，一個值為 20 億的數(shù)字需要耗用 238m 的空間;

 

 

2、分區(qū) bitmap 的優(yōu)勢和問題，對于數(shù)字最大范圍為 20 億，按照不同的大小分區(qū)如下：如果每個分區(qū)很大，那么少量分布均勻的數(shù)字很容易占滿所有分區(qū);如果每個分區(qū)很小，分區(qū)數(shù)(key 的數(shù)量)就很多，key 的空間開銷也很大。那么如何做到最優(yōu)的空間消耗呢?

 

 

3、RoaringBitmap 的核心原理和不足：

RoaringBitmap(官網(wǎng)地址，論文地址)是 Druid、Spark、Hive 等很多大數(shù)據(jù)框架依賴的 bitmap 核心組件，我們先看看它是怎么做到空間優(yōu)化的。

RoaringBitmap 將一個整型數(shù)字拆分成高低 2 個短整型，并共用高位做 key，可以知道最大分區(qū)為 65535，低位做 value，可以用一個 short[][] 來存儲，相同 key 的 value 存儲在同一個 short[] 里，進行二分查找去重，當(dāng) value 的數(shù)量到達 4096 時，空間消耗已經(jīng)等同于一個長度為 65535 的 bitmap，這時進行 bitmap 轉(zhuǎn)換。 RoaringBitmap 在理論上通過高低分位成兩個 short 類型數(shù)字，從而有效節(jié)省數(shù)據(jù)量小時的空間開銷，并在數(shù)據(jù)增長到臨界點 4096 時轉(zhuǎn)換成 bitmap，數(shù)據(jù)量大時不再增長空間開銷。

 

 

但是 RoaringBitmap 在落地的實現(xiàn)和應(yīng)用中仍然通常在面臨以下問題，不能做到性能和空間最優(yōu)：

高低分位后，實際上形成一個 65535*4096 的固定分區(qū)，對不同的數(shù)據(jù)特點，不能靈活設(shè)置分區(qū)大小和分區(qū)數(shù)量以滿足不同數(shù)據(jù)范圍和不同增長幅度的場景需求;

在其 java 的實現(xiàn)版本里，由于 short 數(shù)組的動態(tài)變長，產(chǎn)生大量的無用對象不能及時垃圾回收(gc)，而且只有當(dāng)每個分區(qū)抵達 4096 數(shù)量時才能轉(zhuǎn)為 bitmap 停止內(nèi)存增長，容易導(dǎo)致在分區(qū)均勻情況下接近 4096 的時候空間開銷很大，這時 bitmap 的數(shù)量很少，而 65535 個 short[] 動態(tài)增長產(chǎn)生的大量垃圾內(nèi)存，其實際空間消耗已經(jīng)遠遠超出理論的預(yù)估值。

耗時慢，由于二分查找去重需要進行數(shù)組排序，會產(chǎn)生額外的性能消耗，特別是數(shù)據(jù)量低于 5000 萬時，二分查找的性能并不比線性查找有優(yōu)勢，反而耗時更多。當(dāng)數(shù)據(jù)量很大時，數(shù)組結(jié)構(gòu)已經(jīng)轉(zhuǎn)成 bitmap，此時二分查找已經(jīng)不再起作用。

4、原創(chuàng)實現(xiàn)的高效 ArrayBitmap

為了克服數(shù)據(jù)量小而且稀疏時導(dǎo)致的 bitmap 空間浪費問題，經(jīng)過實踐摸索尋找到一種動態(tài)增長的分桶數(shù)組結(jié)合 bitmap 數(shù)據(jù)結(jié)構(gòu)的新設(shè)計方案來解決，經(jīng)過大量測試證明，相對于 RoaringBitmap 有更好的性能和更優(yōu)的內(nèi)存空間消耗。

 

 

性能測試對比：

經(jīng)過和 roaring bitmap 不同數(shù)據(jù)大小的測試對比(20 億范圍隨機)，情況如下：

10 萬、50 萬、100 萬、500 萬、1000 萬數(shù)據(jù)范圍：內(nèi)存占用略同于 roaring bitmap，但耗時只有一半;

5000 萬數(shù)據(jù)：由于超過 3000 萬轉(zhuǎn) bitmap 存在拷貝空間耗用，內(nèi)存占用大于 roaring bitmap，但是耗時更低;

1 億數(shù)據(jù)：內(nèi)存占用和 roaring bitmap 接近，但是耗時只有三分之一。

2 億及以上數(shù)據(jù)：內(nèi)存占用低于 roaring bitmap，耗時只有四分之一。

為了方便讀者理解上面的思想，作者抽取出了兩個簡化的 java 實現(xiàn)類供參考，CoolBitSet.java 實現(xiàn)了 bitmap 的所有操作，CoolBitMap.java 是集成了數(shù)組和 bitmap 存儲的高級結(jié)構(gòu)，可在附件下載。

(六)鋒刃大數(shù)據(jù)平臺的建立

在成功解決了以上 bitmap 的各種問題后，經(jīng)過 1 年多的建設(shè)，基于流式處理結(jié)合 bitmap 技術(shù)，從最開始的架構(gòu)方案和程序 demo，已經(jīng)實施落地為完整的大數(shù)據(jù)計算系統(tǒng)“鋒刃” ，系統(tǒng)邊界不僅解決實時計算，還包括離線提速和 OLAP，和當(dāng)前數(shù)據(jù)工廠( Hadoop+Hive )互補，并且作為平臺提供 bitmap 結(jié)構(gòu)的文件存儲，以及 OLAP 的大數(shù)據(jù)分析系統(tǒng)。PCG 運營數(shù)據(jù)應(yīng)用框架團隊提供鋒刃平臺開發(fā)和場景實施支持。

七、業(yè)務(wù)場景實施及架構(gòu)升級

(一)騰訊燈塔實時統(tǒng)計上線

騰訊燈塔產(chǎn)品介紹：

騰訊燈塔是基于騰訊海量大數(shù)據(jù)開發(fā)的移動應(yīng)用智能數(shù)據(jù)分析平臺，聚焦數(shù)據(jù)驅(qū)動用戶增長，為業(yè)務(wù)提供分析云與營銷云服務(wù)。提供包括應(yīng)用分析、廣告效果監(jiān)測、廣告渠道反作弊、DMP 標(biāo)簽、市場指數(shù)等全鏈路大數(shù)據(jù)運營服務(wù)。騰訊燈塔秉承獨立第三方的數(shù)據(jù)服務(wù)理念，去偽存真，指引有價值的增長。目前日均處理 4000 億 + 日志，覆蓋 MAU 13 億，積累 7 大類，1000+ 標(biāo)簽。

產(chǎn)品官網(wǎng)：beacon.qq.com

1、燈塔實時計算經(jīng)歷“實時清洗上線—實時統(tǒng)計開發(fā)實施—試運行 1 個月—故障演練”共 3 個月，目前已經(jīng)全量上線，所有產(chǎn)品可以查看一維 1 分鐘和 10 分鐘到實時新增、啟動用戶、啟動次數(shù)。當(dāng)前運行狀況正常。

 

 

2、確定了實時系統(tǒng)服務(wù)保障量化指標(biāo)，保證實時查看結(jié)果，對延遲情況保障：平均延時不超過 5 分鐘，異常延時(版本更新重啟等)不超過 30 分鐘，超過 30 分鐘屬故障。vip 產(chǎn)品(1 分鐘，10 分鐘，日)保證和離線統(tǒng)計結(jié)果偏差不超過萬分之五，長尾產(chǎn)品結(jié)果偏差不超過千分之五。

3、數(shù)據(jù)核對情況：以 10 分鐘為標(biāo)準(zhǔn)，目前實時計算結(jié)果和離線統(tǒng)計結(jié)果核對一致。1 分鐘離線沒有統(tǒng)計，日統(tǒng)計離線有策略補充基準(zhǔn)不一樣，經(jīng)過和燈塔業(yè)務(wù)確認，統(tǒng)一了核對結(jié)果。

資源耗用情況：

約 35 臺機器(去重服務(wù)：6 臺 m10，flink：11 臺 m10，去重 dcache：4 臺 m10 共 200g，id server：10 臺 docker 合計 1 臺 m10，id server dcache：10 臺 m10+3ts80)。

(二)騰訊某安全產(chǎn)品場景離線提速上線

需求：當(dāng)前離線 hive 計算每日 25 億數(shù)量大 app 的卸載留存很難算出，復(fù)雜任務(wù)計算耗時從早上 8 點到晚上 11 點。

方案：現(xiàn)改用 bitmap 方案對 1200 個 app 進行優(yōu)化提速，按 app_ 渠道 _ 日劃分為 12 萬個 bitmap 進行聚合計算。

效果：現(xiàn)統(tǒng)計留存卸載的耗時為，日 10 秒，周 20 秒，月 1-2 分鐘(90 個 bitmap 聚合)

耗用資源：20 臺機器(flink2 臺、去重服務(wù) 7 臺、dcache10 臺(400g)、id 查詢 1 臺)

目前已經(jīng)上線一期、二期。

(三)騰訊某大數(shù)據(jù)分析產(chǎn)品離線分析架構(gòu)升級

需求：當(dāng)前離線 hive 跑 3000 億全表 join1000 億日表耗時 7 小時以上，難以滿足模型頻繁驗證。

方案：3000 億全表按照 app 維度理論生成 3000 萬的 bitmap(其中用于統(tǒng)計的數(shù)量在 100 以上有 200 萬)，1000 億日表用于統(tǒng)計的數(shù)量 100 以上的有 48 萬，20 億用戶大盤表生成 1 個 bitmap，通過三類 bitmap 求新增并更新歷史全表和大盤用戶表。

 

 

(四)ABTest 實時數(shù)據(jù)分析平臺

1、ABTest 的應(yīng)用場景可以分為兩大類型：

(1)、算法類：瀏覽器資訊、廣告、搜索、推送

(2)、運營活動：瀏覽器框架改版、瀏覽器 vivo 裝機新用戶推送、應(yīng)用寶活動類

2、ABTest 需求：

為了衡量算法投放前后或者是運營行為活動前后的效果，我們需要實時計算下述指標(biāo)及綜合指標(biāo)的前后變化，并且通過用戶標(biāo)簽(搜索類、看資訊類、點快鏈類、無行為類)劃分人群來分析。

(1)、PV，UV，CTR;活躍，留存，新增，收入… 等實時/離線指標(biāo)提升

(2)、模型量化計算綜合提升

如下圖，需要通過實時計算將表格內(nèi)的統(tǒng)計指標(biāo)完成：

 

 

3、Abtest 系統(tǒng)架構(gòu)方案：

 

 

4、ABtest 實時數(shù)據(jù)分析平臺上線

之前幾個小時才能看到線上數(shù)據(jù)，現(xiàn)在只要五分鐘!

實時數(shù)據(jù)能讓我們能更快的看到實驗數(shù)據(jù)，及時發(fā)現(xiàn)并下線異常實驗。同時也能實時監(jiān)控實驗，及大盤核心指標(biāo)，發(fā)現(xiàn)異常數(shù)據(jù)。更快發(fā)現(xiàn)問題就能更及時解決問題，從而降低異常對線上用戶的的影響。

 

 

(五)業(yè)務(wù)實施推動架構(gòu)升級

在實施上線以上實時統(tǒng)計、離線加速的業(yè)務(wù)場景，業(yè)務(wù)系統(tǒng)獲得了高性能的同時，也暴露了在高可用性和高可靠性的某些不足，為此，也推動著鋒刃實施團隊進行自身的架構(gòu)升級。

1、首先 flink 的清洗和去重改造成基于消息通道的生產(chǎn)消費模式，借助消息 offset 消費位可以更準(zhǔn)確的故障恢復(fù)消費。

2、增加配置平臺工具化方便業(yè)務(wù)配置自己的清洗邏輯、統(tǒng)計邏輯、聚合邏輯等。

 

 

3、我們發(fā)現(xiàn)，鋒刃系統(tǒng)大部分的時間精力耗在上面的虛線框內(nèi)，實現(xiàn)一個分布式的 bitmap 計算引擎、內(nèi)存結(jié)構(gòu)、及持久化存儲上，以及穩(wěn)定性保障上。將 bitmap 引擎遷移到部門 kv 存儲產(chǎn)品 decache 和 bdb 上，并提供專門的熱備、故障恢復(fù)、冷熱切換、內(nèi)存管理、分布式擴容等特性。這樣鋒刃復(fù)雜繁重的去重服務(wù)模塊就簡化成一個代理模塊，可以更專注在業(yè)務(wù)需求的滿足上。如下圖：

 

 

八、OLAP 的愿景目標(biāo)

我們的大數(shù)據(jù)統(tǒng)計需求其實可以歸納為兩大類型：

關(guān)鍵維度的實時監(jiān)控：適合少量關(guān)鍵維度比如 app 的去重用戶、新增用戶指標(biāo)監(jiān)控，周期性強，每分鐘每天都需要統(tǒng)計輸出。

所有維度的 OLAP 查詢：適合業(yè)務(wù)的自定義排查分析，比如一次促銷活動后，新增用戶指標(biāo)上去了，業(yè)務(wù)人員想通過地區(qū)、版本、版面欄目、動作等多種維度信息分析新增用戶的構(gòu)成，這是一種非周期性的排查分析需求。之前這樣的特定需求都是業(yè)務(wù)方提交給數(shù)據(jù)分析人員專門寫 hive 離線任務(wù)去完成。如果我們的大數(shù)據(jù) OLAP 能力足夠強大，可以讓業(yè)務(wù)和產(chǎn)品人員完成所有維度的自定義查詢，而且能在 5 秒內(nèi)接近實時得到查詢結(jié)果�？梢院艽筇嵘�我們的大數(shù)據(jù)統(tǒng)計效率和滿足業(yè)務(wù)的靈活多樣型，同時這樣我們的數(shù)據(jù)分析人員也可以從繁瑣的統(tǒng)計工作中得到釋放，去轉(zhuǎn)型做模型分析。

總的來說，做到讓用戶“關(guān)鍵維度自助看實時監(jiān)控、所有維度分析自助 OLAP”，徹底解放我們的技術(shù)人員，這是我們想通過技術(shù)手段實現(xiàn)的愿景。

鋒刃系統(tǒng)可以很好滿足第 1 點的關(guān)鍵維度實時監(jiān)控，但是要支持所有維度的統(tǒng)計，會產(chǎn)生大量的維度組合生成的 bitmap，并不適合走實時內(nèi)存處理，并且高度靈活的根據(jù)維度取值來自定義查詢，需要增加維度列式存儲和索引設(shè)計。鋒刃系統(tǒng)接下來需要在設(shè)計上增強對 OLAP 能力的滿足。

我們先看看以 Druid 為代表的大數(shù)據(jù) OLAP 技術(shù)的主要設(shè)計原理。

(一)Druid 的主要原理

 

 

簡言之，Druid 的設(shè)計原理可以通過上述步驟歸納：

1、提出 rowid、時間戳、維度(多個)、指標(biāo)(多個)的 OLAP 數(shù)據(jù)模型，并按列壓縮存儲，導(dǎo)入明細數(shù)據(jù)時設(shè)置 rollup 為 true 可以實現(xiàn)自動上鉆合并，比如點擊數(shù)累加。

2、在數(shù)據(jù)導(dǎo)入時，進行預(yù)計算，根據(jù)維度取值生成 rowid 的 bitmap 索引，而鋒刃系統(tǒng)則是根據(jù)業(yè)務(wù)的特點，基于手機用戶(IMEI)生成 bitmap 索引，這是兩者的本質(zhì)區(qū)別。

3 和 4、當(dāng)執(zhí)行帶維度條件的 SQL 語句時，將 gd 和 1.1 對應(yīng)的 bitmap 做聚合后得到關(guān)聯(lián)的 rowid

5、通過關(guān)聯(lián)的 rowid 找到列存儲對應(yīng)的指標(biāo)點擊數(shù)，進行累加得到最后結(jié)果

由于列存儲和 bitmap 索引機制的高效性，Druid 不需要遍歷整個數(shù)據(jù)集也不需要讀取整行數(shù)據(jù)就能接近實時的計算出結(jié)果。

但是 Druid 在解決海量用戶精確去重存在以下不足：

由于 Druid 的指標(biāo)只能是數(shù)字，IMEI 無法當(dāng)作指標(biāo)，只能當(dāng)作維度，幾十億 imei 會產(chǎn)生幾十億的 bitmap 索引，對內(nèi)存會產(chǎn)生壓力導(dǎo)致益出風(fēng)險;

Druid 是按行號建立 bitmap 索引，只能做根據(jù)維度取值的關(guān)聯(lián)，找出關(guān)聯(lián)行，但是 bitmap 索引不做 IMEI 去重。去重只能通過常規(guī)的 distinct 方法完成，對于幾十億的 IMEI 去重耗時長，容易超時。

Druid 要保證統(tǒng)計高精確性，必須要以明細存儲，要犧牲導(dǎo)入時做聚合處理，增加查詢時的處理壓力。

(二)Druid、鋒刃、Impala 各自適用場景

Druid 最擅長解決“點擊數(shù)/下載數(shù)”這樣的指標(biāo)，并且維度取值不是太大的業(yè)務(wù)場景;解決幾十億 IMEI 統(tǒng)計場景比較吃力，需要約束業(yè)務(wù)范圍和數(shù)據(jù)量，按 app 和業(yè)務(wù)分類分表，針對不同業(yè)務(wù)特定分析。但是對于含有歷史新增 imei 去重的 OLAP、以及多寬表關(guān)聯(lián)仍然不太合適。

如前面提到的，鋒刃當(dāng)前適合解決預(yù)先定義的關(guān)鍵維度的實時統(tǒng)計和離線統(tǒng)計，是針對 IMEI 場景的高清確性的，但是設(shè)計上還不能覆蓋所有維度的自定義 OLAP。

Impala 適合解決數(shù)據(jù)范圍不大的集群內(nèi)存能覆蓋的業(yè)務(wù)場景，超出內(nèi)存限制性能會直線下降。

(三)統(tǒng)一的 OLAP 架構(gòu)方案

如果在 OLAP 架構(gòu)上沒有統(tǒng)一規(guī)劃，完全由各業(yè)務(wù)團隊自由搭建，就會形成基于 Druid，Impala，Kudu，Kylin 等各式各樣框架的方案解決各自業(yè)務(wù)小范圍需求的局面，造成功能重疊及人員浪費，而且長期來看業(yè)務(wù)團隊自身也不具備強大的運維能力。如果我們完全自研一套 OLAP 系統(tǒng)，比如在鋒刃上實現(xiàn)自研 rowid 反向索引、分布式節(jié)點存儲、查詢、任務(wù)調(diào)度等 Druid 的功能，到最后測試穩(wěn)定可運行，也需要耗費很久時間，業(yè)務(wù)團隊面臨用戶壓力，沒有足夠的耐心等待。

所以我們在保持自研能力的同時，也在構(gòu)思可以用于馬上滿足業(yè)務(wù)需求的架構(gòu)集成方案，把鋒刃和 druid 的優(yōu)勢整合進來，雖然底層設(shè)計沒打通，但是通過上層的集成和封裝能得到一套統(tǒng)一的 OLAP 架構(gòu)方案。

1、Cube 模型歸納

經(jīng)過思考，首先架構(gòu)方案需要滿足一個 cube 的索引模型，才能很好支持自定義 OLAP 查詢，由于維度長短不齊，這是一個看上去不規(guī)整立方體(cube)，可以通過時間、維度、取值切蛋糕似得拿到 rowid 和 imei 的 bitmap 索引。這樣就能很快找到維度條件關(guān)聯(lián)的 rowid 計算 count 類指標(biāo)，并拿到對應(yīng)的 imei 的 bitmap 計算用戶去重類指標(biāo)。

Cube[t][d][v] = bitmap(rowid) ，bitmap(imei)

t：時間 (Z 軸) ，d：維度 (Y 軸) ，v：取值 (X 軸)

橫切：查找 t2 時間數(shù)據(jù)，cube[t2][ ][ ]

豎切：查找 d2 維度數(shù)據(jù)， cube[ ][d2][ ]

切塊：查找 t0-t1 時間，d0=v0 and d0=v1 的數(shù)據(jù)，cube[<2][d0][<2] (紅框內(nèi))

 

 

2、鋒刃 + Druid 的 OLAP 架構(gòu)方案

如果我們不是直接自研實現(xiàn)，而是把鋒刃和 Druid 通過如下架構(gòu)方案集成，也是可以間接滿足上面的 cube 的索引模型，雖然看上去有一點小別扭。

(1)鋒刃繼續(xù)承擔(dān)消息的接入、實時清洗、和用戶去重，這里把用戶去重分成上面歸納的兩種類型，一類是實時出的關(guān)鍵指標(biāo)，基于內(nèi)存結(jié)構(gòu);一類是可適當(dāng)延遲出的所有維度指標(biāo)，基于持久化存儲，把這兩部分的用戶去重結(jié)果都導(dǎo)入到 Druid。

(2)Druid 承擔(dān)所有維度的自定義查詢，由于鋒刃完成了用戶去重的功能，druid 除了可以快速根據(jù)自定義維度過濾，并完成 count 類指標(biāo)統(tǒng)計外，還可以同時查到用戶去重的結(jié)果，結(jié)果記錄是按照 group 展開的。

 

 

我們注意到上面的方案還有一點缺陷，如果查出一個時間范圍內(nèi)的多條用戶結(jié)果，不能通過 druid 直接合并顯示，這時需要返回鋒刃系統(tǒng)找到對應(yīng)的用戶 bitmap 再做去重后返回結(jié)果。

(3)我們把用戶的自定義查詢過程封裝成一個統(tǒng)一的輸入輸出如下，這樣看上去就是一個基本實現(xiàn) OLAP 功能的完整方案了。

 

 

總結(jié)

本文從集群壓力到大數(shù)據(jù)平臺整體架構(gòu)，再到實時優(yōu)化的切入，一步步闡述了鋒刃大數(shù)據(jù)系統(tǒng)產(chǎn)生的來龍去脈，重點介紹了流式處理結(jié)合 bitmap 技術(shù)架構(gòu)方案的主要原理，相關(guān)業(yè)務(wù)場景實施上線，以及后續(xù)的 OLAP 目標(biāo)規(guī)劃。關(guān)于鋒刃大數(shù)據(jù)系統(tǒng)更多的內(nèi)容，請參考鋒刃團隊后續(xù)的設(shè)計文檔、使用指南、以及開源計劃。

作者介紹

彭淵，現(xiàn)任騰訊 T4 專家，歷任阿里資深專家，華為中間件首席架構(gòu)師，淘寶高級專家等。在中國 IT 互聯(lián)網(wǎng)技術(shù)領(lǐng)域從業(yè)多年，曾撰寫多款開源軟件，代表作有 Fourinone(四不像)分布式核心技術(shù)框架、CoolHash 并行數(shù)據(jù)庫引擎等，曾出版書籍《大規(guī)模分布式系統(tǒng)架構(gòu)與設(shè)計實戰(zhàn)》，擁有多項軟件著作權(quán)和專利。

標(biāo)簽： idc 安全 大數(shù)據(jù) 大數(shù)據(jù)分析 大數(shù)據(jù)分析系統(tǒng) 大數(shù)據(jù)技術(shù) 大數(shù)據(jù)架構(gòu) 大數(shù)據(jù)開發(fā) 大數(shù)據(jù)平臺 大數(shù)據(jù)平臺架構(gòu) 大數(shù)據(jù)統(tǒng)計分析 大數(shù)據(jù)系統(tǒng) 互聯(lián)網(wǎng) 互聯(lián)網(wǎng)技術(shù)

版權(quán)申明：本站文章部分自網(wǎng)絡(luò)，如有侵權(quán)，請聯(lián)系：west999com@outlook.com
特別注意：本站所有轉(zhuǎn)載文章言論不代表本站觀點！
本站所提供的圖片等素材，版權(quán)歸原作者所有，如需使用，請與原作者聯(lián)系。