将Azure Cosmos DB与Apache Kafka FT连接。Ryan Crawcour

将Azure Cosmos DB与Apache Kafka FT连接。Ryan Crawcour

介绍

当为微软Azure客户建立解决方案时，跨越在ApacheKafka®生态系统中深深侵犯的客户并不罕见，并希望继续在其中扩展。因此，弄清楚如何将Azure第一方服务连接到这个生态系统是至关重要的。

Ryan Crawcour是一个微软工程师，他们一直在努力过去10年以上的数据和分析，包括建立像Azure Cosmos DB这样的服务，这些服务由全球数百万人民使用。最近，Ryan采取了一个面向客户的角色，他可以帮助客户建立使用Microsoft Azure云平台和开发工具的最佳解决方案。　

在一个案例中，Ryan帮助客户利用他们现有的Kafka投资并在Azure中的持久托管数据库系统中持续存在。他们选择了Azure Cosmos DB，一个完全管理的，分布式的现代NoSQL数据库服务作为他们的首选数据库，但问题仍然是如何将来自Kafka基础架构的事件养成Azure Cosmos DB，以及它们如何从中获得变更他们的数据库系统回到了Kafka主题。　

虽然整合在他的血液中，但瑞安承认他对卡夫卡的世界相对较新，并且已经学会了达到他在客户的环境中找到的内容。通常这是kafka，出于许多充分原因，客户不想更改其解决方案基础架构的这一核心部分。这导致他围绕着kafka和围绕它的生态系统，使他能够更好地为客户服务。　

他一直在追踪Kafka Connect的发展和进展。对他来说，它是来自Kafka的自然步骤，作为kafka作为一个关键柱子的消息传递基础设施。 Kafka Connect可以被认为是一块中间件，可用于以双向方式将各种系统连接到Kafka。这意味着将来自Kafka的数据纳入下游系统，通常是数据库，以及在这些系统中发生的更改，并将其发布回Kafka，其中其他系统可以反应。　

有一天，客户问他如何将Azure Cosmos DB连接到Kafka。当时没有连接器，所以他用汇合团队帮助建立两个：一个水槽连接器，其中数据从Kafka主题流入Azure Cosmos DB，以及Azure Cosmos DB的源连接器是源头数据推动数据库中发生的更改进入Kafka主题。

成绩单

蒂姆·贝格尔顿：

大多数时候要与Kafka Connect进行集成，您需要的连接器已经存在，但有时它不会。今天，我与Microsoft Ryan Crawcour交谈，关于构建COSMOS DB的连接器作为Azure中可用的多模型分布式数据库。我们讨论了Cosmos DB的所有内容和一些酷炫的东西，这些内容在当今的媒体音频剧集中建造了这一点，即关于Kafka，Confluent和云的播客。

蒂姆·贝格尔顿：

您好，欢迎来到另一章流音频。我再次成为你的主人，蒂姆·贝格兰。我今天加入了Ryan Crawcour的虚拟工作室。 Ryan是Microsoft的客户工程师，他将与我们谈论Cosmos DB和Azure Service以及Kafka Connect。瑞安，欢迎来到演出。

Ryan Crawcour：

谢谢蒂姆。很高兴在节目上。长期听众，第一次扬声器。

蒂姆·贝格尔顿：

爱它，爱它。好吧，瑞安，感谢您是一个听众。在我们进入宇宙和所有这些之前，请告诉我们实际上自己。

Ryan Crawcour：

当然。

蒂姆·贝格尔顿：

无论如何，客户工程师在Azure做了什么？

Ryan Crawcour：

好问题。我是微软的工程师10多年，我已经在产品工程团队的幕后工作。我们在微软呼吁客户工程部分，作为工程师，我们与我们的合作伙伴和客户密切合作，以构建解决方案，对他们的问题，对吧？所以潜在的第一方服务没有他们需要的确切能力。

因此，我们将建立一个桥梁，这使得能够更容易地通过我们的平台和服务，或者我们将与他们合作，共同工程师在我们的云的一种经验中使用它们最佳地工作我们与其他大客户有过。这通常是我们所做的，我们是一名工程师，为客户和客户提供工作，我猜是最重要的。

蒂姆·贝格尔顿：

这就是你所做的那种工作，通常是面向基础架构，还是你在应用程序开发上充满了？

