我们最终选择了Redshift，这是一个基于AmazonWebServices的数据仓库服务，增强了我们的交互式分析能力，每天以最快的速度导入数亿条数据记录到确保核心数据源的可用性。Redshift是一个很棒的解决方案，可以在几秒钟内回答问题以实现交互式数据分析和快速原型制作（而Hadoop和Hive用于每天处理TB级数据，只需几分钟或几小时内回答）。看看我们使用Redshift的感受：包括挑战和回报，这只是亿万系统的一个缩影。Pinterest使用Redshift实现强大的交互式数据分析。Redshift易于上手且相当可靠。但是，面对PB级的海量数据和快速扩张的组织，我们在生产环境中使用Redshift会面临一些问题。有趣的挑战。挑战一：创建一个100TB的ETL来完成从Hive到Redshift的转换。Hive中有数TB的数据。我们花了一些时间来思考一个最佳实践，如何将100TB的核心数据导入到Redshift中。Hive中的数据格式多种多样，有rawjson、Thrift、RCFile等，都需要用flat的方式转成文本文件。我们用Python编写了模式映射脚本，生成Hive查询来处理重量级ETL。在Hive中，大多数表都是时间序列数据，并按日期进行分片。为了保证最好的结果，我们使用日期作为排序键，每天向每个表追加数据，从而避免了高成本的VACUUM操作。另一种方式是每天使用一张表，通过视图关联起来，但是我们发现Redshift并没有很好的视图查询优化机制（比如不能下推LIMIT）。加载一个大的快照表也是一个挑战。我们最新的表db_pins包含200亿个Pin，这在规模上远远超过10TB的数据。将它加载到快照表中会导致昂贵的分片和排序，因此我们在Hive中进行大量分片并逐块加载到Redshift中。由于Redshift只有有限的存储空间，我们使用表预留的方式来处理大数据时序表，周期性的往Redshift中运行插入查询，将有限的数据复制到新表中，这样会更快删除行要快很多然后进行昂贵的冲洗，或者删除整个表并重新导入。也许最大的挑战来自于S3的最终一致性。我们发现Redshift有时会出现严重的数据丢失现象，然后追溯到S3的问题。我们通过绑定一些小文件来减少S3上的文件数量，从而减少数据丢失。我们还在ETL的每个步骤中添加了审计，因此数据丢失率现在通常低于可接受的0.0001%。挑战2：使用Hives获得100倍的加速，而不是RedshiftRedshift本质上是高性能，这使得原型中的一些查询使用Hive获得50-100倍的加速成为可能，但是一旦进入生产环境，它并不总是符合预期的性能，因为它进行了测试。在早期的测试中，我们发现一些查询时长长达数小时，调试性能问题非常棘手，需要收集查询计划、查询执行统计等，但最终没有出现明显的性能问题。从中得到的教训是，每当更新系统统计数据时，都需要准备数据，因为这将极大地影响优化工作。为每个表选择一个好的sortkey和partitionkey，一个sortkey会比较容易，但是一个不好的partitionkey会扭曲并影响系统的性能。下面是Hive和Redshift集群的基准测试结果，基于db_pins（200亿行，每行50列，总大小10TB）和一些其他核心表。请记住，这些比较不包括集群大小、资源争用和其他可能的优化机制，因此这些比较根本不科学。Pinterest使用Redshift实现强大的交互式数据分析。我们还发现了一些常识性错误，总结了我们的最佳实践，并创建了实时监控慢速查询的工具。任何超过20分钟的时间都被认为是可疑的，并提醒工程师审查我们遵循的最佳实践。Pinterest使用Redshift进行强大的交互式数据分析也许最常见的错误是倾向于在select子句中放置诸如“Select*”之类的东西，这不利于列存储，因为它需要扫描所有非必要的列。挑战3：管理对不断增长的查询/用户的争用。由于其良好的性能，经过我们的配置，Redshift在Pinterest中得到了广泛的应用。我们是一个快速发展的组织，越来越多的人有兴趣并行使用Redshift。由于大量查询争夺资源，导致查询速度明显下降。昂贵的查询会消耗大量资源并显着影响其他并行查询，因此我们需要制定规则以尽量减少争用。我们避免在高峰时段（上午9点到下午5点）进行重量级ETL查询。ETL查询和COPY一样，会占用大量的输入输出和网络带宽。为保证用户交互查询，这些时间段应避免ETL查询。我们优化ETL管道以在高峰时间之前完成，或者暂停管道并在高峰之后恢复。甚至，用户交互查询在高峰时段被暂停。可能包含错误的长查询将立即停止，而不是让它浪费资源。目前我们搭建了16个hs1.8xlarge性能的节点。Pinterest上通常有100个用户同时使用Redshift，我们每天运行300到500个交互式查询。由于许多查询可以在几秒钟内完成，因此整体性能超出了我们的预期。以下是上周交互式查询的持续百分比。我们可以看到75%的查询可以在35秒内完成。Pinterest采用Redshift进行强大的交互式数据分析因为我们已经成功地使用了Redshift，所以我们将继续将它集成到我们的下一代工具中。如果您对此类挑战感兴趣并且拥有快速、可扩展的方法，请加入我们的团队。
