为什么选择Parquet而不是像Postgres这样的关系型数据库管理系统？

Question

我正在为我的公司建立数据架构。这是一个简单的ETL过程，包括内部和外部数据，旨在构建静态仪表盘和搜索趋势等功能。

我尝试逐步思考ETL过程的每个步骤，现在我在质疑“加载”部分。

我计划使用Spark（在开发环境中使用LocalExcecutor，在生产环境中使用Azure服务），因此我开始考虑将Parquet存储到Blob服务中。我知道Parquet相对于CSV或其他存储格式的所有优点，我真的很喜欢这项技术。我阅读的大多数有关Spark的文章都以 df.write.parquet(...) 结尾。

但我无法想象为什么不能直接启动Postgres并将所有内容保存在那里。我理解我们不会每天产生100G的数据，但我想构建一些未来可靠的东西，特别是在一个快速增长的公司中，由于业务和记录的日志和指标等原因，数据将呈指数级增长。

有经验的开发人员能否提供任何专业意见？

编辑：这也让我开始质疑这条推文：https://twitter.com/markmadsen/status/1044360179213651968

- Ragnar

---

我对PostGRE SQL不够熟悉，但是我可以使用Parquet。优点是节省空间，对于高度并行化的输出更有效率。缺点是无法处理加载到列中的不同数据类型。 - afeldman

@afeldman：DBMS被称为PostgreSQL或简称为Postgres。 - user330315

Answer 1

主要的权衡是成本和事务语义。

使用DBMS意味着您可以以事务方式加载数据。您还需要持续支付存储和计算 成本。相同数量数据的存储成本在托管的DBMS中将比blob存储更昂贵。

在DBMS上扩展处理也更加困难（Azure提供的最大Postgres服务器大小似乎有64个vcpus）。通过将数据存储到RDBMs中，您可能会更快地遇到IO或计算瓶颈，而使用Spark + blob存储则不会。然而，对于许多数据集来说，这可能不是问题，正如推文指出的那样，如果您可以通过SQL在DB内完成所有操作，则它是一个更简单的架构。

如果您在blob存储上存储Parquet文件，则更新现有数据很困难（我不知道Azure的详细信息，但通常无法进行事务处理）。计算成本与存储成本是分开的。

- Micah Kornfield

---

谢谢你的回答。我想现在我们会选择RDBM，然后在以后使用Parquet+Blob来准备架构。我现在会将这些记录在文档中。 - Ragnar

Answer 2

我对专用的Postgres服务器之一的问题是它是一个24/7的固定资源。如果它在一天中有22个小时处于空闲状态，并且在2个小时内承受大量负载（特别是如果这些时间不连续且难以预测），那么这个服务器在那2个小时期间的大小将会过低，而在其他22个小时则过高。

如果您将数据存储为Azure Data Lake Gen 2上的parquet格式，然后使用Serverless Synapse进行SQL查询，那么就不需要按照24/7的方式付费。当负载较重时，所有内容都会自动缩放。

另一个好处是parquet文件具有压缩功能，而Postgres不存储压缩数据。

缺点是“延迟”(可能不是正确的术语，但这是我想到的)。如果要查询少量数据，那么根据我的经验，使用文件+Serverless方法相比于良好索引的集群化或分区的Postgres表会慢得多。此外，从服务器模型转换为Serverless模型时，很难预测账单。肯定会有使用模式，其中Serverless比专用服务器更昂贵，尤其是如果做了许多必须读取全部或大部分数据的查询。

保存parquet比进行大量插入更容易/更快速。这是一个双刃剑，因为DB可以保证酸度，而保存parquet文件则不能。

Parquet存储优化是一个单独的任务。Postgres有自动清理功能。如果要消费的数据是每天发布一次，但您希望在节点/属性/特征分区方案上使用它，则需要手动完成此操作(可能需要使用spark池)。

- Dean MacGregor

Answer 3

使用原始文件格式在Hadoop中存储数据效率非常低。Parquet是一种适合快速查询大量数据的行列式文件格式。正如您上面所说，从Spark将数据写入Parquet非常容易。同时，使用分布式处理引擎（Spark）将数据写入分布式文件系统（Parquet+HDFS），使整个流程无缝衔接。此体系结构非常适合OLAP类型的数据。

另一方面，Postgres是关系数据库。虽然它很适合存储和分析事务性数据，但它不能像HDFS那样轻松地进行水平扩展。因此，在从Spark向/在Postgres中写入/查询大量数据时，数据库可能成为瓶颈。但如果您正在处理的数据是OLTP类型，则可以考虑这种体系结构。

希望这能有所帮助。

- Pushkin

---

问题更多的是在性能和成本方面，对于“小型”大数据来说，什么更适合。现在为我们设置Hadoop集群过于庞大，但也许一年后我们会倾向于这样做。我不想在一年后从头开始重新构建整个堆栈，但更改存储是可以管理的。现在我们需要ETL过程，我们需要批处理来高效地分析数据。从我的阅读中，将其存储为Parquet格式是必须的（不一定在Hadoop上，在此处Blob存储就足够了），但我认为现在我们不需要它。我不确定。 - Ragnar