big-data-format
CSV
CSV文件（逗号分割不同列的值）常被使用普通文本格式的系统用作交换它们的表格数据。CSV是基于行的文件格式，这意味着文件中的每行数据都对应于表格的一行。总的来说，CSV包含一个头部行，它为数据提供列的名称。不然的话，这些文件会被认为是半结构化。起初，CSV文件不能表示层级或关系型数据。数据之间的关联基本是通过多个CSV文件来实现。一个或多个文件中都会在列中存储外键，但是CSV格式本身并不能表达这些文件之间的关系。而且，CSV格式并没有完全标准化，可以使用除逗号之外的其他分隔符，比如制表符和空格。
优点：
- CSV易于人们理解和手动编辑；
- CSV提供了简单易懂的信息格式；
- 几乎所有现存的系统都可以处理CSV；
- CSV易于实现和解析；
- CSV格式紧凑。在XML中，每行数据的每列都需要开始和结束标签。在CSV中你只需要写一次列头信息。
缺点：
- CSV只能处理扁平化的数据。复杂的数据结构需要额外处理；
- 不支持设置列的数据类型。文本类型的列和数字类型的没有任何区别；
- 没有标准方式表示二进制数据；
- CSV的导入问题（不区分NULL和“null”引用）（译者语：CSV空列在导入时会变成字符串“null”）
- 对特殊字符的支持很差
- 缺少标准
JSON
Json数据（JavaScript object notation，即JavaScript对象符号）在一个部分结构化的格式中被表示成一系列键值对。因为可以以层级格式存储数据，所以JSON常被和XML做对比。孩子数据由双亲数据负责呈现。两种格式都是自描述的，并且方便用户阅读理解，但是通常情况下JSON文档会小很多。因此，它们被越来越多的用于网络通讯，特别是伴随着基于REST网络服务的出现。
优点
- JSON支持层级结构，简化了在一个文档中存储关联数据和展示复杂关系的难度；
- 大多数语言提供了简化JSON序列化的工具库，或内建支持JSON序列化/反序列化；
- JSON支持对象列表，帮助避免列表转换成关系型数据模型时的不确定性；
- JSON是一种被NoSQL数据库广泛使用的文件格式，比如MongoDB，Couchbase和Azure Cosmos DB；
- 目前大部分工具都内置支持JSON。
Parquet
Parquet于2013年面世，由Cloudera和Twitter开发，用来作为列存储的格式，对多列数据集做了优化。由于数据是按列储存，所以它可以被高度压缩（压缩算法在低信息熵的数据中表现更好，而列数据通常正是如此）而且具有良好的可拆分性。该格式的开发者声称这种存储格式是解决大数据问题的理想方案
不像CSV和JSON，Parquet文件是二进制文件，包含描述内容的元数据。所以，不需要读取/解析文件内容，Spark仅仅依赖元数据就可以确定列的名称、压缩/编码信息、数据类型甚至一些基本的统计数据。Parquet文件列的元数据存储在文件的尾部，这样允许快速的、一次性写入。
Parquet针对一次写入，多次读取特性做了优化。它写入慢，但是读取特别快，特别当你只访问全部列的一部分时。有大量读取工作时，Parquet是个好选择。对于需要对整行数据处理的场景，你需要使用类似CSV或者AVRO格式
优点：
- Parquet是列式格式
只有被需要的列会被获取/读取，降低了磁盘I/O。这个概念被称为投影下推（译者语：原文projection pushdown） - Schema和数据在一起，所以数据是自描述的
- 尽管它最初是为HDFS创建的，但是数据也可以存放在其他文件系统中，比如GlusterFs或者NFS；
- Parquet只是一些文件，这意味着很容易移动、备份和复制它；
- 在Spark中原生支持，开箱即用，能够很简单的获取和存储文件到你的存储中
- Parquet提供优异的压缩功能，当使用类似snappy压缩格式时，压缩比高达75%
- 实践表明，和其他文件格式相比，该格式读取速度最快
- Parquet非常适合要对海量数据的特定列做汇总的数据仓库
- 可以使用Avro API和Avro Schema读取和写入Parquet（这允许使用Avro格式存储原始数据，但是使用Parquet处理数据
- 它也支持谓词下推（译者语：原文是predicate pushdown），因此可以进一步降低磁盘I/O开销
Avro
Apache Avro是由Hadoop工作组于2009年发布。它是基于行的格式，并且具备高度的可分拆性。它也被描述为一个类似Java序列化的数据序列化系统。它的schema存储在JSON格式中，但是数据以二进制方式存储，以求文件尺寸最小同时效率最高。通过管理新增字段、缺失字段和被修改的字段，Arvo为schema进化提供了强大的支持。这允许老系统读取新的数据，也允许新系统读取老数据--如果你的数据可能会更改，这会是非常重要的特性。
借助Avro管理schema进化的能力，我们可以在不同时间独立地更新各个组件，并且不兼容的风险很低。这让应用避免使用if-else语句处理不同的schema版本，也让开发者避免查看老代码来理解老的schema。因为所有版本的schema都存储在易于人们阅读理解的JSON头部，所以你很容易理解所拥有的全部字段。
很多不同语言都支持Avro。因为schema存储在JSON中，但是数据存储为二进制，所以Avro在持久化数据存储和数据传输中都是相当紧凑的方案。Avro是写入很多场景的首选方案，因为它可以很容易在尾部添加新行
优点：
- Avro是语言中立的数据序列化方案；
- Avro在文件头部存储schema，所以数据是自描述的；
- Avro格式的文件既可拆分又可压缩，因此是Hadoop生态系统中文件存储的好选择；
- 读Avro文件使用得schema不用和写文件所用的schema一样。这使得我们可以独立的添加新字段；
- 和Sequence Files（译者语：一种Hadoop的文件格式）一样，Avro文件也包含用来分隔块的Sync标识符。这使得它有高度可分拆性；
这些块可以使用类似snappy这样的压缩格式压缩。
ORC
全称是(Optimized Row Columnar), ORC文件格式是一种Hadoop生态圈中的列式存储格式，它的产生早在2013年初，最初产生自Apache Hive，用于降低Hadoop数据存储空间和加速Hive查询速度。和Parquet类似，它并不是一个单纯的列式存储格式，仍然是首先根据行组分割整个表，在每一个行组内进行按列存储。ORC文件是自描述的，它的元数据使用Protocol Buffers序列化，并且文件中的数据尽可能的压缩以降低存储空间的消耗，目前也被Spark SQL、Presto等查询引擎支持，但是Impala对于ORC目前没有支持，仍然使用Parquet作为主要的列式存储格式。2015年ORC项目被Apache项目基金会提升为Apache顶级项目。
优点:
- ORC是列式存储，有多种文件压缩方式，并且有着很高的压缩比。
- 文件是可切分（Split）的。因此，在Hive中使用ORC作为表的文件存储格式，不仅节省HDFS存储资源，查询任务的输入数据量减少，使用的MapTask也就减少了。
- 提供了多种索引，row group index、bloom filter index。
- ORC可以支持复杂的数据结构（比如Map等）
每种格式的空间占用
space-per-format
每种格式的写入延迟
ingestion-latency
每种格式的随机读取延迟
random-data-lookup
基本统计操作耗时
basic-statistics
每种格式的数据处理耗时
processing-latency
从性能测试中学到得
- CSV写入速度最快，JSON最易于人们阅读，Parquet在读取列的子集时最快，而Avro在一次读取所有列时最快。
- JSON是web通讯的标准。由于它们拥有类似定义良好schema等的可用性，API和网站始终使用JSON通讯；
- Parquet和Avro确实为应对大数据的需求做了更多的优化--可拆分性，支持压缩，复杂数据结构的支持。但是可读性和写入数独相当糟糕；
- 在Parquet和Avro中，可以并发访问的最小数据单元是HDFS的文件块--因为有它，我们可以轻而易举的平均分配处理流程到Hadoop集群中的可用资源中；
- 当你要在Hadoop中选择数据存储格式时，你需要考虑很多因素，比如和第三方应用的对接、scheme进化、支持特殊的数据类型...但是如果对你来说性能是第一位的，那么上面的测试表明Parquet是你最好的选择（译者语：小心这种不够完善的基准测试，还是要在你自己的环境中做大量细致的性能测试）；
- 压缩算法在减少数据容量和增强数据写入和读取性能上都扮演着极其重要的角色。但是这部分并没有被测试到；
- Apache Avro被证明是一种快速且通用的数据结构编码器。由于其非常高效的序列化和反序列化，这个格式可以在需要同时访问记录全部属性时保证优良的性能；
根据上述测试，类似Apache Parquet这样的列存储在快速数据写入、快速随机数据读取和可扩展性的数据分析上都取得了非常好的适应性。很多情况下，这提供了保持系统简单的额外优势，因为存储数据和其他使用场景（随机访问和分析）只需要一种技术；
不管你做什么--永远不要使用JSON格式。在几乎全部测试中，它都是性能最差。
https://www.jianshu.com/p/80c1cb6ccc74
https://www.jianshu.com/p/2c42a4b7e565
网友评论