作者:蚂蚁金服数据中台技术专家-王飞(必武)
整理:平凡的世界-zkx,转载请注明出处。
第一节会介绍一下数据仓库的基本理论
第二节给大家介绍一下基于spark多数据源的集成,
第三节给大家介绍基于SparkSQL里面对数仓进行OLAP的分析
希望大家带着问题去看本博客的内容?
1.我们所有的系统都是围绕业务去解决问题的,从一些业务不同的视角,业务的视角,所看到的问题是不一样的。
比如,传统数据库解决的是什么样的业务问题?数据仓库又是解决什么样的问题?数据仓库和在传统数据库在形式上有较大的类似,
很多时候,都是使用sql语句对数据进行操作,但是他们的区别本质到底是什么呢?这个话题我们可以展开和大家聊一下。
2.第二个问题希望大家听完这节课,对数据仓库的基础架构有大致的了解,不同的核心模块使用哪些技术栈,业务模型是什么样子的?该怎么去设计模型?
3.第三个问题希望大家去了解一下spark构建数据仓库的核心能力,和数据仓库的哪些核心组件核心能力的要求是比较match的?方便进行技术选型。
4.如何使用Spark Core/Streaming去扩展数据仓库的多个数据源。
5.如何使用Spark进行OLAP? 除了sparksql还有哪些可以进行OLAP?
介绍数据仓库的基本理论,1991年 数据仓库之父 比尔恩门 下过这样一个定义,这个定义是比较受大家广泛接受的这样一个定义。用几个关键词描述了数据仓库?面向主题和集成的这几个关键词其实是描述了一个数据的特征,最后一个支持管理决策,介绍了一个数据仓库的一个使用场景。
面向主题跟传统的数据库相比的一个特征,传统数据库主要用的是OLTP的数据处理方式(联机事务处理方式),
OLTP要求数据仓库使用的是OLAP(联机分析处理方式),OLTP在处理的时候,侧重于事务的特性,要求数据操作的原子性,一致性等等。
所进行的操作是具体的action,一个行为,而数据仓库使用的OLAP做联机分析的时候,面向的是一个主题,是一个分析的话题,
比如想分析整个商品相连的趋势,相当于确定了一个主题,主题的主体就是商品,内容就是往年的相当的趋势,围绕整个主题,
构建整个OLAP所需要的数据,拿出来分析,最终达到一个结果。首先这个是面向主题,代表了对数据的处理方式,要的结果不同而定义的,
由于我们面向于一个主题做数据分析的时候,往往要需要多个数据源,不同的数据源,不同的业务系统数据合并到一起
日志,业务系统数据,数据的定义是全局的,要保证数据的一致性,无法放到一起进行数据分析。
比如会员系统,交易系统,商品浏览系统,3个不同的业务系统,3个系统合并到一起,来分析用户日常的消费行为。
在不同的系统中,对用户定义的字段是不一样的,有的是ID,有的可能是名字,有的可能是其他的来定义用户
,在把这些数据进行整合的时候,那我们就需要全局的用户定义,全局统一的用户定义来描述用户的信息
多个系统对数据定义的时候,要求数据是全局统一的,如果没有全局统一的数据是很难关联起来的。
相对稳定是传统数仓比较明显的特征,以前的数据,因为数据都是通过在线系统清洗出来的,
它不需要插入,和频繁的update,数据时效性要求不高。当前互联网的发展,当前的T+1离线分析场景以及不能满足了。
当前数据对时效性要求是挺高的,最近流行的流批都是解决数据时效性的问题。 比如lambad kappa架构。
时效性现在已经足够的打破了。
sparkstreaming通过时间驱动的,通过传入时间参数,返回这个时间阶段的RDD。
对sql解析,生成逻辑计划和物理计划,未解析的 解析后的 优化后的 可执行的物理计划,catalog是构建数据的元数据(数据源 udf 表结构的所有信息)
这节课请大家搞清这俩问题哈~
哪些操作是窄依赖?
数仓的特性有哪些?
问题总结:
1.write接口包含什么?
write接口包含Append Overwrite Ignore等等;
2.Catalyst优化的API开发的Spark任务包含什么?
优化的API开发的Spark任务包含DataFrame SQL DataSet等等
3.spark sql适合复杂的ETL分层的逻辑么。我看好多都是用hive写的。
答:你指的分层具体指什么,中间表临时表嘛?
追问:是的,ODS->DWD->DWS-ADM中的处理逻辑?
答: ODS->DWD->DWS->ADM 描述的是数据的分层,是为了方便进行数据管理的,更偏理论;实际应用的时候其实概念并不是 太强;SQL 只是用来连接表与表之间的计算关系,和实现这个数据分层并没有直接关系。
4.现在经常提到的数据中台和数仓之间是怎样的关系?
侧重点不一样,中台更强调服务,是业务和数据的连接层
5.A:从etl到事实表维表过程中,etl的结果也会在数仓中吗? 那对于数据源表新增字段等,有什么解决办法吗?
B:其实你问了一个比较细节的技术问题,表结构变化了,原始数据怎么处理;其实这个要看具体的存储模块能不能解决了;新增字段这种场景下,如何能够兼容老的数据结构(新增字段自动填充null),就可以解决;
A:那碰到复杂的ETL逻辑的时候,比如说生成大宽表的时候,通常都是上百个字段,那spark sql适用这类的复杂逻辑么?
B:看你自己接受程度吧,理论上SQL是能够表达的,但是处理太过复杂;我们自己的场景下就有100+字段的数据,但是我们不是用的SQL,我们自己定义的一套计算模型;模型化的数据可以使用程序自动生成,对于这种上百列的数据任务处理起来会更容易一点;
6.A:spark sql能否实现表结构的合并、基于原有属性派生新属性等较复杂的数据转换操作?B:自定义 UDF 能解决你的这个问题吗?
A:在spark中能基于ETL后的数据构建多维数据集吗?
B:多维数据集具体是指什么样的形式呢,能具体解释一下吗
A:微软的SSAS能构建多维数据集,多维数据集的形式就是您前面讲的星型模型或雪花模型,多维数据集中的数据以多维的形式而不只是二维的形式展示
B:时间+多维+事实列 构成了多维数据模型,数据处理的方式还是用 SQL 进行的
7.A:关于元数据管理,有哪些比较好的方案吗?
B: 你指的是维表数据,还是表信息相关的元数据?
A:表信息相关的元数据。
B:spark 默认提供了 Hive 的元数据,可以直接基于 Hive 管理元数据;
如果你是想自己管理元数据的话,很复杂,看你们自己的业务需要,投入产出比;
A:人为地去理解,把这三部分看成多维数据模型吧?
B:我是这么理解的,可能还要看具体的数据场景吧
8.增量ETL时,处理源数据删除的数据有什么思路吗?
B: 这是个数据建模的问题;如果你的数据是操作型的数据,可以把操作类型作为一个维度进行管理;计算分析的时候把操作类型作为选择分析方式的一个条件
A: 这个可以理解为,要修改etl处理source部分的处理逻辑吗?
B: 我没实际处理过这种问题;只能是探讨一下,原始数据是操作类型的数据,包含了删除等动作,在构建 明细表的时候,就可以是 以这种流水型的数据进行建模;创建一条记录->更新有一条记录->删除一条记录;根据行为进行数据的计算分析;