數據人看Feed流-架構實踐

背景

Feed流：能夠理解爲信息流，解決的是信息生產者與信息消費者之間的信息傳遞問題。
咱們常見的Feed流場景有：
1 手淘，微淘提供給消費者的首頁商品信息，用戶關注店鋪的新消息等
2 微信朋友圈，及時獲取朋友分享的信息
3 微博，粉絲獲取關注明星、大V的信息
4 頭條，用戶獲取系統推薦的新聞、評論、八卦

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

本文但願能夠提供兩點價值：

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

業務分析

Feed流參與者的價值

• 信息生產者

但願信息支持格式豐富（文字、圖片、視頻），發佈流暢（生產信息的可用性），訂閱者及時收到消息（時效性），訂閱者不漏消息（傳遞的可靠性）

• 信息消費者

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

• 平臺

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

Feed信息傳遞方式

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

Feed流的技術難點

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

新浪微博爲例，做爲移動社交時代的重量級社交分享平臺，2017年初日活躍用戶1.6億，月活躍用戶近3.3億，天天新增數億條數據，總數據量達千億級，核心單個業務的後端數據訪問QPS高達百萬級

截止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優化之路-合理的使用編碼壓縮

圖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來製造序列號

Rowkey	消息元數據列	狀態列	其它列
MD5(用戶ID)+用戶ID+序列號	消息ID、做者、發佈時間、關鍵字等	已讀、未讀

圖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流場景的持續優化和賦能！

原文連接 本文爲雲棲社區原創內容，未經容許不得轉載。