作者：蚂蚁金服数据中台技术专家－王飞（必武）
整理:平凡的世界-zkx,转载请注明出处。
image.png
image.png
第一节会介绍一下数据仓库的基本理论
第二节给大家介绍一下基于spark多数据源的集成，
第三节给大家介绍基于SparkSQL里面对数仓进行OLAP的分析
希望大家带着问题去看本博客的内容?
1.我们所有的系统都是围绕业务去解决问题的，从一些业务不同的视角，业务的视角,所看到的问题是不一样的。
比如，传统数据库解决的是什么样的业务问题?数据仓库又是解决什么样的问题?数据仓库和在传统数据库在形式上有较大的类似,
很多时候，都是使用sql语句对数据进行操作，但是他们的区别本质到底是什么呢?这个话题我们可以展开和大家聊一下。
2.第二个问题希望大家听完这节课，对数据仓库的基础架构有大致的了解，不同的核心模块使用哪些技术栈，业务模型是什么样子的?该怎么去设计模型?
3.第三个问题希望大家去了解一下spark构建数据仓库的核心能力，和数据仓库的哪些核心组件核心能力的要求是比较match的？方便进行技术选型。
4.如何使用Spark Core/Streaming去扩展数据仓库的多个数据源。
5.如何使用Spark进行OLAP? 除了sparksql还有哪些可以进行OLAP？
image.png
image.png
介绍数据仓库的基本理论，1991年 数据仓库之父 比尔恩门 下过这样一个定义，这个定义是比较受大家广泛接受的这样一个定义。用几个关键词描述了数据仓库?面向主题和集成的这几个关键词其实是描述了一个数据的特征，最后一个支持管理决策，介绍了一个数据仓库的一个使用场景。
image.png
面向主题跟传统的数据库相比的一个特征，传统数据库主要用的是OLTP的数据处理方式(联机事务处理方式)，
OLTP要求数据仓库使用的是OLAP(联机分析处理方式)，OLTP在处理的时候，侧重于事务的特性，要求数据操作的原子性，一致性等等。
所进行的操作是具体的action,一个行为，而数据仓库使用的OLAP做联机分析的时候，面向的是一个主题，是一个分析的话题，
比如想分析整个商品相连的趋势，相当于确定了一个主题，主题的主体就是商品，内容就是往年的相当的趋势,围绕整个主题，
构建整个OLAP所需要的数据,拿出来分析，最终达到一个结果。首先这个是面向主题，代表了对数据的处理方式,要的结果不同而定义的，
image.png
由于我们面向于一个主题做数据分析的时候，往往要需要多个数据源，不同的数据源，不同的业务系统数据合并到一起
日志，业务系统数据，数据的定义是全局的，要保证数据的一致性，无法放到一起进行数据分析。
比如会员系统，交易系统，商品浏览系统，3个不同的业务系统，3个系统合并到一起，来分析用户日常的消费行为。
在不同的系统中，对用户定义的字段是不一样的，有的是ID，有的可能是名字，有的可能是其他的来定义用户
，在把这些数据进行整合的时候，那我们就需要全局的用户定义,全局统一的用户定义来描述用户的信息
多个系统对数据定义的时候，要求数据是全局统一的，如果没有全局统一的数据是很难关联起来的。
image.png
image.png
相对稳定是传统数仓比较明显的特征，以前的数据，因为数据都是通过在线系统清洗出来的，
它不需要插入，和频繁的update,数据时效性要求不高。当前互联网的发展，当前的T+1离线分析场景以及不能满足了。
当前数据对时效性要求是挺高的，最近流行的流批都是解决数据时效性的问题。 比如lambad kappa架构。
时效性现在已经足够的打破了。
image.png
image.png
image.png
image.png
image.png
image.png
image.png
image.png
image.png
image.png
image.png
image.png
image.png
image.png
image.png
image.png
image.png
image.png
image.png
image.png
image.png
image.png
image.png
image.png
image.png
image.png
image.png
image.png
image.png
sparkstreaming通过时间驱动的，通过传入时间参数，返回这个时间阶段的RDD。
image.png
image.png
image.png
image.png
image.png
image.png
image.png
对sql解析,生成逻辑计划和物理计划，未解析的 解析后的 优化后的 可执行的物理计划,catalog是构建数据的元数据(数据源 udf 表结构的所有信息)
image.png
这节课请大家搞清这俩问题哈～
哪些操作是窄依赖?
数仓的特性有哪些?
问题总结:
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： 我没实际处理过这种问题；只能是探讨一下，原始数据是操作类型的数据，包含了删除等动作，在构建 明细表的时候，就可以是 以这种流水型的数据进行建模；创建一条记录->更新有一条记录->删除一条记录；根据行为进行数据的计算分析；
网友评论