【问题标题】:Avro vs. ParquetAvro 与 Parquet
【发布时间】:2015-05-11 12:16:32
【问题描述】:

我计划在我的 hadoop 相关项目中使用其中一种 hadoop 文件格式。我了解 parquet 对于基于列的查询和 avro 用于全扫描或当我们需要所有列数据时非常有效!

在继续选择其中一种文件格式之前,我想了解其中一种文件格式的缺点/缺点。谁能简单的给我解释一下?

【问题讨论】:

    标签: hadoop avro parquet


    【解决方案1】:

    如果您还没有决定,我会继续为您的数据编写 Avro 模式。完成后,在 Avro 容器文件和 Parquet 文件之间进行选择就像换出一样简单,例如,

    job.setOutputFormatClass(AvroKeyOutputFormat.class);
    AvroJob.setOutputKeySchema(MyAvroType.getClassSchema());
    

    job.setOutputFormatClass(AvroParquetOutputFormat.class);
    AvroParquetOutputFormat.setSchema(job, MyAvroType.getClassSchema());
    

    Parquet 格式在写入方面似乎确实需要更多计算密集型 - 例如,需要 RAM 进行缓冲,需要 CPU 来排序数据等,但它应该减少 I/O、存储和传输成本以及实现高效读取,尤其是使用仅处理部分列的类似 SQL(例如,Hive 或 SparkSQL)查询。

    在一个项目中,我最终从 Parquet 容器恢复到 Avro 容器,因为架构过于广泛和嵌套(派生自一些相当分层的面向对象的类)并导致了 1000 多个 Parquet 列。反过来,我们的行组又宽又浅,这意味着我们需要很长时间才能处理每个组最后一列中的少量行。

    我还没有太多机会将 Parquet 用于更规范化/健全的数据,但我知道如果使用得当,它可以显着提高性能。

    【讨论】:

    • Parquet 也支持嵌套数据集/集合。
    • @Ruslan:是的,它确实在技术上支持嵌套结构。问题是由于数据的广泛反规范化导致的列数非常多。它有效,但速度很慢。
    • 是的,在 parquet 中写入数据更昂贵。读取是另一种方式,尤其是当您的查询通常读取列的子集时。
    • 我认为 Parquet 适用于大多数用例,除了同一列中的数据变化很大,并且总是在几乎所有列上进行分析。
    • Apache Arrow 还不支持混合嵌套(带有字典的列表或带有列表的字典)。因此,如果您想在 Parquet 中处理复杂的嵌套,您将不得不使用 Spark、Hive 等以及不依赖 Arrow 来读写 Parquet 的工具。
    【解决方案2】:

    Avro 是一种基于行的格式。如果你想检索整个数据,你可以使用 Avro

    Parquet 是一种基于列的格式。如果您的数据包含很多列,但您对列的子集感兴趣,那么您可以使用 Parquet

    当涉及频繁更新数据时,HBase 很有用。 Avro 的检索速度很快,Parquet 更快。

    【讨论】:

    • parquet 以混合方式将数据存储在磁盘上。它对数据进行水平分区,并以列的方式存储每个分区。
    【解决方案3】:

    Avro

    • 广泛用作序列化平台
    • 基于行,提供紧凑且快速的二进制格式
    • 架构已在文件中编码,因此可以取消标记数据
    • 文件支持块压缩并且是可拆分的
    • 支持架构演变

    镶木地板

    • 面向列的二进制文件格式
    • 使用 Dremel 论文中描述的记录粉碎和组装算法
    • 每个数据文件都包含一组行的值
    • 在需要查询特定列时有效地提高磁盘 I/O

    来自Choosing an HDFS data storage format- Avro vs. Parquet and more

    【讨论】:

      【解决方案4】:

      Avro 和 Parquet 都是“自我描述”的存储格式,这意味着在文件中存储数据时都嵌入了数据、元数据信息和架构。 两种存储格式的使用取决于用例。三个方面构成了您可以选择哪种格式最适合您的情况的基础:

      1. 读/写操作:Parquet 是一种基于列的文件格式。它支持索引。因此,它适用于一次写入和读取密集型、复杂或分析查询、低延迟数据查询。这通常由最终用户/数据科学家使用。
        同时,作为基于行的文件格式,Avro 最适合用于写入密集型操作。这通常由数据工程师使用。两者都支持序列化和压缩格式,尽管它们以不同的方式实现。

      2. 工具:Parquet 非常适合 Impala。 (Impala 是一个大规模并行处理 (MPP) RDBM SQL 查询引擎,它知道如何对驻留在一个或几个外部存储引擎中的数据进行操作。)同样,Parquet 非常适合复杂/交互式查询和快速(低延迟) ) 输出 HDFS 中的数据。 CDH(Cloudera Distribution Hadoop)支持这一点。 Hadoop 支持 Apache 的优化行列 (ORC) 格式(选择取决于 Hadoop 发行版),而 Avro 最适合 Spark 处理。

      3. 模式演变:发展数据库模式意味着改变数据库的结构,从而改变它的数据,从而改变它的查询处理。
        Parquet 和 Avro 都支持模式演化,但程度不同。
        Parquet 适用于“附加”操作,例如添加列,但不用于重命名列,除非“读取”是通过索引完成的。
        Avro 比 Parquet 更适合追加、删除和一般变异列。从历史上看,Avro 提供了比 Parquet 更丰富的模式演化可能性,尽管它们的模式演化能力趋于模糊,但与 Parquet 相比,Avro 在这方面仍然大放异彩。

      【讨论】:

      • “工具”部分有点误导。 Parquet 被 Spark、Presto、Hive 等许多其他框架高效使用。Avro 并非特定于 Spark,它被广泛用作 HDFS 存储格式和消息传递场景,如 Kafka。
      • Aakash Aggarwal:您能解释一下第 2 段中“Avro 最适合 Spark 处理”的意思吗?正如 devrimbaris 所提到的,Parquet 也很好地集成在 Spark 处理环境中。 o_O ?!?
      【解决方案5】:

      你的理解是对的。事实上,我们在 DWH 的数据迁移过程中遇到了类似的情况。我们选择 Parquet 而不是 Avro,因为我们获得的磁盘节省几乎是 AVro 的两倍。此外,查询处理时间也比 Avro 好得多。但是,是的,我们的查询基于聚合、基于列的操作等。因此 Parquet 无疑是一个明显的赢家。

      我们使用的是 CDH 发行版的 Hive 0.12。您提到您遇到了 Hive+Parquet 的问题,这些是什么?我们没有遇到任何人。

      【讨论】:

        【解决方案6】:

        Silver Blaze 用一个示例用例很好地描述了 Parquet 是他的最佳选择。根据您的要求考虑其中一个是有意义的。我也将简要描述不同的其他文件格式以及时间空间复杂度比较。希望对您有所帮助。

        您可以在 Hive 中使用多种文件格式。值得一提的是 AVRO、Parquet。 RCFile & ORC。如果您想比较这些文件格式的性能和空间利用率,可以参考一些在线文档。跟随一些有用的链接,可以让你继续前进。

        This Blog Post

        This link from MapR [They don't discuss Parquet though]

        This link from Inquidia

        上面给出的链接会让你继续前进。我希望这能回答您的问题。

        谢谢!

        【讨论】:

          【解决方案7】:

          关于 Parquet 的说明,可以参考这里:http://bigdata.devcodenote.com/2015/04/parquet-file-format.html

          我打算很快写关于 Avro 以及两者之间的比较。完成后会在这里发布。

          【讨论】:

          • 等待比较。目前我为我的项目选择了 Avro,因为 parquet 与 hive 存在兼容性问题 :)
          • @Abshinek,你能提供一些关于 hive 和 avro 兼容性问题的信息
          • @EB 应该没有问题,如果有问题会在cwiki.apache.org/confluence/display/Hive/AvroSerDe提到
          猜你喜欢
          • 2015-08-30
          • 2015-12-23
          • 2019-09-25
          • 2016-11-22
          • 1970-01-01
          • 2020-09-21
          • 1970-01-01
          • 2014-06-22
          • 2022-10-14
          相关资源
          最近更新 更多