Cookpad 如何在扩展 Amazon Redshift 集群规模的同时，通过限制资源用量有效控制成本

Original Link:  https://aws.amazon.com/cn/blogs/big-data/how-cookpad-scaled-its-amazon-redshift-cluster-while-controlling-costs-with-usage-limits/

本文为Cookpad有限公司数据工程师Shimpei Kodama撰写的客座文章。

Cookpad是一家科技企业，致力于构建一套社区平台以供用户共享食谱创意与烹饪技巧。Cookpad公司的使命是“让日常烹饪变得妙趣横生”。作为日本最大的食谱共享平台之一，Cookpad的月度用户超过5000万，并在其他国家/地区也保持着迅猛的增长势头。

自2015年以来，Cookpad一直使用Amazon Redshift作为其数据分析平台，帮助员工访问所有数据、执行分析、获取洞察，并借此提升最终用户的满意度。截至本文撰稿时，Cookpad的Amazon Redshift集群每天负责处理全球团队提交的数千项查询，且单一单集群批处理作业量超过500项。

在今天的文章中，我们将探讨Cookpad如何将日志数据的加载间隔从几个小时缩短至几分钟，保证用户可通过Amazon Redshift Spectrum查询完整日志信息。此外，我们还将讨论如何通过并发扩展将查询队列等待时间减少15%。最后，我们将介绍如何使用Amazon Redshift即付即用定价模式轻松控制运营成本。

使用Amazon Redshift Spectrum分析持续增长的日志数据

随着服务规模的快速增长，我们在2018年末开始面临一大实际挑战——日志数据体量开始迅猛提升。当时，我们需要将数据加载至约250个日志表当中。在压缩之后，单月日志数据总量约为3 TB，磁盘使用百分比已经高于80%。

由于日志表数量与数据量的快速膨胀，我们最终耗尽了所有磁盘存储空间，因此无法在不添加节点的前提下按指定时间间隔将日志加载至Amazon Redshift、或通过Amazon Redshift执行日志数据查询。后来发布的RA3实例能够很好地解决磁盘容量问题，但当时是2018年，我们已经别无选择。

另外，在日志表加载间隔方面，我们大多数日志表的加载间隔为6个小时。尽管某些日志表所需要的时间间隔更短，我们可以在发布之后立即检查日志，但这会影响到查询性能，因此不具备可行性。

面对每月大约3 TB的新增压缩日志数据（带来高达80%的磁盘使用率），我们只能添加更多节点，或者从集群中卸载未使用/陈旧数据。但这两种选择也有自己的问题——我们需要将访问率较低的数据（例如旧有日志）保留在Amazon Redshift以上，借此随时查询以供长期分析。

我们的解决方案

为了应对这些挑战，我们决定将日志数据迁移至Amazon Simple Storage Service (Amazon S3)，并使用Amazon Redshift Spectrum对其进行查询。

我们构建起一条名为Prism的全新数据管道，该管道将日志数据（采用Parquet格式）放置在S3存储桶内，而不再使用 Amazon Kinesis Data Firehose。选择这种方法的原因之一，在于我们希望能按日志的生成时间（而非日志的接收时间）对Amazon S3中的日志文件进行分区，以便将延后获取的日志也放入正确的分区当中（这项功能于2019年2月以自定义前缀的形式正式发布）。另一个原因是，我们希望能将Amazon ZS3中的大量小文件合并为少数体量较大的文件，借此提高用户查询性能。下图所示，为我们数据管道的基本架构。

这条管道包含以下操作步骤：

1. Fluentd将日志文件放置在S3存储桶内。
2. 将Amazon S3事件通知发送至Amazon Simple Notification Service (Amazon SNS)主题与Amazon Simple Queue Service (Amazon SQS)队列处，其中后者订阅SNS主题以接收消息。
3. 预处理器从SQS队列处接收消息，处理日志文件以执行清洗与转换，并将处理后的文件保存在S3存储桶内。
4. Amazon S3事件通知将被发送至另一SQS队列处。
5. Prism Stream从该SQS队列接收消息，将文件从JSON格式转换为Parquet格式，再将转换后的文件保存在另一S3存储桶中。S3存储桶中的日志文件将按日志生成日期进行分区。
6. S3存储桶内的Parquet日志文件现在可供Amazon Redshift Spectrum直接查询。
7. Prism Merge会定期将多个小型日志文件合并为体量合理的较大文件。

