blink cep基于用户的行为分析大杀器
场景
今天我们做o2o有很多的线下场景需要基于用户的行为进行分析,比如 我们在商场入门口装了一个摄像头,可以通过摄像头识别商场进入的人脸,和出去时候的人脸,这样形成了2条数据。商场想统计下,每个用户在商场的逗留时间。这里面就出现了一种pattern的模式,就是当用户进门和出门这两个事件都发生的时候,激发某个动作(事件)。比如在这里是在用户出门的时候将用户进门时间和出门时间的差值相减,并存储在tablestore当中。然后可以通过分析汇总算出今日用户在商场的平均逗留时间,继而可以统计出当月,当年的平均逗留时间,等等,促使商家提升总体运营水平。
这里面 用户进入商场 和用户走出商场是两个用户行为,当它们组合在一起时候就有了奇妙的意义。blink在分析此类用户行为方面提供了极其强大的模式匹配功能。下面我以这个场景,详细描述下如果使用。
架构图
用户行为表
用户逗留时间表
用户行为表用来记录摄像头识别的用户进门和出门的产生的记录,用户逗留时间表用来记录每个用户的逗留时间。
以用户行为表为blink的源表,用户逗留时间表为结果表。这里使用tablestore为存储数据库。为什么使用tablestore,因为tablestore的通道和blink能进行无缝的集成,tablestore的存储成本非常的低廉,扩展性又非常的好。有想了解tablestore的同学,点击传送门,当然也可以换成hbase等类似的数据库。
下面是具体的代码
CREATE TABLE mofun_source_user_action (
--id
id BIGINT,
-- 记录日期
record_date BIGINT,
--用户iduser_id
BIGINT,
--数据触发时间
prd_time BIGINT,
--数据行为类型
opt_type varchar,
--计算列
ts AS to_timestamp(prd_time),
WATERMARK FOR ts AS withOffset(ts, 1000),
primary key (record_date, user_id
, prd_time,opt_type)
)
CREATE TABLE ots_result_user_play_time (
--进入id
inid BIGINT,
--出去id
outid BIGINT,
--记录日期
record_date BIGINT,user_id
BIGINT,
play_time BIGINT,
primary key (record_date,user_id
)
)
insert into ots_result_user_play_time
SELECT
inid, outid, start_tstamp, `user_id`, play_time
FROM mofun_source_user_action MATCH_RECOGNIZE (
PARTITION BY `user_id` ORDER BY ts MEASURES e1.id as inid, e2.id as outid, e1.record_date AS start_tstamp, (e2.prd_time-e1.prd_time) AS play_time ONE ROW PER MATCH PATTERN (e1->e2) WITHIN INTERVAL '10' Hour DEFINE e1 AS e1.opt_type ='in',e2 as e2.opt_type='out' )
其中最关键的是最后这块代码
解释一下代码
DEFINE,定义的是模式匹配的变量,意思你要用哪列,什么条件的数据来进行条件匹配
PATTERN 就是变量的匹配模式,e1->e2的意思是指 进门后面如果出现了出门就匹配成功
MEASURES 里面是要在select中显示的数据列
具体文档看传送门(https://yuque.antfin-inc.com/rtcompute/doc/sql-query-cep),不过这篇文章讲得也不是很清楚,后面我会写一篇文章专门详细介绍复杂的匹配。
像上面这种场景稍微的进行一下更改就有很多场景可以使用。比如 我们现在经常使用短视频,那么我们怎么分析用户在某个短视频的停留时间呢?就可以在用户进入视频和出了视频产生一个事件,然后用上面这个语法就能分析出来,每个用户在视频上面的停留时间,然后根据排个实时排行榜,然后进行推荐。排行榜的架构,可以看我的上一篇文章,如何构建实时的排行数据。
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
云计算数据库迁移需要避免的10个错误
云计算数据库迁移需要避免的10个错误139w.com 鼎点网络 数据库专家Chris Foot分享了IT团队在进行云计算数据库迁移时通常会遇到的十个疏忽和错误,并为此提供了如何避免这些错误的建议。越来越多的组织正在采用数据库即服务(DBaaS)平台,以寻求更快、更具可扩展性的部署,并降低成本。随着现有的大量数据库即服务(DBaaS)产品和工具的出现,启动云计算数据库迁移的案例变得更加令人关注。但是,很多组织在云计算数据库迁移期间存在一系列常见的误解和错误,这些问题将继续为其IT团队带来困扰。主要影响那些对云计算数据库迁移不熟悉的组织,但已将大量本地数据库迁移到云平台的公司也不能幸免。当组织在云计算数据库迁移的早期识别并解决问题时,就能够在数据库即服务(DBaaS)系统出现问题时将其影响降至最低,并减少意外发生。以下是IT团队在进行云计算数据库迁移时需要避免的10个错误。1.低估云计算数据库迁移和支持成本数据库即服务(DBaaS)平台并不是一种新产品,而是一种新架构,与所有新架构一样,数据库即服务(DBaaS)将产生广泛的影响,从而改变组织存储的构建、访问、管理、监控、保护其系统的方式。...
- 下一篇
空学Kafka之二
继续上一篇 (空学Kafka之一)[https://www.atatech.org/articles/145913] 构建数据通道 考量点 及时性,可靠性,吞吐量,安全性(通道安全,审计等),数据格式的上线兼容,ETL or ELT,统一还是专属(比如GoldenGate是oracle私有的,有很强的耦合性),优先选择Kafka Connect 深入浅出Connect 连接器插件实现了 Connector API,API 包含了两部分内容。大致上是分而治之的思想,连接器相当于分拆器splittor,任务相当于拆分后的具体执行器executer。 连接器:负责以下三件事。 决定需要运行多少个任务。 按照任务来拆分数据复制。 从 worker 进程获取任务配置并将其传递下去。 任务:负责将数据移入或移出 Kafka。 相比较直接采用Kafka的publis
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- CentOS8,CentOS7,CentOS6编译安装Redis5.0.7
- Linux系统CentOS6、CentOS7手动修改IP地址
- CentOS7,8上快速安装Gitea,搭建Git服务器
- CentOS8安装MyCat,轻松搞定数据库的读写分离、垂直分库、水平分库
- SpringBoot2整合Redis,开启缓存,提高访问速度
- MySQL8.0.19开启GTID主从同步CentOS8
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- Docker快速安装Oracle11G,搭建oracle11g学习环境
- CentOS8编译安装MySQL8.0.19
- CentOS8安装Docker,最新的服务器搭配容器使用