導(dǎo)語(yǔ)當(dāng)業(yè)務(wù)發(fā)展到一定規(guī)模，實(shí)時(shí)數(shù)據(jù)倉(cāng)庫(kù)是一個(gè)必要的基礎(chǔ)服務(wù)。從數(shù)據(jù)驅(qū)動(dòng)方面考慮，多維實(shí)時(shí)數(shù)據(jù)分析系統(tǒng)的重要性也不言而喻。但是當(dāng)數(shù)據(jù)

導(dǎo)語(yǔ)

當(dāng)業(yè)務(wù)發(fā)展到一定規(guī)模，實(shí)時(shí)數(shù)據(jù)倉(cāng)庫(kù)是一個(gè)必要的基礎(chǔ)服務(wù)。從數(shù)據(jù)驅(qū)動(dòng)方面考慮，多維實(shí)時(shí)數(shù)據(jù)分析系統(tǒng)的重要性也不言而喻。但是當(dāng)數(shù)據(jù)量巨大的情況下，拿騰訊看點(diǎn)來(lái)說(shuō)，一天上報(bào)的數(shù)據(jù)量達(dá)到萬(wàn)億級(jí)的規(guī)模，要實(shí)現(xiàn)極低延遲的實(shí)時(shí)計(jì)算和亞秒級(jí)的多維實(shí)時(shí)查詢是有技術(shù)挑戰(zhàn)的。本文將介紹一下信息流場(chǎng)景下，騰訊看點(diǎn)的實(shí)時(shí)數(shù)據(jù)倉(cāng)庫(kù)和多維實(shí)時(shí)數(shù)據(jù)分析系統(tǒng)的技術(shù)架構(gòu)。

一、可解決的痛點(diǎn)

可以先看一下，多維實(shí)時(shí)數(shù)據(jù)分析系統(tǒng)可以解決哪些痛點(diǎn)。比如：

推薦同學(xué)10分鐘前上了一個(gè)推薦策略，想知道在不同人群的推薦效果怎么樣?

運(yùn)營(yíng)同學(xué)想知道，在廣東省的用戶中，最火的廣東地域內(nèi)容是哪些，方便做地域Push。

審核同學(xué)想知道，過(guò)去5分鐘，游戲類被舉報(bào)最多的內(nèi)容和賬號(hào)是哪些?

老板可能想了解，過(guò)去10分鐘有多少用戶在看點(diǎn)消費(fèi)了內(nèi)容，對(duì)消費(fèi)人群有一個(gè)宏觀了解。

二、調(diào)研

在進(jìn)行開發(fā)之前，我們做了這些調(diào)研。

1.離線數(shù)據(jù)分析平臺(tái)能否滿足這些需求，結(jié)論是不能滿足。離線數(shù)據(jù)分析平臺(tái)不行的原因如下：

C側(cè)數(shù)據(jù)上報(bào)過(guò)來(lái)，需要經(jīng)過(guò)Spark的多層離線計(jì)算，最終結(jié)果出庫(kù)到Mysql或者ES提供給離線分析平臺(tái)查詢。這個(gè)過(guò)程的延時(shí)最少3-6個(gè)小時(shí)，目前比較常見(jiàn)的都是提供隔天的查詢，所以很多實(shí)時(shí)性要求高的業(yè)務(wù)場(chǎng)景都是不能滿足的; 另一個(gè)問(wèn)題是，騰訊看點(diǎn)的數(shù)據(jù)量太大，帶來(lái)的不穩(wěn)定性也比較大，經(jīng)常會(huì)有預(yù)料不到的延遲。所以，離線分析平臺(tái)是無(wú)法滿足很多需求的。

2.實(shí)時(shí)數(shù)據(jù)分析平臺(tái)的話，事業(yè)群內(nèi)部提供了準(zhǔn)實(shí)時(shí)數(shù)據(jù)查詢的功能，底層技術(shù)用的是Kudu+Impala，Impala雖然是MPP架構(gòu)的大數(shù)據(jù)計(jì)算引擎，并且訪問(wèn)以列式存儲(chǔ)數(shù)據(jù)的Kudu。但是對(duì)于實(shí)時(shí)數(shù)據(jù)分析場(chǎng)景來(lái)說(shuō)，查詢響應(yīng)的速度和數(shù)據(jù)的延遲都還是比較高，查詢一次實(shí)時(shí)DAU，返回結(jié)果耗時(shí)至少幾分鐘，無(wú)法提供良好的交互式用戶體驗(yàn)。

