火花：阿夫罗与镶木地板的表现

Question

现在Spark 2.4已经内置了对Avro格式的支持，我正在考虑将数据湖中某些数据集的格式从Parquet更改为Avro，这些数据集通常是针对整行而不是特定列聚合进行查询/联接的。

然而，数据之上的大部分工作都是通过Spark完成的，据我所知，Spark的内存缓存和计算是在列格式的数据上完成的。在这方面，Parquet是否提供了性能提升，而Avro是否会招致某种数据“转换”损失？在这方面，我还需要注意什么？

Answer 1

这两种格式在不同的约束下大放异彩，但具有具有架构的强类型和共同的二进制编码之类的东西。在其基本形式中，它归结为这种分化：

< li>Avro是一种行格式。由此可见，您可以逐行追加到现有文件中。然后，这些按行追加的内容也立即对处理这些文件的所有读者可见。当您有一个以流(非批处理)方式写入数据湖的进程时，Avro是最好的。 < li >拼花是一种分栏格式，其文件不可附加。这意味着，对于新到达的记录，您必须始终创建新文件。作为这种行为的交换，拼花地板带来了一些好处。数据以列的方式存储，压缩和编码(简单的类型感知、低cpu但高效的压缩)应用于每一列。因此，拼花文件将比Avro文件小得多。此外，Parquet还写出了基本的统计数据，当您从其中装载数据时，您可以将部分选择下推到I/O，然后只从磁盘装载必要的一组行。因为Parquet已经是柱状的了，而且大多数内存中的结构也是柱状的，所以从它们加载数据通常要快得多。

由于您已经将数据和摄取过程调整为编写Parquet文件，只要数据摄取（延迟）不会成为您的问题，您可能最好使用Parquet。

一个典型的用法实际上是混合使用Parket和Avro。最近、新到达的数据以Avro文件的形式存储，因为这使得数据可以立即进入数据湖。更多的历史数据会被转换，例如每天转换为Parket文件，因为它们更小，加载效率最高，但只能批量写入。在处理这些数据时，您可以将两个表作为两个表的联合加载到Spark中。因此，您可以使用Parket进行高效读取，并使用Avro立即提供数据。这种模式通常被Uber的Hudi或由Netflix开始的Apache Iceberg（孵化）等表格式所隐藏。