开发网站需要什么语言,连云港网站定制开发,邯郸市城乡建设管理局网站,做网站设计难吗前言
StarRocks存算分离表中#xff0c;垃圾回收是为了删除那些无用的历史版本数据#xff0c;从而节约存储空间。考虑到对象存储按照存储容量收费#xff0c;因此#xff0c;节约存储空间对于降本增效尤为必要。
在系统运行过程中#xff0c;有以下几种情况可能会需要删…前言
StarRocks存算分离表中垃圾回收是为了删除那些无用的历史版本数据从而节约存储空间。考虑到对象存储按照存储容量收费因此节约存储空间对于降本增效尤为必要。
在系统运行过程中有以下几种情况可能会需要删除对象存储上的数据
用户手动执行了删除库、表、分区等命令如执行了 drop table、drop database 以及 drop partition 等命令随着系统内 Compaction 任务不断进行合并之前的数据文件可以被安全回收
目前在 StarRocks 的存算分离表存储在对象存储上的文件类型包含如下几种
Segment 文件导入过程中会产生数据文件存算分离的数据文件格式与存算一体保持一致Txn Log 文件StarRocks 存算分离实现中每次导入或者 Compaction 都会产生一次事务每个 Tablet 在数据写入的最后阶段都会产生一个 Txn Log 文件记录本次导入新增的数据文件列表Tablet Meta 文件StarRocks 每次导入或者 Compaction 都会产生全局唯一的版本。而 Tablet Meta 文件在事务提交阶段产生存储 Tablet 特定版本的元数据信息其中主要记录了该版本所有可见的数据文件名
本文旨在描述 StarRocks 存算分离表垃圾回收的原理会针对上述两种数据清理场景分别描述其内部原理帮助开发和运维人员能更好地理解并根据实际需要做出合适的配置以在性能和成本方面取得平衡。 数据多版本技术
在介绍数据清理之前我们有必要先介绍下目前 StarRocks 存算分离的数据多版本技术以便更好地理解垃圾数据回收原理。
StarRocks 存算分离版本中数据在对象存储上的组织结构如下图所示 上图中共产生了三次数据导入事务其中
Load Txn 1:nbsp;在事务数据写入阶段生成了新数据文件 file 1 file 2该事务提交后生成了 Tablet Meta V1其中记录该版本可见的文件列表为 {file-1, file-2}Load Txn 2: 在事务数据写入阶段生成了新数据文件 file 3 file 4。在提交时根据前一个版本即 Tablet Meta V1然后加上本次导入事务生成的新数据文件file-3 file-4生成了新的 Tablet Meta V2因此该版本可见的文件列表为 {file-1, file-2, file-3, file-4}Load Txn 3: 在事务写入阶段产生了新数据文件 file 5。该事务提交时根据前一个版本即 Tablet Meta V2然后加上本次导入事务生成的新数据文件file-5产生了新的 Tablet Meta V3因此该版本的可见文件列表为 {file-1, file-2, file-3, file-4, file-5}
除了用户导入事务产生了新的数据版本在存算分离架构中系统后台 Compaction 任务也会产生新数据版本。Compaction 的目的有二: 1). 将多个版本的小文件合并为大文件减少查询时的随机 IO 次数2). 消除重复数据记录减少数据总量。
在存算分离表中每次 Compaction 同样会产生一个全新的版本。依然以上面为例假如在上面 Txn 3 之后新的事务 Txn 4 为一次 Compaction 任务并且将 file1 ~ file4 这4个文件合并成为 file-6那么该事务提交时生成的新版本 Tablet Meta V4 内记录的文件列表为 {file-5, file-6}。 观察上例并思考可知如果系统在运行过程中一直不会进行 Compaction。那么系统中的数据文永远也无法被删除。试想上例中我们即使将 Tablet Meta V1Tablet Meta V2 文件删除但我们无法删除 file-1、file-2、file-3 以及 file-4因为这些文件依然被 Tablet Meta V3 所引用。
但有了数据合并Compaction后情况就变得不一样了。上例中由于发生了一次 Compaction上图中的 Txn 4将 file-1、file-2、file-3、file-4 合并生成了新文件 file-6 并生成了新的 Tablet Meta V4由于 file-1 至 file-4 中的内容已经在 file-6 中存在因而一旦版本 V1、V2、V3 不再被访问file-1、file-2、file-3、file-4 便可以被安全删除。此时的数据版本情况如下图所示 因此综合上面的讨论我们可以发现只有在 Compaction 完成后原始的数据文件方可被删除但 Tablet Meta 文件的清理依赖其他规则。
目前我们在 Tablet Meta 组织上采用了一种高效方法
对于 Compaction 事务 我们会在其产生的 Tablet Meta 中记录本次合并任务的输入文件列表这样下次我们在清理该 Tablet Meta 时即可安全删除这些输入文件。 仍然以上面为例Compaction Txn 4 在生成的 Tablet Meta V4 中记录了本次合并任务的输入文件 file-1、file-2、file-3、file-4。这样下次系统清理掉 Tablet Meta V4 之后拿到这个文件列表便可以安全删除。
但这种删除方式也依赖一个前提即 Tablet Meta 按照版本顺序删除不可乱序。试想一下上面的例子中我们在删除版本 V4 时必须确保 V3 已经被安全删除。否则访问 V3 时就会发现 file-1 这些已经被删除了。
工程实现
本章节主要描述当前垃圾数据清理的工程实现原理。 FE 后台清理线程
当前存算分离表的垃圾回收任务以 Partition 为单位执行由 FE 节点构建清理任务并交由 CN 节点执行。具体来说FE 会同时为若干个活跃 Partition 创建 Vacuum 任务然后下发至 CN 执行。Leader FE 节点上存在后台 Vacuum 线程周期性运行每次运行时
1. 筛选出当前需要执行 Vacuum 的 Partition 2. 为筛选出的 Partition 构造 Vacuum 任务交由 FE 端线程池处理这些任务 3. FE 端线程池可同时执行若干任务由参数控制每个任务都会下发给 Partition 内 Tablet 所在的 BE 执行 在步骤 2 中构造的 Vacuum 任务中最关键的参数有三 minRetainVersion: 控制 CN 端执行时需要保留的最小版本号。FE 决定了某个分区可以最多保留多少个历史版本。避免 CN 执行时清理过猛将历史版本清理过多造成正在进行中的查询访问历史版本数据失败。 graceTimestamp: 控制多长时间内产生的 Tablet Meta 不会被清理避免在高频导入场景下刚刚产生的 Tablet Meta 被立即回收 minActiveTxnId: 用于回收 Txn Log 文件 FE 为需要 Vacuum 的 Partition 构造好 VacuumRequest 发往 CN 节点接下来 CN 节点只需要负责执行任务即可 CN 执行垃圾回收
CN 只需要负责执行 FE 下发的 VacuumRequest 即可。目前 Vacuum 任务复用了 RELEASE_SNAPSHOT 线程池该线程池在存算分离集群上无用因而可直接复用。由于该线程池工作线程数量较少默认为5这可能在一定程度上影响清理速度需要特别注意。
清理 Tablet Meta 文件
清理 Tablet Meta 实际上主要是清理如下内容
Tablet Meta 文件即从对象存储上删除特定版本的 Tablet Meta 文件如果该版本是由 Compaction 事务产生便可以收集到 Compaction 所对应的输入 Segment 文件以便接下来删除参考上面的例子删除 Tablet Meta V4 的时候可以获取可以删除的数据文件 file-1 ~ file-4
这里需要特别说明的一点是对于某个特定 Tablet 的 Meta 文件的清理是往前回溯进行的。具体来说FE 的 VacuumRequest 中记录了最大可回收版本号min_retain_versionCN 节点处理时就从该版本开始逐步向前回溯。
例如下例中假如最新的版本为 v10且系统配置保留最近的3个版本那么nbsp;min_retain_versionnbsp;便是 v8按照规则就是从 v7 开始向前回溯直到 v1。另外在回溯时我们还会获取 Meta 文件的最后创建时间如果没有超过一个特定的间隔grace_timestamp那也暂时不回收该 Tablet Meta 文件。 之所以采用这种前向回溯的方式的原因在于
避免 list 所有 Meta 文件因为 list object 调用在对象存储上效率非常低下避免从前往后扫描时需要不断获取 Tablet 每个 Meta 文件的内容以获得 Compaction Input假如 Meta 文件出现 cache miss就会产生一次对象存储访问效率低下
不妨举个例子说明如下图所示 当前系统中有 4 次事务其中
Load Txn 1导入事务产生数据文件 file-1、file-2该事务生成的 Meta V1 内记录文件为 {file-1, file-2}Compaction Txn 2Compaction 事务将 file-1、file-2 合并为新文件 file-3该事务生成的 Meta V2 内记录文件为 {file-3}同时记录了 Compaction Inputs 为 {file-1, file-2}Load Txn 3导入事务产生数据文件 file-4该事务生成的 Meta V3 内记录文件为 {file-3, file-4}Compaction Txn 4数据合并事务将 file-3、file-4 合并为新文件 file-5该事务生成的 Meta V4 内记录文件为 {file-5}, 同时记录了 Compaction Inputs 为 {file-3, file-4}
试想下如果按照顺序遍历的方式清理那么我们首先
要通过 list object 获取起始版本号为 V1产生一次对象存储的 list object 调用以 V1 为起始版本号逐个递增开始获得 Meta 文件且对于每个 Meta 文件都需要读取内容获得 Compaction Input Files 字段取得可以被清理的数据文件列表那么本例中就需要执行 4 次如下
打开并读取 Tablet Meta V1获取 Compaction Input Files然后清理 打开并读取 Tablet Meta V2获取 Compaction Input Files然后清理 打开并读取 Tablet Meta V3获取 Compaction Input Files然后清理 打开并读取 Tablet Meta V4获取 Compaction Input Files然后清理 这里需要访问 V1 ~ V4 这所有 Tablet Meta而获取 Tablet Meta 文件内容可能是一个较为耗时的动作假如 Tablet Meta Cache Miss 时就需要访问对象存储。
而通过从后往前的回溯遍历方式就可以避免上述问题但前提是需要构建好一个前向回溯链。
为了构造前向回溯链我们做了一个优化在每个 Tablet Meta 中记录了前一次 Compaction Txn 的版本号prev_garbage_version例如在本例中Tablet Meta V3 中记录了该字段为 V2而 Tablet Meta V4 由于拷贝自 Tablet Meta V3因此nbsp;prev_garbage_versionnbsp;字段值便也为 V2。 回收时首先获得 Tablet Meta V4假如判断其为安全可删除的接下来找到nbsp;prev_garbage_version这里记录为 V2因而这里便可以跳过 Tablet Meta V3直接找到 Tablet Meta V2获得其 Compaction inputs也可以被安全删除。而由于 Tablet Meta V2 内的nbsp;prev_prev_garbage_versionnbsp;为空因此便不再需要往前回溯了。这样就避免了打开 Tablet Meta V1 和 Tablet Meta V3就获得了所有 Compaction 事务的 Input Files。 清理 Segment 文件
垃圾回收的核心在于回收无用数据文件而根据上文的基本原理可知删除数据文件一般发生在清理那些 Compaction 事务产生的 Tablet Meta 文件时这些文件中记录了当次 Compaction 的输入文件列表由于这些文件已经被成功合并生成了新的文件因此这些原始输入文件可以被安全删除了。
因此对于 CN 节点来说就非常简单了在上面的清理 Tablet Meta 文件时捎带获取到 Tablet Meta 文件中记录的 Compaction Input Files 内容然后就可以安全删除。
考虑到一般对象存储提供了批量删除文件接口CN 在清理 Segment 文件时也进行了批量删除由参数nbsp;lake_vacuum_min_batch_delete_sizenbsp;控制批次大小。 清理 Txn Log 文件
Txn Log 文件在数据导入过程中产生记录本次导入或者 Compaction 过程中产生的新文件。正常情况下Txn Log文件一般在事务提交后即被删除。但异常时该文件可能会残留也依赖后台的 Vacuum 任务来统一清理。
CN 清理时首先通过 list objects 来获得当前所有的 Txn Log 文件由于 Txn Log 文件存储在单独 log/ 目录下对象数较少list 效率一般不会成为大问题然后从文件名中解析出 tablet id 和 txn id 信息接下来判断该 Txn Log 文件是否可以被安全删除原理也比较简单
判断该txn id是否比当前系统中的最小活跃事务id更小min active txn id如果是那么意味着该事务一定在 FE 上已经结束了要么已提交要么已回滚此时 Txn Log 即可被安全删除。 删除表和分区
StarRocks 目前有如下几种方式来删除表和分区 drop table xxx;nbsp; drop table xxx force;nbsp; drop partition xxx;nbsp; drop partition xxx force; 前者实现了回收站机制删除的表会先放入回收站直到一段时间后才开始真正删除。而后者则立即删除无任何缓冲时间。
当前实现中删除表会触发我们物理删除表上的所有数据而从对象存储删除数据是一个非常耗时的动作。我们将两种删除模式进行统一都统一为后台异步清理模式。用户提交的删除表命令会立即返回成功后台线程会慢慢删除表的物理数据。 删除表
删除分区的实现原理同删除表基本一致也都是将待删除的分区加入回收站中而 FE 后台线程则会不断地从回收站中取出需要被删除的 table执行真正的删除动作。
真正的数据删除在nbsp;deleteFromRecycleBinnbsp;内实现对于存算分离内表对于一个表进行物理删除时内部也是按照分区为单位逐个进行删除因为我们当前最新的版本是按照分区为粒度组织数据目录如下所示 ${cluster_uuid}/${db_id}/${table_id}/${partition_id} 而删除最终是调用了 CN 节点的nbsp;drop_tablenbsp;的 RPC 接口来执行真正的数据删除。真正删除时通过调用nbsp;remove_allnbsp;来直接将分区目录下面的所有文件一次性删除效率较高。而且可以发现这里的删除任务会被提交到一个独立的线程池来执行。 删除分区
删除分区的实现原理同删除表基本一致也都是将待删除的分区加入回收站中然后在回收站后台慢慢清理。最终的清理也是调用 CN 节点的nbsp;drop_tablenbsp;的 rpc 接口来完成真正的数据删除。这个已经在前面描述过这里就不再赘述。 缓存清理
当前的实现中回收对象存储的垃圾数据文件时并不会同步删除缓存缓存淘汰依赖自身的 LRU 机制。
