亚马逊AWS官方博客

基于 Uniprot 开放数据集使用 Cytoscape.js 和 Amazon Neptune 图形数据库快速搭建无服务化蛋白质数据分析平台

1. 方案介绍

1.1 方案背景

当前,大部分蛋白质研究(蛋白质的生物功能,其医药和工业应用等)都局限在一小部分蛋白上,这部分被称为充分研究的已知蛋白;与之相应,还有大量蛋白(估计占全部已获得序列蛋白的 60%~90%)罕被研究。2022 年春夏之际,《自然》杂志旗下《自然*生物技术》、《自然*方法》同时发表两篇评论文章,呼吁启动”Understudied Proteins Initiative”[1][2]。该计划旨在通过将未知蛋白与已知蛋白关联,促进人们对整个蛋白世界的深入研究。

上海纽约大学的方刚受邀参与了 2022 年 2 月美国国家科学基金会针对未充分研究蛋白计划的相关立项研讨会[3],并建议将梳理同源蛋白数据库作为计划重要内容,并写入报告[3]。蛋白的同源关系是关联未知与已知蛋白的重要手段,人们已经开发的对蛋白计算的全部算法中,超过 2/3 需要依赖蛋白同源性。在过去 20 年间,已经有近百种识别蛋白同源性的算法和数据库被开发出来,但这些算法的输出,即数据库里的内容,存在严重的不一致的问题;例如,从若干主流同源蛋白数据库检索出的同源性不一致的蛋白,占数据库全部蛋白的 50%以上。这些问题在 2016 年被《自然*方法》杂志一篇文章呼吁重视,并提出改进路线图[4],但数年过去收效甚微。方刚团队近期提出了一个新的衡量蛋白间相似度的尺度。基于这一尺度,他们构建了一个蛋白质网络,该团队利用这一网络解释了易于导致不同算法得出不一致同源蛋白的原因,并提出进一步分析这些蛋白的技术路线(文章在审稿中);巧合的是,这些蛋白几乎包括了全部的未充分研究蛋白。

1.2 方案业务

基于此,方刚团队首先希望将其构建的蛋白质相似度的方案平台化,并借助亚马逊云科技的上托管的蛋白质开放数据集(Uniprot),为参与”未充分研究蛋白计划”的其他科研团队提供一个 SaaS 化的工作平台。目前这些蛋白质网络(ortholog group, OG)是使用 OG 文件描述了蛋白质信息、蛋白质的关系等;每个 OG 是一个高度相似的蛋白质的集合,可以使用其中一个蛋白质代表这个 OG。不同的 OG 组成了一个网络(大约 1W 个以内),通过 OG 的关系网络,我们可以直观判断未充分研究蛋白与已知蛋白的关联情况,如:未知蛋白与周边已知蛋白在蛋白质结构、重要活性位点的异同;未知蛋白在不同物种间的分布情况,及结合其他基因组数据所提示的功能信息,如表达量高低等。这些关联情况可以为下一步计算分析提供直接的线索。

基于此需求,我们实现了平台的原型,并帮助搭建了上海纽约大学开放的蛋白质分析平台:https://db.protdc.bio 以推进蛋白质分析平台的实际生产落地应用。

