知识点01:回顾
-
Flume的功能和应用场景是什么?
- 功能:实现实时数据流的数据采集
- 应用:基于文件或者网络端口的实时数据采集
-
Flume中的Agent、Source、Channel、Sink分别是什么?
- Agent:每个agent就是一个独立的Flume程序
- Source:负责读取数据,动态监听数据源,将实时产生的数据封装为event,source将数据发送给Channel
- Channel:负责临时缓存数据
- Sink:负责读取Channel中的数据,将数据发送到目标地中
- Event:每一条数据对应一个Event对象
- header:存储KV
- body:数据的内容
-
如何开发一个Flume程序?
- step1:先开发配置文件:properties
- 定义Agent:名字、source、channel、sink
- 定义source:类型、属性
- 定义channel:类型、属性
- 定义sink:类型、属性
- step2:运行agent
- flume agent -c 配置文件目录 -f 运行的文件 -n agent名称
- step1:先开发配置文件:properties
-
exec source和taildir source的功能和特点分别是什么?
- exec:通过Linux命令来实现监听文件,动态采集文件中的变化的内容
- 特点:搭配tail -f 命令使用,只能监听单个文件
- taildir:动态监听多个文件
- exec:通过Linux命令来实现监听文件,动态采集文件中的变化的内容
-
file channel和memory channel的功能和特点分别是什么?
- file:性能相对慢、安全高、存储空间大
- 数据量大,性能要求不高
- mem:性能相对块、安全低、存储空间小
- 数据量小,性能要求高
- file:性能相对慢、安全高、存储空间大
-
HDFS sink的功能和应用场景是什么?
- 功能:将Flume采集的数据写入HDFS中
- 怎么设置文件大小:roll.size
- 怎么实现存储分区:通过添加时间标记
- 应用场景
- 用于实时数据采集到离线存储系统
- 代替Hive sink,实现数据仓库的数据采集
-
Sqoop的功能与应用场景?
- 功能:用于实现RDBMS与HDFS之间数据导入和导出
- 应用场景
- 数据同步:增量
- 数据迁移:全量
-
导入HDFS的常用选项有哪些?
- 命令:sqoop import
- 选项
- –connect:指定数据库连接地址
- –username:指定数据库用户名
- –password/–password-file
- –table
- –target-dir:指定写入的HDFS的目录
- –delete-target-dir
- -m/–num-mapper
- –column
- –where
- -e/–query:注意事项:必须加上where $CONDITIONS
- –fields-terminated-by
-
导入Hive的方式有几种?
-
方式一:直接导入
--hive-import --hive-database --hive-table
- 原理
- step1:通过MapReduce将数据导入HDFS
- step2:通过load命令加载到表的目录中
- 原理
-
方式二:hcatalog导入
--hcatalog-database --hcatalog-table
- 原理:直接获取了Hive元数据,使用表的目录作为MapReduce输出目录
-
-
增量导入的方式有几种?
- append
- 要求:必须有一列自增的int,通过判断上一次的值来实现追加导入
- 特点:只能导入新增的数据
- lastmodifield
- 要求:表中必须有一列时间列,时间随着数据的更新自动改变
- 特点:既能导入新增数据也能导入更新的数据
- 特殊方式:直接进行过滤采集
- 要求:每次运行的输出目录不能一样
- append
-
导出的选项有哪些?
- –export-dir
-
增量导出的方式有几种?
- updateonly:只能导出更新的数据
- allowerinsert:既能导出新增的数据,也能导出更新的数据
知识点02:目标
- 数据仓库中的核心设计:面试中常问
- 数据仓库的介绍
- 什么是数据仓库?数据仓库就是一个数据超市,将所有数据分类存放管理,加工,提供数据的应用
- 定义、功能、应用场景
- 特点
- 核心流程:ETL、分层、建模
- 数据仓库中的概念
- 维度:什么是维度?为什么使用维度?有哪些维度?
- 指标:什么是指标?功能是什么?有哪些指标?
- 大数据分析的需求:基于不同维度去分析各种指标
- 建模
- 什么是建模?
- 怎么建模?
- ER模型和维度模型
- 分层
- 什么是分层?
- 怎么分层?
- ODS、DW、DA
知识点03:数据仓库的功能与应用场景
-
目标:掌握数据仓库的功能与应用场景
-
路径
- step1:OLTP与OLAP
- step2:数据仓库功能
- step3:数据仓库应用
-
实施
- OLTP与OLAP
- OLTP:联机事务处理
- 场景:为了满足公司的买卖的业务场景,而给用户提供了注册、登录、订单等功能,为了实现这些功能而存储了数据
- 数据的使用者:用户
- 特点
- 业务性数据管理和存储
- 读写速度:快
- 满足事务性的需求
- 数据量相对较小
- 工具
- 一般选用关系型数据库来实现:MySQL、Oracle
- OLAP:联机分析处理
- 场景:为了满足运营决策的需求,将公司各种各样的数据,实现数据分析的管理
- 数据的使用者:运营、运维、领导层、数据分析师
- 特点
- 读写速度要求:按照一定时间周期进行处理,每个小时,每天
- 离线数据仓库:T+1
- 数据量:非常庞大
- 事务性的需求:不需要
- 读写速度要求:按照一定时间周期进行处理,每个小时,每天
- 工具
- 一般使用专业数据仓库工具来实现:Hive、GreepNum
- OLTP:联机事务处理
- 数据仓库功能
- 功能:为了满足OLAP场景下的数据管理需求
- 存储:管理
- 处理:将各种原始数据进行规范化的处理,提供给各个需求方
- 本质:是一种分布式、统一化的、规范化的数据管理的设计模型
- 功能:为了满足OLAP场景下的数据管理需求
- 数据仓库应用
- 应用场景:满足企业中所有数据的统一化存储,通过规范化的数据处理来实现企业的数据分析应用
- OLTP与OLAP
-
小结
- 数据仓库的功能与应用场景是什么?
- 功能:为了满足OLAP场景而实现的一种数据管理的设计模型
- 存储:实现各种数据统一化的存储
- 处理:将各种原始数据进行规范化的处理,提供数据的应用
- 应用:满足各种企业实现统一化和规范化的数据分析的应用
- 功能:为了满足OLAP场景而实现的一种数据管理的设计模型
- 数据仓库的功能与应用场景是什么?
知识点04:数据仓库的特点
-
目标:掌握数据仓库的核心特点
-
实施
-
面向主题:按照主题划分数据的应用需求
-
数据库:面向业务
- 人事部门:人事管理系统:人事数据库中
- 在职人员信息
- 离职人员信息
- 财务部门:财务管理系统:财务数据库中
- 支持数据表
- 收入数据表
- 盈利数据表
- 人事部门:人事管理系统:人事数据库中
-
数据仓库:面向主题的
-
数据仓库:公司中所有的数据全部通过数据采集或者数据同步进入数据仓库【超市 = 所有数据】
-
数据集市/主题域:一般都是按照部门划分【商品类别=数据类别】
- 销售数据集市 - 财务数据集市 - 人事数据集市 - 运维数据集市 - 运营数据集市
-
数据主题:各个应用对应的主题【商品细分 = 应用类别】
订单主题 收入主题、支出主题、税务主题 在职人员主题、离职人员主题 应用日志主题、机器日志主题 来源分析主题、用户分析主题……
-
-
-
-
-
数据集成:存储整个公司所有数据,为公司所有数据的需求方提供数据
- 数据仓库本身不产生数据,也不使用数据
- 数据仓库会将整个公司采集到的所有数据源的数据进行存储,提供给各个数据的应用方
-
非易失/稳定性:按照数据仓库的业务需求,没有更新和删除的业务
- 更新:没有,如果修改了数据,修改了数据的真实性,分析的结果就不对了
- 删除:没有,工作中会出现删除老的历史数据,不会删除使用的数据
-
时变性/动态性:数据仓库中会按照时间记录时间发生变化的数据状态
- 数据仓库中的数据随着时间的变化会不断增加
- 变化状态:增加
-
-
小结
-
数据仓库的核心特点有哪些?
- 面向主题
- 数据集成
- 非易失
- 时变性
-
知识点05:数据仓库核心流程
-
目标:掌握数据仓库的核心实现流程
-
路径
- step1:ETL
- step2:分层
- step3:建模
-
实施
-
ETL
-
功能:Extract、Transform、Load:抽取、转换、加载,将原始数据根据需求进行处理,将处理好的数据再写入HDFS
-
阶段:两个阶段
-
数据生成
-
数据采集:第一个阶段是采集之后
-
采集:采集后的数据放在HDFS上
/nginx/log/source/2021-05-09/20210509.log
- 数据不一定是标准的结构化格式
-
ETL:过滤、补全、转换
/nginx/log/etl/2021-05-09/20210509.log
- 通过代码进行开发:MapReduce、SparkCore
-
入库:将ETL以后的每一天的数据作为Hive表的一个分区
-
-
数据存储:第二个阶段是数据仓库中
- ETL场景:数据本身就是结构化的,直接加载到Hive表中
- 实现:通过SQL来实现ETL
-
数据计算
-
数据应用
-
-
实现:过滤、转换、补全
-
过滤:将不需要的数据,或者非法的数据进行过滤
-
数据中有10个字段,发现一条数据只有1个字段
-
数据中重要的字段丢失:ip/userid/sessionId
-
-
转换:将原始数据格式变成我们想要的数据格式
-
解密:数据本来采集的时候是加密的,ETL时候实现解密操作
-
格式:18/Aug/2021:19:30:00 =》 2021-08-18 19:30:00
-
-
补全:需要使用的数据,但是原始数据中没有
-
通过解析IP地址:得到用户所在的位置:国家、省份、城市
-
通过时间信息:补全年、月、日、周、季度
-
-
-
-
分层
-
功能:规定数据在数据仓库中处理的步骤
-
实现:每一层就是一个数据库,不同层的数据表在不同的数据库中
-
-
建模
- 功能:决定了数据表如何构建
- 实现:ER建模、维度建模等
-
-
小结
- 数据仓库的核心流程有哪些?
- ETL:数据的过滤、转换、补全
- 分层:决定了数据在数据仓库中处理的步骤
- 建模:决定了如何建表
- 数据仓库的核心流程有哪些?
知识点06:指标设计
- 目标:掌握数据仓库业务中的指标
- 路径
- step1:指标的功能
- step2:常见基础指标
- 实施
- 指标的功能
- 概念:对数据统计分析得到的结果,就是指标,也称为指数【指标是通过数值来体现的】
- 功能:通过指标来衡量事实的结果,反映事实的好坏
- 大数据分析的目的:发现产品公司或者平台存在的问题,解决问题
- 指标:通过指标来发现问题
- 常见基础指标
- 每个行业的需求不同,指标也不同
- PV:page view,用于反映网页的访问量
- 字段:url
- 统计:count(url)
- UV:unique view:用于反映网站的用户访问量
- 字段:访客id,userid、uuid、guid
- 访客id:只要访问了,就有这个id
- 统计UV:统计访问人数
- 会员id:登陆了,就有会员id
- 统计登陆人数
- 会话id:与服务端构建了连接,服务端会分配Session Id
- 访客id:只要访问了,就有这个id
- 计算:count(distinct userid)
- 字段:访客id,userid、uuid、guid
- IP:用于反映IP的个数,IP可以反映用户群体的分布
- 字段:ip
- 计算:count(distinct ip)
- 跳出率:只访问了一个页面的会话个数 / 总的会话的个数
- 字段:sessionId
- 计算:PV等于1的Session个数 count(case pv = 1 else sessionId else null) / 总的会话个数 count(distinct sessionId)
- 越低代表用户粘性越高,平台的运营就越好
- 二跳率:访问了两个页面及以上的会话个数 / 总的会话个数
- 字段:sessionId
- 计算:PV大于1的Session个数 count(case pv > 1 else sessionId else null) / 总的会话个数 count(distinct sessionId)
- 平均访问时长:总的Session访问时间 / 总的session个数
- 字段:time,sessionId
- 计算:sum(访问最后一个页面的时间 - 访问第一个页面时间) / count(distinct sessionId)
- 指标的功能
- 小结
- 什么是指标?常见的指标有哪些?
- 指标:对数据统计分析的结果,就是指标,也叫作指数
- 作用:反映一个事实好坏
- 常见的指标:自己记住,不断的积累
- 自己回去学习常见的分析指标:神策,里面提供了非常多的各个行业分析指标
- PV、UV、IP、跳出率、二跳率、平均访问时间、访问次数、留存率……
- 教育:考勤分析、考试分析、报名转换率
- 电商:总订单个数、退款订单个数、总成交额、热门商品Top10
- 游戏:闯关率、等级平均升级时长、装备爆出率
- ……
- 什么是指标?常见的指标有哪些?
知识点07:维度设计
-
目标:掌握数据仓库中维度的设计
-
路径
- step1:维度的概念
- step2:维度的功能
- step3:常见维度
- step4:上钻与下卷
-
实施
- 维度的概念
- 用于描述事实的角度
- 大数据分析目的:发现问题,调整方案,支撑运营和决策的
- 指标:UV:100
- 描述:昨天的UV是1000,今天的UV是100
- 结果:是不好的,因为基于时间维度做了对比
- 指标如果不基于组合维度进行分析得到,这个指标是没有意义的
- 昨天的UV是1000,今天的UV是100
- 基于多个组合维度来看:时间 + 地区
- 地区维度
- 昨天的1000,是十个地区的结果,每个地区都有100个UV
- 今天的100,是1个地区的结果,这个地区只有100个UV
- 今天的100,是十个地区的结果,有1地区只有100个UV,其他九个地区都是0
- 地区维度
- 用于描述事实的角度
- 维度的功能
-
基于组合维度来更加细化我们的指标,来更加精确的发现问题
-
问题:去年营业额2000万、今年营业额:2000万【基于时间年维度】
-
目的:为什么今年营业额没有增长?
-
实现:发现问题
-
校区的问题
- 去年每个校区都是100万
- 统计今年每个校区的营业额【基于时间年+校区】
- 是否有个别校区拖后腿的,其他校区都在增长,而这个校区降低了
-
学科的问题
- 统计今天每个学科的营业额【基于时间年+学科】
-
每个月对应的营业额
-
-
- 常见维度
- 维度一般是固定的:很少发生变化
- 时间维度:年、季度、月、周、天、小时
- 地区维度:国家、省份、城市
- 平台维度:网站、APP、小程序、H5
- 操作系统维度:Windows、Mac OS、Android:IOS
- 校区维度
- 学科维度
- ……
- 下钻与上卷
- 下钻:当前基于一个大的维度进行分析,要下钻到一个更细的维度进行分析
- 先按年分析
- 然后按照小时分析
- 上卷:当前我的分析是基于一个小的维度的进行分析,要上卷到一个大的颗粒维度来进行分析
- 先按每个小时分析
- 然后按照每天分析
- 下钻:当前基于一个大的维度进行分析,要下钻到一个更细的维度进行分析
- 维度的概念
-
小结
-
什么是维度?常见的维度有哪些?
- 本质:用于描述事实的角度
- 功能:用于细化对指标事实的分析,更加精确发现对应的问题
- 常见
- 时间维度:年、季度、月、小时、天
- 地区维度
- 运营商维度
- 平台维度
- 来源渠道维度
- ……
-
实现:统计每天每个地区的UV
-
指标:UV,count(distinct userid)
-
维度:天、地区
-
实现
select 天,地区,count(distinct userid) as uv from table group by 天,地区;
-
-
知识点08:建模:ER模型
-
目标:了解ER模型的设计及构建过程
-
路径
- step1:ER模型的应用
- step2:ER模型的构建
-
实施
-
ER模型的应用
- 实体关系模型
- 一般应用于OLTP的关系型数据库系统来实现业务数据库的建模,实现满足业务的数据存储
- 思想:实现业务存储、通过外键构建数据关联关系、避免冗余存储,记录事件的产生
-
ER模型的构建
-
流程
- step1:找到所有实体,以及每个实体的属性
- step2:找到所有实体之间的关系
- step3:建表,每个实体与每个关系都是一张表
-
角色
- 实体、属性、关系
-
举个栗子
-
小明在商店买了一双800块的鞋
-
实体
-
小明:用户实体
用户id 用户name 用户age 手机 密码
-
商店:店铺实体
店铺id 店铺名称 营业执照 经营范围 地址
-
鞋:商品实体
商品id 商品名称 尺寸 颜色 价格
-
-
关系
-
订单:实体之间的购买关系
订单id 用户id 店铺id 商品id 订单价格 支付方式 ……
-
-
建表
- 实体:用户、商品、店铺
- 关系:订单
-
-
优点
- 符合数据库的设计规范,没有冗余数据,保证性能,业务的需求把握的比较全面
-
缺点
- 设计时候非常复杂,必须找到所有实体和关系,才能构建
-
-
-
小结
- 了解ER模型的应用及构建流程
知识点09:建模:维度模型
-
目标:掌握维度模型的设计及构建过程
-
路径
- step1:维度模型的应用
- step2:维度模型的构建
-
实施
-
维度模型的应用
- 一般应用于大数据的数据仓库的模型构建,用于通过不同维度来反映事情的好坏
-
维度模型的构建
-
角色
- 维度:基于不同维度下的指标的结果,看待指标的角度
- 事实:就是通过指标来反映事实
- 流程
- step1:构建所有维度
- step2:基于维度分析事实
-
举个栗子
-
小明在商店买了一双800块的鞋
-
维度
- 小明:用户维度
- 商店:店铺维度
- 鞋:商品维度
-
事实:指标【数值】
- 一双:衡量多少
- 800块:衡量贵或者便宜
-
维度表
- 一个维度可以有一张表,也可以有多张表
-
事实表
- 多个事实放在一张表中
时间维度 地区维度 平台维度 UV PV IP 跳出率 二跳率
-
-
-
小结
- 什么是维度模型?
- 基于不同维度实现统计分析各种指标事实,用于描述事实的结果
- 什么是维度模型?
知识点10:事实表
-
目标:了解事实指标值的分类及事实表的分类
-
路径
- step1:事实指标值的分类
- step2:事实表的分类
-
实施
-
事实指标值的分类
- 可累加类型:基于不同的维度和统计可以直接进行累加的值
- 举个栗子:PV
- 统计这个月每天的PV
- |
- 统计这个月的PV
- 举个栗子:PV
- 半可累加类型:在有一些维度下可以累加,在有一些维度下不可以累加
- 举例:银行余额
- 可以累加:账户维度
- 不可以累加:时间
- 举例:银行余额
- 不可累加类型:在任何维度下,指标的累加是没有意义的
- 举例:比例类型
- 空值:不建议产生空值,事实表中是不会出现空值
- 即使指标没有结果,也为0
- 可累加类型:基于不同的维度和统计可以直接进行累加的值
-
事实表的分类
-
事务事实表:原始的事务数据,业务数据
-
例如:订单信息表:记录每一条订单事实的信息
时间 订单id 商品id 订单价格…… 2021-01-01 12:00:00 2021-01-01 12:00:01 2021-01-01 12:00:01 ……
- 大数据中就是原始业务数据
-
-
周期快照事实表:基于事务事实表按照一定的周期进行聚合
-
例如:订单统计表:统计得到每天的订单总个数和订单总金额
天 订单总个数 订单总金额 2020-01-01 1000 2000
- 大数据中就是统计分析的结果表
-
-
累积快照事实表:事实的结果随着时间的变化而不断完善
-
例如:订单状态表
订单id 提交成功 支付成功 发货状态 收货状态 退货状态 order001 12:00:00 12:01:00
-
-
无事实事实表:特殊的事实表,无事实的事实表中没有度量值,只有多个维度外键,一般用于业务维度关联
-
举例栗子:可以统计分析哪些商品销售的比较好,商品销售量、销售总金额
-
需求:哪些商品在今天没有卖出?
-
无事实事实表中:记录所有上架的商品的信息
-
所有商品id
今天 商品id
-
-
订单事实表中:记录所有被销售的商品的信息
-
订单中的商品id
今天 订单id 商品id
-
-
-
-
-
-
小结
- 事实指标值分为哪几类?
- 可累加事实值
- 半可累加事实值
- 不可累加事实值
- 事实表分为哪几类?
- 事务事实表
- 周期快照事实表
- 累积快照事实表
- 无事实事实表
- 事实指标值分为哪几类?
知识点11:维度表:雪花模型
-
目标:了解维度模型中的雪花模型
-
路径
- step1:雪花模型的结构
- step2:雪花模型的构建
-
实施
-
雪花模型的结构
-
维度模型构建的方式:决定了维度表与事实表怎么关联
-
雪花模型:如果对于一个维度,它有子维度,将子维度关联在父维度上的
- 优点
- 减少数据冗余存储
- 缺点
- 每一次要想获取具体的数据,必须关联每一张子表,性能比较差
- 优点
-
-
-
雪花模型的构建
-
时间维度
- 事实表
-
时间维度id 地区维度 平台维度 UV IP PV
4 11111
- 时间维度:B
时间维度id year:外键 month:外键 day :外键
1 1 1 1
4 19 -1 -1
- 年维度表:B1
yearid yearvalue
1 2000
……
10 2009
19 2020
……
100 2099
-
月维度表
monthid month 1 01 …… 12 12
-
天维度表
dayid dayvalue 1 1 …… 31 31
-
地区维度
-
地区维度表
地区维度id 国家维度id 省份维度id 城市维度id
-
国家维度表
-
省份维度表
-
城市维度表
-
-
小结
- 了解雪花模型的设计
知识点12:维度表:星型/星座模型
-
目标:掌握维度模型中星型模型和星座模型的设计
-
路径
- step1:星型模型的设计
- step2:星型模型的构建
- step3:星座模型
-
实施
-
星型模型的设计
- 所有维度表直接关联事实表,维度表不存在子表
- 优点
- 每次查询时候,直接获取对应的数据结果,不用关联其他的维度子表,可以提高性能
- 缺点
- 数据冗余度比较高
-
-
星型模型的构建
-
时间维度表
时间维度id year month day type 1 2020 01 01 day 2 2020 01 02 …… 4 2020 1 -1 month 5 2020 -1 -1 year
-
地区维度表
地区维度id 国家 省份 城市 类型 1 中国 上海 浦东 市 2 中国 上海 徐汇 市 …… 10 中国 上海 -1 省 11 中国 -1 -1 国
-
需求:统计基于基于时间维度下以及地区维度下的PV、UV、IP
- 事实表
-
时间维度id 地区维度id PV UV IP
1 1 10 1 1
4 -1 1000 100 20
5 -1 1000 200 0
-
星座模型
- 星座模型:基于星型模型的演变,多个事实共同使用一个维度表
-
小结
- 什么是星型模型?
- 所有维度表直接关联事实表,维度表不存在子表,所有单类维度数据都在一个维度表中
- 什么是星座模型?
- 基于星型模型,多个事实共享维度表
- 什么是星型模型?
知识点13:渐变维度
-
目标:了解数据仓库中渐变维度数据的处理方案
-
路径
- step1:渐变维度问题
- step2:处理方案
-
实施
-
渐变维度问题
-
维度数据发生变化,如何处理发生变化的数据
-
举例
-
每个用户会对应一个工作地区,2019年在北京
-
2020搬到了三亚
-
-
- 现在是2020年,需要对2019年的北京的数据进行统计,这条数据是否参与统计? - 应不应该参加统计? - 应该 - 如果参与统计,数据中是没有的,无法统计,数据是如何存储的?
-
处理方案
-
SCD1:通过更新维度记录直接覆盖已存在的值
-
当2020年对2019年对北京进行统计的时候,按照覆盖的机制,这个人没有北京的记录,不会被统计
-
结果不准确了
-
-
SCD2:构建拉链表,根据不同的时间来标记这一列不同的状态
- 记录这个用户的所有状态的变化
| 用户id | 所在的地区 | 时间标记:start | 时间标记:end |
| ------ | ---------- | --------------- | ------------- |
| 1001 | beijing | 2018-01-01 | 2020-01-01 |
| 1001 | sanya | 2020-01-01 | 2021-01-01 |
| 1001 | meiguo | 2021-01-01 | 9999-12-31 | -
工作中的需求是可以指定日期查询对应的状态
-
where starttime >= 2019 and end < 2020
-
默认应该处理最新的状态:通过9999-12-31,来标记这是最新的状态
- where endtime = 9999-12-31
-
-
SCD3:通过增加列的方式来记录每个状态
用户id 工作城市1 工作城市2 10001 beijing sanya - 不能满足需求,一般不用
-
-
-
小结
- 重点了解拉链表的处理方案
知识点14:分层设计
- 目标:了解分层的设计
- 实施
-
目的
- 决定数据在数据仓库中处理的流程
- 数据从进入到被应用,总共经过哪些步骤
- 决定数据在数据仓库中处理的流程
-
实现
- 每一层在HIve中就是一个数据库而言,每一层的表放在对应的数据库中
-
架构
- 原始数据层
- 名称:ODS,原始数据层或者操作数据层
- 功能:用于存储最原始的数据
- 数据仓库层
- 名称:DW:DWD、DWM、DWS,专门用于实现原始数据的处理和加工转换的
- 功能:实现原始数据的转换处理
- 数据应用层
- 名称:DA/APP/ADS,存储最终要被使用的数据的
- 功能:存储结果
- 原始数据层
-
-
小结
- 分层的目的是什么?
- 规范化的决定了数据在数据仓库中处理的步骤流程
- 分层的目的是什么?
知识点15:常见层次
- 目标:掌握数据仓库常用的层级及每个层级的功能
- 实施
- 每个公司的分层都不一样,常见的层次要记住功能
- ODS:原始数据层
- 专门用于存储原始数据的,数据与原始的业务数据是一致的
- DWD:详细数据层
- 一般用于将ODS的结果进行ETL处理,存储在DWD层中
- DWM:中间数据层
- 用于对DWD层的数据进行轻量级的通用性的处理和聚合的
- 一般看业务需求,如果简单的业务,一般不需要DWM层
- DWS/DM:汇总数据层/数据集市层
- 用于实现最终所有维度的指标的聚合分析,不同的部门需要的数据进行单独的划分
- APP/DA/ADS:数据应用层
- 用于存储最后应用的结果
- DIM:维度数据层
- 用于存储维度表的数据
- 有的公司的维度表时放在数据仓库Hive中,有的公司的维度表是在MySQL中
- TMP:临时数据层
- 一般用于存储一些临时数据表
- 小结
- 常见的层次有哪些?
- ODS
- DWD
- DWM
- DWS
- APP
- DIM
- TMP
- 常见的层次有哪些?
知识点16:分层案例
-
目标:理解案例中分层设计的实现
-
实施
- 电商案例
- 斗鱼案例
-
美团数仓设计
- https://tech.meituan.com/2017/05/26/hotel-dw-layer-topic.html
-
携程数仓设计
- https://mp.weixin.qq.com/s/CfxNcMJIl6irunrTNTs25g
-
小结
- 了解基本分层的设计
转载:https://blog.csdn.net/qq_45925467/article/details/116569356