数据仓库学习系列-大数据数仓综述

目录

• 背景
• 第一部分 数据仓库缘起
• 第二部分 数据仓库概述
• 第三部分 数据仓库技术实现
• 第四部分 常见数据仓库产品
• 第五部分 数据仓库的架构设计
• 第六部分 建模方法
• 第七部分 最佳实践
• 参考文献及资料

背景

第一部分 数据仓库缘起

1.1 历史数据的积存

历史数据使用频率低，堆积在业务库中，导致性能降低。将冷数据迁移至数据仓库。

1.2 企业数据分析需要

历史积存，开展数据分析工作，作为经营管理的决策分析。

各个业务线分别建立数据抽取和数据仓库。管理和维护成本较大。需要统一建设企业级别数据仓库。

统一的数据口径。

第二部分 数据仓库概述

数据仓库是一个面向主题、集成的、非易失的且随时间变化

2.1 数据仓库的特点

2.1 面向主题

为数据分析提供服务。根据主题将元素数据集合在一起。

2.2 集成

原始数据来源不同的数据源，需要整合。经过抽取、清洗、转换（ETL）过程。

数据治理

2.3 非易失

保存在数据仓库中数据原则上不允许修改，只允许通过工具进行查询和分析。

2.4 时变性

数据仓库会定期接受集成新的数据，反应数据的最新变化。

2.2 数据仓库VS数据库

数据库是面向事物设计的，属于OLTP（在线事物处理）系统。主要是随机读写，设计避免冗余，设计需要符合范式（数据库3范式）。

数据仓库是面向主题设计，属于OLAP（在线分析处理）系统。主要是批量读写。关注数据的整合，以及分析处理性能。会有意的引入数据冗余，反范式设计。以空间换取时间，提升数据获取的效率。

特征	数据库	数据仓库
面向	事物	数据分析
数据类型	细节、业务	ETL处理后的数据
数据特点	当前的、最新的	历史的、跨时间
目的	日常操作	长期信息需求、决策支持
设计模型	基于ER模型、面向应用	星形、雪花模型、面向主题
操作	读/写	读为主、批量写
数据规模	GB、TB	PB

注： 设计实体关系模型（ER Model）

第三部分 数据仓库技术实现

3.1 传统数仓技术实现

由关系型数据库组成的MPP（大规模并行处理）集群。

业务库是关系型数据库，多个关系型数据库，组成集群。

数据分布在各个节点存储，分库分表。兼容SQL语法。

存在的问题：扩展性有限（分库分表的限制）、热点问题。

3.2 MPP架构

将单机数据节点组成集群，提升整体处理性能。

非共享架构，每个节点是独立的资源、独立运行。

每个节点使用专用网络相互连接，彼此协同计算，作为整体提供服务。

设计上优先考虑C（一致性）、其次考虑A（可用性）、尽量做好P（分区容错性）。CAP理论。

架构优点

运算精细化 延迟低 吞吐低

架构适用于中等规模的数据仓库数据处理。

架构缺点

存储位置不透明。使用hash分布。查询任务会在每个节点执行。

并行计算是，单节点有瓶颈。容错性差（随着集群规模的增加，故障率。世界上也没超大规模的MPP数据库）。

分布式事务的实现会导致扩展性降低。

3.2 大数据数仓技术实现

依托大数据技术产生数据仓库。完成海量数据的存储（分布式文件系统）。

移动计算，而不是移动数据。

将SQL转换成大数据计算引擎任务，完成数据分析。

缺点：SQL支持率。事务支持（对事物要求不高）。

3.2.1 分布式架构

大数据中常见架构。Hadoop架构。

各节点实现场地自治。可以单独运行局部应用。数据在集群中全局透明共享。

每个节点通过局域网，廉价网络，节点间数据通信开销较大。需要在运算过程中减少数据的移动，即计算去贴近数据。

在CAP理论中，优先考虑P（分区容错性）、然后是A（可用性）、最后考虑C（一致性）。

数据处理较为粗狂，将数据作为文件对待。对于小数据场景下，处理效率低。

3.3 MPP+分布式的架构

数据存储在分布式架构中的公共存储，提高分区容错性。

上层架构采用MPP，减少运算的延迟。

