访谈嘉宾: 郑奇煌,目前就职于杭州某互联网风控公司。主要专注于大数据、流计算和中间件,他希望自己能在技术的路上越走越远,用技术为社会创造出价值和财富。时常更新个人的博客:zqhxuyuan.github.io,分享技术学习心得。

访谈实录:

怎么对Kafka产生兴趣的?

最早,我是通过Zhuang Xiaodan在Github上改造的metaq和Liu Ady的jafka才接触到Kafka的,但并没有就此开始做深入的研究。

我在工作当中的主要任务是大数据Spark的开发,一些流任务的处理会借用Kafka。因为业务主要使用了Scala语言开发,我就想着学习一个Scala相关的开源项目。对于我来说,Spark的一些概念很难,于是就选了Kafka作为研究对象,相对来说Kafka的概念还是比较容易理解的。

决定写《Kafka技术内幕》的原因是什么?

在学习了很多关于Kafka的优秀资料以后,比如郭俊李志涛两位的博客,我想要更加深入地理解背后的技术原理,所以决定去研究源码。断断续续看了一个多月,画了很多图,就把学习笔记放在了博客上,从读者的留言反馈上看,效果还不错。也许是头脑一时发热也许是内心某种追求的激励,在2016年六七月份的时候,我联系了图灵的编辑王军花,表达了想要写书的意思。她还是很鼓励我写作的,认为这本书可以填补国内还没有出版过Kafka相关书籍的空白。当时,除了英文版的Learning Kafka之外,确实没有其他比较完整的资料了,所以这些更坚定了我写书的决心。

怎么定义“在技术上有追求的人”?在技术领域,你有哪些尊敬的人?

我觉得“对技术有追求的人”是能够利用技术为社会创造出价值和财富的人,他们推动着社会不断进步。相比这些人,我觉得自己目前还只是“码农”一枚,在精深技术的道路上还有走很长、很曲折的一段。就我所在的圈子来说,我比较崇(膜)拜Linux之父Linus和乔布斯这样的大神~

Kafka是一个什么样的工具?擅长做什么?

最开始的时候,Kafka的定位是一个消息中间件。你把消息放进去,然后另一个人从里面取出消息进行消费,甚至许多不同的人都可以取出相同的消息。Kafka主要擅长做消息生产和消费的解耦,即使消费者消费太慢了也不会影响到生产者。它的主要应用有日志收集、性能度量、网站监控等,比如把日志、性能信息等放入Kafka,再通过其他程序对数据进行分析。在最新的版本中,Kafka已经是一个成熟的流式数据处理平台了,并且也支持外部数据库导入导出到Kafka。

可以说,图解IT技术是《Kafka技术内幕》的一大特色。书中的图都是你自己绘制的吗?使用了哪些绘图工具?相比文字,绘图有哪些更高的要求?

书里面的图片有近400幅,全部是用Mac的Keynote做的。除了准确表达程序的执行步骤之外,图片能简明扼要地呈现。相比文字,用图片表达,比如不同组件之间的关联关系或是某一个变量存在的含义,更容易上读者理解接受。

听说你在写作过程中经历了重重的困难,三改稿件。跟我们分享下遇到的那些困难,以及不断修改稿件的原因?

第一稿的内容太多,代码和图片都过于详细,于是在第二稿的时候,我删掉了一些比较简单的代码和图片。删减工作并不是想象的那样简单,我必须增加过渡性的铺垫说明。另外,我是边研究源码边写作的,这虽然保证了准确性,却对写作有一定的牵制。有些源码理解起来比较困难,还得参考相关的测试用例,一点一点啃下官方的英文设计文档。有些地方会有理解不准确,就推翻重写。比如,在消费组的状态机这块,原先画的流程图太长,后来自己看起来都有困难,于是重新对这部分进行了拆解。

整体结构上,我一开始设计的顺序是生产者、Broker、消费者。原因是,介绍完Broker的数据结构,再理解消费者会比较简单。后来发现,把生产者和消费者作为客户端一起分析的话,组织结构会更好,我又把消费者移到了Broker前面。这么一调整,就要求对消费者中涉及的Broker知识提前做出简单介绍和修改。

