《大数据之路》学习笔记

目的是构建可分享的，规范的，统一的全域数据体系，提高数据提取效率，避免重复建设。

目标和现状：

目标：

1.统一的 元数据管理平台（表字段命名规范，打标签）

2.统一的配置化数据抽数平台(Hdfs，Mysql，Oracle，Hbase等互相抽数)

3.统一的自动识别依赖的调度平台

4.统一的指标体系+维度建模(贴源，明细，轻度汇总，维度汇总)管理平台

5.统一的 大数据平台报表展示工具

6.统一的 数据质量监控平台

7.统一的 计算管理平台(智能构建大小合适的队列，动态分配队列给任务)

8.统一的特征工程（AI的基础）

9.统一的ETL开发部署测试平台

10.统一的 实时数据处理平台

现状：

1.无元数据管理，没有人知道行内究竟有什么数据可用。

2.所有的抽数方法都重复开发，单一项目内可能小范围重用

3.所有依赖全部手工保证，口口相传

4.无指标管理，口径混乱

5.报表平台繁多，各自维护

6.系统内自行开发数据质量监控，完全无重用

7.队列分配写死，忙的忙死，闲的闲死

8.无特征工程，少量几个机器学习程序，数据完全不共享

9.各开发组单独开发，版式各异，开发到部署路径很长，效率低下。

10.无实时处理，按项目单独开发实时处理模块，开发维护成本巨大。

1.数据技术

日志采集

日志采集主要目的是为了进行客户行为分析，而非传统的Bug分析，问题定位等。主要方法：

1.设立日志采集服务器实时从各系统接收和存储日志。

2.为了全方位的分析，需要定义完整的日志采集格式。

3.日志上传是智能分批次上传

4.界面中嵌入js，搜集客户端信息，并上传远程日志服务器。

5.安全性考虑，日志服务器与生产隔离，数据进入数据区需要清洗处理。

6.PV浏览日志和用户交互日志在数据结构上应该可以相互join

7.用户交互日志，首先需要有系统定义交互的场景，进行埋点，分配交互动作的Id，然后在页面嵌入Js，提取动作日志，发送日志服务器

8.日志采集到服务器后进行清洗，识别垃圾数据，恶意数据。最后形成半结构化数据，方便进入关系型系统用于分析。

9.特殊场景下，某些日志数据需要进行一定程度的聚合，能js层聚合就尽量在js层聚合。减少服务端存储压力，减少垃圾数据。

10.识别用于的访问路径，需要有更好的方法。（目前是利用页面生命周期，识别回退等行为）

11.H5和App跨平台日志搜集，把H5的日志，包装成App的日志再发送。

12.对日志处理保存进行分流，识别优先级，保障重点系统日志搜集。 日志保存每日一个分区或者文件

13.上传日志的程序可以从服务端获取配置，从而改变行为。比如延迟上报，部分采样上报，聚合上报等

14.用户交互日志实时传回后台分析程序，用户动作会影响其稍后的商品推荐。实时性要求很高的程序，实时分析日志，调用API完成业务计算。

数据同步

1.数据同步的3种方式：

a.直连同步，类似Sqoop。数据量较少

b.日志解析同步离线/实时， 实时性要求很高

c.数据文件同步， 数据量很大，先导出到数据文件，然后sftp方式拷贝到目标系统，再导入

2.数据传输的核心系统OneClick:

a.包含数据传输中间组件DataX，每个数据源都只负责和DataX进行数据通讯。DataX对接Mysql, Oracle, HDFS, Hbase其他系统

b.包含任务配置系统，各目标数据系统间全部抽象为库和表，只需要配置DataX的参数，就能新建数据同步任务

c.可根据元数据，评估任务的数据量和时间，自动拆分，并发执行。自动分配合适的资源。可配置优先级

d.数据实时同步：binlog + 消息系统，实时推送

e.数据同步提供各种调用接口，可程序调用，命令行调用等

f.分区存储

g.数据漂移问题：

日切点包含部分第二天数据，逻辑兼容

清洗过程进行反补修改

离线数据开发

1.提供统一的开发界面和接口，支持SQL，MapReduce，机器学习，Shell

2.集成SQLSCan，植入硬性开发规范

3.集成ETL开发，测试，执行，发布