结果

加载日志的间隔从几小时缩短到约10分钟。现在，我们无需添加节点即可通过Amazon Redshift Spectrum查询完整日志。

另外，Amazon Redshift Spectrum的schema on read能够在无需重新加载数据的前提下，解决varchar列字符长度溢出的问题，更好地适应Amazon Redshift本地表的使用需求。

最终性能满足了我们的SLA要求，使我们能够立即对Amazon S3中的数据进行分析，且不必预先加载数据。根据相关实验，Amazon Redshift Spectrum拥有良好的性能表现，处理时长仅比使用Amazon Redshift本地表长20%。

通过并发扩展缩短查询响应时间

我们遇到的另一项挑战，在于全球分布团队会随时发起大量工作请求，并导致查询队列时间有所增加，进而引发过载问题。例如，英国团队的批处理作业一般从世界标准时间03：00开始，结束于世界标准时间08：00，转换为日本标准时间则为12：00至17：00。在此期间，日本团队常常会遭遇性能下滑状况。

为了解决此问题，我们决定启用Amazon Redshift并发扩展，借此在必要时为后台自动添加更多集群以支持大量并发查询请求。

在AWS为Amazon Redshift添加Usage Limits（用量限制）功能之后，我们很快采用，保证在控制成本的同时继续享受并发扩展带来的便利。目前，我们已经将用量限制（禁用功能）设置为每天1小时。

在启用并发扩展之后，我们每天能够在并发扩展集群上运行超过100项查询，且主集群上的日均队列等待时间缩短了15%。

对Amazon Redshift Spectrum 及并发扩展进行成本优化

我们还为Amazon Redshift集群采购了预留实例，借此享受可观的价格折扣。不过考虑到Amazon Redshift Spectrum与并发扩展只能使用即付即用计费模型，因此我们决定使用工作负载管理（WLM）配合用量限制以控制并监控成本水平、满足预算约束。

在Amazon Redshift Spectrum当中，我们配置了WLM与用量限制（警报）。我们将WLM配置为在超过数量超过1 TB时停止查询，以防止错误执行大规模扫描。另外，我们还配置了每周用量限制，保证在超出Amazon Redshift Spectrum每周预算之前向我们发送警报提醒。

用量限制与并发扩展功能还可监视并控制用户的使用情况，以及这两项功能所对应的相关成本。您可以创建每日、每周以及每月用量限制，并预先定义在达到限制并有可能破坏支出可预测性时应采取的操作措施。操作方法包括将用量统计信息以事件形式记录至系统表内，生成Amazon SNS警报，并根据预定义的阈值禁用Amazon Redshift Spectrum或并发扩展。以此为基础，我们可以继续使用Amazon Redshift Spectrum与并发扩展带来的助益，又可在适当的阈值控制范围内安心支配预算配额。

关于更多详细信息，请参阅在Amazon Redshift中管理用量限制并观看以下视频。

在并发扩展方面，我们将用量限制设置为每天1小时，同时充分考虑到成本与队列等待时长间的权衡。因此，并发扩展集群每天只在业务环境中启动并运行1个小时（一般会稍微超过1小时）。值得庆幸的是，相对于每天24小时持续运行的主集群，我们等于获得了1个小时的并发扩展额度。如此一来，我们既获得了并发扩展支持，也将额外成本控制在极低水平。

总结

Amazon Redshift已经成为Cookpad公司为员工提供自助服务分析的关键基础。正如前文所述，我们使用AWS提供的种种新功能对集群容量进行了扩展，且全程未添加任何节点。

本篇作者