Welcome to Tencent Cloud + Community to get more Tencent's massive technical practice dry goods~
This article was first published in the cloud+ community and may not be reproduced without permission.
Hello everyone, I would like to briefly introduce. My name is Rao Jun. I am one of the co-founders of Confluent, a start-up company in Silicon Valley. The three founders of our company were all kafka developers at the beginning . Our company was established in 2014. The purpose of the establishment is to make the company a business that helps various enterprises to do data flow based on Kafka.
Before starting, I would like to do a simple survey, who has used Kafka in this room. About 80% of people use it. Okay, thank you. Sharing with you today, I want to share our project, the development of Kafka, how it was created, and some of his experiences. Speaking of Kafka, we have to go back to 2010. In this field, I joined LinkedIn in 2010. Many people may be familiar with it. This is a social platform that provides talents and opportunities. In 2010, LinkedIn began to take shape, which is also a stage of rapid growth of LinkedIn. When I joined LinkedIn in 2010, I was probably employee No. 600. I left LinkedIn in 2014. When I left, I had grown to employee No. 6000. In just four years, the organization developed rapidly. In the process of the rapid development of LinkedIn, the reason why it can have such a rapid development is inseparable from the data. Like many Internet companies, the data is the core of LinkedIn. LinkedIn has its own users. Users can directly or indirectly provide their own data to LinkedIn. Through various scientific research or analysis, LinkedIn can extract a lot of new insights and cognition, and this information will be fed back to us. On the product, this product will be more effective and can attract more users to our platform, so if the data is done well, it can form a very good virtuous circle, users can get more data, can do Better analytics can produce better products and attract more users.
Diversity of data sources
From a data perspective, LinkedIn's data is very diverse. The most common data may be known as one type - transaction data. These data are generally stored in the database. From LinkedIn's perspective In other words, this kind of transaction data is very simple. You provide a job resume, or some resumes of your school, including the connection between you and the members, which are all transactional data, but there are still a lot of non-transactional data. , some behavioral data of many users, such as which link you click as a user, which search keywords you enter, these are actually very valuable information. From our internal operations, there are a lot of operational service metrics, some application logs, and finally some information on many of our smartphones, which is also very valuable. Therefore, in terms of value, the value of these non-transactional data is no less than the value of these transactional data. But in terms of traffic, the traffic of these non-transactional data may be 100 times, or even 10 million times, the data source of this transactional data. Let’s take a small example to see how LinkedIn uses the idea of this data to provide this service.
It is called people you may know in English, abbreviated as PYMK. What this organization does is to provide some recommendations to LinkedIn users. He wants to recommend some other LinkedIn users. It is not yet in your connection. What is his recommendation? do it? It uses 30 to 40 kinds of information internally and adds them up to give you the final recommendation. To give some simple examples, say the two of us went to the same school, or worked in a company, this is a strong message, maybe we just need to be connected, but there is this kind of indirect message, For example, two people, A and B, do not have any obvious relationship in common, but if many people see the resumes of these two people at the same time in a short period of time, it means that they may still have some The kind of hidden information that makes them worth connecting together. So in the early days of LinkedIn, if you use this service, you will find a lot of recommendations are amazing. At first glance, you may think that he would recommend such a person to me, but if you think about it, you will find that there are many strong reasons for it, and there are indeed some truths, and there are many similar services in it , so that he can use a variety of real-time data. However, in 2010, we at LinkedIn had a big problem, that is, the integration of data was actually a very imperfect process. This picture roughly introduces the state at that time, so I see that there are various data sources above. LinkedIn was an old Internet company at the beginning. All data is stored in the database. With the concept of Development, I have a system that collects all user behavior data, a lot of data is stored in local files, and some other information is stored in the running log, running some identification monitoring data.
Downstream we can see that this is a variety of consumer end. LinkedIn initially had this kind of data warehouse. Over time, we have more and more real-time microservices, which are similar to these batch processing. Also capture more or less the same information from these different data sources. Like the recommendation engine we just mentioned, it is one of the microservices. We have many of them, as well as some social graph processing. It can analyze the relationship between two nodes, such as two LinkedIn members. How are they connected, which connection is the strongest, and there are some real-time searches, so the number of these is gradually increasing, and many of their usages are more real-time, from data generation to its updated system, most of the time it is A few seconds, or even shorter delays.
点到点的数据集成
所以当时我们的做法是，如果想把这些数据送到从数据源送到消费端的话，做法就是我们说的点到点的数据集成，我们知道有些数据，我们想要的是把这些数据送到数据仓库里，我们的做法是写下脚本或者写一些程序。过了几天，我们发现很多系统里也需要读数据，我们又会做一些类似的工作，又在写下脚本一些程序，所以我们一直在很长一段时间都在做这种类似的东西，但是我写了五六个类似的数据流之后，发现这是一个非常低效的做法。主要的问题是什么？第一个我们要解决的问题是一个叉乘问题，是和数据员和数据消费端叉乘的问题。所以每增加一个数据源，就要把这个数据源和所有的消费端都连起来，同样增加一个消费端的话，消费端需要和所有的数据源直接连接。第二个问题就是我们在做这种点到点的流数据流的时候，每做一个数据流，我们都要重复很多相同的工作，另外每一个数据源，我们都没有足够的时间把它做到百分之百的尽善尽美，所以我们觉得这个体系结构不是非常理想。
理想架构
那么如果要改进的话，应该改进成什么样？我们当时想如果有这么一个体系结构，假设中间这个地方我们有一个集中式的日志系统，能够把所有数据源的信息先缓存住，如果能做到这一点，我们就会把这个框架大大的简化。所以你如果是数据源的话，你不需要知道所有的消费端，你唯一要做的事，就是把你的数据发送给中央的日志系统。同样你如果是一个消费端的话，你也不需要知道所有的数据源，你做的事情只是要像这种中央的日志系统去订阅你所要的消息，所以我们就把刚才叉乘问题简化成一个现实问题，关键的就是在体系结构里头，什么样的系统可以做这个中央的日志系统，所以这是我们当时在讨论的事情，我们最开始的话也没有想重新造一个新的系统，这个好像是一个非常常见的企业级的问题，那这个企业里应该有一个类似的解决方法。如果你仔细看一看，想一想，中央日志系统从界面角度来讲，类似于传统的消息系统。我们的消息系统一般把这种生产端和消费端分开，然后又是一个非常实时的系统，所以我们想为什么不尝试一些现有的消息系统，当时又有一些开源的消息系统，还有一些企业级的消息系统，但我们发现效果非常的不好。具体的原因有很多，但是最重要的一个原因就是这些传统的消息系统，从它的设计上来讲，不是给我们这个用法来设计的，尤其最大的问题就是它的吞吐量。
Kafka第一版：高吞吐发布订阅消息系统
很多的这种早期的消息，他的设计师给这些数据库上的数据，这种消费交易型数据来设计，但是你可能很难想象把很多非交易性数据，比如说用户行为日志，还有一些这种监测数据，都通过这种传统的消息来流通。所以在这种情况下，我们觉得我们没有办法解决这个问题，但又没有一个现成的结果，那么就说我们自己来做一个事情。在2010年左右，我们做了开始做kafka的第一个版本。第一个版本我们的定位也很简单，就想把它做成一个高吞吐的消息系统，高存储是我们最重要的目的。
分布式架构
下面的话，我们大概讲讲我们怎么实现高吞吐。第一件事我们做了高吞吐，就是把在咖啡的第一个版本里，我们就把它做成一个分布式的框架。很多熟悉kafka的人都知道，kafka里面有三层，中间这层加服务层下面是生产端，然后下面是消费端。服务端的话一般有一个或者多个节点，基本的概念叫做消息拓片，这个消息源是可以分区的，每一个分区可以放到某一个节点的某一个硬盘上，所以如果想增加吞吐的话，最简单的方法就是增加集群里的机器，可以有更多的资源，不管是从存储还是带宽的角度，你都可以有更多的资源来接受很多的数据，同样我们生产端和消费端做的也是一个这种多线程的设计。在任何一个情况下，你可以有成千上万的这种生产端的线程和消费端的线程，从喀斯特机群上写或者读取数据。所以这个设计就是说在我们第一个班级有的东西很多，这种老牌的一些消息系统。
简单实用的日志存储
第二点我们做的是使用了一个日志的存储结构，这个也非常简单，但是它是一个非常有效的存储结构，所以大概是它的一些结构的话是每一个消息源的分区，都会有一个相对应的这么一个日志结构，而且日志结构式和硬盘挂在一起的所有会是通过硬盘来存储的。这个结构里面就是每一个小方块都对应了一个消息，每一个消息有一个代号，代号是连续增加的，如果你是一个生产端的话，你做的事情就是你把你要写的消息写到日志的最后面，你会得到一个新的更大的消息代号日志，再送到给消费端的话是按顺序送的，你按什么顺序写进去，他就按什么顺序送给消费端，这样的好处是，从消费端来讲你的开销非常的小，因为不需要记住所有消费端的消息，只需要记住它最后消费过的一个消息的代号。然后记住这个的话，它就可以从这个地方往后继续消费，因为我们知道所有的消息都是按顺序去做发送的，所以在这个消息之前的所有消息应该已经全都被消费过了。
两个优化
这个设计有几个好处，第一个好处就是他的访问的模式非常利于优化，因为不光是从写的角度还是从读的角度来讲，这个都是线性的写，读也是从某一个位置开始线性的读。所以从这个角度出发，利于操作系统和文件系统来优化它的性能。第二点，我们这个系统设置上可以支持同时多消费，在任何时候你可以有一个或者多个消费者，消费者他可以说从这个地方开始消费，另一个消费者可以从一个不同的地方再消费，但不管你有多少个消费者，这个数据只是存一次，所以从存储的角度来讲，它的性能和你消费的次数是没有关系的。另外一点并不是很明显的，由于我们日志是存在硬盘上的，使得我们可以同时接收实时的消费者，也可以接受一些不实时的批处理的消费者。但是因为所有的数据都在硬盘上，我们可以有一个非常大的缓存，所以不管你是实时还是不实时的，从消费者端的服务方法都是一套的，他不需要做不同的优化，唯一的就是我们依赖这种操作系统来决定哪些数据是可以从内存里提供给消费者，哪些需要从硬盘里来读。但是从这个框架的设计上都是一样的。最后一点我们做成这种高吞吐，我们又做了两个小的优化，这两个优化是有关联的，第一个优化就是批处理，所有三个层面在服务端，刚才我们说到这些消息是要存在一个基于硬盘的日志里，但是写到硬盘的话它是有一定的开销，所以我们不是每一个消息就马上写了这个硬盘，而是一般会等一段时间，当我们积攒了一些足够的消息之后，才把他一批写到硬盘，所以虽然你还有同样的开销，但你这个开销是分摊到很多消息上，同样在生产端也是这样，如果你想发送一个消息，我们一般也不是马上就把这个消息作为一个远程的请求发送给这个服务端，而是我们也会等一等，希望能够等到一些更多的消息，把他们一起打包送到这个服务端。和批处理相关的就是数据压缩，我们压缩也是在一批数据上进行压缩，而且是从端到端的压缩，如果你开启压缩的功能的话，再生产端我们先会等一批数据等到一批数据完成之后，我们会把这一批数据一起做一个压缩，击压缩一批数据，往往会得到比这个压缩每一个消息得到更好的压缩比例也是。不同的消息往往会有一些这种重复，然后压缩的数据会被从生产端送到这个服务端，那服务端会把数据压缩的格式存在日志里头在以压缩的格式送到消费端，直到消费端在消费一个消息的时候，我们才会把这个消息解压。所以如果你启动了压缩的话，我们不光节省了网络的开销，还节省了这个寄存开销，所以这两个都是非常有效的实现这种高吞吐的方法。所以我们第一个版本kafka做了大概有半年左右的时间，但是我们又花了更多的一点时间把它用到领英的数据线上，因为领英内部有很多的微服务，大概在我们2011年底的时候做完了这件事，这是当时的一些基本的数量。
生产端我们当时有几十万的消息被生产出来，然后有上百万的消息被消费，这个数据在当时还是非常的可观，而且领英当时有几百个微服务，上万个微服务的线程，更重要的是我们在做了这个事情之后，实现了这个领域内部的一个数据的民主化。在没有kafka之前，你如果是领英的一个工程师或者是一个产品经理，或者是一个数据分析家，你想做一些新的设计或者新的这种应用程序，最困难的问题是你不知道应该用什么样的界面去读取，也不知道这个数据是不是完整。做了kafka这件事情，我们就把这一块的问题大大的简化了，大大解放了工程师创新的能力。所以有了成功的经历，并且感觉kafka的这个系统非常有用，我们又往后做了一些更多的开发，第二部分的开发主要是做一些这种高可用性上的支持。
Kafka第二版：高可用性
第一个版本里的话，每一个消息只是被存在一个节点上，如果那个节点下机的话，那这个数据就没法获取了。如果这个机器是永久性的损坏的话，你的数据还会丢失。所以第二版我们做的时候，就是增加了一些这种高可用性，实现方法就是增加的这种多副本的机制。如果群里有多个节点的话，那我们可以把一个消息冗余的存在多个副本上，同一个小的颜色是多个不同的副本。在同样的情况，如果你一个机器下线的话，另外一个迹象，如果还有同样的副本，他还可以继续持续提供同样数据的服务。所以有了第二个版本之后，我们就可以把它可能够包括的数据的面能够拓展得更广一点，不光是这种非交易性的时候，一些包括交易性的数据，也可以通过我们的系统来被收集。
在2000年我们还做了一件事，那一年是kafka这个项目被捐赠给了阿帕奇基金会，当时我们做这个事也是觉得我们做的系统至少对领域内部非常有用，那我们就看看是不是对其他的公司也有一些用处，其他的互联网公司也许也觉得有用，但是我没有意识到开源了之后，他用途是非常广泛，所以往往是布局网，不只是局限于这种互联网的公司而是整个工业界。只要你的公司有些这种实时数据，你需要收集的话都可以用得上。很大的原因是一些各种各样的传统的企业，它也在经历这种软件化数字化的过程。有一些传统行业，以前强的地方可能是在那些传统的制造业，或者说有一些零售点，但现在必须在软件上或在数据上也能够比较强才可以。那kafka就从实时这种数据的集成上，给很多企业都提供了非常有效的渠道。在下一步我们经历了几年kafka的开发，知道它用途越来越广，所以我们就想做一件致力于kafka上的事，因为这个事是全职性的工作，所以我们在2014年就离开了领英成立了Confluent公司。这个公司我们是想为各种各样的企业提供方便，用的可以更广一点，现在我们的公司大概是有超过两百人。
Kafka的发展
下面大概讲一讲从14年之后我们做了哪些发展。在这之后，kafka我们主要做了两块的东西，第一块和企业级的功能有关的东西，这块主要是和数据集成有关的。第二块是和数据流处理有关的。那么两方面都会稍微讲一讲。这个就跳过去了，在企业界上我们做了很大的一块，和刚才我们最开始讲的数据集成的事情有关。很多的这种公司，如果你的公司时间比较长的话，你会发现你数据源是分散在很多的系统里，刚才我们讲的就是有kafka之后很方便，你可以把这些数据提取出来，但是不同的公司的话，你不希望每个公司都读东西来做他们自己的一套东西，所以我们设计的初衷中有两块，第一块是它有一个平台部分，里面它把很多常见的东西提取出来，做成一个模块，比如说你需要做一些数据的分布，你需要做一些并行处理，你还需要做一些这种失败检测，检测之后你能再做一些数据平衡，所以这些常见的东西都做到这个模块里面，这个模块里面又有一个开放式的接口，这个接口可以用来设计实现各种各样的不同的数据源的连接。在数据的发送端的地方，如果想搜索一些副本，我们也可以做一些类似的事情，所以这是我们做的第一块。
第二块做的就是和数据流有关的一个方面。如果你有一个系统，像kafka里能实时把很多的数据收集起来，最开始的用途是当成一个数据传输的平台。但是我们觉得加以时间的话，kafka可能并不只局限一个传输平台，而且还可以做这种分享合作的平台，有实时数据之后，你常做的一些事情比如说你要做一些这种数据流的出来，比如说把一个数据从一个格式转到另外一个格式，你可能还想做一些数据的扩充，比如说你有一个数据流，里面有一些数据的信息，但只有用户的代号，没有数据的用户的具体信息，但是你有一个可能数据库里有很多更详细的用户的信息，如果您能够把这两个信息并在一起，这个数据流就更丰富，可以使你做一些更多的更有效的处理。另外你可能也想做一些实时的数据的聚合，应用程序里，我们想把这一块再简化。
Kafka的未来
未来的话，我觉得kafka系统不光是一个实时的数据收集和传输的平台，更多的可能随着时间发展的话，它可能还是更多的数据流的处理，交换和共享的一个平台，所以我们会在这个方向上做更多的东西。未来随着很多的应用更广，我们觉得很多的应用程序会越来越变成这种实时的应用程序。所以在这个基础上，我们在kafka上可能会有很强的一套生态系统。
最后给大家分享一个小的故事。这个故事是是我们北美的一个用户，这个银行是一个比较传统的老牌银行，已经是几十年的一个历史银行，很长时间存在的一个问题是它的数据是非常的分分散的。所以你如果是这个银行的客户，你可能有一个银行的账户，你可能有一个贷款，你可能还有一个保险，你可能还有一张信用卡，以前所有这个客户的信息，因为它都是不同的商业部门，它都是完全分开的。你如果作为一个银行的销售人员，你苦恼的事就是没法知道这个客户的所有的信息。这个公司它做了一个和Kafka有关的项目，一个项目就是把所有的客户的不同的数据源信息都实时地收集起来，然后把这个信息推提供给他们上万个销售人员，这样的话销售人员在做销售的时候，就会有更有效的一些实时信息可以给客户做一些更有针对的推荐，所以这个项目就非常成功。
更多分享资料，戳下面的链接：
https://ask.qcloudimg.com/draft/1184429/hz4fk5b242.pdf
问答
apache kafka vs apache storm如何使用？
相关阅读
此文已由作者授权腾讯云+社区发布，原文链接：https://cloud.tencent.com/developer/article/1114675?fromSource=waitui