两者之间的折中。计算架构没有好坏之分，只有场景适合。

第四部分 常见数据仓库产品

4.1 传统数仓

• Oracle RAC

oracle的集群版本。共享磁盘存储。单个集群只能支持100个节点。

• DB2

IBM的场景。

• Teradata

商业数据库。性能和易用高。和硬件一起卖。稳定易用。

• Greenplum

开源产品。基于Postgre SQL改造。技术更新快。稳定性比TD弱一些。

4.2 大数据数仓

• Hive

  Hadoop的生态。HQL语法SQL。延迟大。底层是MapReduce计算引擎。

• Spark SQL

  底层计算基于Spark

• Hbase

  nosql。存储非结构化数据。高并发读。实时流处理、前端高并发的业务查询。DDL频发变化的业务。

• Impala

  数据查询引擎。底层兼容hive hbase。快速交互查询服务。数据仓库的查询接口。

• HAWQ

  Greenplum在hadoop上的移植产品。分布式批处理架构+MPP架构。兼容两者的性能。

• Tidb

  new sql数据库。架构是MPP+SMP。底层是nosql存储，但是支持nosql语法。主要兼容的是mysql。同时可用用来作为OLTP和OLAP，但是更侧重于OLTP。

第五部分 数据仓库的架构设计

5.1 架构图

• 数据应用层、ADS层（报表决策、并发查询、搜索检索）

  数据集市层。

• 公共维护模型层、CDM层(数据汇总层 DWS、数据明细层DWD)

  明细层存储大量零散表、清洗了，还满足3范式。数据汇总层按照主题进行聚合，宽表进行存储。

• 操作数据源层（ODS层） 贴源数据

  数据积存。

• ETL（Sqoop、Kettle等）

  数据的接入。

5.2 ETL流程

ETL（Extract Transform Load）

将数据通过抽取、交互转换、加载至目的端的过程。

ETL规则的设计和实施占用数据仓库工作量的60%-80%。

数据抽取（Extract ）

抽取的数据：结构化数据、非结构化数据、半结构化数据

结构化数据通常使用JDBC方式、数据库日志方式获取，例如CDC；非|半结构化数据通过监听文件变动获取等。

抽取方式

1、数据抽取方式有全量同步、增量同步两种方式

2、全量同步会将全部数据进行抽取，一般用于初始化数据装载。

3、检测变动，抽取发生变化的数据，一般用于数据更新。

数据的转换（Transform ）

数据转换需要经历数据清洗和数据转换两个阶段。

数据清洗解决的问题：数据的重复去重、二义性、不完整、违反业务或者逻辑规则。

数据转换解决的问题：数据标准化处理、进行字段、数据类型、数据定义的转换。

数据加载（Load）

将最后处理完的数据导入到对应的目标源中。

常见ETL工具

结构化：

• Sqoop

  结构数据，jdbc方式，mapreduce计算框架；

• Kettle

  可视化界面。开源免费。

• Datastage

  商业。

• Informatica

  商业。

• Kafka

  消息队列。可以进行ETL处理。

非|半结构化数据

• Flume

  老牌。

• Logstash

  ELK家族。

5.3 ODS层

数据积存层。数据和业务数据库保持一致。

存储的数据只读。业务库的扩充集合。

业务系统对数据完成修改后，只能追加。

id	name	age
0001	test1	23
0002	test	25

入库后：

id	name	age	update_time	from	update_type
0001	test1	23	2022-02-01	DB01	insert
0002	test	25	2022-02-01	DB01	update

离线数仓中，业务数据定期通过ETL流程导入至ODS层。有全量和增量两种方式。

全量：数据第一次导入

增量：非第一次，根据业务库的变化，导入变化的数据。使用外连接的方式来更新（建议）、或者覆盖，避免冗余。

5.4 数据分析

5.4.1 DWD 数据明细层

DWD层对ODS层的数据进行清洗、标准化、维度退化（时间、分类、地域等）

数据仍然满足3NF范式，为分析计算做准备。轻度汇总。

注：维度是我们对数据的组织方式。

5.4.2 DWS 数据汇总层

数据汇总层对数据明细层的数据，按照分析主题进行计算汇总，存放便于分析的宽表。

