大数据架构之关系型数据仓库——解读大数据架构（二）

文章目录

前言

本文对关系型数据仓库（RDW）进行了简要的介绍说明，包括什么是关系型数据仓库，以及为什么要使用关系型数据仓库，其优缺点有哪些，如何增量更新数据等，最后还讨论了关系型数据仓库是否会消失的问题，以及哪些人会继续使用关系型数据仓库。

什么是关系型数仓

关系型数仓（RDW 是集中存储和管理从多个数据源复制的大量结构化数据的地方，用于历史和趋势分析报表，以便公司可以做出更好的业务决策。之所以称为关系型，是因为它基于关系模型，这是一种广泛使用的数据库数据表示和组织方法。在关系模型中，数据被组织成表（也称为关系）。这些表由行和列组成，其中每行代表一个实体（例如客户或产品），每列代表该实体的一个属性（例如名称、价格或数量）。它被称为数据仓库，因为它收集、存储和管理来自各种来源的大量结构化数据，例如事务数据库、web 应用程序系统和外部数据源。

并非所有数据仓库都基于关系模型, 非关系型数据仓库 包括柱状数据仓库、NoSQL 数据仓库和图数据仓库等类型。然而，关系数据仓库更受欢迎并被广泛采用，主要是因为关系数据库几十年来一直是占主导地位的数据管理范例。关系模型非常适合业务应用程序中常见的结构化数据。它还由于 SQL 的广泛使用而流行，多年来 SQL 一直是关系数据仓库的标准语言。

RDW 充当许多主题领域的中央存储库，并提供唯一版本真实数据（SVOT） ， SVOT 是数据仓库中的一个关键概念，指的是为公司提供统一，一致的数据视图 。这意味着数据仓库中的所有数据都以标准化、结构化的格式存储，并能表示数据版本的唯一、准确。这确保所有用户都可以访问相同的数据，消除任何差异或不一致，并消除数据孤岛。这改善了整个组织的决策、协作和效率。它还降低了因使用不同的、不一致的数据源而可能出现的错误和误解的风险。

想象一下，如果没有数据仓库，而是直接从多个源系统生成报表，甚至可能是一些 Excel 文件。如果报表查看者质疑数据的准确性，你可以告诉他们什么？ "真实"可能分散在如此多的源系统中，以至于很难追踪数据的来源。此外，某些报告会对相同的数据给出不同的结果，例如，如果两个报告使用复杂的逻辑从多个源提取数据，并且逻辑更新不正确（或根本不更新）。将所有数据集中在一个中心位置意味着数据仓库是唯一的真实数据来源，有关报表数据的任何问题都可以由数据仓库来解答。对于希望充分利用数据价值的公司来说，维护 SVOT 至关重要。

如果整个公司都使用数据仓库 (DW)，则通常将数仓叫做企业数据仓库（EDW）。这是一个更全面、更强大的数据仓库版本，旨在支持整个组织的需求。虽然标准数据仓库可能支持几个业务部门，但整个公司内有许多数据仓库，而 EDW 使用更广泛的数据源和数据类型来支持所有业务部门。 EDW 提供了公司所有数据 的单一、统一视图。

下图说明了拥有数据仓库的主要原因。左图显示了在没有数据仓库的情况下使用来自多个应用程序的数据运行报表是多么具有挑战性。每个部门都会运行一份报表，从与每个应用程序关联的所有数据库采集数据。运行的查询如此之多，必然会出现性能问题和不正确的数据。右图显示，将所有应用程序数据复制到 EDW 后，每个部门都可以非常轻松地运行报告，而不会影响性能。

通常，要构建数据仓库，数据管道将执行三个步骤，称为提取、转换和加载 (ETL)：

该管道从源系统中提取数据，例如数据库和普通文件
然后，对提取的数据进行转换或其他操作，以满足目标系统的要求。这可能涉及数据清洗、过滤、聚合或组合来自多个来源的数据。
转换后的数据被加载到数据仓库中。 DBA 可以使数据库和字段名称更有意义，使最终用户更轻松、更快速地创建报表。

对数仓的错误认识与使用

上边说明了什么叫数仓，下边列举了对数仓的错误认识，进而导致的错误使用：
直接复制源表加上DW 前缀

