数据仓库
数据仓库的数据来源往往有两类:
- 业务数据, 处理事务过程中产生的数据, 通常存储在关系型数据库中,如 MySQL, Oracle等.
- 行为数据, 用户与客户端产品交互过程中产生的数据, 通常存储在日志文件中.
那么业务数据应该如何采集到数据仓库呢?
1. 数据采集 - 业务数据同步方式
接口 - 最古老的方式
推: 应用主动发送数据到大数据平台.
拉: 大数据平台定时从应用拉取数据.
优点:
实现简单
缺点:
耦合非常严重, 需要记录对方的访问信息和接口地址
增加业务开发人员额外工作
消息队列
订阅: 应用将数据发布到消息队列, 大数据订阅主题并消费
优点:
业务与大数据解耦, 业务应用不关心谁消费了这条消息
多个消费者可以同时消费
缺点:
仍旧增加开发人员额外工作
MQ带来的复杂度, 可用性问题
数据库级别同步
离线数据同步, 适用T+1的场景 sqoop, datax
增量数据同步, canal, streamsets
-canal 模拟 MySQL slave 的交互协议，伪装自己为 MySQL slave ，向 MySQL master 发送 dump 协议
-MySQL master 收到 dump 请求，开始推送 binary log 给 slave (即 canal )
-canal 解析 binary log 对象(原始为 byte 流)
实现MySQL增量数据 - 字段映射并同步 - HBase/ES/RDB(mysql, postgresql, oracle, sqlserver…)
优点:
不影响业务开发, 只需要双方提前对数据格式达成共识
缺点:
复杂度
无法在迁移过程中做复杂的转换
总结
毫无疑问, 目前所有的数仓(的业务数据)都是基于数据库级别的同步来作为数据输入的.
那么我们再来看一下行为数据的采集:
2. 数据采集 - 行为数据同步
在讨论行为数据的同步方式之前, 先来考虑两个问题:
业务数据的数据结构是有固定的模式的, 然而行为数据(停留,点击, 跳转, 提交, 轨迹等)复杂多样, 怎样针对不同的行为制定相同的数据模式?
行为数据由前端发送, 还是后端发送?
带着这俩问题, 先来看下事件模型.
2.1. 用户行为数据模型 - Event Model
通常都会使用事件模型Event Model来描述用户在产品上的各种行为.
Event五要素
- Who: 登录用户ID, 匿名ID(cookie_id, 设备id)
- When: 事件发生实际时间, 要考虑到本地时间不一定准确的问题, 可以初始化时从服务器获取, 而服务器要做NTP服务
- Where: ip, GPS
- How: 从事这个事件的方式. 包括设备,浏览器,APP版本,OS版本,渠道,referer,屏幕宽高,是否wifi
- What: 用户所做事件的具体内容
复杂的数据纬度, 统一的数据格式
每个产品的数据指标都不同, 如PV, UV, 视频播放数, 做题数等.尤其一些细节、精细化的分析, 都需要复杂的数据纬度来支撑.
通过上面的Event Model, 为不同的事件, 定义相同的数据格式, 方便后续的收集处理.
埋点: 前端 vs 后端
一句话:如果事件只在客户端发生,不需要往后端发送任何请求,那么在前端埋点;否则后端埋点较好.
考虑以下几种情况:
事件只在前端发生, 不往后端发送任何请求, 前端发
前端不能拿到事件所有(关键)字段, 后端发
事件数据后端也需要使用, 后端发
经常新增或修改指标, 后端发 (app涉及发版和用户更新问题)
对数据的完整性、一致性、即时性要求很高, 后端发(controller层在处理业务请求时同时发送)
eg:
客户端通常会多条数据打包压缩, 等满足一定条件再发, 如果网络状况不好, 或者应用关闭or进入后台, 可能造成上传不及时
行为数据同步方式
浏览器/APP -> Nginx -> Flume -> HDFS, Kafka