111

kafka 迈进了光荣的1.0

 6 years ago
source link: http://mp.weixin.qq.com/s/5r7M7KvV-qJqVzct3W5G-A
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

kafka 迈进了光荣的1.0

Original 孙彪彪 一生数据人 2017-11-05 05:21 Posted on

首发个人公众号  spark技术分享 ,  同步个人网站  coolplayer.net ，未经本人同意，禁止一切转载

kafka 已经走了7个年头，最初就是个消息系统，现在已经演化为了一个分布式流式平台，你可以使用kafka 干一系列的事情，比如发布订阅消息，数据仓库，流失处理，离线大规模数据处理，我之前也很奇怪， 中国那么多大的公司都在使用 kafka，那么成熟的一个大数据组件，为啥还没有发布1.0正式版本， 现在终于姗姗来迟，在官方发布1.0之际，我们来看下kafka的整个roadmap。kafka 一路走来，不断的给我们带来惊喜，支持存储无限的key-vlue 数据，极其易用的连接 api https://www.confluent.io/blog/announcing-kafka-connect-building-large-scale-low-latency-data-pipelines/, 很方便地连接外部存储（mysql，es等）， 实时处理框架 Stream API https://kafka.apache.org/documentation/streams/ ，现在也支持了exact once 语义。

1.0 发布的一些新特性

  • 0.10.0 版本里开始引入的 Streams API 在 1.0.0 版本里继续演进，改进了 builder API（KIP-120），新增了用于查看运行时活跃任务的 API（KIP-130）和用于聚合分区的 cogroup API（KIP-150）。增强的 print() 和 writeAsText() 方法让调试变得更容易（KIP-160）。其他更多信息可以参考 Streams 文档。

  • 改进了 Connect 的度量指标（KIP-196），新增了大量用于健康监测的度量指标（KIP-188），并提供了集群的 GloabalTopicCount 和 GlobalPartitionCount 度量指标（KIP-168）。

  • 支持 Java 9，实现更快的 TLS 和 CRC32C，加快了加密速度，降低了计算开销。

  • 调整了 SASL 认证模块的错误处理逻辑（KIP-152），原先的认证错误信息现在被清晰地记录到日志当中。

  • 更好地支持磁盘容错（KIP-112），更优雅地处理磁盘错误，单个 JBOD 上的磁盘错误不会导致整个集群崩溃。

  • 0.11.0 版本中引入的幂等性生产者需要将 max.in.flight.requests.per.connection 参数设置为 1，这对吞吐量造成了一定的限制。而在 1.0.0 版本里，这个参数最大可以被设置为 5（KAFKA-5949），极大提升了吞吐量范围。

kafka 最初的设计思想

有人肯定有疑问，为啥1.0版本等了那么长时间，并没有一个规范来规定1.0长什么样子， 其实之所以现在才到 1.0 版本，不是因为kafka还不够稳定，kafka 之所以那么牛逼闪闪就是因为稳定性， kafka 没有到1.0版本的主要原因是因为还不够完整。

2009 kafka 刚面世的时候，是考虑设计成为一个 完整的实时数据平台，但是并没有一开始就搞一个很大很全的东西，而是找一个突破口，一个用户确实存在的痛点，这个痛点就是，如果你需要实时性，就只能是一个小数据量的队列，如果你需要处理大规模数据量，就只能是批处理，而不是实时的。实时性和数据规模二者只能选其一，kafka 最初就是要解决这个问题，kafka 要建造一个一统江湖的 实时数据平台，可以让你所有的app都跑在上面。

Image

kafka 的转变之路

kafka 开始大踏步的往前走，开始构建整个实时数据平台，一个流式的大数据平台，既要实时性，也要大规模数据， 一步一步的转变开发者的思想，原来还可以这样设计流式系统， 一个流式的数据中心，也可以叫做数据仓库，连接各种不同的外部数据源，实时流入数据到这个数据中心，刚开始这种想法有点不可思议。但是kafka用实际行动证明是可行的，大家慢慢开始用 kafka 来建设一个流式数据中心。

开始的时候kafka想着可以一步到位，实现流式存储，流式处理，但是发现这个目标有点太大，还是先解决存的问题吧，先会爬，才能跑。

第一步：  持续的日志流

要想实现伟大的目标，要先有一个持续的日志流，然后可以在全公司推广 pub-sub APIs。  虽然有一些反对，但是后面看来这个抽象对设计大规模pub-sub消息系统是极其正确的。这种API 的正确使用姿势就是， 发布者append到日志流上，整个日志流是有序的，订阅者持续地进行消费，每次记录一个消费的位置 offset，下次接着这个位置继续消费

Image

第二步，一个多副本，高容错的数据流

下面，就要打造一个高容错的kafka， 使用者一般都是把消息队列当成一个临时存储，消费完了就可以丢弃，而没有考虑长时间的持久存储，kafka的高明之处就是很重视长时间存储，其实流式数据的存储是很关键的，你想想，如果某个时间点你的app挂掉了，你还需要对以往数据从新消费，如果之前流式数据被你丢弃了，是不是就完蛋了。

慢慢的，大家都接受了一个关键的概念，区分清楚了什么是流，什么是表，其实很好理解，流动的数据就代表着这个世界的变化，是变化的。而一个表，代表这个世界在某个时间点的一个状态，是确定的。你可以订阅消费这些动态变化的表，你得到结果也是动态变化的。

第三步: 连接和流式处理 API

到这里，就需要一些方便易用的 连接api， 可以把数据轻松的流入到kafka，发布者把事件流打入kafka， 就不用关心是谁在消费它了， 实现了解耦，订阅者可以从kafka里面轻松的消费事件。kafka提供了一系列的插件用来把外部数据导入kafka， 和把kafka中的数据sink到外部系统。这里你可以看到所有可用的连接器，https://www.confluent.io/product/connectors/ ， 后面kafka 提供了 Stream API 可以让你轻松的消费流式数据，你可以把这个库嵌入到你的 app中，就不用关心流式系统底层的一些问题，直接消费就好了。

Image

第四步，多样性的使用姿势  和exact-once语义

到了这里就可以做一些高级的事情了，首先是提供了 exact-once语义， 这样你就可以放心的使用kafka 而不用担心丢失数据的问题，因为对于一些关键系统，丢数据就意味着挨骂，exact-once 可以保证你得到一个完全准确的结果，

之前kafka的api实现库是java版本的，就限制了使用范围，后面kafka提供了协议级别的能力，让你不再局限于某种语言， 另外今年8月还推出了KSQL，一个Kafka上的streaming SQL语言   https://www.confluent.io/blog/ksql-open-source-streaming-sql-for-apache-kafka/， function-as-a-service  或者 其他 collection-like DSL 来消费kafka，

kafka 的生态系统

Image

kafka 已经具备了一个生态系统的雏形， 发布订阅消息，数据仓库，流失处理，离线大规模数据处理。 kafka 花费了数十年才实现了这一目标。

欢迎关注 spark技术分享 

                              

Image

report

Recommend

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK