DZone>大数据专区>与Robin Moffatt一起解释Kafka的工作原理
与Robin Moffatt讲解Kafka的工作原理
在本期节目中，Confluent高级开发者倡导者Robin Moffat谈到了Apache Kafka和它的优势，事件流领域的未来，以及他作为开发者倡导者在社区中的角色。
通过
CORE -
4月22日，22 - 大数据区 -访谈
喜欢 (2)
评论
保存
鸣叫
1.70K浏览次数
加入DZone社区，获得完整的会员体验。
在这一集《鸡尾酒》中，我们与来自Confluent的资深开发者倡导者讨论了Apache Kafka、Kafka的分布式pub-sub模型所带来的优势，以及用于整合的事件处理模型如何解决与传统静态数据存储相关的问题，以及事件流领域的未来。
本集概要
- Robin Moffat 告诉我们他在Confluent担任高级开发倡导者的工作。
- 我们了解到Kafka作为一个分布式的pub-sub模型所提供的功能，以及它相对于传统的请求-响应模型的优势。
- 我们了解到ksqlDB作为Kafka之上的数据库的作用，以及它与其他数据库的区别所在。
- 如何通过事件处理促进微服务架构？
- 事件流的未来是什么样子的？
采访记录
Kevin Montalbo:欢 迎来到《鸡尾酒会上的编码》播客的第40集。我的名字是Kevin Montalbo。在澳大利亚悉尼加入我们的是托罗云的首席执行官和创始人大卫-布朗。嘿，大卫
大卫-布朗。 日安，凯文!
凯文-蒙塔尔博。 我们今天的嘉宾是Confluent的高级开发者倡导者，Confluent是由Apache Kafka的原创作者创立的公司。他是一位顶级的演讲者，自2009年以来一直在多个会议上演讲，包括QCon、Devoxx、Strata、Kafka Summit和Øredev。与我们一起喝鸡尾酒的是Robin Moffatt。嘿，罗宾，很高兴你能在这里和我们在一起!
罗宾-莫法特。 谢谢你邀请我!
Kevin Montalbo。 好的。那么，我们想先问一下你在Confluent的背景。高级开发者倡导者是做什么的，这些经验是如何让你成为Kafka峰会程序委员会的一员的？
Robin Moffat。 所以，我开发产品。这是一个有趣的角色，因为，你知道，这让我看到了我认为自己在做什么，我父母认为我在做什么，我的同事认为我在做什么。而这就像，不同的角色有不同的。但是人们对开发者倡导者的看法，如果你在Twitter或其他地方关注他们，就像他们坐飞机，他们去参加所有这些花哨的会议，以及开发者社区中的所有这些东西，每个人都在抱怨时差，就像，"是的，它很糟糕"，以及所有这些东西。
但实际上，特别是自COVID以来，开发者倡导者所做的，都是为开发者倡导，并向他们倡导。所以，这就像与开发人员一起工作，帮助他们走上与哪个软件或技术或概念的旅程。这将对他们有好处，通常对公司或基金会或任何东西都有好处，这就意味着倡导者。
所以，我为Confluent工作，就像你说的。所以，我对Apache Kafka有很大的兴趣和热情，这就像我是如何进入这个角色的。所以，我的工作是帮助开发者和架构师了解Apache Kafka，了解Confluent能为他们做什么，以及如何从它那里获得最大的利益。还有，它在哪里为他们工作。所以，这是一个有趣的事情。这不是市场营销，不是销售，不是工程，也不是产品。它是所有这些东西的一种，但又不是，然后还有其他东西。
所以，这是在帮助他们理解它是什么。有点像，你只是做一个讲座来推广它，但它也帮助他们了解它不是什么，他们可以用它做什么，他们不应该用它做什么，只是帮助他们有一个快乐的时间，如果它将是适合他们的东西。所以，这就是开发者倡导者的工作。
大卫-布朗。 抱歉打断你，罗宾。我是否听到你说你也代表开发商？就像几乎，代表开发商向Confluent公司提出？比如说，这可能是社区所要求的。这就是他们给我的反馈。你是否承担了这样的角色？
罗宾-莫法特。 是的，正是如此。是的。所以，在我看来，作为一个开发者的倡导者，这是一个非常慎重的部分。所以，我认为任何一个好的开发者都会有这种能力，能够回到公司或雇用他们的人那里，能够说，"看，这个东西不起作用，"或者说，你可能认为这个东西很好，但没有人想这样。大家想要的是这个。显然，这有点像，"嗯，每个人都有自己的意见。"因此，这种产品和工程，他们做得很好，他们有点像，为适合我们的东西而工作。
但是对于开发者的倡导者来说，这不是说，"嘿，这是我们最新的功能。这就是为什么你必须使用它"。而是说，"这是我们刚刚开发的这个很酷的东西。我们认为它能帮助你这样做。"
开发人员可能会说，"不，它不会，因为XY说我需要把它带回给产品经理，并说，"所以我们已经结合了他们的反馈，我们得到了这样的结果"。这是非常非常有价值的反馈，因为这不仅仅是来自内部。这实际上是来自使用他们的软件的人，每天都在说，"这些是我们的痛点。"因此，一个好的开发者支持者总是在倾听，总是在反馈。这不仅仅是一种告诉人们的东西。它就像帮助人们做一些事情，但它也在收集这些反馈，并把它带回去。所以，这是这个角色的一个关键部分。
大卫-布朗： 你说过，在COVID之前的世界里，你可能会在会议和类似的地方做这些工作。你会做大量的旅行。那么，在后COVID时代，这种反馈循环是如何发生的？它是社区论坛吗？
罗宾-莫法特。 是的。所以，有很多会议，是的，当然。所以，我想在COVID之前，我大概有三分之一的时间在旅行，有会议，有会谈，但我一直是网络世界的大粉丝，就像当年的方式。我已经显示出我的年龄了，就像我曾经进入IRC和类似的东西。我一直觉得人们在网上的联系方式很吸引人，就像这样。
所以，我想现在有很多Slack工作空间，有Discourse论坛。我们最近在Confluent设立了一个这样的论坛。我们在去年年底推出了这个论坛。这对于将开发人员聚集在一起来说，又是非常有用的。这也是回到了倡导者的问题上。这也是为了满足开发人员的需求。所以，我们在Confluent有一个Slack工作区，我们有一个论坛，但也有像Twitter，Reddit这样的东西，这就像开发人员在那里，所以倡导者会有点像去和他们见面。所以，你在网上和人们聊天就能得到很多反馈。
有时是公开的对话。很多时候，你会从某人公开抱怨的事情中获得非常有成效的对话。就像，我们都喜欢在Twitter上咆哮的东西，但实际上是在私下里与人们进行跟进。而不是像那些不伦不类的公司回应，"嘿，对不起，我们听说你有一个问题。你能把你的账号发给我吗，等等，等等。这就像一个企业，无聊，可怕的事情。但实际上说，"哦，这听起来很糟糕。比如，问题是什么？"有时他们会无视你，有时他们会横眉冷对。但很多时候，他们会说，"哦，实际上，问题就在这里。"而你实际上可以帮助他们解决，即使只是解决 "嗯，这是文档页。也许你错过了这个。"然后，他们有一个快乐的时光。如果没有文档页，那么这就是很好的反馈，可以带回团队说，"这件事有点不清楚，也许我们应该更好地记录它。"
大卫-布朗。 这很难，因为你几乎要被拖入技术支持的行列了。
罗宾-莫法特。 是的。这是一个有趣的、细微的界限，在宣传中究竟有多少是真正的支持论坛上的人。因为从某种意义上说，如果你所做的只是在论坛上提问，这只是一部分，但这也是在积累你在这个领域的知识。而我发现相当有用的一件事是，回答一堆东西让你了解人们有痛苦的领域，然后实际上产生了真正有用的会议讲座。因为如果人们总是在我们询问的时候遇到麻烦，然后你可以写一个谈论这个东西的会议演讲，你不能完全保证听众，因为每个人总是有这个东西的问题。所以，你的会议几乎是自己写的，因为它定义了你想谈论的领域。
大卫-布朗。 那你会向组织中的谁报告呢？是产品负责人还是开发团队？你会参与到冲刺计划本身吗？你如何把这些反馈带回来？
罗宾-莫法特。 所以，开发者关系作为一个整体，作为一门学科，往往会有不同的报告，有的报告给市场，有的报告给产品。在Confluent，它随着时间的推移而变化。随着时间的推移，它被报告给两个部门。有时，它被放在工程部下。但很多时候，这种反馈循环来自于与产品经理和工程团队建立关系，并直接回到他们身边，说："看，有这个东西。"我想随着公司规模的扩大，也许这种做法会变得更加正式。但在小公司里，这就像直接接触并建立个人关系。
大卫-布朗。 好吧，我想我们应该开始谈论卡夫卡。那么，首先，Kafka作为一个分布式的、发布的、订阅的系统，与传统的请求-回应模式相比，有什么优势？
Robin Moffat。 所以Kafka，我喜欢把它说成是事件。"让我们来模拟我们周围的世界正在发生的事情"。所以，事件描述事物，事件就像，事情发生了，"那里发生了什么？什么时间发生的？"这就是我们所处理的很多数据的起源，通过建模和以这种方式处理数据。然后你实际上是以一种方式来捕捉它，就处理这些数据的概念方式而言，摩擦力非常小。而一旦你开始把它归入其他方式，它就会很好，但要做出权衡。所以，这就是为什么在事件发生时捕捉它们是一个伟大的方式，以请求-响应的方式去做它。请求-响应在某些情况下是很好的，但很多时候你想用异步的方法来处理那些放在请求-响应中的事情。你开始阻断事情，等待响应，而其他的事情就会失败。
你就会产生连锁反应，这就像多米诺骨牌一样。所有的东西都被阻断了，等待着一个端点的响应。所以，通过使用Kafka作为你的代理，你实际上可以把消息放到一个主题上，然后其他服务异步地处理这些消息。所以，你的系统之间有更松散的耦合。它们在某种意义上仍然是耦合的，因为它们仍然在相互工作。但你是以异步方式进行的，这在很多情况下是正确的方式，但并不总是这样。
这就是问题所在，它取决于。这就是在你的系统中找出你真正需要的方式。你是否需要那种直接耦合，在我得到回应之前故意不做任何事情？还是说，这个客户刚刚下了一个订单？所以，我打算，比如说，下了一个订单，我把它放到一个消息队列里，放到一个主题里，然后其他任何需要知道我下了一个订单的人，无论是库存服务、运输服务还是欺诈检测服务，他们都可以订阅这个。
罗宾-莫法特。 这是一个话题，他们可以了解这个，但然后下订单并不取决于每一个人的回应，并说，"是的，我听说过它。实际上，你可以直接把它放到那个话题上，那些服务机构在有能力的时候就会收到这个消息。"
David Brown： 是的，我对Kafka的用例和架构感兴趣，包括pub-sub模型的部署模型，就像你在那里说的。但首先，我想谈谈数据整合，因为在你以前的博客中，你谈到了建立在传统静态数据存储上的数据整合将不可避免地以高度的耦合性和糟糕的可扩展性而告终。如何通过整合切换到事件处理模型来克服这个问题？
罗宾-莫法特。
它被发布到一个主题上。它不会从该主题中删除，直到创建该主题的人，他们已经定义了保留该数据的时间。
所以，在可扩展性方面，我想，在整合方面，我们在历史上建立系统的方式是，我在一个地方得到了这个，我想在另一个地方结束。我想回到很多很多年前。这就像，嗯，这很好。我想有一个很大的主机。我也许会把它从一个子系统复制到另一个子系统，然后继续前进几年。这就像，好吧，我们已经有了这个巨大的中央交易服务器和另一个巨大的中央数据仓库。我只是在它们之间复制这些东西。那是一种点对点的做法，这很好。
然后又快进了几年，我想我们谈论的是10、15年前，突然整个事情就爆炸了。突然间，有许多不同的数据库可以选择，有许多不同的云服务可以选择。人们在办公桌上运行软件，不再是只有这种精英的数据团队的权限。
这就像任何能够启动服务器或拥有信用卡的人，现在可以开始存储数据和生产数据，并希望你能提取数据或发送数据。因此，你结束了这个巨大的，巨大的意大利面碗的紧密耦合的混乱。但你说，"我想把数据从这个地方弄到这个地方"。而其他人会说，"好吧，我也想从这个地方得到数据，所以我要把它复制到这里，但在这个feed运行之前，我不能把它复制到这里。"然后，这个feed中断了，就像有10个人开始尖叫，而我们已经知道了其中一个人，其他9个人在后面捎带上了一个人。
所以，使用Kafka这样的东西进行整合的意义在于，当一个事件发生时，它会被发布到一个主题上。它不会从这个主题中删除，直到创建这个主题的人，他们已经定义了保留数据的时间，这可能是，我们想根据时间来保留它。比如，"让我们把这个数据保留10年或10天，或任何适合于该商业案例或基于科学的数据。让我们保留最后一张幻灯片，那个特定主题的10兆字节的价值。"或者 "确实让我们永远保留它"。这完全取决于特定的数据或你正在工作的实体。任何其他想要该数据的人都可以订阅该主题，并独立从中读取。
因此，你可以有非常，非常接近实时的数据交换，比如数据被生产出来，比如一个订单被写出来，这些其他的服务可以从中读取，并几乎即时知道它。你可以让其他系统，也许它就像一个审计系统或机器学习模型，有点像得到一些训练数据，他们可以从中读取。他们可以每天一次连接到它，然后说，"给我所有的新数据。"
但问题是，数据就在Kafka的那个主题上，任何人都可以阅读，只要有权限访问它。所以，这是一种更松散的耦合方式，说这里有一些被创建的数据，现在任何需要这些数据的人都可以访问它，但没有建立这些紧密的耦合。所以，它使它更松散的耦合。因为Kafka是一个分布式系统，所以它也使得它更具有可扩展性。所以，当你有更多的数据和更大的吞吐量时，你可以加入越来越多的Kafka经纪商，你可以从X中获得更多的可扩展性，你的消费系统可以并行地消费。所以，这样做也是非常好的。
大卫-布朗： 是的，我的意思是，当我考虑到事件处理引擎，比如Kafka，显然有像物联网这样的模型，产生大量事件的设备或LinkedIn或任何可能的东西，这是在网站上发生的一些事件，他们只需要跟踪大量的数据，因为人们正在做事情。但当然，你所说的那些交易型数据库在企业中仍然是非常重要的。那么，你如何从这些大型的SQL数据库中把事件流转到Kafka中呢？
Robin Moffat。 所以，有两种不同的方法。一种是将数据写入数据库的应用程序，对吗？这就是Kafka。所以，这取决于我们为什么要把它写到数据库里？我们把它写到数据库只是因为我们一直都是这样做的吗？我们总是把数据写到数据库里。所以，我们会继续写到数据库中，或者实际上我们会说，"好吧，我们其实一开始并没有把它放到数据库中。我们只是把它放入数据库，作为与其他系统交换的一种方式。"在这种情况下，你会说，"好吧，鉴于，如果它适合这个项目，我们就改变它，改写成Kafka吧。"
很多时候，这不是一个选项，至少在最初。最初大家都说，"不，我们不会改变任何东西。"或者说，"这个项目的范围并不是真的要做这个。"所以，你可以使用一些东西或改变数据捕获，这让你从数据库中获取数据并将其流向其他任何地方，包括Kafka。所以很多很多不同的数据库都支持这种方式。这就像细节不同，但甲骨文有一个重做日志，可以从交易日志中获取数据，这已经像在我的SQL，Postgres，所有的关系型数据库。我已经有了磁带，交易日志的概念，你实际上可以捕获事件，如插入和更新，甚至删除。你可以把这些数据从数据库中抓出来，然后你可以把它流到各个地方，包括Kafka。
大卫-布朗： 是的。很好。很多人都熟悉Kafka，但我认为很少有人会熟悉ksqlDB，它也是由Confluent生产的。现在它被描述为一个数据库，用于在Kafka之上构建流处理应用程序。告诉我们ksqlDB的目的是什么，它和传统的SQL数据库有什么不同？
Robin Moffat:是 的，所以ksqlDB真的很酷。当我加入Confluent的时候，它是一个刚刚起步的东西，看到它的发展，真是太棒了。它就像一个建立事件驱动应用程序的数据库，但ksqlDB也是一种进行流处理的方式，使用SQL声明流处理。所以，当我进来的时候，我想我是在大数据领域。我的背景是分析学。然后我开始阅读关于Hadoop和诸如此类的东西。有一个叫Spark的东西，所有这些东西，我觉得我一定被排除在外了，因为我不会写Java，我不会写Scala或任何那种人们用来做流处理的东西。然后我开始阅读关于ksqlDB的文章，并开始接触它。
我当时想，"这真是太酷了"。我可以采取一个事件流，我可以说，"我想把这个事件流转化为另一个。"我可以过滤它，我可以聚合它。我甚至可以把它连接到另一个流。我可以用SQL来表达。而SQL就像是我的面包和黄油，因为这是我的背景。所以，这就是ksqlDB让你做的事情之一；你在SQL中创建这些查询，并且连续查询，当你创建这个查询时，它实际上在服务器上继续运行。如果服务器停止了，当它重新启动时，该查询继续运行。因此，你继续处理这些数据流。
所以，ksqlDB的一个关键目的是，你可以建立这些流处理应用程序，你用SQL来表达。所以，如果你开始考虑像ETL这样的事情，在过去，你会把一些数据拉出来，然后进行转换，再把它放到别的地方，或者你把它拉出来，放到别的地方，然后根据你是做ELT还是ETL进行转换，实际上你可以通过把数据从系统中取出来，来做这个流ETL的概念。
所以，就像从一个事务性数据库中，就像你几分钟前刚开始的那样，当数据从数据库中出来时，你可以对它进行转换，充实它，做你想做的事情。然后你可以将其存储到Kafka主题中，供其他系统使用或服务使用。你也可以用Kafka Connect这样的东西把它流到下游，然后把它推送到另一个系统。
ksqlDB还做了一件非常酷的事情，这就是 "DB "这个名字的由来，因为它曾经被称为ksql。然后它被重新命名为ksqlDB，因为它实际上是在存储数据。它在内部建立了一个状态存储。所以，ksqlDB本身是建立在Apache Kafka上的。所以，它从Kafka主题读取数据，将数据写入Kafka主题。
Apache Kafka是这个持久化层。但在它里面，它有自己的状态存储，我想它在后台使用RocksDB，但他们的状态存储实际上是建立了状态。所以，如果你要建立一个聚合，比如我想知道在过去10分钟内有多少订单被处理，你可以建立这种累积的聚合器，并在内部实际持有，这相当有用，因为你有这种主干聚合。它可以被扩展到跨ksqlDB工作者，而且这种处理方式是自动的。但你实际上可以直接查询聚合。所以，你可以直接对ksqlDB进行所谓的极地查询，或者你可以使用REST API或客户端的工作。所以，如果你有点退一步说，这意味着你可以说，"我有这个数据从任何地方进来。"
我把它直接生产到Kafka，或者我从数据库流中提取，或者从其他任何地方提取。我可以运行一个查询，这将建立一个聚合，说："这个时间段的最大订单值是多少？"，或者 "我们处理了多少？"不管怎么样。它在ksqlDB内持有持续更新的状态。然后一个外部应用程序可以查询ksqlDB并说，"在这个10分钟的窗口中，我们目前处理了多少个订单？"所以，你不需要在其他地方有额外的现金或存储。你只是让你的数据被创建。它正在进入一个Kafka主题。然后ksqlDB在上面维护这些状态。
大卫-布朗： 有意思。所以据我所知，ksqlDB l基本上是Kafka流的一个接口，能够使用SQL语法查询或设置Kafka流。David Brown元素，就像你说的，是这个持久性数据存储相关的，你可以推测设置流指向另一个流，将其输出到Kafka流的持久性数据存储中。在这个时间窗口方面是否有限制，你可以查询这些数据？
所以，是的，ksqlDB，你是对的，它作为一个Kafka流应用程序运行。作为一个用户，你不需要知道任何Java，这很好，因为我不知道任何Java，所以你只需要写sql。然后在保留和类似的东西方面，你可以在创建一个叫做表的东西时定义它。
所以在ksqlDB中，你有流的概念。所以，你可以针对流进行选择。你也可以建立一个表。所以你可以说 "创建表 "作为选择你的聚合体。而这个表是由Kafka主题支持的。你可以在那个表中说，"我想在这个数据上保留什么期限？"这将归结为你所编写的应用程序的业务用例。
David Brown: 关系如何？
罗宾-莫法特。 是的。所以你可以在其中做连接。ksqlDB的最新版本是0.19，我想是昨天发布的，现在也支持外键连接。所以是的，你可以在流和表、表和流之间做连接。因此，你也可以这样做。
大卫-布朗。 你也可以连接到外部的SQL数据库，比如Oracle、Postgres数据库？
Robin Moffat： 从某种意义上说，因为你可以把这些集成到Kafka中。所以，要遵循的模式是将这些数据拉到Kafka主题中。一个经济的例子是，我有所有的数据从我的平台和我的网站平台进来。它把审计数据写进了Kafka主题，而且它有一个外键引用到客户那里。所以，它并没有完整的记录。它只是像大部分正常化。我在数据库里有我的客户数据。所以，你把这些数据从数据库中拉到一个Kafka主题中。
在这个Kafka主题中，你把它作为一个ksqlDB表来建模。所以，有一个东西叫做流表的二元性。如果你想的话，我们可以深入了解一下，但这基本上是你如何在语义上处理数据的。它是一个无边界的事件流，还是一个键值信息？所以，你可以把数据库中的数据整合到Kafka中，作为一个快照的连续变化流，然后你可以把它加入到该事件流中。所以，你可以连接到数据和外部资源。我们只是要确保你先把这些数据从外部源拉到Kafka。
大卫-布朗。 对。你之前用pub-sub的例子提到了微服务，以你的订单为例，将新的订单发布到一个消息队列中，让服务订阅这个队列，并在此基础上执行一些逻辑。那么，你能更深入地解释一下Kafka流媒体引擎是如何促进微服务架构的吗？
Robin Moffat
Kafka是有元素的。
是的。所以，这是一个能够在服务中交换信息的想法。所以你已经有了每个微服务的模型，而不是围绕请求-响应的想法来构建。所以，你知道，你的订单服务向欺诈检查服务发送一个请求，然后什么都不做，直到它从那里得到一个响应。它实际上可以把一个消息放到Kafka主题上。所以，你在不同的微服务之间异步地做这些关系，你的欺诈检查服务。
事实上，也许这实际上应该是一个请求-响应，因为你可能不希望订单继续进行，直到它被欺诈检查过。所以，这取决于背后的那种业务流程。像库存更新这样的事情，也许你会简单地说，订单服务发出一个消息说，"我们刚刚卖出了这个东西，我们已经分配了这个东西。"
所以你的库存服务将订阅这个主题。它将发现这一点，它可以更新自己的内部数据存储，但你开始以这种方式建立你的服务，使用Kafka作为它们之间的中介，因为数据被保留在Kafka上。所以，这是Kafka和人们可能熟悉的消息队列解决方案之间的关键区别之一，因为Kafka有元素，它的行为有点像消息队列，但它不像是其他队列的替代品。它是一个更广泛的技术，因为它保留了数据，不仅你最初设计的系统可以围绕它建立。你有你的订单服务，把你的消息放到一个主题上，你的欺诈检查服务和你的库存服务都可以从这里得到，其他服务也可以随后出现，也可以建立在这些数据上。
因此，就微服务而言，需要考虑的一个关键问题是围绕你的数据模式，以及你将如何管理它。以及它们之间的兼容性。因为如果你在做请求-响应，你已经有了一种像你可以交换的消息格式。这就是你要支持的API。如果你开始在一个主题上异步地使用消息，这些消息的模式就成为你的API。
所以，你需要确保当你下订单时，当你说这个订单是在这个时间戳下的，它被送到这个地址，或类似的东西，这些字段被其他服务理解为特定的格式，它们存在的地方，它们是可选的，以及类似的东西。因此，这就是为什么像模式注册表这样的东西变得非常重要，因为在第一天，你说，"好吧，我正在写这个概念证明，我明白这个数据的结果是什么。"所以，这是很明显的。我对这些都不感兴趣。
然后在第100天，你得到了一些新的开发人员，或者也许你去度假了，人们开始说，"我想这就像订单一样，所以我们就把一些数据放在这里，看起来像这样。"然后事情就开始变化了。有人改变了时间戳。而不是作为一个条形图来做，他们一直在制作Posix，Epoch 1970，事情开始中断。所以，你必须有兼容性的保证，以及你将如何与模式之类的东西一起工作，这些东西在不同的微服务之间充当API。
David Brown： 这很有趣，因为在很多这样的东西中，你认为它并不重要，因为系统是如此灵活。几周前，我们在播客中邀请了来自Mongo的倡导者David Brown。他也说了同样的话："你们这些家伙，你们真的需要在你们的模式开发上花些心思。"你也说了同样的话，这很有意思。
罗宾-莫法特。
有时候，人们不得不通过不那么出色的方式来学习，并被它烧毁。
我只是想完全同意这个观点，对吗？它的灵活性、自由度和简易性，对开发者来说是非常有吸引力的，因为它就像，"我可以拿起这个东西做事情"，但在某种意义上，它就像拿着刀子在玩耍。这就像，"去吧，请便"。但是，如果你要做，请确保你意识到可能出现的痛苦。
有时人们不得不通过不那么出色的方式来学习，并被它烧伤。然后他们就会说，"好吧，下一次，我们要这样做。"在你如何建立系统的问题上，这总是一种有趣的交易。你是否会使用一些东西，制定成吨成吨的护栏，它就像超级限制，但你不能犯任何错误，这通常是非常乏味和无聊的？或者你会说，"这就是完全的绿地。你们自己去吧，但你们要靠自己。"这是一种在什么是有成效的，但从长远来看是支持的，与什么不是一个好主意之间取得适当的平衡。
大卫-布朗。 听着，最后，我想听听你对事件流的未来的看法。我们以前有一些嘉宾在节目中，他们应该对活动流媒体有一些大的宏伟愿景，但我想你更多的是在地面上与开发人员，他们正在做什么，他们正在寻找什么。对于这个行业的发展方向，你有什么想法吗？
罗宾-莫法特。 所以，我认为这很容易被卷入其中。就像在Twitter上一样，你有这些回声室，因为你关注那些对你感兴趣的人，所以有时很容易感觉到每个人都在同一个点。当然，每个人都在建立流媒体系统。当然，每个人都在做实时流式ETL。但实际上，我认为人们刚刚开始追赶。我想云计算对于运行我们的工作负载是有意义的，因为如果你能让别人为你做的话，你为什么要自己运行它。
因此，我认为近期和中期的未来是人们意识到，由于事件是我们周围世界的模型，从事件流平台开始，比如Apache Kafka，比如Confluent来处理你的数据，无论你是建立集成管道，还是建立应用程序，这都是一件非常非常强大的事情，因为你不会失去数据的真实性。
你实际上是在与事件打交道，而这正是数据的来源，很多时候都是如此。从那里，你可以去建立状态，并把它放在关系数据库或NoSQL存储中，或做任何你已经做的事情。但我认为，思维方式的转变，从 "这是我们在过去50年中一直在做的事情"，然后 "让我们抛弃模式，称之为SQL或其他"。这都是同样做事方式的一部分。但是，与事件一起工作有一个基本的部分，然后你在此基础上建立，我认为这是一个思想的转变，它开始发生，但它仍然有相当长的路要走。我真的相信，这是一个非常、非常强大的基础，在此基础上可以实际建立系统。
大卫-布朗： 是的。我们从其他嘉宾那里也听到了同样的话。我们只是在这个起点上，无论是事件流、微服务、数字转型或任何你决定的流行语。很多这些概念、技术和架构现在都开始成熟了。是的，我们开始了解它们是如何被使用的，如何被部署。而在未来的10年里，大多数企业都会忙着做这件事。
罗宾-莫法特。 这很好，因为这就是所有这些技术的全部意义所在。它很有趣，但希望它也会发展，提供价值。它不仅仅是闪亮的盒子。
大卫-布朗： 是的。罗宾，很高兴你参加这个节目。我们的听众如何能关注你，并与你所写的东西保持联系？
罗宾-莫法特。 所以我一直在Twitter上。我在Twitter上是"@rmoff"。我有一个博客，Rmoff.net。你也可以查看Confluent Cloud，Confluent博客，我在那里也写了很多东西。
大卫-布朗： 很好。谢谢你加入我们今天的节目。
罗宾-莫法特。 非常感谢你邀请我。
节目说明
大数据 数据库 IT 关系型数据库 流处理 dev 事件 kafka
在DZone发表的文章，得到了David Brown的许可。点击这里查看原文。
DZone贡献者所表达的观点属于他们自己。
DZone上的热门文章
评论
