第一章:了解DW
1.1什么是数据仓库?
数据仓库(Data Warehouse),简称DW。数据仓库顾名思义,是⼀个很⼤的数据存储集合,出于企业的分析性报告和决策⽀持⽬的⽽创建,对多样的业务数据进⾏筛选与整合。它能为企业提供⼀定的BI(商业智能:例如数据挖掘、数据分析和数据报表)能⼒。有了数据报表,还可以指导业务流程改进。
•由数据仓库之父比尔·恩门(BillInmon)提出
•数据仓库是一个面向主题的、集成的、非易失的且随时间变化的数据集合
•主要用于组织积累的历史数据,并使用分析方法(OLAP、数据分析)进行分析整理,进而辅助决策,为管理者、企业系统提供数据支持,构建商业智能。
1.2数据仓库诞生的原因:• 历史数据积存 • 企业数据分析需要
历史数据积存
• 历史数据使用频率低,堆积在业务库中,导致性能下降
1.3数据仓库诞生的背景:
-企业数据分析需要:•各个部门自己建立独立的数据抽取系统,导致数据不一致。
1.4数据仓库解决什么问题?
数据仓库是应景大数据而生的,解决的问题无非就是存储和快速提取, 另外还有跨部⻔应⽤的功能。
对于不同数据整合到了数据仓库之后,也就是大数据有了存储的位置;我们可以不同的部门进行不同的应用(例如数据挖掘、数据分析、报表展示和查询等等);而快速提取是我们对于数据仓库的基本需求,所以数据仓库在设计起初就要具备快速提取的功能。而技术实现呢,就是分布式。
1.5数据仓库的主要特征
-⾯向主题的:传统数据库最大的特点就是面向应用进行组织数据,一个业务系统管理一部分企业数据,多个业务系统之间呢是相互分离的,而数据仓库则是面向主题的。我们可以通过从上图中的源数据那部分看到,它把多个业务的数据来整合,所以是面向主题的。
实例
-集成的:集成是指数据仓库中数据必须是一致的,也就是我们要通过ETL进行软码编辑。数据仓库的数据是从原有的、分散多个数据仓库、数据文件、用户日志中抽取出来的,那数据来源上可能既有内部数据,又有外部数据。
数据仓库中的数据是为分析而服务的,而分析呢又需要多种、广泛的不同数据源、数据,以便进行比较、鉴别。因此数据仓库中的数据必须从多个数据源中获取。那这些数据源就包括我们在上篇博客介绍过的内部数据、外部数据、文件系统以及网上的其他数据等。这些是通过数据集成而形成数据仓库的数据,所以它是集成的。
-非易失:保存的数据是一系列历史快照,不允许被修改,只允许通过工具进行查询、分析。
-时变性:数仓会定期接收、集成新的数据,从而反映出数据的最新变化。
1.6数据仓库 VS 数据库
• 数据库面向事务设计,属于OLTP(在线事务处理)系统,主要操作是随机读写;在设计时尽 量避免冗余,常采用符合范式规范来设计 。
• 数据仓库是面向主题设计的,属于OLAP(在线分析处理)系统,主要操作是批量读写;关 注数据整合,以及分析、处理性能;会有意引入冗余,采用反范式方式设计。
1.7 技术的实现
传统数据仓库:
• 由关系型数据库组成MPP(大规模并行处理)集群
问题:扩展性有限,热点问题
大数据数据仓库:
• 利用大数据天然的扩展性,完成海量数据的存放
• 将SQL转换为大数据计算引擎任务,完成数据分析
问题:SQL支持率,事务支持
1.8 MPP & 分布式架构
MPP架构
• 传统数仓中常见的技术架构,将单机数据库节点组成集群,提升整体处理性能
• 节点间为非共享架构(Share Nothing),每个节点都有独立的磁盘存储系统和内存系统
• 每台数据节点通过专用网络或者商业通用网络互相连接,彼此协同计算,作为整体提供服务
• 设计上优先考虑C(一致性),其次考虑 A(可用性),尽量做好P(分区容错性)
架构优点
• 运算方式精细,延迟低、吞吐低
• 适合中等规模的结构化数据处理
架构缺点
• 存储位置不透明,通过Hash确定数据所在的物理节点,查询任务在所有节点均会执行
• 并行计算时,单节点瓶颈会成为整个系统短板,容错性差
• 分布式事务的实现会导致扩展性降低
分布式架构
• 大数据中常见的技术架构,也称为Hadoop架构/批处理架构
• 各节点实现场地自治(可以单独运行局部应用),数据在集群中全局透明共享
• 每台节点通过局域网或广域网相连,节点间的通信开销较大,在运算时致力减少数据移动
• 优先考虑的是P(分区容错性),然后是A(可用性),最后再考虑C(一致性)
架构特点
• 解决了单点故障问题,会将出错的任务调度到其他副本节点
• 运算方式粗犷,吞吐量大
• 扩展性极强,适合处理非结构化、半结构化数据
• 需要将中间结果进行存储,且数据移动开销较大
MPP + 分布式架构
• 数据存储采用分布式架构中的公共存储,提高分区容错性
• 上层架构采用MPP,减少运算延迟
第二章:数据仓库的架构
2.1 架构图
数据仓库各层说明:
一、数据加载层:ETL(Extract-Transform-Load)
二、数据运营层:ODS(Operational Data Store)
三、数据仓库层:DW(Data Warehouse)
1. 数据明细层:DWD(Data Warehouse Detail)
2. 数据中间层:DWM(Data WareHouse Middle)
3. 数据服务层:DWS(Data WareHouse Service)
四、数据应用层:APP(Application)
五、维表层:DIM(Dimension)
分层好处:
清晰数据结构:每一个数据分层都有它的作用域和职责,在使用表的时候能更方便地定位和理解
减少重复开发:规范数据分层,开发一些通用的中间层数据,能够减少极大的重复计算
统一数据口径:通过数据分层,提供统一的数据出口,统一对外输出的数据口径
复杂问题简单化:将复杂的任务分解成多个步骤来完成,每一层只处理单一的步骤,比较简单和容易理解。当数据出现问题之后,不用修复所有的数据,只需要从有问题的步骤开始修复。
屏蔽原始数据的异常:不必改一次业务就需要重新接入数据。
2.2 ETL流程
ETL -- Extract-Transform-Load
• 将数据从来源端经过抽取(extract)、交互转换(transform)、加载(load)至目的端的过程
• 构建数据仓库的重要一环,用户从数据源抽取出所需的数据,经过数据清洗,最终按照预先定义好的数据仓库模型,将数据加载到数据仓库中去
• ETL规则的设计和实施约占整个数据仓库搭建工作量60%~80%
数据抽取(Extraction)
• 抽取的数据源可以分为结构化数据、非结构化数据、半结构化数据
• 结构化数据一般采用JDBC、数据库日志方式,非/半结构化数据会监听文件变动
抽取方式
• 数据抽取方式有全量同步、增量同步两种方式
• 全量同步会将全部数据进行抽取,一般用于初始化数据装载
• 增量同步方式会检测数据的变动,抽取发生变动的数据,一般用于数据更新
数据转换(Transformation)
• 数据转换要经历数据清洗和转换两个阶段
-数据清洗主要是对出现的重复、二义性、不完整、违反业务或逻辑规则等问题的数据进行统一的处理
-数据转换主要是对数据进行标准化处理,进行字段、数据类型、数据定义的转换
• 结构化数据在转换过程中的逻辑较为简单,非/半结构化数据的转换会较为复杂
数据加载(Loading)
• 将最后处理完的数据导入到对应的目标源里
2.3 数据积存
操作数据层(ODS)
• 数据与原业务数据保持一致,可以增加字段用来进行数据管理
• 存储的历史数据是只读的,提供业务系统查询使用
• 业务系统对历史数据完成修改后,将update_type字段更新为UPDATE,追加回ODS中
在离线数仓中,业务数据定期通过ETL流程导入到ODS中,导入方式有全量、增量两种
-全量导入:数据第一次导入时,选择此种方式
-增量导入:数据非第一次导入,每次只需要导入新增、更改的数据,建议使用外连接&全覆盖方式
2.4 数据分析
数据明细层(DWD)
• 数据明细层对ODS层的数据进行清洗、标准化、维度退化(时间、分类、地域)
• 数据仍然满足3NF模型,为分析运算做准备
数据汇总层(DWS)
• 数据汇总层的数据对数据明细层的数据,按照分析主题进行计算汇总,存放便于分析的宽表
• 存储模型并非3NF,而是注重数据聚合,复杂查询、处理性能更优的数仓模型,如维度模型
数据应用层(ADS)
• 数据应用层也被称为数据集市
• 存储数据分析结果,为不同业务场景提供接口,减轻数据仓库的负担 -数据仓库擅长数据分析,直接开放业务查询接口,会加重其负担
3.1 基本概念
OLTP系统建模方法
• OLTP(在线事务处理)系统中,主要操作是随机读写
• 为了保证数据一致性、减少冗余,常使用关系模型
• 在关系模型中,使用三范式规则来减少冗余
OLAP(在线联机分析)
• OLAP系统,主要操作是复杂分析查询;关注数据整合,以及分析、处理性能
• OLAP根据数据存储的方式不同,又分为ROLAP、MOLAP、HOLAP
OLAP系统分类
OLAP系统分类
• ROLAP(Relation OLAP,关系型 OLAP):使用关系模型构建,存储系统一般为RDBMS
• MOLAP(Multidimensional OLAP,多维型 OLAP):预先聚合计算,使用多维数组的形式保存数据结果,加快查询分析时间
• HOLAP(Hybrid OLAP,混合架构的 OLAP):ROLAP 和 MOLAP 两者的集成;如低层是关系型的,高层是多维矩阵型的;查询效率高于ROLAP,低于MOLAP
3.2 ROLAP
ROLAP系统建模方法
• 典型的数据仓库建模方法有ER模型、维度模型、Data Value、Anchor
维度模型
• 维度模型中,表被分为维度表、事实表,维度是对事实的一种组织。
• 维度一般包含分类、时间、地域等
维度模型
• 维度模型分为星型模型、雪花模型、星座模型
• 维度模型建立后,方便对数据进行多维分析
星型模型
• 标准的星型模型,维度只有一层,分析性能最优
雪花模型
• 雪花模型具有多层维度,比较接近三范式设计,较为灵活
星座模型
• 星座模型基于多个事实表,事实表之间会共享一些维度表
• 是大型数据仓库中的常态,是业务增长的结果,与模型设计无关
什么是宽表模型?
• 宽表模型是维度模型的衍生,适合join性能不佳的数据仓库产品
• 宽表模型将维度冗余到事实表中,形成宽表,以此减少join操作
3.3 MOLAP
MOLAP系统建模方法
• MOLAP将数据进行预结算,并将聚合结果存储到CUBE模型中
• CUBE模型以多维数组的形式,物化到存储系统中,加快后续的查询
• 生成CUBE需要大量的时间、空间,维度预处理可能会导致数据膨胀
3.4 多维分析
OLAP多维分析
• OLAP主要操作是复杂查询,可以多表关联,使用COUNT、SUM、AVG等聚合函数
• OLAP对复杂查询操作做了直观的定义,包括钻取、切片、切块、旋转
Ø 钻取
• 对维度不同层次的分析,通过改变维度的层次来变换分析的粒度
• 钻取包括上卷(Roll-up)、下钻(Drill-down)
• 上卷(Roll-up),也称为向上钻取,指从低层次到高层次的切换
• 下钻(Drill-down),指从高层次到低层次的切换
Ø 切片(Slice)、切块(Dice)
• 选择某个维度进行分割称为切片
• 按照多维进行的切片称为切块
Ø 旋转(Pivot)
• 对维度方向的互换,类似于交换坐标轴上卷(Roll-up)
4.1 表的分类
维度建模中的表类型
• 事实表
• 维度表
• 事务事实表
• 周期快照事实表
• 累积快照事实表
事实表
• 一般是指一个现实存在的业务对象,比如用户,商品,商家,销售员等等
维度表
• 一般是指对应一些业务状态,代码的解释表。也可以称之为码表
• 通常使用维度对事实表中的数据进行统计、聚合运算
事务事实表
• 随着业务不断产生的数据,一旦产生不会再变化,如交易流水、操作日志、出库入库记录
周期快照事实表
• 随着业务周期型的推进而变化,完成间隔周期内的度量统计,如年、季度累计
• 使用周期+状态度量的组合,如年累计订单数,年是周期,订单总数是量度
累积快照事实表
• 记录不确定周期的度量统计,完全覆盖一个事实的生命周期,如订单状态表
• 通常有多个时间字段,用于记录生命周期中的关键时间点
• 只有一条记录,针对此记录不断更新
实现方式一
• 使用日期分区表,全量数据记录,每天的分区存储昨天全量数据与当天增量数据合并的结果
• 数据量大会导致全量表膨胀,存储大量永远不更新的冷数据,对性能影响较大
• 适用于数据量少的情况
实现方式二
• 使用日期分区表,推测数据最长生命周期,存储周期内数据;周期外的冷数据存储到归档表
• 需要保留多天的分区数据,存储消耗依然很大
实现方式三
• 使用日期分区表,以业务实体的结束时间分区,每天的分区存放当天结束的数据;设计一个时间非常大的分区,如9999-12-31,存放截止当前未结束的数据
• 已结束的数据存放到相应分区,存放未结束数据的分区,数据量也不会很大,ETL性能好
• 无存储浪费,数据全局唯一
• 业务系统可能无法标识业务实体的结束时间,可以使用其它相关业务系统的结束标志作为此业务系统的结束,也可以使用最长生命周期时间或前端系统的数据归档时间
拉链表
• 拉链表记录每条信息的生命周期,用于保留数据的所有历史(变更)状态
• 拉链表将表数据的随机修改方式,变为顺序追加
4.2 ETL策略
全量同步
• 数据初始化装载一定使用全量同步的方式
• 因为业务、技术原因,使用全量同步的方式做周期数据更新,直接覆盖原有数据即可
增量同步
• 传统数据整合方案中,大多采用merge方式(update+insert)
• 主流大数据平台不支持update操作,可采用全外连接+数据全量覆盖方式
-如果担心数据更新出错,可以采用分区方式,每天保存最新的全量版本,保留较短周期
4.3 任务调度
为什么需要任务调度?
• 解决任务单元间的依赖关系
• 自动化完成任务的定时执行
常见任务类型
• Shell
• Java程序
• Mapreduce程序
• SQL脚本
常见调度工具
• Azkaban
• Oozie
第四章:大数据名词科普
4.1数据集市
数据仓库也称为中央或企业数据仓库。因此,在某些情况下,数据仓库的来源将是多个,而数据集市是数据仓库的一个子集。
有两种类型的数据集市——独立型和从属型。独立型数据集市直接从操作型环境获取数据。从属型数据集市从企业级数据仓库获取数据。从长远的角度看,从属型数据集市在体系结构上比独立型数据集市更稳定。
4.2数据孤岛
数据孤岛(通常称为信息孤岛)是只有一组人可以轻松访问的数据集。这意味着其他人很难获得这些信息,或者更糟糕的是,他们根本无法访问它。
4.3数据湖
数据湖(Data Lake)是一个以原始格式存储数据的存储库或系统,它按原样存储数据,而无需事先对数据进行结构化处理。一个数据湖可以存储结构化数据(如关系型数据库中的表),半结构化数据(如CSV、日志、XML、JSON),非结构化数据(如电子邮件、文档、PDF)和二进制数据(如图形、音频、视频)。
数据湖是一个存储库,它允许存储大量的原始数据,也就是说,没有按照特定的模式进行准备、处理或操作的数据。
数据湖的一个关键特征是不会拒绝任何数据,这意味着结构化格式和非结构化数据格式都可以存储。由于数据湖中的数据在从源获取时不受数据结构的约束,因此在需要时应用“读取”模式来促进数据分析。
数据湖特征:
1. 容量大 2.格式多 3.处理速度快 4.体系结构
未来的发展趋势可能是湖仓一体。
4.4数据中台
各种信息系统大多是独立建设的,无法做到信息的互联互通,导致形成了多个数据孤岛。数据中台的作用是融合新老信息,整合各个孤岛上的信息,快速形成数据服务能力,为企业经营决策、精细化运营提供支持。
4.5宽表和窄表
宽表:从字面意义上讲就是字段比较多的数据库表。通常是指业务主题相关的指标、维度、属性关联在一起的一张数据库表。由于把不同的内容都放在同一张表存储,宽表已经不符合三范式的模型设计规范,随之带来的主要坏处就是数据的大量冗余,与之相对应的好处就是查询性能的提高与便捷。这种宽表的设计广泛应用于数据挖掘模型训练前的数据准备,通过把相关字段放在同一张表中,可以大大提高数据挖掘模型训练过程中迭代计算时的效率问题。
窄表:严格按照数据库设计三范式。尽量减少数据冗余,但是缺点是修改一个数据可能需要修改多张表。
4.6数据仓库元数据
元数据(Metadata),又称中介数据、中继数据,为描述数据的数据(data about data),主要是描述数据属性(property)的信息,用来支持如指示存储位置、历史数据、资源查找、文件记录等功能。
举几个简单例子:
如果一本书是一个“数据",那么它的书名、封面、出版社、作者、总页码就是它的“元数据”。
如果一个电影是一个“数据”,那么它的总时长、制作人、总导演、演员列表就是它的“元数据”。
如果数据库中某个表是一个”数据”,那么它的列名、列类型、列长度、表注释就是它的"元数据"。
4.7数据治理
数据治理(Data Governance)是组织中涉及数据使用的一整套管理行为。由企业数据治理部门发起并推行,关于如何制定和实施针对整个企业内部数据的商业应用和技术管理的一系列政策和流程。
数据的质量直接影响着数据的价值,并且直接影响着数据分析的结果以及我们以此做出的决策的质量。我们常说,用数据说话,用数据支撑决策管理,但低质量的数据、甚至存在错误的数据,必然会"说假话"!!! 数据治理即提高数据的质量,发挥数据资产价值。
4.8 ETL流程文章来源:https://www.toymoban.com/news/detail-411988.html
ETL是英文Extract-Transform-Load 的缩写,用来描述将数据从来源端经过抽取(extract)、转换(transform)、加载(load)至目的端的过程。常见于数据仓库开发中将数据由业务系统归集到数据仓库(DW)或者数据集市的过程。在ETL三个部分中,花费时间最长的是“T”(Transform,清洗、转换)的部分,一般情况下这部分工作量是整个ETL的2/3。文章来源地址https://www.toymoban.com/news/detail-411988.html
到了这里,关于数据仓库介绍(DW)的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!