第2章 日志采集

2.1 浏览器的页面日志采集

主要分为两类:页面展现日志采集、页面交互日志采集

2.1.1 页面浏览日志采集流程

一次HTTP请求中发生了什么:
https://blog.csdn.net/qq_40804005/article/details/82876209

以访问淘宝首页为例,
(1)输入URL
(2)发起HTTP请求,一个标准的HTTP请求包含请求行(方法、URL、版本号)、请求报头(header)、请求正文(可选)
(3)服务端接受并解析.返回包括状态行(包括状态码)、响应报头、响应正文(html)

页面浏览日志采集过程:
(1)客户端日志采集,植入HTML文档javascript,通过该脚本获取各种信息.
(2)客户端日志发送,日志采集与发送一般会集成在同一个脚本内,大部分情况采集完成即进行上报.
(3)服务端日志收集,服务端向客户端发送确认信息,并将得到的日志写入缓存.
(4)服务端日志解析存档,经过日志解析程序处理,日志被解析出来,并注入消息通道.

2.1.2 页面交互日志采集

当用户在页面上产生指定行为时,采集代码与响应代码一起触发执行

2.1.3 页面日志服务器端清洗和预处理

(1)识别流量攻击、网络爬虫和作弊流量
(2)数据缺项补正
(3)剔除无效数据
(4)日志隔离分发,主要考虑数据安全问题.

2.2 无线客户端日志采集

无线客户端的日志采集采用SDK完成.
事件是无线客户端日志行为的最小单位.

2.2.1 页面事件

页面事件记录三类信息:
(1)设备及用户的基本信息
(2)被访问页面信息(cur_page)
(3)访问基本路径(来源pre_page\enter_from)

透传参数可以是的当前一些信息传递到下一个甚至下下个页面的日志中

2.2.3 特殊场景

可在客户端对只需要计数的一些事件做适当聚合,减少日志采集服务端请求.

2.2.4 H5&Native日志统一

为什么要统一:
(1)采用SDK可以采集到更多设备相关数据
(2)SDK会先在本地缓存,然后借机上传,网络状况不佳时延迟上报

具体流程:
(1)H5页面浏览、交互依然使用js脚本获取
(2)打包日志后调用移动客户端对应接口方法,将埋点数据对象作为参数传入
(3)移动客户端日志采集SDK,封装提供接口,实现将传入内容转换成移动客户端日志格式

2.3日志采集的挑战

应对日志爆发式增长:尽可能靠前地不知路由差异,尽可能早地进行分流,将分类任务前置到服务端
采集与计算一体化设计

第3章 数据同步

3.1 数据同步基础

3.1.1 直连同步

通过定义好的规范接口API和基于动态链接库的方式直接连接业务库.

3.1.2 数据文件同步

约定好文件编码、大小、格式等,直接从源系统生成数据的文本文件.

3.1.3 数据库日志解析同步

获取所有的数据记录变更.

通过数据库日志解析进行同步的方式性能好、效率高,对业务系统影响较小,但存在一些问题:
(1)数据延迟.更新量超出系统处理峰值.
(2)投入较大.需要在源数据和目标数据库之间部署系统实时抽取数据.
(3)数据漂移和遗漏.在业务日期数据中包含前一天活后一天凌晨附近的数据或者丢失当天变更数据.

3.2阿里数据仓库的同步方式

3.2.2 实时数据同步

通过解析Mysql的binlog日志来实时获得增量的数据更新,并通过消息订阅模式来实现数据的实时同步.

3.3数据同步遇到的问题与解决方案

3.3.3 增量与全量同步的合并

传统数据整合方案中,合并技术大多采用merge方式(update+insert)
当前流行的大数据平台基本不支持update,现在推荐的方式是全外连接+数据全量覆盖重新加载(insert overwrite) 性能高,保留时间较短

3.3.5 数据漂移的处理

数据漂移通常指ODS表同一个业务日期数据中包含前一天或后一天凌晨附近的数据或者丢失当天变更数据.

