知名网站建设推荐,东莞做网站服务商,有名的wordpress网站,影视拍摄制作的公司欢迎大家前往腾讯云社区#xff0c;获取更多腾讯海量技术实践干货哦~ 本文首发在云社区#xff0c;未经许可#xff0c;不得转载。大家好#xff0c;我大概简单的介绍一下#xff0c;我叫饶军#xff0c;我是硅谷的初创公司Confluent的联合创始人之一#xff0c;我们公司… 欢迎大家前往腾讯云社区获取更多腾讯海量技术实践干货哦~ 本文首发在云社区未经许可不得转载。 大家好我大概简单的介绍一下我叫饶军我是硅谷的初创公司Confluent的联合创始人之一我们公司的三个创始人都是在最开始在领这个公司做kafka开发出身的。我们公司是2014年成立的成立的宗旨想把公司做成一个帮助各种各样企业做基于kafka之上的数据流的事情。 在开始之前我想大概做一个简单的调查在座的有谁用过Kafka。大概有80%的人都用了。好谢谢。今天跟大家分享想分享一下我们的项目Kafka的发展它是怎么创建起来的然后他的一些经历。说起Kafka的话那就要回朔到2010年在这个领域我是在2010年加入领英可能很多人都熟悉这是一个提供人才和机会的社交平台。在2010年的时候领英初具了一点规模这也是领英高速成长的一个阶段。在2010年我加入领英的时候大概是600号员工我是2014年离开领英离开的时候已经发展到6000号员工在短短的四年的过程这个组织高速发展。在领英的高速发展的过程中之所以它能有这么高速发展与数据有不可分割的关系领英像很多互联网公司一样数据是它的核心领英有自己的用户通过自己提供的服务和用户交流用户把自己的数据直接的或者间接地提供给领英领英通过做各样的科研或者分析可以提取出很多新的见识和认知这些信息会被反馈到我们的产品上这个产品就会做得更有效可以吸引更多的用户到我们平台所以如果数据做得好的话可以形成一个非常好的良性循环用户可以得到更多的数据可以做更好的分析可以生产更好的产品又可以吸引到更多的用户。 数据源的多样性 从数据上角度来讲领英的数据是非常多元化的最常见的数据可能大家都知道这是一种——交易数据这些数据一般是存在数据库里的从领英的角度来讲这种这种交易数据就很简单你提供工作简历或者你上学的一些简历包括你和里面成员的连接关系都是一种交易性的数据但是还存在大量的非交易数据一些很多用户的行为数据比如说作为一个用户你点了哪个连接你输入哪些搜索的关键词这些其实都是非常有价值的信息。从我们内部的运营来讲有很多的运营服务指标一些应用程序的日志然后到最后我们很多智能手机上的一些信息这也非常有价值。所以从价值来讲这些非交易性的数据的价值不亚于这些交易性数据的价值。但是从流量上来讲这些非交易型的数据的流量可能是这种交易性数据的一百倍甚至一千万倍的数据源。下面就举一个小的例子看看领英怎么用这些数据的理念提供这个服务。 英文叫做people you may know简称PYMK这个机构做的事情就是提供给领英的用户一些推荐他想推荐一些其他的领英的用户目前还没有在你的连接里他这个推荐是怎么做的呢它内部里要用到30到40种信息把这些信息加起来使得给你最后一个推荐。举一些简单的例子比如说我们两个人去过同一个学校或者在一个公司工作过这是一个很强的信息也许我们就是需要连接在一起但是有很这种非直接的信息比如说甲和乙两个人他们没有直接这种共同的一些明显的关系但是如果在某一个很短的时间有很多人同时看到这两个人的简历那说明他们可能还有一些这种隐藏的信息使得他们值得连在一起。所以在早期的领英大家使用这个服务的话就会发现很多的推荐非常神奇。你乍一看的话可能觉得他怎么会推荐这么一个人给我但是你如果细想一下就会发现它有很多很强的理由确实是有些道理类似的在里面还有很多的服务使得他可以用到各种各样的实时数据。但当时在2010年的时候我们领英有很大的一块问题就是在数据的集成上其实是一个非常不完善的过程。这个图大概就介绍了一下当时的状态所以在上面我看到这是各种各样的数据源领英最开始是一个老牌的互联网公司所有的数据都是存在数据库里头随着理念的发展我有一个系统是收集所有的用户行为的数据很多的数据都是存在本地的文件里还有一些其他的信息是存在运行上的日志里运行一些识别监测数据。 在下游我们可以看到这是各种各样的消费端领英最开始有这种数据仓库随着时间的推移我们有越来越多实时的微服务它和这些批处理差不多也要夺取或多或少同样的从这些不同数据源而来的信息。像我们刚才讲到的这种推荐引擎它是其中的一个微服务我们有很多这样的还有一些社交的图形处理他可以分析两个节点之间比如两个领英的成员他们之间是怎么连起来的哪个连接是最强还有一些实时的搜索所以这些数量逐渐增多而且他们很多的用法是更加的实时从数据产生到它更新的系统很多时候是几秒甚至更短的一些延时。 点到点的数据集成 所以当时我们的做法是如果想把这些数据送到从数据源送到消费端的话做法就是我们说的点到点的数据集成我们知道有些数据我们想要的是把这些数据送到数据仓库里我们的做法是写下脚本或者写一些程序。过了几天我们发现很多系统里也需要读数据我们又会做一些类似的工作又在写下脚本一些程序所以我们一直在很长一段时间都在做这种类似的东西但是我写了五六个类似的数据流之后发现这是一个非常低效的做法。主要的问题是什么第一个我们要解决的问题是一个叉乘问题是和数据员和数据消费端叉乘的问题。所以每增加一个数据源就要把这个数据源和所有的消费端都连起来同样增加一个消费端的话消费端需要和所有的数据源直接连接。第二个问题就是我们在做这种点到点的流数据流的时候每做一个数据流我们都要重复很多相同的工作另外每一个数据源我们都没有足够的时间把它做到百分之百的尽善尽美所以我们觉得这个体系结构不是非常理想。 理想架构 那么如果要改进的话应该改进成什么样我们当时想如果有这么一个体系结构假设中间这个地方我们有一个集中式的日志系统能够把所有数据源的信息先缓存住如果能做到这一点我们就会把这个框架大大的简化。所以你如果是数据源的话你不需要知道所有的消费端你唯一要做的事就是把你的数据发送给中央的日志系统。同样你如果是一个消费端的话你也不需要知道所有的数据源你做的事情只是要像这种中央的日志系统去订阅你所要的消息所以我们就把刚才叉乘问题简化成一个现实问题关键的就是在体系结构里头什么样的系统可以做这个中央的日志系统所以这是我们当时在讨论的事情我们最开始的话也没有想重新造一个新的系统这个好像是一个非常常见的企业级的问题那这个企业里应该有一个类似的解决方法。如果你仔细看一看想一想中央日志系统从界面角度来讲类似于传统的消息系统。我们的消息系统一般把这种生产端和消费端分开然后又是一个非常实时的系统所以我们想为什么不尝试一些现有的消息系统当时又有一些开源的消息系统还有一些企业级的消息系统但我们发现效果非常的不好。具体的原因有很多但是最重要的一个原因就是这些传统的消息系统从它的设计上来讲不是给我们这个用法来设计的尤其最大的问题就是它的吞吐量。 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/dra... 问答apache kafka vs apache storm如何使用相关阅读陈新宇CKafka在人脸识别PASS中的应用杨原腾讯云Kafka自动化运营实践白瑜庆知乎基于Kubernetes的kafka平台的设计和实现 此文已由作者授权腾讯云社区发布原文链接https://cloud.tencent.com/dev...
