HBase實踐 | 數據人看Feed流-架構實踐

• 2019 年 10 月 7 日
• 筆記

背景

Feed流：可以理解為資訊流，解決的是資訊生產者與資訊消費者之間的資訊傳遞問題。 我們常見的Feed流場景有：

• 手淘，微淘提供給消費者的首頁商品資訊，用戶關注店鋪的新消息等
• 微信朋友圈，及時獲取朋友分享的資訊
• 微博，粉絲獲取關註明星、大V的資訊
• 頭條，用戶獲取系統推薦的新聞、評論、八卦

關於Feed流的架構設計，包括以上場景中的很多業內專家給出了相應的思考、設計和實踐。本人是大數據方向出身的技術人，所在的團隊參與了阿里手淘、微淘Feed流的存儲層相關服務，我們的HBase/Lindorm數據存儲產品在公有雲上也支援著Soul、趣頭條、惠頭條等一些受歡迎的新媒體、社交類產品。我們在數據存儲產品的功能、性能、可用性上的一些理解，希望對真實落地一個Feed流架構可以有一些幫助，以及一起探討Feed流的未來以及數據產品如何幫助Feed流進一步迭代。

本文希望可以提供兩點價值：

• Feed流當前的主流架構以及落地方案
• 一個初創公司如何選擇Feed流的架構演進路徑

業務分析

Feed流參與者的價值

• 資訊生產者

希望資訊支援格式豐富（文字、圖片、影片），發布流暢（生產資訊的可用性），訂閱者及時收到消息（時效性），訂閱者不漏消息（傳遞的可靠性）

• 資訊消費者

希望及時收到關注的消息（時效性），希望不錯過朋友、偶像的消息（傳遞的可靠性），希望獲得有價值的消息（解決資訊過載）

• 平台

希望吸引更多的生產者和消費者（PV、UV），用戶更長的停留時間，廣告、商品更高的轉化率

Feed資訊傳遞方式

一種是基於關係的消息傳遞，關係通過加好友、關注、訂閱等方式建立，可能是雙向的也可能是單向的。一種是基於推薦演算法的，系統根據用戶畫像、消息畫像利用標籤分類或者協同過濾等演算法向用戶推送消息。微信和微博偏向於基於關係，頭條、抖音偏向於基於推薦。

Feed流的技術難點

互聯網場景總是需要一定規模才能體現出技術的瓶頸，下面我們先看兩組公開數據：

新浪微博為例，作為移動社交時代的重量級社交分享平台，2017年初日活躍用戶1.6億，月活躍用戶近3.3億，每天新增數億條數據，總數據量達千億級，核心單個業務的後端數據訪問QPS高達百萬級（來自 Feed系統架構與Feed快取模型）

截止2016年12月底，頭條日活躍用戶7800W，月活躍用戶1.75億，單用戶平均使用時長76分鐘，用戶行為峰值150w+msg/s，每天訓練數據300T+（壓縮後），機器規模萬級別（來自 今日頭條推薦系統架構設計實踐）

上面還是兩大巨頭的歷史指標，假設一條消息1KB那麼千億消息約93TB的數據量，日增量在幾百GB規模且QPS高達百萬，因此需要一個具備高讀寫吞吐，擴展性良好的分散式存儲系統。用戶瀏覽新消息期望百毫秒響應，希望新消息在秒級或者至少1分鐘左右可見，對系統的實時性要求很高，這裡需要多級的快取架構。系統必須具備高可用，良好的容錯性。最後這個系統最好不要太貴。

因此我們需要一個高吞吐、易擴展、低延遲、高可用、低成本的Feed流架構。

主流架構

圖1是對Feed流的最簡單抽象，完成一個從生產者向消費者傳遞消息的過程。

圖1 Feed流簡單抽象

消息和關係

首先，用戶在APP側獲得的是一個Feed ID列表，這個列表不一定包含了所有的新消息，用戶也不一定每一個都打開瀏覽，如果傳遞整個消息非常浪費資源，因此產生出來的消息首先生成主體和索引兩個部分，其中索引包含了消息ID和元數據。其次一個應用總是存在關係，基於關係的傳遞是必不可少的，也因此一定有一個關係的存儲和查詢服務。

圖2 Feed流消息、關係的存儲

消息本身應該算是一種半結構化數據（包含文字，圖片，短影片，音頻，元數據等）。其讀寫吞吐量要求高，讀寫比例需要看具體場景。總的存儲空間大，需要很好的擴展性來支撐業務增長。消息可能會有多次更新，比如內容修改，瀏覽數，點贊數，轉發數（成熟的系統會獨立一個counter模組來服務這些元數據）以及標記刪除。消息一般不會永久保存，可能要在1年或者3年後刪除。

綜上，個人推薦使用HBase存儲