所以(Kudu+Impala)這種通用大數(shù)據(jù)處理框架的速度優(yōu)勢(shì)更多的是相比(Spark+Hdfs)這種離線分析框架來(lái)說(shuō)的，對(duì)于我們這個(gè)實(shí)時(shí)性要求更高的場(chǎng)景，是無(wú)法滿足的。

三、項(xiàng)目背景

經(jīng)過(guò)剛才的介紹，再來(lái)看下我們這個(gè)項(xiàng)目的背景。

作者發(fā)文的內(nèi)容被內(nèi)容中心引入，經(jīng)過(guò)內(nèi)容審核鏈路，啟用或者下架。啟用的內(nèi)容給到推薦系統(tǒng)和運(yùn)營(yíng)系統(tǒng)，然后推薦系統(tǒng)和運(yùn)營(yíng)系統(tǒng)將內(nèi)容進(jìn)行C側(cè)分發(fā)。內(nèi)容分發(fā)給C側(cè)用戶之后，用戶會(huì)產(chǎn)生各種行為，曝光、點(diǎn)擊、舉報(bào)等，通過(guò)埋點(diǎn)上報(bào)實(shí)時(shí)接入到消息隊(duì)列中。

接下來(lái)我們做了兩部分工作，就是圖中有顏色的這兩部分。

第一部分構(gòu)建了一個(gè)騰訊看點(diǎn)的實(shí)時(shí)數(shù)據(jù)倉(cāng)庫(kù);第二部分就是基于OLAP存儲(chǔ)引擎，開發(fā)了多維實(shí)時(shí)數(shù)據(jù)分析系統(tǒng)。

我們?yōu)槭裁匆獦?gòu)建實(shí)時(shí)數(shù)倉(cāng)，因?yàn)樵嫉纳蠄?bào)數(shù)據(jù)量非常大，一天上報(bào)峰值就有上萬(wàn)億條。而且上報(bào)格式混亂。缺乏內(nèi)容維度信息、用戶畫像信息，下游沒(méi)辦法直接使用。而我們提供的實(shí)時(shí)數(shù)倉(cāng)，是根據(jù)騰訊看點(diǎn)信息流的業(yè)務(wù)場(chǎng)景，進(jìn)行了內(nèi)容維度的關(guān)聯(lián)，用戶畫像的關(guān)聯(lián)，各種粒度的聚合，下游可以非常方便的使用實(shí)時(shí)數(shù)據(jù)。

四、方案選型

那就看下我們多維實(shí)時(shí)數(shù)據(jù)分析系統(tǒng)的方案選型，選型我們對(duì)比了行業(yè)內(nèi)的領(lǐng)先方案，選擇了最符合我們業(yè)務(wù)場(chǎng)景的方案。

第一塊是實(shí)時(shí)數(shù)倉(cāng)的選型，我們選擇的是業(yè)界比較成熟的Lambda架構(gòu)，他的優(yōu)點(diǎn)是靈活性高、容錯(cuò)性高、成熟度高和遷移成本低;缺點(diǎn)是實(shí)時(shí)、離線數(shù)據(jù)用兩套代碼，可能會(huì)存在一個(gè)口徑修改了，另一個(gè)沒(méi)改的問(wèn)題，我們每天都有做數(shù)據(jù)對(duì)賬的工作，如果有異常會(huì)進(jìn)行告警。

第二塊是實(shí)時(shí)計(jì)算引擎選型，因?yàn)镕link設(shè)計(jì)之初就是為了流處理，SparkStreaming嚴(yán)格來(lái)說(shuō)還是微批處理，Strom用的已經(jīng)不多了。再看Flink具有Exactly-once的準(zhǔn)確性、輕量級(jí)Checkpoint容錯(cuò)機(jī)制、低延時(shí)高吞吐和易用性高的特點(diǎn)，我們選擇了Flink作為實(shí)時(shí)計(jì)算引擎。

