使用开放表格式的性能不佳

Question

我有一个现有案例：

每天从多个 Hive 表读取整个/完整数据， 如 SQL 查询中所述，对其进行处理/转换（连接、聚合、过滤等）。

这些 SQL 查询在一系列 YAML 文件中提到，假设有 3 个 YAML 文件。

每个结果都保存到临时视图中，后续 SQL 查询将使用之前生成的临时视图，直到执行最后一个 YAMl 中的最后一个 SQL，

最终结果以hive_table_name_epoch的格式写入HIVE TABLE。

数据量：~400,000,000（4亿）

数据大小：~ 400 Gib

执行时间：~25 分钟

新用例： 尝试集成开放表格式（Delta Lake 或 Apache Hudi）。 目的：只维护一张hive表，而不是每天创建hive表，避免一次又一次地写入整个数据， 相反，只写入所需的更新、新的插入和删除

案例1：使用Delta Lake

数据量：~400,000,000（4亿）

数据大小：~ 400 Gib

执行时间：~ 1.10 小时

案例 2：使用 Apache Hudi 数据量：~400,000,000（4 亿）

数据大小：~ 400 Gib

执行时间：~ 40 分钟

问题： 每天处理和写入整个数据的旧概念仍然表现得更好， 比使用开放表格式。

现有的案例真的可以与增量概念结合吗？

如果我们知道如何使我们的数据CDC，那么它就会有意义。

Answer 1

一般来说，这些acid库通过重写底层文件来进行数据修改（除了读/增量删除向量上的hudi合并）。

那么需要考虑的一个重要方面是传入数据中有多少与目标表主键匹配。如果是 50%，那么你至少会重写 50% 的文件。您最终可能会重写所有文件，因为匹配的 pks 可能分布在每个文件上。

因此，在合并设计和替换整表之间做出选择是有门槛的。顺便说一句，这些格式为您带来了酸性功能，例如无停机时间和时间旅行，因此它们在任何情况下都会受益。

对于 hudi，您可以调整目标 parquet 文件大小以加快数据修改速度，因为在某些情况下会导致重写量减少。但较小的文件大小会带来较慢的读取查询。

总而言之，虽然 Lakehouse 范式采用了 SQL，但它比传统的数据仓库技术要复杂一些：您必须了解它的工作原理，并分析您的工作负载以选择最佳路径，否则在合并期间性能可能会急剧下降.