数仓相关概念。
我与大数据也是颇有渊源的。我还记得正儿八经地开始搬砖时,一开始便是etl脚本的改造,负责将tcl实现的脚本改写为python实现的Hive SQL脚本。随后又负责了文件的加解密和校验,后来才知道这项工作是属于“数据稽核”,其实就是对ftp下载的文件(文件中包含数据有多少条,加密值等),进行解密并校验数据是否存在异常。再后来接触到数仓,血缘关系,元数据治理,数据质量,任务调度,离线批处理,实时流处理等等。语言/技术栈从python,java,scala,hive,spark,zookeeper,kafka,flume,springmvc,springboot,如今又机缘巧合地专注于hive和spark源码相关的工作,再回首来读这本大数据之路,颇有感触。
1 数仓分层理念
ODS(Operational Data Store),操作数据层。通常是最原始的来源数据。
DWD(Data Warehouse Detail),明细数据层。通常叫明细层。
DWS(Data Warehouse Summary),汇总数据层。通常叫汇总成。
ADS(Application Data Store),应用数据层。通常叫应用层。
DWM(Data Warehouse Middle),中间数据层。通常叫中间层。
2 日志采集
PV(Page View):页面浏览量
UV(Unique Visitors):访客数
日志采集分两类:页面浏览日志采集(包含PV和UV)和页面交互日志采集(主要是用户在页面的操作动作)。
3 数据同步
3.1 批量数据同步
阿里数据同步开源工具DataX。但开源版本应用的话需要二次开发封装成产品。
3.2 实时数据同步
flumn + kafka
3.3 数据同步的问题和挑战
分库分表
高效同步和批量同步
增量与全量同步的合并
同步性能的处理
数据漂移的处理:数据漂移是指一个业务日期中包含前一天或后一天的数据,通常是凌晨附近的数据。
4 离线数据开发
4.1 一些产品
对于阿里系的产品,我们应该知道盘古(分布式文件系统),伏羲(任务调度系统),女娲(namespace服务),神龙(监控系统)。
我们还应该知道OTS(Open Table Service),也就是元数据服务。
顺便提一句,对于京东有大蛇系统(曾经在一次meeting up上一个很唬的京东同学宣称大蛇系统是业界最NB的,(⊙o⊙)…)
现在都流行搞统一的数据开发平台,好多公司都在推进这项工作,各有千秋。怎么说呢,这是一项很长远的工作,公司间对这一块的技术壁垒也很深。小厂基本都做的很渣渣,而大厂由于员工彼此跳槽的互动交流导致互相抄。这么来看,大厂间的员工流动也是一件好事,促进了技术的交流,打破了技术壁垒。
4.2 数据稽核
数据稽核,对应阿里的产品应该就是在彼岸了。
数据稽核说白了就是采用对源表和目标表的字段进行sum,avg,max,min等求值比对是否存在差异。这里分享一个我们这边用的方案:sum + hash 法。
这里还有一些数据脱敏等工作。
4.3 数据质量
数据质量一般是针对数据进行监控和清洗。
其中监控对数据不做任何处理,只是根据数据质量规则监控数据,脏数据超出一定阈值进行报警;而数据清洗(通常属于ETL的一个环节)则是根据数据质量规则,对数据进行清洗,但不会触发报警。
4.4 任务调度系统
调度系统是数仓中不可或缺的产品。现在大厂的调度系统套路基本一样:调度引擎(master)+ 执行引擎(worker)。通常调度引擎负责任务配置,以及任务各个参数的生成;执行引擎负责获取需要调度的任务,并分配资源拉起任务。
这里需要考虑的有任务的状态:生成批次,等待调度,等待资源,运行中,(这里可以可以嵌入数据质量的检查),成功,失败。
需要明确的是执行引擎只是负责将任务拉起来,具体执行的引擎可能是hive,spark,shell等等。
任务类型通常分为:周期性任务(小时级任务,天级任务,周级任务,月级任务);一次性任务(adhoc)。
按功能划分:例行任务和回溯任务。通常回溯任务最好能做到资源隔离,避免影响例行任务。
这里还有个基线的概念。任务的调度划分优先级,相同优先级的任务通常可以划分到相同的基线中,高优的任务基线需要高保障充足的资源倾斜。
当然监控报警是不可获取的。告警分电话,短信(个人或群组),邮件等。
SOA(Service Oriented Architecture):面向服务的架构。即微服务。
5 实时技术
对实时这一块,确实有很多感触。我记得是三四年前,那时候东家的数仓数据ODS数据接入是kafka,而ODS数据最终是需要落地的。通常spark streaming是用于实时场景,而在我之前东家是用于kafka数据的落盘使用的。至于为什么没有选择flume等其他工具,我想应该也是为了炫酷和技术匮乏吧(瞧,我用的是spark streaming。其实主要还是flume当时也没有人会用。)。
这里踩了无数的坑,架构一再调整。
第一版架构: kafka + spark streaming + hbase
说白了就是看有帖子这么讲实时架构,然后就拍脑门用了。最后发现hbase总是被打挂。从而hbase稳定性是无法保障(顺便也说明一个公司的引擎维护团队是多么地重要),最终弃用。
第二版架构:kafka + spark streaming + spark sql + hive
这版架构最后发现任务批次总是积压,最终发现瓶颈在于hive落盘的io压力太大,消费的速率赶不上生产的速率,另外,spark streaming实时写产生的小文件,集群难以承受,最终还是弃用。
第三版架构:kafka + flume + hdfs(hive)+ kafka + spark sql + hive
最后一版总算走入了正轨。也是异常曲折,由此可见,在小厂,每一个环节都是举步维艰。
而当时,flume其实已经很成熟了,但由于公司内负责这一块的只有几个会spark的(那时候spark streaming 也异常火爆),并没有flume技术栈的同学;另外,也缺乏对引擎架构选型的眼光,架构设计基本靠baidu。这里走过的弯路,显然是用高大上的实时架构方案来完成离线数据落盘。从根上就错了。
回过头来再看之前走过的路,对比阿里的技术方案,其实发现一开始就混淆了什么是实时,什么是离线,两者之间的界限在哪?实时应该采用什么技术方案?离线采用什么技术方案?用实时架构实现离线方案,是超前走在批流合一的噱头了么(那时候storm昙花一现,已经被flink打败了,而spark streaming还在挣扎中。flink最吸引眼球的便是批流合一。)?如今,flink有了阿里的大力研发,真正地崛起了。
5.1 数据采集
采集是实时处理的源头,通常实时数据来自于日志等。通常将采集到的数据吐到数据中间件(kafka等,也叫数据交换平台),共下游消费。
那么从数据中间件消费的数据一定就是实时吗?未必,如果中间件中的数据来自于离线,那根本就不是实时。
日志采集有多种方案:flume,logstash,filebeat,logagent等等。在技术选型前,一定要做好各个方案的性能测试,综合评估。
5.2 数据处理
数据处理技术,从之前的storm,到spark streaming,再到flink。从现在来看,基本都采用flink了。现在flink也支持了flink sql,让流处理不再神秘,可以像写sql一样实现流处理。
这里主要涉及到一个问题就是,实时处理程序是常驻进程,一旦宕机或其他原因进程挂掉,需要考虑到数据丢失的问题,能否忍受数据丢失?或如何做到重启服务之后的数据恢复。这就是需要考虑的容错机制ACK,事务问题和kafka消费偏移量记录的问题。
5.3 数据存储
之前已经提到,实时系统中保证低延时和查询性能,中间数据流转采用数据中间件(kafka等消息系统),数据最后的存储采用hbase,es等。
6 数据服务
数据服务目前来看阿里还是很领先了。对应我们这边的便是提取工具:提供统一的数据查询平台,用户直接通过sql查询,而底层查询引擎会承接presto,spark,hive等等。在查询性能上,优选presto,提供毫秒级的查询体验;当presto查询失败时,会进行降级,通过spark查询,提供秒级的查询体验;spark也失败时,通过hive兜底,提供分钟级的查询体验。而这些对于用户而言是透明的,用户并不知道自己的查询是通过什么查询引擎来实现的。
当然书中提到的稳定性保障,限流,降级,监控等等,这些应该是所有集中化服务产品都应具备的。
7 数据挖掘
不是特别了解。
8 大数据领域建模综述
OLTP和OLAP
OLTP(Online Transaction Processing):联机事务处理。强调事务,在线,高速,小查询。通常对应于关系型数据库。
OLAP(Online Analytical Processing):联机分析处理。强调分析,通常应用在决策分析系统中。
典型数仓建模理论
主要是集中数仓建模的方法论。既然是方法论,具体的落地和实践,可能在现实中往往是彼此交叉融合。
ER模型
ER(Entity Relationship):实体关系模型。
维度模型
维度模型从分析决策的需求出发构建模型。分析决策和维度的关系:分析通常是从不同的维度来分析,比如某类商品的维度;某类用户的维度等等。
具体到模型有星型模型和雪花模型。
DV模型
DV(Data Vault)模型有三部分:Hub(实体),Link(实体关系),Satellite(卫星体,也是详情)。
Anchor模型
DV模型的规范化。有四部分:Anchors(类似于Hub,实体但只有主键),Attributes(类似于Satellite),Ties(类似于Link),Knots(多个Anchors中公共属性的提炼,有点像维表)。
本文链接: https://stefanxiepj.github.io/archives/b34d08b8.html
版权声明: 本作品采用 知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议 进行许可。转载请注明出处!