目的是构建可分享的,规范的,统一的全域数据体系,提高数据提取效率,避免重复建设。
目标和现状:
目标:
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
领取专属 10元无门槛券
私享最新 技术干货