时间戳字段通常分四类:
(1)表中记录数据更新时间时间戳字段
(2)日志中标识数据记录更新时间的时间戳字段
(3)数据库记录业务发生时间的时间戳字段(服务端时间)
(4)标识数据记录被抽取到时间的时间戳字段(客户端时间)

处理方法:
(1)多获取后一天的数据
(2)通过多个时间戳字段限制时间来获取相对准确的数据

第5章 实时技术

5.1 简介

数据时效性一般分为三种,离线、准实时、实时

5.2 流式技术

5.2.1 数据采集

从采集数据种类来看主要分为两种:
(1)数据库变更日志
(2)引擎访问日志

5.2.2 数据处理

1.去重指标
精确去重,需要进行数据倾斜处理
模糊去重,使用去重算法,损失精度,如布隆过滤器、基数估计
2.数据倾斜
去重指标分桶,对去重值进行分桶Hash
非去重指标分桶

5.2.3 数据存储

中间计算结果
最终结果数据
维表数据

第9章 阿里巴巴数据整合及管理体系

9.2规范定义

9.2.2 指标体系

操作细则
(1)派生指标种类
事务型指标:对业务活动进行衡量的指标
存量型指标:对实体对象某些状态的统计
复合型指标:事务型指标和存量型指标复合出的指标
(2)复合指标举例
比率型、比例型、变化量型、统计型、排名型

9.3 模型设计

9.3.2 模型层次

操作数据层ODS
公共维度模型层CDM-包括明细数据层DWD和汇总数据层ADS
应用数据层ADS

9.3.3 基本原则

1 高内聚低耦合
2 核心模型与扩展模型分离 比如搜索,先记录核心数据
3 公共处理逻辑下沉及单一
4 成本与性能平衡
5 数据可回滚
6 一致性
7 命名可理解

9.4 模型实施

9.4.1 业界常用模型实施过程

Kimball模型实施过程
(1)高层模型:对业务过程中的维表和事实表的图形描述
(2)详细模型:为高层模型填补缺失信息
(3)模型审查、再设计和验证
(4)提交ETL设计和开发

Inmon模型实施过程
将模型划分为三个层次,分别是实体关系图层(ERD层)、数据项集(DIS层)和物理层(physical model)
ERD层:业务中实体或主题域以及它们之间的关系
DIS层:描述了数据模型中的关键字、属性以及细节数据之间的关系
物理层:描述了数据模型的物理特性

9.4.2 OneData实施过程

首先,进行充分的业务调研与需求分析
其次,进行数据总体架构设计,主要是对数据域对数据进行划分
然后,构建总线矩阵、明确统计指标
再次,进行规范定义与汇总模型设计
最终,进行数据代码开发

总线矩阵:明确每个数据域下有那些业务过程,业务过程与哪些维度相关

第10章 维度设计

10.1 维度设计基础

10.1.1 维度基本概念

维度建模中,度量称为事实,环境称为维度.
维度一般作为查询约束、分类汇总以及排序.
维度使用主键标识唯一性,包括代理建和自然建,代理建一般用于处理缓慢变化维,不具备业务含义;自然键具有业务含义.

10.1.2 维度基本设计方法

第一步:选择维度或新建维度.保证维度唯一性
第二步:确定主维表.一般是ODS表,直接与业务系统同步.
第三步:确定相关维表.
第四步:确定维度属性.

要点:
(1)维度尽可能丰富
(2)区分数值属性和事实
(3)沉淀出通用的维度属性

10.1.4 规范化和反规范化

当属性层次被实例化为一系列维度,而不是单一维度时,被称为雪花模式.
出于易用性和性能的考虑,维表一般是不规范的.在实际实用中,几乎总是使用维表的空间来换取简明性和查询性能.

10.1.5一致性维度和交叉探查

一致性的几种表现形式:
共享维表
一致性上卷
交叉属性

10.2维度设计高级主题

10.2.1 维度整合

垂直整合:不同来源表包含相同数据集,只是存储的信息不同.比如淘宝会员系统中包括会员基础信息表、会员扩展信息表、会员等级信息表、天猫会员等级信息表.
水平整合:即不同来源表包含不同数据集,不同子集之间无交叉也可部分交叉.比如不同的会员体系进行整合,淘宝会员、支付宝会员水平整合.