第三塊是實(shí)時(shí)存儲(chǔ)引擎，我們的要求就是需要有維度索引、支持高并發(fā)、預(yù)聚合、高性能實(shí)時(shí)多維OLAP查詢?？梢钥吹?，Hbase、Tdsql和ES都不能滿足要求，Druid有一個(gè)缺陷，它是按照時(shí)序劃分Segment，無(wú)法將同一個(gè)內(nèi)容，存放在同一個(gè)Segment上，計(jì)算全局TopN只能是近似值，所以我們選擇了最近兩年大火的MPP數(shù)據(jù)庫(kù)引擎ClickHouse。

五、設(shè)計(jì)目標(biāo)與設(shè)計(jì)難點(diǎn)

我們多維實(shí)時(shí)數(shù)據(jù)分析系統(tǒng)分為三大模塊：

實(shí)時(shí)計(jì)算引擎; 實(shí)時(shí)存儲(chǔ)引擎; App層。

難點(diǎn)主要在前兩個(gè)模塊：實(shí)時(shí)計(jì)算引擎和實(shí)時(shí)存儲(chǔ)引擎。

千萬(wàn)級(jí)/s的海量數(shù)據(jù)如何實(shí)時(shí)接入，并且進(jìn)行極低延遲維表關(guān)聯(lián); 實(shí)時(shí)存儲(chǔ)引擎如何支持高并發(fā)寫入、高可用分布式和高性能索引查詢，是比較難的。

這幾個(gè)模塊的具體實(shí)現(xiàn)，看一下我們系統(tǒng)的架構(gòu)設(shè)計(jì)。

六、架構(gòu)設(shè)計(jì)

前端采用的是開源組件Ant Design，利用了Nginx服務(wù)器，部署靜態(tài)頁(yè)面，并反向代理了瀏覽器的請(qǐng)求到后臺(tái)服務(wù)器上。

后臺(tái)服務(wù)是基于騰訊自研的RPC后臺(tái)服務(wù)框架寫的，并且會(huì)進(jìn)行一些二級(jí)緩存。

實(shí)時(shí)數(shù)倉(cāng)部分，分為了接入層、實(shí)時(shí)計(jì)算層和實(shí)時(shí)數(shù)倉(cāng)存儲(chǔ)層。

接入層主要是從千萬(wàn)級(jí)/s的原始消息隊(duì)列中，拆分出不同行為數(shù)據(jù)的微隊(duì)列，拿看點(diǎn)的視頻來(lái)說(shuō)，拆分過(guò)后，數(shù)據(jù)就只有百萬(wàn)級(jí)/s了; 實(shí)時(shí)計(jì)算層主要負(fù)責(zé)，多行行為流水?dāng)?shù)據(jù)進(jìn)行行轉(zhuǎn)列，實(shí)時(shí)關(guān)聯(lián)用戶畫像數(shù)據(jù)和內(nèi)容維度數(shù)據(jù); 實(shí)時(shí)數(shù)倉(cāng)存儲(chǔ)層主要是設(shè)計(jì)出符合看點(diǎn)業(yè)務(wù)的，下游好用的實(shí)時(shí)消息隊(duì)列。我們暫時(shí)提供了兩個(gè)消息隊(duì)列，作為實(shí)時(shí)數(shù)倉(cāng)的兩層。一層DWM層是內(nèi)容ID-用戶ID粒度聚合的，就是一條數(shù)據(jù)包含內(nèi)容ID-用戶ID還有B側(cè)內(nèi)容數(shù)據(jù)、C側(cè)用戶數(shù)據(jù)和用戶畫像數(shù)據(jù);另一層是DWS層，是內(nèi)容ID粒度聚合的，一條數(shù)據(jù)包含內(nèi)容ID，B側(cè)數(shù)據(jù)和C側(cè)數(shù)據(jù)?？梢钥吹絻?nèi)容ID-用戶ID粒度的消息隊(duì)列流量進(jìn)一步減小到十萬(wàn)級(jí)/s，內(nèi)容ID粒度的更是萬(wàn)級(jí)/s，并且格式更加清晰，維度信息更加豐富。

