数据仓库相关概念的解释

数据仓库相关概念的解释

1 ETL是什么？

​ ETL 是英文 Extract-Transform-Load 的缩写，用来描述将数据从源端经过抽取（extract）、转换（transform）、加载（load）至目的端的过程，它能够对各种分布的、异构的元数据（如关系数据）进行抽取，按照预先设计的规则将不完整数据、重复数据以及错误数据等“脏”数据内容进行清晰，得到符合要求的“干净”数据，并加载到数据仓库中进行存储，这些“干净”数据久成为了数据分析、数据挖掘的基石。

ETL 就是抽取、转换、加载这三个单词的缩写，所以顾名思义主要的工作就是把数据从那块儿抽过来，然后进行一个清洗、加工，最后再存到哪块儿。

抽取：这个环节可能主要是比如说Sqoop、Flume、Kafka、还有Kettle、Datax、Maxwell这些狗屎抽取工作。离线可能主要是用的Sqoop或者DataX去进行离线数据的抽取，像实时可能会采用比如说Flume或者是kafka、Maxwell，还有Kettle去进行抽取。

转换：转换包括清洗、合并、拆分、加工等等，可以用Hadoop生态的东西，MapReduce、Spark、Flink、Hive等进行数据方面的清洗。

加载：抽取转换之后，就是将数据加载到目标数据库。可能会用到Hbase去存储一些大数据方面的东西，或者HDFS等等这些工具。

**ETL是实现商务智能（Business Intelligence，BI）的核心** 。一般情况下，ETL 会花费整个BI项目三分之一的时间，因此ETL设计得好坏直接影响BI项目的成败。

​ 企业中常用的ETL实现有多种方式，常见的方式如下。

（1）借助ETL工具（如Pentaho Kettle、Infomatic 等）。

（2）编写SQL语句。

（3）将ETL工具和SQL语句结合起来使用。

上述3种实现方式各有利弊，其中第1种方式可以快速建立ETL工程，屏蔽复杂的编码任务、加快速度和降低难度，但是缺少灵活性：第二种方式使用编写SQL语句的方式优点是灵活，可以提高ETL的运行效率，但是编码复杂，对技术要求比较稿；第三种方式综合了前面两种方法的优点，可以极大地提高ETL的开发速度和效率。

ETL体系结构

ETL主要是用来实现异构数据源数据集成的。多种数据源的所有原始数据大部分未作修改就被载入ETL，因此，无论数据源再关系型数据库、非关系型数据库，还是在外部文件，集成后的数据都将被置于数据库的数据表或数据仓库的维度表中，以便在数据库内或数据仓库种做进一步转换（因此，一般会将最终的数据存储到数据库或者数据仓库中）。ETL的体系结构如图下所示。

如图，若数据源1和数据源2均为功能较强大的DBMS(数据库管理系统)，则可以使用SQL语句完成一部分数据清洗工作。但是，如果数据源为外部文件，就无法使用SQL语句进行数据清洗工作了，只能直接从数据源中抽取出来，然后在数据转换的时候进行数据清洗的工作。因此，数据仓库中的数据清洗工作主要还是在数据转换的时候进行。清洗好的数据将保存到目标数据库中，用于后续的数据分析、数据挖掘以及商业智能。

2 数据流向

何为数仓DW

Data warehouse(可简写为DW 或者 DWH) 数据仓库，是在数据库已经大量存在的情况下，它是一整套包括了 etl、调度、建模在内的完整的理论体系。

数据仓库的方案建设的目的，是为前端查询和分析作为基础，主要应用于 OLAP（on-line Analytical Processing），支持复杂的分析操作，侧重决策支持，并且提供只管移动的查询结果。目前行业比较流行的有：AWS Redshift，Greenplum，Hive等。

数据仓库并不是数据的最终目的地，而是为数据最终的目的地做好准备，这些准备包含：清洗、转义、分类、重组、合并、拆分、统计等