10.2.2 水平整合

方案一:不同分类实例化为不同维度,同时在主维度中保存公共属性
方案二:维护单一维度,包含所有可能属性.

主要考虑三个原则:
扩展性,效能,易用性

10.2.3 垂直拆分

主维度与冗余信息产出时间不一致,比如商品主维度1.30产出,商标、品牌等3.产出.
类似的,搜索用户行为数据(这不是维表)原始日志基于impr_id,不带events,不过反作弊首先完成,然后再merge events数据,最后merge doc级别的events,通过反作弊.

10.3 维度变化

10.3.1 缓慢变化维

三种处理方式:
(1)重写维度值.不保留历史数据,始终取最新数据.
(2)插入新的维度行.保留历史数据,维度值变化前的事实和过去的维度值关联,维度变化后的事实和当前维度值关联.
(3)添加维度列.

10.3.2 快照维表

采用快照的方式.简单有效,理解性好.但存储浪费大.

10.3.3 极限存储

历史拉链存储,新增两个时间戳字段(start_dt, end_dt)记录维度的有效时间

阿里的极限存储:
(1)透明化.上层做视图操作或在Hive中hook.
(2)分月做历史拉链表.

10.3.4 微型维度

使用极限存储,需要避免维度的过度增长.
通过将一些属性从维表中移出,放置到全新维表中解决维度过度增长的问题,微型维度将通过不稳定的属性从主维度中移出,并放置到新表中实现.

10.4 特殊维度

10.4.1 递归层次

具有父子关系的维度设计
(1)将维度扁平化
(2)设计层次桥接表(记录关系)

10.4.2 行为维度

维度与事实相关,如交易、物流等称之为行为维度
(1)快照事实行为维度,比如交易金额、信用分值
(2)分组事实行为维度,根据金额划分的等级
(3)复杂逻辑事实行为维度,商品热度(根据多种事实计算得到)

两个原则:
(1)避免过快增长
(2)避免耦合度过高

10.4.3 多值维度

针对多值维度,主要处理方式有三种
(1)降低事实表的力度
(2)采用多字段
(3)采用通用桥接表

10.4.4 多值属性

保持维度主键不变,将多值属性放在维度的一个属性字段中.
保持维度主键不变,将多值属性放在维度多个属性字段中.
一个维度值存放多条记录,重复维度值.

第11章 事实表设计

11.1 事实表基础

11.1.1 事实表特性

紧紧围绕着业务过程来设计，通过获取描述业务过程的度量来表达业务过程
事实表中一条记录所表达的业务细节程度被称为粒度。粒度可以是维度属性组合所表示的细节程度，一种是所表示的具体业务含义。
维度也可以存储到事实表中，这种维度被称为退化维度。
事实表有三种类型：事务事实表、周期快照事实表、累计快照事实表

11.1.2 事实表设计原则

（1）尽可能包含所有与业务过程相关的事实
（2）只选择与业务过程相关的事实
（3）分解不可加性事实为可加组件
（4）在选择维度和事实前明确维度
（5）同一个事实表中不能有多重不同粒度的事实
（6）对空值进行处理
（7）使用退化维度提高事实表的易用性

11.1.1.3 事实表设计方法

第一步：选择业务过程及确定事实表类型
第二步：声明粒度
第三步：确定维度
第四步：确定事实
第五步：冗余维度

11.2 事务事实表

下单、支付、成功完结是三种事务
事务事实表可以是针对单个事务，也可以是针对多个事务的。

11.2.6 事实的设计准则

（1）事实完整性
（2）事实一致性
（3）事实可加性

11.3 周期快照事实表

当需要对一些状态度量进行追踪时，则需要聚集与之相关的事务才能进行识别计算。

11.3.1 特性

