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上的流量发生倾斜。