Ryan Crawcour：

好吧，所以我们有了我们的不同部分。我猜，通过基础架构的基础设施更多的基础架构是代码的。我们在建立基础架构方面涉及很多，以及如何创建一个安全，可扩展的云解决方案，并且足够灵活。以及如何重用订阅中的资源和这些类型。

我们确实参与其中，但我们通常更涉及特定解决方案。它是事物的数据分析侧，或它的消息传递解决方案，或者是我们可能需要的集成类型场景或数字功能。这是一点，但我会说它更加解决客户的解决方案。

蒂姆·贝格尔顿：

凉爽，凉爽。如果您是云提供商，总是可以完成，从根本上讲，您是基础设施提供商。你的作品在其中建造了一件事。

Ryan Crawcour：

哦，究竟。这里有一些硬件在我们的数据中心运行，用它做点什么，对吗？猜猜我的工作是帮助客户用它做更多。

蒂姆·贝格尔顿：

对。您听到的所有内容都是数据库，但它可能是一种高水平的抽象。或者我们是融合的，我们有融合的云，这里是天空中的Kafka。你仍然有东西可以建立在那之上，这仍然是一个 -

Ryan Crawcour：

哦，你有各种各样的东西到那个碗。而且你需要确保......它可能只是一个简单的客户喜欢在锈症中发展。哦，看，没有生锈的Azure服务器SDKS，对吗？好吧，让我们坐下来与客户一起工作并在潜在的锈病中建立一个SDK？或者任何案例可能是什么。

但是，是的，总是有些东西的工作，因为每一个客户都是独一无二的，每位客户都会略有不同。有时这是他们的竞争优势，以及他们的差异化，你不能指望每位客户捕捉到完全相同的解决方案。我们采取了与他们在那里遇到的客户的方法，从那里工作。这就是我的团队所做的。

蒂姆·贝格尔顿：

爱它。现在我们将谈论连接，以及集成Kafka和Cosmos DB的过程。但我在想我实际上是完全愿意承认的，我不知道，Azure Cosmos DB，一切顺利，我打赌我并不完全独自在观众中。所以告诉我们这件事。

Ryan Crawcour：

Cosmos DB是一个令人兴奋的产品。在我加入这个团队之前，我实际上是产品工程团队的一部分，使Cosmos DB Live作为产品，对吧？

蒂姆·贝格尔顿：

你知道它很好。

Ryan Crawcour：

我知道它很好，但是在当天回来，我们有很多内部的Microsoft产品，或服务，或来到数据团队的领域并说：“嘿，我们正在寻找一个可以执行以下操作的数据库事情，对吗？“我们打开了，我们看了，我们就像，“好吧 -

蒂姆·贝格尔顿：

没有一个。

Ryan Crawcour：

“没有一个。”我们幸运的是，我们有一个研发团队，我们将它扔到墙上到研发团队，并说：“你能帮助我们吗？”他们提出了一些非常有趣的事情来解决一些非常令人敬畏的挑战。那是一个服务的开始，服务，对吗？ Cosmos DB，它是一个NoSQL数据库，它从地面设计为云。

我们没有采取一些盒子产品和一种Cliberify IT，它是由地面构建的，以成为多区域分布式云数据库，在读取和写入方面具有超低延迟。我认为我们仍然是任何在实际性能上提供SLA的云服务数据库之一？所以我们会给你一个说“这是百分位数”的SLA，我不记得掉手的号码，“但它的读数总是在五毫秒内，你的写入百分比将永远在五毫秒内两毫秒，或任何数字。“因此，我们实际上保证了在SLA级别，这是我想的非常独特的。

蒂姆·贝格尔顿：

听到关于强加极其受欢迎的云数据服务总是很奇怪。没有SLA。

Ryan Crawcour：

确切地。我的意思是，不仅有一个正常运行时间SLA，我的意思是，正常运行时间是伟大的，但实际上是一个表演SLA，我们认为真的很大 -

蒂姆·贝格尔顿：

这是典型的。

Ryan Crawcour：

它很糟糕。我认为这是它在开始时恢复到工程的地方。它真的从一开始就是这样，对吧？它被设计为这款令人难以置信的呼应，响应，低延迟的服务。它的超级容易......它在我们拥有的每个单一的蔚蓝的中心运行，因为它是我们的环零服务之一，并且通过环零服务我们的意思是，许多其他服务依赖它，所以它必须在那里其他服务存在并运行。

