这是我们在Metacog的朋友的博客。luiscaro是Metacog的首席云和DevOps架构师，负责整个平台的安全性和可伸缩性。dougstein是Metacog的首席技术官，他负责产品战略和开发；他兼任产品所有者和市场代言人。在Metacog，我们使用Databricks作为我们的开发和生产环境已经一年多了。在这段时间里，我们构建了一个带有数据链的健壮的持续集成（CI）系统，这使得我们能够更快地发布产品改进。在这个博客中，我们将描述如何使用Databricks、GitHub、Jenkins和AWS构建CI系统。什么是Metacog？Metacog允许公司用真实的性能任务（通过由客户提供的评分准则和培训集通知的机器学习算法评分）来代替简单的评估（例如多项选择）。我们通过提供一个学习分析API-as-a-service来实现这一点，它允许我们将一个人与在线操控者的互动（即实时事件）转化为对其理解的准确评估。该产品为我们的客户提供了一个API和JSON wire格式，用于大规模吸收、分析和报告"元认知活动流"（学习者如何处理开放式的绩效任务，而不仅仅是最终答案）。看到了吗https://phet.Metacog.com/invisibleLink例如，这是一项针对中学科学的表现性任务。Metacog平台适用于K-12、大专、企业、军事等领域的学习（指导、培训或评估）。持续集成/交付的需要Metacog支持数以千万计的并发学习者（每个人都可能以高达几十到几百KB/秒的速度生成活动）。这是一个大数据，平台需要能够在不丢失的情况下接收数据，并应用各种具有最佳性能、可靠性和准确性的机器学习算法。为此，Metacog使用Databricks作为开发和运行分析和评分管道的主要计算环境来实现apachespark。Metacog开发团队由后端开发人员、devops和数据科学家组成，他们不断地对平台代码、基础设施和机器学习功能进行改进。为了使这个"从研究到开发再到生产"的流程真正成为一个流线型和敏捷的过程，Metacog为所有的Spark代码部署了一个持续集成的生产系统。Metacog的开发管道Metacog开发管道确保了核心开发人员和数据科学家能够：访问代码的最新版本。在他们喜欢的工具集中开发和运行代码——我们的团队除了使用内置的Databricks笔记本之外，还集成了IntelliJ等ide和Databricks。合并改进，然后自动部署（无需人工干预）到镜像生产环境的共享阶段环境。开发流程如下图所示：管道的工作原理如下：开发人员使用GitHub同步他/她的本地开发环境（可以是笔记本或IDE）。每当开发人员在特定的分支上提交代码时，Metacog-Jenkins服务器会自动测试新代码；如果测试通过，则构建代码并将其部署到实时测试基础设施中。此基础结构由生产资源的精确副本组成，以便在将更改部署到生产环境之前进行负载测试和最终检查。在Spark代码的情况下，实时测试使用使用Databricks作业功能创建的多个Spark集群。管道中的主要部件有：Databricks笔记本：提供一个协作的在线编辑环境，允许开发人员和数据科学家在一个真正的Spark集群上运行他们的代码（而不是在笔记本电脑上使用Spark本地模式）。笔记本电脑允许数据科学家在大数据集上测试和调整机器学习算法和方法。类似地，笔记本允许开发人员评估算法性能并检测/修复只在大数据集中出现的错误。Jenkins持续集成服务器：Metacog使用Jenkins进行连续测试并交付所有开发人员代码。Jenkins保证来自多个开发人员的不同提交通过所有单元测试，并且在没有开发人员或devops帮助的情况下交付和部署代码。每次开发人员对主分支执行提交时，Jenkins都会自动测试并构建分支代码。Databricks工作区库：当笔记本需要使用来自外部源或库的代码时，这个接口允许将JAR附加到运行笔记本的集群上。这样笔记本代码就可以引用和使用附加的库。amazonwebservicess3：一个对象存储服务，Jenkins使用它来存储Spark和非Spark代码的所有构建文件。Databricks作业：作业接口根据调度和自定义触发器将代码部署到集群。Metacog使用这个接口来部署和维护livetesting和productionspark集群，以保证它们的稳定性和可伸缩性。多亏了Databricks-Jobs接口，Metacog基础设施团队可以根据平台需求和预期使用情况轻松地提供一组特定的集群。它简化了版本管理和服务器配置，使团队能够优化成本和性能。（另一个好处是：DevOps不必不断提醒开发人员或数据科学家自行清理并关闭未使用的集群！）在下面的部分中，我们将详细描述我们如何使用Databricks api来自动化管道中的两个关键功能：将构建的jar部署为库（组件1和组件3），以及使用最新的构建（组件5）更新阶段和生产资源。将部署的库与Databricks笔记本一起使用开发人员和数据科学家都需要能够在他们的笔记本中使用来自生产代码的任何方法或类。有了这些库，他们就可以访问生产数据，测试或评估不同版本的生产代码的性能。使用库API，Jenkins服务器可以将JAR文件作为库构建并部署到Databricks工作区的一个特殊文件夹中。当Databricks加载这样的库时，它会识别版本控制，这样开发人员就可以为他们正在开发的代码使用库的兼容版本。这使开发人员能够控制何时采用新的库版本，并为他们提供了一个稳定的基准测试和回归测试环境。每次有人向stage repo提交代码时，Jenkins都会遵循以下步骤：构建repo代码，如果测试通过，它将生成一个带有递增版本号的JAR并将其上载到S3。执行一个Python脚本，该脚本使用awsdk和jars3url，为JAR生成一个预签名的URL，并调用Databricks API"libraries/create"端点。由于libraries/create调用需要一个JAR url，因此S3预签名url非常适合我们生成一个有效期为几分钟的公共url。通过使用预签名的URL，我们授予Databricks-API有时间限制的下载构建JAR的权限，从而降低了JAR暴露的风险。def createlibrary（路径，jarurl）：head={'Authorization'：DBAUTH}endpoint=DBBASEENDPOINT+'库/创建'newpath="/"+路径data={"path"：newpath，"jar_规范"：{"uri"：jarurl}}r=请求。会话（）.post（端点，headers=head，data=json.dumps文件（数据）如果r.status U代码==200：打印"为笔记本上载的库"其他：打印r.内容过程完成后，开发人员可以使用Databricks web控制台将这些库附加到任何笔记本集群或作业上。以下是Jenkins构建输出的示例：下面是更新作业后Databricks工作区的一个示例（注意清单末尾新构建的v376jar）：用Jenkins更新Databricks作业和集群设置Metacog使用Jobs API来部署和管理生产和stage Spark集群。除了上面描述的步骤外，在构建新版本的库时，Jenkins必须更新所有作业，以确保集群使用新的构建JAR和该JAR的正确Spark版本。这个功能是通过使用存储在S3上的构建文件和使用Databricks作业API更新作业的python脚本来实现的。分三步完成（如上图所示）：步骤1：Jenkins将构建JAR与上次生成.txt指定JAR版本号第2步：Jenkins运行一个python脚本，执行一个名为deployJar的作业，该作业运行一个笔记本，将Jenkins构建的JAR从S3复制到"dbfs:/FileStore/jobjars"。Python脚本使用"jobs/runs/list"和"/jobs/run now"端点触发deployJar并等待它完成。deployJar笔记本如下所示：步骤3：为了使用新的JAR和任何其他Spark集群设置（例如新的Spark版本）更新生产和阶段作业，Jenkins执行一个Python脚本，该脚本调用Databricks API"jobs/reset"端点。"jobs/reset"端点是在步骤2中创建的"dbfs:/FileStore/job jars"路径。以下是上一个示例的更新作业：成果与效益多亏了Databricks环境和api，我们成功地实现了所有Spark代码的连续交付管道。Metacog团队现在享受的一些主要好处是：缩短了将特性投入生产的时间：在实施流水线之前，新特性需要大约1个月的时间才能融入到平台的生产版本中。随着管道的使用，这一时间被缩短到仅计划进行现场测试的1或2周。这意味着发行节奏从每年12次提高到每年至少24次。更好地管理awsec2成本：DevOps不必不断提醒开发人员或数据科学家进行清理