Lakehouse并发控制，我们是否对其实际效果过于乐观？

本文共计2880个文字，预计阅读时间需要12分钟。

1.+ 概述：在数据湖之上，事务被视为Lakehouse的关键特征。然而，目前实际完成了什么？有哪些方法？它在现实世界中的表现如何？这些问题是本博客的重点。

1. 概述

如今数据湖上的事务被认为是 Lakehouse 的一个关键特征。 但到目前为止，实际完成了什么？ 目前有哪些方法？ 它们在现实世界中的表现如何？ 这些问题是本博客的重点。

有幸从事过各种数据库项目——RDBMS (Oracle)、NoSQL 键值存储 (Voldemort)、流数据库 (ksqlDB)、闭源实时数据存储，当然还有 Apache Hudi， 我可以肯定地说，工作负载的不同深刻地影响了不同数据库中采用的并发控制机制。本博客还将介绍我们如何重新思考 Apache Hudi 数据湖的并发控制机制。

首先，我们直截了当点，RDBMS 数据库提供了最丰富的事务功能集和最广泛的并发控制机制，不同的隔离级别、细粒度锁、死锁检测/避免等其他更多机制，因为它们必须支持行级变更和跨多个表的读取，同时强制执行键约束并维护索引。而NoSQL 存储提供了非常弱的保证，例如仅仅提供最终一致性和简单的行级原子性，以换取更简单的工作负载的更好的扩展性。传统数据仓库基于列存或多或少提供了您在 RDBMS 中可以找到的全套功能，强制执行锁定和键约束，而云数据仓库似乎更多地关注存算分离架构，同时提供更少的隔离级别。作为一个令人惊讶的例子，没有强制执行键约束。

2. 数据湖并发控制中的陷阱

从历史看来，数据湖一直被视为在云存储上读取/写入文件的批处理作业，有趣的是看到大多数新工作如何扩展此视图并使用某种形式的“乐观并发控制”（OCC）来实现文件版本控制。