實(shí)時(shí)存儲(chǔ)部分分為實(shí)時(shí)寫入層、OLAP存儲(chǔ)層和后臺(tái)接口層。

實(shí)時(shí)寫入層主要是負(fù)責(zé)Hash路由將數(shù)據(jù)寫入; OLAP存儲(chǔ)層利用MPP存儲(chǔ)引擎，設(shè)計(jì)符合業(yè)務(wù)的索引和物化視圖，高效存儲(chǔ)海量數(shù)據(jù); 后臺(tái)接口層提供高效的多維實(shí)時(shí)查詢接口。

七、實(shí)時(shí)計(jì)算

這個(gè)系統(tǒng)最復(fù)雜的兩塊，實(shí)時(shí)計(jì)算和實(shí)時(shí)存儲(chǔ)。先介紹實(shí)時(shí)計(jì)算部分：分為實(shí)時(shí)關(guān)聯(lián)和實(shí)時(shí)數(shù)倉(cāng)。

1、實(shí)時(shí)高性能維表關(guān)聯(lián)

實(shí)時(shí)維表關(guān)聯(lián)這一塊難度在于。百萬(wàn)級(jí)/s的實(shí)時(shí)數(shù)據(jù)流，如果直接去關(guān)聯(lián)HBase，1分鐘的數(shù)據(jù)，關(guān)聯(lián)完HBase耗時(shí)是小時(shí)級(jí)的，會(huì)導(dǎo)致數(shù)據(jù)延遲嚴(yán)重。

我們提出了幾個(gè)解決方案：

第一個(gè)是，在Flink實(shí)時(shí)計(jì)算環(huán)節(jié)，先按照1分鐘進(jìn)行了窗口聚合，將窗口內(nèi)多行行為數(shù)據(jù)轉(zhuǎn)一行多列的數(shù)據(jù)格式，經(jīng)過(guò)這一步操作，原本小時(shí)級(jí)的關(guān)聯(lián)耗時(shí)下降到了十幾分鐘，但是還是不夠的。

第二個(gè)是，在訪問(wèn)HBase內(nèi)容之前設(shè)置一層Redis緩存，因?yàn)?000條數(shù)據(jù)訪問(wèn)HBase是秒級(jí)的，而訪問(wèn)Redis是毫秒級(jí)的，訪問(wèn)Redis的速度基本是訪問(wèn)HBase的1000倍。為了防止過(guò)期的數(shù)據(jù)浪費(fèi)緩存，緩存過(guò)期時(shí)間設(shè)置成24小時(shí)，同時(shí)通過(guò)監(jiān)聽(tīng)寫HBase Proxy來(lái)保證緩存的一致性。這樣將訪問(wèn)時(shí)間從十幾分鐘變成了秒級(jí)。

第三個(gè)是，上報(bào)過(guò)程中會(huì)上報(bào)不少非常規(guī)內(nèi)容ID，這些內(nèi)容ID在內(nèi)容HBase中是不存儲(chǔ)的，會(huì)造成緩存穿透的問(wèn)題。所以在實(shí)時(shí)計(jì)算的時(shí)候，我們直接過(guò)濾掉這些內(nèi)容ID，防止緩存穿透，又減少一些時(shí)間。

第四個(gè)是，因?yàn)樵O(shè)置了定時(shí)緩存，會(huì)引入一個(gè)緩存雪崩的問(wèn)題。為了防止雪崩，我們?cè)趯?shí)時(shí)計(jì)算中，進(jìn)行了削峰填谷的操作，錯(cuò)開設(shè)置緩存的時(shí)間。

可以看到，優(yōu)化前后，數(shù)據(jù)量從百億級(jí)減少到了十億級(jí)，耗時(shí)從小時(shí)級(jí)減少到了數(shù)十秒，減少99%。

