Azure 事件中心内的日志压缩
日志压缩是使用基于事件键的保留将数据保留在事件中心的一种方式。 默认情况下,每个事件中心/Kafka 主题是使用基于时间的保留或“删除”清理策略(在保留时间过期后清除事件)创建的。 不要使用粗粒度的基于时间的保留,而可以使用基于事件键的保留机制,其中事件中心将为事件中心或 Kafka 主题的每个事件键重新训练最后一个已知值。
注意
基本层不支持日志压缩功能。
如下图所示,事件中心分区的事件日志可能包含多个具有相同键的事件。 如果你使用压缩的事件中心,则事件中心服务负责清除旧事件,仅保留给定事件键的最新事件。
压缩键
为每个事件设置的分区键用作压缩键。
逻辑删除
客户端应用程序可以标记事件中心的、要在执行压缩作业期间删除的现有事件。 这些标记称为逻辑删除。 客户端应用程序通过发送一个具有现有键和 null
事件有效负载的新事件来设置逻辑删除。
日志压缩的工作原理
可以在每个事件中心/Kafka 主题级别启用日志压缩。 可以从任何支持协议将事件引入到压缩项目。 Azure 事件中心服务对每个压缩的事件中心运行压缩作业。 压缩作业通过仅保留给定事件键的最新事件来清理每个事件中心分区日志。
在任意给定的时间,已压缩事件中心的事件日志可能具有干净部分和脏部分。 干净部分包含压缩作业所压缩的事件,而脏部分包含尚未压缩的事件。
事件中心服务管理压缩作业的执行,用户无法对其进行控制。 因此,事件中心服务将确定何时开始压缩,以及压缩给定的已压缩事件中心的速度。
压缩保证
事件中心的日志压缩功能提供以下保证:
- 始终在键和分区级别保持消息的顺序。 压缩作业不会改变消息的顺序,而只会丢弃相同键的旧事件。
- 消息的序列号和偏移量永远不会更改。
- 从事件日志开头行进的任何使用者至少会按照事件写入顺序看到所有事件的最终状态。
- 使用者仍然可以看到已标记为要在“逻辑删除保留时间(小时)”所定义的时间内删除的事件。
日志压缩用例
如果你要流式处理同一组可更新事件,日志压缩非常有用。 由于压缩的事件中心仅保留最新事件,用户无需担心事件存储的增长。 因此,日志压缩在变更数据捕获 (CDC) 、在流处理应用程序的表中维护事件以及事件缓存等方案中很常用。
配额和限制
限制 | 基本 | 标准 | 高级 | 专用 |
---|---|---|---|---|
压缩事件中心的大小 | 空值 | 每个分区 1 GB | 每个分区 250 GB | 每个分区 250 GB |
有关其他配额和限制,请参阅事件中心配额和限制。
后续步骤
有关如何在事件中心使用日志压缩的说明,请参阅使用日志压缩