它位于每个蓝色区域，超级易于开启多区域读取，超级易于开启多区域写入。您只需在短划线或您想要的任何内容中转到门户或CLI命令并通过此启用它。在几秒钟内，您可以在多个地区拥有您的数据库，您甚至可以写入多个不同的区域，并将其分析冲突和复制以及为您提供的东西。所以它真的，真的很酷的数据库。我们用它的另一个酷东西之一是我们开始作为核心json数据库，对吗？所以JSON文件，就像我一样 -

蒂姆·贝格尔顿：

我要问，数据模型API。

Ryan Crawcour：

数据模型，所以我们开始作为JSON NoSQL数据库。然后我们认为，我们在我们在我们的评分数据方面都在封面下做了什么，以及我们如何建模，以及我们如何复制它，以及我们如何保持高变量正常运行时间，在同一平台上有其他数据库模型有意义，对吧？

我们实际上在Cosmos DB之上添加了，所以它是相同的核心引擎，但我们现在可以运行GremlinG图数据库。因此，您可以与Cosmos与Gremlin进行交流，您可以使用Mongo API与Cosmos与Cosmos交谈，您可以使用Cassandra API与Cosmos交谈，您可以使用键值API与Cosmos交谈。就数据库而言，有一堆API现在坐在数据库的顶部，包括我们的核心JSON的SQL API。

但是有一堆这些其他API坐在核心引擎的顶部。因此，您现在跨多种不同类型的模型获得相同的多区域读写功能。而且你不必为你弄清楚封面下的基础设施，这为你完成了。您所做的只是单击一个按钮并使用它。

蒂姆·贝格尔顿：

是的是的。并使用您选择的API。非常酷。

Ryan Crawcour：

是的，它非常好。

蒂姆·贝格尔顿：

但是，在某种程度上有一个潜在的数据表达，你可以剥离一些洋葱层，你可以到达那个。和 -

Ryan Crawcour：

您可以剥离耦合，我的意思是，数据全部存储在公共数据模型中。在大多数情况下，如果我们谈论cosmos db的核心，它将被认为是json文件。

蒂姆·贝格尔顿：

Gotcha，因为这就是它的开始。

Ryan Crawcour：

是的，这就是它的开始。

蒂姆·贝格尔顿：

好，好，因为我坐在这里想，哇，我们还有20分钟的谈话。我们如何谈论连接器？因为这对所有这些模型都很难，但是你是连接器，我假设选择一个型号。有一个API可以进入“真实的Cosmos数据”。你经历了 -

Ryan Crawcour：

哦，是的，我的意思是和这个漂亮的事情，以及多模型工作的方式，如果你使用蒙古API对阵COSMOS DB，对吧？我们不必为它构建连接，因为猜测是什么？ Mongo建于Mongo数据库连接器。

蒂姆·贝格尔顿：

足够公平，有一个。

Ryan Crawcour：

如果您使用Mongo API，请使用Mongo连接器，对吧？使用Mongo SDKS，使用您的Mongo类型的司机，使用您的Mongo Tooling，以及您的Mongo Ecosystem。这就是为什么我们建造它，对吧？它桥接那种差距，你不必将所有代码从Mongo驱动程序转移到Cosmos DB特定驱动程序。您可以使用不同的API。与cassandra相同，我的意思是，如果您在Cosmos DB上使用Cassandra API，并且您希望将数据从Kafka泵入Cassandra，请使用Cassandra连接器，右图？

我们为核心API构建了SQL核心连接器，以及我们称之为SQL的原因，这不是因为它代表了一个关系数据库系统。它不是SQL Server，对吧？这只是您用来与JSON文件交谈的查询语言的表示吗？因为所有SQL都真的是一种结构化查询语言。

所以从一些容器中选择某些条件是真的，订购的东西，对吗？我们认为这是典型的SQL语法，然后我们将使用它来转移和查询我们的后端商店。其他JSON数据库有一种非常具体的语言，您可以使用它与他们交谈。我们认为人们对SQL非常舒适。那么为什么不给他们一个SQL方式与他们的JSON数据库交谈。

蒂姆·贝格尔顿：

这不是大多数JSON数据库如何做到，但听起来很令人愉快。