数仓不是源表的副本，数仓中的表是用来数据分析的，直接将数据源的表复制一份至数仓，然后加上DW 前缀是无意义的。

作为多个表的 union 视图

将多个数据源的表直接复制到数仓，然后在数仓中通过 Union 多张表查询视图，比如说有三个数据源的表分别为 t1, t2, t3, 然后复制到数仓创建 dw_t1, dw_t2, dw_t3 表，然后需要创建一张报表需要用到这三张视图，就在数仓中使用 Union 联合查询，这是错误的做法。

相反，我们需要在数仓中建模，然后将外部多个数据源表中的数据复制到数仓的一个模型表中，供分析查询。
单纯作为外部源数据的集中存储

还有更极端的错误做法就是把数仓单纯作为一个外部数据源的集中存储地，不断的往数仓中添加乱七八糟的，未经建模整理的外部源数据，用垃圾场来形容毫不为过，试想一下，让我们从垃圾场去找东西方便吗？

许多数仓在一开始只是为几个用户提供的一次性解决方案，随着用户的增多，演变成为整个公司提供数据的成熟但设计不佳的数据仓库。其实在一开始的时候，数仓就需要确定每一次的数据接入是否为一次性的，是否应该在前期花费一些必要的时间去进行数据建模，让数仓的表更加抽象化，进而后期可以支持接入更多的数据源。

自上而下的方法

在 RDW 中，我们需要预先做大量工作才能将数据传输到可以使用它来创建报表的位置。预先完成所有这些工作是一种称为自上而下方法的设计和实现 。这种方法非常适合查询历史数据创建报表 ，在这种报表中，我们试图确定发生了什么（描述性分析）以及发生的原因（诊断分析）。

在自上而下的方法中，首先建立数据仓库的总体规划、设计和架构，然后开发具体的组件。该方法强调在深入开发数据仓库之前制定符合整个公司的愿景并了解公司的战略目标和数据需求的重要性。

描述性分析 和诊断分析 是商业中常用的两种重要的数据分析类型。

描述性分析涉及分析数据以描述过去或当前的事件，通常通过使用汇总统计或数据可视化。此类分析用于了解过去发生的情况，并识别数据中有助于决策的模式或趋势。

诊断分析通常通过检查不同变量或因素之间的关系来调查过去事件的原因。此类分析可以定位问题原因或推断可能影响业务发展的问题。

假设一家公司想要分析过去一年的销售数据。描述性分析将涉及计算汇总统计数据，例如总销售收入、每日平均销售额以及按产品类别划分的销售额，以了解发生的情况。相比之下，诊断分析将检查因素（例如销售和营销支出，或季节性和客户人口统计）之间的关系，以了解销售额全年波动的原因。通过结合这两种方法，公司可以更深入地了解其数据并做出更明智的决策。

关系型数仓的架构如下图所示，ETL 用于将多个来源的数据提取到 RDW 中，在其中可以执行报告和其他分析。
自上而下的方法通常涉及以下步骤：

预先提出一些假设

首先要清楚地了解公司战略, 然后确保知道要对数据提出哪些问题。
定义业务需求

确定组织的目的、目标和关键绩效指标 (KPI)。收集并分析各部门和用户的数据需求，还可以将此步骤视为定义报表的要求。
设计数据仓库架构

根据业务需求，创建数据仓库的高层架构，包括数据仓库的结构、数据模型和数据集成流程。
开发数据模型

为数据仓库设计详细的数据模型，考虑各种数据实体之间的关系和数据的粒度。
构建架构

为数据仓库开发适当的数据库、写时 schema、表和字段。
开发ETL

开发 ETL 流程以从各种源系统中提取数据，将其转换为所需的格式，并将其加载到数据仓库中。
开发和部署BI工具和应用程序

构建部署 BI 工具，允许用户访问、分析和报表创建。
测试和完善数据仓库

执行测试以确保数据质量、性能和可靠性。进行必要的调整以优化系统。
维护和扩展数据仓库

随着组织需求的发展，相应地更新和扩展数据仓库。

