数据仓库-通用数据仓库分层方法

0x00概述

数据分层是数据仓库设计中非常重要的一部分. 出色的分层设计可以使整个数据系统更易于理解和使用. 当前，大多数可以在Internet上检索到的相关文章都只提到数据分层的设计，或者缺少清晰详细的说明，或者缺少可实施的解决方案，或者缺少特定的示例.

因此，本文将指出一种通用的数据仓库分层方法，具体包括以下内容:

介绍数据分层的作用

提出通用数据分层设计和分层设计原理

举一些具体的例子来说明

提出可以实施的实用意见

0x01数据分层？

“为什么要设计数据分层？”

这应该是设计数据分层时必须挑战数据仓库学生的第一个问题. 可能会有许多类似的问题，例如“为什么要建立数据仓库？”和“为什么要进行元数据管理？” ，“为什么要进行数据质量管理？”. 当然，这里我们仅讨论为什么我们需要设计数据分层.

作为数据计划者，我们绝对希望我们的数据可以有序地流动，并且设计人员和用户可以清楚地看到数据的整个生命周期. 从直觉上讲，它与下面的左图和直观的依存关系一样清晰.

但是，在大多数情况下，我们完整的数据系统依赖于复杂而混乱的级别. 如下右图所示，我们可能不知不觉地创建了一组表依赖结构混乱数据仓库，甚至是循环依赖数据系统.

因此，我们需要一套有效的数据组织和管理方法，以使我们的数据系统更加有序. 这是提到的数据分层. 数据分层不能解决所有数据问题，但是数据分层可以为我们带来以下好处:

清晰的数据结构: 每个数据层都有其范围和职责，使用表时可以更轻松地定位和理解

减少重复开发: 标准化数据分层并开发一些常见的中间层数据，可以减少大量的重复计算

统一数据口径: 通过数据分层提供统一数据导出，并为外部输出提供统一数据口径

简化复杂问题: 将复杂任务分解为多个步骤来完成，每一层解决一个特定问题

0x02通用数据分层设计

为了满足上述数据分层的好处，我们将数据模型分为三层: 数据操作层（ODS），数据仓库层（DW）和数据应用程序层（APP）. 如下所示. 简单地说，我们可以将其理解为: ** ODS层存储要访问的原始数据，DW层存储我们要设计的数据仓库的中间层数据，而APP是面向业务的应用程序数据. **下面将详细介绍这三层的设计.

1. 数据操作层: ODS（操作数据存储）

“面向主题”的数据操作层，也称为ODS层，是最接近数据源中数据的层. 提取，清理和传输数据源中的数据，也就是说，在传奇的ETL之后，加载该层. 通常根据源业务系统的分类对这一层的数据进行分类.

通常来说，为了考虑可能需要跟踪的后续数据问题，建议不要为此层做过多的数据清理工作，这样就可以完整访问原始数据. 至于数据的去噪和删除，则可以在DWD背面进行处理，例如繁重和离群的处理.

二，数据仓库层: DW（数据仓库）

当我们进行数据仓库时，数据仓库层是核心设计层. 在这里，从ODS层获得的数据将根据主题构建各种数据模型. DW层分为DWD（数据仓库详细信息）层，DWM（数据仓库中间）层和DWS（数据仓库服务）层.

1. 数据详细信息层: DWD（数据仓库详细信息）

此层通常保持与ODS层相同的数据粒度，并提供一定的数据质量保证. 同时，为了提高数据细节层的易用性，该层将采用一些维数退化技术将维数退化为事实表，并减少事实表与维表之间的关联.

此外，部分数据聚合也将在此层进行，并且将同一主题的数据收集到一个表中，以提高数据的可用性. 示例将在后面给出.

2. 数据仓库中间: DWM（数据仓库中间）

此层将基于DWD层中的数据对数据执行光聚合操作，生成一系列中间表，提高公共指标的可重用性，并减少重复处理.

从直觉上讲，它是对共同的核心维度执行汇总运算以计算相应的统计指标.

3. 数据服务层: DWS（数据仓库服务）

也称为数据集市或宽表. 根据业务量，例如流量，订单，用户等，将生成一个包含更多字段的宽表，以提供后续业务查询，OLAP分析，数据分发等.

通常来说，此级别的数据表相对较少，并且一个表将覆盖更多的业务内容. 由于具有许多字段，因此该级别的表通常称为宽表.

在实际计算中，如果直接从DWD或ODS计算宽表的统计指标，则将有太多的计算和太少的尺寸. 因此，一般的方法是在DWM层中计算多个小表. 然后将中间表拼接成DWS宽表. 由于宽和窄之间的边界很难定义，因此您也可以删除DWM层而仅保留DWS层，或将所有数据放置在DWS中.

