288      技術社區[雲棲]

表格存儲(TableStore)新功能Stream應用場景介紹

上麵一篇我們介紹了表格存儲新功能Stream, 下麵我們展開說一些場景，看看有了Stream後，哪些我們常見的應用場景可以更高效的設計和實現。

直播用戶行為分析和存儲

場景描述

現在視頻直播非常火熱，假如我們使用TableStore記錄用戶的每一次進入房間和離開房間，房間內的操作記錄等，並希望根據用戶的最近的觀看記錄，更新直播推薦列表。給主播提供近期收看其直播的用戶的屬性特征，幫助主播優化直播內容迎合觀眾。

表結構設計

數據存儲示例

設計好表結構後，我們看下具體如何存儲：
比如原始數據是：

2017/5/20 10:10:10的時候小王在進入房間001，主播5此時在房間1做直播
2017/5/20 10:12:30的時候小王在房間001點了讚
2017/5/20 10:15:06的時候小王在房間001送給主播鮮花
2017/5/20 10:15:16的時候小王在房間001關注了主播
2017/5/20 10:25:41的時候小王離開了房間001

主鍵

1. part_key：第一個主鍵，分區建，主要是為了負載均衡，保證數據可以均勻分布在所有機器上，提高並發度和性能。如果業務主鍵user_id可以保證均勻分布，那麼可以不需要這個主鍵。
2. user_id：第二個主鍵，用戶ID，可以是字符串也可以是數字，唯一標識一個用戶。
3. room_id：第三個主鍵，房間ID，每個直播房間我們可以認為有一個唯一的標識，可以是字符串也可以是數字。
4. timestamp：第四個主鍵，時間戳，表示某一個時刻，單位可以是秒或者毫秒，用來表示用戶產生操作的時間戳，記錄了操作的時間戳，我們可以用來分析用戶操作頻率，或者和直播內容進行關聯分析。
5. 至此，上述四個主鍵可以唯一確定某一個用戶在某一個時間點在某一個房間的操作數據。

屬性列

1. operation：操作類型，例如進入房間，離開房間，關注，購買，打賞等等。
2. actor_id：直播人的id。也就是主播的id，一些特殊活動下，可能會變成一個主播列表。
3. device：用戶訪問的設備類型。

除了上麵提到的一些基本屬性以外，我們也可以根據需求添加關注的屬性，例如用戶的訪問設備mac地址，ip地址等。

數據分析需求

如果我們現在想做一些運營分析，例如：

1. 最近10分鍾有多少用戶在房間內做了支付操作。
2. 最近用戶支付較多的房間主播有什麼共同屬性。
3. 過去一天什麼時間段，用戶房間內操作最活躍。
4. 對於某一個用戶，如何根據他最近的房間操作，例如離開了什麼樣的房間，在什麼樣的房間會滯留，推薦後續的直播內容。

從上麵的這些分析需求我們大體可以分為兩類：
1. 離線分析過去一段時間用戶操作行為，例如上麵的場景3
2. 實時分析最近用戶的行為，例如上麵的場景1，2，4

如何獲取增量數據

假設我們直接使用API根據時間來獲取增量數據，那麼我們需要先要得到所有的用戶id以及房間id，然後根據時間進行讀取。用戶數乘以房間數可能會是一個非常大的量，那麼我們的分析就難以保證實效性。有了增量通道，我們可以使用Stream Client，訂閱實時的增量數據。在Stream Client實現代碼把增量數據推送到流計算平台或者ODPS中，做定期的分析。

結構圖如下：

商品訂單係統

場景描述

假設，我們的係統已經使用表格存儲記錄每個用戶的訂單信息，現在我們希望根據訂單信息進行分析，近期的熱點商品，根據訂單更新采購庫存。

表結構設計

數據存儲示例

設計好表結構後，我們看下具體如何存儲：
比如原始數據是：

2017/5/20 10:12:20小王下了訂單，訂單號10005，購買了商品5，數量2，單價15，使用支付寶支付30元。

主鍵