主要特点

面向主题

操作型数据库组织面向事务处理任务，而数据仓库中的数据是按照一定的主题域进行组织。

主题是指用户使用数据仓库进行决策时所关系的重点方面，一个主题通过与多个操作型信息系统相关。

集成

需要对元数据进行加工与融合，统一与综合

在加工的过程中必须消除源数据的不一致性，以保证数据仓库内的信息是关于整个企业的一致的全局信息。（关联关系）

不可修改

DW中的数据并不是最新的，而是来源于其他数据源

数据仓库主要是为决策分析提供数据，涉及的操作主要是数据的查询

与时间相关

处于决策的需要数据仓库中的数据都需要表明时间属性

与数据库对比

DW：专门为数据分析设计的，设计读取大量数据以了解数据之间的关系和趋势

数据库：用于捕获和存储数据

特性	数据仓库	事务数据库
适合的工作负载	分析、报告、大数据	事务处理
数据源	从多个来源手机和标准话的数据	从单个来源（例如事务系统）捕获的数据
数据捕获	批量写入操作通过按照预定的批处理计划执行	针对连续写入操作进行了优化，因为新数据能够最大程度地提供事务吞吐量
数据标准化	非标准化schema，例如星型schema或雪花行schema	高度标准化的静态schema
数据存储	使用列式存储进行了优化，可实现轻松访问和高速查询性能	针对在单行型物理块中执行高吞吐量写入操作进行了优化
数据访问	为最小化I/O并最大化数据吞吐量进行了优化	大量小型读取操作

3 ODS 是什么？

• ODS层最好理解，基本上就是数据从源表拉过来，进行etl，比如mysql 映射到hive，那么到了hive里面就是ods层。
• ODS 全称是 Operational Data Store，是、操作数据存储“面向主题的”，数据运营层，也叫ODS层，是最接近数据源中数据的一层，数据源中的数据，经过抽取、洗净、传输，即传说中的ETL之后，装入本层。本层的数据，总体上大多是按照源头业务系统的分类方式而分类的。但是，这一层面的数据却不等同于原始数据。在元数据装入这一层时，要进行诸如去噪（例如有一条数据中人的年龄是300岁，这种属于异常数据，就与要提前做一些处理）、去重（例如在个人资料表中，同一ID 却有两条重复数据，在接入的时候需要做进一步去重）、字段命名规范等一系列操作。

4 数据仓库层DW

数据仓库层（DW），是数据仓库的主题，在这里，从ODS 层中获得的数据按照主题 建立各种数据模型。这一层和维度建模会有比较深的联系。

细分：

1. 数据明细层：DWD（Data Warehouse Detail）
2. 数据中间层：DWM（Data Warehouse Middle）
3. 数据服务层：DWS（Data Warehouse Service）

DWD 明细层

明细层（ODS，Operational Data Store，DWD：data warehouse detail）

• 概念：是数据仓库的细节数据层，是对STAGE 层数据进行沉淀，减少了抽取的复杂性，同时ODS/DWD的信息模型组织主要遵循企业业务事务处理的形式，将各个专业数据进行集中，明细曾跟stage层的粒度一致，属于分析的公共资源
• 数据生产方式：部分数据直接来自kafka，部分数据为接口层数据与历史数据合成。
• 这个stage层不是很清晰

DWD 轻度汇总层（MID或DWB，data warehouse basis）

• 概念：轻度汇总层数据仓库中DWD 层和DM层之间的一个过渡层次，是对DWD层的生产数据进行轻度综合和汇总统计（可以把复杂的清晰，处理包含，如根据PV日志生成的会话数据）。轻度综合层与DWD的主要区别在于二者的应用领域不同，DWD的数据来源于生产型系统，并未满意一些不可预见的需求而进行沉淀；轻度综合层则面向分析型应用进行细粒度的统计和沉淀
• 数据生成方式：由明细层按照一定的业务需求生成轻度汇总表。明细层需要复杂清晰的数据和需要MR处理的数据也经过处理后接入到轻度汇总层。
• 日志存储方式：内表，parquet文件格式。
• 日志删除方式：长久存储。
• 表schema：一般按天创建分区，没有时间概念的按具体业务选择分区字段。
• 库与表命名。库名：dwd.表名：初步考虑格式为：dwd日期业务表名，待定。
• 旧数据更新方式：直接覆盖

