云端现代数据仓库简介 - 第一部分

引言

本系列短文旨在面向那些刚接触数据仓库的人，以及那些习惯于更传统方法但正对云技术感兴趣的人。在第一部分，我们将快速概述传统本地数据仓库，以及最新技术如何发展并在云中得到应用。在第二部分，我们将动手实践，构建一个简单的云端数据仓库并为其提供数据。

什么是数据仓库？

数据仓库使企业能够分析其数据，从而做出更好的业务决策。基于数据做出的决策比基于直觉和猜测的决策更有效。一个好的数据仓库使企业能够切分和分析其数据，并从中提取有价值的业务见解。通常，这意味着为高管和经理生成报告和仪表板，以及为分析师提供探索数据的工具。

数据仓库需要从原始数据源获取数据。这些数据源可能是企业中的关系型/NoSQL数据库、Salesforce API 等第三方 API，以及可能涉及平面文件的合作伙伴组织集成。所有这些数据源都需要合并成一个连贯的数据集，该数据集经过优化，可支持快速数据库查询。

我们将探讨传统的本地方法，然后与当今的云服务进行比较和对比。

在云中，我们经常谈论 IaaS、PaaS 和 SaaS，但这些术语是什么意思？

• 基础设施即服务 (IaaS) 主要指虚拟机、网络和存储。这与本地部署类似，但增加了额外的弹性扩展机制。
• 平台即服务 (PaaS) 提供服务，您无需担心虚拟机、备份、配置等问题。它们是更高级别的抽象，可降低复杂性并加快您的上市时间。
• 软件即服务 (SaaS) 是 PaaS 的“超级版本”。它通常会抽象掉几乎所有的技术复杂性，让您专注于真正重要的事情。

当今最大的云提供商是 AWS。除了像 Panoply 云数据仓库、Periscope Unified Data Platform 和 Snowflake 这样的公司提供的一些 SaaS 产品外，它还提供了许多用于数据存储、计算和数据分析的 PaaS 服务。

传统方法

传统方法是本地部署，使用昂贵的关系型数据库产品，并通过 ETL 作业定期为其提供数据。这样做是有效的，但数据输入速度可能很慢，而且成本很高，包括维护和操作所需专业知识的成本，以及软件许可证和硬件的成本。但是，企业需要数据仓库提供的见解，因此这些成本是值得的。

传统的关系型数据库是面向行的。一行的数据存储在一起。但数据分析师通常一次只想对一小部分列执行聚合。例如，如果我们有一个订单表，我们可能想按产品进行聚合。每个订单行可能包含二十到三十列，而 `GROUP BY` 查询必须扫描每一行，包括读取所有不关心的列。这会导致大量的 IO 浪费，对性能和可扩展性都不利。

因此，为了弥补这一限制，维度模型应运而生。现在，我们将订单存储为“事实”，并为产品、商店、日期、客户等事物创建“维度”表。

例如，一个电子商务系统运行在一个具有以下模式的 OLTP 数据库上

ETL 作业定期从 OLTP 数据库读取数据，并将该模型转换为如下所示的星型模式

这种星型模式使查询更有效率。我们甚至可以进一步使用雪花模式，将维度进一步细分。除了避免扫描与查询无关的数据外，还可以使用预先计算的值来增强维度，从而避免了动态应用函数的需要。例如，时间维度可以包含日、周、月、季度和年列，或者可以添加特定于企业的公司财政周期等数据。

转向维度模型使得在这些面向行的存储中实现高性能数据分析成为可能。这种方法的缺点是难以以一种高效的、零散的方式填充维度。通常需要昂贵的 ETL 工具来自动化一些复杂性，这也使得在线数据仓库不切实际。最多，您可以每小时加载一次数据，但更常见的是每天晚上加载。

ETL 也有一些成本。开发起来可能很慢，运行起来通常也很慢，最终你会得到一个为通用分析优化的通用转换。新的、创新的数据转换方法现在已不可行，因为我们无法访问原始数据。转换可能包括过滤器，一旦数据被过滤掉，除非重新运行修改过的 ETL 过程来处理所有数据，否则就无法恢复。当新的数据源可用时，企业必须等待开发、测试和部署新的、通常是复杂的 ETL 管道。

关系型数据库中每兆字节 (MB) 的存储成本远高于典型的文件存储。因此，数据仓库中可存储的数据量受到限制。这意味着我们必须仔细考虑要存储什么以及数据的保留期限。由于托管的大小和成本，它会排除整个数据集。

云革命

如今，最新技术已经向前发展，并已进入云端。今天，我们可以比以往任何时候都更便宜、更可靠地存储大量数据。不仅存储成本极其低廉，计算成本也在下降，同时出现了分析和利用我们数据的新云技术。平台即服务 (PaaS) 已进入数据仓库领域，现在我们看到了软件即服务 (SaaS) 产品也随之兴起。