Ryan Crawcour：

是的，如果你熟悉SQL，那肯定非常愉快。如果您不熟悉SQL，那么，它并不难以学习。

蒂姆·贝格尔顿：

确切地。如果你不熟悉SQL，那么你很快就会成为，那么有时会欢迎来到专业人士。我们很高兴在这里。而你即将学习。

Ryan Crawcour：

就是这样，我的意思是，如果你在生活中的某些时候与数据库一起工作，你可能会以某种方式遇到SQL，对吧？在一些味道中，无论是Oracle，还是MySQL，或Maria，或Postgres，或SQL Server，您将在您的生活中遇到SQLS。

蒂姆·贝格尔顿：

确实是你。好的，那很酷。我实际上并不知道关于cosmos db，那里有很多很酷的东西。让我们走上连接器。因此，您将一个连接器作为客户工程的一部分，这听起来正是如果连接器不存在的那种会出现的东西，客户需要将数据纳入或退出Kafka或两者。我们来了。

Ryan Crawcour：

那就对了。我的意思是，我们正在与客户合作，解决方案建筑师进入，并与客户说话，这很棒。而客户与Kafka和Kafka的关系很长，并不希望远离Kafka，但希望在Azure中运行。

蒂姆·贝格尔顿：

我已经喜欢他们了。

Ryan Crawcour：

他们来找我们，说：“好吧，我们该怎么办？”客户有这些消息，拥有整个生态系统，以及围绕Kafka建造的工具。他们绝对想要保留这一点。但他们看到了很多Azure Cosmos DB，我们如何在它们之间建立这种整合？我们有点看，我们去了，“好吧，你可以写一堆自定义代码，然后你可以拥有一堆部署在Kafka读者和作家的应用程序，你可以做到这一切自己自己。“

我们与客户交谈，他们就像，“我们真的不想要那样，我们的整个Kafka环境得到管理，我们现在不想拥有这种非托管的东西 -

蒂姆·贝格尔顿：

不是你怎么做的。

Ryan Crawcour：

“我们不想雇用一堆开发人员，开发和维护代码，并担心版本。”他们不感兴趣。我们就像我们已经使用了这个很酷的东西，我们正在使用称为Kafka Connect。我们只想继续使用Kafka Connect，因为我们使用它，我们喜欢它，它很棒，它对我们来说很低，它坐起来，有助于帮助我们。

我们看着，好吧，Cosmos DB没有连接器，对吗？没有任何人的错，但新数据库，而不是我们的正常驾驶室。我们想，“好的，让我们去看看。”幸运的是，纽带上有一些很好的文档，你可以去看看，并且有一个可以启动的示例连接器。我们认为这看起来不太困难。

蒂姆·贝格尔顿：

这不是，你看看API。而且你就像，“哦，来吧，那是一天解决的事情。”

Ryan Crawcour：

那是我的累积奖金。我差不多说了客户。我就像，“是的，别担心，星期五，我差点说，”看看，星期一，我会为你提供一个连接器。“因为你看它，那么有一个界面因为有四种方法和另一个界面，有四种方法。我喜欢，“容易，对？”我只是要得到[串扰00:15:41]。

蒂姆·贝格尔顿：

只是这个概念，这就是为什么第一次播放是，为什么我们只是写这个？谁需要连接器？它似乎如此稳定。

Ryan Crawcour：

那是什么，对吗？我们首先想到，好吧，我们甚至不需要Kafka Connect和连接器，但是你开始挖掘杂草，你觉得，“哦，好吧，挂上。”它变得有点困难，对吗？你有分区，你得到了检查站，你已经抵消了，你有重启性，你有 -

蒂姆·贝格尔顿：

规模。

Ryan Crawcour：

保证一旦交付消息，您已经订购了消息传递交付，就像“哦，挂断。现在它开始变得有点复杂，对吧？”

蒂姆·贝格尔顿：

是的是的。

Ryan Crawcour：

我真的不想去重建一大堆那种东西。什么时候已经为我们做了大部分的平台，对吧？我想，好的，酷，kafka connect。再次愚蠢地，我想，“是的，我会在周末敲门。”好吧，让我们说这没有一个周末，花了一点时间。我可能在大约一个星期内完成了一个工作原型，让他们从kafka留出了一条消息，并将其粘在宇宙中，并在宇宙上进行了变化，并将其粘在kafka。而且我想，“伟大的，概念证明证明它的工作原理。”客户看到，他们说：“我们什么时候可以拥有它？”这就是Kafka连接的旅程开始的地方。这是一个很多旅程，但这是一个有趣的旅程。

