很早就看过一点,看的不连续,今天专门花时间完整看一遍总结下这本书里自己关注的知识点和自己的一些思考,算是读书笔记吧。
2.2.1页面事件
1、这里说到页面型日志上报的时候,进入页面和离开页面成对使用和上报以解决使用时长问题。
个人记录:这个策略很好,成对上报进入页面也记录下,使用方便,要不还要再处理数据
2、页面透传阿里是通过spm实现,用户行为路径轻松实现
个人记录:spm现在互联网公司用的比较全面了,不过各有各的用法,但是一般在使用上并不轻松,往往需要做数据打平的工作,在没有固定层级的数据场景里,处理并不容易,可以作为一个基础让spm系统更加完善。
2.2.3特殊场景
1、对于曝光这种大量上报的场景,节省带宽。网络传输压力等考虑会压缩上报
个人记录:使用还是广泛的,特别是曝光,会压缩上报,这个跟日志格式设计也有点关系,不同场景的日志都能使用这个模式;还有就是下游etl肯定要考虑把这个数据还原
2、页面回退,阿里通过页面的生命周期,识别页面的附庸,配合栈的深度识别页面回退
个人记录:这个对于链路分析太有用了,把整体日志形式铺平的时候就需要考虑这个问题,还没做到这一步,这是需要学习的;如果有层级概念,处理也可以打平使用
2.2.5 设备识别
个人记录:这个识别设备对于风控还有用户准确性判断都很重要,一般是客户端来处理,但是数据人员最好知道各个含义,比如idfa,idfv,imei,oaid之类的
2.3.1 典型场景
1、日志分流与定制处理;对于不同页面关注点不一样,用统一解析处理方案成本高,这里阿里做了流量分流
个人记录:这里做的很细,实际工作中还没做到这一步,不过思路差不多
2、采集与计算一体化设计;pv型日志规范通过spm规范和spm元数据中心,并且这里也能实现查询,工程化管理;还支持自定义日志
个人记录:做到加埋点和查埋点一体化管理,太优秀了
3.1.3 数据库日志解析同步
1、主要是数据库变更日志解析,这本书比较早,现在来看cdc是发展方向,还有就是配合flink做实时处理
个人记录:这里相对于离线抽取,可以实时,也可以避免主从延迟问题,缺点也有
3.3.5 数据漂移的处理
个人记录:主要是通过拉取更多的数据做补充,之前没怎么关注,一般就是多拉取点,做补充
6.1.3 SmartDQ
1、openApi基础上再抽象一层DSL来描述取数需求
个人记录:对于服务不是很了解,但是看下来用一个接口满足了很多需求,数据抽象和业务抽象都做了工作,比如ORM框架,都不知道是啥东西
9.1.2 体系架构
1、业务板块 + 规范定义 + 模型设计
规范定义指以维度建模作为理论基础,构建总线矩阵,划分和定义数据域、业务过程、度量/原子指标、修饰类型、修饰词、时间周期、派生指标
9.3.3 基本原则
1、高内聚低耦合
2、核心模型与拓展模型分离
建立核心模型与拓展模型体系,核心模型包括的字段支持常用的核心业务,拓展模型包括的字段支持个性化或少量应用的需要,不能让拓展模型的字段过度侵入核心模型。
个人记录:扩充还是要看需求,大多数不会分核心和非核心
3、公共处理逻辑下沉及单一
4、成本与性能平衡
5、数据可回滚
6、一致性
具有相同含义的字段再不同表中的命名必须相同,必须使用规范定义中的名称
个人记录:一旦开始不注意,建立之后就很难修改了
7、命名清晰可理解
10.3.1 缓慢变化维
三种处理方式
1、重写纬度值
2、插入新的维度行,同一行事实数据写2条记录
3、添加维度列,维护2列,新老列
个人记录:也可以不在事实表维护值,只维护id,在有大量事实数据的情况下,刷数据十分麻烦
10.4.1 递归层次
个人记录:就是把有分级的数据打平,比如商品的类目名称,但是处理之后,数据的第一列就每个类目都会有,这个对于固定层级理解略微麻烦一点点
10.4.2 行为维度
个人记录:就是用事实加工出来的维度,要考虑是不是需要加入现有的维度表
10.4.5 杂项维度
个人记录:就是维度不维护,事实表中产生的记录数据,考虑要不要抽出来单独维护维表,这个维表是由事实产生的
11.1.2 事实表设计原则
1、尽可能包含所有与业务过程相关的事实
2、只选择与业务过程相关的事实
3、分解不可加事实为可加的组件(比如实付金额分解为原价+优惠金额)
4、在选择维度和事实之前必须先声明粒度
5、同一个事实表中不能有多种不同粒度的事实
6、事实的单位要一致
7、对事实的null值要处理
个人记录:作者是建议都处理成0,数字型的
8、使用退化维护提高事实表的易用性
剩下的基本都是比较常见的内容,不再赘述,作为一个数据产品还是比较好的,方方面面都涵盖到了。