1. part_key：第一個主鍵，分區建，主要是為了負載均衡，保證數據可以均勻分布在所有機器上，提高並發度和性能。如果業務主鍵user_id可以保證均勻分布，那麼可以不需要這個主鍵。
2. user_id：第二個主鍵，用戶ID，可以是字符串也可以是數字，唯一標識一個用戶。
3. timestamp：第三個主鍵，時間戳，表示某一個時刻，單位可以是秒或者毫秒，用來表示用戶訂單的時間戳。在這裏放置時間，是因為係統往往需要查詢某個用戶一段時間內的所有訂單信息。
4. order_id：第四個主鍵，訂單號。
5. 至此，上述四個主鍵可以唯一確定某一個用戶在某一個時間點下的一個訂單。

屬性列

1. commodity_id：購買商品的id。
2. price：購買商品的單價。
3. count：購買商品的總價。
4. total：訂單的總價。
5. payment_type：用戶支付類型。
6. status：訂單的狀態。

數據消費需求

針對訂單係統，我們需要一下功能：

1. 用戶可以快速查詢過去一段時間的所有訂單
2. 當有用戶下單後，我們需要更新我們的倉儲信息，當庫存少於一定數量後需要發起采購
3. 分析用戶的近期購買興趣，做購買推薦
4. 檢測異常訂單，例如某個用戶短時間內大量都買一個產品

針對需求1，我們的表設計再結合表格存儲的GetRange可以很方便的實現。
需求2，基於我們的增量可以很方便獲取近期的訂單，定期更新庫存。表格存儲即將發布的Stream對接FC（敬請期待），可以做到完全的無服務器觸發整個流程，實現訂單，庫存的自動化管理。
需求3和4，如果希望依賴ODPS做離線分析，可以使用DATAX結合我們的Stream Reader插件將數據導入opds進行分析。如果希望接入其他流計算平台，可以使用Stream Client訂閱增量數據。

基於Stream實現屬性高效查詢

場景描述

我們用表格存儲存放商家，以及商品的信息，商品有較多的屬性例如價格，產地，適合人群等等，我們希望可以對這些商品的屬性做各種靈活的查詢。例如，產地是杭州的價格50到100之間的商品，或者我們希望對屬性中某個做模煳搜索，例如“茶”。

表結構設計

數據存儲示例

設計好表結構後，我們看下具體如何存儲：
比如原始數據是：

2017/5/20 商家1上架商品10005，商品產地杭州，名稱西湖龍井茶葉，價格300，適合人群12歲以上, 屬性描述如下：XXXXX

為了實現靈活的查詢我們可能需要借助一個搜索係統例如Elasticsearch，那我們在插入一條新的商品的時候需要雙寫表格存儲和Elasticsearch。那我們架構是：

基於這樣的架構，我們需要引入一個MQ，自己實現表格存儲和ES的雙寫。現在有了Stream功能後，我們可以直接寫入表格存儲，把增量同步進入Elasticsearch。架構修改為如下：

一個更讓人期待的功能是阿裏雲數據同步通道DTS正在集成表格存儲到ES，屆時用戶隻需要做一些配置就可以打通表格存儲和ES，靈活的實現屬性的查詢搜索。我們也可以參考表格存儲和ES場景分析和實踐

總結

最後我們來總結一下有了Stream帶來的好處和適用的場景，
Stream可以很方便的在以下場景中使用：

1. 增量數據複製 DataX StreamReader
2. 對接流計算,實時計算平台
3. 對接函數計算
4. 對接搜索
5. 訂閱增量數據

在使用表格存儲這類水平擴展的分布式數據庫的時候，我們需要讓我們數據的分區鍵盡量分布均勻，避免寫入尾部熱點。所以我們無法使用時間做為分區鍵，但是如果我們的業務需要基於時間去讀取消費數據，例如下圖中，pk1，pk20和pk95等一些鍵值產生了新數據，我們需要跳著讀區這些新數據，可能這樣的key非常多，我們也很難得知哪些key產生的新數據。

為了獲得這些增量數據，我們得依賴一個隊列，對一個更新操作執行雙寫，這樣會增加很多額外的係統依賴和成本。而Stream的天生基於Commitlog的特性徹底改變了這一點，數據庫的內容是根據主鍵進行排序組織，而數據庫日誌是根據修改順序排序（如下圖所示）。所以我們可以很方便的連續讀區到這些在數據庫文件中跳躍的鍵值。

最後更新：2017-08-29 22:32:24

  上一篇：  阿裏雲服務器學生專享優惠

  下一篇：  阿裏雲服務器租賃-阿裏雲服務器租賃價格多少錢