2、下游提供服務(wù)

實(shí)時(shí)數(shù)倉(cāng)的難度在于：它處于比較新的領(lǐng)域，并且各個(gè)公司各個(gè)業(yè)務(wù)差距比較大，怎么能設(shè)計(jì)出方便，好用，符合看點(diǎn)業(yè)務(wù)場(chǎng)景的實(shí)時(shí)數(shù)倉(cāng)是有難度的。

先看一下實(shí)時(shí)數(shù)倉(cāng)做了什么，實(shí)時(shí)數(shù)倉(cāng)對(duì)外就是幾個(gè)消息隊(duì)列，不同的消息隊(duì)列里面存放的就是不同聚合粒度的實(shí)時(shí)數(shù)據(jù)，包括內(nèi)容ID、用戶ID、C側(cè)行為數(shù)據(jù)、B側(cè)內(nèi)容維度數(shù)據(jù)和用戶畫像數(shù)據(jù)等。

我們是怎么搭建實(shí)時(shí)數(shù)倉(cāng)的，就是上面介紹的實(shí)時(shí)計(jì)算引擎的輸出，放到消息隊(duì)列中保存，可以提供給下游多用戶復(fù)用。

我們可以看下，在我們建設(shè)實(shí)時(shí)數(shù)據(jù)倉(cāng)庫(kù)前后，開發(fā)一個(gè)實(shí)時(shí)應(yīng)用的區(qū)別。沒(méi)有數(shù)倉(cāng)的時(shí)候，我們需要消費(fèi)千萬(wàn)級(jí)/s的原始隊(duì)列，進(jìn)行復(fù)雜的數(shù)據(jù)清洗，然后再進(jìn)行用戶畫像關(guān)聯(lián)、內(nèi)容維度關(guān)聯(lián)，才能拿到符合要求格式的實(shí)時(shí)數(shù)據(jù)，開發(fā)和擴(kuò)展的成本都會(huì)比較高，如果想開發(fā)一個(gè)新的應(yīng)用，又要走一遍這個(gè)流程。有了數(shù)倉(cāng)之后，如果想開發(fā)內(nèi)容ID粒度的實(shí)時(shí)應(yīng)用，就直接申請(qǐng)TPS萬(wàn)級(jí)/s的DWS層的消息隊(duì)列。開發(fā)成本變低很多，資源消耗小很多，可擴(kuò)展性也強(qiáng)很多。

看個(gè)實(shí)際例子，開發(fā)我們系統(tǒng)的實(shí)時(shí)數(shù)據(jù)大屏，原本需要進(jìn)行如上所有操作，才能拿到數(shù)據(jù)?，F(xiàn)在只需要消費(fèi)DWS層消息隊(duì)列，寫一條Flink SQL即可，僅消耗2個(gè)cpu核心，1G內(nèi)存。

可以看到，以50個(gè)消費(fèi)者為例，建立實(shí)時(shí)數(shù)倉(cāng)前后，下游開發(fā)一個(gè)實(shí)時(shí)應(yīng)用，可以減少98%的資源消耗。包括計(jì)算資源，存儲(chǔ)資源，人力成本和開發(fā)人員學(xué)習(xí)接入成本等等。并且消費(fèi)者越多，節(jié)省越多。就拿Redis存儲(chǔ)這一部分來(lái)說(shuō)，一個(gè)月就能省下上百萬(wàn)人民幣。

八、實(shí)時(shí)存儲(chǔ)

介紹完實(shí)時(shí)計(jì)算，再來(lái)介紹實(shí)時(shí)存儲(chǔ)。這塊分為三個(gè)部分來(lái)介紹：

分布式-高可用; 海量數(shù)據(jù)-寫入; 高性能-查詢。

1、分布式-高可用

我們這里聽(tīng)取的是Clickhouse官方的建議，借助ZK實(shí)現(xiàn)高可用的方案。數(shù)據(jù)寫入一個(gè)分片，僅寫入一個(gè)副本，然后再寫ZK，通過(guò)ZK告訴同一個(gè)分片的其他副本，其他副本再過(guò)來(lái)拉取數(shù)據(jù)，保證數(shù)據(jù)一致性。

