現在視訊直播非常火熱，假如我們使用tablestore記錄使用者的每一次進入房間和離開房間，房間内的操作記錄等，并希望根據使用者的最近的觀看記錄，更新直播推薦清單。給主播提供近期收看其直播的使用者的屬性特征，幫助主播優化直播内容迎合觀衆。
主鍵順序
名稱
類型
值
備注
1
partition_key
string
md5(user_id)前四位
為了負載均衡
2
user_id
string/int
使用者id
可以是字元串也可以是長整型數字
3
room_id
房間id
可以使字元串也可以是長整型數字
4
timestamp
int
時間戳
使用長整型，64位，足夠儲存毫秒級别的時間戳
設計好表結構後，我們看下具體如何存儲：
比如原始資料是：
part_key
operation
actor_id
device
network
01f3
1495246210
進入房間
005
iphone7
4g
1495246810
點贊
1495256810
鮮花
1495259810
關注主播
1495266810
退出房間
part_key：第一個主鍵，分區建，主要是為了負載均衡，保證資料可以均勻分布在所有機器上，提高并發度和性能。如果業務主鍵user_id可以保證均勻分布，那麼可以不需要這個主鍵。
user_id：第二個主鍵，使用者id，可以是字元串也可以是數字，唯一辨別一個使用者。
room_id：第三個主鍵，房間id，每個直播房間我們可以認為有一個唯一的辨別，可以是字元串也可以是數字。
timestamp：第四個主鍵，時間戳，表示某一個時刻，機關可以是秒或者毫秒，用來表示使用者産生操作的時間戳，記錄了操作的時間戳，我們可以用來分析使用者操作頻率，或者和直播内容進行關聯分析。
至此，上述四個主鍵可以唯一确定某一個使用者在某一個時間點在某一個房間的操作資料。
operation：操作類型，例如進入房間，離開房間，關注，購買，打賞等等。
actor_id：直播人的id。也就是主播的id，一些特殊活動下，可能會變成一個主播清單。
device：使用者通路的裝置類型。
除了上面提到的一些基本屬性以外，我們也可以根據需求添加關注的屬性，例如使用者的通路裝置mac位址，ip位址等。
如果我們現在想做一些營運分析，例如：
最近10分鐘有多少使用者在房間内做了支付操作。
最近使用者支付較多的房間主播有什麼共同屬性。
過去一天什麼時間段，使用者房間内操作最活躍。
對于某一個使用者，如何根據他最近的房間操作，例如離開了什麼樣的房間，在什麼樣的房間會滞留，推薦後續的直播内容。
從上面的這些分析需求我們大體可以分為兩類：
離線分析過去一段時間使用者操作行為，例如上面的場景3
實時分析最近使用者的行為，例如上面的場景1，2，4
假設我們直接使用api根據時間來擷取增量資料，那麼我們需要先要得到所有的使用者id以及房間id，然後根據時間進行讀取。使用者數乘以房間數可能會是一個非常大的量，那麼我們的分析就難以保證明效性。有了增量通道，我們可以使用stream client，訂閱實時的增量資料。在stream client實作代碼把增量資料推送到流計算平台或者odps中，做定期的分析。
假設，我們的系統已經使用表格存儲記錄每個使用者的訂單資訊，現在我們希望根據訂單資訊進行分析，近期的熱點商品，根據訂單更新采購庫存。
order_id
訂單id
commodity_id
price
count
total
payment_type
status
10005
15
30
alipay
finished
timestamp：第三個主鍵，時間戳，表示某一個時刻，機關可以是秒或者毫秒，用來表示使用者訂單的時間戳。在這裡放置時間，是因為系統往往需要查詢某個使用者一段時間内的所有訂單資訊。
order_id：第四個主鍵，訂單号。
至此，上述四個主鍵可以唯一确定某一個使用者在某一個時間點下的一個訂單。
commodity_id：購買商品的id。
price：購買商品的單價。
count：購買商品的總價。
total：訂單的總價。
payment_type：使用者支付類型。
status：訂單的狀态。
針對訂單系統，我們需要一下功能：
使用者可以快速查詢過去一段時間的所有訂單
當有使用者下單後，我們需要更新我們的倉儲資訊，當庫存少于一定數量後需要發起采購
分析使用者的近期購買興趣，做購買推薦
檢測異常訂單，例如某個使用者短時間内大量都買一個産品
針對需求1，我們的表設計再結合表格存儲的getrange可以很友善的實作。
需求2，基于我們的增量可以很友善擷取近期的訂單，定期更新庫存。表格存儲即将釋出的stream對接fc（敬請期待），可以做到完全的無伺服器觸發整個流程，實作訂單，庫存的自動化管理。
需求3和4，如果希望依賴odps做離線分析，可以使用datax結合我們的stream reader插件将資料導入opds進行分析。如果希望接入其他流計算平台，可以使用stream client訂閱增量資料。
我們用表格存儲存放商家，以及商品的資訊，商品有較多的屬性例如價格，産地，适合人群等等，我們希望可以對這些商品的屬性做各種靈活的查詢。例如，産地是杭州的價格50到100之間的商品，或者我們希望對屬性中某個做模糊搜尋，例如“茶”。
merchant_id
商戶id
商品id
|part_key | merchant_id | commodity_id | location | price | age | property
|------- | ------- | ------- | ------- | ------- | ------- | ------- |
|01f3 | 000001 | 10005 | 杭州 | 300| above 12 | xxxxx|
為了實作靈活的查詢我們可能需要借助一個搜尋系統例如elasticsearch，那我們在插入一條新的商品的時候需要雙寫表格存儲和elasticsearch。那我們架構是：
基于這樣的架構，我們需要引入一個mq，自己實作表格存儲和es的雙寫。現在有了stream功能後，我們可以直接寫入表格存儲，把增量同步進入elasticsearch。架構修改為如下：
最後我們來總結一下有了stream帶來的好處和适用的場景，
stream可以很友善的在以下場景中使用：
增量資料複制 datax streamreader
對接流計算,實時計算平台
對接函數計算
對接搜尋
訂閱增量資料
在使用表格存儲這類水準擴充的分布式資料庫的時候，我們需要讓我們資料的分區鍵盡量分布均勻，避免寫入尾部熱點。是以我們無法使用時間做為分區鍵，但是如果我們的業務需要基于時間去讀取消費資料，例如下圖中，pk1，pk20和pk95等一些鍵值産生了新資料，我們需要跳着讀區這些新資料，可能這樣的key非常多，我們也很難得知哪些key産生的新資料。
為了獲得這些增量資料，我們得依賴一個隊列，對一個更新操作執行雙寫，這樣會增加很多額外的系統依賴和成本。而stream的天生基于commitlog的特性徹底改變了這一點，資料庫的内容是根據主鍵進行排序組織，而資料庫日志是根據修改順序排序（如下圖所示）。是以我們可以很友善的連續讀區到這些在資料庫檔案中跳躍的鍵值。