另外,我是利用业余时间写作的,进度上确实有点慢。在这里,也对编辑的工作和耐心表示由衷的感谢,也对网络上一些网友的期待表示感谢,期望本书不会让你们失望。读者如果对本书有什么意见,都可以在图灵社区提出来。

你是一个“完美主义者”吗?认可某件事情的标准有哪些?

我觉得,既然选择了一件事情,就要弄懂它的所有细节,去深究它的实现原理。认可事情的话,我的理解是,你开发出来的某款软件用起来容易上手。当然这是相对的,你肯定要花时间去深入研究背后的技术,再困难的事情最终也一定都可以解决。

如何看待由代码堆叠而来的源码分析?

其实,有关源码分析的书籍最(被)忌(骂)代码太多。在《Kafka技术内幕》这本书里面,我已经尽量避免大段大段的代码,并且没有直接粘贴代码段的情况。我建议读者尽量打开IDE,跟随作者一起阅读源码,这种效果是最好的。

其实,我因为本书没有更多的实战部分,总觉得有很多遗憾。Linux OpenMessaging规范发起人冯嘉曾建议我在书里加上cruise-control、RocketMQ等内容,我也一开始就打算加上流处理框架与Kafka的整合,但因为书太厚了,只能忍痛割爱。如果再版的话,我会加进相关的内容。

你曾经阅读过Hadoop、HBase、Storm等的源码,对源码研究有哪些体会?

最早,我是看蔡斌的《Hadoop技术内幕》入门大数据的,一边看书一边研究源码,还整理了八百多页的学习笔记。当时还兴冲冲地在微博上发布了#图说Hadoop源码#(现在链接失效了)的系列文章,作为粉丝的深夜福利(笑)。

enter image description here

分布式文件系统看完后,我结合《HBase权威指南》学习了分布式存储框架HBase(0.94)。接着,主要是结合hseagle和fxjwind两位的博客研究分布式计算Storm的源码。当然,这几个开源项目看到最后,有些部分是没有深入进去的,不过总的收获还是蛮大的。

研究源码的时候,我倾向先学习一些优秀的博客文章,然后结合自己的理解,总结成视觉型的流程图,还要写学习笔记。说来也巧,学习完这几个开源项目,我用到的画图工具一般都是系统自带的工具,比如Window的Office/PlantUML,Ubuntu的LibreOffice,GoogleDoc,Mac的Keynote。

另外,读源码难免会遇到一些难点,这时候可以参考测试用例。开源项目的测试用例一般都是很完整的。还要订阅官方的邮件,开发人员会很耐心并且及时地解答你的问题。我在测试Kafka Streams时遇到的一些问题,就是Kafka的开发人员帮忙解决的。

请介绍下Kafka的编译原理?

Kafka首先是一个分布式的消息队列,消息队列的客户端包括生产者和消费者。开发者使用Kafka非常简单,生产者发布消息到Kafka的某个主题,消费者从Kafka的指定主题获取消息并进行消费。消息队列的服务端则是由代理节点、控制器、ZooKeeper等组件构成的,服务端的代理节点是一个集群,它实现了消息队列的的负载均衡、故障容错、副本复制等功能。

Kafka还是一个流式数据处理平台(Kafka Streams),提供了一种轻量级的流计算解决方案,部署和使用都非常简单,直接启动一个普通的Java应用程序即可。消息进入Kafka后,应用程序利用这个轻量级的库通过流计算的算子,可以做到流式地、实时地消息处理。

除此之外,为了对接不同的数据源,Kafka还支持连接器(Kafka Connect)。这样,从数据源产生数据到Kafka、实时处理流式数据、结果数据同步到目标数据源,都是围绕着Kafka这个生态系统构建的,我们可以看到Kafka从消息队列到流式数据处理平台,是在一步步成长壮大的。


更多精彩,加入图灵访谈微信!