用于仲裁的AWS Glue表Map数据类型的字段数和面临的挑战

如何解决用于仲裁的AWS Glue表Map数据类型的字段数和面临的挑战

我们正在一个Data-Lake项目中，并且我们正在从cloudwatch日志中获取数据，然后将通过Kinesis服务将其发送到S3。一旦进入S3，我们需要创建一个表以通过Athena查看数据，我们有JSON文件。我们有3个字段，一个是时间戳，另一个是属性，这又是一个对象，可以容纳任意数量的字段，并因情况而异，因此在创建表时，我将其定义为map<string,string> ，基于一些研究和建议。现在的挑战是在通过雅典娜查询时，它总是说肯定有数据时返回零记录。为了确认这一点，我这次通过搜寻器创建了一个表，并且能够通过Athena查看数据，但是唯一的区别是，属性列定义为其中具有特定字段的struct，但是其中手动表具有{{1} }处理进入的任意文件。感谢您提供任何帮助找出与此相关的根本原因。谢谢。

下面是位于S3中的示例JSON行。

map<string,string>

解决方法

返回的零记录通常意味着表的位置错误，或者您具有分区表但未添加任何分区。我认为如果是前者，您会想出来的，所以我怀疑是后者。运行搜寻器时，除创建表外，它还将添加找到的分区。

如果您需要添加分区的帮助，请编辑问题并提供有关如何在S3上构造数据的示例。

在这种情况下，使用Glue搜寻器可能无法很好地工作，它将很难找出properties列的架构，而且永远也做不成。 Glue搜寻器通常在不太基本的事情上表现很差（有关Glue无法解决的用例，请参见this question）。

我认为使用手动创建的表会很好，该表使用map<string,string>作为properties列的类型。当您知道属性的类型并希望将其用作该类型时，只需在查询时强制转换值即可。一种替代方法是使用string作为类型，并使用JSON functions在查询时提取值。