这期内容当中小编将会给大家带来有关Kafka的资源隔离是什么，文章内容丰富且以专业的角度为大家分析和叙述，阅读完这篇文章希望大家可以有所收获。
之前由于业务的复杂性和规模不大，大数据平台对于Kafka集群的划分比较简单。于是，一段时间以后导致公司业务数据混杂在一起，某一个业务主题存在的不合理使用都有可能导致某些Broker负载过重，影响到其他正常的业务，甚至某些Broker的故障会出现影响整个集群，导致全公司业务不可用的风险。
按功能属性拆分独立的集群
集群内部Topic粒度的资源隔离
集群拆分
按照功能维度拆分多个Kafka物理集群，进行业务隔离，降低运维复杂度。
以目前最重要的埋点数据使用来说,目前拆分为三类集群，各类集群的功能定义如下：
Log集群：各端的埋点数据采集后会优先落地到该集群,所以这个过程不能出现由于Kafka问题导致采集中断，这对Kafka可用性要求很高。因此该集群不会对外提供订阅，保证消费方可控；同时该集群业务也作为离线采集的源头，数据会通过Camus组件按小时时间粒度dump到HDFS中，这部分数据参与后续的离线计算。
全量订阅集群：该集群Topic中的绝大部分数据是从Log集群实时同步过来的。上面我们提到了Log集群的数据是不对外的，因此全量集群就承担了消费订阅的职责。目前主要是用于平台内部的实时任务中，来对多个业务线的数据分析并提供分析服务。
个性定制集群：之前提到过，我们可以根据业务方需求来拆分、合并数据日志源，同时我们还支持定制化Topic，该集群只需要提供分流后Topic的落地存储。
资源隔离
Topic的流量大小是集群内部进行资源隔离的重要依据。例如，我们在业务中埋点日志量较大的两个数据源分别是后端埋点数据源server-event和端上的埋点mobile-event数据源，我们要避免存储两个数据的主题分区分配到集群中同一个Broker上的节点。通过在不同Topic进行物理隔离，就可以避免Broker上的流量发生倾斜。
上述就是小编为大家分享的Kafka的资源隔离是什么了，如果刚好有类似的疑惑，不妨参照上述分析进行理解。如果想知道更多相关知识，欢迎关注创新互联行业资讯频道。
