在AWS中构建数据仓库和数据湖

数据仓库，数据湖，湖屋。如果这些词对你一点都不熟悉，那么你的工作显然与数据无关。👨‍💻

然而，这将是一个相当不切实际的前提，因为今天，似乎一切都与数据相关。或者公司领导们喜欢这样描述：

• 以数据为中心和数据驱动的业务。
• 数据随时随地、任何方式。

最重要的资产

似乎数据已经成为越来越多公司最有价值的资产。我记得大型企业总是产生大量的数据，想想每个月新增的几百万亿字节的数据。这还是10-15年前的事情。但是现在，你可以在几天内轻松产生这么多数据。有人可能问，即使是一些任何人都会使用的内容，这真的有必要吗？答案是肯定的 😃。

并不是所有的内容都有用，有些部分甚至根本没有用过。我经常亲眼目睹企业生成大量的数据，然后在成功加载之后变得毫无用处。

但这已经不再重要了。在云中存储数据（Data storage ）变得便宜，数据源呈指数增长，今天没有人能够预测到一年后他们会需要什么样的数据，因为新的服务已经接入到系统中。此时，即使是旧数据也可能变得有价值。

因此，存储尽可能多的数据是一种策略。但也要以尽可能有效的方式来存储。这样数据既可以有效地保存，又可以查询、重用、转换和进一步分发。

让我们来看看如何在AWS内部实现这一目标的三种本地方式：

• Athena数据库-一种在云中创建数据湖的便宜有效的简单方式。
• Redshift数据库-一个严肃的云版本的，它有潜力取代大多数目前无法跟上数据指数增长的内部解决方案。
• Databricks-将数据湖和数据仓库组合为一个完整的解决方案，还带有一些额外的奖励。

AWS Athena的数据湖

数据湖是一个快速存储非结构化、半结构化或结构化形式的数据的地方。同时，您不希望这些数据在存储后被修改。相反，您希望它们尽可能地原子和不可变。只有这样才能确保在后续阶段最大限度地重复使用的潜力。如果您在第一次加载到数据湖后就失去了数据的原子特性，那么没有办法再获取到丢失的信息。

AWS Athena是一个直接存储在S3存储桶中且没有运行在后台的服务器集群上的数据库。这意味着它是一项非常便宜的数据湖服务。结构化文件格式，如parquet或逗号分隔值（CSV）文件保持数据的组织。S3存储桶保存文件，当处理程序从数据库中选择数据时，Athena会引用它们。

Athena不支持其他被认为是标准的各种功能，比如更新语句。这就是为什么您需要将Athena视为一个非常简单的选项。另一方面，它可以帮助您防止修改您的原子数据湖，因为您不能进行修改 😐。

它支持索引和分区，使得它可用于有效执行选择语句和创建逻辑上独立的数据块（例如，按日期或键列分隔）。它还可以非常容易地进行水平扩展，只需向基础架构添加新的存储桶即可。

优缺点

需要考虑的好处：

• 雅典娜的优势在于其价格便宜（仅由S3存储桶和按使用量计费的SQL使用成本组成）。如果您想在AWS中构建一个实惠的数据湖，那么雅典娜就是您的首选。
• 作为一项原生服务，雅典娜可以轻松与其他有用的AWS服务集成，如用于数据可视化的Amazon QuickSight或用于创建持久化结构化元数据的AWS Glue数据目录。
• 最适合在不维护整个基础架构的情况下对大量结构化或非结构化数据运行特定查询。

需要考虑的缺点：

• 雅典娜在返回复杂的选择查询时并不特别有效，尤其是如果这些查询不符合您设计请求数据从数据湖中获取的数据模型假设。
• 这也使得它在处理潜在的数据模型未来变化时缺乏灵活性。
• 雅典娜不支持开箱即用的任何其他高级功能，如果您希望将某些特定内容作为服务的一部分，您需要在其上实现它。
• 如果您希望在一些更高级的演示层中使用数据湖数据，往往唯一的选择就是将其与另一个更适合此目的的数据库服务（如AWS Aurora或AWS Dynamo DB）结合使用。

目的和现实应用案例