（1）用快照采样状态：以预定的间隔采样状态度量。这种间隔联合一个或多个维度，江北用来定义快照事实表粒度，每行都将包含记录所涉及的状态的事实
（2）密度与稀疏性：事务事实表是稀疏的，而快照事实表是稠密的，无论是否发生事务，都会记录一行
（3）半可加性：快照事实表在每个采样周期内是不能对状态度量进行汇总的。

11.3.3 注意事项

（1）事务与快照成对设计
（2）附加事实，保存上一周期状态
（3）周期选择

11.4 累计快照事实表

11.4.4 物理实现

（1）全量表形式。一般以日期作为分区，记录前天全量数据与当天增量数据的融合。
（2）全量表变化形式。针对事实表数据量很大的情况
（3）以业务实体的结束时间分区。

11.7 聚集型事实表

11.7.1 聚集的基本原则

一致性。聚集表必须提供与查询明细粒度一致的查询结果。
避免单一表设计。不要再同一个表中存储不同层次的聚集数据。
聚集粒度可不同。

11.7.3 阿里公共汇总层

数据公用性。
不跨数据域。
区分统计周期。

11.7.4 聚集补充说明

1.聚集是不跨越事实的
聚集是针对原始星形模型进行的汇总，横向钻取是针对多个事实基于一致性维度进行的分析，多采用融合事实表。
2.聚集带来的问题
聚集会增加ETL维度的难度。当子类目对应一级类目发生变更时，先前存在的、已经被汇总到聚集表中的数据需要被重新调整。

第12章 元数据

12.1 元数据概述

元数据打通了源数据、数据仓库、数据应用，记录了数据从产生到消费的全过程。

元数据按用途可分为技术元数据和业务元数据。
技术元数据包括：分布式系统存储的元数据、分布式计算系统运行的元数据、数据开发平台中数据同步、计算任务、任务调度等信息、数据质量和运维相关元数据。
业务元数据包括：业务过程、维度属性、指标等规范化定义；数据应用元数据

12.2 元数据应用

基于现有底层数据已经有下游使用的情况，我们可以通过下游所使用的元数据指导数据参考建模。
所使用的元数据包括：
表的基础元数据，如下游情况、查询次数、关联次数、聚合次数、产出时间
表的关联关系元数据，包括关联关系表、关联类型、关联字段、关联次数
表的字段基础元数据，包括字段名称、字段注释、查询次数、关联次数、聚合次数、过滤次数

第13章 计算管理

13.1 系统规划

HBO，基于历史的优化器。根据任务历史执行情况为任务分配更合理的资源，包括内存、CPU以及Instance个数。
CBO，基于代价的优化器。优化器有多个模块相互组合协调工作，包括元数据、统计信息、优化规则集、核心计划器

13.2 任务优化

13.2.1 Map倾斜

Map端两个主要过程

导致Map端长尾的两种情况：
上游文件大小不均匀，小文件特别多。
某个值特别多，Hash过后过于集中。

解决方案：
合并小文件。
distribute by rand()将Map端分发后的数据重新按照随机值再进行一次分发。

13.2.2 join倾斜

导致join倾斜的集中情况：
join的某路输入比较小。
join的每路输入都比较大，且长尾是控制导致的。
join的每路输入都比较大，且长尾是热点导致的。

方案：
Mapjoin
将空值处理为随机值
将热点key去除，对主表数据用热点key切分成热点数据和非热点数据两部分分别处理，最后合并。

13.2.3 Reduce倾斜

Reduce端负责对Map端梳理后的有序key-value键值对进行聚合，即进行Count、Sum、Avg等聚合操作，得到最终的聚合结果。

导致Reduce倾斜的情况：
对同一个表按照维度不同的列进行count distinct操作
Map端直接聚合时出现key值分布不均匀
动态分区数过多时造成小文件过多
多个distinct同时出现在一段sql代码中，数据会被分发多次，也会造成数据膨胀

解决方案：
第二种情况，对热点key进行处理
第三种情况，把符合不同条件的数据放到不同的分区，避免多次insert overwrite
第四种情况，如果出现多个需要去重的指标，那么在把不同指标join在一起之前，一定要确保指标的粒度是原始表的数据粒度。