《大数据之路》学习笔记

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

目标和现状:

目标:

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

  • 发表于:
  • 原文链接:http://kuaibao.qq.com/s/20180108G0R2WR00?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。

扫码关注云+社区

领取腾讯云代金券