亚马逊AWS官方博客
Narrativ 使用 Amazon Redshift 帮助创建者货币化其数字化内容
Narrativ 对自己的定位是：Narrativ 为下一代数字化内容创建者创建内容货币化技术。我们的产品组合包括一个实时竞标平台和视觉故事描述工具，将它们结合使用，每月可产生数百万美元的广告价值和数十亿个数据点。
在 Narrativ，我们已看到在过去 15 个月内，平台使用量产生巨大增长，而我们的产品所产生的数据也发生类似数量级的增长。此博文分享了我们使用 AWS 发展成为稳固、可扩展、高性能且具有成本效益的分析环境的内容，我们还讨论了一路来从数据仓库和数据湖分析中学习到的最佳实践。
我们预计 Narrativ 将会继续加速增长，在去年年底已开始计划下一个数量级。我们一直在使用 Amazon Redshift 作为我们的数据仓库，它为我们提供了优良的服务。随着我们的数据持续增长，我们将 Amazon S3 用作数据湖并使用 Amazon Redshift Spectrum 中的外部表格直接查询 S3 中的数据。令我们兴奋的是，这使我们能够轻松地扩展存储和单独计算资源，以满足我们的需求，且不需权衡成本或复杂性。
在此过程中，我们创建了 Spectrify，它简化了 Redshift Spectrum 的使用并封装了很多最佳实践。用一个简单的命令，Spectrify 便可以完成三件事。首先，它以逗号分隔值 (CSV) 格式将 Amazon Redshift 表导出到 S3 中。其次，它将导出的 CSV 并行转换为 Apache Parquet 文件。第三，它在 Amazon Redshift 集群中创建外部表。现在，查询可以使用 Amazon Redshift 中的数据将大量 Parquet 数据扩展到 S3 中，只需片刻便可返回结果。
上图显示 Spectrify 如何简化 Amazon S3 中的 Parquet 数据查询及 Amazon Redshift 中的数据查询，从而在短时间内返回结果。
Narrativ 的 Amazon Redshift
从 Narrativ 开始创建起，Amazon Redshift 便一直是我们数据仓库的基础。我们使用它来生成流量统计数据，在我们的编程系统中提供数据驱动算法，并将其作为窗口来探索数据见解。Amazon Redshift 已扩展到足以支持公司的需求。我们的集群已从 3 个节点发展到 36 个节点，每小时的查询量显著增加，而性能没有下降。随着我们的工作负载从统计和会计转向数据驱动型见解，Amazon Redshift 与不断增加的查询复杂性保持同步。
在计划下一个数据策略迭代时，我们的要求如下：
- 可由小型工程团队维护（基本不干涉）
- 能够随时查询所有的历史数据
- 能够非常快速地查询前三个月的数据
- 在当前数据量的 10 倍下还能保持性能
我们考虑了几个满足这些要求的想法：
- 升级到 DC2 集群和 DS2 集群
- 升级到很大的 DC2 集群
- 转向开源替代产品（难以维持）
- 转向另一个大数据提供商（进入门槛高、成本高、风险大）
然后，我们发现了 Redshift Spectrum，它通过将计算成本与存储成本分离来改变规则。利用 Redshift Spectrum，我们可以将旧的、不常使用的数据卸载到 S3 中，同时维持规模适度，但速度快的 Amazon Redshift 集群。与其他解决方案相比，Redshift Spectrum 可通过允许我们加入所有查询的同一维度表，从而降低复杂性。最后，它甚至还可以提高/保持性能（取决于具体查询）。通过 Redshift Spectrum，我们的一切要求都可得到满足，并且实现起来简单、快速、经济有效。
接下来，我们将 Redshift Spectrum 视为一项关键工具，可将 AWS 上的数据功能扩展到下一个数量级。Redshift Spectrum 使我们能够定义 Amazon S3 中存储的数据所支持的 Amazon Redshift 表。用此方式，Redshift Spectrum 可将 Amazon Redshift 转变为混合数据仓库/数据湖。在不受计算成本限制的无限存储和 Amazon Redshift 本身的性能和聚合工作流方面，它都能提供最好的选择。
解锁 Redshift Spectrum
使用最佳实践可以为 Redshift Spectrum 提供巨大的性能改进。我们在 GitHub 的开源 Python 库中共享了 Spectrify 实施最佳实践，以帮助别人获得和我们一样的回报。下面是我们对于优化 Redshift Spectrum 的最重要建议的进一步详细信息，这些建议纳入了 Spectrify 中。
使用 Apache Parquet
Apache Parquet 是柱状文件格式。当您将数据存储到 Parquet 时，Redshift Spectrum 只能扩展与您的查询相关的列数据。相比之下，CSV 或 JSON 等面向行的格式需要扫描每一列，与查询与否无关。对于 Narrativ 的工作负载，使用 Parquet 会带来巨大的性能提升并大大降低费用。
柱状格式还支持进行更高效的数据压缩。将相似的数据分组在一起时，数据压缩得更好。在此情况下，我们发现 gzip 压缩的 Parquet 文件比 gzip 压缩的 CSV 减少 80%。这种减少表示数据可以被更快的提取，从而被扫描。
当我们第一次研究将数据转换为 Parquet 时，没有发现适合我们需求的选择。我们没有使用 Spark 或 Hadoop 生态系统中的任何其他项目，它们是创建 Parquet 文件的最常用工具集。几个 Python 项目可对 Parquet 提供写入支持。然而，我们对数据一致性问题持保留态度，尤其是对于可为空值的列。此外，我们没有找到支持正确时间戳格式的库。
我们构建了 Spectrify 来解决所有这些问题。我们对 Apache Arrow 项目进行处理，以确保 Redshift Spectrum 与 Spectrify 生成的 Parquet 文件间完全兼容。
对数据进行分区
Narrativ 将标有时间戳的事件数据存储在 Redshift Spectrum 中。我们按事件创建日期对数据进行分区，从而使 Redshift Spectrum 能够为很多查询跳过大多数数据文件的检查阶段。通常，我们的查询只涉及时域的一小部分，比如一个月甚至仅仅是一天（例如，回答 2017 年黑色星期五的一个具体问题）。查询很少涉及到多年来的整个历史。
这大大减少了扫描的数据量，而且我们看到大多数查询在十分之一的时间内完成。同时，我们的费用也大大降低。单独分区将每个查询的平均成本降低了 20 倍。
小结
在为数据量的数量级增长做准备时，我们转向了使用 Amazon Redshift 和 Redshift Spectrum 在 Amazon S3 上为分析构建的数据湖策略。Redshift Spectrum 使我们能够在 S3 和 Amazon Redshift 间查询数据、维持或提高查询性能并轻松、经济高效地进行查询。在此过程中，我们学到了最佳实践，并将 Spectrify 构建为进一步简化数据准备和分析。我们希望，通过分享代码示例和我们学到的内容，也能帮助您在不断增长的数据中获得类似结果。
有关更多信息，请参见我们的 Spectrify 使用文档和代码示例，及我们在 GitHub 上的完整示例。
其他阅读资源
如果您认为此博文有帮助，请务必读一读 Using Amazon Redshift Spectrum, Amazon Athena, and AWS Glue with Node.js in Production 和 How I built a data warehouse using Amazon Redshift and AWS services in record time。
关于作者
Colin Nichols 在 Narrativ 主导大数据计划。 他喜欢研究系统的交叉点，并且在围绕质量、自动化和持续学习原则塑造工程文化方面具有丰富的经验。 Colin 在业余时间喜欢教他的狗 MacGyver 一些新把戏。