這里沒(méi)有選用消息隊(duì)列進(jìn)行數(shù)據(jù)同步，是因?yàn)閆K更加輕量級(jí)。而且寫的時(shí)候，任意寫一個(gè)副本，其它副本都能夠通過(guò)ZK獲得一致的數(shù)據(jù)。而且就算其它節(jié)點(diǎn)第一次來(lái)獲取數(shù)據(jù)失敗了，后面只要發(fā)現(xiàn)它跟ZK上記錄的數(shù)據(jù)不一致，就會(huì)再次嘗試獲取數(shù)據(jù)，保證一致性。

2、海量數(shù)據(jù)-寫入

數(shù)據(jù)寫入遇到的第一個(gè)問(wèn)題是，海量數(shù)據(jù)直接寫入Clickhouse的話，會(huì)導(dǎo)致ZK的QPS太高，解決方案是改用Batch方式寫入。Batch設(shè)置多大呢，Batch太小的話緩解不了ZK的壓力，Batch也不能太大，不然上游內(nèi)存壓力太大，通過(guò)實(shí)驗(yàn)，最終我們選用了大小幾十萬(wàn)的Batch。

第二個(gè)問(wèn)題是，隨著數(shù)據(jù)量的增長(zhǎng)，單QQ看點(diǎn)的視頻內(nèi)容每天可能寫入百億級(jí)的數(shù)據(jù)，默認(rèn)方案是寫一張分布式表，這就會(huì)造成單臺(tái)機(jī)器出現(xiàn)磁盤的瓶頸，尤其是Clickhouse底層運(yùn)用的是Mergetree，原理類似于HBase、RocketsDb的底層LSM-Tree。在合并的過(guò)程中會(huì)存在寫放大的問(wèn)題，加重磁盤壓力。峰值每分鐘幾千萬(wàn)條數(shù)據(jù)，寫完耗時(shí)幾十秒，如果正在做Merge，就會(huì)阻塞寫入請(qǐng)求，查詢也會(huì)非常慢。我們做的兩個(gè)優(yōu)化方案：一是對(duì)磁盤做Raid，提升磁盤的IO;二是在寫入之前進(jìn)行分表，直接分開寫入到不同的分片上，磁盤壓力直接變?yōu)?/N。

第三個(gè)問(wèn)題是，雖然我們寫入按照分片進(jìn)行了劃分，但是這里引入了一個(gè)分布式系統(tǒng)常見(jiàn)的問(wèn)題，就是局部的Top并非全局Top的問(wèn)題。比如同一個(gè)內(nèi)容ID的數(shù)據(jù)落在了不同的分片上，計(jì)算全局Top100閱讀的內(nèi)容ID，有一個(gè)內(nèi)容ID在分片1上是Top100，但是在其它分片上不是Top100，導(dǎo)致匯總的時(shí)候，會(huì)丟失一部分?jǐn)?shù)據(jù)，影響最終結(jié)果。我們做的優(yōu)化是在寫入之前加上一層路由，將同一個(gè)內(nèi)容ID的記錄，全部路由到同一個(gè)分片上，解決了該問(wèn)題。

介紹完寫入，下一步介紹Clickhouse的高性能存儲(chǔ)和查詢。

3、高性能-存儲(chǔ)-查詢

Clickhouse高性能查詢的一個(gè)關(guān)鍵點(diǎn)是稀疏索引。稀疏索引這個(gè)設(shè)計(jì)就很有講究，設(shè)計(jì)得好可以加速查詢，設(shè)計(jì)不好反而會(huì)影響查詢效率。我根據(jù)我們的業(yè)務(wù)場(chǎng)景，因?yàn)槲覀兊牟樵兇蟛糠侄际菚r(shí)間和內(nèi)容ID相關(guān)的，比如說(shuō)，某個(gè)內(nèi)容，過(guò)去N分鐘在各個(gè)人群表現(xiàn)如何?我按照日期，分鐘粒度時(shí)間和內(nèi)容ID建立了稀疏索引。針對(duì)某個(gè)內(nèi)容的查詢，建立稀疏索引之后，可以減少99%的文件掃描。

