文件格式是数据分析中的最大瓶颈之一。CSV 和 JSON 等基于文本的格式易于阅读和共享，但它们并不适用于现代分析型工作负载的规模和复杂性。每次查询都会付出性能代价，因为这些格式不会区分您需要的数据与不需要的数据。
Parquet 解决了这个问题。它是一种专为数据工程、数据科学和大数据系统中的分析型工作负载构建的文件格式。按列而非按行存储数据，使查询只需读取所需内容。结果如何？查询更快、存储成本更低、计算浪费更少。
本文将带您了解 Parquet 的不同之处、其高层工作原理，以及何时应使用它。我们将侧重概念和用例，而非底层实现细节或代码。如果您想通过代码示例和实践实现上手，我们有一份详细指南： 面向数据专业人士的 Apache Parquet，涵盖技术细节。
什么是 Parquet 文件？
那么 Parquet 究竟是什么？从本质上说，它是一种为高效数据存储和快速分析查询而构建的列式存储文件格式。与传统格式按行存储数据不同，Parquet 按列存储。这一看似简单的改变，使其非常适合大规模数据处理。
Parquet 在以下场景表现最佳：
- 只读取数据集中的一部分列
- 扫描海量数据
- 执行聚合、过滤和分析查询
该格式属于 Apache 生态，由 Apache Parquet 作为开源标准维护。由于其开放且支持度高，Parquet 能与众多现代数据工具顺畅集成，包括数据仓库、数据湖和分布式处理框架。
列式存储 vs. 行式格式
行式格式（CSV、JSON）将完整记录存储在单行中。这在事务型用例或需要一次读取整行时效果良好。
列式格式（Parquet）将同一列的所有值存储在一起。这样分析引擎只读取所需列，跳过其余部分。
举个例子：如果一个数据集有 50 列，而您的分析只需要 3 列，像 Parquet 这样的列式格式只会读取这 3 列。对于行式格式，即使大多数数据不会被使用，也必须扫描整行。
让我们具体一点。假设您在分析电商交易。数据集包含 40 列，但您只需要按月计算平均订单金额。您只需要order_total和order_date。使用 Parquet，您的查询只读取这 2 列。使用 CSV，它会对每一行读取全部 40 列，尽管其中 38 列与您的分析无关。在拥有数百万笔交易的数据集中，这种差异巨大。
这种效率对数据发挥作用至关重要。如果您对原始数据如何转化为可行动洞见感兴趣，我们的 数据—信息—知识—智慧金字塔速查表对这种转变进行了拆解。
为什么 Parquet 被广泛使用
这种列式设计带来了多项对分析非常实用的优势：
- 更好的压缩效果，因为相似数据类型存放在一起更易高效压缩
- 更快的查询性能，因为分析引擎整体需处理的数据更少
- 相比纯文本格式更低的存储成本
这些特性使 Parquet 在数据湖、云存储系统和分析流水线中十分常见，在这些场景中效率比可读性更重要。
简而言之，Parquet 是一种面向列的开放标准文件格式，旨在高效处理大型数据集，尤其适用于以分析为目标而非简单数据交换的场景。
为何在数据分析中使用 Parquet 文件
了解了什么是 Parquet，接下来看看它为何在数据分析中如此流行。原因并不是 Parquet 比其他格式更易用，而是它在规模化时效率更高。大多数分析型工作负载不同于事务系统，后者一次获取一条完整记录；分析更倾向于扫描大型数据集并聚焦在少数几列。
列式存储天然契合这一模式。当数据按列存储时，分析引擎只读取所需字段。如果一个查询仅涉及 50 列中的 5 列，Parquet 允许引擎完全跳过其余 45 列。这显著减少了磁盘 I/O，而 I/O 通常是数据处理的主要瓶颈。
压缩是另一个主要优势。同一列中的值通常具有相似的数据类型和范围，因此 Parquet 的压缩效果远优于行式格式。更好的压缩意味着更小的文件、更低的存储成本，以及在查询执行期间需要传输的数据更少。
这两个因素（减少 I/O 与改进压缩）直接转化为更快的查询。这也是为什么 Parquet 成为众多分析引擎和分布式查询系统的默认选择。
Parquet 现已成为数据湖与云分析平台中的标准格式，在这些平台中，大量数据被集中存储并被反复查询。在这些环境中，性能和成本效率比可读性更重要，使 Parquet 优于 CSV 或 JSON 等文本格式。
如果您使用 Python，常常需要在不同文件格式之间切换。我们的 Python 数据导入指南涵盖如何与 Parquet、CSV、JSON 以及其他格式协作。
Parquet 文件如何存储数据（高层概览）
我们已经讨论了列式存储的优势，那么 Parquet 实际上如何在磁盘上组织数据？与顺序写入完整记录（行式）不同，Parquet 将每一列的所有值分组存放。
在行式格式中，每条记录都会被完整写入，然后再处理下一条。这在您经常需要整行数据时很有效，但当分析查询只关心少数字段时就会变得低效。
Parquet 采用相反的方法。同一列的所有值存放在一起，各列彼此独立。运行查询时，分析引擎仅扫描相关列，忽略其余。如果查询对特定列应用条件，引擎可直接在该列上评估条件，而无需触及不相关字段。更少的磁盘读取，更快的执行。
您无需了解 Parquet 的内部结构也能从中受益。关键思想很简单：把相似数据放在一起，能实现更聪明的读取。即便不考虑压缩或其他优化，这一设计选择就已让 Parquet 在分析型工作负载中表现出色。
当您处理大规模数据系统时，这些存储模式尤为重要。如果您使用 PostgreSQL 进行结构化查询，请查看我们的 PostgreSQL 基础速查表获取查询优化技巧。而如果您面对的是海量数据集，不妨结合 Parquet 的列式存储探索 数据分区策略。
这种面向列的布局解释了 Parquet 在分析密集型环境中的高性能，也说明了它为何成为现代数据系统中的基础格式。
Parquet 文件格式的关键特性
除了列式存储这一核心理念，Parquet 还包含多项让其在分析型工作负载中特别有效的特性。该格式并不以人类可读性为优化目标，而是优先考虑高效存储、快速查询，以及在现代数据工具间的互操作性。
列式存储
Parquet 按列而非按行存储数据，使分析引擎仅读取查询所需字段。这减少了不必要的数据扫描，并显著提升大数据集的性能。
高效压缩
由于同一列中的值往往相似，Parquet 能实现远高于行式格式的压缩比。更小的文件意味着更低的存储成本和更快的数据传输。
模式（Schema）支持
Parquet 文件包含显式模式，定义数据类型与结构。这确保了跨工具的一致数据解读，并避免了松散类型文本格式常见的问题。如果您使用 Power BI，模式管理尤为重要。您可以在我们的指南中进一步了解如何处理表结构： 在 Power Query M 中处理表。
内置元数据助力更快查询
Parquet 存储有关列和数据块的元数据，这使得查询引擎可以跳过与查询无关的文件片段。无需扫描整个数据集，即可更高效地进行过滤和选择性读取。
与大数据工具的兼容性
大多数现代数据处理框架和查询引擎都支持 Parquet，使其成为数据湖和云分析工作流中的可靠选择。广泛的兼容性有助于团队在保证性能的同时避免被单一格式绑定。
该格式可在不同工具与语言中顺畅使用。如果您在构建仪表板，我们的 Power BI 基础学习路径涵盖如何高效使用多种数据源。对于用 R 进行大规模数据处理的用户， data.table 包与 Parquet 搭配，能实现高性能分析。
Parquet 与 CSV 及其他文件格式的对比
此时您可能在想，Parquet 与您熟悉的 CSV 等格式相比如何？简言之，Parquet 与 CSV 的设计目标不同。
CSV 是一种行式的纯文本格式。它易于创建、可用文本编辑器或电子表格直接打开且便于共享。这使其适用于小型数据集、快速导出，以及系统或人员之间的基础数据交换。
相比之下，Parquet 是为分析而生的二进制列式格式。它不是为可读性而优化，而是为性能而优化。分析型查询通常只需要大型数据集中的少数几列，Parquet 专为高效读取这些列而设计。这让大规模数据分析在分布式环境中变得更快、更具成本效益。
同样的设计也带来了取舍。它不可读，而且很少适合临时数据共享或人工检查。对于这些用例，CSV 或 JSON 等格式仍更实用。
其他格式介于两者之间。JSON 灵活且广泛用于 API，但在规模化分析时效率低下。Avro 和 ORC 与 Parquet 一样面向大数据系统，但它们在更偏好行式或列式访问的场景中扮演略有不同的角色。如果您在这些格式之间做选择，我们整理了 Avro 与 Parquet 的对比的详细比较，阐述了取舍。
在实践中，当查询性能和存储效率最重要时，Parquet 通常是最常见的选择。
Parquet 文件的常见使用场景
结合我们已讨论的 Parquet 工作原理和优势，来看它实际会出现在哪里。Parquet 文件最常见于为分析而反复查询海量数据的环境，而不是从头到尾只读一次的场景。
数据湖与湖仓架构
一个常见用例是数据湖与湖仓架构，在这里原始和处理后的数据被低成本存储，并按需查询。Parquet 的高效存储与选择性列读取，使其非常适合这些规模庞大且不断演变的数据集。
商业智能与分析型工作负载
Parquet 也广泛用于商业智能和分析型工作负载。仪表板、报表和探索性分析往往会在大量记录中仅扫描部分列，这与 Parquet 的列式设计完美契合。
Power BI 和 Tableau 等工具常使用 Parquet 来提升性能。如果您在 Power BI 中工作并希望更好地管理数据资产，我们的课程 在 Power BI 中部署与维护资产涵盖最佳实践。如果您正准备专业化验证 Power BI 技能，请查看我们的指南： 通过 PL-300 Power BI 认证。
机器学习工作流
在机器学习工作流中，Parquet 常用于存储特征和训练数据。模型可以只加载所需特征，从而减少 I/O 开销并加速对大型数据集的实验。当您对这些特征集进行探索性数据分析时，Plotly Express 等可视化库与 Parquet 配合良好。我们的 Plotly Express 速查表向您展示如何高效创建交互式可视化。
基于云和分布式的查询系统
最后，Parquet 非常适合基于云和分布式的查询系统，在这些系统中，性能和成本与扫描数据量密切相关。通过尽量减少不必要的读取并高效压缩数据，Parquet 帮助这些系统在数据规模增长时实现高效扩展。
支持 Parquet 文件的工具与平台
了解 Parquet 的使用场景是一方面，那么实际您会用到哪些工具？Parquet 得到广泛采用的原因之一是其在现代数据生态中的广泛支持。您学习的不是小众或厂商特定的格式。Parquet 是大规模分析的事实标准。
大多数分布式查询引擎和数据处理框架都能原生读写 Parquet。它常用于云数据平台、大数据处理系统以及为高效扫描大型数据集而设计的分析引擎。由于 Parquet 是开放的、由 Apache 支持的格式，它能在不同工具间顺畅集成，而不会将用户锁定在单一厂商或技术栈中。
Parquet 在数据科学和机器学习工作流中也得到良好支持，在这些工作流中，数据集必须在团队、流水线和环境之间共享。同一份 Parquet 文件通常可用于探索、报告和模型训练，无需转换。如果您使用 R 并需要可复现实验文档， Quarto 可与 Parquet 良好配合，创建融合代码、分析与结果的报告。
这种广泛的兼容性也是 Parquet 的吸引力之一。选择 Parquet 并不意味着绑定某个特定数据库、云服务商或分析引擎，而是采用一种可跨平台工作的格式，能随您的数据架构一同扩展。
Parquet 文件的局限与取舍
尽管优势众多，Parquet 并非解决所有数据存储问题的灵丹妙药。尽管它很强大，但并非万能。其设计偏向特定类型的工作负载，理解其局限有助于避免误用。
不适合频繁更新
Parquet 为读多写少的分析优化，而非频繁更新或小而频繁的增量写入。写入 Parquet 通常以批处理方式进行，因此不适合事务系统或实时逐条更新。
模式管理更复杂
与简单文本格式相比，模式管理也可能更复杂。尽管 Parquet 支持模式及其演进，但随时间改变列定义需要协调和谨慎，尤其在共享数据环境中。
不能替代数据库
Parquet 并非为替代操作型工作负载中的数据库而设计。它缺乏对事务、点查索引以及低延迟更新的原生支持——而这些对面向应用的系统至关重要。
小文件问题
最后，Parquet 也会遭遇常说的“小文件问题”。将数据存为大量体积很小的 Parquet 文件，会降低列式存储的效率增益，并可能损害分布式系统的性能。Parquet 在以与查询方式相匹配的、合理大小的块进行写入时效果最佳。
这些取舍并不降低 Parquet 的价值，但明确了其最佳适用范围：面向读优化的大规模分析，而非事务型或高度可变的工作负载。
使用 Parquet 时要避免的常见错误
创建过多小文件是一种错误。因为写入成千上万个小型 Parquet 文件会背离初衷。目标应是至少数十 MB，理想情况下数百 MB 的文件大小。在分布式系统中，这通常意味着将写入操作配置为合适的批量。
将 Parquet 用于频繁更新的数据是另一种错误。如果您需要在一天内多次更新单条记录，Parquet 并非合适选择。它是为批量写入而设计，而非增量更新。
忽视模式演进也是错误。当您需要新增或更改列时，请提前规划。Parquet 支持模式演进，但这需要谨慎协调，尤其在共享数据环境中。
最后，不对大型数据集进行分区也会出错。对于非常大的数据集，应考虑按常用过滤列进行分区。这样查询引擎可以跳过与过滤条件不匹配的整批文件。
何时应该（不应该）使用 Parquet
综上所述，何时实际应使用 Parquet？答案取决于将格式与您的工作负载相匹配。Parquet 是强有力的选择，但前提是它契合您的工作类型。考虑数据的读写方式，通常就能让决策变得明晰。
Parquet 适用的情形
- 您从事扫描大型数据集的分析或报告型工作负载
- 查询通常只读取部分列，而非整行
- 数据以批量方式写入——例如每日导入或定时流水线
- 存储效率和查询性能比可读性更重要
- 您正在构建或参与数据湖/湖仓架构
在这些场景中，Parquet 的列式布局、压缩与元数据能迅速带来回报。
何时更简单的格式可能更好
- 您需要便于人工检查或手动编辑的文件
- 数据在系统之间以小规模或临时工作流进行交换
- 您在处理频繁更新或事务型写入
- 简单性与互操作性比性能更重要
对于轻量级数据交换或早期阶段的工作流，CSV 或 JSON 等格式往往更适合。可以把它们类比为开发环境中的配置文件（如果您使用过 dotfiles，您就会明白为何对需要经常阅读和编辑的文件而言，纯文本很重要）。
关键在于，Parquet 在读多写少的分析环境中大放异彩。若您的工作负载符合这一模式，它几乎无可匹敌；若不符合，更简单的格式往往更省事。
结论
务实结论是：如果您处理大型数据集且查询通常只需少数列，Parquet 很可能为您节省时间和成本。若您需要对单条记录进行频繁更新，或需要人类可读的文件，请继续使用更简单的格式。
Parquet 的美妙之处在于它是开放标准，且具有广泛生态支持。您可以跨工具使用它，而无需绑定某一厂商。无论您是执行查询的分析师、构建流水线的工程师，还是设计数据系统的架构师，Parquet 都能自然融入现代分布式环境。
如果您是 Parquet 新手，请从小处着手。尝试将一份经常查询的 CSV 转换为 Parquet 并比较查询性能。对于大型数据集，这种差异通常一目了然。此后，您可以决定在工作流的哪些地方采用列式存储更为合适。
想更深入了解实现细节？我们的 Apache Parquet 教程通过代码演示实际案例，我们还有大量关于现代数据格式与分析工具的资源，助您构建更高效的数据系统。
%22%3E%3Cpath%20d%3D%22m-369%200h408v79h-408z%22%20fill%3D%22%237933ff%22%2F%3E%3Cpath%20d%3D%22m-148%200h306v45h-306z%22%20fill%3D%22%23974dff%22%2F%3E%3C%2Fg%3E%3C%2Fsvg%3E)
%22%2F%3E%3C%2FclipPath%3E%3Cg%20clip-path%3D%22url(%23a)%22%3E%3Cpath%20d%3D%22m76%200h484v36h-484z%22%20fill%3D%22%23974dff%22%2F%3E%3Cpath%20d%3D%22m0%200h384v24h-384z%22%20fill%3D%22%2306bdfc%22%20transform%3D%22matrix(1%200%200%20-1%200%2060)%22%2F%3E%3C%2Fg%3E%3C%2Fsvg%3E)
文件格式是数据分析中的最大瓶颈之一。CSV 和 JSON 等基于文本的格式易于阅读和共享，但它们并不适用于现代分析型工作负载的规模和复杂性。每次查询都会付出性能代价，因为这些格式不会区分您需要的数据与不需要的数据。
Parquet 解决了这个问题。它是一种专为数据工程、数据科学和大数据系统中的分析型工作负载构建的文件格式。按列而非按行存储数据，使查询只需读取所需内容。结果如何？查询更快、存储成本更低、计算浪费更少。
本文将带您了解 Parquet 的不同之处、其高层工作原理，以及何时应使用它。我们将侧重概念和用例，而非底层实现细节或代码。如果您想通过代码示例和实践实现上手，我们有一份详细指南： 面向数据专业人士的 Apache Parquet，涵盖技术细节。
什么是 Parquet 文件？
那么 Parquet 究竟是什么？从本质上说，它是一种为高效数据存储和快速分析查询而构建的列式存储文件格式。与传统格式按行存储数据不同，Parquet 按列存储。这一看似简单的改变，使其非常适合大规模数据处理。
Parquet 在以下场景表现最佳：
该格式属于 Apache 生态，由 Apache Parquet 作为开源标准维护。由于其开放且支持度高，Parquet 能与众多现代数据工具顺畅集成，包括数据仓库、数据湖和分布式处理框架。
列式存储 vs. 行式格式
行式格式（CSV、JSON）将完整记录存储在单行中。这在事务型用例或需要一次读取整行时效果良好。
列式格式（Parquet）将同一列的所有值存储在一起。这样分析引擎只读取所需列，跳过其余部分。
举个例子：如果一个数据集有 50 列，而您的分析只需要 3 列，像 Parquet 这样的列式格式只会读取这 3 列。对于行式格式，即使大多数数据不会被使用，也必须扫描整行。
让我们具体一点。假设您在分析电商交易。数据集包含 40 列，但您只需要按月计算平均订单金额。您只需要
order_total和order_date。使用 Parquet，您的查询只读取这 2 列。使用 CSV，它会对每一行读取全部 40 列，尽管其中 38 列与您的分析无关。在拥有数百万笔交易的数据集中，这种差异巨大。这种效率对数据发挥作用至关重要。如果您对原始数据如何转化为可行动洞见感兴趣，我们的 数据—信息—知识—智慧金字塔速查表对这种转变进行了拆解。
为什么 Parquet 被广泛使用
这种列式设计带来了多项对分析非常实用的优势：
这些特性使 Parquet 在数据湖、云存储系统和分析流水线中十分常见，在这些场景中效率比可读性更重要。
简而言之，Parquet 是一种面向列的开放标准文件格式，旨在高效处理大型数据集，尤其适用于以分析为目标而非简单数据交换的场景。
为何在数据分析中使用 Parquet 文件
了解了什么是 Parquet，接下来看看它为何在数据分析中如此流行。原因并不是 Parquet 比其他格式更易用，而是它在规模化时效率更高。大多数分析型工作负载不同于事务系统，后者一次获取一条完整记录；分析更倾向于扫描大型数据集并聚焦在少数几列。
列式存储天然契合这一模式。当数据按列存储时，分析引擎只读取所需字段。如果一个查询仅涉及 50 列中的 5 列，Parquet 允许引擎完全跳过其余 45 列。这显著减少了磁盘 I/O，而 I/O 通常是数据处理的主要瓶颈。
压缩是另一个主要优势。同一列中的值通常具有相似的数据类型和范围，因此 Parquet 的压缩效果远优于行式格式。更好的压缩意味着更小的文件、更低的存储成本，以及在查询执行期间需要传输的数据更少。
这两个因素（减少 I/O 与改进压缩）直接转化为更快的查询。这也是为什么 Parquet 成为众多分析引擎和分布式查询系统的默认选择。
Parquet 现已成为数据湖与云分析平台中的标准格式，在这些平台中，大量数据被集中存储并被反复查询。在这些环境中，性能和成本效率比可读性更重要，使 Parquet 优于 CSV 或 JSON 等文本格式。
如果您使用 Python，常常需要在不同文件格式之间切换。我们的 Python 数据导入指南涵盖如何与 Parquet、CSV、JSON 以及其他格式协作。
Parquet 文件如何存储数据（高层概览）
我们已经讨论了列式存储的优势，那么 Parquet 实际上如何在磁盘上组织数据？与顺序写入完整记录（行式）不同，Parquet 将每一列的所有值分组存放。
在行式格式中，每条记录都会被完整写入，然后再处理下一条。这在您经常需要整行数据时很有效，但当分析查询只关心少数字段时就会变得低效。
Parquet 采用相反的方法。同一列的所有值存放在一起，各列彼此独立。运行查询时，分析引擎仅扫描相关列，忽略其余。如果查询对特定列应用条件，引擎可直接在该列上评估条件，而无需触及不相关字段。更少的磁盘读取，更快的执行。
您无需了解 Parquet 的内部结构也能从中受益。关键思想很简单：把相似数据放在一起，能实现更聪明的读取。即便不考虑压缩或其他优化，这一设计选择就已让 Parquet 在分析型工作负载中表现出色。
当您处理大规模数据系统时，这些存储模式尤为重要。如果您使用 PostgreSQL 进行结构化查询，请查看我们的 PostgreSQL 基础速查表获取查询优化技巧。而如果您面对的是海量数据集，不妨结合 Parquet 的列式存储探索 数据分区策略。
这种面向列的布局解释了 Parquet 在分析密集型环境中的高性能，也说明了它为何成为现代数据系统中的基础格式。
Parquet 文件格式的关键特性
除了列式存储这一核心理念，Parquet 还包含多项让其在分析型工作负载中特别有效的特性。该格式并不以人类可读性为优化目标，而是优先考虑高效存储、快速查询，以及在现代数据工具间的互操作性。
列式存储
Parquet 按列而非按行存储数据，使分析引擎仅读取查询所需字段。这减少了不必要的数据扫描，并显著提升大数据集的性能。
高效压缩
由于同一列中的值往往相似，Parquet 能实现远高于行式格式的压缩比。更小的文件意味着更低的存储成本和更快的数据传输。
模式（Schema）支持
Parquet 文件包含显式模式，定义数据类型与结构。这确保了跨工具的一致数据解读，并避免了松散类型文本格式常见的问题。如果您使用 Power BI，模式管理尤为重要。您可以在我们的指南中进一步了解如何处理表结构： 在 Power Query M 中处理表。
内置元数据助力更快查询
Parquet 存储有关列和数据块的元数据，这使得查询引擎可以跳过与查询无关的文件片段。无需扫描整个数据集，即可更高效地进行过滤和选择性读取。
与大数据工具的兼容性
大多数现代数据处理框架和查询引擎都支持 Parquet，使其成为数据湖和云分析工作流中的可靠选择。广泛的兼容性有助于团队在保证性能的同时避免被单一格式绑定。
该格式可在不同工具与语言中顺畅使用。如果您在构建仪表板，我们的 Power BI 基础学习路径涵盖如何高效使用多种数据源。对于用 R 进行大规模数据处理的用户， data.table 包与 Parquet 搭配，能实现高性能分析。
Parquet 与 CSV 及其他文件格式的对比
此时您可能在想，Parquet 与您熟悉的 CSV 等格式相比如何？简言之，Parquet 与 CSV 的设计目标不同。
CSV 是一种行式的纯文本格式。它易于创建、可用文本编辑器或电子表格直接打开且便于共享。这使其适用于小型数据集、快速导出，以及系统或人员之间的基础数据交换。
相比之下，Parquet 是为分析而生的二进制列式格式。它不是为可读性而优化，而是为性能而优化。分析型查询通常只需要大型数据集中的少数几列，Parquet 专为高效读取这些列而设计。这让大规模数据分析在分布式环境中变得更快、更具成本效益。
同样的设计也带来了取舍。它不可读，而且很少适合临时数据共享或人工检查。对于这些用例，CSV 或 JSON 等格式仍更实用。
其他格式介于两者之间。JSON 灵活且广泛用于 API，但在规模化分析时效率低下。Avro 和 ORC 与 Parquet 一样面向大数据系统，但它们在更偏好行式或列式访问的场景中扮演略有不同的角色。如果您在这些格式之间做选择，我们整理了 Avro 与 Parquet 的对比的详细比较，阐述了取舍。
在实践中，当查询性能和存储效率最重要时，Parquet 通常是最常见的选择。
Parquet 文件的常见使用场景
结合我们已讨论的 Parquet 工作原理和优势，来看它实际会出现在哪里。Parquet 文件最常见于为分析而反复查询海量数据的环境，而不是从头到尾只读一次的场景。
数据湖与湖仓架构
一个常见用例是数据湖与湖仓架构，在这里原始和处理后的数据被低成本存储，并按需查询。Parquet 的高效存储与选择性列读取，使其非常适合这些规模庞大且不断演变的数据集。
商业智能与分析型工作负载
Parquet 也广泛用于商业智能和分析型工作负载。仪表板、报表和探索性分析往往会在大量记录中仅扫描部分列，这与 Parquet 的列式设计完美契合。
Power BI 和 Tableau 等工具常使用 Parquet 来提升性能。如果您在 Power BI 中工作并希望更好地管理数据资产，我们的课程 在 Power BI 中部署与维护资产涵盖最佳实践。如果您正准备专业化验证 Power BI 技能，请查看我们的指南： 通过 PL-300 Power BI 认证。
机器学习工作流
在机器学习工作流中，Parquet 常用于存储特征和训练数据。模型可以只加载所需特征，从而减少 I/O 开销并加速对大型数据集的实验。当您对这些特征集进行探索性数据分析时，Plotly Express 等可视化库与 Parquet 配合良好。我们的 Plotly Express 速查表向您展示如何高效创建交互式可视化。
基于云和分布式的查询系统
最后，Parquet 非常适合基于云和分布式的查询系统，在这些系统中，性能和成本与扫描数据量密切相关。通过尽量减少不必要的读取并高效压缩数据，Parquet 帮助这些系统在数据规模增长时实现高效扩展。
支持 Parquet 文件的工具与平台
了解 Parquet 的使用场景是一方面，那么实际您会用到哪些工具？Parquet 得到广泛采用的原因之一是其在现代数据生态中的广泛支持。您学习的不是小众或厂商特定的格式。Parquet 是大规模分析的事实标准。
大多数分布式查询引擎和数据处理框架都能原生读写 Parquet。它常用于云数据平台、大数据处理系统以及为高效扫描大型数据集而设计的分析引擎。由于 Parquet 是开放的、由 Apache 支持的格式，它能在不同工具间顺畅集成，而不会将用户锁定在单一厂商或技术栈中。
Parquet 在数据科学和机器学习工作流中也得到良好支持，在这些工作流中，数据集必须在团队、流水线和环境之间共享。同一份 Parquet 文件通常可用于探索、报告和模型训练，无需转换。如果您使用 R 并需要可复现实验文档， Quarto 可与 Parquet 良好配合，创建融合代码、分析与结果的报告。
这种广泛的兼容性也是 Parquet 的吸引力之一。选择 Parquet 并不意味着绑定某个特定数据库、云服务商或分析引擎，而是采用一种可跨平台工作的格式，能随您的数据架构一同扩展。
Parquet 文件的局限与取舍
尽管优势众多，Parquet 并非解决所有数据存储问题的灵丹妙药。尽管它很强大，但并非万能。其设计偏向特定类型的工作负载，理解其局限有助于避免误用。
不适合频繁更新
Parquet 为读多写少的分析优化，而非频繁更新或小而频繁的增量写入。写入 Parquet 通常以批处理方式进行，因此不适合事务系统或实时逐条更新。
模式管理更复杂
与简单文本格式相比，模式管理也可能更复杂。尽管 Parquet 支持模式及其演进，但随时间改变列定义需要协调和谨慎，尤其在共享数据环境中。
不能替代数据库
Parquet 并非为替代操作型工作负载中的数据库而设计。它缺乏对事务、点查索引以及低延迟更新的原生支持——而这些对面向应用的系统至关重要。
小文件问题
最后，Parquet 也会遭遇常说的“小文件问题”。将数据存为大量体积很小的 Parquet 文件，会降低列式存储的效率增益，并可能损害分布式系统的性能。Parquet 在以与查询方式相匹配的、合理大小的块进行写入时效果最佳。
这些取舍并不降低 Parquet 的价值，但明确了其最佳适用范围：面向读优化的大规模分析，而非事务型或高度可变的工作负载。
使用 Parquet 时要避免的常见错误
创建过多小文件是一种错误。因为写入成千上万个小型 Parquet 文件会背离初衷。目标应是至少数十 MB，理想情况下数百 MB 的文件大小。在分布式系统中，这通常意味着将写入操作配置为合适的批量。
将 Parquet 用于频繁更新的数据是另一种错误。如果您需要在一天内多次更新单条记录，Parquet 并非合适选择。它是为批量写入而设计，而非增量更新。
忽视模式演进也是错误。当您需要新增或更改列时，请提前规划。Parquet 支持模式演进，但这需要谨慎协调，尤其在共享数据环境中。
最后，不对大型数据集进行分区也会出错。对于非常大的数据集，应考虑按常用过滤列进行分区。这样查询引擎可以跳过与过滤条件不匹配的整批文件。
何时应该（不应该）使用 Parquet
综上所述，何时实际应使用 Parquet？答案取决于将格式与您的工作负载相匹配。Parquet 是强有力的选择，但前提是它契合您的工作类型。考虑数据的读写方式，通常就能让决策变得明晰。
Parquet 适用的情形
在这些场景中，Parquet 的列式布局、压缩与元数据能迅速带来回报。
何时更简单的格式可能更好
对于轻量级数据交换或早期阶段的工作流，CSV 或 JSON 等格式往往更适合。可以把它们类比为开发环境中的配置文件（如果您使用过 dotfiles，您就会明白为何对需要经常阅读和编辑的文件而言，纯文本很重要）。
关键在于，Parquet 在读多写少的分析环境中大放异彩。若您的工作负载符合这一模式，它几乎无可匹敌；若不符合，更简单的格式往往更省事。
结论
务实结论是：如果您处理大型数据集且查询通常只需少数列，Parquet 很可能为您节省时间和成本。若您需要对单条记录进行频繁更新，或需要人类可读的文件，请继续使用更简单的格式。
Parquet 的美妙之处在于它是开放标准，且具有广泛生态支持。您可以跨工具使用它，而无需绑定某一厂商。无论您是执行查询的分析师、构建流水线的工程师，还是设计数据系统的架构师，Parquet 都能自然融入现代分布式环境。
如果您是 Parquet 新手，请从小处着手。尝试将一份经常查询的 CSV 转换为 Parquet 并比较查询性能。对于大型数据集，这种差异通常一目了然。此后，您可以决定在工作流的哪些地方采用列式存储更为合适。
想更深入了解实现细节？我们的 Apache Parquet 教程通过代码演示实际案例，我们还有大量关于现代数据格式与分析工具的资源，助您构建更高效的数据系统。