这是一篇与 athenahealth 共同撰写的客座博文。
athenahealth 为全国医疗团体和卫生系统提供网络支持软件和服务的领先供应商。 其电子健康记录、收入周期管理和患者参与工具允许随时随地访问，为其客户带来更好的财务结果，并使其供应商客户能够提供更优质的护理。
在人工智能 (AI) 领域，athenahealth 使用数据科学和机器学习 (ML) 来加速业务流程并跨多个服务提供建议、预测和见解。 从首次在自动化文档服务中实施、以非接触方式处理数百万个提供者-患者文档，到最近在虚拟助手方面的工作和改善收入周期绩效，athenahealth 继续应用人工智能来帮助提高效率、服务能力和更好的结果为提供者和他们的病人。
这篇博文演示了 athenahealth 如何使用 AWS 上的 Kubeflow （一种特定于 AWS 的 Kubeflow 发行版），用于构建和简化端到端数据科学工作流程，以保留基本工具、优化运营效率、提高数据科学家的生产力，并为更轻松地扩展其 ML 功能奠定基础。
Kubeflow 是一个开源 ML 平台，致力于使 Kubernetes 上的 ML 工作流部署变得简单、可移植和可扩展。 Kubeflow 通过整合与 Kubernetes 良好集成的相关开源工具来实现这一点。 其中一些项目包括用于管道编排的 Argo、用于服务网格的 Istio、用于笔记本的 Jupyter、Spark、TensorBoard 和 Katib。 Kubeflow Pipelines 帮助构建和部署可移植、可扩展的 ML 工作流，其中可以包括数据提取、预处理、模型训练和模型评估等步骤，以可重复的管道形式。
AWS 通过提供自己的 Kubeflow 发行版（在 AWS 上称为 Kubeflow）为开源 Kubeflow 社区做出贡献，该发行版可帮助 athenahealth 等组织构建高度可靠、安全、可移植和可扩展的 ML 工作流，并通过与 AWS 托管服务的集成降低运营开销。 AWS 提供了各种 Kubeflow 部署选项，例如使用 亚马逊Cognito, 部署 亚马逊关系数据库服务 （亚马逊 RDS）和 亚马逊简单存储服务 (Amazon S3) 和普通部署。 有关每个选项的服务集成和可用插件的详细信息，请参阅 部署.
如今，AWS 上的 Kubeflow 为使用 Kubeflow 提供了一条清晰的途径，并增加了以下 AWS 服务：
许多 AWS 客户正在利用 Kubeflow on AWS 分发版，包括 athenahealth。
在这里，athenahealth MLOps 团队讨论了他们遇到的挑战以及他们在 Kubeflow 旅程中创建的解决方案。
与以前的 ML 环境的挑战
在我们在 AWS 上采用 Kubeflow 之前，我们的数据科学家使用了一套标准化的工具和流程，允许在用于训练给定模型的技术和工作流程中实现灵活性。 标准化工具的示例组件包括数据摄取 API、安全扫描工具、由 athenahealth 中的另一个团队构建和维护的 CI/CD 管道，以及由 MLOps 团队构建和维护的公共服务平台。 然而，随着我们对 AI 和 ML 的使用日趋成熟，为每种模型创建的工具和基础设施的种类也在增加。 尽管我们仍然能够支持现有流程，但我们看到了即将出现的以下挑战：
- 维护和增长 – 随着部署模型数量的增加，复制和维护模型训练环境需要付出更多努力。 每个项目都维护了详细的文档，其中概述了每个脚本如何用于构建最终模型。 在许多情况下，这是一个复杂的过程，涉及 5 到 10 个脚本，每个脚本都有多个输出。 这些必须手动跟踪，并提供有关如何在后续流程中使用每个输出的详细说明。 随着时间的推移，维护它变得很麻烦。 此外，随着项目变得更加复杂，工具的数量也增加了。 例如，大多数模型使用带有 GPU 的 Spark 和 TensorFlow，这需要更多种类的环境配置。 随着时间的推移，用户会在他们的开发环境中切换到新版本的工具，但是当这些版本变得不兼容时，他们就无法运行旧脚本。 因此，维护和扩充旧项目需要更多的工程时间和精力。 此外，随着新的数据科学家加入团队，知识转移和入职需要更多时间，因为同步本地环境包括许多未记录的依赖项。 在项目之间切换面临同样的问题，因为每个模型都有自己的工作流程。
- 安保行业 – 我们重视安全，因此优先遵守与机器学习和数据科学相关的所有合同、法律和监管义务。 必须以特定方式使用、存储和访问数据，我们嵌入了强大的流程，以确保我们的做法符合我们的法律义务并与行业最佳做法保持一致。 在采用 Kubeflow 之前，确保以特定方式存储和访问数据涉及跨多个不同工作流的定期验证。 我们知道我们可以通过将这些不同的工作流程整合到一个平台上来提高效率。 但是，该平台需要足够灵活，才能与我们的标准化工具很好地集成。
- 运营 – 我们还看到了通过集中记录和监控工作流来提高运营效率和管理的机会。 因为每个团队都开发了自己的工具，所以我们分别从每个工作流程中收集这些信息并汇总它们。
数据科学团队评估了用于整合工作流程的各种解决方案。 除了满足这些要求外，我们还寻找能够与现有标准化基础架构和工具无缝集成的解决方案。 我们选择 AWS 上的 Amazon EKS 和 Kubeflow 作为我们的工作流程解决方案。
包含 Kubeflow 的数据科学家开发周期
数据科学项目从一张白纸开始：没有数据，没有代码，只有可以用 ML 解决的业务问题。 第一项任务是概念验证 (POC)，以发现数据是否包含足够的信号以使 ML 模型有效地解决业务问题，首先是从我们的 Snowflake 数据仓库中查询原始数据集。 此阶段是迭代的，数据科学家在此过程中使用 Kubernetes pod 或 Kubeflow Jupyter 笔记本。
我们的 Kubeflow 集群使用 Karpenter 集群自动扩缩器，这使得数据科学家可以轻松地旋转资源，因为他们只需要专注于定义所需的实例类型，而配置工作由一组预定义的 Karpenter 配置器完成。 对于 CPU 和 GPU 实例类型，我们有单独的预置器，根据我们的预置器配置，Amazon EKS 支持的所有实例都属于这两个类别之一。 数据科学家使用节点选择器选择实例类型，而 Karpenter 负责节点生命周期管理。
开发查询后，数据科学家将原始数据提取到 Amazon S3 上的某个位置，然后从 AWS Kubeflow UI 启动 Jupyter 笔记本来探索数据。 目标是创建将用于训练第一个模型的特征集。 这使数据科学家能够确定数据中是否有足够的信号来满足客户的业务需求。
在结果令人满意后，数据科学家将进入开发周期的下一阶段，并将他们的发现转化为强大的管道。 他们将 POC 代码转换为可大规模运行的生产质量代码。 为了通过使用批准的库来确保合规性，使用适当的基础 Docker 映像创建一个容器。 对于我们的数据科学家，我们发现提供标准的 Python、TensorFlow 和 Spark 基础映像可以为大多数（如果不是全部）工作负载提供足够的灵活性。 然后他们可以使用他们组件的 Dockerfile 来进一步定制他们的开发环境。 然后，CI/CD 流程会使用此 Dockerfile 来构建将在生产中使用的组件映像，从而保持开发和生产环境之间的一致性。
我们有一个工具让数据科学家能够在 Kubernetes 上运行的 pod 中启动他们的开发环境。 当这个 pod 运行时，数据科学家可以将 Visual Studio Code IDE 直接附加到 pod 并调试他们的模型代码。 在他们成功运行代码后，他们可以将更改推送到 git，并使用最新更改创建一个新的开发环境。
标准数据科学管道由提取、预处理、训练和评估等阶段组成。 管道中的每个阶段都显示为 Kubeflow 中的一个组件，它由一个 Kubernetes pod 组成，该 pod 运行一个命令，其中一些信息作为参数传入。 这些参数可以是静态值，也可以是对前一个组件输出的引用。 pod 中使用的 Docker 映像是从 CI/CD 过程构建的。 有关此过程的详细信息，请参见下一节讨论的 CI/CD 工作流程。
Kubeflow 上的开发周期。 开发工作流程从左侧的 POC 开始。 完成的模型部署到运行在 Amazon ECS 上的 athenahealth 模型服务平台。
支持自动化工作流程的 CI/CD 流程
作为 CI/CD 流程的一部分，我们使用 Jenkins 并行构建和测试所有 Kubeflow 组件映像。 成功完成后，管道组件模板包含指向图像的引用指针，生成的管道将上传到 Kubeflow。 Jenkins 管道中的参数允许用户在成功构建后启动管道并运行他们的模型训练测试。
或者，为了保持较短的开发周期，数据科学家还可以从本地机器启动管道，修改他们可能正在试验的任何管道参数。
存在工具以确保默认使用来自 CI/CD 构建的引用指针。 如果 repo 中有可部署的工件，则 CI/CD 逻辑将继续将该工件部署到运行在 Amazon ECS 上的 athenahealth 模型服务平台（预测服务） AWS 法门. 在所有这些阶段都过去之后，数据科学家将代码合并到主分支。 然后将管道和可部署的工件推送到生产环境。
CI/CD 部署工作流程。 此图描述了数据科学构建和部署工作流程。 CI/CD 过程由以下因素驱动 詹金斯.
安保行业
在整合我们的数据科学工作流程时，我们能够集中我们的方法来保护培训管道。 在本节中，我们将讨论我们的数据和集群安全方法。
数据安全
数据安全在 athenahealth 至关重要。 因此，我们开发和维护的基础设施完全符合保护这些数据的安全性和完整性的法规和标准。
为确保我们符合数据合规标准，我们根据我们的 athenahealth 企业指南预置我们的 AWS 基础设施。 数据的两个主要存储是用于高度可扩展管道元数据的 Amazon RDS 和用于管道和模型工件的 Amazon S3。 对于 Amazon S3，我们确保对存储桶进行加密、强制实施 HTTPS 终端节点以及存储桶策略和 AWS身份和访问管理 (IAM) 角色在允许访问数据时遵循最小权限原则。 Amazon RDS 数据也是如此：始终启用加密，并且安全组和凭证访问遵循最小权限原则。 这种标准化确保只有授权方可以访问数据，并且这种访问被跟踪。
除了这些措施外，该平台还进行了安全威胁评估以及持续的安全和合规性扫描。
我们还通过包含敏感数据的所有 S3 存储桶的数据生命周期管理来满足数据保留要求。 此策略自动将数据移动到 亚马逊S3冰川 创建 30 天后。 对此的例外情况通过数据检索请求进行管理，并根据具体情况予以批准或拒绝。 这可确保所有工作流都符合数据保留策略。 如果模型表现不佳并且需要重新训练，或者必须根据旧模型数据集的历史迭代评估新模型，这也解决了恢复数据的问题。
为了限制从 Kubeflow on AWS 和 Amazon EKS 内对 Amazon S3 和 Amazon RDS 的访问，我们使用 IRSA（服务账户的 IAM 角色），它为 Kubernetes 内的资源提供基于 IAM 的权限预置。 Kubeflow 中的每个租户都有一个唯一的预创建服务帐户，我们将其绑定到专门为满足租户访问要求而创建的 IAM 角色。 使用每个用户的 Amazon Cognito 用户池组成员身份也限制了用户对租户的访问。 当用户通过集群身份验证时，生成的令牌包含组声明，Kubernetes RBAC 使用此信息来允许或拒绝访问集群中的特定资源。 下一节将更详细地解释此设置。
使用多用户隔离的集群安全性
正如我们在上一节中提到的，数据科学家执行探索性数据分析、运行数据分析和训练 ML 模型。 为了根据项目分配资源、组织数据和管理工作流，AWS 上的 Kubeflow 提供了基于 Kubernetes 命名空间的隔离。 这种隔离适用于与 Kubeflow UI 交互； 但是，它没有提供任何工具来控制使用 Kubectl 对 Kubernetes API 的访问。 这意味着可以在 Kubeflow UI 上控制用户访问，但不能通过 Kubectl 在 Kubernetes API 上控制。
下图中描述的架构通过基于组成员身份统一对 Kubeflow 中项目的访问来解决此问题。 为此，我们利用了 AWS 清单上的 Kubeflow，它与 Amazon Cognito 用户池集成。 此外，我们使用 Kubernetes 基于角色的访问控制 (RBAC) 来控制集群内的授权。 用户权限是根据 Amazon Cognito 组成员资格预置的。 此信息通过 OIDC 客户端生成的令牌传递给集群。 由于内置的 Amazon EKS 功能允许关联 OIDC 身份提供商以对集群进行身份验证，因此简化了此过程。
默认情况下，Amazon EKS 身份验证由 IAM 身份验证器执行，该工具可以使用 IAM 凭证对 EKS 集群进行身份验证。 这种认证方式有其优点； 但是，它不适合我们的用例，因为 athenahealth 使用 Microsoft Azure Active Directory 为整个组织提供身份服务。
Kubernetes 命名空间隔离。 数据科学家可以根据工作需要获得单个或多个组的成员资格。 访问会定期审查并酌情删除。
Azure Active Directory 是一种企业范围的身份服务，是控制用户对 Kubeflow 集群的访问的真实来源。 为此的设置包括创建充当服务主体的 Azure 企业应用程序，并为需要访问集群的各种租户添加组。 Azure 上的此设置通过设置将身份验证责任外包给 Azure 的联合 OIDC 身份提供程序在 Amazon Cognito 中进行镜像。 对 Azure 组的访问由 SailPoint IdentityIQ 控制，它将访问请求发送给项目所有者，以根据需要允许或拒绝。 在 Amazon Cognito 用户池中，创建了两个应用程序客户端：一个用于使用 OIDC 身份提供商为 Kubernetes 集群设置身份验证，另一个用于将 Kubeflow 身份验证保护到 Kubeflow UI。 这些客户端被配置为在与集群进行身份验证时传递组声明，并且这些组声明与 RBAC 一起用于在集群内设置授权。
Kubernetes RBAC 角色绑定在组和集群角色 Kubeflow-edit 之间设置，该角色是在集群中安装 Kubeflow 时创建的。 此角色绑定确保通过 OIDC 登录后与集群交互的任何用户都可以访问他们在其组声明中定义的具有权限的命名空间。 尽管这适用于使用 Kubectl 与集群交互的用户，但 Kubeflow UI 目前不提供基于组成员身份的用户访问权限，因为它不使用 RBAC。 相反，它使用 Istio 授权策略资源来控制用户的访问。 为了克服这一挑战，我们开发了一个自定义控制器，它通过轮询 Amazon Cognito 组来同步用户，并为每个用户而不是按组添加或删除相应的角色绑定。 此设置使用户在与 Kubeflow UI 和 Kubectl 交互时拥有相同级别的权限。
运营效率
在本节中，我们将讨论如何利用可用的开源工具和 AWS 工具来管理和调试我们的工作流程，以及最大限度地减少升级 Kubeflow 对运营的影响。
记录和监控
对于日志记录，我们利用 FluentD 将我们所有的容器日志推送到 亚马逊开放搜索服务 和 Prometheus 的系统指标。 然后，我们使用 Kibana 和 Grafana UI 来搜索和过滤日志和指标。 下图描述了我们如何设置它。
Kubeflow 日志记录。 我们同时使用 Grafana UI 和 Kibana 来查看和筛选日志
以下屏幕截图是来自我们管道的 Kibana UI 视图。
示例 Kibana UI 视图。 Kibana 允许自定义视图。
安全的 Kubeflow 集群升级
当我们将用户加入 AWS 上的 Kubeflow 时，我们保持了可靠且一致的用户体验，同时允许 MLOps 团队在发布和集成新功能时保持敏捷。 从表面上看，Kustomize 对我们来说似乎是模块化的，可以在不影响其他组件的情况下一次运行和升级一个组件，从而使我们能够在对用户造成最小干扰的情况下添加新功能。 然而，在实践中，最好的方法是简单地启动一个新的 Kubernetes 集群，而不是对现有集群应用组件级升级。 我们发现了两个用例，在这些用例中创建全新的集群更有意义：
- 升级到 AWS 提供就地集群升级的 Kubernetes 版本。 但是，很难测试每个 Kubeflow 和 Kubernetes 资源是否按预期工作，并且清单是否保持向后兼容性。
- 将 Kubeflow 升级到更新的版本，其中添加或修改了多个功能，并且在现有 Kubernetes 集群上执行就地升级几乎总是不是一个有前途的想法。
在解决这个问题时，我们制定了一种策略，使我们能够在不影响任何现有工作负载的情况下安全地更换集群。 为此，我们必须满足以下标准：
- 分离 Kubeflow 存储和计算资源，以便在取消配置旧集群时保留管道元数据、管道工件和用户数据
- 与 AWS 清单上的 Kubeflow 集成，以便在发生 Kubeflow 版本升级时，只需进行最少的更改
- 如果集群升级后出现问题，可以轻松回滚
- 有一个简单的界面来将候选集群升级到生产环境
下图说明了此体系结构。
安全的 Kubeflow 集群升级。 一旦 Kubeflow Candidate 测试成功，它就会通过更新到 Route 53 升级为 Kubeflow Prod。
AWS 清单上的 Kubeflow 预打包了 Amazon RDS 和 Amazon S3 集成。 通过这些托管服务充当通用数据存储，我们可以设置蓝绿部署策略。 为此，我们确保管道元数据保存在独立于 EKS 集群的 Amazon RDS 中，并且管道日志和工件保存在 Amazon S3 中。 除了管道元数据和工件之外，我们还设置了 FluentD 以将 pod 日志路由到 Amazon OpenSearch Service。
这确保了存储层与计算层完全分离，从而能够在全新的 EKS 集群上测试 Kubeflow 版本更新期间的更改。 在所有测试都成功后，我们可以简单地更改 亚马逊路线53 托管 Kubeflow 的候选集群的 DNS 记录。 此外，我们将旧集群作为备份运行几天，以防我们需要回滚。
AWS 上的 Amazon EKS 和 Kubeflow 对我们的 ML 管道的好处
Amazon EKS 和 Kubeflow on AWS 包将我们的开发工作流程转变为强烈鼓励可重复模型训练的模式。 这些工具使我们能够拥有具有完全定义的租户的完全定义的集群并运行完全定义的代码。
构建这个平台的很多胜利都不是量化的，更多的是与平台开发人员和用户的工作流程如何改进有关。 例如，MinIO 被直接访问 Amazon S3 所取代，这使我们更接近我们原来的工作流程，并减少了我们必须维护的服务数量。 我们还能够利用 Amazon RDS 作为 Kubeflow 的后端，这使得集群之间的迁移更容易，并让我们能够每晚备份我们的管道。
我们还发现 Kubeflow 与 AWS 托管服务集成的改进是有益的。 例如，通过在 Kubeflow on AWS 清单中预配置 Amazon RDS、Amazon S3 和 Amazon Cognito，我们可以节省时间和精力来更新到更新的 Kubeflow 发行版。 当我们过去手动修改官方 Kubeflow 清单时，从设计到测试更新到新版本需要数周时间。
切换到 Amazon EKS 让我们有机会在 Kustomize（现在是 Kubectl 的一部分）和 Terraform 中定义我们的集群。 事实证明，对于平台工作，Kubernetes 和 Terraform 在投入足够的时间学习后非常容易使用。 经过多次迭代，我们可用的工具使执行标准平台操作变得非常容易，例如升级组件或更换整个开发集群。 与原始运行作业相比 亚马逊弹性计算云 (Amazon EC2) 实例，很难比较拥有明确定义的 Pod 以及内置有保证的资源清理和重试机制的巨大差异。
Kubernetes 提供了很好的安全标准，而我们只是触及了多用户隔离允许我们做的事情的皮毛。 我们将多用户隔离视为一种模式，当培训平台产生生产级数据时，未来会有更多回报，并且我们会从团队外部引入开发人员。
同时，Kubeflow 允许我们进行可重复的模型训练。 即使使用相同的数据，也没有任何训练会产生相同的模型，但我们有次优。 使用 Kubeflow，我们确切地知道用于训练模型的代码和数据。 由于我们管道中的每个步骤都以程序化的方式清晰地定义，因此入职培训有了很大的改进。 当新的数据科学家有修复错误的任务时，他们需要更少的手动操作，因为在阶段之间如何使用代码输出有一个清晰的结构。
与在单个 EC2 实例上运行相比，使用 Kubeflow 还可以提高性能。 通常在模型训练中，数据科学家需要不同的工具和优化来进行预处理和训练。 例如，预处理通常使用分布式数据处理工具（如 Spark）运行，而训练通常使用 GPU 实例运行。 使用 Kubeflow 管道，他们可以为管道中的不同阶段指定不同的实例类型。 这允许他们在一个阶段使用强大的 GPU 实例，并在另一个阶段使用一组较小的机器进行分布式处理。 此外，由于 Kubeflow 管道描述了阶段之间的依赖关系，因此管道可以并行运行阶段。
最后，因为我们创建了将租户添加到集群的流程，所以现在有一种更正式的方法可以将团队注册到集群上的租户。 因为我们使用 Kubecost 来跟踪 EKS 集群中的成本，它允许我们将成本归因于单个项目，而不是将成本归因于账户级别，其中包括所有数据科学项目。 Kubecost 提供每个命名空间花费的资金报告，该报告与负责运行管道的租户或团队紧密耦合。
尽管有所有好处，但我们会警告说，只有在用户完全支持的情况下才进行这种迁移。 投入时间的用户可以从使用 Amazon EKS 和 Kubernetes 中获得很多好处，但学习曲线很长。
结论
通过在我们的端到端 ML 基础设施中实施 Kubeflow on AWS 管道，我们能够整合和标准化我们的数据科学工作流程，同时保留我们的基本工具（例如 CI/CD 和模型服务）。 我们的数据科学家现在可以基于此工作流程在项目之间移动，而无需学习如何维护完全不同的工具集。 对于我们的一些模型，我们也对新工作流程的速度（快五倍）感到惊喜，这允许更多的训练迭代，从而产生具有更好预测的模型。
我们还建立了坚实的基础来增强我们的 MLOps 能力并扩展我们项目的数量和规模。 例如，随着我们在模型沿袭和跟踪方面加强治理态势，我们将关注点从超过 15 个工作流减少到只有一个。 当 Log4shell 漏洞在 2021 年末曝光时，我们能够专注于单个工作流并根据需要快速修复（执行 Amazon Elastic Container注册 (Amazon ECR) 扫描、升级 Amazon OpenSearch 服务、更新我们的工具等），对数据科学家正在进行的工作的影响最小。 随着 AWS 和 Kubeflow 增强功能的推出，我们可以根据需要合并它们。
这将我们带到了 Kubeflow 采用 AWS 的一个重要且低调的方面。 这一旅程的关键成果之一是能够为我们的数据科学家无缝地推出 Kubeflow 的升级和增强功能。 尽管我们之前讨论了我们的方法，但我们也依赖于 AWS 提供的 Kubeflow 清单。 在 2019 版本发布之前，我们在 1.0.0 年开始了我们的 Kubeflow 之旅作为概念验证。 （我们目前使用的是 1.4.1，正在评估 1.5。AWS 已经在开发 1.6 版本。）在这三年间，至少有六个版本具有大量内容。 AWS 的 Kubeflow 团队通过他们严谨的方法来集成和验证这些升级并以可预测、可靠的时间表发布清单，这对于使 athenahealth MLOps 团队能够规划我们的开发路线图以及因此我们的资源分配和关注领域至关重要，以更大的信心走向未来。
你可以按照 AWS 实验室 GitHub 存储库 跟踪所有 AWS 对 Kubeflow 的贡献。 您还可以在 Kubeflow #AWS Slack 频道; 您的反馈有助于 AWS 优先考虑为 Kubeflow 项目做出贡献的下一个功能。
关于作者
坎瓦尔吉特·库尔米 是 Amazon Web Services 的高级解决方案架构师。 他与 AWS 客户合作，提供指导和技术援助，帮助他们在使用 AWS 时提高解决方案的价值。 Kanwaljit 专门帮助客户使用容器化和机器学习应用程序。
泰勒卡尔巴赫 是 athenahealth 技术人员的主要成员。 Tyler 在医疗保健领域的分析、数据科学、神经网络和机器学习应用程序开发方面拥有大约 7 年的经验。 他为目前服务于生产流量的多个机器学习解决方案做出了贡献。 目前，作为 athenahealth 工程组织的首席数据科学家，Tyler 一直是该团队的一员，该团队从一开始就为 athenahealth 构建了新的机器学习培训平台。
维克多·克雷洛夫 是 athenahealth 技术人员的主要成员。 Victor 是一名工程师和 Scrum 大师，帮助数据科学家构建安全的快速机器学习管道。 在 athenahealth，他从事界面、临床订购、处方、调度、分析以及现在的机器学习方面的工作。 他看重编写清晰且经过良好单元测试的代码，但对单行代码有一种不健康的痴迷。 在业余时间，他喜欢边遛狗边听播客。
萨桑克·维穆里 是 athenahealth 技术人员的主要成员。 他在开发跨医疗保健、保险和生物信息学等领域的数据驱动解决方案方面拥有丰富的经验。 Sasank 目前致力于在 AWS 和 Kubernetes 上设计和开发机器学习训练和推理平台，帮助大规模训练和部署 ML 解决方案。
阿努图姆库尔 是 athenahealth 的建筑师。 Anu 在构建机器学习、云操作、大数据、实时分布式数据管道、广告技术、数据分析、社交媒体分析方面的各种软件产品方面拥有超过 XNUMX 年的架构、设计和开发经验。 Anu 目前在 athenahealth 的机器学习平台和数据管道团队的产品工程组织中担任架构师。
曾威廉 是 athenahealth 的高级工程经理。 他在医疗保健 IT、大数据分布式计算、智能光网络、实时视频编辑系统、企业软件和团体医疗保健承保方面拥有超过 20 年的工程领导经验。 William 目前在 athenahealth 领导两个出色的团队，即产品工程组织的机器学习运营和 DevOps 工程团队。