還有一個(gè)問(wèn)題就是，我們現(xiàn)在數(shù)據(jù)量太大，維度太多。拿QQ看點(diǎn)的視頻內(nèi)容來(lái)說(shuō)，一天流水有上百億條，有些維度有幾百個(gè)類別。如果一次性把所有維度進(jìn)行預(yù)聚合，數(shù)據(jù)量會(huì)指數(shù)膨脹，查詢反而變慢，并且會(huì)占用大量?jī)?nèi)存空間。我們的優(yōu)化，針對(duì)不同的維度，建立對(duì)應(yīng)的預(yù)聚合物化視圖，用空間換時(shí)間，這樣可以縮短查詢的時(shí)間。

分布式表查詢還會(huì)有一個(gè)問(wèn)題，查詢單個(gè)內(nèi)容ID的信息，分布式表會(huì)將查詢下發(fā)到所有的分片上，然后再返回查詢結(jié)果進(jìn)行匯總。實(shí)際上，因?yàn)樽鲞^(guò)路由，一個(gè)內(nèi)容ID只存在于一個(gè)分片上，剩下的分片都在空跑。針對(duì)這類查詢，我們的優(yōu)化是后臺(tái)按照同樣的規(guī)則先進(jìn)行路由，直接查詢目標(biāo)分片，這樣減少了N-1/N的負(fù)載，可以大量縮短查詢時(shí)間。而且由于我們是提供的OLAP查詢，數(shù)據(jù)滿足最終一致性即可，通過(guò)主從副本讀寫分離，可以進(jìn)一步提升性能。

我們?cè)诤笈_(tái)還做了一個(gè)1分鐘的數(shù)據(jù)緩存，針對(duì)相同條件查詢，后臺(tái)就直接返回了。

4、擴(kuò)容

這里再介紹一下我們的擴(kuò)容的方案，調(diào)研了業(yè)內(nèi)的一些常見(jiàn)方案。

比如HBase，原始數(shù)據(jù)都存放在HDFS上，擴(kuò)容只是Region Server擴(kuò)容，不涉及原始數(shù)據(jù)的遷移。但是Clickhouse的每個(gè)分片數(shù)據(jù)都是在本地，是一個(gè)比較底層存儲(chǔ)引擎，不能像HBase那樣方便擴(kuò)容。

Redis是哈希槽這種類似一致性哈希的方式，是比較經(jīng)典分布式緩存的方案。Redis slot在Rehash的過(guò)程中雖然存在短暫的ask讀不可用，但是總體來(lái)說(shuō)遷移是比較方便的，從原h(huán)[0]遷移到h[1]，最后再刪除h[0]。但是Clickhouse大部分都是OLAP批量查詢，不是點(diǎn)查，而且由于列式存儲(chǔ)，不支持刪除的特性，一致性哈希的方案不是很適合。

目前擴(kuò)容的方案是，另外消費(fèi)一份數(shù)據(jù)，寫入新Clickhouse集群，兩個(gè)集群一起跑一段時(shí)間，因?yàn)閷?shí)時(shí)數(shù)據(jù)就保存3天，等3天之后，后臺(tái)服務(wù)直接訪問(wèn)新集群。

九、成果

騰訊看點(diǎn)實(shí)時(shí)數(shù)據(jù)倉(cāng)庫(kù)：DWM層和DWS層，數(shù)據(jù)延遲1分鐘。

遠(yuǎn)見(jiàn)多維實(shí)時(shí)數(shù)據(jù)分析系統(tǒng)：亞秒級(jí)響應(yīng)多維條件查詢請(qǐng)求，在未命中緩存情況下，過(guò)去30分鐘的查詢，99%的請(qǐng)求耗時(shí)在1秒內(nèi);過(guò)去24小時(shí)的查詢，90%的請(qǐng)求耗時(shí)在5秒內(nèi)，99%的請(qǐng)求耗時(shí)在10秒內(nèi)。

關(guān)鍵詞：