蒂姆·贝格尔顿：

在第一周之后有什么事物，因为这是始终是数据集成故事。这不仅仅是一个Kafka Connect Stories。随时随地将事情连接到其他东西，通常是概念上简单的，JSON文档让它们进入消息，或消息到JSON中。你就像，来吧。 [串扰00:17:27]解释说？

Ryan Crawcour：

[听不清00:17:29]。

蒂姆·贝格尔顿：

但答案很困难。

Ryan Crawcour：

我不认为这很困难，概念上这很容易。就像我说的那样，我把那个第一版本的连接器真的很快，但是你开始找到那些小的细微差别和那些绊倒你的东西，对吧？其中一个例如，当时很简单。我们幸运的是，幸运的是，我发现了Kafka Connect已经让其他人陷入了困境，而且我有一个很好的解决方案就是消息格式。

你有json，好吧，这很棒。但您也有json的员工，没有计划员。您将JSON作为二进制文件在Avro的条款中，您拥有所有这些其他类型的格式，就像“好吧，我如何处理那样？”如果我正在编写一个可以由任何人使用的连接器，而Kafka采用这些类型的消息类型，我将需要能够处理这些消息类型。

我想，“哦，这将是一个痛苦。”但幸运的方式Kafka Connect的方式在构建这些东西时，有连接器，有转换，还有转换器，对吗？因此，如果有Avro的转换器或JSON，则实际上，您实际上可以刚刚去并拉出其中一个转换器，或者是架构或任何东西。您可以拉出其中一个转换器并使用它们。

如果没有适合的转换器，那么有一个模型可以实际上可以去并构建自定义转换器，对吧？如果您有一些您使用的格式，那么您可以只要建立自定义转换器，并将连接器插入该。 Kafka Connect的方式是有点结构，它使得转换器，变压器，连接器使您的生活变得易于开发者，对吧？因为你可以进入并定位你需要的作品。

蒂姆·贝格尔顿：

那些是三个架构的架构中可能重要的是，从输入源连接器转换，抱歉，连接器，变换，转换器以同步连接器的相反顺序，转换或转换，转换，转换，转换器，转换器思考。但是是的，那些是三件。顺便说一句，如果我们只是在谈论Kafka Connect，就像每个人都知道Kafka Connect是什么，你的问题是什么？

如果您没有，该集中的节目笔记中有一个链接，我们将尝试在Show Notes中包含一个或多个剧集中的一个或多个剧集或在线其他材料。如果您是全新的，并且您不知道连接是什么，它实际上对于不知道Kafka Connect的人来说实际上非常正常。直到一些细节[串扰00:20:07]。

Ryan Crawcour：

我不知道Kafka Connect是什么，我多年来一直与Kafka合作。而且我不知道Kafka Connect是什么。

蒂姆·贝格尔顿：

对，你可以访问，所以按照我们有意的链接 -

Ryan Crawcour：

[听不清00:20:15]忘记。

蒂姆·贝格尔顿：

我们有意地没有给出所有背景，但显示说明中有链接您要查看。

Ryan Crawcour：

和罗宾迈菲特作为扰流板。

蒂姆·贝格尔顿：

它可能会在它上有罗宾Moffitt的名字。这可能是所有人基本上。

Ryan Crawcour：

绝对地。

蒂姆·贝格尔顿：

给我们一个有趣的东西的例子，因为你说，你部署了它，这是基本的东西。然后你发现了，“哦，等，这很难。”什么是绊倒你的东西。

Ryan Crawcour：

客户正在运行一段时间，有点回到我们并说：“我们正在丢失消息，或者我们得到重复的消息。”我们就像，“哦，这不是我想听到的。”我的意思是，Kafka让它获得了管理检查点的令人敬畏的方式，以及水印，以及在您阅读Kafka主题的地方，右图所在，呢？

Kafka Connect与Kafka管理那些抵消和那些类型的检查站的真正良好的工作？所以当连接器重新启动时，可以说，“嘿，我在我失败的时候，我从这一点给了我所有的东西。”这真是太棒了。真的很好，真的很好。但是，从Cosmos DB进入Kafka，他们开始丢失留言，或者他们开始​​重复，而且我们就像，“哦，发生了什么？”