1. HBase支援結構化和半結構化數據；
2. 具有非常好的寫入性能，特別對於Feed流場景可以利用批量寫介面單機（32核64GB）達到幾十萬的寫入效率；
3. HBase具備非常平滑的水平擴展能力，自動進行Sharding和Balance；
4. HBase內置的BlockCache加上SSD盤可以提供ms級的高並發讀；
5. HBase的TTL特性可以自動的淘汰過期數據；
6. 利用數據複製搭建一個冷熱分離系統，新消息存儲在擁有SSD磁碟和大規格快取的熱庫，舊數據存儲在冷庫。
7. 運用編碼壓縮有效的控制存儲成本，見HBase優化之路-合理的使用編碼壓縮： https://yq.aliyun.com/articles/702370

圖3 使用HBase存儲Feed流消息

對於關係服務，其寫入操作是建立關係和刪除關係，讀取操作是獲取關係列表，邏輯上僅需要一個KV系統。如果數據量較少可以使用RDS，如果數據量較大推薦使用HBase。如果對關係的QPS壓力大可以考慮用Redis做快取。

圖4 用戶關係存儲

消息傳遞

講到Feed流一定會有關於推模式和拉模式的討論，推模式是把消息複製N次發送到N個用戶的收信箱，用戶想看消息時從自己的收信箱直接獲取。拉模式相反，生產者的消息寫入自己的發信箱，用戶想看消息時從關注的M個發信箱中收集消息。

圖5 消息傳遞的推模式和拉模式

推模式實現相對簡單，時效性也比較好。拉模式要想獲得好的性能需要多級的快取架構。推模式重寫，拉模式重讀，Feed流場景下寫的聚合效果要優於讀，寫可以大批量聚合。N越大，寫入造成的數據冗餘就越大。M越大，讀消耗的資源越大。

隨著業務的增長，推模式資源浪費會越發嚴重。原因在於兩點：第一存在著大量的殭屍帳號，以及大比例的非活躍用戶幾天或者半個月才登陸一次；第二資訊過載，資訊太多，重複資訊太多，垃圾資訊太多，用戶感覺有用的資訊少，消息的閱讀比例低。這種情況下推模式相當一部分在做無用功，白白浪費系統資源。

是推？是拉？還是混合？沒有最好的架構，只有適合的場景~

基於關係的傳遞

圖6是純推模式的架構，該架構有3個關鍵的部分

1. 非同步化。生產者提交消息首先寫入一個隊列，成功則表示發布成功，Dispatcher模組會非同步的處理消息。這一點非常關鍵，首先生產者的消息發布體驗非常好，不需要等待消息同步到粉絲的收信箱，發布延遲低成功率高；其次Dispatcher可以控制隊列的處理速度，可以有效的控制大V帳號造成的脈衝壓力。
2. 多級隊列。Dispatcher可以根據消費者的狀態，資訊的分類等劃分不同的處理方式，分配不同的資源。比如對於大V帳號的消息，當前活躍用戶選擇直接發送，保障消息的時效性，非活躍用戶放入隊列延遲發送。比如轉發多的消息可以優先處理等。隊列里的消息可以採用批量聚合寫的方式提高吞吐。
3. 收信箱。假如有兩億用戶，每個用戶保留最新2000條推送消息。即便存儲的是索引也是千億的規模。收信箱一般的表結構為用戶ID+消息序列 + 消息ID + 消息元數據，消息序列是一個遞增的ID，需要存儲一個偏移量表示上次讀到的消息序列ID。用戶讀取最新消息 select * from inbox where 消息序列 > offset。

圖6 基於關係傳遞的純推模式

推薦使用HBase實現收信箱

1. HBase單機批量寫能力在幾十萬並且可以水平擴展。
2. HBase的高效前綴掃描非常適合讀取最新的消息。
3. HBase的TTL功能可以對數據定義生命周期，高效的淘汰過期數據。
4. HBase的Filter過濾器和二級索引可以有效的實現Inbox的搜索能力。

消費者收信箱hbase表設計如下，其中序列號要保證遞增，一般用時間戳即可，特別高頻情況下可以用一個RDS來製造序列號

圖7是推拉結合的模式

• 增加發信箱，大V的發布進入其獨立的發信箱。非大V的發布直接發送到用戶的收信箱。其好處是解決大量的殭屍帳號和非活躍帳號的問題。用戶只有在請求新消息的時候（比如登陸、下拉消息框）才會去消耗系統資源。
• 發信箱的多級快取架構。一個大V可能有百萬粉絲，一條熱點消息的傳播窗口也會非常短，即短時間內會對發信箱中的同一條消息大量重複讀取，對系統挑戰很大。終態下我們可能會選擇兩級快取，收信箱數據還是要持久化的，否則升級或者宕機時數據就丟失了，所以第一層是一個分散式數據存儲，這個存儲推薦使用HBase，原因和Inbox類似。第二層使用redis快取加速，但是大V過大可能造成熱點問題還需要第三層本地快取。快取層的優化主要包括兩個方向：第一提高快取命中率，常用的方式是對數據進行編碼壓縮，第二保障快取的可用性，這裡涉及到對快取的冗餘。

圖7 基於關係傳遞的推拉混合模式

基於推薦的傳遞

圖8是基於推薦的模型，可以看出它是在推拉結合的模式上融合了推薦系統。