4.集成运维，监控，数据质量检测

5.调度工具能自动监控识别任务关系，无需手工配置调整

实时技术

T+1延迟为1天，准实时延迟为1小时，实时延迟为1秒。 准实时和实时都是业务系统产生一条数据立刻被处理，而不是等待调度任务跑批处理。

基本流程：

a.业务系统调用kafka发送同步消息

b.SparkSteam程序订阅消息，调用初始化好的实例处理消息，返回消息结果

c.实例个数就是并发的个数，直接影响到TPS

比较好的实践：

a.提供实时处理程序的框架，可配置支持的并发数，监控，日志，运维方案等。 使用者只需要引入框架程序，实现自己的业务处理逻辑，就能架构起实时系统。

b.实时系统需要初始化数据到内存数据库中Hbase，以便及时响应计算。Hbase做双活

c.复杂场景中Hbase中数据也分层管理，

d.从离线表中抽取数据到Hbase，供实时业务处理. 一般取T-1的数据。

e.双流关联，Hbase中两个实时表数据关联，A关联B，如果关联不上就等待，再尝试关联后才输出。

数据服务

1.数据中心作为一个整体，想外提供数据服务。数据服务需要集中管理，对接全行的所有数据业务。

2.以一组业务逻辑表，汇总表，指标表为基础，对外提供SQL服务，SQL是一组模版来实现的。

3.逻辑表是各中数据加工的最后结果，数据来源有mysql，Oracle, Hbase等各种系统

数据挖掘

数据挖掘过程：

商业理解，数据准备，特征工程，模型训练，模型测试， 模型部署，线上应用

提供一套中心解决方案，能够让多个数据挖掘的开发过程，共享同一个体系，并提高效率。 避免各部门在自身业务发展过程中重复建设，浪费不必要的资源。

全局特征库：

特征提取使用有索引

特征对外服务有统一接口API

特征加工录入有规范

特征数据存储分层：

原始统一清洗，去噪处理层

面向挖掘场景的，客户，账户，行业，商家，商品等场景数据层

数据挖掘的结果保存层

可向外提供挖掘数据的服务层

用户画像：

给用户打上各种各样的标签，比如品牌偏好，类别偏好，消费偏好

反欺诈:

规则，有监督，无监督

离线反欺诈，实时反欺诈

2.数据模型

数据模型对比： ER模型和维度模型

ER模型是基于联机系统的应用模型，目的是方便应用快速读写，避免冗余。

维度模型是以数据分析为基础的模型，适当冗余，汇总。方便快速产出分析结果， 主要是星型和雪花型

星型维度模型解析：

1.从联机系统获取销售明细表，每条交易一条数据，并进行各种关联，获取交易的地域，时间，部们，产品等各种信息。每个信息，都是后续业务查看数据的维度

2.事实表： 以所有的维度为基础，对所有交易明细进行轻度汇总。 （数据量很大的，需要采用当日数据合并昨日数据进行汇总）

3.从轻度汇总表再导出部分维度集合和子表，再次进行汇总。

雪花行维度模型解析：

和星型表比起来，雪花是在星型的末端，再次保存了键值，拆分成单一维度级别的子表。

简单的说，就是星型表以事实表为中心，只有一层维度。 而雪花型以事实表为中心， 2层以上的维度表。

全行数据表命名规范统一：（参见财务指标系统命名规范）

数据域： 存款， 贷款， 支付， 同业，财务，风险， 司库等包含多个业务过程的领域数据称为数据域。

业务过程： 每个业务过程是一个不可切分的行为事件： 交易， 下单，退款，贷款发放， 还款等

时间周期： 1d， 30d, td, 1y, 2m

修饰词： 除了维度以外，对业务场景描述的词， log， pc， channel等

原子指标： 具有明确业务含义的度量，不能再拆分 支付金额， 存款余额等

派生指标： 一个原子指标 + 多个修饰词 + 时间周期

维度： 账户维度， 客户维度， 部门维度， 时间维度。 汇总后看数据的方式

维度属性： 客户维度中的： 客户id， 客户名称， 客户电话， 客户地址等

定义指标的过程，需要明确数据域，业务过程，周期， 原子指标和修饰词， 另外还需要考虑可能的维度，用于构建维度表满足业务分析的需要。

