我们有一个Amazon S3桶，里面有大约100万个JSON文件，每个文件的压缩量在500KB左右。这些文件是由AWS Kinesis Firehose放进去的，每5分钟写一个新文件。这些文件都描述了类似的事件，所以在逻辑上都是一样的，都是有效的JSON，但有不同的结构/层次。此外，它们的格式和行尾也不一致：有些对象在一行，有些在多行，有时一个对象的结尾与另一个对象的开头在同一行（即
}{
）。
我们需要解析/查询/粉碎这些对象，然后将结果导入我们内部数据仓库的SQL Server数据库。
Amazon Athena无法处理不一致的间隔/结构。我想过创建一个Lambda函数来清理间距，但这仍然留下了不同结构的问题。由于文件是由Kinesis铺设的，它迫使你把文件放在按年、月、日、小时嵌套的文件夹中，所以我们每年都要创建成千上万的分区。Athena的分区数量限制并不为人所知，但研究表明，如果我们每小时创建一个分区，很快就会耗尽这个限制。
我曾研究过先把数据泵入Redshift，然后再把它拉下来。亚马逊Redshift的外部表格可以处理间距问题，但不能处理嵌套的JSON，而这些文件几乎都有。
COPY
命令可以处理嵌套的JSON，但要求我们事先知道JSON结构，而且不允许我们访问文件名，而我们需要完整的导入（这是我们获得日期的唯一途径）。总的来说，Redshift和Athena有同样的问题：不一致的结构使其难以定义模式。
我曾研究过使用AWS Glue等工具，但它们只是移动数据，而且不能将数据移动到我们的内部服务器中，所以我们必须找到某种中介，这增加了成本、延迟和维护开销。
我曾尝试切断中间人，使用ZappySys的S3 JSON SSIS任务来直接提取文件，并在SSIS包中汇总，但它无法处理间隔问题或不一致的结构。
我不可能是第一个面临这个问题的人，但我只是一直在旋转我的车轮。