自上而下的方法具有一些优点，例如全面了解组织的数据需求、更好的数据一致性以及改进的治理。然而，它也可能非常耗时且资源密集，与数据湖使用的自下而上的方法相比，需要更长的时间才能产生价值。

关系型数仓的优点

关系型数仓最直接的好处就是可以快捷，方便的生成 BI 报表，还有一些别的好处：

减轻业务方生产系统的压力

分析报表查询，不经过业务方的数据库系统。
读取速度快

数仓的表是一次写入多次读取，意味着数仓的数据库技术可以针对查询做一些优化，加速查询速度。
整合多个数据源

将多个数据源的数据集中在一个查询入口，减少报表构建的复杂度，提升报表查询的性能。
历史数据保存

数仓保存加载的源数据的历史数据记录，支持需要查询历史数据构建报表。
整合重构业务表元信息

许多应用程序数据库的表名和字段名非常难以理解，尤其是较旧的 ERP 和 CRM 产品（例如表名T116和字段名RAP16）。在数据仓库中，我们可以将这些源表中的数据以更加容易理解的方式复制到数仓（例如，Customer而不是T116）。还可以为表创建更好的数据模型，用户不必翻译神秘的表和字段名称，能够更轻松地创建报表。
防止业务表变更对报表的影响

如果直接从业务表查询数据构建报表，当业务表元信息变更后，报表将变得不可用。通过数仓构建报表则不会有这种影响，最多报表无法查询最新的业务数据构建报表，但是历史的报表是可以继续查看的。

当数仓的 ETL 适应业务方的业务表变更进行修复后，就可以继续查询最新的报表了。
提供数据安全保障

如果没有 DW，将需要给用户提供生成报表所需的各个数据源的访问权限，可能有几十个，提供访问权限的过程可能需要数周时间。使用数据仓库，每个用户只需要申请一个统一的查询入口，即可根据权限访问对应的数据库表，效率高。
保证数据质量

数仓从各个数据源获取到的数据往往都需要经过清洗，保证生成报表的数据质量。

关系型数仓的缺点

复杂

数据仓库的设计、构建和维护可能非常复杂且耗时。所需的专业技能和资源可能会增加成本。
成本高

实施数据仓库的成本可能很高，需要在硬件、软件和人员方面进行大量投资。持续的维护和升级也会增加成本。
数据集成难度高

集成来自不同来源的数据可能具有挑战性，因为它可能涉及处理不同的数据格式、结构和质量问题。这可能会导致在数据清理和预处理上花费时间和精力。此外，某些数据（例如来自物联网设备的流数据）太难提取到 RDW 中，因此从这些数据中获得的潜在价值就会丢失。
数据转换耗时

为了将数据加载到 DW 中，可能需要对其进行转换以符合仓库的数据模型。此过程可能非常耗时，并且数据转换中的错误可能会导致分析不准确。
数据延迟

由于数据仓库设计用于处理大量数据，因此它们的处理速度可能比其他类型的数据库慢。这可能会导致数据延迟，即仓库中的数据不是最新的源数据库的最新数据。
维护期间不可用

对于 RDW，通常需要一个维护时段。加载和清理数据非常耗费资源，如果用户再次期间尝试同时运行报表查询，他们将遇到性能非常低的情况。因此，在维护期间，用户不可用。如果在维护时段期间出现任何问题，例如 ETL 作业失败，可能需要延长维护时段。如果用户尝试运行报表查询但仍然不可用，会降低用户的信任度。
灵活性有限

DW 旨在支持特定类型的分析，这可能会限制其其他类型数据处理或分析的灵活性。可能需要将其他工具或系统与仓库集成以满足特定需求。
存在安全和隐私问题

在集中位置存储大量敏感数据可能会增加数据泄露和隐私侵犯的风险，因此需要采取强有力的安全措施。

数据加载

由于输入数据仓库的源表会随着时间的推移而发生变化，因此数据仓库需要反映这些变化。这听起来很简单，但是需要做出许多决定：加载（或拉取）数据的频率、使用什么提取方法、如何加载数据以及如何确定自上次加载以来哪些数据已更改。

加载数据的频率