如果我们看看 AWS，我们会发现许多极具吸引力的数据存储和查询 PaaS 产品。我们可以廉价、可靠、安全地将所有数据存储在 S3 中。我们不需要先转换数据，只需将其直接放入 S3，当我们需要时，它就会永远在那里。这通常被称为数据湖。数据湖与数据仓库不同。它们本质上是大量的结构化和非结构化数据的集合，存储在 S3 等成本效益高且可靠的存储中，并附带一个元数据存储。需要元数据来记录存储了什么数据以及存储在哪里。如果您因为丢失了对数据是什么、在哪里丢失了数据的跟踪而失去了对数据湖的控制，您就会陷入所谓的“数据沼泽”。

几乎所有的 AWS 服务、第三方云产品和服务都与 S3 集成。从那里，我们可以将数据从数据湖转移到 EMR 和 Redshift 等其他 PaaS 服务。您可以今天使用 Redshift，明天迁移到 SaaS 产品，而无需担心如何迁移数据。原始数据都以其原始格式保存在 S3 中。您不必受限于当前的数据仓库策略，并且可以随着技术和服务的演进而转移。

Redshift

Redshift 是一个分布式、面向列的存储数据仓库。这意味着它不是按行存储数据，而是按列存储数据，这使得它可以高效地扫描单列数据进行聚合。这使得对海量数据集进行聚合更加高效。它仍然是关系型的，您仍然可以编写 SQL，进行连接，以及执行您在关系型数据库中习惯执行的几乎所有操作。

但这是一个范式转变，事实和维度不再总是必需的。首先，因为它已经是面向列的，其次，它是一个大规模并行处理 (MPP) 平台。这意味着计算分布在许多节点上，我们可以做以前不可能做到的事情。这两点意味着我们不必将数据优化为一套严格的维度。我们可以利用数据存储的面向列的特性和大规模并行计算来实现高效的聚合和投影。

因此，昨天的 ETL 已经消失，取而代之的是更简单的 ETL 和 ELT。ELT 是我们先提取和加载 (Extract and Load)，然后再转换 (Transform)。我们可以在 Redshift 中以查询的形式进行转换。转换不再总是发生在将数据加载到数据仓库之前，而是发生在查询本身中。同样，这也是由于 Redshift 的大规模并行处理能力。当然，它并非万能，与其他所有事物一样，具体取决于您的用例以及这些查询的运行频率。如果您需要低延迟的查询性能或处理非常大的数据集，建模仍然很重要。

数据仓库甚至可以是一个临时构建、使用和按需丢弃的构造。我们可以利用自动化来创建一个大小适中的 Redshift 集群，只拉入我们所需的数据，对其进行转换，然后运行分析。一旦我们获得了所需的见解，我们就可以将这些结果物化到另一个数据库中，然后丢弃数据仓库。这真是一场革命！

仍然存在一些需要处理的棘手问题

• 您如何跟踪存储在 S3 中的数据？如果没有有效的元数据管理策略，您最终会得到大量数据，却对它们是什么或来自哪里知之甚少——这就是数据沼泽。
• 安全。访问控制、审计日志、监控。安全几乎是任何架构中最困难的部分，无论是本地部署还是云端。一旦出现问题，其后果可能是成为头条新闻，被报道为又一次数据泄露。
• S3 文件大小。我提到 S3 非常便宜，但这只有在使用得当的情况下才成立。一种糟糕的使用方式是拥有大量非常小的文件。当文件大小平衡得当且适中时，S3 的成本效益最高。文件太大，您就会读取比所需更多的数据；文件太小，您将为数据访问支付更多费用，并且由于效率较低（需要发出更多 HTTP 请求），性能也会受到影响。

将数据导入 Redshift

将数据导入 Redshift 的选项太多，无法一一列举。但下面我将提供几个简单的示例，以便我们开始。

S3 直接导入 Redshift

将数据从本地数据源导出到 S3。您可以按原样将数据放入 S3，也可以先对其进行一些处理。我们可以从 Redshift 内部运行 `COPY` 命令，将 S3 文件中的分隔数据复制到 Redshift 的表中。

S3 -> Lambda -> Redshift

添加一个 S3 文件会触发一个 Lambda 函数，该函数执行一些数据转换，然后写入 Redshift。您甚至可以写回 S3，然后像以前一样使用 `COPY` 命令。

S3 -> EMR -> Redshift

有时，您需要对源数据执行仅 Hadoop 才能管理的复杂转换。您可以在 Amazon EMR 上运行 Hadoop 作业，并将结果写入 Redshift。

下一步

此外，还有 Panoply 和 Periscope Data 等云数据仓库公司，它们几乎可以读取任何 AWS 服务，甚至还为您的本地数据源提供数据导出器，进一步简化您的数据架构。

在下一部分中，我们将从简单开始，在 AWS 中构建 S3 到 Redshift 的架构。我们将介绍 Redshift 的基本工作原理，包括数据库的分布式特性如何影响我们的表设计。数据进入 Redshift 后，我们将运行一些查询，看看 Redshift 查询与您习惯的常规 SQL 相比如何。

历史

• 2017 年 12 月 19 日：初始版本