騰訊看點王展雄：實時數(shù)倉與多維實時分析系統(tǒng)搭建
近幾年，數(shù)字驅(qū)動的口號越喊越響，在這樣一個用數(shù)據(jù)說話的時代，數(shù)據(jù)在一定程度上決定企業(yè)的業(yè)務和決策。而從數(shù)據(jù)驅(qū)動的方面考慮，多維實時數(shù)據(jù)分析系統(tǒng)的重要性也不言而喻。但是當數(shù)據(jù)量巨大的情況下，企業(yè)對數(shù)據(jù)技術也提出了更高的要求，但是要實現(xiàn)極低延遲的實時計算和亞秒級的多維實時查詢還是有難度的。
以騰訊看點來說，一天上報的數(shù)據(jù)量達到萬億級的規(guī)模，企業(yè)要如何知道在不同人群的推薦效果怎么樣？在不同地域中最火的內(nèi)容分別是什么？被舉報最多的內(nèi)容和賬號是哪些？在某個時間段內(nèi)有多少用戶消費了內(nèi)容？在分享一開始，王展雄首先總結(jié)了多維實時數(shù)據(jù)分析系統(tǒng)可以解決的主要痛點問題，比如：- 推薦同學10分鐘前上了一個推薦策略，想知道在不同人群的推薦效果怎么樣？
- 運營同學想知道，在廣東省的用戶中，最火的廣東地域內(nèi)容是哪些？
- 審核同學想知道，過去5分鐘，游戲類被舉報最多的內(nèi)容和賬號是哪些？
- 老板可能想了解，過去10分鐘有多少用戶在看點消費了內(nèi)容？
騰訊看點在實時數(shù)倉與多維實時分析系統(tǒng)搭建之前，首先做的就是進行調(diào)研，即離線數(shù)據(jù)分析平臺能否解決以上這些需求？結(jié)論是不能。首先，C端的行為數(shù)據(jù)上報過來需要經(jīng)過Spark多層離線計算，把最終結(jié)果初步過ES，初步之后再提供離線數(shù)據(jù)平臺進行查詢。這個過程延時最少在3-6小時，目前最常見的就是隔天的查詢。加之騰訊看點的數(shù)據(jù)量大，穩(wěn)定性較弱，離線分析平臺難以滿足多樣化的需求。此外，企業(yè)內(nèi)部現(xiàn)有的準實時數(shù)據(jù)查詢平臺的底層技術用的是Kudu+Impala，Impala雖然是MPP架構(gòu)的大數(shù)據(jù)計算引擎，并且訪問以列式存儲數(shù)據(jù)的Kudu。但是Kudu+Impala這種通用大數(shù)據(jù)處理框架只是相比Spark+Hdfs這種離線分析框架而言具有速度優(yōu)勢，對于實時數(shù)據(jù)分析場景來說，查詢響應的速度和數(shù)據(jù)的延遲仍然比較高，無法滿足實時性要求更高的場景，無法提供良好的交互式用戶體驗。技術研發(fā)是要根據(jù)企業(yè)的業(yè)務需求進行的，騰訊看點內(nèi)容業(yè)務的運行模式是作者發(fā)布的內(nèi)容被內(nèi)容中心引入，經(jīng)過內(nèi)容審核鏈路，審核結(jié)果啟用或者下架。啟用的內(nèi)容給到推薦系統(tǒng)和運營系統(tǒng)，然后推薦系統(tǒng)和運營系統(tǒng)將內(nèi)容通過手機QQ、微信、QQ瀏覽器，還有一些獨立端的APP進行C側(cè)分發(fā)。內(nèi)容分發(fā)給C側(cè)用戶之后，用戶會產(chǎn)生各種行為，曝光、點擊、舉報等，通過埋點上報實時接入到消息隊列中。而工程技術人員接下來要做兩件事，一個是構(gòu)建騰訊看點的實時數(shù)據(jù)倉庫，另一個則是基于OLAP存儲引擎，開發(fā)多維實時數(shù)據(jù)分析系統(tǒng)。實時數(shù)據(jù)倉庫能夠按照信息流的業(yè)務場景進行內(nèi)部維度關聯(lián)、用戶畫像關聯(lián)，聚合各種內(nèi)容，提高下游使用實時數(shù)據(jù)的便捷性。多維實時數(shù)據(jù)分析系統(tǒng)可以實時分析系統(tǒng)消費了上一輪數(shù)據(jù)實時數(shù)據(jù)倉庫，然后利用了OLAP存儲計算引擎，讓海量的數(shù)據(jù)進行了高效的存儲，提供高性能的查詢。每種方案都有不足，騰訊看點對比行業(yè)內(nèi)的領先方案，最終選擇最符合企業(yè)業(yè)務場景的方案。- 實時數(shù)倉的選型：騰訊看點選擇了業(yè)界比較成熟的Lambda架構(gòu)，Lambda架構(gòu)具有靈活性高、容錯性高、成熟度高和遷移成本低眾多有點；缺點是實時、離線數(shù)據(jù)需要使用兩套代碼，可能業(yè)務邏輯修改了，但是批次沒有跟上。騰訊看點對這個問題的處理方法是每天都進行數(shù)據(jù)對賬工作，如果有異常則進行告警。
- 實時計算引擎選型：選擇了Flink作為實時計算引擎。因為Flink設計之初就是為了流處理，此外，F(xiàn)link還具有Exactly-once的準確性、輕量級Checkpoint容錯機制、低延時高吞吐和易用性高的特點，是最佳選擇。
- 實時存儲引擎選型：騰訊看點的業(yè)務對維度索引、支持高并發(fā)、預聚合、高性能實時多維OLAP查詢有要求，而Hbase、Tdsql和ES都不能滿足。Druid存在按照時序劃分Segment的缺陷，無法將同一個內(nèi)容，存放在同一個Segment上，計算全局TopN只能是近似值。綜合對比，最終選擇了MPP數(shù)據(jù)庫引擎ClickHouse。
騰訊看點的多維實時數(shù)據(jù)分析系統(tǒng)分為三大模塊：實時計算引擎、實時存儲引擎、App層。難點主要在實時計算引擎和實時存儲引擎兩個模塊：要實現(xiàn)千萬級/s的海量數(shù)據(jù)實時接入，并且進行極低延遲的實時維表關聯(lián)；實現(xiàn)高并發(fā)寫入、高可用分布式和高性能索引查詢。王展雄指出，騰訊看點的前端采用的是開源組件Ant Design，利用了Nginx服務器，部署靜態(tài)頁面，并反向代理了瀏覽器的請求到后臺服務器上。后臺服務是基于騰訊自研的RPC后臺服務框架寫的，并且會進行一些二級緩存。
實時數(shù)倉部分，分為了接入層、實時計算層和實時數(shù)倉存儲層。實時存儲部分分為實時寫入層、OLAP存儲層和后臺接口層。實時計算分為實時關聯(lián)和實時數(shù)倉。在實時高性能維表關聯(lián)上，王展雄指出，百萬級/s的實時數(shù)據(jù)流，如果直接去關聯(lián)HBase，1分鐘的數(shù)據(jù)，關聯(lián)完HBase耗時是小時級的，會導致數(shù)據(jù)延遲嚴重。- 第一個是，在Flink實時計算環(huán)節(jié)，先按照1分鐘進行了窗口聚合，將窗口內(nèi)多行行為數(shù)據(jù)轉(zhuǎn)一行多列的數(shù)據(jù)格式，經(jīng)過這一步操作，原本小時級的關聯(lián)耗時下降到了十幾分鐘，但是還是不夠的。
- 第二個是，在訪問HBase內(nèi)容之前設置一層Redis緩存，因為1000條數(shù)據(jù)訪問HBase是秒級的，而訪問Redis是毫秒級的，訪問Redis的速度基本是訪問HBase的1000倍。為了防止過期的數(shù)據(jù)浪費緩存，緩存過期時間設置成24小時，同時通過監(jiān)聽寫HBase Proxy來保證緩存的一致性，并將訪問時間從十幾分鐘變成了秒級。
- 第三個是，上報過程中會上報不少非常規(guī)內(nèi)容ID，這些內(nèi)容ID在內(nèi)容HBase中是不存儲的，會造成緩存穿透的問題。所以在實時計算的時候，系統(tǒng)直接過濾掉這些內(nèi)容ID，防止緩存穿透，又減少一些時間。
- 第四個是，因為設置了定時緩存，會引入一個緩存雪崩的問題。為了防止雪崩，我們在實時計算中，進行了削峰填谷的操作，錯開設置緩存的時間。
優(yōu)化后，數(shù)據(jù)量從百億級減少到了十億級，耗時從小時級減少到了數(shù)十秒，減少99%。而實時數(shù)倉的難度在于，它處于比較新的領域，并且各個公司各個業(yè)務差距比較大，要設計出方便，好用，符合看點業(yè)務場景的實時數(shù)倉是有難度的。實時數(shù)倉對外就是幾個消息隊列，不同的消息隊列里面存放的就是不同聚合粒度的實時數(shù)據(jù)，包括內(nèi)容ID、用戶ID、C側(cè)行為數(shù)據(jù)、B側(cè)內(nèi)容維度數(shù)據(jù)和用戶畫像數(shù)據(jù)等。騰訊看點搭建數(shù)倉通過上面介紹的實時計算引擎的輸出，放到消息隊列中保存，可以提供給下游多用戶復用。在沒有數(shù)倉的時候，需要消費千萬級/s的原始隊列，進行復雜的數(shù)據(jù)清洗，然后再進行用戶畫像關聯(lián)、內(nèi)容維度關聯(lián)，才能拿到符合要求格式的實時數(shù)據(jù)，開發(fā)和擴展的成本都會比較高，如果想開發(fā)一個新的應用，又要走一遍這個流程。有了數(shù)倉之后，如果想開發(fā)內(nèi)容ID粒度的實時應用，就直接申請TPS萬級/s的DWS層的消息隊列。開發(fā)成本變低很多，資源消耗小很多，可擴展性也強很多。開發(fā)騰訊看點系統(tǒng)的實時數(shù)據(jù)大屏，原本需要進行如上所有操作，才能拿到數(shù)據(jù)?，F(xiàn)在只需要消費DWS層消息隊列，寫一條Flink SQL即可，僅消耗2個cpu核心，1G內(nèi)存。可以看到，以50個消費者為例，建立實時數(shù)倉前后，下游開發(fā)一個實時應用，可以減少98%的資源消耗。包括計算資源，存儲資源，人力成本和開發(fā)人員學習接入成本等等。并且消費者越多，節(jié)省越多。就拿Redis存儲這一部分來說，一個月就能省下上百萬人民幣。表引擎以什么方式存儲？以什么方式加載？以及數(shù)據(jù)表又有什么特性？這些問題都與實時儲存技術相關。騰訊看點聽取了Clickhouse官方的建議，借助ZK實現(xiàn)高可用的方案。數(shù)據(jù)寫入一個分片，僅寫入一個副本，然后再寫ZK，通過ZK告訴同一個分片的其他副本，其他副本再過來拉取數(shù)據(jù)。ZK更加輕量級，寫的時候，任意寫一個副本，其它副本都能夠通過ZK獲得一致的數(shù)據(jù)。此外，即便其它節(jié)點第一次來獲取數(shù)據(jù)失敗了，后面只要發(fā)現(xiàn)它跟ZK上記錄的數(shù)據(jù)不一致，就會再次嘗試獲取數(shù)據(jù)，保證數(shù)據(jù)一致性。王展雄先生指出，數(shù)據(jù)寫入遇到的第一個問題是，海量數(shù)據(jù)直接寫入Clickhouse的話，會導致ZK的QPS太高，解決方案是改用Batch方式寫入。Batch設置多大呢，Batch太小的話緩解不了ZK的壓力，Batch也不能太大，不然上游內(nèi)存壓力太大，通過實驗，最終選用了大小幾十萬的Batch。第二個問題是，如果采取默認方案，隨著數(shù)據(jù)量的增長，會造成單臺機器出現(xiàn)磁盤的瓶頸，在合并的過程中會存在寫放大的問題，加重磁盤壓力。峰值每分鐘幾千萬條數(shù)據(jù)，寫完耗時幾十秒，如果正在做Merge，就會阻塞寫入請求，查詢也會非常慢。為此騰訊看點做了兩個優(yōu)化方案：一是對磁盤做Raid，提升磁盤的IO；二是在寫入之前進行分表，直接分開寫入到不同的分片上，磁盤壓力直接變?yōu)?/N。第三個問題是，雖然寫入按照分片進行了劃分，但是存在一個分布式系統(tǒng)常見的問題，就是局部的Top并非全局Top的問題，導致匯總的時候，會丟失一部分數(shù)據(jù)，影響最終結(jié)果。騰訊看點內(nèi)部在寫入之前加上一層路由，將同一個內(nèi)容ID的記錄，全部路由到同一個分片上，解決了該問題。Clickhouse高性能查詢的一個關鍵點是稀疏索引。稀疏索引這個設計就很有講究，設計得好可以加速查詢，設計不好反而會影響查詢效率。騰訊看點根據(jù)自身的業(yè)務場景，針對某個內(nèi)容的查詢，建立稀疏索引之后，可以減少99%的文件掃描。但是騰訊看點的數(shù)據(jù)量太大，維度太多，如果一次性把所有維度進行預聚合，數(shù)據(jù)量會指數(shù)膨脹，查詢反而變慢，并且會占用大量內(nèi)存空間。針對不同的維度，騰訊看點建立對應的預聚合物化視圖，用空間換時間，縮短查詢時間。此外，分布式表查詢還有一個問題，查詢單個內(nèi)容ID的信息，分布式表會將查詢下發(fā)到所有的分片上，然后再返回查詢結(jié)果進行匯總。實際上，因為做過路由，一個內(nèi)容ID只存在于一個分片上，剩下的分片都在空跑。針對這類查詢，騰訊看點的優(yōu)化方案是后臺按照同樣的規(guī)則先進行路由，直接查詢目標分片，這樣減少了N-1/N的負載，可以大量縮短查詢時間。而且由于我們是提供的OLAP查詢，數(shù)據(jù)滿足最終一致性即可，通過主從副本讀寫分離，可以進一步提升性能。在后臺再做一個1分鐘的數(shù)據(jù)緩存，針對相同條件查詢，后臺就直接返回了。
分享最后，王展雄指出，騰訊看點的實時分析系統(tǒng)力亞秒級的響應查詢請求，在未命中緩存情況下，過去30分鐘的查詢，99%的請求耗時在1秒內(nèi)；過去24小時的查詢，90%的請求耗時在5秒內(nèi)，99%的請求耗時在10秒內(nèi)。
本站僅提供存儲服務，所有內(nèi)容均由用戶發(fā)布，如發(fā)現(xiàn)有害或侵權內(nèi)容，請
點擊舉報。
