优势：与Kafka Connect Source API类似，Kafka Connect Sink API允许利用现有的Kafka连接器的生态系统来执行流式ETL，且无需编写任何代码。Kafka Connect Sink API建立在Kafka Consumer API的基础之上，但是与它有所不同。
局限：如果写入的数据源没有可用的适配器，那么需要自行编写Kafka Connect连接器，并且调试过程会有些复杂。
4.2.5 Kafka Streams API优势：对于流处理场景，Kafka中附带Kafka Streams API，并且能够编写高级DSL（类似于函数式编程或者Spark类型的程序）或偏底层的API（类似于Storm）。Kafka Streams API完全隐藏了Producer和Consumer的复杂性，让开发者更加专注于流处理的逻辑实现上。同时，它还具有连接、聚合、一次性处理等功能。
局限：使用Kafka Streams API会让编码门槛提高，同时也可能让你业务逻辑变得复杂。
4.2.6 KSQL优势：KSQL不是Kafka API的直接组成部分，而是Kafka Streams之上的包装器。这里还是值得一说的，虽然Kafka Streams允许编写一些复杂的Topology，但它还是需要一些实质性的编程知识，尤其是新手来说。KSQL希望通过提供与现有的SQL语义类似来抽象出这种复杂性。对于开发者来说，KSQL是非常具有诱惑力的，它使得流处理器变得轻而易举。
局限：对于复杂的业务场景，对数据进行复杂的转换操作，或一些特定的需求，可能还是需要使用Kafka Streams来完成。
5.Kafka与Kubernetes结合是否效率更高？Kubernetes是Google开源的一个容器编排引擎，它支持自动化部署、大规模可伸缩、应用容器化管理。Kubernetes旨在运行无状态工作负载，这些工作负载通常采用微服务架构形式，轻量级、水平扩展。而Kafka的本质上是一个分布式的存储介质，这意味着你在使用时必需处理状态，它比微服务更重要。尽管Kubernetes支持有状态的工作负载，但还是需要谨慎使用。
那么，应该在Kubernetes上运行Kafka吗？如何让Kafka和Kubernetes互相补充，以及如何避免可能遇到的“坑”？
5.2 基础指标进程：Kafka Broker对CPU很友好，TLS的引入可能会产生一些开销。Kafka Client如果使用加密会需要更多的CPU，但是这并不会影响Broker。
内存：Kafka Broker的JVM通常可以设置为4GB-8GB之间，但是由于Kafka大量使用了页面缓存，因此还是需要有足够的系统内存。在Kubernetes中，相应的设置容器资源限制和请求。
存储：容器中的存储是暂时的，重启后数据将会丢失，但是可以对Kafka数据使用空目录卷。因此，需要使用持久化存储，存储必须是非本地的，以便Kubernetes在重启后或重新定位后更加灵活的选择另一个节点。
网络：与大多数分布式系统一样，Kafka性能在很大程度上取决于低网络延迟和高带宽。建议不要把所有的Broker放在同一个节点，因为这样会降低可用性。如果Kubernetes节点出现故障，那么整个Kafka集群都会出现故障。
5.3 性能安装Kafka之前，做POC测试是非常重要的。这样做的好处是，在遇到有关性能瓶颈问题时，可以提供帮助。而Kafka附带了两个POC测试工具，它们分别是：kafka-producer-perf-test.sh和kafka-consumer-perf-test.sh。
监控：监控Kafka指标是非常有必要的，能够让我们及时的掌握Kafka、Zookeeper集群的健康状态，例如使用Kafka Eagle来监控和管理Kafka Topic（）。
日志：日志是一个比较关键的部分，确保Kafka安装中所有的容器都记录到stdout和stderr中，并确保Kubernetes集群日志能集中管理，例如输送到ElasticSearch。
动态更新：StatefulSets支持自动更新，RollingUpdate策略将一次更新一个Kafka Pod，来实现零停机维护，这也是Kubernetes的优势之一。
扩容：Kubernetes可以很容易的将Pod缩放到一定数量的副本，这意味着可以声明性的定义所需数量的Kafka Broker。
备份&还原：Kafka部署在Kubernetes中，这样Kafka的可用性就取决于Kubernetes的可用性，如果Kubernetes集群出现故障，那么Kafka的可用性就会下降，同时，也会出现数据丢失的风险，因此需要做好数据备份策略，例如MirrorMaker，或是S3进行连接备份。
5.4 对于Kubernetes的选择