如果目标是创建一个没有任何高级数据仓库功能的简单数据湖，则选择雅典娜。例如，如果您不希望数据湖上定期运行严肃的高性能分析查询。相反，拥有一批易于扩展的不可变数据存储是首要任务。

您无需过多担心空间不足的问题。甚至可以通过实施数据生命周期策略进一步降低S3存储桶的成本。这基本上意味着将数据移动到针对存档目的具有较慢摄取返回时间但成本较低的不同类型的S3存储桶中。

雅典娜的一个很棒的功能是它会自动创建一个文件，其中包含作为SQL查询结果一部分的数据。然后，您可以将此文件用于任何目的。因此，如果您有许多Lambda服务对数据进行进一步的多个步骤处理，它是一个很好的选择。每个Lambda的输出将自动成为结构化文件格式的输入，以供后续处理使用。

在云基础架构中大量原始数据到达时，雅典娜是一个很好的选择，您不需要在加载时处理这些数据。这意味着您只需要在云中拥有快速存储和易于理解的结构。

另一个应用案例是为另一个服务创建一个专用的数据存档空间。在这种情况下，雅典娜数据库将成为您暂时不需要的所有数据的廉价备份存储位置，但这些数据可能在将来发生变化。此时，您只需将数据摄入并将其发送出去。

AWS Redshift的数据仓库

数据仓库是一个以非常结构化的方式存储数据的地方。易于加载和提取。目的是运行大量非常复杂的查询，通过复杂的连接将许多表连接在一起。各种分析功能可用于计算现有数据的各种统计数据。最终目标是提取未来预测和事实，以在企业中利用现有数据。

Redshift是一个完整的数据仓库系统。它具备优化的集群服务器和数据库存储系统，可实现水平和垂直扩展，并优化快速复杂查询的返回。虽然今天你也可以在无服务器模式下运行Redshift。在S3上没有任何文件或类似的东西。这是一个具有自己存储格式的标准数据库集群服务器。

它内置了性能监控工具，同时还提供可定制的仪表盘指标，可用于调整性能以适应您的使用情况。管理也可以通过单独的仪表盘访问。了解所有可能的功能和设置以及它们对集群的影响需要花费一些精力。但是，与基于本地解决方案的Oracle服务器的管理相比，它远不及复杂。

尽管Redshift存在一些限制，限制了其在日常使用中的使用方式（例如，对一个数据库集群中并发活动用户或会话数量的硬性限制），但操作速度非常快可以在一定程度上规避这些限制。

优缺点

需要考虑的优点：

• 原生的AWS云数据仓库服务，易于与其他服务集成。
• 集中存储、监控和摄取来自非常不同的源系统的各种类型的数据源的地方。
• 如果您曾经想要一个无需维护基础设施的无服务器数据仓库，现在可以实现。
• 针对高性能分析和报告进行了优化。与数据湖解决方案不同，它具有用于存储所有传入数据的强大的关系数据模型。
• Redshift数据库引擎源自PostgreSQL，与其他数据库系统高度兼容。
• 非常有用的COPY和UNLOAD语句，用于从S3存储桶加载和卸载数据。

需要考虑的缺点：

• Redshift不支持大量并发活动会话。会话将被暂停并按顺序进行处理。虽然在大多数情况下这可能不是一个问题，因为操作速度非常快，但在具有许多活跃用户的系统中，这是一个限制因素。
• 尽管Redshift支持许多先前来自成熟的Oracle系统的功能，但它仍然不在同一个水平上。其中一些预期功能可能不存在（例如DB触发器）。或者Redshift在某种程度上仅支持它们（例如物化视图）。
• 无论何时需要更高级的自定义数据处理作业，您都必须从头开始创建。大部分时间使用Python或Javascript编程语言。与Oracle系统的情况不同，它并不像PL/SQL那样自然，即使是函数和过程也使用非常类似SQL查询的语言。

用途和真实世界应用案例

Redshift可以成为所有以前存放在云之外的各种数据源的中央存储库。它是以前的Oracle数据仓库解决方案的有效替代品。由于它也是一个关系数据库，从Oracle迁移到Redshift甚至是一个相当简单的操作。

如果您在许多地方都有现有的数据仓库解决方案，这些解决方案在方法、结构或预定义的常见流程方面并不真正统一，Redshift是一个很好的选择。

