赞
踩
* 历史数据积存
* 企业数据分析需要
* 历史数据使用频率低,堆积在业务库中,导致性能下降
* 各个部门自己建立独立的数据抽取系统,导致数据不一致
* 由数据仓库之父比尔·恩门(Bill Inmon)提出
* 数据仓库是一个面向主题的,集成的,非易失的且随时间变化的数据集合
* 主要用于组织积累的历史数据,并使用分析方法(OLAP,数据分析)进行分析整理,进而辅助决策,为管理者,企业系统提供数据支持,构建商业智能
* 面向主题:为数据分析提供服务,根据主题将原始数据集合在一起
* 集成:原始数据来源于不同数据源,要整合成最终数据,需要经过抽取,清洗,转换的过程
* 非易失:保存的数据是一系列历史快照,不允许呗修改,只允许通过工具进行查询,分析
* 时变性:数据仓库会定期接受,集成新的数据,从而反映出数据的最新变化
* 数据库面向事物设计,属于OLTP(在线事物处理),主要操作是随机读写;在设计时尽量避免冗余,采用符合范式规范来设计
* 数据仓库是面向主题设计的,属于OLAP(在线分析处理)系统,主要操作是批量读写;关注数据整合,以及分析,处理性能;会有意引入冗余,采用反范式方式设计
数据库 | 数据仓库 | |
面向 | 事务 | 分析 |
数据类型 | 细节,业务 | 综合,清洗过的数据 |
数据特点 | 当前的,最新的 | 历史的,跨时间维护 |
目的 | 日常操作 | 长期信息需求,决策支持 |
设计模式 | 基于ER模型,面向应用 | 星型/雪花模型,面向主题 |
操作 | 读/写 | 大多为读 |
数据规模 | GB/TB | >= TB |
1. 传统数据仓库:由关系型数据组成MPP(大规模并行处理);缺点是:扩展性有限,热点问题
2. 大数据数据仓库:优势:扩展性,避免热点问题;缺点是:SQL支持率(已经不算问题了),事物支持
* 利用大数据天然的扩展性,完成海量数据的存放
* 将SQL转化为大数据计算引擎的任务,完成数据分析
* 传统数仓中常见的技术架构,将单机数据库节点组成集群,提升整体处理性能
* 节点间为非共享架构(Share Nothing),每个节点都有独立的磁盘存储系统和内存系统
* 每个数据节点通过专用网络或者商业通用网络互相连接,彼此协同计算,作为整体提供服务
* 设计上优先考虑C(一致性),其次考虑A(可用性),尽量做好P(分区容错性)
优点: 运算方式精细,延迟低,吞吐低
适合中等规模的结构化数据处理
缺点: 存储位置不透明,通过Hash确定数据所在的物理节点,查询任务在所有节点均会执行
并行计算时,单节点瓶颈会成为整个系统短板,容错性差
分布式事物的实现导致扩展性降低
* 大数据常见的技术架构,也成为Hadoop架构/批处理架构
* 各阶段实现场地自治(可以单独运行局部应用),数据在集群中全局透明共享
* 每台节点通过局域网或广域网相连,节点间的通信开销比较大,在运算时致力减少数据移动
* 优先考虑的是P(分区容错性),然后是A(可用性), 最后再考虑C(一致性)
* 数据存储采用分布式架构中的公共存储,提高分区容错性
* 上层架构采用MPP,减少运算延迟
5.1 传统数据仓库:Oracle RAC,DB2,Teradata,Greenplum
5.2 大数据数据仓库:Hive, Spark SQL,HBase, Impala, HAWQ, TIDB
* 将数据从来源端经过抽取(extract),交互转换(transform),加载(load)至目的端的过程
* 构建数据仓库的重要一环,用户从数据源抽取所需的数据,经过数据清洗,最终按照预先定义好的数据仓库模型,将数据加载到数据仓库中去
* ETL规则的设计和实施约占整个数据仓库搭建工作量的60%~ 80%
6.2.1 数据抽取(extract)
* 抽取的数据源可以分为结构化数据,非结构化数据,半结构化数据
* 结构化数据一般采用JDBC,数据库日志方式,半结构化数据会监听文件变动
抽取方式:
* 数抽取方式有全量同步,增量同步两种方式
* 全量同步会将全部数据进行抽取,一般用于初始化数据装载
* 增量同步方式会检测数据的变动,抽取发生变动的数据,一般用于数据更新
6.2.2 数据转换(transform)
* 数据转换要经历数据清洗和转换的两个阶段:
-- 数据清洗主要对出现的重复,多义,不完整,违反业务或逻辑规则等问题的数据进行统一的处理
-- 数据转换主要对数据进行标准化处理,进行字段,数据类型,数据定义的转换
* 结构化数据在转换过程中的逻辑比较简单,非结构和半结构化数据的转换比较复杂
6.2.3 数据加载(Loading)
* 将最后处理完的数据导入到对应的目标源中
* 数据与原业务数据保持一致,可以增加字段来进行数据管理
* 存储的历史数据是只可读的,提供业务系统查询使用
* 业务系统对历史数据完成修改后,将update_type字段更新为update,追加到ODS中
* 在离线数仓中,业务数据 定期通过ETL流程导入到ODS中,导入方式有全量、增量两种方式
-- 首次导入:全量
-- 增量导入:非首次导入,每次只导入新增,修改的数据,建议使用外链接&全覆盖的方式
6.4.1 数据明细层(DWD)
* 数据明细层对ODS层的数据进行清洗,标准化,维度退化(时间,分类,地域)
* 数据仍然满足3NF模型,为分析运算做准备
6.4.2 数据汇总层(DWS)
* 数据汇总层的数据对数据明细层的数据按照分析主题进行计算汇总,存放便于分析的宽表
* 存储模型并非3NF,而是注重数据聚,复杂查询,处理性能更优的数仓模型,如维度模型
6.4.3 数据应用层(ADS)
* 数据应用层也被成为数据集市
* 存储数据分析结果,为不同业务场景提供接口,减轻数据仓库的负担
-- 数据仓库擅长数据分析,直接开发业务查询接口,会加重其负担
7.1.1 OLTP系统建模方法
* OLTP(在线事务处理)系统中,主要操作是随机读写
* 为保证数据一致性,减少冗余,常使用关系模型
* 在关系模型中,使用三范式规则来减少冗余
7.1.2 OLAP(在线联机分析)
* 主要作用是复杂分析查询,关注数据整合,以及分析,处理性能
* OLAP根据数据存储的方式不同,又分为ROLAP,MOLAP,HOLAP
7.1.3 OLAP系统分类
* ROLAP(Relation OLAP,关系型OLAP):使用关系模型构建,存储系统一般为RDBMS
* MOLAP(Multidimensional OLAP,多维型OLAP):预先聚合计算,使用多维数据的形式保存数据结果,加快查询分析时间
* HOLAP(Hybrid OLAP,混合架构的OLAP):ROLAP和MOLAP两者的集成;如底层是关系型的,高层是多维矩阵型的;查询效率高于ROLAP, 低于MOLAP
* 典型的数据仓库建模方法有ER模型,维度模型,Data Value,Anchor
-- ER模型:出发点是整合数据,为数据分析决策服务。需要全面的了解业务和数据。实施周期长。最建模人员能力要求高
-- 维度建模:为分析需求服务,更快的完成需求分析。具有较好大规模复杂查询相应性能。最流行的数仓建模模型,最经典
-- Data Value和 Anchor 略
7.2.1 维度模型
* 维度模型中,表被分为维度表,事实表,维度是对事实的一种组织
* 维度一般包含分类,时间,地域等
* 维度模型分为星型模型(维度只有一层,分析性能最好),雪花模型(多层维度,比较灵活),星座模型(公用维度表,大型数据仓库的常态,与模型设计无关)
-- 宽表模型:是维度建模的衍生,适合join性能不佳的数据仓库产品
-- 宽表模型:将维度冗余到事实表中,形成宽表,以此减少join操作
* 维度模型建立后,方便对数据进行多维分析
* 将数据进行与计算结果,并将聚合结果存储到CUBE模型中
* CUBE模型以多维数组的形式,物化到存储系统中,加快后续的查询
* 生成CUBE需要大量的时间,空间,维度处理可能会导致数据膨胀
* OLAP主要操作是复杂查询,可以多表关联,使用Count,Sum,Avg等聚合函数
* OLAP对复杂查询操作做了直观的定义,包括钻取,切片,切块,旋转
7.4.1 钻取
* 对维度不同层次的分析,通过改变维度的层次来变换分析的粒度
* 钻取包括上卷(Roll-up)、下钻(Drill-down)
* 上卷(Roll-up):维度从低层次到高层次的切换,如:组-->村->镇->县->市->省->国
* 下钻(Drill-down):与上卷相反
7.4.2 切片(Slice)、切块(Dice)、旋转(Pivot)
* 选择某个维度进行分割成为切片
* 按照多维进行的切片成为切块
* 对维度方向的互换
* 事实表:指一个现实存在的业务对象,比如用户,商品,商家, 销售员等等
* 维度表:对应一些业务状态,代码的解释,可以对事实表中的数据进行统计,聚合运算
* 事务事实表:业务产生的数据,一旦产生不会在变化,如交易流水,操作日志,出库入库记录
* 周期快照事实表:随着业务周期性的推进而变化,完成间隔周期内的度量统计,如年,季度累计
使用周期+状态度量的组合,如年累计订单数,年是周期,订单总数据是量度
* 累积快照事实表:记录不确定周期的度量统计,完全覆盖一个事实的生命周期,如订单状态表
通常有多个时间字段,用于记录生命周期中的关键时间点
只有一条记录,针对此记录不断更新
* 拉链表:拉链表记录每条信息的生命周期,用于保留数据的所有历史(变更)状态
拉链表将数据的随机修改方式,变为顺序追加
8.1.1 累积快照事实表的实现方式
实现方式一:
* 使用日期分区表,全量数据记录,每天的分区存储昨天全量数据与当天增量数据合并的结果
* 数据量大会导致全量表膨胀,存储大量永远不更新的冷数据,对性能影响较大
* 适用于数据量少的情况
实现方式二:
* 使用日期分区表,推测数据最长生命周期,存储周期内数据;周期外的冷数据存储到归档表
* 需要保留多天的分区数据,存储消耗依然很大
实现方式三:
* 使用日期分区表,以业务实体的结束时间分区,每天的分区存放当天结束的数据;设计一个时间非常大的分区,如9999-12-31,存放截止当前未结束的数据
* 已结束的数据存放到相应分区,存放未结束数据的分区,数据量也不会很大,ETL性能好
* 无存储浪费,数据全局唯一
* 业务系统可能无法标识业务实体的结束时间,可以使用其他相关业务系统的结束标志作为此业务系统的结束,也可以使用最长生命周期时间或全段系统的数据归档 时间
8.2.1 全量同步
* 数据初始化装载一定是全量同步的方式
* 因为业务,技术原因,使用全量同步的方式做周期数据更新,直接覆盖原有数据即可
8.2.1 增量同步
* 传统数据整合方案中,大多数采用merge方式(update + insert)
* 主流大数据平台不支持update操作,可采用全外连接+数据全量覆盖方式
--如果担心数据更新出错,可以采用分区方式,每天保存最新的全量版本,保留较短周期
* 解决任务单元间的依赖关系
* 自动化完成任务的定时执行
* 常见的任务类型:Shell, Java程序, MapReduce程序,SQL脚本
* 常见的调度工具:Azkaban,Oozie
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。