AWS IOT分区设计

如何解决AWS IOT分区设计

问题：每分钟有100万个温度监控IOT设备发送温度数据。

我们需要查询此数据以获取给定HH：MM的最低，最高，平均温度，或者过滤特定设备或所有设备。

如果你们中的任何人已经实现了物联网分析，那么高层架构将是什么样？这就是我的想法：

IOT-> Kinesis-> S3-> ATHENA / REDSHIFT

每个设备都可以发送简单的json数据： {“ device_id”：“ 101”，“温度”：“ 65.4”}

问题：

1. 由于我们正在执行汇总查询，我应该使用Parquet这样的列数据格式吗？但是它可以用于快速的数据提取吗？并能快速查询按特定设备过滤的查询吗？

2. 分区键应在哪一列？我的猜测是时间戳，因为WHERE子句位于YY：DD：HH：MM？ json是否应将时间戳记作为一列？

3. 如果是，那么GLUE模式的时间戳分区如何与已经由YYYY-MM-DD-HH分区的S3配合？

解决方法

您没有指定一个重要的参数：收集数据点后需要多长时间才能查询它？换句话说，如果您像描述的那样对特定分钟进行统计，那么您期望多久才能运行该查询？如果在一分钟，五分钟，三十分钟或几小时之内，则在架构解决方案的方式上将有很大的不同。

Kinesis Firehose具有一个缓冲区，您可以使用该缓冲区调整交付给S3的文件的大小。您可以设置文件大小和时间的目标，以便一旦缓冲区达到某个大小或该缓冲区中最旧的数据点达到一定的期限，就将其写入。较大的文件大小更适合分析，但要权衡的地方是它会导致数据流延迟。

Kinesis Data Firehose具有Record Format Conversion功能，可以将传入的JSON数据即时转换为Parquet或ORC。通常，列式格式更适合分析，因为它们允许在读取时跳过列，进行压缩并在某些情况下允许跳过块。对于您的用例，它可能导致生成的文件比JSON小，并且由于数据按时间粗略排序，因此当您查找特定的分钟或特定的设备时，Athena将有机会跳过文件的大块。对于不查看设备的查询，也不必读取该列。 （请注意，从理论上讲，这对于Parquet和ORC都是正确的，但是在实践中，我对ORC和Athena的运气并不好，如果尝试的话，请给我报告，但是如果您没有时间实木复合地板，因为在雅典娜，根据我的经验，它可以更好地兑现这些承诺。

使用“记录格式转换”的缺点是您必须缓冲更长的时间，目标文件的大小比常规传递的大得多。这是有道理的，因为您不想有很多小的Parquet文件，但不会有任何好处。

Kinesis Data Firehose提供按小时分区的文件，这意味着您可以通过为每个…/YYYY/MM/DD/前缀或每个{{ 1}}前缀（表的分区键不必与S3前缀的“目录”匹配，您不需要三个或四个分区键，只需要一个即可，它可以只覆盖日期或日期和小时）。我将使用Partition Projection来避免手动添加分区（这里的an example on how to configure it for Kinesis Data Firehose data sets使用覆盖整个小时的分区键）。

选择覆盖日期还是日期和小时的分区键取决于您最常见的查询。如果您提到的几乎所有查询都是针对特定分钟的查询，那么对每个小时前缀进行分区是最有意义的。通过该设置，Athena将能够跳过所有分区，但只有一分钟属于该分区，然后它将能够跳过读取该分区内的许多数据，因为它将大致按时间排序，并且Parquet保留了足够的元数据知道说哪些块包含每一列的范围。

我不确定您关于胶水的最后一个问题是什么意思。希望您应该能够完全避免将Glue用于这种体系结构（如果我们不计算Glue数据目录的话）。

是否要进行“记录格式转换”取决于我们正在讨论的数据量以及需要多长时间才能查询它。如果您需要能够几乎立即查询它，就不能缓冲很长时间，并且几乎可以肯定不使用记录格式转换，除非数据量很大（一百万个数据点有两个数字，例如16个字节，将需要几分钟的时间来填充最小文件大小，并且压缩时间更长。

如果不进行“记录格式转换”，则每个查询的费用都会更高，但是您可以更快地运行查询-这可能是值得的。