在数据处理领域，数据分析师在数据湖上运行即席查询。数据湖充当分析和生产环境之间的接口，可防止下游查询影响上游数据引入管道。为了确保数据湖中的数据处理效率，选择合适的存储格式至关重要。

Vanilla数据湖解决方案构建在具有Hive元存储的云对象存储之上，其中数据文件以Parquet格式编写。尽管此设置针对可缩放的分析查询模式进行了优化，但由于两个原因，它难以处理对数据的频繁更新：

1. Hive表格式要求使用最新数据重写Parquet文件。例如，要更新Hive未分区表中的一条记录，需要读取所有数据、更新记录并写回整个数据集。
2. 由于将数据组织为压缩的列格式（比行格式更复杂）的开销，因此编写Parquet文件的成本很高。

计划中的下游转换进一步加剧了这个问题。这些必要的步骤用于清理和处理数据以供使用，但会增加延迟，因为总延迟现在包括这些处理作业的组合计划间隔。

幸运的是，Hudi格式的引入允许Avro和Parquet文件在读取时共存，从而支持快速写入，为拥有数据延迟最小的数据湖提供了可能性。提交时间线的概念进一步允许为数据提供原子性、一致性、隔离性和持久性（ACID）保证。

数据源特性及配置

我们根据输入源的不同特性采用不同的配置集：

1. 高吞吐量或低吞吐量。高吞吐源是指具有高活性源的源，例如，我们从每笔客户交易中生成的预订事件流。另一方面，低吞吐源是活性水平相对较低的源，例如，每晚发生的对账生成的事务事件。
2. Kafka（无界）或关系数据库源（有界）。写出来源可以大致分为无界和有界。无界源通常与具体化为Kafka主题的交易事件相关，代表用户在与Grab超级应用交互时生成的事件。边界源通常是指关系数据库（RDS）源，其大小与预配的存储绑定。

在下文部分，将深入探讨每个源之间的差异以及我们针对它们优化的相应配置。

未经允许不得转载：大白鲨游戏网 » 数据湖中的数据处理和优化