00 Confluent_Kafka权威指南-前言部分

冬天里的懒猫

发布于 2020-08-03 15:46:31

6820

发布于 2020-08-03 15:46:31

文章被收录于专栏：做不甩锅的后端做不甩锅的后端

文章目录
Foreword 序
Preface 前言
谁应该读本书
本书使用的约定
使用代码示例
致谢

Foreword 序

对kafka来说，这是一个激动人心的时刻。kafka被成千上万个组织使用，包含了三分之一的世界500强公司。它是增长最快的开源项目之一，围绕它产生了一个巨大的生态系统。它是管理和处理流式数据的核心。那么kafka从何而来？我们为什么要建造它？它到底是什么？ Kafka最初是我们在Linkedin开发的一个内部基础性系统。我们的初衷很简单：有很多数据库和系统能够存储数据，但是缺少对连续不断的流式数据的处理。在创建kafka之前，我们对各种现有的技术进行选择，从消息传递系统到日志聚合和ETL工具等，但是没有一个能很好的满足我们的需求。我们最终决定从头开始。我们的想法是，与其像关系数据库、key-value数据库、搜索引擎、缓存数据库等专注保存大量的数据，我们将专注于数据的流式处理-建立一个数据系统-实际上是基于这个想法的数据架构。这个想法被证明比我们预期的更加广泛适用。虽然kafka一开始只是在社交网络场景下支撑实时应用和数据流式处理，你现在可以看到它是每个行业的架构核心，大型的零售商正在重新围绕流式数据设计他们的基础业务、汽车制造企业正在收集和处理物联网汽车实时数据流、银行也正在重新考虑建立围绕kafka的基础业务处理和系统。那么kafka究竟是怎么回事呢，它与你已经知道和使用的系统相比如何？我们认为kafka是一个流式处理平台：允许对流式数据进行发布订阅、存储和处理，这正是apache kafka的设计初衷。这种数据的处理方式可能与你习惯的方式有点不同，但是对抽象应用程序的体系结构收到了难以置信的效果。kafka经常被拿来与现有的三个技术领域做比较：企业消息系统、大数据系统hadoop以及其数据集成和etl工具。这些比较虽然能说明一部分问题，但是存在着诸多的局限性。 Kafka像传统的消息队列一样，支持对消息的发布和订阅。在这方面类似于activeMQ、RabbitMQ、IBM的MQSeries以及其他的消息队列产品。但是即便有这些相似之处，kafka还是与传统的消息队列存在跟不上的区别，使得kafka完全是另外一种系统。kafka与传统的消息系统相比有三个最大的区别：首先,kafka是一个作为完全分布式系统的集群系统。即便在规模最大的公司也能将分布式扩展到所有的应用之上。而不是像传统的消息队列，需要运行几十个单独的消息broker,手动指定不同的应用。这使得你有了一个中心平台可以灵活应对公司内部的各种数据流。其次，kafka是一个真正的存储系统，可以持久化存储你想要的任何数据。这是一个巨大的优势，它实现了真正的传输保证，其数据复制了多个副本、支持持久化，并且可以随时保存。最后，流式处理的概念大大提高了数据处理的抽象水平，传统的消息队列中，消息队列只是分发消息。而kafka的流式处理能力让你用更少的代码就可以实现对数据的动态流式计算。这些差异让kafka自成体系，简单的只是认为kafka是另外一种消息队列是没有任何意义的。另外一个关于kafka的观点，也是我们设计和开发kafka的初衷之一，我们可以把kafka看成一个实时版本的hadoop。hadoop允许周期性的存储和处理大规模的文件和数据，kafka让你可以对大规模持续的数据流进行存储和处理。在技术层面上，二者肯定存在相似之处。许多人将新兴的流式处理当作是hadoop批处理的超集。这种比较忽略了数据的连续性，低延迟的处理与自然的批处理的存储很大的不同。而hadoop的大数据分析能力，通常应用在数仓之上，不具有实时性，而kafka的低延迟特性，则让实时数据处理分析直接应用到业务的核心应用成为了可能。这使得当业务在进行的时候，可以有能力对业务的各种情况进行反应，当业务的各种情况出现时，就可以构建直接支持操作的服务，对业务进行反馈或者反馈客户体验等等。与kafka进行比较的最后一个领域是ETL或者数据抽取工具。毕竟，这些工具移动数据，而kafka也可以移动数据。这是有一定到理的，但是我认为，核心区别在于kafka反转了这个问题，kafka是一个面向数据实时处理的平台，而不是从一个系统抽取数据插入另外一个系统的工具。这意味着kafka不仅可以连接现成的应用程序和系统，还可以支持自定义应用程序来触发这些相同的数据流。我们认为围绕事件流的架构设计是非常重要的。在某些方面，这些流动的数据流是现代数据是公司最核心的内容，与你在财报上看到的现金流同等重要。结合这三个领域的能力，在所有的用例中将所有的数据流聚集到一起，这就是为什么流平台如此引人入胜的原因。

