大数据-70 Kafka 高级特性物理存储日志存储日志清理: 日志删除与日志压缩

news2024/9/28 3:22:09

点一下关注吧！！！非常感谢！！持续更新！！！

目前已经更新到了：

上节我们完成了如下内容：

在这里插入图片描述

Kafka提供两种日志清理策略：

日志删除任务会根据 log.retention.hours / log.retention.minutes / log.retention.ms 设定日志保留的时间节点。如果超过该设定值，就需要进行删除。默认是7天，log.retention.ms 优先级最高。

Kafka依据日志分段中最大的时间戳进行定位。首先要查询日志分段所对应的时间戳文件，查找时间索引文件中最后一个索引项，若最后一条索引项的时间戳字段大于0，则取该值，否则取最近修改时间。

因为日志文件可以有意无意的被修改，并不能真实的反应日志分段的最大时间消息。

从日志对象中所维护日志分段的跳跃表中移除待删除的日志分段，保证没有现成对这些日志分段进行读取操作。
这些日志分段上所有文件添加上 .delete 后缀。
交由一个 delete-file 命名的延迟任务来删除这些 .delete 为后缀的文件，延迟执行时间可以通过 file.delete.delay.ms 进行设置。

日志删除任务会检查当前日志的大小是否超过设定值，设定项为：log.retention.bytes。单个日志分段的大小由 log.segement.bytes 进行设定。

根据日志分段的下一个日志分段的起始偏移量是否大于等于日志文件的起始偏移量，若是，则可以删除日志分段。
在这里插入图片描述

日志压缩是Kafka的一种机制，可以提供较为细粒度的记录保留，而不是基于粗粒度的基于时间保留。
对于具有相同Key，而数据不同，只保留最后一条数据，前面的数据在适合情况下删除。

日志压缩特性，就实时计算来说，可以在异常容灾方面有很好的用途。
比如，我们在Spark、Flink中做实时计算时，需要在内存中维护一些数据，这些数据可能是通过聚合了一天或者一周的日志得到的，这些数据一旦由于异常（内存、网络、硬盘）崩溃了，从头开始计算是需要很长时间的。

一个比较可行的方案就是定时将内存里的数据备份到外部存储介质中，当出现崩溃时，再从外部存介质中恢复并继续计算。

Kafka即是数据源又是存储工具，可以简化技术栈，降低维护成本
使用外部存储介质的话，需要将存储的Key记录下来，恢复的时候再使用这些Key将数据取回，实现起来有一定的工程难度和复杂度。使用Kafka的日志压缩特性，只需要把数据写入Kafka，等异常出现恢复任务再读回内存就可以了
Kafka对于磁盘的读写做了大量的优化工作，比如磁盘顺序读写。相对于外部存储介质没有索引查询等工作量负担，可以实现高性能。同时，Kafka的日志压缩机制可以充分利用廉价的磁盘，不用依赖昂贵的内存来处理，在性能相似的情况下，实现非常高的性价比（仅针对异常处理和容灾的场景）。

主题的 cleanup.policy 需要设置为：compact
Kafka后台线程会定时将Topic遍历两次：

日志压缩允许删除，除最后一个key外，删除先前出现的所有该Key对应的记录，在一段时间后从日志中清理以释放空间。
注意：日志压缩与Key有关，确保每个消息的Key不为Null。

压缩是在Kafka后台通过定时重新打开Segment来完成的，Segment压缩细节如下图所示：
在这里插入图片描述
日志压缩可以确保：

任何保持在日志头部以内的使用者都将看到所写的每条消息，这些消息将具有顺序偏移量。
可以使用Topic的min.compation.lag.ms属性来保证消息在被压缩之前必须经过的最短时间，也就是说，它为每个消息（未压缩）头部停留的时间提供下一个下限。可以使用Topic的max.compactiton.lag.ms属性来保证从收到消息符合压缩条件之间的最大延时
消息始终保证顺序，压缩永远不会重新排序消息，只是删除一些而已
消息的偏移量永远不会改变，它是日志中位置的永久标识
从日志开始的任何使用者将至少看到所有记录的最终状态，按记录的顺序写入。
另外，如果使用者在比Topic的log.cleaner.delete.retention.ms短的时间内到达日志的头部，则会看到已删除的所有的delete标记，保留时间默认是24小时。

默认情况下，启动日志清理器，若需要启动特定Topic的日志清理，请添加特定的属性。