需要多久更新一次 DW 在很大程度上取决于源系统数据的更新频率以及用户需要报表创建的时效性。用户通常不想查看当天的数据，而更愿意获取前一天结束时的所有数据。在这种情况下，可以在源系统数据库完成更新后每天晚上运行作业以通过 ETL 工具从源系统中加载数据，从而创建一个夜间维护窗口来完成所有数据传输。如果最终用户在白天需要更新，则需要更频繁的加载，例如每小时一次。

需要考虑的一件事是每次加载的数据大小。如果它非常大，更新 DW 可能会花费太长时间，因此可能希望将更新拆分为更小的块并进行更频繁的加载和更新（例如，每小时而不是每天）。

写入方式

有两种从源系统提取数据的方法：
全量加载

在全量加载中，所有数据都是从源系统中的一个或多个表中完全加载的。由于这种记载反映了源系统上当前可用的所有数据，因此无需跟踪更改，使得该方法非常容易构建。源数据按原样提供，不需要任何其他信息（例如时间戳）。

增量加载

在增量加载中，仅加载自指定时间（例如上次加载结束）以来发生更改的数据，而不是整个表。这最适合大型表，并且仅当可以识别所有更改的信息时才有效。

无论是进行全量加载还是增量加载，都有两种加载数据的方法：在线和离线。

在在线加载中，加载过程可以直接连接到源系统以访问源表，也可以连接到以预先配置的方式（例如，在事务日志或更改表中）存储数据更改的中间系统。

但是，并不是一直可以直接访问源系统。在这种情况下，数据将暂存于原始源系统之外，加载的数据通常被放在 CSV 或 JSON 等文件中。

如何确定变更数据

时间戳

业务系统的表最好带上更新时间字段

变更数据获取

大多数关系数据库支持更改数据捕获(CDC)，它记录数据库表的INSERTs、UPDATEs 等变更操作，并根据关系数据库的事务日志使表记录更改内容、位置和时间。如果需要近乎实时的数据仓库，可以在几秒钟内看到数据仓库中反映的源系统的更改，那么 CDC 可能是关键的支持技术。

分区

业务系统的表如果按照时间分区，那么数仓在加载数据时可以指定分区，加载指定日期的数据。

变更触发器

业务表也可以通过设置变更触发器，将变更数据写入"变更表"，然后数仓加载变更表中的数据。如果数据库支持CDC，最好还是使用 CDC 加载变更数据。

数仓 Merge 更新

如果没有其他方式，数仓可以加载全量数据，然后在数仓内执行 Merge 操作，对比源字段与目标字段。但是该方法将会严重增加数仓的负担，不建议使用。

关系型数仓会消失吗

大约在 2010 年代初，互联网界就开始讨论是否还需要关系型数据仓库的问题，该问题实际上是关于数据仓库架构的------可以只使用数据湖，还是应该同时使用数据湖和 RDW？

我一直觉得 RDW 是需要的，因为数据湖是基于 Hadoop 的，并且有太多限制。但是，一旦 Delta Lake等解决方案变得可用，并且数据湖开始出现使用比 Hadoop 更好、更易于使用的产品时，RDW 可能会慢慢退出历史的舞台，目前比较成熟的解决方案是湖仓一体方案，笔者公司现在就在探索使用 Flink+Paimon 的湖仓一体方案，可以完全抛弃 Hadoop 那一套，使用更加方便。

数据湖为数据科学家和自定义数据消费用户（"高级用户"）提供丰富的数据源，并且可以很好地满足分析和大数据的需求。但高级用户并没有那么多，大多数人仍然需要集成良好、系统清理、易于访问的关系数据，其中包括获取一段时间内事物如何演变或进展的历史日志。这些人最适合使用关系型数据仓库。

总结

本文介绍了大数据架构第一个广泛使用的技术解决方案，用于集中多个来源的数据并对其进行报告：关系数据仓库 。 RDW 通过提供用于数据存储和检索的集中存储库，彻底改变了企业和组织管理数据的方式，从而实现更高效的数据管理和分析。 RDW 能够以结构化方式存储和组织数据，允许用户快速轻松地生成复杂的查询和报表，从而提供有价值的信息并支持关键决策。

如今，关系数据仓库仍然是许多数据架构的基本组成部分，并且可以在从金融和医疗保健到零售和制造的各个行业中看到。