我们挖到它有点多，而且Cosmos DB已经称为这个令人敬畏的概念，改变饲料，对吗？你可以订阅变化饲料 -

蒂姆·贝格尔顿：

那似乎很方便。

Ryan Crawcour：

并将其更改在数据库中，它将这些变化泵成了饲料的变化，对吧？有点像更改数据捕获，但它是您可以订阅的实际馈送，以及对文档的所有更改，只是按顺序出现在该更改源中。

蒂姆·贝格尔顿：

如果一个是写源连接器，它似乎是三分之一。

Ryan Crawcour：

绝对地。如果那不是那里，我甚至不会想到写一个源连接器，对吗？因为它真的很难这样做。自从[听不清00:22:22]以来，我必须弄清楚改变了什么，而且我刚刚购买了一个同步连接器。但幸运的是，改变饲料。所以我在更改饲料的顶部连接到源连接器。

现在改变饲料也有自己的管理检查点的方式，对吧？当你与更改饲料交谈时，您就会告诉它，这就是您必须从这一点向我提供所有更改的地方，您可以设置检查点，您可以将其设置为前进和各种各样的酷东西。事实证明，当您左侧有一个有检查点的系统时，并且您有一个具有检查点的右侧的系统。将这些检查站与彼此同步保持同步，这可能是一个好主意吗？因为如果他们不与彼此同步，所以可能发生各种各样的酷东西。

并挖掘这些细节，这就是发生的事情。我们彼此相互同步地获得这些检查站，这就是我们跳过邮件或重复邮件的地方。需要一段时间才能得到正确的。当您是一个分布式工人平台时，恰好交付的概念，也很难。

Cosmos DB是分布式数据库，Kafka Connect拥有多个工人，以及多个工人试图将更改读出了数据库的变化，进入了Kafka主题。那个分布的性质，并恰好曾经送货变得相当棘手，对吧？这些消息是交付的，那些工人说，“哦，那个消息我正在送达，哦，现在，坚持这个。”但那项工作已经发表了这封消息，不要再递送它，那种东西。

那些完全一旦以分布式方式工作的那些语义，这成为一点具有挑战性，并且为我们带来了相当多的时间，以便比构建初始连接器Doc更长时间。只是弄清楚如何以分布式方式实现一次。超级努力。

蒂姆·贝格尔顿：

我不知道是否有时间挖掘它的所有东西，但是是项目效力键，从源连接器的角度来制作写作，使物品有效，是魔法？

Ryan Crawcour：

是的，我想我们看了那个，这很难做到，但项目效力绝对是其中之一。我猜挑战是更多的，当让我们说，连接器因某种原因而失败。有人关闭了Kafka Connect Cluster或无论您的连接破坏了什么。然后你重新开始连接器，真的很难知道已经写给了Kafka的内容，以及数据库中的发生变化，并确保我们彼此同步，所以我们开始了相同的观点。

这就是挑战的所在的地方，有时候连接器会是领先的，或者在它被认为是在Kafka的后面。然后它将开始发送重复的数据库或文档，或者它会认为它是进一步的，它将从kafka进一步开始，然后我们有效地丢失了一些事情。

蒂姆·贝格尔顿：

Gotcha。

Ryan Crawcour：

在那种围绕具有分布式多个工人的弹性，独立于您的数据库和Kafka开始和停止，然后能够重新同步这些东西。肯定有一个项目效力问题，但还有一点点。当您正在查看像Kafka这样的分区系统时，还有一些其他挑战，然后您正在查看像Cosmos DB这样的分区系统，因为Cosmos DB是无限的水平可扩展的，对吧？通过仅为数据分区，与Kafka相同，您可以拥有数千和数千个请愿。你在cosmos db中有同样的东西。

现在正在写一些有效地做那些多分区的故事并按顺序保持东西，并同步，也有点具有挑战性。能够说，“这是正确的，这个工作人员，你致力于该分区，或者这个工作人员正在使用该分区，或者您正在使用这组分区。”