指标命名：

原子指标： 动作+度量

修饰次： 尽量用简写， 太长就拼音字母

时间： 制定简写规格表

数据域和业务过程： 制定简写规格表

模型的层次设计

操作数据层ODS层： 从源系统导出的数据，按分区存储。 原封不动进行存储。

公共维度模型层CDM层：

按照数据分析需求，加工明细表宽表（按时间紧急程度，也可多个宽表，较少字段可先加工出来，供后续继续加工）

从明细宽表，加工轻度为总表，也就是维度模型中的事实表

从轻度汇总表再加工出维度表。 买家维度， 卖家维度，会员维度，行业维度，地区维度

数据建模的基本原则：

1.将高概率访问的数据放一起，低概率访问的数据分开存储。

2.业务流程分核心模型表和扩展模型表： 核心模型表满足90%以上系统的字段需求，扩展模型表满足10%的系统需求。

（按照跑批的先后需求，核心模型表早期出数后，可提前发信号让下游系统使用，无需等到扩展模型表也出数再一起启动）

3.公共处理逻辑下沉，比如存款账户余额的获取的三种场景判断，等需要在底层模型完成，避免有多个程序处理。

4.适当冗余数据，减少join

5.数据可回滚，不同时间运行多次，数据结果确定不变。

6.不同表中相同含义的字段，在不同的表中，命名要一致。

7.统一命名规范

模型的实施过程：

1.前提： 数据域和业务过程的定义和完善，可以统一进行管理，迭代更新。

2.明确业务需求，提取原子指标，修饰词，周期

3.以业务指标为基础构建维度表

4.从维度表反推事实表，同时查看目前已经存在的事实表是否已经满足需求。

5.把指标纳入到已有的业务过程，数据域下。 或者新建数据域以及业务过程。

3.数据管理

元数据管理：

1.最原始需求就是让用户知道我们有什么数据，数据在什么位置，是否可用。

2.需要有丰富的表和字段说明，方便理解和使用

3.提供表字段的血缘关系图谱，方便评估数据依赖，数据变更的影响

4.数据标签： 对数据进行打标签，明确各方面的属性

基础标签：存储情况，访问情况，安全等级

数仓标签：增量还是全量，生命周期

业务标签：主题域，业务线，产品线等

5.DDL发布工具，变更通知到订阅人员，避免前端数据表结构变化，影响到下游系统等到变更完成才发现。

6.元数据门户，数据地图

7.表，字段的查询次数，关联次数，聚合次数，产出时间等，为建模进行指导。确定哪些字段能够进入到目标模型。

数据血缘关系的实现：

属于比较难实现的系统，属于元系统的进阶功能。 可分手工配置信息和自动识别信息，长期进行完善。

自动配置：

1.通过任务日志进行解析分析

2.根据任务依赖关系进行解析

计算管理：

优化的问题：

1.总体资源进行队列切分，并动态指派给不同的任务。队列统一管理，避免某些队列固定指派给某些系统，导致忙的忙死，闲的闲死。

2.队列切分，并大小分层。大的队列用于跑大任务，小队列用于跑小任务。队列切分的大小(CPU+内存分配)，依照任务的数据量大小，历史执行时间等来确定。

数据倾斜处理方案：

1.map倾斜

map读取数据到内存，可能有些map文件块读取的量特别大。 select * from **之后加上distribute by rand()来打乱不同map块的读写，并发到多个map块来读取。

2.join倾斜

join过程某路数据较小，可采用map join，提前到map阶段就join select /*+MAPJOIN(b)*/

join过程因为空值很多，对空值随机赋值 on coalesce(table_a.key,rand()*9999) = table_b.key

join过程大表join，热点数据导致长尾， 把热点数据单独到其他表，使用mapjoin，同时其他数据并发跑，最后union

3.reduce倾斜

count distinct操作，如果在一个SQL中出现多次，性能会急剧下降。 原因是Map端的数据，对于每个distinct都拷贝了一份，传给reduce。占用大量IO.

distinct和group by的性能差异，distinct不会在map的时候进行聚合，导致所有数据都传到reduce端操作。

值分布不均匀导致的长尾，可以用拆分热点mapjoin，然后再聚合

SQL语句中出现多个distinct， 使用group by来替代distinct