File 与其他形式相比，拼花地板形式的优缺点是什么？

Apache拼花地板的特点是：

• 自我描述
• 柱状格式
• 语言独立

---

与Avro、序列文件、RC文件等相比，我想对这些格式进行概述。我已经读过：，它提供了一些关于格式的见解，但我想知道如何在每种格式中访问数据和存储数据。拼花地板与其他地板相比有什么优势？

我认为我能描述的主要区别在于面向记录的格式与面向列的格式。面向记录的格式是我们都习惯使用的--文本文件，如CSV、TSV等分隔格式。AVRO比那些稍冷一些，因为它可以随时间改变模式，例如从记录中添加或删除列。各种格式的其他技巧（特别是压缩）涉及到格式是否可以拆分——也就是说，您是否可以从数据集中的任何位置读取一块记录，并且仍然知道它的模式？但这里有更多关于柱状格式的细节，比如拼花地板

Parquet和其他柱状格式非常有效地处理常见的Hadoop情况。在一个设计良好的关系数据库中，表（数据集）的列数通常比预期的要多——100或200列并不少见。这是因为我们经常使用Hadoop作为一个从关系格式中去规范化数据的地方——是的，你会得到很多重复的值，很多表都被压缩成一个表。但是，由于所有联接都已计算出来，因此查询变得更加容易。还有其他优点，例如在时间数据中保留状态。所以不管怎样，在一个表中有一大堆列是很常见的

假设有132列，其中一些是很长的文本字段，每个列一列接一列，每条记录可能会占用10K

虽然使用SQL查询这些表很容易，但通常您只需要基于这百多个列中的几个列来获取一些记录范围。例如，对于销售额>500美元的客户，您可能需要2月和3月的所有记录

要以行格式执行此操作，查询需要扫描数据集的每个记录。读取第一行，将记录解析为字段（列），并获取日期和销售列，如果满足条件，则将其包含在结果中。重复一遍。如果你有10年（120个月）的历史，你阅读每一条记录只是为了找到其中的两个月。当然，这是一个在年份和月份使用分区的好机会，但即便如此，在这两个月内，您仍在读取和解析每个记录/行的10K，以确定客户的销售额是否超过500美元

在一种列格式中，记录的每一列（字段）都与其他同类型的列（字段）一起存储，分布在磁盘上的许多不同块上--年列、月列、客户员工手册列（或其他长文本），所有其他使这些记录如此巨大的记录都在磁盘上各自独立的位置，当然还有一起销售的专栏。好吧，见鬼，日期和月份是数字，销售也是数字——它们只是几个字节。如果我们只需要为每条记录读取几个字节，就可以确定哪些记录与我们的查询匹配，这不是很好吗？柱状存储来营救

即使没有分区，扫描满足查询所需的小字段也是非常快的——它们都是按记录排序的，大小都相同，因此磁盘查找包含记录的数据要少得多。无需通读员工手册和其他长文本字段，只需忽略它们。因此，通过将列而不是行分组，您几乎可以始终扫描更少的数据。赢

但是等等，情况会好转。如果您的查询只需要知道这些值和其他一些值（比如132列中的10列），而不关心员工手册列，那么一旦选择了要返回的正确记录，它现在只需要返回呈现结果所需的10列，而忽略数据集中132列中的其他122列。同样，我们跳过了很多阅读

（注意：由于这个原因，在执行直接转换时，列格式是一个糟糕的选择，例如，如果要将所有两个表合并到一个大（ger）表中结果集保存为一个新表，但无论如何都会对源进行完全扫描，因此在读取性能方面没有多大好处，而且由于列格式需要记住更多关于内容所在位置的信息，因此它们比类似的行格式使用更多内存）

columnar的另一个好处是：数据是分散的。要获得一条记录，您可以让132个工人在132个数据块上的132个不同位置读取（和写入）数据。是的，并行化

现在最关键的是：当压缩算法能够找到重复的模式时，它会工作得更好。您可以将

aabbbbcccccccc

压缩为

2A6B16C

，但

abcabcbccccccc

不会变小（实际上，在这种情况下它会变小，但请相信我：-））。所以再一次，少读书。还有写作

因此，我们在回答常见查询时读取的数据要少得多，并行读写可能更快，而压缩往往工作得更好

当您的输入端很大，并且您的输出是经过过滤的子集时，Columnar非常好：从大到小非常好。当输入和输出大致相同时，就没有那么好了

但在我们的例子中，黑斑羚接受了我们在5、10、20或30分钟内运行的旧蜂巢查询，并在几秒钟或一分钟内完成了大部分查询

---

希望这能帮助你回答至少部分问题

Tom的回答非常详细和详尽，但您可能也对Allstate Insurance的Parquet vs Avro感兴趣，总结如下：<

<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

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

ken,felicia,mia
30,36,2