它将为您提供一个机会，将来自不同地方和国家的各种数据仓库系统合并到一个平台下。您仍然可以按国家将它们分开，以使数据保持安全，并且只能被需要的人访问。但同时，它将允许您构建一个覆盖所有企业数据的统一的仓库解决方案。

另一个情况可能是，如果目标是建立一个具有自助服务广泛支持的数据仓库平台。您可以将其理解为个体系统用户可以构建的一组处理过程。但与此同时，它们永远不是公共平台解决方案的一部分。这意味着这些服务只能由创建者或由创建者定义的人群访问。它们不会以任何方式影响其他用户。

查看我们与 Datalake and Datawarehouse的比较。

Databricks在AWS上的Lakehouse

Lakehouse是一个与Databricks服务紧密相关的术语。即使它不是AWS的原生服务，它在AWS生态系统中运行得非常好，并提供了多种选项，以便与其他AWS服务进行连接和集成。

Databricks旨在连接（以前）非常不同的领域：

• 用于存储非结构化、半结构化和结构化数据的数据湖解决方案。
• 用于数据仓库结构化和快速访问查询数据的解决方案（也称为Delta Lake）。
• 支持在数据湖上进行分析和机器学习计算的解决方案。
• 针对上述所有领域的数据治理，具有集中管理和开箱即用的工具，以支持不同类型的开发人员和用户的生产力。

这是一个常用平台，数据工程师、SQL开发人员和 machine learning数据科学家可以同时使用。每个组别也有一组工具可用于完成他们的任务。

因此，Databricks的目标是一个多面手的解决方案，试图将数据湖和数据仓库的优势结合到一个单一的解决方案中。除此之外，它还提供了在已构建的数据存储上直接测试和运行机器学习模型的工具。

优点和缺点

需要考虑的好处：

• Databricks是一个高度可扩展的数据平台。它根据工作负载大小进行扩展，甚至可以自动进行扩展。
• 它是数据科学家、数据工程师和业务分析师的协作环境。能够在同一个空间和一起进行所有这些操作是一个巨大的优势。这不仅从组织的角度来看，而且还有助于节省以其他方式需要用于单独环境的成本。
• AWS Databricks与其他AWS服务（如Amazon S3、Amazon Redshift和 Amazon EMR）无缝集成。这使用户可以轻松地在服务之间传输数据，并利用AWS云服务的全部范围。

需要考虑的缺点：

• Databricks的设置和管理可能很复杂，特别是对于新手用户来说。为了充分利用该平台，需要相当高的技术专长。
• 尽管Databricks在按使用量付费的定价模式方面具有成本效益，但对于大规模数据处理项目来说，仍然可能很昂贵。使用该平台的成本可能会迅速增加，特别是如果用户需要扩展其资源。
• Databricks提供了一系列预构建的工具和模板，但对于需要更多自定义选项的用户来说，这也可能是一个限制。该平台可能不适合需要对其大数据处理工作流程具有更大灵活性和控制权的用户。

目的和实际应用案例

AWS Databricks最适合具有大量数据的大型企业。在这里，它可以满足从不同外部系统加载和上下文化各种数据源的要求。

通常的需求是提供实时数据。这意味着从数据出现在源系统中的时间开始，进程应立即接收并处理并将数据即时或只有很小的延迟存储到Databricks中。如果延迟超过一分钟，就被视为准实时处理。无论如何，这两种情况在Databricks平台上通常都可以实现。这主要是由于大量的适配器和实时接口连接到其他各种AWS原生服务。

Databricks还可以轻松与Informatica ETL systems集成。如果组织系统已经广泛使用Informatica生态系统，Databricks看起来就是一个很好的兼容附加组件。

最后的话

随着数据量的指数增长，了解这些可以有效应对的解决方案是很好的。曾经需要大量管理和维护的噩梦现在需要很少的管理工作。团队可以专注于从数据中创造价值。

根据您的需求，只需选择能够处理它的服务。虽然一旦做出决定，您可能需要坚持使用AWS Databricks，但其他选择更加灵活，即使能力较弱，特别是它们的serverless模式。稍后迁移到另一个解决方案相当容易。