DWS 主题层（DM，data market 或DWS，data warehouse service）

• 概念：又称数据集市或宽表。按照业务划分，如流量、订单、用户等，生成字段比较多的宽表，用于提供后续的业务查询，OLAP分析，数据分发等。
• 数据生成方式：由轻度汇总层和明细层数据计算生成。
• 日志存储方式：使用impala内表，parquet文件格式。
• 日志删除方式：长久存储。
• 表schema：一般按天创建分区，没有时间概念的按具体业务选择分区字段。
• 库与表命名。库名：dm.表名：初步考虑格式为：dm日期业务表名，待定。
• 旧数据更新方式：直接覆盖

5 数据产品层/应用层 APP

数据产品层（APP），这一层是提供为数据产品使用的结果数据。

主要是提供给数据产品和数据分析使用的数据，一般会存放在 ES、Mysql 等系统中供线上系统使用，也可能会存在 Hive 或者 Druid 中供数据分析和数据挖掘使用。

如我们经常说的报表数据，或者说那种打款表，一般就放在这里。

应用层（App）

• 概念：应用层是根据业务需要，由前面三层数据统计而出的结果，可以直接提供查询占星，或导入至MySql中使用。
• 数据生成方式：由明细层、轻度汇总层，数据集市层生成，一般要求数据主要来源于集市层。
• 日志存储方式：使用 impala 内表，parquet 文件格式。
• 日志删除方式：长久存储。
• 表schema：一般按天创建分区，没有事件概念的按具体业务选择分区字段。
• 库与表命名。库名：暂定 apl，另外根据业务不同，不限定一定要一个库。
• 旧数据更新方式：直接覆盖。

6 数据的来源

数据主要会有两个大的来源：

业务库，这里经常会使用 Sqoop 来抽取

在实时方面，可以考虑用 Canal 监听 Mysql 的 Binlog，实时接入即可。

埋点日志，线上系统会打入各种日志，这些日志一般以文件的形式保存，我们可以选择用 Flume 定时抽取，也可以用用 Spark Streaming 或者 Storm 来实时接入，当然，Kafka 也会是一个关键的角色。

还有使用 filebeat 收集日志，打到kafka ，然后处理日志

注意：在这层，理应不是简单的数据接入，而是要考虑一定的数据清洗，比如异常字段的处理、字段命名规范化、时间字段的统一等，一般这些很容易会被忽略，但是却至关重要。特别是后期我们做各种特征自动生成的时候，会十分有用。

7 ODS、DW -> App 层

这里也主要分两种类型：

1. 每日定时任务型：比如典型的日计算任务，每天凌晨算前一天的数据，早上起来看报表。这种任务经常使用 Hive、Spark 或者生撸 MR 程序来计算，最终结果写入 Hive、Hbase、Mysql、Es 或者 Redis 中。
2. 实时数据：这部分主要是各种实时的系统使用，比如我们的实时推荐、实时用户画像，一般我们会用 Spark Streaming、Storm 或者 Flink 来计算，最后会落入 Es、Hbase 或者 Redis 中。

8 维度表 DIM

维度表（Dimension）

为表层主要包含两部分数据：

• 高基数维度数据：一般是用户资料表、商品资料表类似的资料表。数据量可能是千万级或者上亿级别。
• 低基数维度数据：一般是配置表，比如枚举值对应的中文含义，或者日期维表。数据量可能是个位数或者几千万。