三，数据应用层: APP（应用程序）

此处，数据主要用于数据产品和数据分析. 通常，它将存储在ES，PostgreSql，Redis和其他用于系统的系统中. 它也可以存储在Hive或Druid中，以进行数据分析以及数据挖掘和使用. 例如，我们经常谈论的报告数据通常放在此处.

四个尺寸表面（尺寸）

最后，添加一个尺寸表层，它主要包含两部分数据:

高基数维度数据: 通常类似于用户数据表和产品数据表的数据表. 数据量可能是数千万或数亿.

低基数维度数据: 通常，它是一个配置表（例如枚举值的中文含义）或日期维度表. 数据量可以是个位数或数万.

到目前为止，我们已经结束了数据分层设计中每一层的含义. 这是一个易于理解的摘要，如下图所示.

0x03给我一个栗子

趁热打铁，给个栗子讲解，下图可以看作是一个电子商务网站的数据系统设计. 目前，我们仅关注用户访问日志数据的这一部分.

在ODS层中，由于两端的开发团队不同或其他各种问题，用户的访问日志被分为几个表并报告给我们的ODS层.

为了大家的方便，我们在DWD层制作了一个用户访问行为日表. 在这里，我们将PC网页，H5，applet和本机APP访问日志收集到一个表中，并使用统一的字段名，以提高数据质量，从而使每个人都可以轻松使用该列表.

在DWM层，我们将从DWD层中选择业务重点的核心维度以进行聚合操作，例如仅保留人员，产品，设备和页面区域的维度. 同样，我们做了很多DWM中间表

在DWS层，我们将整个网站中某人的行为数据放入表中. 这是我们的桌子. 使用此表，我们可以快速满足大多数常规业务需求.

最后，在APP应用程序层，从DWS层中的一个或多个表中取出数据，并根据需要将其拼接到一个应用程序表中.

备注: 该示例只是为了简单说明每一层的作用，而不是最合理的解决方案，您可以辩证地看待它.

0x04技术实践

既然我们讨论了数据分层，那么将在不同的层中使用什么计算引擎和存储系统，本节将简要分享.

数据层的存储通常如下:

数据源: 数据源通常是业务和掩埋点，当然，会有各种数据源，例如第三方购买数据. 业务的存储通常是Mysql和PostgreSql.

ODS层: ODS中的数据量通常非常大，因此大多数公司会选择将其存储在HDFS上，即Hive或Hbase，而Hive大多.

DW层: 通常与ODS存储相同数据仓库，但为了满足更多需求，它也将存储在PG和ES中.

APP层: 应用层的数据通常需要相对较快的响应速度，因此通常存储在Mysql，PG和Redis中.

对于计算引擎，您可以简单地参考图中的列表. 当前，与大数据相关的技术更新和迭代相对较快，本节中的列表仅供参考.

0x05思考

就像“讨论数据仓库和范式”一文最后讨论了数据仓库和范式之间的关系一样，本文还将考虑并总结数据分层的原理是什么？为什么要分层？每层之间的边界是什么？

我个人从这些角度理解数据层的划分:

从应用程序支持的角度来看，我们希望级别越高，对应用程序越友好. 例如，APP层基本上是为应用程序设计的，并且易于理解. 相对而言，对于DWS层，对成本有一点了解，然后DWM和DWD层更难理解，因为可以对其尺寸进行比较. 更多，并且一项需求可能需要多个表来完成复杂的计算.

在容量方面，我们希望20％的表能够支持80％的需求. 直接来说，DWS表可以支持大多数需求（超过80％）. 如果DWS无法支持，请使用DWM和DWD表来支持它们. 需要从原始日志的Taken中获取很少支持的数据. 结合第一点是: 80％的需求，我们都希望以非常友好的方式支持应用程序，而不是直接暴露给应用程序端的原始日志.

就数据聚合程度而言，我们希望数据聚合程度越高，聚合程度就越高. 只要看上面的例子. ODS和DWD的数据基本上是原始日志的粒度. 没有聚合操作完成. DWM会执行光聚合操作仅保留总体尺寸，而DWS会执行更高的聚合操作，并且可能仅保留一两个可以表征当前描述主题的尺寸. 从这个角度，我们还可以理解，我们根据数据聚合的程度划分了数据层次结构.

0xFF摘要

数据分层的设计也需要在某种程度上通过数据命名来体现. 本文的核心是解释数据分层的思想和方法. 会有单独的文章分享如何根据数据分层数据. 设计数据表的命名约定.

本文来自电脑杂谈，转载请注明本文网址：
https://www.pc-fly.com/a/jisuanjixue/article-288148-1.html