火山引擎ByteHouse：分析型数据库如何设计并发控制？

更多技术交流、求职机会，欢迎关注字节跳动数据平台微信公众号，回复【1】进入官方交流群

分析型数据库设计并发控制的主要原因是为了确保数据的完整性和一致性，同时提高数据库的吞吐量和响应速度。并发控制可以防止多个事务同时对同一数据进行修改，导致数据不一致的情况发生。通过合理的并发控制策略，分析型数据库可以在保证数据一致性的前提下，最大限度地提高数据库的并发处理能力，从而提高整体性能。

此外，并发控制也可以有效减少事务因等待锁释放而造成的延迟，确保数据库能够快速响应用户的查询和更新操作。因此，设计合理的并发控制机制是分析型数据库中非常重要的一个环节，它能够确保数据库系统高效、稳定地运行，为数据分析、查询等应用提供强有力的支持。

作为火山引擎推出的一款分析型数据库，ByteHouse通过并发控制，让多个用户或应用程序可以同时访问和操作数据库，而不会产生冲突或破坏数据，提高数据库的利用率和响应速度，为用户提供更好的数据分析服务。

事务和并发控制

在ByteHouse里，为了保证数据质量，我们提供了事务语义的支持。每条SQL 语句都会转换为一个事务去执行，事务提供了原子性、一致性、隔离性和持久性 (ACID) 属性的保证，旨在在并发读写，软件异常，硬件异常等各种情况下仍然可以保证数据的正确性和完整性。

原子性（Atomicity）保证每一个事物被视为一个单元，事物要么完全成功要么彻底失败。在事务成功之前，写入的数据不可见，不会出现部分数据可见的情况。事务失败之后，会把写入的部分数据自动清理掉，不会导致垃圾数据的残留。ByteHouse在各种情况下等会保证原子性，包括掉电，错误和宕机等各种异常情况。

一致性（consistency）保证数据库只会从一个有效的状态变成另外一个有效的状态，任何数据的写入必须遵循已经定义好的规则。

隔离性（isolation）确保数据库SQL并发执行（例如，同一时刻读写同一张表）的正确性，确保数据库的状态在并发场景下能等价于某种顺序执行的状态，事务之间互不影响。隔离性是并发控制的目标，可以有多种隔离级别的实现，ByteHouse为用户提供的是read committed（rc）隔离级别的支持。未完成的事务的写入对于其他事务是不可见的。

持久性（Durability）保证数据的高可用性。一旦事务成功提交，其写入的数据会被持久化，及时在出现各种系统failure的情况下不丢失。ByteHouse采取的存储计算分离结构，利用了成熟的高可用分布式文件系统或者对象存储（例如hdfs，S3），保证成功事务所提交数据的高可用。

ByteHouse是一款分析型数据库（OLAP），跟事务型数据库（OLTP）在事务上的需求是不同。分析型在事务上针对高吞吐低延迟的场景，相反，事务性数据库针对的是高QPS实时的场景。除了基本的ACID属性需要保证，ByteHouse在事务实现选型上主要有3个特别的需求。首先，ByteHouse单个事务可能涉及到海量数据（例如，上亿行级别），事务对数据吞吐和写入性能有较高要求，并且需要保证其原子性。其次，分析型数据库的workload中读的比例高于写，事务需要保证读workload不会被写workload影响和阻塞。最后，事务需要具备灵活可控的并发控制的功能，ByteHouse里除了需要处理用户侧并发的workload，还需要处理并发的后台任务。

ByteHouse事务处理主要是对用户数据的元数据进行管理，元数据包括用户的db，table和part（part是数据文件的元数据，包括了part名字，columns，行数，状态，版本，提交时间等信息）。随着数据的增长，元数据本身数量级也会线性增长，不能丢失并且需要高可用，所以需要一个分布式存储/数据库的方案。我们选择了成熟的分布式key-value数据库的作为ByteHouse的元数据的存储方案，通过抽象元数据读写API，后端适配了字节自研的ByteKV和苹果公司开发的FoundationDB。

分布式时钟

事务在分布式系统中的执行需要在分布式不同节点中进行时钟同步。ByteHouse采取了简单实用的Timestamp Oracle（TSO）方案。其优点首先简单易懂，采取中心授时，能够确定唯一时间。然后是性能好，通常一个tso节点能支持1m+的QPS。缺点是不适合跨数据中心的场景，所有事务从tso获取时间延迟较高。由于TSO是中心化授时方案，ByteHouse为其提供了高可用服务。