蛋白质数据分析平台的工作流程包括

  1. 使用 Uniprot 开放数据集初始化图数据库。
  2. 使用 OG 网络结构信息初始化 OG 网络结构数据库。
  3. 使用 Cytoscape.JS Web 组件实现 Web 端的可视化 OG 网络。
  4. 实现单个到多个 OG 网络信息查询、筛选、关联关系分析等,并在 UI 进行可视化操作。
  5. 通过选中单个或多个有意义的 OG 的蛋白质节点,查询 Uniprot 数据集以获得更加丰富的 Annotation 信息。同时,由于 Uniprot ID 的通用性,方便了前端开发者将其他生物数据库的内容打印到平台上,进一步丰富平台内容。
  6. 平台预留了可扩展空间,允许开发者安装第三方软件,存储少量的第三方软件所需的辅助数据及软件运算结果。

            1.3 技术架构介绍

            技术挑战及解决方案:

            1. 当前蛋白质结构复杂、开源数据较多,需要高性能的图形数据库支撑海量蛋白质的使用

              方案:使用 Amazon Neptune 这一亚马逊云科技托管的图形数据库,最高每秒可实现 100000 次查询,并实现了数据的高可用性;并且利用 Amazon 公开数据集 Uniprot 和 S3 的集成特性,简单方便加载和管理公开数据集。

            1. 平台前期使用率低应用维护成本高

              方案:从计算、到数据库存储,提供完全托管的 Serverless 解决方案,只需为使用的资源付费,即使是要求最苛刻和不可预测的应用程序也可以经济高效地运行。同时支持指定最小和最大容量限制,进而管理成本。

            1. 图形化操作复杂,以往主要采用 Jupyter 集成的插件,多个用户难以共用平台

              解决:使用 Cytoscape.JS 开源组建结合 Amazon API Gateway 和 Lambda 函数实现 Web 托管平台,最大化提升平台的易用特性。用户无需本地化安装任何组建,也无需开启其他计算资源即可使用蛋白质平台分析平台。

            云上无服务化架构设计:

            方案特点:

            1. 无服务化

              方案可以使用无服务器化的方案进行部署,计算资源使用 Amazon Lambda 服务,存储资源使用 MySQL 和 Neptune 数据库的无服务器化的方案。

            1. 自动化部署

              方案使用 CDK 脚本进行自动化部署,只需简单操作即可完成私有化平台的部署工作。

            1. 易扩展

              方案代码使用开源的方式提供,方便基于此方案的基础上定制化开发和优化。

            1. Web 可视化

              Cytoscape.JS 是一个用于创建交互式网络图的 JavaScript 图形库。它专门用于可视化和分析图形数据,是 Web 应用程序中构建网络图形用户界面的有力工具。Cytoscape.js 提供了丰富的文档、示例和社区支持,使开发者能够轻松构建各种类型的网络图形应用程序。它是开源的,适用于 Web 开发,并与众多前端和后端技术集成。

            1. 海量开放数据集

              方案采用 Uniprot 开放数据集,并和图形数据高度集成,简单易用。

            2. 部署前

            1. 亚马逊云科技的账号权限
            1. 可以进行部署的操作系统(本文使用 Amazon Linux2023 操作系统)

            2.1 准备部署所需要的资源

            在方案部署前,我们需要一些准备工作来帮助部署阶段的顺利进行,准备工作的核心分为以下几个部分:

            所需要的资源信息如下:

            • 亚马逊云科技的账号
              • 密钥:有用户的访问凭证密钥(请参考《访问密钥》创建和管理自己的访问密钥)
              • 区域:本文主要以海外 AWS 账号为主,国内账号部署需要修改 CDK 部署脚本或者手动部署资源后执行第 4 章节的数据初始化步骤
            • EC2 部署机器(部署环境可以在本地电脑或者云端进行,但为了环境的一致性,本文的操作需要在亚马逊云环境上进行。具体操作请参考《创建 EC2 资源和启动实例》)
              • 实例类型:t3.small
              • 镜像:Amazon Linux 2023
              • 存储大小:50GB
              • 网络:公有子网,公有 IP
              • 密钥:提前准备密钥对或者在创建 EC2 的时候创建密钥对(请参考《创建密钥对》)
            • SSL 证书(可选:是否选择根据网站是否需要启用 HTTPS,推荐使用 HTTPS 协议)
              • 可以参考:《请求公有证书》获取对应域名的公有证书,建议采用 DNS 认证的方式,预计 30 分钟内即可通过 DNS 域名验证,最终可以获取证书的 ARN 资源信息。

            2.2 初始化环境

            该步骤主要针对部署机器的环境进行初始化,因为主要采用 CDK 的方式进行部署,所以主要的初始化内容为安装 AWS CDK v2 的环境。

            2.2.1 连接到 EC2 部署服务器

            使用 SSH 连接到您的 Amazon Linux 2023 操作系统,参考《连接到您的 Linux 实例

            2.2.2 更新 yum 环境

            sudo yum update -y
            sudo su

            2.2.3 安装依赖组件 NPM and Node

            sudo yum install npm -y

            安装 CDK

            npm i -g aws-cdk

            安装依赖的 pip 组件

            sudo yum -y install python-pip

            检查版本信息

            Check requires Node.js ≥ 16 and NPM ≥ 8.3.0

            npm -v && node -v
            cdk --version
            pip --version

            2.2.4 配置当前机器的 CLI 环境

            根据 2.1 中准备的账号密钥,配置当前 EC2 的 CLI 环境

            aws configure

            3. 部署

            3.1 下载部署代码

            yum install git -y
            git clone https://github.com/cloudswb/proteindc-analysis-platform.git

            3.2 初始化代码 CDK 环境

            使用 pip 安装 requirements.txt 中的依赖包

            cd proteindc-analysis-platform/proteindc-website-deploy/
            
            pip3 install -r requirements.txt

            修改和配置 config.py 文件

            config.py 中包含了所有在部署阶段需要配置的参数信息,核心的参数信息使用了“必须修改”字样。其他参数您可以根据参数的描述信息判断是否需要修改。

            vim deploy/config.py

            标注【必须修改】的信息是必须根据自己的情况修改,其他信息可以视情况修改。需要注意的是 WEB_CERT_ARN 参数来自 2.1 章节的证书准备内容,您准备好证书后可以在 Amazon Certificate Manager 服务中获取相应证书的 ARN 信息。

            ACCT_ID = '' #部署的账号 ID【必须修改】
            ACCT_REGION = 'us-east-1' #部署到的区域代码,默认为美东 1
            
            VPC_NAME = 'proteindc-vpc' #新建 VPC 的名称
            VPC_CIDR = '20.0.0.0/16' #新建 VPC 的 IP 网段
            
            
            WEB_BUCKET_NAME = "proteinxxx.xxx.com" #存储前端网页代码的存储桶名称【必须修改】
            WEB_DOMAIN_NAME = "proteinxx.xxx.com" #部署的自有域名【必须修改】
            WEB_ROOT_FILE = "index.html" #网站默认页面
            WEB_UPLOAD_FOLDER = "../web" #网站在 git 代码中的位置
            WEB_CERT_ARN = "" #网站使用的 SSL 证书 ARN 信息,默认为空代表不使用 HTTPS 访问【如果需要使用 HTTPS 则必须修改】
            
            MYSQL_DB_IDENTIFIER = 'nyu-mysql' #用于存储网络结构的 RDS MySQL 数据库的实例名称
            MYSQL_DEFAULT_DB_NAME = 'proteinog' #RDS 数据库实例的默认数据库
            MYSQL_PASSWORD = '4z(hFH-({u2Y*g:$BL{!D$Rp%H_!' #RDS 数据库实例的密码
            MYSQL_USER_NAME = 'awsuser' #RDS 数据库的用户名
            
            IS_NEPTUNE_SERVERLESS = True #是否部署无服务化的 Neptune 数据库
            NEPTUNE_DB_IDENTIFIER = 'proteindc-neptune' #图形数据库的实例名称
            NEPTUNE_DB_INSTANCE_CLASS = 'db.r6g.4xlarge' #图数据库的实例类型(如果 IS_NEPTUNE_SERVERLESS 为 True,则不需要该值)
            
            NEPTUNE_NOTEBOOK_INSTANCE_CLASS = 'ml.t3.large' #Notebook 实例的类型

            3.3 初始化 CDK 环境

            1. 初始化当前账号的 CDK 环境:

              Bootstrapping 是指在将 AWS CDK 应用程序部署到 AWS 环境中 AWS CDK 之前为其配置资源的过程。

              cd ~/proteindc-analysis-platform/proteindc-website-deploy/
              
              # 替换<Account ID> 为 12 位的账号 ID,<Region ID>为区域代码,如:us-east-1
              sudo cdk bootstrap aws://<account ID>/<region ID>
              
              # 例如 sudo cdk bootstrap aws://112233445566/us-east-1

              bootstrap 安装结束后,可以在 CloudFormation 中查看到堆栈创建的状态为‘CREATE_COMPLETE’,这个过程的时间可能会需要 5 分钟左右。

            1. 使用 CDK Synth 初始化 CloudFormation 模版

              cdk synth 命令的主要作用是将 CDK 应用程序的代码转换为 CloudFormation 模板。这个模板可以用于创建、更新或删除与您的 CDK 应用程序相关联的 AWS 资源。cdk synth 不会执行实际的部署操作,而只是生成 CloudFormation 模板文件,以便您可以在必要时手动或通过其他方式执行部署。

              sudo cdk synth --all

            3.4 使用 cdk deploy 部署

            在整个部署过程中一共有 8 个 CloudFormation 堆栈将需要完成:

            顺序 堆栈名称
            1 CDKToolkit CDK 初始化环境
            2 ProteinDCVpcDeployStack 创建新的 VPC 用于环境部署
            3 ProteinDCNeptuneServerlessDeployStack 创建 Neptune 数据库,用于存储 Uniprot 数据
            4 ProteinDCNeptuneNotebookDeployStack 创建 Jupyter Notebook,用于初始化方案
            5 ProteinDCRDSDeployStack 创建 MySQL 数据库,用于存储网络结构
            6 ProteinDCLayerLambdaAGWDeployStack 创建方案后端 Lambda 函数以及网关接口
            7 ProteinDCWebsiteS3DeployStack 创建方案前端 S3 用于存储网页静态资源
            8 ProteinDCWebsiteCloudFrontDeployStack 创建方案网站 CDN 用于浏览器网页访问

            cdk deploy 命令的主要作用是将 CDK 应用程序中定义的堆栈(Stacks)部署到 AWS 帐户中。堆栈是 AWS 资源的集合,可以包括虚拟机实例、数据库、存储桶等 AWS 服务。这个部署过程大概需要 30 分钟左右。

            sudo cdk deploy --all
            
            # OR: 如果不需每个部署阶段进行人工确认,则执行下面代码进行自动确认
            
            sudo cdk deploy --all --require-approval never

            3.5 监控部署状态

            在命令行中,可以查看部署的阶段和进行确认是否进行部署:

            在 CloudFormation 中进行查看部署状态,当所有的 7 个部署的 Stack 分别完成后,整个部署阶段将完成。

            4. 初始化数据

            部署完成后,我们可以根据部署脚本中准备的测试数据对环境进行数据初始化,您也可以根据需要修改部署的脚本使用自己的数据初始化数据。

            整个数据初始化包含的内容有 2 个:

            1. OG 网络信息
            1. Uniprot 蛋白质信息

            所有的初始化脚步都存放在 SageMaker Notebook 的 Jupyter 环境中。

            4.1 查看 Jupyter 数据初始化环境

            在 CloudFormation 中点开‘ProteinDCNeptuneServerlessDeployStack’堆栈,在‘输出’标签页,在‘neptuneNotebookInstanceName’属性中输出了新创建的 Notebook 的名称:‘proteindc-neptuneNeptuneNotebookWorkbench’。

            打开 Amazon SageMaker 服务定位到 Notebook Instances,我们可以使用‘Open JupyterLab’打开 Jupyter 环境:

            在 ProteinDC/data_init/ 文件夹中,包含 2 个初始化脚本:

            • Load_OG_network_to_RDS.ipynb
              • 用于使用网络结构数据初始化 MySQL 数据库
            • Load_Uniprot_data_to_neptune.ipynb
              • 用于使用 Uniprot 数据初始化 Neptune 数据库

            接下来,我们将详细介绍如何利用这两个脚本进行数据初始化。

            4.2 使用 OG 信息初始化 MySQL 数据库

            打开 1.Load_OG_network_to_RDS.ipynb 初始化 MySQL

            1. 设置初始化的数据源

            OG 数据的来源为位于“/data_init/og_data/source/sample_og_1.csv”的示例数据,该数据为方刚团队整理的测试 OG 网络信息,您也可以根据自己的需要修改该数据内容,该数据的具体格式为:

            <From OG Protein ID>,<To OG Protein ID>,<Edge Weight Value>

            例如:

            A0A2P9HAN0,51534,0.0464063
            H6RJT1,E6SH66,0.125
            D7B069,37787,0.0416666

            您可以将自己的网络信息替换该文件,执行初始化的脚本后会自动加载‘og_data/source’文件夹中的所有 csv 文件进行初始化。

            2. 配置目标 MySQL 数据库的端点信息

            首先我们需要找到并设置 MySQL 的数据库服务器地址,在‘ProteinDCRDSDeployStack’堆栈中找到此前自动创建的 RDS 数据库的端点信息:

            在 1.Load_OG_network_to_RDS.ipynb 文件中,我们根据‘rdsClusterEndpoint’参数中的端点值替换‘host’属性。

            其他属性如 port、user、passwd、database 可以在此前配置的‘deploy/config.py’中找到。

            3. 执行初始化脚本

            启动自动顺序执行初始化脚本:

            查看最后一个脚本的输出结果,我们可以验证网络结构是否初始化正确:

            4.3 使用 Uniprot 信息初始化图数据库(Neptune)

            Neptune 用于存储蛋白质信息,本章节主要使用 Uniprot 公开数据集初始化 Neptune 数据库,具体操作步骤如下:

            1. 设置图数据库的目标连接端点信息

            打开 CloudFormation 信息,找到 ‘ProteinDCNeptuneServerlessDeployStack’ 堆栈的’输出’信息,记录如下三个值描述了创建完成的 Neptune 数据库的信息。

            打开 Notebook 中的第二个初始化代码:2.Load_Uniprot_data_to_neptune.ipynb,定位到初始化数据库参数段落。根据如下参数对应表格,在初始化脚本中配置初始化参数信息。

            CloudFormation 部署输出参数 配置参数 介绍
            neptuneClusterEndpoint neptune_host 数据库端点地址
            neptuneClusterPort neptune_port 数据库端口
            neptuneLoadS3Role iamRoleArn 数据库从 S3 中加载数据的角色 ARN 信息

            设置完成后的参数应如下图示:

            2. 配置初始化的数据源:RDF 数据文件位置

            Neptune 数据库的数据源来自 Uniprot 数据库,该数据集来自 Amazon 的开放数据集,具体位置于巴黎区域的 S3 存储桶 s3://aws-open-data-uniprot-rdf/ 中。如果您的方案部署的区域不在巴黎区域(如本文部署在 us-east-1 中),代码将会自动将您指定的用于初始化 Neptune 的 RDF 文件先复制到您部署区域的 SageMaker 对应的 S3 存储桶中,然后从本区域的 S3 存储桶中读取文件。

            那么,如何浏览公开数据集的所有文件找到需要加载的 RDF 文件呢?

            1. 您可以浏览 Uniprot 开放数据集的官方网站
            1. 您也可以通过 S3 的 ls 命令查看s3://aws-open-data-uniprot-rdf/ 存储桶中的所有文件信息,如:
              aws s3 ls s3://aws-open-data-uniprot-rdf/2023/

            确定需要初始化的蛋白质的 uniprot 的 RDF 文件后,您需要在 Notebook 的脚本‘2.Load_Uniprot_data_to_neptune.ipynb’中定位到“设置需要加载的文件”章节,默认示例给出了三个加载的 RDF 文件,您可以根据需要修改加载的文件的位置信息:

            "2023-03/supporting/taxonomy.rdf.gz",
            "2023-03/supporting/go.rdf.gz",
            "2023-03/uniprot/uniprotkb_reviewed_eukaryota_opisthokonta_metazoa_33208_0.rdf.gz"

            注意事项:

            • 因为数据加载内容较多,在数据加载阶段推荐使用高配置的数据库实例如 r6g.4xLarge 及以上配置,或者使用 Serverless 的 Neptune 在设定的性能范围内动态扩容(默认在 us-east-1 区域中部署,会自动使用 Neptune Serverless 分配 1-40 个 NCU)。
            • 因为开放数据默认在巴黎区域的存储桶中,如果您的部署的环境不在巴黎,则会自动将需要加载的开放数据先保存到当前区域的 SageMaker 存储桶中再进行加载到 Neptune 数据库。
            • 截止发稿时间,巴黎区域 Neptune 数据库暂时不支持 Serverless 的 Neptune 数据库,所以您暂时不可以在巴黎区域使用无服务化的 Neptune 数据库,请您注意在部署阶段 Config.py 文件的配置信息。

            3. 运行 Jupyter 代码环境,执行数据库初始化

            注意,这里我们使用的 kernel 需要为 Python3

            4. 查看初始化状态和结果

            执行脚本文件中的“监控数据加载进度”和“测试”段落的测试脚本可以判断是否加载完成和加载成功。

            5. 网站访问

            5.1 域名解析

            默认部署完成后,CDK 会创建 CloudFront 的 Distribution 域名,当然我们推荐使用自定义域名将您的域名解析到 CloudFront 中。

            如下图所示,在‘ProteinDCWebsiteCloudFrontDeployStack’堆栈的输出信息中,可以获得 2 种域名信息:

            1. CloudFront 分配的域名(见 1:WebsiteCloudfrontDistributionDomainName 属性对应的值)
            1. 自定义域名(见 2: WebsiteDomainName 属性对应的值)

            注意:只有自定义域名可以使用 SSL 证书

            如果使用自定义域名,我们需要解析域名后访问平台网址,有 2 种方式可以进行域名的解析:

            1. 使用 CNAME 的方式进行解析域名
              1. 适合域名并非在 AWS 平台进行托管的情况,使用 CNAME 的方式解析到对应的 Distribution 地址。
            1. 使用 Alias 的方式进行解析域名
              1. 适合域名在 AWS 平台进行托管的情况,可以直接将域名解析到 CloudFront 服务。

            下面,我们以 Route53 为例,演示如何配置域名解析的 2 种解析方式:

            方式 1:使用 CNAME 方式进行解析

            方式 2:使用 Alias 的方式进行解析

            5.2 访问平台

            6. 功能介绍

            6.1 根据 Protein ID 检索网络信息

            在 Protein ID 输出框中可以输入 1 个或者多个 Protein ID 信息,将会把 Protein ID 对应的 OG 网络信息呈现在页面。

            6.2 设置网络深度

            可以根据需要查询的网络层级自定义深度信息,默认为 3 级,即会将网络层级在三级那的所有节点呈现在网络结构中。

            6.3 查看选中 Protein 的 Annotation 信息

            通过选中 OG 节点,并使用 Retrive annotation Info 获取相关的 Annotation 信息:

            7 总结

            通过本方案,我们协同纽约大学方刚老师团队快速搭建了一个蛋白质数据分析平台的原型,并实现了该平台的高度可扩展性和易复制性,通过该方案的输出数据,可以更加方便的和其他蛋白质计算工具和平台相集成,从而加速蛋白质的分析过程。

            整个方案的代码以开源的形式发布在了 Github 中(https://github.com/cloudswb/proteindc-analysis-platform.git),如果您对方案有任何疑问和问题,欢迎在 Github 中提出,也欢迎共同贡献相关的代码修复 bug 或者增加功能。

            引用:

            1. Kustatscher, G., Collins, T., Gingras, A., Guo, T., Hermjakob, H., Ideker, T., Lilley, K. S., Lundberg, E., Marcotte, E. M., Ralser, M., & Rappsilber, J. (2022). An open invitation to the Understudied Proteins Initiative. Nature Biotechnology, 40(6), 815-817. https://doi.org/10.1038/s41587-022-01316-z
            1. Kustatscher, G., Collins, T., Gingras, A., Guo, T., Hermjakob, H., Ideker, T., Lilley, K. S., Lundberg, E., Marcotte, E. M., Ralser, M., & Rappsilber, J. (2022). Understudied proteins: Opportunities and challenges for functional proteomics. Nature Methods, 19(7), 774-779. https://doi.org/10.1038/s41592-022-01454-x
            1. Arighi, C., Babor, J., Bateman, A., Blaby, I., Blaby-Haas, C., Bridge, A. J., Burley, S. K., Cleveland, S., Colwell, L. J., Conesa, A., Dallago, C., Danchin, A., Deutschbauer, A., Dias, R., Ding, Y., Fang, G., Friedberg, I., Gerlt, J., Goldford, J., . . . Xu, J. (2022). A roadmap for the functional annotation of protein families: A community perspective. Database: The Journal of Biological Databases and Curation, 2022. https://doi.org/10.1093/database/baac062
            1. Altenhoff, A. M., Boeckmann, B., Capella-Gutierrez, S., Dalquen, D. A., DeLuca, T., Forslund, K., Huerta-Cepas, J., Linard, B., Pereira, C., Pryszcz, L. P., Schreiber, F., Szklarczyk, D., Train, M., Bork, P., Lecompte, O., Xenarios, I., Sjölander, K., Jensen, L. J., Martin, M. J., . . . Dessimoz, C. (2016). Standardized benchmarking in the quest for orthologs. Nature Methods, 13(5), 425-430. https://doi.org/10.1038/nmeth.3830

            本篇作者

            张凯

            亚马逊云科技解决方案架构师,主要负责基于 AWS 云计算的解决方案架构设计和的方案咨询,关注教育和医疗行业,10 多年的软件研发、管理和解决方案架构设计经验。

            方刚

            上海纽约大学生物学助理教授,纽约大学生物系助理教授。近期研究重点是从演化角度探索系统生物学,并研究大语言模型在生物学研究中的潜在应用。