层式结构，简化了文档中有关数据的存储，以及复杂关系的表示问题。 大多数编程语言都能够提供简化的JSON序列化库，并且能够对JSON序列化/反序列化提供内置的支持。 JSON支持对象列表，能够有助于避免将对象列表错误地转换为关系型数据模型。 诸如MongoDB、Couchbase和Azure Cosmos DB等NoSQL数据库，都能够支持JSON文件格式。 目前大多数工具都内置了对于JSON的支持。 
3、Parquet
Cloudera和Twitter于2013年开发出了Parquet。它可以被用作基于列的存储格式，并针对多列数据集进行了适当地优化。由于其数据是按列进行存储的，因此它可以对数据进行高度压缩(其压缩算法对于那些包含在列中的、信息熵值较低的数据，效果会更好)，以及拆分操作。Parquet的开发者号称：此类存储格式非常适合于处理大数据的相关问题。
与CSV和JSON不同，Parquet是一种二进制文件，其中包含了各种针对其内容的元数据(metadata)。因此，在无需读取与解析文件内容的情况下，Spark可以仅依靠元数据来确定文件中的列名称、压缩/编码方式、数据类型、乃至一些基本的统计类信息。另外，由于Parquet文件的列相关元数据通常被存储在文件的末尾，因此方便了用户一次性快速地写入信息。同时，Parquet针对WORM(Write Once Read Many，一次写入多次读取，请参见)的范例也进行了优化。虽然在写入文件其速度较慢，但是用户在读取时，尤其是仅访问某个列的子集时，速度却快得惊人。可见，对于那些需要大量进行读取操作的工作负载而言，Parquet是一种不错的选择。而对于需要操作整行数据的用例而言，用户则应当使用CSV或AVRO之类的格式。
Parquet在数据存储方面的优点包括：  由于是一种柱状结构的形式，因此Parquet只会读取所需的列信息，进而减少了对于磁盘I/O的消耗。这个概念被称为投影下推(projection pushdown)。 由于schema是随着数据一起移动的，因此数据能够自我描述(self-describing)。 虽然主要是为HDFS而创建的，但是其数据完全可以被存储在GlusterFs或NFS之类的其他文件系统中。 作为一个文件，您可以轻松地对Parquet进行移动、备份、复制、以及使用。 能够对Spark提供开箱即用式的原生支持，能够对于用户存储中的文件直接进行读取与保存。 当采用诸如snappy之类的压缩格式时，Parquet可以达到75%的高压缩比。 在实际运用中，与同类其他文件格式相比，该格式读取工作流的速度最快。 Parquet非常适合于那些需要对大量数据进行列汇总的数据仓库类应用。 可以通过Avro API和Avro Schema来读取和写入Parquet。 通过提供谓词下推(predicate pushdown)，Parquet可以进一步降低磁盘I/O的成本。 
谓词下推/过滤下推
谓词下推的基本思想是：将查询的某些部分(如：谓词)“推送”到数据的存储位置。例如，当我们提供一些过滤条件时，数据存储将会以过滤记录的方式，再从磁盘中读取数据。
谓词下推的优点：由于不再需要将整个数据读入内存并进行过滤，因此它并不需要大量的内存，也不会产生过多的磁盘I/O。显然整体性能得到了显著提升。
可见，此类方法可以通过较早地过滤掉无关数据的方式，来大幅减少查询与处理的时间。根据处理框架的不同，谓词下推可以通过执行不同的操作来优化查询。例如：在通过网络传输之前便过滤数据，在将数据加载到内存之前过滤数据，或是跳过读取整个文件(文件块)等操作。
目前，大多数RDBMS，包括Parquet和ORC等大数据存储格式，都能够遵循谓词下推的相关概念。
投影下推 
 
投影下推的基本思想是：在对存储进行数据查询与读取时，并非读取所有字段，而只是读取那些必需的列。通常，Parquets和ORC之类的列格式都能够通过遵循此概念，以产生更好的I/O性能。
4、Avro
由Hadoop工作组于2009年发布的Apache Avro，