非结构化数据存储选型咨询：AWS S3构建NoSQL数据湖场景

针对你在AWS S3上构建无Schema、包含混合类型对象（比如{a:2}或者嵌套结构{b:2,c:4, a: [1,2]}）的数据湖需求，除了JSON之外，还有几个非常实用的存储选项，结合你的场景给你梳理一下：

• Parquet/ORC（列式存储格式）：别以为列式存储只能配合固定Schema用，它们其实对Schema演化和混合类型支持很好。比如Parquet天生支持嵌套结构，能完美存储你提到的嵌套对象，而且压缩比远高于JSON，查询性能也强很多——毕竟列式存储只读取需要的字段。AWS的Athena、Glue、Redshift都原生支持这两种格式，哪怕你的数据字段时有时无、类型多变，只要开启Schema演化（比如Glue爬虫自动识别），就能轻松处理这些混合结构。

• Avro：这货简直是为动态Schema场景量身定做的。它的Schema可以和数据绑定存储，也可以单独存在Schema Registry里，天生支持字段新增、类型变化和嵌套结构。Avro的序列化效率比JSON高，文件体积更小，而且AWS生态里的Glue、Kinesis、EMR等服务都能无缝兼容。如果你的数据Schema经常变动，或者需要保留不同版本的结构，Avro会是比JSON更优的选择。

• Apache Iceberg/Hudi（Lakehouse表格式）：如果你需要在数据湖上做更复杂的操作（比如更新、删除数据，或者做增量同步），同时还要支持灵活的Schema，这两个表格式就很合适。它们底层用Parquet/ORC作为存储格式，但在S3之上封装了一层表管理能力，支持Schema演化、ACID事务、时间旅行等特性。AWS Glue已经原生支持Iceberg，Hudi也能通过EMR或者自定义集成在S3上运行，非常适合需要兼顾灵活性和数据治理的场景。

• AWS DocumentDB：如果更倾向于直接用NoSQL文档数据库的方式管理数据，DocumentDB是兼容MongoDB的托管服务，它可以和S3联动做数据备份或者导出到数据湖，也可以直接作为数据湖的一部分来存储你的混合类型文档。它天然支持BSON格式（二进制JSON），能直接处理嵌套、缺失字段、混合类型的对象，而且提供了成熟的查询能力，不需要额外转换格式就能直接操作数据。

• Raw BSON文件：如果不想用托管数据库，直接在S3上存储BSON文件也是个选项。BSON是MongoDB的二进制序列化格式，比JSON更紧凑，还支持更多原生数据类型（比如日期、二进制数据）。后续你可以用MongoDB工具或者AWS Glue来解析这些BSON文件，处理起来和JSON一样灵活，但存储效率更高。

最后给个小建议：如果看重压缩率和查询性能，优先选Parquet/ORC+Schema演化；如果Schema变动频繁，Avro更适配；如果需要事务和数据更新能力，Iceberg/Hudi是首选；如果想要开箱即用的文档查询体验，DocumentDB会更省心。

内容的提问来源于stack exchange，提问作者Manish Trivedi