您没有指定一个重要参数：收集数据点后多长时间您需要能够查询它？换句话说，如果您像描述的那样对特定分钟进行统计，您希望能够以多快的速度运行该查询？如果在一分钟、五分钟、30 分钟或几小时内完成，那么在如何构建解决方案方面会产生巨大的差异。
Kinesis Firehose 有一个缓冲区，您可以使用该缓冲区调整传送到 S3 的文件的大小。您可以设置文件大小和时间的目标，以便缓冲区在达到特定大小或其中最旧的数据点达到特定年龄时写入。更大的文件大小更适合分析，但代价当然是它会在数据流中引入延迟。
Kinesis Data Firehose 具有Record Format Conversion 功能，可以将传入的 JSON 数据即时转换为 Parquet 或 ORC。一般来说，列格式更适合分析，因为它们允许在读取时跳过列，它们进行压缩，并允许在某些情况下跳过块。对于您的用例，它可能会产生比 JSON 更小的文件，并且由于数据是按时间大致排序的，因此当您查找特定分钟或特定设备时，Athena 将有机会跳过大块文件。对于不查看设备的查询，也不必读取该列。 （请注意，理论上 Parquet 和 ORC 都是如此，但在实践中我对 ORC 和 Athena 的运气并不好，如果你尝试请向我报告，但如果你没有时间去Parquet，因为根据我的经验，在 Athena 中它更好地兑现了这些承诺）。
使用记录格式转换的缺点是您必须缓冲更长的时间，目标文件大小比常规交付要大得多。这是有道理的，因为您不想拥有很多小的 Parquet 文件，它不会给您带来任何好处。
Kinesis Data Firehose 提供按小时分区的文件，这意味着您可以通过为每个 …/YYYY/MM/DD/ 前缀或每个 …/YYYY/MM/DD/HH/ 前缀添加分区来创建具有仅涵盖日期或包含小时的分区键的 Athena 表（表的分区键不必与 S3 前缀的“目录”匹配，你不需要三个或四个分区键，你只需要一个，它要么只涵盖日期，要么涵盖日期和小时）。我会使用Partition Projection 来避免手动添加分区（这里是an example on how to configure it for Kinesis Data Firehose data sets，它使用覆盖小时的分区键）。
是否选择涵盖日期或日期和时间的分区键取决于您最常见的查询。如果您提到的几乎所有查询都是查看特定分钟的查询，那么为每个小时前缀进行分区是最有意义的。使用该设置，Athena 将能够跳过所有分区，但该分钟所属的分区除外，然后它将能够跳过读取该分区内的大量数据，因为它将按时进行粗略排序，并且 Parquet 保留足够的元数据以知道哪些块包含每列的哪些范围。
我不确定你上一个关于 Glue 的问题是什么意思。希望您应该能够避免在此架构中完全使用 Glue（如果我们不计算 Glue 数据目录）。
是否使用记录格式转换取决于我们正在讨论的数据量以及查询数据的速度。如果您需要能够几乎立即查询它，那么您不能缓冲很长时间，并且您几乎绝对不能使用记录格式转换，除非数据量很大（一百万个数据点有两个数字，比如 16 个字节，将需要几分钟来填充最小文件大小，并且压缩时间更长）。
如果您不进行记录格式转换，每个查询的成本都会更高，但您将能够更快地运行查询——这可能是值得的。