我认为我可以描述的主要区别与面向记录和面向列的格式有关。面向记录的格式是我们都习惯的--文本文件，分隔格式，如CSV，TSV。AVRO比那些稍微酷一点，因为它可以随着时间的推移改变模式，例如从记录中添加或删除列。各种格式的其他技巧（特别是包括压缩）涉及到一种格式是否可以拆分--也就是说，您是否可以从数据集中的任何地方读取一个记录块，并且仍然知道它的模式？
Parquet和其他列式格式可以非常有效地处理常见的Hadoop情况。在一个设计良好的关系数据库中，（数据集）的列比你预期的要多得多--一百或两百列并不罕见。这是因为我们经常使用Hadoop作为一个从关系格式中 * 反规范化 * 数据的地方--是的，你会得到很多重复的值，很多表都被合并成一个表。但是由于所有的连接都被计算出来了，所以查询变得更容易了。还有其他的优点，比如保留状态数据。所以不管怎样，在一个表中有大量的列是很常见的。
假设有132列，其中一些是非常长的文本字段，每个不同的列一个接一个，每条记录可能占用10 K。
虽然从SQL的Angular 来看，查询这些表很容易，但通常您只需要基于这一百多列中的几列来获取某些范围的记录。例如，您可能需要销售额> 500美元的客户在2月和3月的所有记录。
要以行格式执行此操作，查询需要扫描数据集的每条记录。读取第一行，将记录解析为字段（列）并获取日期和销售列，如果满足条件，则将其包含在结果中。重复。如果有10年（120个月）的历史记录，你阅读每一个记录只是为了找到其中的两个月。当然，这是一个很好的机会，使用分区的年和月，但即使如此，您要阅读并解析这两个月的每条记录/行中的10 K数据，以确定客户的销售额是否> 500美元。
在列式格式中，记录的每一列（字段）都与其他同类记录一起存储，分布在磁盘上的许多不同块中--列一起表示年，列一起表示月，列一起表示客户员工手册（或其他长文本），以及所有其他使这些记录如此巨大的所有在他们自己的单独的地方在磁盘上，当然列销售在一起。日期和月份是数字，销售额也是数字--它们只是几个字节。如果我们只需要为每个记录读取几个字节来确定哪些记录与我们的查询匹配，那不是很好吗？
即使没有分区，扫描满足我们查询所需的小字段也是超快的--它们都是按记录顺序排列的，并且都是相同的大小，因此磁盘查找包含记录的数据要少得多。不需要通读员工手册和其他长文本字段--只需忽略它们。因此，通过将列彼此分组，而不是将行分组，你几乎总是可以扫描更少的数据。赢！
但是等等，它变得更好了。如果你的查询只需要知道这些值和更多的值，（假设是132列中的10列）并且不关心员工手册列，一旦它选择了要返回的正确记录，它现在只需返回到呈现结果所需的10列，忽略我们数据集中132列中的其他122列。我们跳过了很多阅读。
(Note：因此，在进行直接转换时，列格式是一个糟糕的选择，例如，如果您将两个表连接到一个大的（格尔）结果集中，并将其保存为一个新表，则无论如何都将完全扫描源，因此读取性能没有太多好处，并且因为列格式需要记住更多关于内容所在位置的信息，它们比类似的行格式使用更多的存储器）。
柱状的另一个好处是：数据是分散的。为了得到一条记录，你可以让132个工作者在132个数据块上的132个不同的地方读（写）数据。
现在是关键时刻：当压缩算法可以找到重复模式时，它的工作效果会更好。你可以将AABBBBBBCCCCCCCCCCCCCCCC压缩为2A6B16C，但ABCABCBCBCBCCCCCCCCCCCCCC不会变小（好吧，实际上，在这种情况下，它会变小，但相信我：-）。所以，再一次，更少的阅读。也写。
因此，我们读取更少的数据来回答常见的查询，并行读取和写入可能更快，压缩往往工作得更好。
当你的输入端很大，而你的输出是一个过滤的子集时，列式是很好的：从大到小是很好的。当输入和输出大致相同时，就没有那么好了。

但在我们的例子中，Impala采用了我们在5、10、20或30分钟内运行的旧Hive查询，并在几秒钟或一分钟内完成了大部分查询。

Avro是Hadoop基于行的存储格式。
Parquet是Hadoop的一种列存储格式。
如果您的用例通常在每个查询中扫描或检索一行中的所有字段，Avro通常是最佳选择。
如果您的数据集有许多列，并且您的用例通常涉及处理这些列的子集而不是整个记录，则Parquet针对此类工作进行了优化。
Source

汤姆的答案是相当详细和详尽的，但你可能也有兴趣在this simple study关于 parquet 与Avro在好事达保险做，总结在这里：
“总的来说，Parquet在每次测试中都显示出类似或更好的结果[比Avro]。Parquet在较大数据集上的查询性能差异部分是由于压缩结果;当查询宽数据集时，Spark不得不读取Parquet的数据比Avro少3.5倍。Avro在处理整个数据集时表现不佳，正如所怀疑的那样。”

选择正确的文件格式对于构建高性能的数据应用程序非常重要。本文中概述的概念适用于Pandas，Dask，Spark和Presto / AWS Athena。

列修剪

列修剪是一个很大的性能改进，对于基于列的文件格式（Parquet，ORC）是可能的，而对于基于行的文件格式（CSV，Avro）是不可能的。
假设你有一个包含100列的数据集，想要将其中两列读入DataFrame。如果数据存储在Parquet文件中，下面是如何使用Pandas执行此操作的。

import pandas as pd

pd.read_parquet('some_file.parquet', columns = ['id', 'firstname'])

字符串
Parquet是一种列式文件格式，因此Pandas可以抓取与查询相关的列，并跳过其他列。这是一个巨大的性能改进。
如果数据存储在CSV文件中，您可以像这样读取它：

import pandas as pd

pd.read_csv('some_file.csv', usecols = ['id', 'firstname'])

型
usecols不能跳过整个列，因为CSV文件格式的行性质。
Spark不要求用户显式列出查询中要使用的列。Spark构建了一个执行计划，并将尽可能自动利用列修剪。当然，只有当底层文件格式是面向列的时，才可能进行列修剪。

人气

Spark和Pandas内置了CSV、JSON、ORC、Parquet和文本文件的读写器，但没有内置Avro的读写器。
Avro在Hadoop生态系统中很受欢迎。Parquet在Hadoop生态系统之外也获得了巨大的吸引力。例如，Delta Lake项目就是基于Parquet文件构建的。
Arrow是一个重要的项目，可以轻松使用各种不同语言（C，C++，Go，Java，JavaScript，MATLAB，Python，R，Ruby，Rust）的Parquet文件，但不支持Avro。Parquet文件更容易使用，因为它们被许多不同的项目支持。

架构

Parquet将文件模式存储在文件元数据中。CSV文件不存储文件元数据，因此读者需要提供模式或需要推断模式。提供模式是繁琐的，推断模式容易出错/昂贵。
Avro还将数据模式存储在文件本身中。在文件中存储模式是一个巨大的优势，这也是现代数据项目不应该依赖JSON或CSV的原因之一。

栏目元数据

parquet 还可存储metadata statistics for each column和lets users add their own column metadata。
最小/最大列值元数据允许Dask和Spark集群计算框架支持的Parquet predicate 下推过滤。
下面是如何使用PyArrow获取列统计信息。

import pyarrow.parquet as pq

parquet_file = pq.ParquetFile('some_file.parquet')
print(parquet_file.metadata.row_group(0).column(1).statistics)

<pyarrow._parquet.Statistics object at 0x11ac17eb0>
  has_min_max: True
  min: 1
  max: 9
  null_count: 0
  distinct_count: 0
  num_values: 3
  physical_type: INT64
  logical_type: None
  converted_type (legacy): NONE

复杂列类型

Parquet允许数组、字典和嵌套模式等复杂的列类型，但没有可靠的方法来以CSV等简单文件格式存储复杂类型。

压缩

列式文件格式将相关类型存储在行中，因此它们更容易压缩。CSV文件相对难以压缩。

first_name,age
ken,30
felicia,36
mia,2

型
当相关类型存储在同一行中时，此数据更容易压缩：

ken,felicia,mia
30,36,2

型
Parquet文件最常使用Snappy压缩算法进行压缩。Snappy压缩文件可拆分且可快速膨胀。大数据系统希望减少磁盘上的文件大小，但也希望快速膨胀苍蝇并运行分析查询。

文件的可变性

Parquet文件是不可变的，as described here.CSV文件是可变的。
向CSV文件中添加行很容易，但向Parquet文件中添加行却很困难。

数据湖

在大数据环境中，您将处理数百或数千个Parquet文件。文件的磁盘分区，避免大文件，并压缩小文件非常重要。数据的最佳磁盘布局取决于您的查询模式。

我正在研究不同的文件格式，如Avro，ORC，Parquet，JSON，部分文件，以保存大数据中的数据。发现Parquet文件在很多方面都更好。
这是我的发现

存储为Parquet文件的好处：

1.数据安全，因为数据不是人类可读的
1.低存储消耗
1.高效的阅读数据在更短的时间内，因为它是列存储和最小化延迟。
1.支持高级嵌套数据结构。针对处理大量数据的查询进行了优化

1. Parquet文件可以进一步压缩。

一个真实的时间测试结果与数字：

Sqoop导入一个有13，193，045条记录的表，输出的常规文件大小为8.6 GB。但是同样的Sqoop导入一个有13，193，045条记录的表，作为一个parquet文件，输出的文件只有1.6 GB，节省了500%的存储空间。
此外，我们可以通过引用此parquet文件来创建配置单元外部表，也可以直接从parquet文件处理数据
虽然，sqoop导入作为常规文件所需的时间仅为3分钟，而Parquet文件作为4部分文件所需的时间为6分钟。我很惊讶地看到存储parquet文件的时间差异。这部分时间需要更多的研究。