— Jay Kreps

Preface 前言

Cofounder and CEO at Confluent

对于技术类书籍的作者，你能给予的最大的赞美就是“这是我在开始学习这门课程的时候所希望看到的书”。这是我们在开始写这本书的时候给我们自己设定的目标。我们回顾这本书的写作之初，我们在生产环境中使用kafka，并帮助很多公司使用kafka构建软件架构和管理数据管道，我们不禁扪心自问：我们可以给新用户分享哪些最有用的东西能使他们从入门者变成专家呢？这本书反应了我们每天的工作内容：运行apache kafka 和帮助其他的用户以最好的方式使用他。此书包含了要成功运行kafka所需要的内容和在其上构建高性能程序的内容。我们对流行的用例进行高亮：基于事件驱动的微服务、流处理应用程序、大规模数据管道。我们也聚焦于本书内容的全面性，它的用例和架构对任何使用者来说都是有价值的。本书包括如何安装和配置kafka，以及如何使用kafka API,我们还致力于对kafka的设计原则和可靠性担保、探索kafka让人入胜的架构细节：副本协议、控制层、存储层。我们相信，kafka的设计和内部知识，不仅对哪些对分布式系统感兴趣的人来说是有趣的阅读，对哪些在使用kafka和应用程序中部署kafka的人来说也是非常有用的。你越是理解kafka内部的工作机制，就越是能对kafka的需对权衡做出更好的选择。软件工程中的一个问题是做任何事情都不止一种方法，像kafka这样的平台就提供了很大的灵活性，对于专业人士而言非常好但是对于初学者来说会是一个非常陡峭的学习曲线。通常，apache kafka 会告诉你如何使用某个特性，但是不会告诉你应该在什么情况下使用它。只要有可能，我们试图说明kafka现有的选择，涉及到的权衡、以及何时应该或者不应该使用不同的配置。

谁应该读本书

《Kafka: The Definitive Guide》kafka权威指南，主要是写给开发和使用kafka的软件工程师，也包括SRE、运维和系统管理员。他们在生产环境中安装、配置和监控kafka.我们也为数据架构师和数据工程师-需要负责设计和架构整个数据基础设施的人员编写此书。有些章节，特别是3、4、11章主要面向java开发人员。这些章节需要读者熟悉java的基础知识，包括异常处理以及并发相关内容。其他章节，特别是2、8、9、10则需要读者具备一定的linux基础，需要熟悉linux存储和网络配置。其他章节则没有使用专业术语，对普通读者均适用。另外一类人可能会对这本书感兴趣，他们不是直接参与kafka打交道，而是与需要kafka工作的人一起工作/同样重要的是，在他们的日常工作中他们也需要理解kafka的担保和平衡机制。这本书还能为哪些想让员工接受培训或者确保团队需要做什么的团队管理人提供支持。

本书使用的约定

本书使用了如下排版和印刷惯例： Italic(斜体)字体表示新术语、URL、邮件、文件名和文件扩展名。 Constant width 字体用于程序列表，以及在段落中引用程序元素，如变量或函数名、数据库、数据类型、环境变量、语句和关键字。 Constant width bold 字体显示用户应该按字面意思输入的命令或其他文本。 Constant width italic字体显示应该用用户提供的值或由上下文决定的值替换的文本。