我猜我们最大的挑战是规模，以及一个分布式的性质，使东西有弹性，稳定，对吗？它真的很简单，让它在一个小的Cosmos DB环境中具有低分区的单个主题，获取流程，流动两个方向，微不足道。这是工作的周末，让它在没有丢失的消息中可靠地做到这一点，这需要一点工程。

蒂姆·贝格尔顿：

它总是比任何发展任务更难的一周。这对我来说总是很有趣，如何粗略地集成代码。这正是时间码，你应该能够立即敲掉它，稍后几个小时，你感到舒适。

Ryan Crawcour：

80％的功能需要20％的时间，而20％的功能是80％的时间。

蒂姆·贝格尔顿：

是的是的。这绝对是一个奇怪的帕德索分销在这里发生的事情。

Ryan Crawcour：

好吧，它花了一个星期来写整个连接器。现在它带给你六个星期，就像这样做的那种功能，发生了什么？

蒂姆·贝格尔顿：

是的，是的，它是。

Ryan Crawcour：

让我向你解释一下。

蒂姆·贝格尔顿：

对。这在野外并现在可以使用。我的意思是，我知道它是一个融合的集线器作为一个选择，所以它正在使用其他。

Ryan Crawcour：

这是我们目前的好客户使用。我可能会说10名客户是一个很好的猜测，但在生产中有大客户。你会看到你去融合的集线器，你找一个连接器，它在那里。您可以抓取它，您可以使用它，它被称为已验证或称为认证。它说它仍在预览中，它是它的。即使它说，它在预览中，它是由Microsoft完全支持的，我们将支持它，我们将添加功能，我们将解决问题。

蒂姆·贝格尔顿：

没关系。

Ryan Crawcour：

它也是开源，所以去GitHub，搜索Kafka Connect，Cosmos DB，你会找到它。但我们也可以在节目中将链接放在回购中。

蒂姆·贝格尔顿：

绝对地。

Ryan Crawcour：

如果您有任何问题，只需在仓库中打开问题，他们来到我的桌子上，我们将他们分发，我们会处理它们。当然，我们已经有来自社区的贡献，所以谢谢，但它是完全开放的来源。如果你看到的东西，你想贡献，你想添加功能，或者你想改变一些东西，你可以自由地去提交拉出请求，再次落在我们的桌面上，我们将审查并合并我们需要。

我们昨天已经刚才，我认为，来自Confluent的人写了一个配置验证器。现在，当您实际在配置中输入时，它确实验证了配置。所以你知道你的配置是否有效，这是一个很酷的贡献。所以谢谢。

蒂姆·贝格尔顿：

也许它可以记录描述性错误消息，如果不是，我的意思是，我只是希望。

Ryan Crawcour：

它确实如此。它立即记录非常好的描述性错误消息。这对它是一件好事，即使是它现在的测试版，但我们已经将它传给了Cosmos DB工程团队。所以它将成为来自他们的完整官方产品。如果需要，您将能够打开Microsoft支持的支持案例。但它也是我们想要打开它的一部分。我们喜欢看一种贡献，如果你有问题，或者有功能请求，或任何东西，只需在github中记录它们，我们将从那里带走它们。

蒂姆·贝格尔顿：

今天我的客人一直是Ryan Crawcour。瑞恩，非常感谢作为流式音频的一部分。

Ryan Crawcour：

非常感谢你，让我在节目中。

蒂姆·贝格尔顿：

你有它。嘿，你知道你得到了什么来听到结束，一些免费的融合云。使用促销代码60pdcast，即6-0-p-d-c-a-s-t，获得额外的60美元的免费汇合云使用。请务必在12月31日，2021年12月31日激活它，并在激活后90天内使用它。到期日期之后的任何未使用过的促销价值，并且有一个有限数量的代码，因此不要错过。

无论如何，一如既往，我希望这个播客对你很有用。如果您想讨论或提出一个问题，您可以随时与我联系在Twitter @tlberglund上，这是T-L-B-E-R-G-L-U-N-D。或者您可以对YouTube视频发表评论，或者在社区松弛或社区论坛上伸出口。如果您想注册，节目中的这些内容有注册链接。

虽然您在它的同时，请订阅我们的YouTube频道，并在此播客，无论何处销售。如果您通过Apple Podcasts订阅，请务必向我们留下一段评论，帮助其他人发现它，特别是如果它是五星级的审查，我们认为这是一件好事。因此，谢谢你的支持，我们下次见到你。