米拓建站官网怎么用不了,戚墅堰常州做网站,studio网站开发,校园网网络规划与设计方案导语
腾讯云消息队列 Kafka 内核负责人鲁仕林为大家带来了《Kafka 分级存储在腾讯云的实践与演进》的精彩分享#xff0c;从 Kafka 架构遇到的问题与挑战、Kafka 弹性架构方案类比、Kafka 分级存储架构及原理以及腾讯云的落地与实践四个方面详细分享了 Kafka 分级存储在腾讯云…导语
腾讯云消息队列 Kafka 内核负责人鲁仕林为大家带来了《Kafka 分级存储在腾讯云的实践与演进》的精彩分享从 Kafka 架构遇到的问题与挑战、Kafka 弹性架构方案类比、Kafka 分级存储架构及原理以及腾讯云的落地与实践四个方面详细分享了 Kafka 分级存储在腾讯云的实践与演进。
Kafka 架构遇到的问题与挑战
Kafka 架构 上图是 Kafka 目前本身的架构。腾讯云在线上环境部署 Kafka 集群的时候都是基于 Zookeeper 或者 Kraft 作为元数据存储然后使用物理机或者 VM 作为计算资源本地磁盘作为存储介质来构建集群。
但这种部署模式有以下几个问题
1. 本地状态比较重因为数据都是存在本地的任何的运维操作都需要进行数据搬迁运维复杂度较高。
2. 这种部署模式资源是 Broker 维度所以在进行线上运维的时候扩缩容都是以 Broker 节点维度进行但是节点维度的资源分为 CPU、带宽、磁盘等直接以 Broker 节点维度处理会造成资源浪费。
3. 在线上服务过程中会有故障恢复或者大量历史数据处理等场景处理历史数据会有历史数据回溯的问题造成 pagecache 的污染会影响集群整体读写 SLA。
接下来带着这三个问题来看一下具体是哪些场景。
运维难度大
上面有提到过 Kafka 集群在某些运维操作的时候需要进行数据迁移这就导致了运维难度比较大那哪些场景会涉及到数据搬迁呢 有三种情况
1、节点间数据分布不均
我们都知道稳态情况下 Kafka 中的 Patition 分区是均匀分布于各个 Broker 节点但是分区是归属于 Topic 的而 Topic 又有各种不同的业务场景不同的业务场景之间的流量是不一样的所以 Broker 节点分区均匀的情况下数据不一定分布均匀。
2、节点系统指标瓶颈带宽、磁盘、CPU 等
单节点部分物理资源出现系统瓶颈必须对节点进行升配或者扩容。
3、节点内数据多迁移较慢且影响读写。
如果日常流量比较大集群内数据过多的时候也确实会需要进行数据搬迁。
所以以上三个问题都会导致数据搬迁数据搬迁在数据量大的时候会涉及到天级别的运维跨度这其实在线上是难以接受的。
资源浪费
分析系统瓶颈考虑的资源基本就是 CPU、磁盘、带宽还有内存。 CPU 压缩算法Gzip、Snappy、Zstd等 消息格式转换V0、V1、V2
Kafka 如果使用消息压缩那么就需要在服务端解压缩进行校验就会消耗大量的 CPU(Gzip 压缩损耗尤其大)。另外在云上客户端的环境是较为复杂的客户端的版本使用场景使用姿势都是未知的。
另外客户在购买腾讯云 CKafka 集群时可能并不关注集群的版本信息可能购买的集群版本跟他使用的 SDK 的版本并不是一致的还会涉及到消息的协议转换也会损耗大量的 CPU。
磁盘 存储空间大量冷数据存储 历史数据 Tail-Read 读取磁盘 IO 瓶颈 HDD 磁盘导致大吞吐下磁盘 IO 瓶颈 带宽 瞬时流量突刺 集群扇出度/读写比大
内存
● Broker 限流后产生大量的 Delay 操作
综上所述Kafka 在不同使用场景模式下造成的资源瓶颈都是不同的。线上可能就是遇到一个或者几个场景那么就会带来节点级别的资源损耗。
以上问题大家也都比较了解这些问题都是因为 Kafka 本地状态比较重存储在本地存储和计算资源没有解耦造成的要解决这些问题就需要引入比较成熟的弹性架构来帮助它实现架构上面的弹性资源的解耦。
Kafka 弹性架构方案对比
存储计算分离架构
存储计算分离架构是最开始考虑的也是目前 Pulsar 采用的架构Pulsar 底层的存储是 Bookkeeper图中的架构是 HDFS 作为存储底座该架构就是一套云原生的存储计算分离架构。 Proxy 负责统一接入负责服务发现、限流包括格式转换一些通用需求的功能上传上浮化。 Broker 作为 Partition 的 Holder 用来适配多套存储介质比如 HDFS、Bookkeeper 起到 Partition 之间的负载均衡的作用。 存储层可以用到多模的存储比如 HDFS、腾讯云 COS、亚马逊 S3 等。
这个架构优势比较明显可以看到计算资源跟存储资源是完全解耦的扩容的时候有以下优势 节点扩容无需进行数据迁移 存储节点与计算节点分离可以按需扩容
虽然从理论上看是有优势的但从实际落地来看有两个比较明显的问题。
1. HDFS 或者 Bookkeeper 都会遇到一个问题就是切文件的时候。老文件需要进行 Recover Lease新文件需要进行元数据的存储(强依赖 Zookeeper/Etcd 等)所以在切换文件的时候会有毛刺抖动。
2. 可以看到存储系统加 HDFS 在这个架构里面其实是一个强依赖关系如果它断了那么生产消费都是运行不上去的只能等系统恢复。
这两个问题在线上是比较严重的问题而且很难找到非常靠谱的存储系统去承载它强依赖的关系在系统设计过程中也是不可取的最好是对外部系统弱依赖。
弹性的本地存储架构 第二个架构是目前 CKafka 比较广泛的一套架构核心逻辑就是云盘 云主机然后依赖自动化运营系统结合云盘的 LVM 以及云主机的热迁移实现快速扩容。
自动化运营系统就是用来监控资源的使用量比如说使用的是100G的磁盘已经用到90G了那么就可以用自动化运营系统监测到 90%的磁盘需要进行磁盘扩容那么我们就可以自动化的申请云盘做 LVM 增加存储空间以及吞吐能力。
自动化运营系统同时会监控计算资源节点的运行情况监控发现计算资源如 CPU、内存有瓶颈则会使用腾讯云 CVM 或者容器的热迁移进行计算资源的垂直升配。
这是目前腾讯云线上正在使用的一套产品架构但是这个产品架构之前也说到了是有缺陷的。它只能垂直扩容但是分布式系统都是分布式的只以垂直扩容肯定是不够的肯定要在横向具备扩容的功能所以说这种系统在横向扩容领域还是和原生 Kafka 系统有类似问题。
弹性的远程存储架构 所以针对以上两个弹性架构带来的问题作者又思考了一些新的可能看能否本地存储和远程存储结合起来Kafka 的分级存储本地会有少量的云盘热数据远程存储有大量的冷数据。 本地弹性存储 本地存储服务写流量/Tail-Read 读提供与原生 Kafka 一致的延时、可用性和一致性。 远程存储故障或者性能衰退本地存储支持弹性扩容提供读写服务。
远程弹性存储 远程存储服务 Catch- Up 读冷热数据分离。 按需使用按量计费。 支持多模存储多介质存储。
优势
1、 第一个优势在于写入延迟和本地写入延时是一致的在远程存储出现故障或者毛刺的时候可以退化为本地存储再结合自动化运营系统对本地存储形态进行动态扩容。
2、 第二个优势在于远程的存储相对廉价可以从一定程度上实现降本。
结合成本以及服务稳定性以及可落地性这几方面我们选择本地存储远程存储构建 Kafka 的弹性架构。
Kafka 分级存储架构
接下来我们来聊一下分级存储当前的加固是怎么实现的包括它的语义是什么它能提供怎么样的数据的生命周期管理
分级存储读写流程
分层生产流程
生产的主体流程和原生 Kafka 类似写入到云盘的数据会异步同步到远端存储 COS。 分层消费流程
消费的流程也是类似的会根据用户 Consumer 的 Offset来做一个比较如果是在本地存储那么就本地存储优先返回。如果本地存储没有那就从远端存储里面去实时读取或者说根据不同的读取策略有不同的读取下载策略进行消息读取的消费。 数据生命周期
引入了分层存储之后数据就不只存储在本地了就涉及到远端跟本地的数据生命周期的管理。 上面这四个图就是一个完整的开启分层存储之后数据的流转。
1. Kafka Broker 存储数据的最小文件单元为 SegmentSegment 可以划分为 Active/Inactive 两种类型Active Segment 是指当前正在写入的 SegmentInactive Segment 则反之。
2. 开启分层之后只会上传 Inactive Segment对应图中开启分层后先上传 Segment 0。
3. Local Rentention 参数Inactive Segment 上传到远程存储之后本地其实可以删除了这里设计了一个参数 Local Rentention控制本地已上传文件的保存时间。
4. Rentention 参数该参数在原生 Kafka 中就有体现该参数的语义为 Topic 数据的保存时间对应图中到 Rentention 时间之后远端数据进行数据删除。
这 1-4 步骤的状态流转即构成了 Kafka 本地以及远端数据的生命周期管理。
Offset 约束
Kafka 中每条 Message 都对应 Offset 位点消息数据涉及从本地上传到远端所以对于上传的 Offset 是有一定约束的。
图一 图二 图二中从左到右分别为 Lz,Ly,Ry,Lx,Rx。 Lz(Local log end offset)本地数据中最新数据的 Offset 位点。 Ly(Last stable offset)本地数据中符合消费可见的数据Kafka 中有 消费可见/事务可见 两种消息隔离级别。 Ry(Remote log end offset)远端数据中最新数据的 Offset 位点。 Lx(Local log start offset)本地数据中最老数据的 Offset 位点。 Rx(Remote log start offset)远端数据中最老数据的Offset 位点。
Offset 约束为 Lz Ly Lx 和 Ly Ry Rx 两条规则。
Segment 状态机
上文有提到过数据从本地上传到远程是按照 Segment 维度进行上传的那么每个 Segment 在上传过程中就会有各种状态通过 Segment 状态机可以实现 Segment 状态流转以及状态管理。 Segment 状态流转主要体现在三个维度CopySegmentDeleteSegmentDeletePartition。 CopySegment ○ CopySegmentStarted - CopySegmentFinished DeleteSegment ○ DeleteSegmentStarted - DeleteSegmentFinished DeletePartition ○ DeletePartitionMarked - DeletePartitionStarted - DeletePartitionFinished
同时状态流转中从一个状态转换到另一个状态是有限制的比如不能只能从 CopySegmentStarted - DeleteSegmentStarted从 CopySegmentStarted到DeleteSegmentStarted 必须保证CopySegmentStarted - CopySegmentFinished - DeleteSegmentStarted。
分级存储架构
上文介绍了 Kafka 分级存储的读写流程、数据生命周期、Segment 状态流转那么这些逻辑在 Kafka 原生系统中是在哪里实现的呢
下图中介绍了整个 Kafka 存储的类以及架构图 Kafka ReplicaManager负责管理本地存储 LogManager 以及远程存储 RemoteLogManager。 本地存储 LogManager负责本地数据的生命周期管理。 远程存储 RemoteLogManager负责远程存储的生命周期管理以及 Segment 元数据管理。 ○ RemoteStorageManager 负责远程存储的生命周期管理。 ○ RemoteLogMetadataManager 负责 Segment 元数据管理。 元数据存储 ○ ETCD/ZooKeeper 作为元数据存储服务负责元数据的存储以及 Recovery。 腾讯云的落地与实践
Segment 元数据管理
如下图 依赖内部 Inner-Topic 作为 WAL 进行元数据信息同步。 Broker 消费 WAL 进行内存状态机状态构建。 Broker 定期持久化内存快照 Snapshot 以及快照对应的 Offset 到 Broker 本地。 Broker 依赖 Snapshot 和增量 WAL 进行状态机 Recovery。 消费性能
上文读写流程中介绍了写流程其实和原生 Kafka 是类似的所以写性能基本和原生 Kafka 持平大家可能都比较担心读取性能比如读取历史数据的吞吐、SLA、数据可靠性等。在线上实践过程中我们使用 COS 作为远程存储在初步实践过程中发现直接使用 COS Stream 流式读取会有性能瓶颈问题。使用以下几个方案去提升读取性能。
1. 预加载的方式规划内存池进行消息的预读和预加载。
2. 有空闲资源时对热点数据提前下载。 隔离性
因为引入了第三方存储大家也知道线上的稳定性是第一重要的稳定性就是生命性所以说它的隔离性也是非常重要的。
硬盘
独立的 IO 盘减少磁盘 IO 影响
CPU 核心线程进行绑核 线程隔离
带宽 上传/下载限流 上传/下载任务并行度控制
内存 使用堆外内存 ByteBuffer 复用
回滚 暂停分层上传能力 按需暂停分层数据下载能力 运营系统自动扩容云盘 支持 Topic/集群维度回滚
未来展望
整体落地的架构以上都有介绍的比较清楚最终我们还是讲一下未来怎么发展。
大家都知道数据存到第三方存储之后你对这部分数据的可操控性就强了很多因为数据存在HDFS那么你对文件就有操纵的能力。 Schema
消息格式存储Protobuf、Json
目前大数据、数据符这种概念在业界传播很广在各大厂或者各个公司都有不同的场景Broker 把这部分数据转存到 HDFS 或者COS的时候我们也可以转存一份 Schema或者Protobuf、Json等。Broker只是做计算层不光可以上传数据也可以把 Schema 这个功能运用起来然后把那个数据格式进行转化。
接入层
流量接入无状态可横向扩展
Compute Engine 格式转换计算层如行列格式转换Parquet Parquet 直接对接 Hudi/Delta Lake 云 Api 获取文件
存储层 多模存储数据分级 软硬件结合探索新的存储系统
