从拥有5亿多台设备的2000多万智能家庭中提供洞察

Sameer Vaidya:我们希望你，你的家人和你所爱的人都是安全的，今天能够帮助有需要的人。我们欢迎你参加我们的会议，我所提供的是普遍的和平信息。
(唱)
你们都在这里听我们的讲座来了解我们是如何将我们的数据实践发展为服务洞察和分析的在历史上，超过2000万智能家居消费者拥有超过5亿的连接设备，好吗?为了开始我们的会议，我们想先给你们一些背景知识，作为一个企业，Plume是做什么的，它的业务需求是什么，以及我们试图解决的一些问题是什么?以及我们各个数据团队在解决这些问题时的关系。我要讲的是一些公众可以在网上看到的东西。但从这一点，我将尝试得出一些我们今天正在解决的内部挑战。因此，Plume的业务是为互联智能家居提供消费者体验。
我们在数千万个家庭中运行我们的产品并在这些智能家庭中监控和管理各种类型的服务，明白吗?为了让您了解我们的业务团队正在寻找的一些东西，我将谈论一些业务团队，他们是我们数据产品的利益相关者和消费者。首先，你可以在plume.com上看到我们最近在2000万智能家居发布庆典上提供的信息。营销人员想要从我们拥有的数据中提供一些见解，这样他们就可以在公共网络上发起活动。所以市场营销是我们的消费者之一。他们会根据从不同类型的连接设备中获得的见解，寻找家庭、世界各地、客户不同部署中正在发生的事情。所以在左边，你可以看到一个热图，显示了我们在全球的所有部署，我们必须每天更新。
同样，我们也有来自产品管理的请求。产品经理想要了解各种功能是如何工作的，人们是打开还是关闭它们，它们在现场的表现如何，等等。同样，这发生在我们世界各地的家庭中。我们的产品团队中有一些人，他们是产品工程师或算法工程师，他们试图改善和优化我们的产品在联网智能家居中的性能。他们会问，我们的产品优化效果如何?连接设备的体验质量如何?这些类型的指标和关键绩效指标，他们希望看到我们在一段时间内的地理位置以及我们收集的不同类型的遥测指标。你在这里看到的最明显的是像一天的交通模式，网速测试和时间的可用性跨时间跨地域，对吧?
另一个认真使用我们大量数据产品和见解的团队是我们的NetOps团队。这是网络运营团队，负责在许多不同的地区，在许多家庭推出功能和格式更新。当他们推出新固件和新版本的软件时，他们想要了解的是，与引入变化之前的情况相比，所有东西都仍然稳定地运行并具有竞争力。这些就是我们要为不同类型的利益相关者服务的不同类型的见解。
提供这些见解的团队横跨三种类型的团队。我们有数据工程团队，通过构建管道来摄取和处理数据。我们有一个数据科学团队，他们使用我们的数据来调整和优化他们的算法，并引入产品创新。我们有商业智能和分析团队，他们获取数据和我们在数据仓库中生成的Tableau，并通过仪表板、特别报告和我们的利益相关者要求我们的各种类型的洞察来暴露它，对吧?
这就是我们公司和团队结构的背景以及我们正在努力解决的问题。现在，我们来看看这次会议的议程是什么?我们是，我是萨米尔·维迪亚。我在Plume公司担任架构师，主要从事数据工程BI和分析方面的工作。稍后，我的同事Raghav Karnam将加入我们。他是公司数据科学和机器学习工程方面的专家。他会讲一些他们在机器学习方面所做的事情，并与你们分享一些从中得到的见解。我们今天的课程是针对初学者的，我们把它宣传为初学者水平的课程。
我们所说的初级水平是指那些相对较早地采用这些不同技术来构建大数据分析的人。特别是，如果你对Databricks，数据平台，Lake house, SQL分析等领域感兴趣的话。bob体育客户端下载我们今天要讲的是我们如何在这些技术上建立我们当前这一代的数据处理平台，以及我们从中学到的经验教训，以及整个环境是什么样的。bob体育客户端下载我们将讨论如何使用工作集群来提高我们的生产力。我们使用笔记本来提高开发人员的工作效率，并在数据处理方面进行元数据管理，将我们正在处理的大数据转换为各种应用程序的SQL可查询数据。我将重点关注这一点。Raghav加入我们的时候，他会讲机器学习的生命周期，好吗?
我们希望那些刚接触这一领域的人，从我们今天的演讲中，对于那些更有经验的人，你觉得你知道很多这方面的东西，我们也希望，既然你参加了我们的课程，我们希望你能从我们的课程中学到一些东西，获得一些见解和顿悟。你在我们身上投入的时间是值得的。你是否喜欢我们的会议，我们要说什么，我们公司在做什么。我们希望您能推荐您的朋友申请梅数据领域的工作。我们的大数据之旅从早期就开始了，大约5年多以前。当我们开始研究数据处理和分析时，我们倾向于选择Apache Spark框架来进行所有的数据处理。
在一段时间内，我们一直在使用它，并且成功地使用它。同样，从早期开始，我们就是一个大型的AWS商店。因此，我们已经在全球多个地区采用并部署了AWS，我们对这个平台和托管服务非常满意，也非常成功。bob体育客户端下载因此，从早期开始使用Spark进行数据处理时，我们就自然而然地倾向于使用现有的AWS大数据处理框架。为了处理大数据集群，我们使用AWS Elastic MapReduce，它为我们提供了托管集群，您可以单击并很容易地生成这些集群供您处理。一旦您完成了数据处理，以便通过我们的数据SQL分析仓库公开数据，我们就开始使用AWS Athena，它获取底层数据并使其通过SQL访问。
把Athena看作我们的数据仓库。为了获取底层的大数据，并通过SQL over Athena公开它，你必须使用一种叫做AWS Glue爬虫的东西。我几乎从来没有正确地说过Glue crawler，但我想这次我说对了。Glue爬虫采用底层文件系统，无论是Avro、Parquet还是JSON或CSV，并自动生成元数据，以SQL数据库和Tableaus的形式公开，您可以配置它来实现这一点。这就是我们最初的基础设施。在早期，当我们的团队规模很小，我们处理的数据量也很合理的时候，它运行得还不错。经过一段时间，随着数据的发展，我们开始得到越来越多的数据。开发人员的数量增加了。我们开始有越来越多的团队建造这些工作。我们在保持所有东西的一致性和标准化方面遇到了一些困难。
开始发生的是，我们开始遇到一些瓶颈我想谈谈我们面临的一些挑战以及我们是如何克服它们的。因此，我们将从Spark数据处理集群开始讨论。我们当时的发现，大概是两年前，就是我现在描述的这个时间点。这些挑战是我们两年前面临的，然后我会解释我们是如何克服它们的。所以在Spark数据处理的时间点上，我们发现我们在开发和生产中都在处理数据。在生产中，我们的DevOps团队喜欢为我们控制和管理资源。
我们发现，当人们开始在生产操作中使用EMR集群时，我们开始写越来越多的工作。我们发现，如何确定EMR集群的大小、如何配置它们、如何扩展它们以及如何以一种及时的方式将它们用于我们正在处理的工作是很复杂的。事实证明，当时我们还没有完全弄清楚如何实现自动化。我不知道这在今天是否可行，但至少在那时，我们有一个基础设施，我们可以创建一个集群，让它继续运行，因为它对我们来说太复杂了，不能终止它，关闭它。然后再重新配置，重新启动。因此，由于这种复杂性，我们养成了只构建一次EMR集群并让其运行的习惯。一旦你让它们运行，然后随着我们开始增加越来越多的工作，我们就变得很复杂，要弄清楚如何扩大它们的规模，如何扩大和缩小它们。我们没能算出来。
对于在生产环境中运行的集群，我们发现对于一些不经常或偶尔在一天中运行的批处理，我们整天都在运行集群，这实际上大大降低了这些集群的资源利用率，并为我们没有使用的资源付出不必要的代价。这就是生产过程中发生的事情。在开发过程中，由于开发人员想要创建他们自己的集群，我们经历了一段时间，我们让开发人员做他们自己的集群。而这种灵活性又给我们带来了回报，因为在某些情况下，开发人员所做的就是让大型集群在长周末运行，并意识到他们不是超级负责任的。
原因是没有一种简单的方法来构建一个集群并自动暂停，然后返回工作并启动它等等。所以我们称之为缺乏自动化。我们发现开发人员不能非常负责任地使用它们。因此，我们经历了一段时间，我们试图创建集群并管理集群的共享。这变得相当复杂，因为在集群上使用共享库的后勤工作等等。这就是我们在集群中遇到的一些挑战。在这一点上，就开发过程而言，我们发现大多数开发人员都在使用Spark提交作业，要么评估在集群中搜索并在Spark Shell上运行东西，要么只是运行作业并查看日志文件来进行调试和故障排除。
总的来说，我们发现开发人员的经验和生产力相当低。可能有一两个足智多谋、勇敢的工程师想出了如何使用笔记本电脑，但这并没有被广泛采用。所以出于某种原因，就开发者体验而言，我们一直生活在黑暗的洞穴时代。这些是我们在Spark处理中遇到的一些挑战。实际上，对于底层进程的数据和公开，我们发现的是胶水爬虫……对不起，我的错。我想回到AWS，雅典娜。我想谈谈我们和雅典娜在一起时遇到的挑战。所以有了雅典娜，我们大部分时间都很开心。它对我们试图做的几乎所有查询都表现得很好。有几个方面是我们的陷阱。
其中一个领域是，虽然大多数查询工作得很好，但我们发现在某些情况下，当我们的数据科学家试图通过对长时间收集的大型数据集运行复杂的查询来寻找深入的见解时，他们发现他们想要运行复杂的SQL。他们发现他们会运行几个小时，然后最终会超时或耗尽资源。他们实际上无法完成这些查询。我们发现的阻碍因素是似乎没有任何真正的解决方案。所以在这里你可以看到，如果你超时了或者你试图使用他们不愿意给你的资源，你就会得到这个。
这是因为Athena是一个无服务器环境，无服务器有优点也有缺点，优点是你不必搞乱容量规划和管理资源，这是它吸引人的地方。缺点是，如果您有一个复杂的、大型的查询想要运行，并且您愿意为它付费，因为它对您来说足够有价值，您不介意使用额外的资源，旋转它们并为它付费。真的没有这样的选择，你在那边运气不好。因此，在这种情况下，无服务器的概念对您不利，因为您无法控制旋转所需的额外资源以进行所需的处理。这是我们不太喜欢的一点。
我们遇到的另一个问题是一些可用的数据，我们找到了一种方法，将其暴露给我们的支持代理。他们发现将这些数据放到支持web应用程序中是非常有用的。他们会用它来服务客户支持电话等等。我们认为这很棒，我们可以通过这些网络应用程序公开这些雅典娜数据。在支持数量开始增加之前，它运行得很好，然后随着数量开始增加，我们发现雅典娜为固定数量的积分提供了固定数量的队列。如果有一天有太多的支持代理在应用程序上工作，突然队列就会被填满，没有其他处理可以工作。其他所有人现在都被阻塞了，因为所有的队列都被支持代理占用了。
然后我们意识到，“哦，这不好，因为这是一个共享队列，每个人都在帐户中使用它，这是行不通的。因此，无法控制资源池并决定应用程序的哪个消费者可以获得多少资源的想法，但设施是不可用的。因此，在这种情况下，我们开始感到受到无服务器概念的限制。最后一个领域是元数据管理。Glue爬行是，虽然我说过，大多数时候当开发人员构建这些底层管道时，他们发现配置这些爬行程序非常容易，将它们指向一个位置。它会自动生成元数据。经过一段时间的有机发展。它运行了一段时间，直到它停止工作，好吗?
我们注意到，随着时间的推移，我们的模式开始进化。随着模式的进化，模式的版本也在进化。当我们改变一些处理技术时，我们发现底层文件系统中的某些文件引入的方式与以前不同，因为我们改变了技术。我们注意到，如果开发人员不小心配置爬虫程序，只使用正确的排除子句和正确的参数，爬虫程序就会开始产生大量无用的手工或不正确的元数据。所以这是一个基于某些潜在情况可能发生的事情的例子。所以爬行器突然开始生成大量的Tableau数据，因为它认为底层的分区或文件是数据Tableau，因为它自动地试图检测Tableau是什么。在这种情况下，如果你不是很小心，或者如果有一个特定的情况，你没有解释清楚，很容易你就会把它搞得一团糟，对吧?
所以我们发现这种基于爬行的自动元数据管理系统的想法并不是一个很好的情况。这些就是我们一直在努力解决的问题。于是我们决定寻找一个更好的解决方案。我们遇到了Databricks, Databricks第一次展示了集群的概念。我们非常喜欢它，因为在集群中，他们向我们展示了你可以在开发人员之间创建这些标准集群或共享集群。创建和配置它非常容易。对于你的工作，你创建了一种叫做工作集群的东西。当您提交作业时，作业集群就会自动启动。工作完成后，他们就把房子拆了，就这样。你为你的工作付出了正确的代价。 There is no idle time, underutilized resources.
同样，我们开始提供给开发者的标准集群，或者我们可以根据他们的技术提供给开发者，他们有构建集群的概念，然后当它被偶像化时，它就会被告知并关闭，你不再支付底层的计算成本。当开发人员准备再次使用它时，他们只需单击一个按钮并重新启动该集群，对吗?在某些情况下，您只需向它提交一个查询，它就会自动启动集群。所以我们发现这很有吸引力，我们决定接受它。与元数据管理类似，我们非常喜欢Delta Lake的概念。
Delta lake是一个自显式管理系统，这意味着不需要外部额外的爬虫来查看底层文件系统并确定Tableau结构和模式是什么样子?Delta系统在更新数据时写入数据和元数据。因此，权限和更新是繁重的，但读取是快速、快速和有效的，并且有一种方法来优化底层数据。因此，我们发现这比必须构建、显示基于爬虫的自动化元数据管理系统更有吸引力。
这些是一些吸引我们开始使用数据库的东西。在接下来的几张幻灯片中，我们将向你们讲述我们如何过渡到Databricks平台的过程，我们解决了哪些挑战来扩大我们在全球范围内的处理?bob体育客户端下载我们从中得到了什么好处呢?所以让我们从第一个主题开始，这是关于操作生产力和开发人员生产力的讨论。为此，我们不得不在世界各地的不同区域部署Databricks工作区。然后让开发人员在处理的各个领域使用它们。
我要讲的是我们是如何做到这一点的以及我们必须克服的一些挑战，以及我们从中获得的一些最佳实践，好吗?现在认识到Databricks是一个已安装的产品，这意味着它不像AWS原生产品，您可以单击某些AWS服务并启用并打开它。您必须实际规划Databricks安装，它被称为工作区。在我们的案例中，因为我们在多个地区运营，在世界各地有多个AWS VPC。我们必须计划任意数量的工作空间。现在，我们大概只有不到10个这样的项目，但我们必须为此做好计划。在每一种情况下，我们都必须为对偶进行规划，这是每个区域的开发工作空间和生产工作空间的想法。
为此，我们意识到一些需要注意的事情首先，我们必须标准化命名空间。我所说的名称空间是什么意思?任何给定的Databricks工作区都有一个URL，您可以使用它来访问和引用它。因此，我们得出了命名的最佳实践应该在任何地方都一致使用，因为如果您弄错了，不幸的是没有简单的重命名命令。你必须拆掉整个建筑，重新建造。因此，在经历了如此昂贵的一课之后，我们学会了标准化名称空间。今天我们遵循一个模式，类似于公司名称和域名的破折号和地区名称。然后，你得到。cloud。www.neidfyre.com。因此，在开始安装所有工作区时，我们将该名称空间标准化。
在计划工作空间时，我们还意识到应该计划bucket名称。再次强调，这是必须对桶名进行标准化的事情之一，因为一旦在安装期间选择了桶名，就不能更改桶名，对于自动化和DevOps以及所有这些实践来说，最好在所有地方使用一致的市场名。因此，我们了解到在创建这些工作空间时应该标准化名称空间。用户和组，所以在AWS中在我们的帐户中在不同的vpc中，我们只需要创建组和用户一次。世界各地的AWSIM也提供同样的服务。但对于Databricks，情况并非如此，因为每个工作区都有自己的用户和组概念。这意味着我们必须在每个工作区中管理用户和组。想象一下乘以9或10个，对吧?
但好消息是他们提供了SAML单点登录，这叫做略读集成。有了这个，你可以使用我们的SSO。因此，我们使用单点登录SAML标识提供程序，并在IT部门维护的SAML SSO中映射用户和组。因此，任何时候新用户或新员工加入公司，作为入职过程的一部分，ID将他们提供给我们的单点登录提供商。然后底层集成自动将用户和组推入Databricks工作空间。这使得我们能够在这些大量的工作空间中进行用户管理。这就是我们解决问题的方法。在每个区域中，都有不同的资源，比如集群、作业、数据库等等。因此，我们很快意识到我们需要自动化基于角色的访问控制，并将其一致地应用到每个工作空间。
因此，我们必须构建一些脚本，将所有这些东西作为资源管理角色的基础，并将它们自动应用于所有这些工作空间。这些都是你需要注意和计划的事情。我们还意识到，在跨越这些不同的区域和工作空间的一段时间内，Databricks本身也在升级其底层服务。在不同的时间段里，它们会经历维护和升级阶段。我们发现，我想要大声喊出statusstarwww.neidfyre.com，我们发现当一些事情看起来不太对的时候，它非常有用，我们想知道这是我们的问题还是他们的问题，你可以看看statusstarwww.neidfyre.com，它告诉你在世界各地的不同工作区和地区发生了什么。
这就是我们在世界各地建立不同工作空间的方式。现在，一旦我们设置了这些工作区，我们希望开发人员开始使用它。我们注意到，几乎从第一天开始，每个人都迅速倾向于使用笔记本作为他们的集成开发体验，作为他们的ID选择。我很自豪地宣布，一年后，我们进行了一项调查，许多开发人员在调查中声称，他们主观地认为，通过使用和采用笔记本电脑，他们的生产力提高了30%到50%。对于笔记本电脑来说，最酷的是笔记本电脑里有单元格。在单元格里，你可以用你选择的语言书写。所以我们有使用Scala的数据工程师。所以他们现在在Scala所做的就是开发他们的底层工作并创建jar文件，然后上传到集群中。然后他们就可以在开发和测试中与它交互，看看他们的工作工作得如何。他们可以通过笔记本与Scala代码进行交互。
我们的数据科学家能够编写基于生物素的代码，然后使用Python代码与他们的底层算法交互，等等针对他们的数据。我们的SQL分析师能够使用SQL，他们使用SQL单元来交互和处理数据，用笔记本进行开发过程。这一切都运行得很好。我们能做的一件有趣的事情是，以前我们的分析师会依靠数据工程师把任何东西转换成预定的工作，但现在有了笔记本电脑，他们能做的是，他们能用SQL写一些代码，然后点击一个按钮，就把它安排成预定的工作。这很简单。因此，您只需为作业编写代码和逻辑，然后调度它，Databricks将按照您指定的调度运行它。因此，他们能够快速轻松地获得一些东西，并将其作为一项工作进行推广，而无需等待数据工程团队为他们做这件事。
经过一段时间，我们学到了一些东西。一是早期的笔记本没有底层Git支持，但最近他们引入了GitHub存储库支持，我们对此非常满意。GitHub存储库允许我们将笔记本映射到底层存储库，并在底层存储库中管理它的版本。所以你当然应该看看GitHub回购。然后在调度方面，我们了解到所有的调度作业都非常好和方便，我们没有连接到基于airflow的作业监控系统。
所以在一段时间后，我们把这些转换成气流来得到监测。因此，我们停止使用Databricks调度器，而是简单地使用风流来调度这些作业，以获得作业依赖项和监视。所以我们开始使用《气流》。你可以做的另一件事是，如果这还不够，我们还有其他一些可供开发者使用的体验。首先，您可以使用Simba驱动程序进行配置。可以配置SQL ID。你可以用你喜欢的商业SQL ID连接到Databricks集群，或者你可以用你的开发人员ID，比如IntelliJ或Pycharm，或者类似的东西，用Databricks connect技术提交你的代码到Spark集群。我们的开发人员使用所有这些技术的组合将提高他们的开发效率。
我们现在已经讨论了集群。对于集群，我在前面提到过作业集群、高并发性和标准集群。因此，对于作业集群，我们所做的就是从气流作业中提交作业，负责该作业的每个开发人员可以决定该作业需要多少资源。他们在写气流标签来创建作业大小。抱歉，是集群大小，并将那个作业提交到集群。然后Databricks会在你指定的时候启动一个集群，但在你的工作上，然后像我说的那样把它拆掉?在这里，我们所做的就是使用集群策略的概念这样我们就可以保持一定数量的限制和完整性检查这样就不会有人在我们不知道的情况下疯狂使用它，明白吗?因此我们使用了作业集群策略。
我们尝试了标准和高并发集群。由于开发人员工作的时间点不同，并发性不够，所以我们认为标准集群更适合我们。高并发集群的运行成本要高得多，但它允许……它以平衡所有传入请求的方式构建。因此，如果您有许多开发人员同时工作，您应该使用高并发性集群，但如果您偶尔使用稀疏的集群，您只需为他们提供专用的集群。在此基础上，我们发现了一些最佳实践。其中之一是，对于集群，我们最初尝试在所有地方使用Spot实例。我们很高兴这些实例可以非常便宜，您应该使用Spot实例。随着时间的推移，我们知道这是个坏主意，因为可能发生的是，有时作业会运行三四个小时，五个小时，然后它会终止，因为Spark Driver节点消失了因为底层的Spot实例被拿走了。现在你整个工作都失败了。
因此，我们学到的是，我们应该为驱动程序注释使用保留实例，而为其他所有事情使用Spot实例。这对我们来说非常有效。当开发人员提交这些作业时，他们必须在自己的凭证下提交作业，这并不是应该被发现的。一旦你这样做了，就没有其他开发人员可以排除你的故障了。因此，如果你的工作失败了，而你的一个队友想要帮助你完成这项工作，或者他们正在解决这项工作的故障，那是不可能的。然后Databricks介绍了服务原则。服务原则的概念允许你把我们看成是一个无头的服务用户，你可以在你的组中创建它并使用服务原则来启动你的作业。一旦你这样做了，你组里的人就能看到日志并进行故障排除等等。因此我们发现，我们应该学习管理作业的服务原则。
我们学到的一件事是子网的想法，我应该在之前关于规划工作空间的幻灯片上提到它，但这是我们在事后学到的一课，在某一时刻，我们在我们的一些处理上遇到了一些问题。我们发现，在安装工作空间时，我们的DevOps团队已经将它与一些其他服务一起安装在现有的VPC中，而Databricks的最佳实践建议您拥有一个具有足够子网空间的专用子网。我们经历了惨痛的教训。我们必须将其拆除并在适当的专用子网中重新构建工作区。
所以一定要记得给它一个专用的子网，并给我们足够的空间来成长。因为这是我们一开始学过的，我们想过我们可以用多少实例?对吧?但是随着处理的增长，我们突然意识到我们可以使用相当多的实例，并且我们可能应该计划一个足够大的子网，这样我们就不会担心耗尽空间。因此，您应该计划为您的底层集群和工作空间构建一个足够大的专用子网。对于高可用性，我提到我们使用气流进行作业调度。经过一段时间后，我们了解到Databricks服务和api都要经历一个维护期。这意味着，维护期是指在一段时间内，您的作业可能会调用API来启动集群并运行作业，但由于API正在进行维护升级，因此调用失败。
现在他们很好心地在状态频道、提醒和电子邮件提醒之类的地方宣布了这一点。但永远不会完全相同，您必须在作业启动和执行时考虑到这一点。所以我们学会了在一段时间内重试作业因为当这些APS消失时，它们会在15到20分钟后回来。然后我们了解到，与其让它失败并手动处理它，我们现在已经在我们的气流作业中构建了一个逻辑，在几分钟内重新启动作业，并尝试长达30分钟。现在这对我们来说很有效。我们了解到的另一件事是，在某些情况下，随着实例的数量开始增长，我们的数据处理也在增加，我们了解到在某些情况下，某个地区的AWS底层可用性区域耗尽了某些类型的实例。
当这种情况发生时，你无能为力。有一次，我们向Databricks的支持人员抱怨，但他们说:“看，我们依赖底层AWS为我们提供实例。如果他们没有这种实例类型，我们就无能为力了。”我们认为这是合理的。因此，我们学会了如何重试作业，以便让它在不同的可用分区中运行。这对我们来说工作得更好，现在如果底层可用性区域没有Instances，我们只需尝试另一个可用性区域，并在该可用性区域执行我们的作业。因此，您应该计划这样的重试逻辑，以便在原始可用性区域耗尽Instance类型时在不同的可用性区域中进行重试。我们经历过的另一件事，非常真实。他们在文档中提到了这个，叫做作业的项目效力。
还记得我给你们举的APA提交失败的例子吗?在这种情况下，我们发现重试逻辑会重新提交作业而同一个作业会运行两到三次。这实际上给我们带来了很多问题，因为在某些情况下，它会在下面写入多个文件，这会打乱我们依赖于底层记录计数之类的逻辑。所以它实际上会给你不好的数据结果。我们必须想办法解决这个问题。然后我们学到了这个东西叫做物品效力令牌。现在当我们提交作业时，我们使用项目效力令牌提交。这使得每一份工作在时间和空间上都是独一无二的。当我们重试作业时有多个提交时，我们不再遭受这个问题。
所以强烈建议使用项目效力令牌来提交工作。这些是我们在运营集群时学到的一些经验。这使得我们可以让开发人员以一种自助服务的方式完成大部分工作，大大减少了DevOps管理和维护这些集群的工作量和开销。
现在，随着人们开始使用这些集群，在某种程度上，我们必须更新我们的许可证，并计算出我们的支出。在此之前，我有点不好意思地承认，我们在追踪支出方面做得并不好，但现在我们已经吸取了教训。我们了解到他们有这些很棒的使用报告，你可以在其中使用AWS标签。只要你标记正确，你实际上可以用很多方法来分割你的支出。因此，随着时间的推移，我们学会了如何应用标签，以不同的方式看到我们的支出。从成本中心来看，我们把这些集群花在了什么样的项目上?哪个队在使用它?哪个所有者对某物负责?以及正在运行哪个环境和哪个区域的处理?通过创建这些类型的AWS标记来启动集群，我们现在能够查看使用报告并对其进行切片。
使用报告可以直接通过Databricks帐户管理控制台获得，也可以导出数据并构建自己的自定义报告。所以我们开始导出自定义报告，然后基于Tableau做我们自己的报告。这是非常有用的。所以我强烈建议你从一开始就为此做好计划。
好吧。所以我们谈到了建立集群和建立开发者体验。我想谈谈…转移话题，进入元数据管理，我们如何管理查询性能，以及我们如何从层次结构和SQL转移到Delta Lake。我们之前讲过Glue爬虫，我提到过Glue元数据系统保持Metastore的更新，Metastore本质上是Tableau的定义以及它们如何映射到底层文件系统?现在，当你转向Databricks时，我们不能尝试这种混合的想法，也许我们可以利用和重用现有的AWS Glue系统，等等。但这实际上是相当复杂的，并没有给我们一个明确的抑制这些担忧。因此，在苦苦挣扎了一段时间后，我们决定重新开始，将我们在AWS、Glue和Athena所做的工作与我们在Databricks所做的工作完全分开。
所以我们决定完全采用Databricks Metastore来管理Databricks的元数据。现在，我们想开始使用我们现有的每个人Parquet文件，简单地使用它来将元数据映射到Databricks Metastore。我们发现这些数据实际上有点复杂，因为这需要你做的是，它需要你自己写一个类似爬虫的程序。因为现在还记得，虽然我抱怨Glue爬虫，但好消息是它们至少在那里为您自动化了。但是如果你想用Databricks做你自己的Parquet和Avro，那么你就必须真正制定出你自己有效的元数据管理系统。我们这样做是因为我们想转移到Databricks，然后慢慢迁移到Delta。我将讨论Delta的迁移经验，但我们通过使用Parquet和Avro和Databricks SQL查询发现，它并不像最初的Athena系统那样高效和优化，Athena系统基于与Spark SQL不同的技术。
因此，基于这些经验，我们基本上决定尽可能快地迁移到Delta Lake，因为Delta Lake以一种更优化的方式安排底层数据，这与Databricks合作得更好。因此，如果你打算从Legacy、Parquet和SQL……对不起，Parquet和Avro迁移到Databricks，那么实际上，你应该立即计划迁移到Delta Lake，因为遗留底层的Avro Parquet支持虽然存在，但不是很好。SQL查询的性能都不是很好。你必须维护自己的元数据，编写自己的爬虫系统。所以如果有机会，我会避免这样做。所以我们必须通过这个系统并创建爬虫，但我会避免这样做。
现在，我们能拯救的是数据库公司的一种叫做自动装载机的技术。我们的常驻解决方案架构师帮助我们配置自动装填机，它工作得很好。有了自动加载器，你能做的就是写几行流代码，然后指向一个源。本质上，在流代码中，你可以把它转换成。把它写成Delta并保持最新。所以它就像我们的消化系统，把食物吸收到Delta系统。所以我建议你试一试。但我想花一点时间谈谈我们如何发泄我们现有的Parquet迁移到Delta，因为我认为这是我们要经历的挑战。你们中的一些现有的遗产没有尝试这样做，将不得不做同样的事情。
在这里，第一件事是你必须找出Parquet和Avro数据被使用的地方。这意味着你必须有一个非常干净的内部目录和数据沿袭理解什么是数据?数据在哪里?谁在使用它?它从哪里来?对吧?为此，您必须拥有所有的底层元数据。我所说的元数据是指DDL。对于这些数据，您必须为每个Tableau提供定义语言，以及它如何映射到底层数据。因此，我们首先为这些底层数据的所有部件和所有模式DDL编目。 And so once we did that, we started planning for how to convert the underlying Parquet into Delta. Now realize one thing that there is a quick and easy command for converting Parquet to Delta, because essentially Delta is just Parquet plus, it just write some metadata on top of Parquet.
这是一个非常简单方便的命令。但如果你有阿芙罗，对阿芙罗就没有这么简单的命令了。要把Avro转化为Delta还需要做一些消化工作?但幸运的是，我们的很多基础数据都是Parquet。所以我们可以做得更简单一些。因此，我们所做的是，我们必须首先规划其他消耗管道?现在意识到这一点，第一步是我称之为大鸟的东西，你必须把所有的底层数据从Parquet转换成Delta。一旦你这样做了，就解决了被转换的初始数据的问题。但是想象一下，就在第二天或者下一个小时，某个作业将要运行它将会写入更多的数据，对吧?
因此，你不希望出现这样的情况，即工作是将。抱歉，Parquet数据写入底层数据，然后将其转换为。然后我们要做的就是找出所有的作业都在读取和写入底层的Parquet数据，然后我们要对这些作业进行手术式的修改把读从Parquet写转换为读从Delta写转换为Delta ?所以我们必须使用所有这些管道，转换所有这些代码，并准备好。在某些情况下，我们还发现底层数据的外部消费者直接使用SQL加载数据和其他东西。他们直接从底层文件系统加载数据。我们必须和他们协调说，“嘿，我们正在把它转换成Delta，你们应该准备好了。当时间到来的时候，他们会和我们一起转移到这个德尔塔系统。”
在我们完成这些之后，我们创建了脚本来自动化和转换所有这些数据。我们暂停了所有的管道，下载了所有的数据，然后用新代码启动管道，它以Delta的形式读写?然后恢复所有管道。第二天，所有这些代码都是Delta格式的读写。这就是我们从Parquet转换到Delta的过程。为了保持与Athena的向后兼容性，有一种方法可以获取Delta数据，并通过清单系统公开它，并使其对Athena可用。现在，为此，我们还必须创建自己的MSE护理修复机制，以让Athena看到底层Delta数据已被更新。
所以您不能再使用现有的Glue爬行程序了。您必须构建自己的机制来获取底层数据，并定期刷新Athena的元数据系统，让它看到更新后的Delta数据更改。这就是我们从Parquet到Delta的转换路径。所以在最后，我们现在有了有效的开发人员生产力。底层数据被转换为Delta，给了我们自动化的元数据管理，而且性能更好，因为底层Delta系统有优化和整合文件的旋钮等等。因此，基于此，我们现在能够使用SQL分析，它通过SQL公开这些底层数据。为此，我们只是简单地利用了Athena的现有用途，并开始转移它们一个应用程序，一次一个用户。现在我们的Databricks Metastore已经实现并被填充，我们能够开始将这些底层应用程序从使用Athena转向使用Databricks SQL分析。
对于SQL分析，我们首先做一个SQL端点，我们称之为通用，并开始将大多数应用程序安装到它上面。而且只是在一段时间内，有人需要做更多的事情。我们开始为自定义端点和集群创建。另外，请注意，在SQL Analytics产品中，如果您对他们提供的SQLBot不是很感兴趣，我们可以使用像DBeaver这样的外部SQL ID。SQL分析也能够解决web api。我一直在抱怨资源耗尽。现在，我们可以通过扩展底层集群来满足API性能，从而使用SQL Analytics端点。这就是我故事的结尾。我谈到了我们如何克服工作空间管理、集群和笔记本电脑的一系列问题，我们如何升级到元数据并采用SQL分析。我希望这些见解对你有用。 I want to transition and hand this over now to my colleague Raghav. And he’s going to talk about what he’s doing with ML in the company, over two you Raghav.

