導語
當業務發展到一定規模，實時數據倉庫是一個必要的基礎服務。從數據驅動方面考慮，多維實時數據分析系統的重要性也不言而喻。但是當數據量巨大的情況下，拿騰訊看點來說，一天上報的數據量達到萬億級的規模，要實現極低延遲的實時計算和亞秒級的多維實時查詢是有技術挑戰的。本文將介紹一下信息流場景下，騰訊看點的實時數據倉庫和多維實時數據分析系統的技術架構。
一、可解決的痛點
可以先看一下，多維實時數據分析系統可以解決哪些痛點。比如：
推薦同學10分鐘前上了一個推薦策略，想知道在不同人群的推薦效果怎麼樣？
運營同學想知道，在廣東省的用戶中，最火的廣東地域內容是哪些，方便做地域Push。
審核同學想知道，過去5分鐘，遊戲類被舉報最多的內容和帳號是哪些？
老闆可能想了解，過去10分鐘有多少用戶在看點消費了內容，對消費人群有一個宏觀了解。
二、調研
在進行開發之前，我們做了這些調研。
1.離線數據分析平臺能否滿足這些需求，結論是不能滿足。離線數據分析平臺不行的原因如下：
C側數據上報過來，需要經過Spark的多層離線計算，最終結果出庫到Mysql或者ES提供給離線分析平臺查詢。這個過程的延時最少3-6個小時，目前比較常見的都是提供隔天的查詢，所以很多實時性要求高的業務場景都是不能滿足的； 另一個問題是，騰訊看點的數據量太大，帶來的不穩定性也比較大，經常會有預料不到的延遲。所以，離線分析平臺是無法滿足很多需求的。
2.實時數據分析平臺的話，事業群內部提供了準實時數據查詢的功能，底層技術用的是Kudu+Impala，Impala雖然是MPP架構的大數據計算引擎，並且訪問以列式存儲數據的Kudu。但是對於實時數據分析場景來說，查詢響應的速度和數據的延遲都還是比較高，查詢一次實時DAU，返回結果耗時至少幾分鐘，無法提供良好的交互式用戶體驗。
所以（Kudu+Impala）這種通用大數據處理框架的速度優勢更多的是相比（Spark+Hdfs）這種離線分析框架來說的，對於我們這個實時性要求更高的場景，是無法滿足的。
三、項目背景
經過剛才的介紹，再來看下我們這個項目的背景。
作者發文的內容被內容中心引入，經過內容審核鏈路，啟用或者下架。啟用的內容給到推薦系統和運營系統，然後推薦系統和運營系統將內容進行C側分發。內容分發給C側用戶之後，用戶會產生各種行為，曝光、點擊、舉報等，通過埋點上報實時接入到消息隊列中。
接下來我們做了兩部分工作，就是圖中有顏色的這兩部分。
第一部分構建了一個騰訊看點的實時數據倉庫；第二部分就是基於OLAP存儲引擎，開發了多維實時數據分析系統。
我們為什麼要構建實時數倉，因為原始的上報數據量非常大，一天上報峰值就有上萬億條。而且上報格式混亂。缺乏內容維度信息、用戶畫像信息，下遊沒辦法直接使用。而我們提供的實時數倉，是根據騰訊看點信息流的業務場景，進行了內容維度的關聯，用戶畫像的關聯，各種粒度的聚合，下遊可以非常方便的使用實時數據。
四、方案選型
那就看下我們多維實時數據分析系統的方案選型，選型我們對比了行業內的領先方案，選擇了最符合我們業務場景的方案。
第一塊是實時數倉的選型，我們選擇的是業界比較成熟的Lambda架構，他的優點是靈活性高、容錯性高、成熟度高和遷移成本低；缺點是實時、離線數據用兩套代碼，可能會存在一個口徑修改了，另一個沒改的問題，我們每天都有做數據對帳的工作，如果有異常會進行告警。
第二塊是實時計算引擎選型，因為Flink設計之初就是為了流處理，SparkStreaming嚴格來說還是微批處理，Strom用的已經不多了。再看Flink具有Exactly-once的準確性、輕量級Checkpoint容錯機制、低延時高吞吐和易用性高的特點，我們選擇了Flink作為實時計算引擎。
第三塊是實時存儲引擎，我們的要求就是需要有維度索引、支持高並發、預聚合、高性能實時多維OLAP查詢。可以看到，Hbase、Tdsql和ES都不能滿足要求，Druid有一個缺陷，它是按照時序劃分Segment，無法將同一個內容，存放在同一個Segment上，計算全局TopN只能是近似值，所以我們選擇了最近兩年大火的MPP資料庫引擎ClickHouse。
五、設計目標與設計難點
我們多維實時數據分析系統分為三大模塊：
實時計算引擎； 實時存儲引擎； App層。
難點主要在前兩個模塊：實時計算引擎和實時存儲引擎。
千萬級/s的海量數據如何實時接入，並且進行極低延遲維表關聯； 實時存儲引擎如何支持高並發寫入、高可用分布式和高性能索引查詢，是比較難的。
這幾個模塊的具體實現，看一下我們系統的架構設計。
六、架構設計
前端採用的是開源組件Ant Design，利用了Nginx伺服器，部署靜態頁面，並反向代理了瀏覽器的請求到後臺伺服器上。
後臺服務是基於騰訊自研的RPC後臺服務框架寫的，並且會進行一些二級緩存。
實時數倉部分，分為了接入層、實時計算層和實時數倉存儲層。
接入層主要是從千萬級/s的原始消息隊列中，拆分出不同行為數據的微隊列，拿看點的視頻來說，拆分過後，數據就只有百萬級/s了； 實時計算層主要負責，多行行為流水數據進行行轉列，實時關聯用戶畫像數據和內容維度數據； 實時數倉存儲層主要是設計出符合看點業務的，下遊好用的實時消息隊列。我們暫時提供了兩個消息隊列，作為實時數倉的兩層。一層DWM層是內容ID-用戶ID粒度聚合的，就是一條數據包含內容ID-用戶ID還有B側內容數據、C側用戶數據和用戶畫像數據；另一層是DWS層，是內容ID粒度聚合的，一條數據包含內容ID，B側數據和C側數據。可以看到內容ID-用戶ID粒度的消息隊列流量進一步減小到十萬級/s，內容ID粒度的更是萬級/s，並且格式更加清晰，維度信息更加豐富。
實時存儲部分分為實時寫入層、OLAP存儲層和後臺接口層。
實時寫入層主要是負責Hash路由將數據寫入； OLAP存儲層利用MPP存儲引擎，設計符合業務的索引和物化視圖，高效存儲海量數據； 後臺接口層提供高效的多維實時查詢接口。
七、實時計算
這個系統最複雜的兩塊，實時計算和實時存儲。先介紹實時計算部分：分為實時關聯和實時數倉。
1、實時高性能維表關聯
實時維表關聯這一塊難度在於。百萬級/s的實時數據流，如果直接去關聯HBase，1分鐘的數據，關聯完HBase耗時是小時級的，會導致數據延遲嚴重。
我們提出了幾個解決方案：
第一個是，在Flink實時計算環節，先按照1分鐘進行了窗口聚合，將窗口內多行行為數據轉一行多列的數據格式，經過這一步操作，原本小時級的關聯耗時下降到了十幾分鐘，但是還是不夠的。
第二個是，在訪問HBase內容之前設置一層Redis緩存，因為1000條數據訪問HBase是秒級的，而訪問Redis是毫秒級的，訪問Redis的速度基本是訪問HBase的1000倍。為了防止過期的數據浪費緩存，緩存過期時間設置成24小時，同時通過監聽寫HBase Proxy來保證緩存的一致性。這樣將訪問時間從十幾分鐘變成了秒級。
第三個是，上報過程中會上報不少非常規內容ID，這些內容ID在內容HBase中是不存儲的，會造成緩存穿透的問題。所以在實時計算的時候，我們直接過濾掉這些內容ID，防止緩存穿透，又減少一些時間。
第四個是，因為設置了定時緩存，會引入一個緩存雪崩的問題。為了防止雪崩，我們在實時計算中，進行了削峰填谷的操作，錯開設置緩存的時間。
可以看到，優化前後，數據量從百億級減少到了十億級，耗時從小時級減少到了數十秒，減少99%。
2、下遊提供服務
實時數倉的難度在於：它處於比較新的領域，並且各個公司各個業務差距比較大，怎麼能設計出方便，好用，符合看點業務場景的實時數倉是有難度的。
先看一下實時數倉做了什麼，實時數倉對外就是幾個消息隊列，不同的消息隊列裡面存放的就是不同聚合粒度的實時數據，包括內容ID、用戶ID、C側行為數據、B側內容維度數據和用戶畫像數據等。
我們是怎麼搭建實時數倉的，就是上面介紹的實時計算引擎的輸出，放到消息隊列中保存，可以提供給下遊多用戶復用。
我們可以看下，在我們建設實時數據倉庫前後，開發一個實時應用的區別。沒有數倉的時候，我們需要消費千萬級/s的原始隊列，進行複雜的數據清洗，然後再進行用戶畫像關聯、內容維度關聯，才能拿到符合要求格式的實時數據，開發和擴展的成本都會比較高，如果想開發一個新的應用，又要走一遍這個流程。有了數倉之後，如果想開發內容ID粒度的實時應用，就直接申請TPS萬級/s的DWS層的消息隊列。開發成本變低很多，資源消耗小很多，可擴展性也強很多。
看個實際例子，開發我們系統的實時數據大屏，原本需要進行如上所有操作，才能拿到數據。現在只需要消費DWS層消息隊列，寫一條Flink SQL即可，僅消耗2個cpu核心，1G內存。
可以看到，以50個消費者為例，建立實時數倉前後，下遊開發一個實時應用，可以減少98%的資源消耗。包括計算資源，存儲資源，人力成本和開發人員學習接入成本等等。並且消費者越多，節省越多。就拿Redis存儲這一部分來說，一個月就能省下上百萬人民幣。
八、實時存儲
介紹完實時計算，再來介紹實時存儲。這塊分為三個部分來介紹：
分布式-高可用； 海量數據-寫入； 高性能-查詢。
1、分布式-高可用
我們這裡聽取的是Clickhouse官方的建議，藉助ZK實現高可用的方案。數據寫入一個分片，僅寫入一個副本，然後再寫ZK，通過ZK告訴同一個分片的其他副本，其他副本再過來拉取數據，保證數據一致性。
這裡沒有選用消息隊列進行數據同步，是因為ZK更加輕量級。而且寫的時候，任意寫一個副本，其它副本都能夠通過ZK獲得一致的數據。而且就算其它節點第一次來獲取數據失敗了，後面只要發現它跟ZK上記錄的數據不一致，就會再次嘗試獲取數據，保證一致性。
2、海量數據-寫入
數據寫入遇到的第一個問題是，海量數據直接寫入Clickhouse的話，會導致ZK的QPS太高，解決方案是改用Batch方式寫入。Batch設置多大呢，Batch太小的話緩解不了ZK的壓力，Batch也不能太大，不然上遊內存壓力太大，通過實驗，最終我們選用了大小几十萬的Batch。
第二個問題是，隨著數據量的增長，單QQ看點的視頻內容每天可能寫入百億級的數據，默認方案是寫一張分布式表，這就會造成單臺機器出現磁碟的瓶頸，尤其是Clickhouse底層運用的是Mergetree，原理類似於HBase、RocketsDb的底層LSM-Tree。在合併的過程中會存在寫放大的問題，加重磁碟壓力。峰值每分鐘幾千萬條數據，寫完耗時幾十秒，如果正在做Merge，就會阻塞寫入請求，查詢也會非常慢。我們做的兩個優化方案：一是對磁碟做Raid，提升磁碟的IO；二是在寫入之前進行分表，直接分開寫入到不同的分片上，磁碟壓力直接變為1/N。
第三個問題是，雖然我們寫入按照分片進行了劃分，但是這裡引入了一個分布式系統常見的問題，就是局部的Top並非全局Top的問題。比如同一個內容ID的數據落在了不同的分片上，計算全局Top100閱讀的內容ID，有一個內容ID在分片1上是Top100，但是在其它分片上不是Top100，導致匯總的時候，會丟失一部分數據，影響最終結果。我們做的優化是在寫入之前加上一層路由，將同一個內容ID的記錄，全部路由到同一個分片上，解決了該問題。
介紹完寫入，下一步介紹Clickhouse的高性能存儲和查詢。
3、高性能-存儲-查詢
Clickhouse高性能查詢的一個關鍵點是稀疏索引。稀疏索引這個設計就很有講究，設計得好可以加速查詢，設計不好反而會影響查詢效率。我根據我們的業務場景，因為我們的查詢大部分都是時間和內容ID相關的，比如說，某個內容，過去N分鐘在各個人群表現如何？我按照日期，分鐘粒度時間和內容ID建立了稀疏索引。針對某個內容的查詢，建立稀疏索引之後，可以減少99%的文件掃描。
還有一個問題就是，我們現在數據量太大，維度太多。拿QQ看點的視頻內容來說，一天流水有上百億條，有些維度有幾百個類別。如果一次性把所有維度進行預聚合，數據量會指數膨脹，查詢反而變慢，並且會佔用大量內存空間。我們的優化，針對不同的維度，建立對應的預聚合物化視圖，用空間換時間，這樣可以縮短查詢的時間。
分布式表查詢還會有一個問題，查詢單個內容ID的信息，分布式表會將查詢下發到所有的分片上，然後再返回查詢結果進行匯總。實際上，因為做過路由，一個內容ID只存在於一個分片上，剩下的分片都在空跑。針對這類查詢，我們的優化是後臺按照同樣的規則先進行路由，直接查詢目標分片，這樣減少了N-1/N的負載，可以大量縮短查詢時間。而且由於我們是提供的OLAP查詢，數據滿足最終一致性即可，通過主從副本讀寫分離，可以進一步提升性能。
我們在後臺還做了一個1分鐘的數據緩存，針對相同條件查詢，後臺就直接返回了。
4、擴容
這裡再介紹一下我們的擴容的方案，調研了業內的一些常見方案。
比如HBase，原始數據都存放在HDFS上，擴容只是Region Server擴容，不涉及原始數據的遷移。但是Clickhouse的每個分片數據都是在本地，是一個比較底層存儲引擎，不能像HBase那樣方便擴容。
Redis是哈希槽這種類似一致性哈希的方式，是比較經典分布式緩存的方案。Redis slot在Rehash的過程中雖然存在短暫的ask讀不可用，但是總體來說遷移是比較方便的，從原h[0]遷移到h[1]，最後再刪除h[0]。但是Clickhouse大部分都是OLAP批量查詢，不是點查，而且由於列式存儲，不支持刪除的特性，一致性哈希的方案不是很適合。
目前擴容的方案是，另外消費一份數據，寫入新Clickhouse集群，兩個集群一起跑一段時間，因為實時數據就保存3天，等3天之後，後臺服務直接訪問新集群。
九、成果
騰訊看點實時數據倉庫：DWM層和DWS層，數據延遲1分鐘。
遠見多維實時數據分析系統：亞秒級響應多維條件查詢請求，在未命中緩存情況下，過去30分鐘的查詢，99%的請求耗時在1秒內；過去24小時的查詢，90%的請求耗時在5秒內，99%的請求耗時在10秒內。