Deep Dive
Shownotes Transcript
我是玛丽亚，我在阿霍德德尔海兹担任MLOps技术主管。我也是Marvelous MLOps的联合创始人，我们公司专门教授其他人关于机器学习、MLOps以及使用Aetheryx的MLOps。我对咖啡非常挑剔，你可能已经知道了。我喜欢喝燕麦奶拿铁，咖啡量必须恰到好处。
研磨要完美，微泡也要完美，怎么说来着，细腻？是的，我能冲出比大多数咖啡店更好的咖啡。
我们又回到了MLOps社区播客。我是主持人德米特里奥斯，今天我很荣幸能与Marvelous MLOps的玛丽亚交谈。如果你在MLOps领域有所涉猎，你可能听说过她。这一集进行了深入探讨，我再怎么强调我们对Databricks的深入了解也不为过，包括优缺点、好坏、利弊，所有的一切，而且我们还……
请坚持到最后。她会谈谈她即将开设的课程，以及她正在撰写的书籍。所以，如果你曾经渴望学习，或者你目前正在使用Databricks并进行某种ML/AI项目，
你应该和她联系，因为她是这个领域的专家。让我们深入探讨吧。你需要了解的关于Databricks和Databricks上的MLOps的一切。上次我和你交谈时，你说，是的，我想我应该开始在领英上发布更多内容。哇，效果怎么样？是的，确实如此。是的。
那是两年前的事了，实际上。我们一起录制了第一个播客，正好是两年前。从那时起发生了很多变化，很多很多。那么，你最近在忙些什么呢？我想两年前我有一种冲动，想开始在领英上发布我正在做的事情，以及撰写文章。因为我在领英上和其他地方看到过很多专家，你知道的，谈论MLOps是什么。
我认为那里有很多说法是不正确的。我已经做了很多年了，所以我的声音也应该被听到。好吧，从那时起我就一直坚持着。这真的，真的非常酷。我认识了很多很棒的人。是的，我喜欢它。而且我认为你专注于，不一定是你在领英上的内容，而是你所做的一切。
你所做的领英以外的内容，深入探讨Databricks。我想我很想谈谈
关于Databricks，比如你为什么选择它。这绝对不是Databricks赞助的，尽管他们是MLOps社区的骄傲赞助商，我们喜欢与他们合作。但这具体来说，我想谈谈一个用户的优缺点、好坏、利弊，一个做过大部分认证的人，而且你现在还在开设课程，讲解如何更好地使用Databricks。
我很想从你为什么特别选择Databricks开始。
是的，这是一个很好的问题。我从事MLOps工作已经很久了，在它成为一个流行词之前就做了八年多。我们围绕模型注册表、实验、跟踪构建了自己的工具，使用一些，你知道的，Teradata数据库或任何其他SQL数据库作为后端，以及GFrog artifactory用于模型工件存储。而且
我们在没有人这样做的时候就做了，这真的非常酷。从那时起，我尝试使用各种不同的工具在云端、本地进行MLOps，而且正如我所说，我自己也构建了工具。我觉得我或多或少都见识过了，比如如何连接ML设置的不同部分，以确保其健壮性，并在需要时回滚。
有很多平台和工具。所以当你查看工具时，你可以找到几乎完美的工具，用于你的ML设置的每个组件。但这很复杂，你知道的，将它们组合在一起，你需要投入大量资金，并拥有一个大型团队才能做到这一点。
另一方面，平台是可定制的。它们拥有所有这些你需要的MLOps组件，例如模型注册表、计算、服务组件、监控组件，以及数据版本控制等。
它们都具备这些功能，虽然并不完美，但你仍然可能希望让它为你的用例工作，而不是，你知道的，尝试组合所有现有的工具。如果你在本地，你可能真的没有选择，你必须使用开源工具。
然后你就有选择的余地了。但是如果你在云端，如果你在一个大型组织中，引入任何工具都非常复杂。你知道的，所有这些采购流程、获得可信赖的供应商等等。这对参与此过程的每个人来说都是很大的痛苦。所以你只想在真正需要并且必须这样做的时候才进行这个过程。
但我感觉平台已经足够好了。三年前并非如此，但现在平台已经足够好，可以满足你进行MLOps所需的大部分工作。但是，如果你查看互联网上人们的讨论，人们告诉你应该如何做事情，在我看来，这些说法是不正确的。他们没有推广最佳实践。例如，如果你查看DataBricks的特定培训，它都是围绕笔记本进行的。
如果有人关注我的领英，你知道的，我不太喜欢笔记本。原因如下。我本人是从数据科学家开始的。我自己也经常使用笔记本。那是2016年向数据科学家教授Python的唯一方法。任何课程都是简单的笔记本。
当我开始学习Python时，这就是方法。然后我开始尝试将我的第一个模型投入生产，比如构建一个端点。这就是我们当时的用例。我看到了从笔记本到生产就绪的东西有多么困难。这非常痛苦。那是我第一次意识到，为什么笔记本不是一个很好的起点。
而且忘记使用笔记本真的非常困难，你知道的，因为人们已经使用了多年。他们知道如何轻松地使用它。你知道情况如何。如果你使用某个工具，切换到另一个工具、另一种方法非常困难。你使用的时间越长，就越难。这就像生活中的任何事情一样。
在我看来，笔记本对MLOps生命周期的损害比其他任何东西都大。这就是我对它的感受。所以我们需要教数据科学家如何正确地进行数据科学，而不是使用笔记本。或者，你知道的，至少教他们如何将笔记本转换成或多或少生产就绪的东西。
这就是我经常谈论的内容，也是我们在课程中教授的内容。那么，为什么是DataBricks呢？也许是另一个问题。好吧，如果你查看所有现有的平台，并且有一个
我认为人工智能伦理研究所进行了一项研究，他们只是，这是一个问卷调查，他们询问该领域的专业人士使用哪些工具进行模型注册表、数据湖、服务、培训，而DataBricks位居第一。老实说，这并不让我感到意外，DataBricks发展得非常迅速。
因此，DataBricks如今在许多公司中成为ML的首选工具，因为它很简单。数据工程是在DataBricks上完成的。所有数据都在Unity Catalog中，DataBricks也是ML的逻辑步骤，用于训练你的模型，甚至可能在上面进行服务和监控。所以有很多选择。
另一方面，它不仅仅是领先的平台。我觉得它与我见过的其他供应商非常不同。他们非常乐意接受人们的批评。当你告诉他们你不喜欢某些东西时，他们不会感到惊讶。他们实际上知道情况就是这样，但这并不是他们的首要任务，因为他们还有其他更重要的事情需要解决。
是的，如果我考虑过DataBricks上一个可能有用的很酷的功能，他们也考虑过。他们可能已经在开发它了。这是我在其他任何供应商那里都没有看到的东西。这令人印象深刻。所以这里有很多内容需要展开。让我尝试……
进行处理，因为首先想到的是你提到了如今的平台感觉足够好了。三年前并非如此，但现在无论你使用什么，我想当你提到平台时，你指的是Vertex AI、SageMaker和DataBricks平台。因此，你可以从该平台获得足够多的功能，因此无需再出去
将许多不同的工具拼凑在一起。是的，确实如此。我认为你提到的另一个关键部分是，我们都经历过尝试引入新的供应商，而且我们可能……
举起双手说，我再也不这样做了。我不想再回答DevOps人员或DevSecOps团队关于此供应商或合规性、ISO或SOC2的任何问题，无论是什么。这需要很长时间。我刚刚经历了这个过程，我选择了一个工具
仅仅是因为它们已经被接受到生态系统中，我们不需要再进行入职流程。即使我知道这是一个更糟糕的工具，我也想获得一个我更喜欢的不同工具。但就像，哦，如果我们想这样做，那么我们将面临大约两个月的期限。
提前准备时间来引入新的供应商，而不是让我们使用现有的工具并增强此已接受工具的功能。所以感觉就像
这就是我们许多人的立场。这也是你选择DataBricks的原因之一，因为你看到了这项调查，并说，看起来很多人都在使用它。我只能看到它会继续发展，因为它的功能也在不断发展。人们在DataBricks上做的事情，如果你的数据工程在那里进行，那么它不可避免地会发展壮大。
数据具有重力，如果你还没有这样做，你可能会开始扩展不同的用例。是的。所以，我们之所以在DataBricks中完成所有工作，是因为我们已经有了DataBricks。三年前，甚至更早之前，DataBricks并非完美无缺。但是你那时甚至可以在上面做足够的事情，以便，你知道的，让它
相当不错。它仍然比我们也有权访问的Azure组件更好。基本上，我工作的公司在Azure上，我们也使用DataBricks。如果我必须在Azure和DataBricks之间做出选择，我总是会选择DataBricks，因为在我看来，在上面进行MLOps更容易。这就是原因。但我也想知道
不好的部分，你提到DataBricks非常乐于接受批评。但是，我知道当我与你交谈时，
你说，是的，这就是DataBricks中的做法，但这可能不是最好的方法。无论是尝试在笔记本中工作并假装它们已准备好投入生产。或者我知道我们还讨论过DataBricks功能存储以及它并非一定是最好的方法。所以也许你有一些……
你发现的最佳实践，因为你一直在使用DataBricks并学习它或深入了解它，是的，绝对如此。我认为直到今天，最大的痛点之一仍然是DataBricks上的开发流程，正如我提到的，一切都是围绕笔记本进行的，我认为ML代码必须打包，就是这样……
如果你想拥有专业编写的ML代码，它必须打包。这在DataBricks上是可行的，只是方法并不直接。例如，DataBricks带有运行时的概念。这几乎是你环境的容器化版本。它已经预安装了软件包和其他程序、其他软件。你基本上希望在本地拥有一个可重现的环境来进行开发。
因为你不想开发一个笔记本，比如说，你实际上无法在本地精确地重现相同的环境。这是不可能的。你可以得到一个近似值。但因为它是一个近似值，你只能以某种方式、某种状态进行开发，并且为了进行测试，你想在DataBricks上再次进行测试。但你不想在笔记本和本地开发之间来回切换
所以还有其他方法，例如使用资产包，例如。我认为这是在DataBricks上开发的一种被低估的方法，我非常喜欢使用它。我们下周实际上有一个关于它的闪电演讲。它可能不会及时出现在这个播客中，但会有录音。所以我们也许可以在某个地方插入链接。资产包只是一个功能？
DataBricks的功能？是的，资产包确实是DataBricks开发的一个功能。它本身有很多组件，我想说。但首先，它是一种定义工作流程的方法。因此，如果你在DataBricks中有一个编排管道，你可以在JSON文件中定义它，或者你可以在DataBricks YAML文件中定义它，这就是资产包的定义。
每当你部署该包时，你的工作流程定义都会与部署所需的所有资产、包和其他文件一起部署。
以前在DataBricks中部署东西非常困难，因为你必须处理所有这些问题，例如你的包被上传到DataBricks，你的Python文件被上传到DataBricks，以及你需要的其他所有文件。你必须围绕它构建你自己的逻辑，以确保所有内容都在那里。我们实际上为此构建了整个东西。我们基本上在内部构建了一些与资产包非常相似的东西。现在我们正在弃用它，因为资产包可以完成所有这些工作。
但这不仅仅适用于工作流程。它也适用于开发。我认为人们对此谈论得不多。人们将其用于部署，但人们并没有真正将其用于开发。但我相信对于开发来说，它也是一个非常好的功能。这是关于这个开发流程的一个很好的例子。我们那天到底在谈论什么关于功能存储以及它是如何工作的？
有很多功能存储可用，对吧？不仅仅是DataBricks，还有Feast、Hopsworks和其他工具，Tekton。
所以其他工具更侧重于功能存储，但DataBricks包含各种组件。因此，如果你查看DataBricks功能存储，基本上有两个功能，两种你可以与功能存储交互的方式：功能函数和功能查找。
功能查找基本上是定义如何在特征表中查找键。因此，如果你想查找客户ID并返回该客户ID在表中的某些值，你可以使用它。
它实际上没有回退功能，因此如果找不到，它只会返回None，这本身并不方便。例如，为了替换它，你可以使用功能函数。如果它是None，则查找其他内容或返回该值。所以功能函数本身，我认为，是一个相当丑陋的结构。你必须在SQL中定义你的Python函数，这是唯一的方法。
我不知道是谁首先想出这个方法的，但我有很多理由不喜欢它。首先，它没有版本控制，对吧？当然，你拥有版本控制，但是当你创建此函数时，无法将其指向使用的代码版本或函数版本。此外，该函数的行为会根据你使用的运行时而有所不同。
当然，因为你知道，你在SQL查询的import语句中使用的Python库的Python版本，如果你的Python版本是3.10或3.11，那么它的行为将有所不同，而Python版本由运行时定义。当你在无服务器环境中运行时，情况更糟，因为你无法选择运行时，但无服务器环境中存在环境的概念。
所以对于人们来说可能会非常混乱，比如函数本身的行为。此外，该函数在服务方面有一定的局限性。例如，当你，DataBricks上也有一个功能服务。这个想法实际上非常好，对吧？有时你只想服务功能，而不仅仅是模型。就像你想在表中查找某个键并返回内容一样。
这非常方便，你还可以服务功能函数和功能查找的组合，例如堆栈。这是一个你定义的列表，列表的顺序定义了这些元素的执行顺序。没有条件语句，所以所有这些东西总是被执行。而且，你知道的，所有这些都定义为功能规范，这就是它的名称，这就是你服务的内容。
所以，如果你必须输出一些复杂的数据类型，例如，我不知道，不是整数或字符串的东西，那么功能函数就会失败。我希望他们很快就能修复它，因为它似乎不是预期的行为。
诸如此类的事情。此外，特征工程包本身只能在笔记本或DataBricks环境中工作。你无法在你的机器上运行该Python代码。老实说，我可以继续说下去。我不喜欢这个功能。我
听起来一团糟，老实说。是的，在我看来，这是一个很大的烂摊子。这太糟糕了，因为我认为它有很大的潜力。我还发现最令人沮丧的事情之一是
所以大多数机器学习仍然是在pandas中完成的，对吧？Pandas，我的意思是，现在Polars正在兴起，人们实际上正在迁移到Polars，但仍然不是所有库都支持它。所以pandas仍然是主流。
所以特征可追溯性，这个血统，只有在你使用PySpark时才有效。所以每当你将其转换为Pandas或其他东西时，它将不再起作用。这有点奇怪。等等，你告诉我，有没有解决方法？是的，我们实际上教授了一些丑陋的解决方法，但是……
是的，你为什么要这样设计它？是的，这感觉是你使用托管系统时会遇到的缺点的一部分。但这也是你正在决定的权衡，嘿，我想要一个托管系统，所以我想让我自己做出某些决定，对吧？如果你使用平台，他们会对如何做事情有自己的看法，这是固有的。
这是你的意见和平台构建者的意见大相径庭的时候之一。是的，在这个特定功能上，我会这么说。但我认为，好吧，这只是我真正不喜欢它的事情之一。但是很多其他事情都很棒。正如我所说，包真的很好，等等。
你定义工作流程的方式与以前相比有了很大的改进。我认为这些也非常好。你在DataBricks上进行培训的方式。有很多非常酷的部分。我认为大多数事情都是很酷的部分。我想这就是我谈论DataBricks的原因之一。如果所有这些都不好，我不会这样做的。现在，你……
深入研究Mosaic方面的内容了吗？或者他们是如何将其整合到DataBricks中的？在我们现在的课程中没有，但我们将推出LLM Ops课程，而且我也在我的书中提到了它。所以我涵盖了MLOps，也涵盖了LLM Ops用例，其中确实也涵盖了Mosaic部分。
我们将使用这个术语，是吗？我们将使用LLM ops。我不知道你会怎么称呼它。对我来说，一切都在LLM ops中，老实说。是的，我认为我们非常有偏见，因为对我来说也是如此，但是LLM ops，我从未觉得
是一个具有持久力的术语，这是一个有趣的术语……或者AIOps。AIOps听起来不太好。不，AIOps，我也将其解释为用于运营的AI。就像使用AI来减少Datadog中的警报一样。哦，是的，是的，确实如此。是的。
但是是的，我不知道除了vibe ops之外我们还能称之为什幺。这是我本周的新术语。让我们称之为Mellops吧。我认为Mellops作为术语的流行度实际上相当高。所以我正在推动它。是的。而且我认为它已经经历了……
炒作周期，现在它又开始回升了。当然，当LLM Ops出现时，它下降了，并且处于
幻灭的低谷，现在它正在回升，因为我认为人们意识到，好吧，无论我们使用LLM还是传统的ML，我们都需要弄清楚我们的生产环境，这有点相似，是的，当然，相似之处比人们愿意承认的要多得多
好吧，我经常举这个例子，但是如果你看看，你知道的，数据科学炒作周期，数据科学术语开始出现在2016年或2015年左右。大约又过了三年或五年，MLOps才成为现实。我想我们现在正在经历同样的周期，但这个周期会更大。我的意思是，AI……
的流行程度比过去数据科学的流行程度要高得多。因此，我也预计下一个MLOps炒作周期会更快到来，而且规模也会比我们以前见过的任何周期都要大得多。好吧，多亏了Vibe编码，我们将有很多工作要做。是的，这是很好的工作保障。那是肯定的。是的。
你有没有在与人们合作时建议他们不要使用DataBricks？
哦，是的，当然。绝对如此。我认为每个人都应该使用适合自己情况的东西。例如，我们经常使用DataBricks。我们还在DataBricks上进行了一些模型服务，但我不会在任何地方都推荐它。所以，我绝对不推荐的一种情况是，整个网站由你托管，它运行在你的Kubernetes上，
因此，如果你想要低延迟，你希望将你的模型托管并在同一个Kubernetes服务器上提供服务，而不是其他任何地方。所以是的，在这种情况下，绝对不要为此使用DataBricks。因为这就像反模式一样，哦，我们将引入DataBricks，并使其位于我们的Kubernetes集群之外。这将是反模式，因为它会慢100%。
此外，DataBricks并不适合所有人。我不是在谈论服务部分，我认为这非常有用，因为它简化了很多事情。但这并不适合所有人。所以每秒有20,000个请求的限制适用于整个工作区。而且
你知道的，在某些假设下。所以实际上，它会少于此数。这是针对整个工作区的。如果你在工作区中有多个端点，所有这些都包含在这个限制之下。
对于一些公司来说，这足够了。对于一些公司来说，这永远都不够。所以你只需要选择适合你正在做的事情的工具。情况总是如此。对于大多数公司来说，这将是可以的，因为他们没有任何严格的要求或类似的东西。而且大多数工作仍然是批处理。是的。而这20,000……
听起来你已经遇到了这种情况。我们不需要讨论原因、方式或内容。但是有没有办法与销售人员协商来提高这个数字？
好吧，我想可以，但这已经是增加了容量。所以有一个默认容量，低于这个数字，你可以创建一个请求来将其提高到这个数字。我想，如果你真的是一个大客户，那么这可能是可能的，但我怀疑对于任何客户来说，这都不会那么容易，老实说。好的，所以……
这就是不使用它的时机。现在，你看到了一些什么？我认为我们都将在6月份参加DataBricks峰会，数据和人工智能峰会。你正在做演讲，对吧？实际上，我还不知道。所以我可能会在DevRel剧院做演讲。无论如何，我会在那里。你关注DataBricks上有哪些令人兴奋的发展？
我实际上喜欢，这并非新事物，但我可能无法谈论某些事情，所以我需要对此非常谨慎。你了解内部信息？我不知道你这么酷。太棒了。好的。我不能说，好的。我可以告诉你一些我不能说的事情。所以有App Genie，我认为这超级酷。那是什么？
所以基本上，这是一个用于商业智能的 AI 工具。在我们组织内部，我们现在也打算更广泛地使用它。这确实简化了其他团队（并非所有团队都具备足够的编码知识）与数据交互的方式。
这是我们试图融入产品团队的东西。我认为这是一个非常酷的发展。它已经存在一段时间了，但我认为现在它已经达到了易于使用的状态。
所以我们正在讨论在一个乌托邦世界中使用 Databricks，在这个世界中，我们学习了该平台及其内部运作方式，而这正是我们需要知道的全部。如果我们可以优化它，我们就可以优化我们的整个设置和系统。但对大多数人来说，我觉得
Databricks 只是技术栈的一部分。你在这方面看到了什么？哦，是的，我同意。我认为根据我的观察，这是最常见的模式，所有批处理都在 Databricks 上进行。所以基本上整个模型训练（你需要每周或任何你的再训练周期进行再训练），对吧？
这可以在 Databricks 上进行，我认为这会极大地简化你的生活，尤其是在你的所有数据都在 Unity Catalog 中的情况下。它会比使用任何其他东西都容易得多。这就是我认为 Databricks 将 Unity Catalog 放在适当位置非常明智的原因。
我看到很多情况，这也是我们之前的做法，我们仍然有这种多样化的部署方式。因此，我们训练我们的模型，结果要么是需要服务的模型工件，所以你基本上有模型服务，或者你有批处理服务，这意味着你只是将数据存储在某个数据库中的某个地方，
根据请求，你只需要查询数据库即可。或者你有一个混合场景，你需要一个工件，还需要在某个地方查找一些数据。
因此，当你只想在某个地方查找一些数据而无需任何模型时，我认为 Databricks 不会是我的首选。有多种方法可以做到这一点。你可以使用模型服务以及在其他数据库中的查找。这将是一种方法。或者你可以使用在线表和 Databricks。但是，你对特征服务、模型服务受到限制。在线不支持某些数据类型。
在我看来，这太复杂了。所以我宁愿在 Kubernetes 上运行一些快速的 API，并在 DynamoDB、CosmosDB、MongoDB 等数据库中查找。这也是我在组织中看到的最常见的方法。顺便说一句，这很有道理。
当你进行模型服务时，你可能希望在 Databricks 上进行服务，但 MLflow serve 也适用于 Kubernetes。因此，你可以以相同的方式进行部署，但在 Kubernetes 上。这也是一个不错的方法。我认为你只需要考虑什么对你、对你的特定用例有意义，
然后选择它。Databricks 使端点的监控更容易。这是我投票支持模型服务（如果可能并且适合你，例如是否符合要求）的原因之一。因为对于所有 API 调用，你可以查找该信息。所有这些都存储在你可以启用的推理表中。这确实使它更容易
监控它。所以它比使用其他工具做同样的事情更容易。这就是我的想法。因为我们尝试了不同的方法。所以，和往常一样，这取决于情况。我很高兴你在这里提到了 MLflow，因为我知道 MLflow 已经做了很多工作，特别是围绕着
将 MLflow 扩展到新的 LLM 功能。但在我们之前聊天时，你曾说过 MLflow 的新更新有多酷。我在 MLOps 社区看到，Slack 上有一些关于不喜欢 MLflow 发展方向的讨论。但也许你可以告诉我们你最近喜欢它的哪些方面。
好的，是的，听起来不错。我实际上成为了 Melpho 大使，所以我可能是谈论它最合适的人。就是这样。不，Melpho，我确实感觉有一段时间有点过时了。在我看来，有一段时间没有什么重大的事情发生。而且对于新用户来说，它并不直观易用。
但我认为数据通信非常棒。它在过去几年中得到了显著改进。如果你不明白某些东西，你很可能可以在文档中找到它。
所以这是肯定改进的一件事。但 LLM 功能也是最近出现的东西。它们现在可以拥有 MLflow 跟踪，它们也有提示注册表，这非常酷，而且非常有意义。MLflow 中还有一个 YI 网关。
好吧，我不知道。老实说，我认为没有其他工具具有如此丰富的功能，这使得它一方面成为一个非常酷的工具。但另一方面，再次找出如何正确使用它可能并不简单。这可能是硬币的另一面。
当你谈到在 Kubernetes 上的 MLflow 服务时，这是托管版本还是你刚才谈到的开源版本？MLflow serve 是来自开源 MLflow 的一项功能。
但基本上，Databricks 使用的是完全相同的东西。你只需要在 Databricks 上使用命令来部署端点，而无需在任何地方运行 MLflowServe。但实际上，幕后发生的事情完全相同，这使得它很容易以完全相同的格式几乎在任何地方进行部署。
我发现使用 Databricks 服务的一个教训是，无论何时你部署它，如果你只是部署它，你等待，事情可能会失败，而且很难调试。但人们没有意识到，这与你可以在本地运行和调试的 MLflow serve 完全相同。所以有一些方法可以测试它。
我们现在实际上也在写一篇关于它的博客，因为人们不清楚如何做到这一点。但是，你知道，MLflow 模型，你知道，格式，在某种意义上与 Bento ML 所做的事情非常相似，对吧？它只是打包你的模型，
以某种方式可以服务的形式，你可以在任何地方部署它。你可以从中创建一个镜像，一个 Docker 镜像，然后你可以用它来服务。或者你使用 Databricks，但 Databricks 在后台做的完全相同的事情。所以我想你部署在哪里并不重要，它只是……
在 Databricks 上，我认为它更容易一些，因为所有这些复杂的部分都对你隐藏了。所以，如果你有能力创建你最喜欢的堆栈，我们可以说，使用 Databricks，然后根据需要插入不同的部分，例如不是原生的 Databricks 选项，你可以进一步扩展平台，
让我们谈谈一个具体的用例。这不像，“哦，好吧，这取决于你是否使用这个用例，你想要这个或那个”。让我们谈谈推荐系统用例。那会是什么样子？你会换掉什么？假设我们不必引入任何新的供应商并对特定部分做任何新的事情，让我们只是……
假设实际引入工具的工作不存在，因为我们已经知道这是不真实的，但在假设的世界中，它是如何扩展的？推荐系统通常很大程度上是预先计算的，对吧？
这不是我们在收到请求时正在计算的东西。也许它的一些部分，但大部分实际上只是在某个地方查找已经预先计算好的，因为计算成本很高。而且我们有一些延迟要求。这意味着你首先必须在某个地方查找它。所以这是一个假设。
模型训练可以在 Databricks 上完成，对于推荐系统，我认为，至少就我们而言，我们大量使用 Spark，这完全有道理，因为我们运行的所有过程都可以分布式进行数据预处理。然后，我们为推荐系统所做的更高级别的逻辑也是定制的，也在 PySpark 中运行。
最终结果基本上看起来像一个非常非常大的字典。好吧，你可以将它存储在某个数据库中。
然后，运行在 Kubernetes 上的一些快速 API 最有意义，或者也许，我不知道，这取决于你的要求，但即使是 Azure 函数也可能足够好。所以有多种选择，你只需要看看你组织中已经拥有什么，你有什么模式。
然后选择它。如果 Kubernetes 是你所做事情的重要组成部分，我会完全选择它。然后部署一个快速的 API 应用程序，然后在 Cosmos DB、DynamoDB 或任何你拥有的数据库中查找，并将值返回。对于监控堆栈，你不能使用 Databricks 中的推理表。然后你必须，我们使用的是 App Insights，我们也有
你知道，Prometheus 和 Gryphon 已经设置好了，这就是我们目前正在使用的。
数据层面的事情，比如整个数据管道和处理以及移动数据，创建特征等等？是的。所以，好吧，我们在 Azure 上，我们不处理原始数据部分，所以当数据摄取部分，但有一些限制不允许我们为此使用 Databricks，这就是为什么它仍然是 Azure Data Factory，但是
当预处理发生时，它将所有数据写入 Unity Catalog。所以我们基本上是这些数据的使用者。我们的团队是数据的使用者，数据是由另一个团队生成的。所以如果数据有什么问题，这不是我们的责任去修复，而是那个团队的责任去修复，这简化了某些事情，但也使其他事情复杂化了，显然。
这就是我们正在处理的数据层。然后我们有自己的自定义数据预处理，这是我们的模型所需要的，因为
数据工程团队不关心特定于 ML 的数据转换。所以我们有自己的数据工程管道，用于我们的个性化堆栈。这在我们的个性化领域内的多个子产品中共享。这个管道是使用 Databricks 还是 Airflow？它在 Databricks 上。它使用 Databricks 工作流。我们也写回 Unity Catalog。
然后是子产品，例如，篮子上的推荐、产品详情页上的推荐或个性化优惠推荐也是我们所做的。这些也是在另一个管道完成之后运行的单独的子产品。结果要么写入某个数据库，我们可以使用 FastAPI 来查找它，
就像我们现在实际上在 Azure 函数上进行服务一样。
另一方面，我们实际上也有一个模型。所以它只是一个模型，我们为此使用 Databricks 模型服务。但正如我所说，如果你有某些要求，而 Databricks 模型服务不符合你的要求，你可以使用 MLflow serve 并将其部署到其他地方。嗯哼。
我喜欢我问你理想的堆栈是什么，你给了我你实际的堆栈是什么。但它非常理想。我真的很喜欢我们现在拥有的东西。花了很长时间才弄清楚这一点。我们经历了一次大规模迁移。我们几乎完成了。这感觉很棒。它实际上是我们一开始想象的方式。鉴于我们目前的情况，我认为目前没有比这更好的堆栈了。
这就是为什么，是的，我喜欢你的回答。这就像，我的理想堆栈和我的当前堆栈之间没有区别。是的，确实。是的。是的，我们对我们取得的成就感到非常自豪。这需要付出很多努力。是的。在创建这次迁移时，你做了哪些没有成功的事情？
是的，我们实际上想使用 Databricks 特征服务，并使用在线表进行特征查找。由于我们面临的限制，我们从未能够使用它。这是缺点之一，因为它会简化我们的部署堆栈，对吧？整个部署都可以在 Databricks 上的一个大型管道工作流中完成。
但现在，我们有多个管道，这仍然是可以管理的，但我认为它并不完美。你有点一笔带过了我想回顾的东西，那就是你不是……
进入 Unity Catalog 的原始数据的拥有者。你只是它的使用者，这有利有弊。你如何分解利弊？是的。我认为数据质量部分是最终的关键。当然，在数据摄取方面以及他们处理数据的方式以及他们放入 Unity Catalog 中的内容方面有一些监控，以进行一些质量检查。
但是，这些质量检查与我们所做的检查非常不同。
对他们来说，这就像模式有意义，值在可接受的特定范围内，并且计数正常，诸如此类的事情。但我们检查的是非常不同的东西。它更多的是关于数据的统计特性。数据工程团队，因为我们不是数据的唯一使用者，还有其他使用者，他们并不真正关心这些事情。所以可能会发生我们发现事情坏了的情况，
而他们没有注意到，仅仅是因为他们没有检查我们关心的东西。是的。这是一个每个人都会遇到的普遍问题。这感觉很像你想创建这个数据网格概念、数据契约的地方。
让负责人和消费者，也就是生产者和消费者，握手并说，好吧，我们同意这些是我需要的质量检查，或者这些是我正在寻找的东西，我想要这种新鲜度，我想要这种风格或这种模式，无论它是什么。你考虑过这样做吗？
是的，我们尝试过。但我认为这总是关于，你知道，团队有多大，他们的优先级是什么，他们向谁汇报。所有这些事情都很重要。如果从上面有这种运动，那么事情可能会改变。但是，你知道，如果你只是消费者之一，而有一个更大的团队，你
他们的优先级大相径庭。这很难，你知道吗？是的。是的。这是一个非常好的观点。你如何影响其他有其他优先级的团队，对吧？
考虑到他们提供给你的这些数据，有时会出错，你无法从中提取最大的价值。所以这几乎就像你必须向上提升你的食物链，以便他们能够水平移动，然后向下移动他们的食物链，而不是你只是去和那个团队交谈，说，嘿，我们可以设置这样的东西吗？
是的。所以你尝试了数据契约，数据契约被积极地实施，或者生产者只是说，“是的，我们会解决这个问题。”而他们从未这样做。第二个选项。是的。
这听起来与我听到的一些情况非常相似。好的。在我们跳跃之前，我想强调一下你正在创建的关于 Databricks 的课程。我认为对我来说很清楚，因为在过去一个小时里，我一直和你谈论你作为实践者对 Databricks 的了解程度。你一直在亲自动手处理所有 Databricks 的事情，而且你一直在关注所有即将发布的内容。
这门课程是关于什么的？什么时候开始？我该如何报名？
是的，这是我们在 Maven 上开设的基于群组的课程。我们的想法是，我们真的想教我们所知道的关于 VML 和 Databricks 的一切。这是一个非常实用的课程。每周我们都会学习一部分理论，我们实际上会向人们展示代码并解释它是如何完成的。每个人都需要创建自己的代码
基于他们自己的数据集，我们审查拉取请求，每周迭代地涵盖另一件事，到课程结束时，每个人都将拥有一个完整的端到端 ML 项目，几乎可以在任何公司重用。
所以，这始终是我们这门课程的目标，即创建一个非常实用的东西。我们在 Discord 上非常活跃。所以人们不断地问我们很多问题。课程结束后，我们也会保留，你知道，每个人都可以访问 Discord，我们在某种意义上建立了一个社区。
所以课程什么时候开始，下一个群组将于 5 月 5 日开始，一直持续到 6 月 23 日。我们还有一个将于 9 月 1 日开始的群组，这将是这个特定课程格式的最后一个群组，因为正如我前面提到的，我们将进入 LLM Ops，也许会有扩展的群组。我们还没有完全弄清楚它将是什么样子，但是
从 11 月开始，这将是一门不同的课程，好的，这门课程很棒，我还想提到你已经慷慨地为 MLObs 社区的每个人提供了一个折扣码，所以我们可以，我们将在描述中留下一个链接，其中包含折扣码和所有内容，这太棒了，谢谢你，你也在写一本书，这本书是关于什么的？
好吧，使用 Databricks 的 MLOps，还有什么？你应该知道的。是的，我应该知道的。这基本上是我所有脑力的倾泻。我知道的关于 MLOps 和 Databricks 的一切都会在这本书中。这基本上是我一直想要拥有的指南，如果我刚开始使用 Databricks 的话。也非常实用，包含各种考虑因素。
所以这本书将在明年年初出版，但章节的早期版本已经出来了。我认为第一批章节下周就会出来。但我也相信大约一半的书会在 7 月份出来。我将在 10 月左右完成这本书的写作。至少这是目标。
所以章节将出现在 Riley 平台上，所以任何有权访问 Riley 平台的人都可以阅读它。所以是的，如果你想提前访问，这就是方法。