发布于: Oct 14, 2022
海量数据存储问题一直是数据库使用中关心的问题，随着数据的不断增多，传统的数据库已经无法满足基本要求，智能的云数据库是如何存储并保管这些数据的呢？
Amazon Redshift 与 Amazon S3 为本文中的智能湖仓参考架构提供了统一的原生集成存储层。一般而言，Amazon Redshift 负责存储高度规范化、符合标准要求的可信数据，这些结构化数据遵循标准维度 schema；对于其他结构化、半结构化与非结构化数据，则由 Amazon S3 提供 EB 级别的数据湖存储支持。但 Amazon Redshift 同样支持半结构化数据，供您在其中摄取及存储半结构化数据。Amazon S3 则提供行业领先的可扩展性、数据可用性、安全性与性能表现。开放文件格式允许您使用多种处理及消费层组件对同一批 Amazon S3 数据执行分析。公共目录层在 Amazon S3 中负责存储结构化或半结构化数据集的 schema。消费该 S3 数据集的组件通常会在读取数据集时，将这些 schema 应用于数据集（即 schema-on-read）。
Amazon Redshift Spectrum 是原生集成智能湖仓存储层中的核心组成部分之一。Redshift Spectrum 帮助 Amazon Redshift 提供一个统一的 SQL 接口，用以接收及处理 SQL 语句，并在同一查询内引用及合并托管在数据湖及数据仓库内的数据集。凭借数千个瞬态 Redshift Spectrum 节点配合 Amazon Redshift 的复杂查询优化功能，Amazon Redshift 能够高效查询存储在 Amazon S3 中的 PB 级数据。Redshift Spectrum 还能够查询 S3 数据湖内的分区数据，包括读取使用开源编解码器压缩的数据，并支持包括 JSON、CSV、Avro、Parquet、ORC 以及 Apache Hudi 在内的多种开源行或列式存储。
当 Redshift Spectrum 读取存储在 Amazon S3 中的数据集时，会将来自公共 Amazon Lake Formation 目录的相应 schema 应用于数据（即 schema-on-read）。借助 Redshift Spectrum，您可以建立起执行以下操作的 Amazon Redshift 原生管道：
- 使用 Redshift Spectrum 将大量历史数据保留在数据湖内，并将最近几个月的热数据摄取至数据仓库中。
- 处理附加存储内的热数据与数据湖中的历史数据，由此生成丰富数据集，全程无需执行任何数据移动操作。
- 将丰富数据集插入至附加存储中的表内，或者直接插入由数据湖托管的外部表中。
- 轻松将大量冷门历史数据由数据仓库转移至成本更低廉的数据湖存储内，且仍保证将其作为 Amazon Redshift 查询的一部分以供轻松获取。
Amazon Redshift 中的高度结构化数据通常负责为交互式查询及高度受信的即时商务智能仪表板提供支持；而 Amazon S3 内的结构化、非结构化与半结构化数据，则常被用于驱动机器学习、数据科学与大数据处理用例。
Amazon DMS 与 Amazon AppFlow 能够将数据从结构化来源直接传递至 S3 数据湖或 Amazon Redshift 数据仓库，充分满足用例的具体需求。在摄取数据文件之后，DataSync 会将数据存储至 Amazon S3。处理层组件可通过单一统一接口（例如 Amazon Redshift SQL）访问统一智能湖仓存储层内的数据，并由接口使用 Redshift Spectrum 将 Amazon Redshift 集群中存储的数据与 Amazon S3 的数据加以合并。
在 S3 数据湖内，结构化与非结构化数据均被存储为 S3 对象。数据湖内的各 S3 对象会按存储桶或前缀名称被划分为登陆区、原始区、受信区及策划区等几种类别。对于将数据存储在 S3 数据湖内的管道，数据将从来源处被直接摄取至登陆区内。接下来，处理层将验证登陆区数据并将结果存储在原始区内或添加相应前缀以供永久存储。之后，处理层对原始区数据执行 schema、分区以及其他转换，确保数据达到一致状态，处理后的结果被统一存储在受信区内。最后一步，处理层对受信区数据集进行建模，再将结果与其他数据集进行合并以实施策划，最终结果被存储在策划层内。通常，来自策划层的数据集会被部分或全部纳入 Amazon Redshift 数据仓库中，以支持那些要求极低访问延迟、或者需要运行高复杂度 SQL 查询的用例。
各个区内的数据集，通常会根据相应区（原始、受信或策划区）消费模式的匹配键进行分区。参考架构使用 GZIP、BZIP 以及 Snappy 等开源编解码器对数据集所对应的 S3 对象执行压缩，借此降低存储成本并缩短处理层与消费层内的组件读取时间。数据集通常以 Parquet 及 ORC 等开源列式存储格式存在，以进一步减少处理层与消费层组件查询某些列子集时所需读取的数据量。Amazon S3 提供一系列针对不同用例设计的存储类。其中 Amazon S3 智能分层存储类专门用于在不影响性能或运营开销的前提下，自动将数据转移至最具成本效益的访问层内。
Amazon Redshift 提供 PB 级数据仓库存储容量，用于存储按维度或非规范化 schema 建模的高度结构化数据。在 Amazon Redshift 上，数据将以高压缩比列式格式存储，并分布式存储在高性能节点集群上。各个节点最多提供 64 TB 高性能托管存储容量。Amazon Redshift 会强制执行 schema-on-write、ACID 事务与工作负载隔离等机制，借此保障数据的高质量与一致性。用户大多在 Amazon Redshift 上存储高一致性、统一、可信且受控的结构化数据集，借此满足高吞吐量、低延迟与高并发性用例。当然，您也可以使用 Amazon Redshift 中增量式刷新的物化视图，以显著提高商务智能仪表板中复杂查询的性能与吞吐量。
在通过各种来源获取数据并构建智能湖仓时，我们一般可以直接在整个数据湖及数据仓库中托管数百甚至数千个数据集。中央数据目录将统一为智能湖仓存储（数据仓库与数据湖）内的全部数据集提供元数据，这将大大降低搜索难度、保证智能湖仓能够始终保持良好的数据发现能力。此外，这种将元数据由数据湖托管数据分离至统一中央 schema 的处理方式，还可帮助处理层/消费层组件及 Redshift Spectrum 轻松实现 schema-on-read。
在本文的智能湖仓参考架构中，Lake Formation 提供的中央目录负责存储智能湖仓中托管的全部数据集的元数据（无论数据集实际存储在 Amazon S3 还是 Amazon Redshift 内）。用户可以将全部数据集的技术元数据（例如版本化表 schema、分区信息、物理数据位置以及更新时间戳等）与业务属性（例如数据所有者、数据管理者、列业务定义以及列信息敏感性等）存储在 Lake Formation 中。
大部分由数据湖托管的数据集，其 schema 都在不断变化、数据分区也在持续增加；而由数据仓库托管的数据集 schema 则大多以受控方式持续演进。Amazon Glue crawlers 能够跟踪数据湖托管数据集以及数据仓库数据集内不断变化的数据 schema 与新增分区，并在 Lake Formation 目录中为相应 schema 添加新的版本。此外，Lake Formation 还提供 API，供您使用自定义脚本及第三方产品实现元数据注册与管理。
Lake Formation 为数据湖管理员们提供了中央管理位置，可以为数据湖内托管的数据库和表设置细化的表级与列级权限。在设置 Lake Formation 权限之后，用户和各分组只能使用多个处理层与消费层服务（例如 Amazon Glue、Amazon EMR、Amazon Athena 以及 Redshift Spectrum 等）访问授权的表和列。
相关文章