TSO使用混合逻辑时钟，时钟由物理部分和逻辑部分组成，64位表示一个时间。为了避免TSO宕机导致的时间戳丢失，需要对时间戳持久化。但是如果每次授时都持久化将会降低性能，所以TSO会预申请一个可分配的时间窗口（例如3s）申请成功之后，TSO可以在内存中直接分配3秒窗口之内的所有时间戳。客户端请求时间戳，逻辑时钟部分随着请求递增。如果出现逻辑部分溢出情况，会睡眠50ms等待物理时钟被推进。TSO会每50ms检查时钟，如果当前TSO的物理时钟已经落后于当前时间，需要更新TSO的物理时钟部分为当前物理时间。如果逻辑时钟部分过半，也会增加TSO的物理时钟，一旦物理时钟增长，逻辑时钟清零。如果当前时间窗口已经用完，需要申请下一个时间窗口。同时更新持久化的窗口上界。

• Atomicity（原子性）

ByteHouse单个事务在元数据管理上有高吞吐读写的需求，由于分布式key-value数据库（例如ByteKV，FoundationDB）对单次原子写入的value都有大小限制（例如10MB），ByteHouse自己在分布式key-value存储之后实现了2阶段，使得单次写入大小不受限并且更加灵活可控。在第一阶段可以分批多次写入任意数据，并且不可见。第二阶段对事务进行提交，提交成功之后所有写入的数据同时可见。下面以一个insert sql为例，描述了2阶段原子提交的一个详细流程。

• • 1. a: 在kv里写入事务记录（txn record），唯一标识当前事务；
  • 1. b: 解析insert sql并执行；
  • 1. c: 在远端文件系统或者对象存储写入数据之前，先把要写入数据的位置信息写入undo buffer（供失败情况下清理使用）；
  • 1. d: 把数据写入到远端文件系统或者对象存储；
  • 1. e: 提交数据的元信息part，写入到kv中；
• • 提交事务，并更新事务记录的提交时间；
  • 异步更新part数据的提交时间为事务的提交时间（part未更新提交时间之前，需要反查事务记录的提交时间）；

事务提交详细流程图

• Consistency（一致性）

ByteHouse选择的分布式key-value存储系统，ByteKV和Foundation已经提供了一致性的支持，直接复用即可。

• Isolation（隔离性）

ByteHouse对用户提供Read Committed（RC）隔离级别的支持。每个事务初始化的时候会从TSO服务获取一个timestamp作为其id和开始时间，提交的时候会再从TSO服务获取一个提交时间，在事务提交的时候更新kv里事务记录的提交时间并异步更新part的提交时间。读事务可以读取到已经提交成功（对应事务提交即成功）并且提交时间小于读事务开始时间的part元数据信息，从而实现RC语意。相比更加严格的隔离级别，RC隔离级别可以最大化读性能。而更严格的隔离级别例如Serializable Snapshot Isolation（SSI），读可能会被写入block。

• Durability（持久性）

ByteHouse元数据持久到ByteKV或者FoundationDB中，2个分布式key-value存储提供了持久化和高可用的保障。

ByteHouse利用多版本和锁来保证并发读写场景下数据的正确性。ByteHouse除了来自用户的workload，内部还有后台任务（merge/alter 任务和唯一键表的去重任务）的并发读写需要处理。ByteHouse选择了RC隔离级别，对于新的写入（例如insert），由于不可见，可以无锁执行。对于已有数据，在并发读写时，需要进行并发控制。对于并发读和写这种场景，ByteHouse利用多版本解决了读和写冲突，提供了读写性能。对于并发写写的场景（例如merge和唯一键表的去重任务），利用了加锁来保证数据的正确性。

每个part的元数据除去其原有基本信息之外，都有一个对应的版本（version），每次对已有数据进行变更，都会产生一个新的版本，而不是直接在原有数据上进行更新。对于RC隔离级别，已经开始的读事务，仍然继续读取旧的版本，新版本对其不可见，这样读和写互相不影响，最大化读写性能。

• 分布式KV锁

ByteHouse对于DDL提供了全局KV排他锁避免并发的对table schema进行变更，分布式kv锁是全局共享，不同的节点都可以共享。

• 内存读写锁

  • 支持共享锁和排他锁
  • 支持不同粒度

ByteHouse提供了多级细粒度DML读写锁的支持，DML相关的任务可以根据需求在不同粒度持不同类型的锁。

        Table
       /      \
      bucket   \
      /         \
   partition   partition

ByteHouse对于不可见的part和版本会定期进行回收，例如merge任务生成新的part之后，对于旧的part，当不再被查询引用之后，就会进行回收，释放空间，降低成本。

点击跳转ByteHouse了解更多