发布于: Jun 28, 2022
下一节将解释这一需求，并显示关于我们拥有的三个集群中每一个集群的一些统计信息。
以下是关于转储数据库的一些统计信息。它存储来自其他团队或中央数据仓库数据湖的所有数据。已对所有表格应用表保留，因为大多数 ELT 下游作业都会查找上次更新的日期，仅提取增量数据并存储在用户和副本数据库中。
• 向业务用户开放，并且可以运行他们的即席查询。
• 存储业务用户运行分析查询所需的所有表。
• 用户可以根据他们的需要在他们的模式中创建他们的表。
• 数据平台集群存储业务用户集群中存在的所有表，为即席分析创建的表除外。
• 它主要用于运行与 ETL 平台相关的生产管道作业。
• Amazon S3 归档了大多数此类表的整个历史记录，除了点击流数据集之类的快照表。
以下是用户和数据平台集群的一些统计信息。
- 日提取 ETL 作业的数量：2943
- 加载的 ETL 作业数：1655
- 日负载处理总量：1190 亿
- 日加载总运行时间：11415 分钟
- 日数据摄取总量：1660 亿
- 每日日期摄取总运行时间：25585 分钟
- 按不同数据库用户显示的数据库每日查询负载。
1.使用正确的排序键和分配键设计表格：查询性能取决于其扫描的数据量以及连接是否是同区连接。选择正确的排序键能够确保我们不会扫描不需要的数据，而选择正确的分配键能够确保连接的数据存在于同一节点上，并且减少数据在网络上的移动可提升查询性能。有关更多信息，请参阅在 Amazon Redshift 上设计表格的最佳实践。
2.请在编写查询时参阅在 Amazon Redshift 上设计查询的最佳实践。
3.将较大的文件拆分成较小的文件，使用批量加载而非连续插入，从而更改加载策略。有关更多信息，请参阅 Amazon Redshift 上加载数据的最佳实践。
4.通过分配正确的运行时间、内存、优先队列等配置相应的工作负载管理设置，以避免系统滥用。有关更多信息，请参阅教程：配置工作负载管理 (WLM) 队列以改进查询处理。
5.利用 Amazon Redshift Advisor 确定可能需要压缩的表、缺失统计信息的表、未压缩的数据负载，并进一步微调您的 ETL 管道。有关更多信息，请参阅采用 Amazon Redshift Advisor 的建议。
6.确定最浪费空间的表并经常清空它们。这能够释放浪费的空间，同时提升查询性能。有关更多信息，请参阅对表执行 vacuum 操作。
7.分析提交到数据库的 SQL 并识别表使用模式和消耗较高的连接。它能够帮助数据工程师预连接这些表，从而创建更多反范式化表，并帮助用户迅速、高效地访问单个表。
Amazon Redshift 集群的总容量为 1.15PB、约 6500 个表、4500 个计划 ETL 运行、一天 13000 个 ETL 查询，解决了支付团队业务用户的几乎全部 ETL 需求。但是，最近的数量增长填满了我们的数据库系统，这超出了我们的预期。接下来我们需要选择更实惠的存储选项：在 S3 上创建数据湖并通过 Amazon Redshift Spectrum 访问它们，这样我们甚至不必担心遇到扩展挑战，而且能提供无缝的用户体验。