当前位置:   article > 正文

数据仓库相关概念的解释_数仓明细层

数仓明细层

数据仓库相关概念的解释

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项目的成败。
  • 1

​ 企业中常用的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)

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

  • 高基数维度数据:一般是用户资料表、商品资料表类似的资料表。数据量可能是千万级或者上亿级别。
  • 低基数维度数据:一般是配置表,比如枚举值对应的中文含义,或者日期维表。数据量可能是个位数或者几千万。
声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/小蓝xlanll/article/detail/474677
推荐阅读
相关标签
  

闽ICP备14008679号