表格存储(TableStore)新功能Stream应用场景介绍

点击查看全文

上面一篇我们介绍了表格存储新功能Stream, 下面我们展开说一些场景，看看有了Stream后，哪些我们常见的应用场景可以更高效的设计和实现。

直播用户行为分析和存储

场景描述

现在视频直播非常火热，假如我们使用TableStore记录用户的每一次进入房间和离开房间，房间内的操作记录等，并希望根据用户的最近的观看记录，更新直播推荐列表。给主播提供近期收看其直播的用户的属性特征，帮助主播优化直播内容迎合观众。

表结构设计

主键顺序	名称	类型	值	备注
1	partition_key	string	md5(user_id)前四位	为了负载均衡
2	user_id	string/int	用户id	可以是字符串也可以是长整型数字
3	room_id	string/int	房间Id	可以使字符串也可以是长整型数字
4	timestamp	int	时间戳	使用长整型，64位，足够保存毫秒级别的时间戳

数据存储示例

设计好表结构后，我们看下具体如何存储：

比如原始数据是：

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

part_key	user_id	room_id	timestamp	operation	actor_id	device	network
01f3	000001	001	1495246210	进入房间	005	Iphone7	4G
01f3	000001	001	1495246810	点赞	005	Iphone7	4G
01f3	000001	001	1495256810	鲜花	005	Iphone7	4G
01f3	000001	001	1495259810	关注主播	005	Iphone7	4G
01f3	000001	001	1495266810	退出房间	005	Iphone7	4G

主键

part_key：第一个主键，分区建，主要是为了负载均衡，保证数据可以均匀分布在所有机器上，提高并发度和性能。如果业务主键user_id可以保证均匀分布，那么可以不需要这个主键。
user_id：第二个主键，用户ID，可以是字符串也可以是数字，唯一标识一个用户。
room_id：第三个主键，房间ID，每个直播房间我们可以认为有一个唯一的标识，可以是字符串也可以是数字。
timestamp：第四个主键，时间戳，表示某一个时刻，单位可以是秒或者毫秒，用来表示用户产生操作的时间戳，记录了操作的时间戳，我们可以用来分析用户操作频率，或者和直播内容进行关联分析。
至此，上述四个主键可以唯一确定某一个用户在某一个时间点在某一个房间的操作数据。

属性列

operation：操作类型，例如进入房间，离开房间，关注，购买，打赏等等。
actor_id：直播人的id。也就是主播的id，一些特殊活动下，可能会变成一个主播列表。
device：用户访问的设备类型。

除了上面提到的一些基本属性以外，我们也可以根据需求添加关注的属性，例如用户的访问设备mac地址，ip地址等。

数据分析需求

如果我们现在想做一些运营分析，例如：
最近10分钟有多少用户在房间内做了支付操作。
最近用户支付较多的房间主播有什么共同属性。
过去一天什么时间段，用户房间内操作最活跃。
对于某一个用户，如何根据他最近的房间操作，例如离开了什么样的房间，在什么样的房间会滞留，推荐后续的直播内容。

从上面的这些分析需求我们大体可以分为两类：

1. 离线分析过去一段时间用户操作行为，例如上面的场景3

2. 实时分析最近用户的行为，例如上面的场景1，2，4

如何获取增量数据

假设我们直接使用API根据时间来获取增量数据，那么我们需要先要得到所有的用户id以及房间id，然后根据时间进行读取。用户数乘以房间数可能会是一个非常大的量，那么我们的分析就难以保证实效性。有了增量通道，我们可以使用Stream Client，订阅实时的增量数据。在Stream Client实现代码把增量数据推送到流计算平台或者ODPS中，做定期的分析。

结构图如下：

点击查看全文