Redshift 时间序列表加载问题答案

【问题标题】：Redshift time-series table loading questionsRedshift 时间序列表加载问题
【发布时间】：2017-02-14 03:20:42
【问题描述】：

但是，它没有解决以下任何问题：

我的情况：

我提出的解决方案：

使用 union all 视图创建一年的每日表，以及 sensor_id 的 dist_key（100,000+ uniq 值）和（timestamp、sensor_id）的 sort_key。
将消防软管加载到临时表中
创建一个单独的进程，每小时查询一次临时表以发现表中数据的日期，然后执行插入到“适当的表”中 select * from where timestamp = table's timestamp。
这个按小时编写的作者可能会将表重命名、多个插入选择和表重新创建包装在一个事务中，以使 firehose 不可见。
每月删除一次旧表，创建下个月的表，然后重建视图。
这种联合所有视图维护可能包含在事务中以避免对用户产生影响。
每晚运行一次真空分析仪。

编辑：添加了说明哪些问题已得到解答的注释，并为建议的解决方案添加了一些细节。

【问题讨论】：

我目前正在与类似的事情作斗争。你跟它过去了吗？你的经验是什么？对执行 UNION 的性能影响的任何见解，例如30 个表（一个月的数据量）？
我没有实现时间序列表——事实上我对这个功能非常失望：亚马逊的文档完全不够，看起来你得到零分区的好处，但它使查询计划更加困难，并且直接和简单的负载（比如从消防软管）是不可能的。唯一的好处是滚出数据，也许是分析和吸尘。到目前为止，我的解决方案是暂时忽略问题并评估雪花。
我感觉到你了。他们将其作为 PB 级仓库进行营销。我想知道 PB 级的真空吸尘器是如何工作的 :) Snowflake 似乎很有趣。您是否尝试过 BigQuery？它对分区有很好的支持（至少在文档中）。
我遇到了同样的问题并试图找出最好的方法。如果您能分享您的经验，那就太好了。
我同意 KenFar 的观点，即时间序列表如果连接到某些蒸汽输入（例如 firehose）则不值得付出努力，处理插入将很困难且容易出错。

【解决方案1】：

您提出的流程听起来不错！虽然我无法回答您的所有问题，但这里有一些信息：

写入 union-all 视图并让 redshift 将这些插入定向到正确的基础表的任何方法？

视图是只读的。无法写入视图，也无法插入数据同时期望 Redshift 将其发送到适当的表（例如，给定日期的特定表）。

在查询 union-all 视图时，如果它们的日期范围超出查询条件，是否有任何方法可以启用 redshift 以消除一些底层分区（表）？

Redshift 不会从查询中排除特定表，但它会通过使用区域地图避免读取特定磁盘块。写入磁盘的每个数据块都与特定的表和列相关联。该块有一个区域图，它指示存储在块中的该字段的最小值和最大值。

如果查询包含WHERE 子句，Redshift 可以跳过不包含相关数据的块。这在SORTKEY 列上使用时特别强大，因为相似的数据范围被组合在一起。

假设您使用日期作为SORTKEY，如果查询包含基于该列的WHERE 子句，Redshift 将读取很少的磁盘块。这和跳过表的想法很相似，但实际上是跳过了读磁盘块。

【讨论】：