我们有一个包含大约一百万个JSON文件的Amazon S3存储桶,每个文件压缩大约500KB。 AWS Kinesis Firehose将这些文件放在那里,每5分钟写一个新文件。这些文件都描述了类似的事件,因此在逻辑上都是相同的,并且都是有效的JSON,但具有不同的结构/层次结构。他们的格式和&行结尾不一致:一些对象在一行上,一些在多行上,有时一个对象的末尾与另一个对象的开头在同一行(即}{
)。
我们需要解析/查询/粉碎这些对象,然后将结果导入我们的本地数据仓库SQL Server数据库。
Amazon Athena无法处理不一致的间距/结构。我想创建一个可以清理间距的Lambda函数,但仍然存在不同结构的问题。由于文件是由Kinesis制定的,这迫使你将文件放在按年,月,日和小时嵌套的文件夹中,我们每年必须创建数千个分区。雅典娜分区数量的限制并不为人所知,但研究表明,如果我们每小时创建一个分区,我们很快就会用尽这个限制。
我看过先将数据泵入Redshift然后将其拉下来。 Amazon Redshift外部表可以处理间距问题,但无法处理嵌套的JSON,这几乎所有这些文件都有。 COPY
命令可以处理嵌套的JSON,但要求我们事先知道JSON结构,并且不允许我们访问文件名,这是完全导入所需的文件名(这是我们获取日期)。通常,Redshift与Athena具有相同的问题:不一致的结构使得定义模式变得困难。
我已经研究过使用像AWS Glue这样的工具,但他们只是移动数据,他们无法将数据移动到我们的内部部署服务器上,所以我们必须找到某种中介,这会增加成本,延迟,和维护费用。
我已经尝试删除中间人并使用ZappySys的S3 JSON SSIS任务直接提取文件并将它们聚合在一个SSIS包中,但它无法处理间距问题或不一致的结构。
我不能成为第一个面对这个问题的人,但我只是继续旋转我的车轮。
答案 0 :(得分:1)
我可能会建议两种类型的解决方案
除非JSON格式正确,否则没有工具可以完美地处理它,我相信比Athena或Spectrum更多,MongoDB / DyanoDB / Cassandra将适合这个用例
如果您可以分享在创建大量分区时遇到的限制,那会很棒吗?
答案 1 :(得分:1)
Rumble是开放源代码(Apache 2.0)引擎,它允许您使用JSONiq查询语言直接查询存储在S3上的JSON(特别是JSON Lines文件),而无需必须将其移动到其他位置或将其导入任何数据存储。在内部,它使用Spark和DataFrames。
它已经成功测试了超过200亿个对象(超过10 TB)的集合,并且如果数据是嵌套且异构的(丢失字段,额外字段,同一字段中的不同类型等),它也可以无缝运行。还在Amazon EMR集群中进行了测试。