Raghav Karnam:早上好，大家好。我是拉。我在Plume领导机器学习和数据科学团队。我在这里讲一下Plume的机器学习生命周期，以及我们如何帮助Databricks自动化很多事情。所以Plume在业务方面专注于大量的机器学习用例。第一个也是最主要的一个，我们开始了它能够无缝地为所有家庭提供wifi，对吧?给wifi一个最好的可能，给[听不清]最好的wifi体验。我们需要了解你家里有什么设备，你家里有什么动作。例如，大部分时间在您的客厅，我们必须调整我们的wifi到您的客厅。如果你的电视频率大多是5千兆赫，我们就得调整wifi线路。
为了做这些事情，我们需要了解你家里的设备的性质，你家里的设备，你在家里的时刻。这是机器学习帮助我们的一个非常大的领域。第二个方面是，一旦你有了wifi，你想用wifi做什么?你想做很多事，但你想要安全。你上网的时候想要受到保护。这就是我们的第二个用例，网络安全。[听不清]我确实在数字上保护我们的客户免受外部攻击。网络安全领域，我们在这个领域做了很多机器学习。那么很可能，就像这个话题所表明的，我们有2000多万个洞，5亿多台设备。这是大量的数据。 And how we can help our consumers, Plume is a consumer hold services business. Like say, wifi is our first service.
二是网络安全。第三，是预防做主动维护。有没有一种方法可以让我们知道你的wifi体验出现了故障，并在你意识到之前修复它?这是我们非常感兴趣的一个领域，因为我们希望为你提供最好的wifi体验，这是另一个领域。然后是另一个用例，我们如何用数字保护你。我们能为你提供人身保护吗?例如，今天当你不在家时，假设你正在使用[戒指]或任何其他产品。你的门上有传感器，等等。当你呆在家里的时候，如果有入侵者进来，你会看到一个弹出窗口说，“嘿，有入侵者”，对吧?但这里你需要一个外部传感器。 Can we do this without using external sensors with your access to wifi access points?
这是我们想做的挑战。我们怎么做呢?是机器学习的另一个目的。我们能用wifi信号感知运动检测吗?是的。答案是肯定的，我们已经在某种程度上解决了这个问题。在移动过程中，有很多挑战，比如你离家很远，但你的宠物在你家里移动。你不应该叫它入侵者。因此，在我们进化和改进自己的过程中，有很多侮辱。此外，Plume还有很多创新领域。 We have evoking, we can probably not discuss like this with all this information learning happening within Plum. So these are the machine learning areas of focus for us. And there’s a huge expectation for machine learning teams, because we have to be very fast on up to the needs to market, at the same time, adapt to the scale at which we are growing.
现在，让我们回到第一天。我们在第一代ML生命周期和mlop中面临的挑战是什么，我们是如何在Databricks中结束的?基本上，我们的进化是从一个单一的集中缓冲开始的。最初，当我们开始做数据科学和机器学习时，我们有一个非常小的团队，其中有热情的工程师，他们想做很多很酷的产品，这些产品会更快地进入市场。我们和其他人一样。我们有一个机器学习工程师和数据科学家负责研究胎儿生命周期的各个阶段。但在某个时间点，如果你想要增加功能范围生产的速度，明白吗?那时我们开始思考，有哪些不同的阶段以及我们如何优化每个阶段。例如，这是一个非常标准的过程，就像我们在机器学习中所涉及的步骤。
你阅读数据，你做每一件事，你做很多事情。你是怎么做到的?数据工程师应该以原始格式管理数据。然后，模型的构建通常是数据科学家的责任。那么，如何调整性能和指标呢?保持阈值。部署模型，我们通常让机器学习工程师来做。当现有的生产模式存在时，你如何做到这一点?你在A/B测试模式中添加了额外的模型，你如何做到无缝衔接?
最后的最后一步是当你集成模型时，你要与许多正在构建微服务的软件工程师进行交互，你可以多快地与其他团队集成，以及他们能多好地理解你给他们的机器学习模型，以便他们可以定义简单的通过或失败。这是另一个阶段。
最后一个阶段是不在生产中操作模型。你如何看待模型漂移或数据漂移，等等?这就是我们所关注的领域。就像Sameer在最初的幻灯片上指出的那样，数据科学家使用了很多这些东西。我们想从流程、人员、技术工具等方面进行细分，并优化这些东西。但你可以看到，人们清楚地定义了我们的旅程。这是人的部分和团队的部分，明白吗?也许是工具和技术，数据科学家最初是Viva的小团队，我们中的一些人足够聪明，为整个团队托管笔记本电脑，我们要去。但我们花的时间并不长。然后对ML实验进行跟踪，性能指标。 We had an open source MLflow on a specific server with attacking experiments. But they such a burden was on top of the data scientist’s head. So how do we adapt this? How do we free up the space and the burden on the data scientist? That does have one question to be asked?
这是第一个让我们发现Databricks的问题，甚至Databricks提供了一个名为Databricks笔记本的ID。这些笔记本帮助我们上下旋转Spark集群。以前，在以前的旧数据中，科学家用来启动EMR集群，并在单元中的自MLflow集群中托管笔记本电脑。这就是我们选择Databricks的地方，因为它可以帮助我们上下旋转集群。数据科学家不需要担心，而ID，笔记本它们总是由Databricks托管，所以我们不需要担心。这些是吸引我们的很酷的因素。
这是关于Databricks的第一个原因。然后我们真正地将它用于模型性能度量，MLflow和模型历史。MLflow用于跟踪性能指标和注册表?所以我带着一个样本走过去。我们的指南平衡了这个演示和其他一切，以迎合初学者和已经在使用它的人的兴趣。我冒昧地使用了一些开源数据来演示这个案例?bob下载地址在Plume和MLflow之间的一般架构，这是一个离线架构[听不清]实时架构。这就是它的样子。我们有各种带工作区的数据库。
我们有Databricks工作空间，我们有模板Databricks工作空间。我们有一个Databricks工作空间和生产工作空间的组合?工作空间的开发和生产工作空间的交互方式是非常常见的存储库，那是我们存储模型的地方，对吧?这就是总体架构的样子。大多数时候，我们的数据科学家和机器学习工程师从S3或[Mongle]或其他第三方数据源提取数据。他们在Spark集群上做功能工程。他们有自己的ML框架。我们在深度学习框架中使用了Horovod。我们使用MLflow来跟踪我们的实验，然后使用MLflow存储库来注册模型。注册的模型由生产Databricks工作区使用。 This is a general architecture which we have done, okay? And one of the good things we have all about is for example in case of Plume, we have multiple workspaces. We have a lock space for EMEA, Databricks workspace for EMEA, Databricks workspace for US, Databricks workspace for Asia Pacific, okay?
他写道，例如，每个地区，EMEA都有自己的开发情报和开发工作区。它有自己的登台工作区。它有一个生产工作区。所以我们所做的是我们所有的开发都发生在一个叫做开发空间的地方，在那里我们建立我们的模型，然后我们把它推到一个公共的共享模型沉积物的阶段。因此，我们保留了一个工作空间作为共享的现代注册中心或工作空间。这就是我们检查模型的地方。一旦注册了模型，就可以使用不同的工作空间访问它们。也可以是在不同的地区。他们可以在一个特定区域拥有集中的工作空间。而工作区在不同的区域可以访问该模型。
这就是我们所建立的。在接下来的幻灯片中，我将为你们演示所有这些东西，让你们看得更清楚。与其做架构幻灯片，我更想给你们看一个我们做过的小例子。在这个演示中，我们想要展示的是如何使用MLflow来训练、锁定和跟踪机器学习模型。
对于这种情况，我将使用深度学习模型。演示了LSTM自编码器的使用。但更重要的是，我们想向你们展示MLflow是如何帮助我们的?因此，在MLflow中，您可以随时设置您想要的任何名称的实验。在我的例子中，我只是在这里给出了一些随机的名字你可以通过点击这里来观看实验。这就是你如何在实验中创造[听不清]。然后用一个特定的运行名开始您的实验。
在这个例子中[听不清]是最新的运行时，但是你可以用你的自定义命名约定开始你的运行。一旦你这样做了，你就可以……剩下的步骤是非常有规律的。你得到列车数据，然后载入。那么在每一个机器学习步骤中最重要的一步，比如ILA，你想锁定的参数是什么?举个例子，当你使用MLflow实验时，如果你观察这里，这是我过去做过的两个实验。如果你点击这个实验，你会看到很多参数，这对你的模型跟踪是非常必要的。然后是衡量标准，比如损失或异常数量，或者你们定义的任何客户数据。这些就是指标。每个实验都有这些参数和指标。所以根据你的需要，你有机器学习算法，你选择这些参数和指标。 Few of them can be constant parameters. Few of them can be metrics, which will vary which [eek] with each and every run.
它也有伪影，如果你能观察到这些伪影。它有一个ML模型的行为，可行的文件和一切。回到过去，对吧?如果你回到上一张幻灯片，请稍等。所以一旦你创建了你的实验，你就用那个特定的名字来运行你的实验，你必须定义这些参数和奉献度量。对我来说，成本就是每一个业务环节。想象一下你的模型带着这些细分市场或者不同的国家，不同的产品细分市场或者不同的国家细分市场。您希望切片并在这些切片上监视您的模型性能。所以如何切片非常重要。您可能在脑海中有特定的指标。 You might have some time step seasonality based ones involved. So whatever it is, you have to set those MLflow log parameters.
这就是设置日志参数的方法。一旦你发送了一个日志参数，你就可以遵循构建深度学习模型的一般过程。我讲得很快，因为这些是常规步骤。我将使用调谐器，这是一个[听不清]空间调谐器。你可以使用任何调优器进行超模型参数调优?我想解释的最后一件事是这是你如何生活在你的参数中你要修复不好的方面和一切。然后这将是我的架构我如何知道LSTM层和dropout，等等。您使用自己的体系结构。一旦你训练了你的模型?然后记录你的指标，好吗? What you’re supposed to do is you’re supposed register your model. That’s what I wanted to cover. This is all training the model. One of the most important thing which I found is how do you wrap your pre-processes, the feature engineering and the model together so that you can get in a Python class, which can be leveraged by inference engines.
他们有一个非常漂亮的东西叫做MLflow PyFunc模型，你可以把你的自定义预处理和新模型加在一起，这样就可以[听不清]。这就是我们要做的。我们有一个自定义的预处理数据处理模块，能够利用您的模型。你还可以设置环境变量也可以设置标签，明白吗?一旦你这样做了，你就建立了[听不清]Python模型，然后现在我们就可以移动并将模型注册到远程存储库。我将向你展示如何将模型注册到一个积极的远程。
你想要找出你最好的实验，在你的例子中，你的[听不清]函数或者任何你选择的东西，对吧?对我来说，我只是设置这个实验。我将使用这段代码根据日志进行实验，明白吗?我运行我的日志，得到最好的实验结果。然后使用注册表文档，这是我想分享给你们的，就像在幻灯片中我分享给你们的有多个工作空间，现在，一个工作空间有一个公共注册表。在我们的指示器中，对于这个演示和一个特定的注册表URI，你可以设置你的注册表URI然后你可以把你的模型显示到那个特定的注册表运行你的模型，明白吗?这有点棘手，注册表URI和这个工作空间可以通过键访问公共工作空间?
这只是一个瞄准镜和一组三个键的确认。一旦配置了它们，您就可以访问公共存储库。这就是注册模型的方法。一旦你注册了你的模型，我只想给你展示注册的模型它们是什么样子的，注册模型的一个例子是，假设在放电之后，你可以看到它的各种运动每个版本，它是如何执行的等等。这就是诚信的第三个版本。看在他们的份上，我还是把运行和所有东西都拉出来了，但这就是你们注册的模型的样子。
你的推论是怎样的?推理是这样的，稍等一下，所有的推理模型，你在使用PyFunc模型，你可以调用数据。这一点非常重要，因为你们就是历史。您已经使用了您必须在您的工作空间中携带的那个，基于您出现的实际问题，您选择了模型的最新版本，或者在我的情况下，我使用了旧的现代版本2。
你可以把这个自动化你取一个特定的模型限制，特定的版本，然后在这里加载那个模型。然后你可以在上面进行推理，瞧，你得到了结果。我想这就是我想总结的地方。在这种情况下，这些都是常规趋势。红点只是性能中的异常或异常值。希望你们能看到一些。我试图概述您如何使用MLflow记录您的指标和运行，以及注册您的模型和推理。谢谢大家。祝你有愉快的一天。