存储模型非3NF范式。而是注重数据的聚合，复杂查询、处理性能更优的数仓模型，如维度模型。

数据仓库的核心 面向主题

5.4.3 ADS 数据应用层

数据应用层也称为 数据集市

为不同业务场景提供接口。根据不同的场景来存储。

例如报表：存储在Kylin层、并发查询存储在HBase、搜索检索 存储在Elasticsearch

第六部分 建模方法

6.1 基本概念

OLTP系统建模方法

在线事务处理系统。主要操作是随机读写。

为了保证数据一致性、减少冗余、使用关系模型

关系模型中 使用3NF规则减少冗余。

注：其实现在为了保证前端查询速度，会把表做成宽表，减少join操作。

OLAP

在线联机分析。主要复杂分析查询。关注数据整合，以及分析、处理性能。

安装存储方式的不同分为：ROLAP、MOLAP、HOLAP

6.2 ROLAP

ROLAP（Relation OLAP） 关系型OLAP。使用关系模型构建，存储系统一般为RDBMS。

经典的数据仓库建模方法有：ER模型、维度模型、data value、Anchor

用的最多的是维度模型。

业务变化多、灵活 维度模型。

维度模型中 表被分为：维度表、事实表。维度是对事实的一种组织。

维度包括：分类、时间、地域等。

维度模型分为：星形模型、雪花模型、星座模型

星形模型：维度只有一层 分析性能最优

雪花模型有多层维度 比较接近三范式 较为灵活。

星座模型：基于多个事实表 事实表之间共享一些维度表。是大型数仓中的常态，是业务增长的结果与模型设计无关。

什么是宽表模型

宽表模型是维度模型的衍生。适合join性能不佳的数据仓库产品。

宽表模型将维度冗余到事实表中，形成宽表，以减少join的操作。

传统数据库中join由于有索引，性能还可以。但是对于大数据数仓，数据大量移动会有大量数据搬运。

面向DWS数据汇总层。

6.3 MOLAP

MOLAP（多维 OLAP）；预先聚合计算。使用多维数组的形式保存。加快查询分析。预计算。

将结果进行预计算，并将聚合结果存储在CUBE模型中。空间换时间。

CUBE模型以多维数组的形式，物化在存储系统中，加快后续的查询。

生产CUBE需要大量的时间、空间，维度预处理可能会导致数据膨胀。

CUBE 数据立方体；

常见的产品：

Kylin 使用较多。存储在HBase。

Druid

适用于ADS层。

6.4 多维分析

HOLAP（混合 OLAP）；底层是关系层、高维多维矩阵型。

OLAP主要操作是复杂查询，多表关联、COUNT、SUM、AVG等聚合函数。

钻取

通过更改维度的层次来变换分析的粒度。

切片

切块

旋转

第七部分 最佳实践

7.1 表的分类

维度建模中，表：

事实表

存储一个现实存在的业务对象。

事务事实表

随着业务不断产生的数据，一旦产生就不会再变化。例如交易流水、操作日志、出库记录。

周期快照表

随着业务周期性的推进而变化。完成间隔周期内度量的统计。

累积快照表

记录不确定周期的度量统计。只有一条记录，针对此记录不断更新。

维度表

对业务状态 代码的解释表。也称为码表。

通常使用维度对事实表中的数据进行统计、聚合运算。

技术实现：

拉链表：

拉链表记录每条信息的生命周期，用于保留数据的所有历史变更状态；

拉链表将表数据的随机修改方式变为顺序追加。

7.3 ETL同步策略

全量同步

数据初始装载；

因为业务、技术原因 直接全量覆盖原有表数据。

增量同步：

传统数据整合方案中，大多采用merge方式（update+insert）

主流的大数据平台不支持update操作。可以采用全外连接+数据覆盖的方式

也可以按天分区，全量保存，控制数据生命周期。

7.4 任务调度

解决任务单元间的依赖关系。

自动化完成任务的定时执行。

常见任务：Shell、Java程序、MapReduce、SQL脚本;

任务调度工具：

Azkaban（阿兹卡班）

新

Oozie（乌贼）

老牌

7.5 SQL查询引擎

Presto

参考文献及资料

1、数据治理对运维数据体系的思考与启发，链接：http://blog.itpub.net/69994525/viewspace-2762789/