为什么在一些 RDBMS 上使用 Parquet，比如 Postgres

Question

我正在为我的公司构建数据架构。一个带有内部和外部数据的简单 ETL，旨在构建静态仪表板和其他搜索趋势。

我尝试一步一步地思考 ETL 过程的每一步，现在我正在质疑Load部分。

我计划使用 Spark（开发上的 LocalExcecutor 和 Azure 上的生产服务），所以我开始考虑将 Parquet 用于 Blob 服务。我知道 Parquet 相对于 CSV 或其他存储格式的所有优势，我真的很喜欢这项技术。我读到的大部分关于 Spark 的文章都以df.write.parquet(...).

但我不明白为什么我可以启动一个 Postgres 并将所有内容保存在这里。我知道我们不会每天产生 100Go 的数据，但我想在一家快速发展的公司中建立一些面向未来的证明，该公司将按业务以及我们开始记录的日志和指标以指数方式产生数据。

更有经验的开发人员有什么优点/缺点？

编辑：还有什么让我质疑这是这条推文：https : //twitter.com/markmadsen/status/1044360179213651968

Answer 1

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

使用 DBMS 意味着您可以以事务方式加载数据。您还需要持续支付存储和计算费用。与Blob 存储相比，托管 DBMS 中相同数据量的存储成本会更高。

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

如果将 Parquet 文件存储在 blob 存储上，则在不重新生成大部分数据的情况下更新现有数据是很困难的（我不知道 Azure 的详细信息，但通常无法通过事务方式完成）。计算成本与存储成本是分开的。

Answer 2

我对专用 Postgres 服务器遇到的问题之一是它是 24/7 的固定资源。如果每天闲置 22 小时，并且每天闲置 2 小时（特别是如果这些时间不连续并且不可预测），那么这 2 小时内的服务器大小将会太低，而在其他 22 小时内，服务器大小将会太低太高了。

如果您将数据作为 parquet 存储在 Azure Data Lake Gen 2 上，然后使用无服务器 Synapse 进行 SQL 查询，那么您无需支付任何费用（24/7）。当负载较重时，一切都会自动缩放。

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

缺点是“延迟”（可能不是正确的术语，但我是这样认为的）。如果您想查询少量数据，那么根据我的经验，与索引良好的集群或分区 Postgres 表相比，文件 + 无服务器方法会更慢。此外，使用来自服务器模型的无服务器模型很难预测您的账单。在某些使用模式中，无服务器肯定会比专用服务器更昂贵。特别是如果您执行大量必须读取全部或大部分数据的查询。

保存镶木地板比进行大量插入更容易/更快。这是一把双刃剑，因为数据库保证了酸度，而保存镶木地板文件则不能。

Parquet 存储优化是它自己的任务。Postgres 有 autovacuum 功能。如果您使用的数据每天发布，但您希望将其放在节点/属性/功能分区方案上，那么您需要手动执行此操作（可能使用 Spark 池）。