1. 引入畫像系統，保存用戶畫像、消息畫像（簡單情況下消息畫像可以放在消息元數據中）。畫像用於推薦系統演算法的輸入。
2. 引入了臨時收信箱，在資訊過載的場景中，非大V的消息也是總量很大，其中不免充斥著垃圾、冗餘消息，所以直接進入用戶收信箱不太合適。
3. 收信箱和發信箱都需要有良好的搜索能力，這是推薦系統高效運行的關鍵。Outbox有快取層，索引可以做到快取裡面；Inbox一般情況下二級索引可以滿足大部分需求，但如果用戶希望有全文索引或者任意維度的檢索能力，還需要引入搜索系統如Solr/ES

圖8 基於推薦的Feed流架構

用戶畫像使用HBase存儲

1. 畫像一般是稀疏表，畫像總維度可能在200+甚至更多，但單個用戶的維度可能在幾十，並且維度可能隨業務不斷變化。那麼HBase的Schema free和稀疏表的能力非常適合這個場景，易用且節省大量存儲空間。
2. 對畫像的訪問一般是單行讀，hbase本身單行Get的性能就非常好。阿里雲HBase在這個方向上做了非常多的優化，包括CCSMAP、SharedBucketCache、MemstoreBloomFilter、Index Encoding等，可以達到平均RT=1-2ms，單庫99.9% <100ms。阿里內部利用雙集群Dual Service可以做到 99.9% < 30ms，這一能力我們也在努力推到公有雲。hbase的讀吞吐隨機器數量水平擴展。

臨時收信箱使用雲HBase

1. HBase的讀寫高吞吐、低延遲能力，這裡不再重複。
2. HBase提供Filter和全局二級索引，滿足不同量級的搜索需求。
3. 阿里雲HBase融合HBase與Solr能力，提供低成本的全文索引、多維索引能力。

初創公司的迭代路徑

在業務發展的初期，用戶量和資源都沒有那麼多，團隊的人力投入也是有限的，不可能一上來就搞一個特別複雜的架構，「夠用」就行了，重要的是

1. 可以快速的交付
2. 系統要穩定
3. 未來可以從容的迭代，避免推倒重來

本人水平有限，根據自身的經驗向大家推薦一種迭代路徑以供參考，如有不同意見歡迎交流

起步架構如圖9，使用雲Kafka+雲HBase。如果對Inbox有檢索需求，建議使用HBase的scan+filter即可。

1. 消息分為主體和索引
2. 採用純推的模式
3. 採用非同步化

圖9 起步架構

數據量逐漸增大後，對推模式進一步迭代，主要需求是

1. 控制大V造成的寫入脈衝高峰
2. 控制存儲成本
3. 提升讀寫性能
4. 提升一定的Inbox搜索能力

進一步的迭代架構如圖10

1. 消息分為主體和索引
2. 採用純推的模式
3. 採用非同步化
4. 採用多級隊列解決大V問題
5. 採用冷熱分離降低存儲成本
6. 此時Inbox中的消息也很多，對搜索的需求增強，僅僅Scan+Filter不夠，可能需要二級索引

圖10 純推模式的演進

業務迅猛發展，消息和用戶增長迅速，殭屍帳號、非活躍帳號較多，資訊過載嚴重

1. 消息分為主體和索引
2. 採用推拉結合模式
3. 採用非同步化
4. 引入推薦系統
5. 採用冷熱分離降低存儲成本
6. Outbox採用多級快取提高讀取性能
7. Inbox增加二級索引提升搜索能力

使用雲Kafka+雲HBase+雲Redis

圖11 基於推薦的推拉混合架構

總結

Feed資訊流是互聯網場景中非常普遍的場景，遍佈於電商、社交、新媒體等APP，因此研究Feed流是非常有價值的一件事情。本文總結了Feed流的業務場景和主流架構，分析了不同場景、體量下技術的難點與瓶頸。對Dispatcher、Inbox、Outout幾個組件進行了詳細的演進介紹，提供了基於雲環境的落地方案。本人水平有限，希望可以拋磚引玉，歡迎大家一起探討。Feed流的架構演進還在持續，不同業務場景下還有哪些缺陷和痛點？數據產品如何從功能和性能上演進來支撐Feed流的持續發展？在這些問題的驅動下，雲HBase未來將會大力投入到Feed流場景的持續優化和賦能！

參考文獻

[1] Feed架構-我們做錯了什麼

https://timyang.net/architecture/feed-data-arch-cons/ [2] Feed系統架構與Feed快取模型

https://mp.weixin.qq.com/s/RmDLqQmXQAmtQrajoanNuA?utm_medium=hao.caibaojian.com&utm_source=hao.caibaojian.com [3] 系統架構設計實踐

https://yq.aliyun.com/download/602 [4] 架構和FEED架構分析

http://blog.sina.com.cn/s/blog_53b95aec0100ujim.html [5] feed流個性化推薦架構和演算法分享

https://blog.csdn.net/baymax_007/article/details/89853030