我在为我的系统设计数据流时有点头疼。问题如下：我们正在收到关于Kafka主题的活动。从那里我们设置Kafka连接到s3接收器连接器。所以我们的目标是把Kafka的事件写在s3上。但最重要的是，我们需要使那些s3文件可查询。所以我们决定对s3上编写的事件使用.parquet文件格式，并使用“snappy”作为压缩器。此外，我们在文件中有相同的数据格式（使用“string_1”等通用字段，…”字符串“\”）。因此，我们决定在kafka connect中添加一些代码来管理胶水元数据—使文件可查询。因此，整个事件流被分组到glue上的数据库和表中（基于两个字段）。我们还将s3上的文件拆分为“类似配置单元”的分区，例如“field\u name=field\u value”。所有这些分区也在glue中定义。所以，在s3的新分区中添加文件时，我们将分区值添加到粘合表的分区中。
到目前为止，一切正常。由于使用了分区，我们在s3和glue上有很好的文件分离。因此，查询应该执行得很好。但是，这种方法有一个问题：根据文档，“parquet”的最佳文件大小不小于128mb。因此，我们计划将s3上的文件压缩为更大的文件（具有更少的更大文件），以提高查询的性能。另外，请记住，我们希望通过使s3上的持久化事件可查询（通过向粘合表中添加分区值），实现接近实时的数据访问。我的考虑从这里开始：如果我们想将分区中的文件“压缩”为更小更大的文件，那么一些分区将足够大，至少可以构建128MB的文件，但大多数分区不会。所以我想知道什么能给我们带来更好的结果：
现在就拥有它，这将导致良好的分区数据，但具有较小的Parquet文件（<128 mb）的优势，或者：
更改文件在s3和glue中的分区方式，以始终实现不小于128mb的Parquet文件。这很可能会导致glue中s3上更糟糕的分区数据。
这两种方法的混合。。。
注意，当前的分离是在最后如何查询数据上完成的，所以这是“逻辑的”。另一种方法可能会改变这一点。问题是什么能给我们带来更好的结果？更少的更大的文件但没有根据我们的查询进行有效分区，这将比分区良好但文件大小低于128 mb的数据性能更好？？请建议！