论文阅读：科学大数据的云原生存储库

Meteorology/Paper, Meteorology/Data
目录

Cloud-Native Repositories for Big Scientific Data

R. P. Abernathey et al., “Cloud-Native Repositories for Big Scientific Data,” in Computing in Science & Engineering, vol. 23, no. 2, pp. 26-35, 1 March-April 2021, doi: 10.1109/MCSE.2021.3059437.

一篇介绍云原生数据存储的文章，发表于 Computing in Science & Engineering。

正文

摘要

传统上，科学数据是通过从数据服务器下载到本地计算机来分发的。 随着科学数据集向 PB 级发展，这种工作方式受到了限制。

本文定义的“云原生数据存储库”相对于传统数据存储库具有多个优势：

  • 性能
  • 可靠性
  • 成本效益
  • 协作
  • 可再现性
  • 创造力
  • 下游影响
  • 访问和包含 (access & inclusion)

最佳实践

这些目标激发了一组针对云原生数据存储库的最佳实践：

  • 分析就绪数据 (analysis-ready data)，云优化格式 (cloud-optimized formats)。统称 ARCO
  • 与数据邻近计算 (data-proximate computing) 的松散耦合

Pangeo 项目通过使用开源科学 Python 工具开发了这些原则的原型实现。 通过提供 ARCO 数据目录以及按需、可扩展的分布式计算，Pangeo 使用户能够以超过 10 GB/s 的速率处理大数据。

挑战

为了实现云计算在科学研究中的全部潜力，必须解决几个挑战，例如组织资金，培训用户和执行数据隐私要求。

简介

数据集

当代科学中充斥着许多研究人员使用的庞大而复杂的数据集。 这些数据集为重大科学问题的新发现提供了令人兴奋的潜力，并且代表了新兴的机器学习方法进行开发的理想目标。 但是，科学界对基础设施的态度可能使我们无法实现这一潜力。

传统方式：下载数据

传统上，科学数据是通过“下载模型”分发的，其中科学家将单个数据文件下载到本地计算机进行分析。 此模型要求数据集相对较小，或者用户只希望查看较大数据集的一小部分。 但是，许多最令人兴奋的科学问题都涉及查看 非常大数据集的整体，以识别通用模式并应对严峻的挑战。

下载模型对该分析模式提出了一些挑战:

  • 可复现：下载许多文件后，科学家通常必须进行大量处理和组织，以使其能用于数据分析。 由于科学家的分析代码必须考虑到这个独特的“本地”组织，因此这为可重复性设置了障碍。

    注：类似 nwpc-oper/nwpc-data 项目中自带的数据查找配置文件仅适用于 CMA-PI HPC。

  • 数据量：数据集的绝对大小 (许多 TB 到 PB) 可能导致实际上无法进行下载。

    注：外网带宽限制，或外国数据提供方 (例如 NCEP) 针对性的限流

  • 并行：对此类数据量的分析也可以从并行/分布式 (parallel / distributed) 计算中受益，并行/分布式计算在本地计算机上并不总是很容易获得。

    注：对于 HPC 这不是问题

  • 公平性：这种模式会加剧拥有资源​​托管数据本地副本的特权机构与那些不能托管机构之间的不平等。这限制了谁可以参加科学。

    注：访问 HPC 便捷性很容易让人忽视这点

云计算

云计算具有将大型数据集和大量计算资源紧密放置在一起的能力。 数据驱动科学的云计算的不同方式：

  • 专有平台：一站式解决方案，可提供数据和计算功能，例如 Google Earth Engine。 功能强大，但通常由单个公司控制，并且灵活性和模块化程度有限。

  • 开放式架构：假设数据将在 Internet 上分发，并寻求不同数据目录和计算工具之间的互操作性。

我们认为 开放式架构 是大数据科学基础架构的最佳途径。

建立在开放架构上的基于云的科学平台需要：

  • 软件：用于交互式数据分析，机器学习和可视化
  • 计算资源：弹性扩展
  • 数据：对数据的访问
  • 示例和文档
  • 维护资源

与任何好的系统体系结构一样，这些组件应尽可能地模块化。 尽管云计算框架已经相当完善，但我们认为数据组件是一个缺失的环节，这阻碍了云计算在多个科学领域的采用。

本文内容

尝试定义一个 云原生数据存储库 (cloud-native data repository)

说明它与传统数据存储库有何不同

提出一系列激发此类存储库需求的目标

概述一套实施云原生数据存储库的最佳实践方案

描述 Pangeo 项目的特定实现

通过枚举在构建和维护云原生数据存储库方面的未来挑战来总结

相关工作

大多数相关工作都集中在紧密耦合到数据的数据附近计算 (data-proximate computing) 上。

Google Earth Engine 是地理空间分析领域的开拓性工作，并且在该领域仍然是极具影响力的产品。

SciServer 是一种流行的通用数据邻近计算环境，它在约翰霍普金斯大学的部署提供了来自天文学，宇宙学，湍流，基因组学和海洋学的大型数据集，以及一系列计算工具。

“分析数据库” 使用户能够在多维数组数据集上运行复杂的服务器端查询的工具。 著名的例子包括 SciDB 和 Rasdaman。

这些工具功能强大且有效。但是，它们面临一个结构性问题：同一提供商同时负责数据和计算。

我们的方法有些独特，因为我们主张 将数据存储与计算平台分离，但又不牺牲性能。

云原生数据存储库的目标

与下载模型相比，云原生数据存储库具有许多优势。

性能 (Performance)

本地计算环境有性能瓶颈，限制分数据分析速度的因素包括：

  • 存储 (有限的磁盘空间)
  • I/O 吞吐量
  • 网络带宽
  • CPU

云计算提供了扩展资源以克服性能瓶颈的机会，而云原生数据存储库首先应致力于实现高性能数据分析。

可靠性 (Reliability)

传统数据访问方法：依赖数据提供者维护的自定义服务器，并且在高负载下可能会崩溃。

云原生数据存储库：将可靠性负担转移给云提供商，并利用这一领域的行业驱动型创新。

成本效益 (Cost-Effectiveness)

现状下载模型中明显的成本低效之处是，相同的数据集多次存储在本地硬盘上。 但是，用于分析它们的个人计算机可能仅在一天的一小部分时间内处于活动状态。 当它们处于活动状态时，它们会遭受上述 性能 部分列出的限制。

云原生数据存储库应通过仅存储数据的一个副本来克服这些效率低下的问题，按需进行弹性缩放计算可以访问该副本。 系统架构还应使不同的实体分别承担数据和计算成本。

协作 (Collaboration)

个人计算机上协作数据科学工作流的一个限制是对本地文件系统路径的依赖，以进行数据访问。 当协作者尝试交换代码并发现他们没有相同的数据或组织不同的文件时，这种依赖性会产生摩擦。

云数据通常使用全局名称空间 (带有 https// 或 s3:// 前缀的绝对 URL)，从而使分析代码具有可移植性。 因此，云原生数据存储库应使科学家能够共享功能代码段，从而创建更快，更流畅的协作工作流。

可重现性 (Peproducibility)

数据科学项目的可重现性要求对至少三个元素进行开放访问：

  • 代码
  • 软件环境
  • 数据

本地文件系统数据依赖性限制了可重复性。

云原生数据存储库应补充可重复性工具，例如 Binder，后者可在用户指定的环境中提供基于云的代码执行，从而允许进行计算附近的数据访问。

创造力 (Creativity)

下载模型：通过限制科学家使用已下载和清除的数据来限制科学家的创造力。

云原生数据存储库：使科学家能够随着工作的有机发展而迅速转向新的数据集。

下游影响 (Downstream Impacts)

许多数据提供者，尤其是地理空间领域的数据提供者，渴望帮助企业利用其数据来获取经济利益。 现代技术公司，尤其是初创公司，绝大多数使用云计算来部署其产品。 云原生数据存储库应启用并鼓励商业开发下游生态系统。

访问与包含 (Access & Inclusion)

下载模型：假定科学家在其机构中拥有资金和基础架构，可以购买功能强大的个人工作站和磁盘驱动器，以及足够的带宽来下载大型数据集。 在许多发展中国家，甚至在历史上被排斥社区的美国部分地区，情况并非如此。

云原生数据存储库：通过将基础架构负担转移到云上来帮助减少这些不平等现象，其中成本可由集中的数据和基础架构提供商承担。

与 HPC 对比

传统高性能计算 (High Performance Computer, HPC) 平台可以实现上述目标。 HPC 可以在数据密集型工作流中实现出色的性能，许多 HPC 中心都托管了大量科学数据。

限制：由于对 HPC 系统的访问受到严重限制，上述列表中的社会目标 (协作，可复制性，下游影响，访问和包容) 仍然难以实现。

我们认识到 HPC 仍将是许多数据密集型应用程序的重要工具。 HPC 中心也越来越多地采用云风格的技术，因此这种区别将来可能会变得模糊。

译者注：例如在 HPC 中使用容器技术

最佳实践

基于上述目标，我们提出了一些针对云原生科学数据存储库的最佳实践。

FAIR 数据

FAIR 原则：数据应该

  • 可找到的 Findable
  • 可访问的 Accessible
  • 可互操作的 Interoperable
  • 可重用的 Reusable

云原生存储库应以这些成功的原则为基础，提供

  • 持久性标识符
  • 丰富的元数据
  • 机器可读的目录和元数据
  • 符合标准的格式和协议

同时，迁移到云计算的动机对 FAIR 词典提出了一些挑战：您如何使 PB 级数据“可访问”？ 要回答这个问题，就需要超越 FAIR 框架并考虑完整的科学工作流程。

分析就绪数据 (Analysis-Ready Data)

科学家的工作流程

想象中的科学家工作流程：

  • 构思新的假设
  • 设计工具
  • 建立模型
  • 以有趣的方式分析和可视化数据
  • 深入地思考结果
  • 得出结论并交流发现

现实情况：陷入了数据下载，清理和准备工作的泥潭，即 手动，重复，可自动化 的工作。

这项工作的结果是分析就绪数据 (ARD)，可以立即进行探索，可视化和分析。 这些 ARD 在公开共享时非常有价值，可以加速研究。

个人活动。传统上，制作 ARD 的辛劳发生在科学的边缘，很少在出版物中得到承认或描述，但是在许多工作流程中却是至关重要的一步。 ARD 的生产是一项私人活动，每次使用数据时都会重复此工作，而不是在生成数据时重复一次。 随着数据量增长到“大数据”状态 (从数 TB 到 PB)，创建 ARD 的任务变得越来越繁重。

合作发布。我们建议云本地存储库寻求发布 ARD。 这样做需要与社区的科学家紧密合作，他们了解如何为自己的学科创建 ARD。 发布 ARD 并不意味着放弃原始的原始数据。 相反，必须仔细记录原始数据和 ARD 之间的出处链 (provenance chain)。

数据集而不是单个文件

ARD 的一个关键通用属性是关注有意义，完整的数据集，而不是单个数据文件 (也称为“granules”)。 使用 ARD，科学家应该能够“打开”一个完整的数据集，其中包含分析所需的全部数据，而不是手动循环许多文件。

从技术角度来看，有许多方法可以实现这一目标。

  • 多个文件可以预先串联为单个大文件。劣势：四处移动可能很麻烦
  • 更具可扩展性的方法：软件与数据之间的更紧密集成，将许多单个文件作为一个虚拟对象进行寻址

展示 ARD 的示例如图 1 所示

图 1，图片来自论文。 Pangeo 数据目录中的 ARD 示例。Xarray 提供了高级数据模型和数据集的丰富可视化表示。在后台，数据以 Zarr 格式存储在云对象存储中。使用 Dask 框架可以实现“延迟加载”，这意味着我们可以查看非常大的数据集而无需将其加载到内存中。来自 https://catalog.pangeo.io/browse/master/ocean/sea_surface_height/

云优化数据 (Cloud-Optimized Data)

本地数据环境和基于云的数据环境之间最大的技术区别是对 对象存储 的依赖。

本地数据环境：使用 POSIX 文件系统来存储数据，数据分析原件通过文件系统调用访问数据。

云平台：所有现代公共云平台都提供对象存储服务，这是存储大量数据的最便宜，最可扩展的方式，通过 HTTP 调用读取和写入数据。

尽管云计算环境可以配置本地硬盘，但我们认为，只有在数据访问绕过文件系统并直接进入对象存储时，才能真正实现性能，成本效益和可重复性的目标。

方法：模拟文件系统

解决数据访问问题的一种方法是让分析环境误以为它正在处理文件，而实际上却在处理对象存储。实现方式举例：

  • 操作系统级别，通过在用户空间中使用 Filesystem in Userspace (FUSE)
  • 应用程序级别，例如通过使用文件系统友好的 API 创建包装对象存储的兼容层

问题：由于增加了复杂性并依赖于传统的，未经云优化的文件格式，因此这些方法可能行得通，但通常无法实现最佳性能。

本地文件系统 vs 对象存储

类型延迟吞吐量
本地文件系统低 (毫秒级)受物理设备特性限制：HDD 100 MB/s，SSD 500 MB/s
对象存储服务高 (HTTP 调用，100 毫秒或更长)基本不受限制 (并行访问)

数据格式

许多流行的科学数据格式在对象存储流行之前开发，仅考虑 POSIX 文件系统。

  • HDF5
  • NetCDF，地球科学
  • FITS，天文学
  • ROOT，高能物理学

在打开文件和读取数据时，会执行许多小的查找/读取操作。 即使可以欺骗应用程序以使其在与对象存储进行实际对话时正在访问文件系统，与这些操作相关的应计延迟也会转化为非常慢的性能。 减轻这些挑战可能需要对访问库进行实质性的重构。

方法：云优化格式

一种有吸引力的替代方法是采用从一开始就设计用于对象存储的更现代的云优化格式。

  • 用于表格数据的 AVRO，ORC 和 Parquet
  • 用于多维数组数据的 TileDB Embedded 和 Zarr。
  • Cloud-optimized GeoTIFF

这些格式都具有某些基本特征：

  • 元数据：可以快速读取描述结构和内容的元数据，允许客户端代码构造大型复杂数据集的虚拟表示
  • HTTP 协议：可以使用 HTTP 协议读取数据，无需假设文件系统路径
  • 内部分组：数据以内部分组 (例如，shards/chunks/tiles) 进行组织，可以进行有效的子集和分布式处理

将云优化格式与对象存储相结合，实质上可以将对象存储服务转换为用于数据访问的高性能REST API，而无需操作任何其他基础架构。 因此，云优化格式对于实现性能和成本效益至关重要。 要充分利用分块数据格式，还需要分析软件的配合，实际上，许多分布式计算框架都与云优化格式很好地结合在一起。

在实际操作中，我们建议云原生数据存储库采用云优化格式。 这可能需要在摄取时转换旧格式。 此活动通常可以与使数据准备就绪以进行分析的过程相结合，从而生成可进行分析的云优化(analysis-ready, cloud-optimized, ARCO) 数据。 ARCO 数据是云原生数据存储库的黄金标准。 但是，这样的转码可能是昂贵的，费时的并且易碎的。 有关如何以最佳方式从云原生存储库中继承传统格式的问题，将在以后的挑战部分中讨论。

数据接近计算

下载模型：使用传统的数据存储库，用户将数据带到他们的计算机上

数据接近计算：在云原生数据存储库中，用户将计算转移到数据中

与用于数据分析的垂直集成专有云平台相比，开放式访问云原生数据存储库不应直接耦合到特定的计算解决方案；相反，他们应该寻求与计算服务和访问范式联合的最大互操作性。 这将在数据提供者和消费者之间建立一个有机且不断发展的生态系统。

下面我们列举了一些需要考虑的特定数据近似计算方法。

交互计算

交互式计算使数据科学家可以探索复杂的数据集，测试想法，以图形形式接收视觉反馈，并快速进行迭代以完善其分析。 有效的交互式计算需要丰富的动态用户界面，这在本地环境中很容易实现，而在远程 (例如，基于云的) 计算系统中则更加困难。

Jupyter。云中的 Jupyter 与云原生数据存储库非常匹配，可作为交互式数据近端计算的解决方案。

RStudio Server。为 R 用户提供了可比的体验。

并行分布式计算

对于真正的大数据，云提供了在很短的时间内为并行分布式计算提供大量计算节点的机会。 可以在云中部署的流行分布式计算框架包括 Hadoop，Spark，Dask 和 Ray。 无服务计算 (例如 AWS Lambda) 为分布式处理提供了更具可扩展性的解决方案。

云原生数据存储库应设法使这些数据可访问并具有这些框架的性能，这主要是通过采用云优化格式来实现的。

训练机器学习模型

机器学习 (尤其是深度学习) 得益于非常大，干净，同质的数据集，可在该数据集上训练模型——正是云原生数据存储库将提供的各种数据集。 云计算环境可以提供高性能机器学习所需的各种专用硬件 (例如 GPU，TPU)，而诸如 Kubeflow 或 Dask-ML 之类的框架可以帮助协调云中复杂的机器学习实验。

云原生数据存储库应通过 高吞吐量数据访问 来努力支持诸如此类的机器学习应用程序。

开源和可移植性

我们鼓励云原生数据存储库采用开放源代码软件，以使其基础数据和软件可跨云平台移植的方式使用。 开源软件有助于最大程度地提高透明度和可重复性，从而增加对系统的信任。 特别是对于公共资助的项目，发布开放源代码软件还可以通过允许其他人重用和改编该工具来实现尽可能广泛的访问和影响。

但是，由于商业云提供商依靠许多定制的专有工具来运行其云平台，因此对于在云中部署的基础架构而言，开源的定义可能变得模棱两可。

为了解决这个难题，我们引用了开源云用户的“权利法案”。 开放云架构的运维人员应该能够

  • 在他们选择的任何云提供商上运行他们的软件
  • 仅在其他开放源代码软件的帮助下，在他们实际拥有的一系列计算机上运行他们的软件

采纳这些原则可以减轻寻求将其数据基础架构迁移到云的机构的主要担忧：担心锁定到特定的云提供商。

这些原则限制了体系结构的选择。 例如，原则要求开放的云原生数据存储库可能不应该使用诸如 Google BigQuery 之类的工具作为其存储数据的主要机制，因为 BigQuery 仅在 Google Cloud Platform 中可用。 相反，围绕通用对象存储服务构建的数据存储库几乎可以转移到任何云提供商。

Pangeo 实现

Pangeo 项目 是一个社区组织，旨在推进用于分析大型复杂地球系统数据的开源软件和基础架构。

我们总结了通过整合来自科学 Python 生态系统的不同开源软件工具而实现的上述最佳实践的实现。

架构

数据格式：Zarr

Pangeo Cloud Data Catalog 包含以 Zarr 格式存储的 ARCO 数据集。 这些数据集是多维数组，源于卫星观测和数值模拟，符合 NetCDF 数据模型和气候预测 (CF) 元数据约定。 Zarr 数据集是通过聚合许多单独的 NetCDF 文件 (例如，来自卫星产品的所有时间粒度)，设置适当的块大小 (大约100 MB) 并将数据以 Zarr 格式直接写入 US-CENTRAL 区域的 GCS 来生成的。

数据编目：Intake

使用 Intake 的 YAML 目录格式通过 Intake Python 库 进行分类。 目录存储在 GitHub 存储库 中。

访问方式：

  • 使用 Intake catalog 来交互式地浏览，搜索和打开数据集 (Python)
  • 通过 公共网站 浏览目录 (基于 Flask 的 Web 应用程序)

Pangeo Cloud

Pangeo Cloud 的数据接近计算服务已部署在 GCP 和 AWS 上。 所有计算服务都在 Kubernetes 集群中进行管理，根据系统使用情况灵活地上下扩展容量。

该基础架构基于 JupyterHub，用户可以通过 Web 浏览器进行连接。 经过身份验证 (通过 GitHub) 后，JupyterHub 服务为每个用户生成一个 Jupyter 服务器，提供一个私有的，交互式的 Python 计算环境，该环境中预载了常用的软件包，用于数据访问，分析和可视化。 用户可以根据需要选择不同级别的计算资源 (RAM，CPU)。

数据分析

用户使用 Intake 库与数据目录进行交互。

数据处理：大多数数据集都经过优化，可以使用 Xarray 打开和分析，Xarray 是一个 Python 库，它提供了高级数据模型和计算 API，用于处理标注的多维数据集。 Xarray 支持 “lazy” 操作，只有在明确需要计算和可视化之前，才从存储设备实际加载数据。

并行计算：Xarray 与 Dask 紧密集成，以实现分析操作的自动并行化。

可视化：HoloViz (以前称为PyViz) 工具启用了大数据的交互式可视化功能，该工具在实现缩放时动态重新渲染。

Dask Gateway

Dask Gateway 是一个用于管理 Dask 群集的安全的多租户服务器。 用户可以置备个人的 Dask 群集，用于并行处理数据。

Pangeo 工作负载往往受 I/O 约束，这种并行化使用户能够利用云对象存储的高吞吐量。 每个 worker 都直接从对象存储中提取数据，而 Zarr 块提供了自然的并行化单元。 此配置的各个组件如图 2 所示。

通常，用户将按比例缩放 Dask 集群，对大型数据集执行归约运算 (例如，均值或标准差)，然后切换到本地分析模式以进行最终可视化和解释步骤。

图2，图片来自论文。Pangeo 体系结构图。数据存储库以 Zarr 格式托管在云对象存储(左)中。Kubernetes 集群内的计算节点(右)从对象存储中获取数据和元数据。用户通过Jupyter 连接到系统，并在 Xarray 中编写交互式数据分析代码，该代码在自适应缩放的 Dask 集群上调度计算。

测量数据吞吐量

创建云原生数据存储库的主要动机是希望克服下载模型的性能限制。 在 Pangeo Cloud 中，不下载数据，而是直接从对象存储将数据流传输到同一云区域内的计算节点。

为了量化该架构提供的加速，在图 3 中，我们显示了来自 https://github.com/earthcube2020/ec20_abernathey_etal 采用的基准测试结果。 我们测量了可以将数据从存储服务传输到 Dask 计算群集的速率 (以MB/s 为单位)，该速率是分布式读取进程数的函数。 所有基准测试均在 GCP US-CENTRAL1 地区进行。

我们比较了四种数据访问模式。

  1. 从 ESGF Open-source Project for a Network Data Access Protocol (OPeNDAP) 服务器加载数据。OPeNDAP 是地球科学中成熟且广泛使用的数据交换 API。但是，这不是基于云的服务，因此它是比较新技术的基准。

  2. NetCDF-4 (HDF5) 文件直接放置在 Cloud Object Storage 中。 此选项对于量化传统格式在云中的性能很有用。

  3. Zarr 存储在 GCS 中。

  4. Zarr 存储在 Open Storage Network (OSN) S3 兼容的对象存储服务中。

图3，图片来自论文。读取不同数据访问方法的吞吐量。源数据：https://zenodo.org/record/3,829,032. 代码：http://gallery.pangeo.io/repos/earthcube2020/ec20_abernathey_etal/cloud_storage.html

这些结果表明 Pangeo 实现的云原生数据存储库和数据接近计算具有潜力，以比仅限于个人计算机的工作流更快的速度处理数据。 个人计算机上最快的 SSD 可以提供大约 500 MB/s 的吞吐量。 借助少量的分布式计算节点，Pangeo Cloud 用户可以处理许多 GB/s 的数据。 而且，采用这种方法，不需要下载数据，而只需要存储数据的一个副本。

结论和未来挑战

云公共数据集项目的成功以及 Pangeo 云数据库等新兴工作的潜力表明，云原生数据存储库可以成为帮助数据密集型科学领域克服当前基础架构挑战的可行途径。

云原生科学平台既需要 ARCO 数据，也需要可扩展的数据接近计算。 我们主张将 ARCO 数据的存储与邻近数据的计算组件分离，这些服务应可互操作但独立。

尽管云原生数据存储库有可能加速科学发现，但我们看到一些挑战将限制它们在不久的将来被采用。

资金

学术研究机构和资金系统不习惯为云计算付费。 与云原生存储库相关的潜在成本节省 (即消除大数据集和相关本地计算资源的重复本地副本) 只能通过汇总多个研究组来实现。

可以将迁移到云原生模型的过程视为整个领域向低成本，高生产率状态过渡的阶段。 我们认为，将云原生数据存储库和数据邻近的计算服务之间的关注点分离将有助于简化此过渡。

用户教育和培训

真正的云原生数据科学工作流程将看起来不完全像本地工作流程。

忘记熟悉的模式：例如依赖本地文件系统路径进行数据存储。

学习新概念：有效使用像 Dask 这样的分布式计算工具需要学习新的概念。

云原生概念：即使是习惯于并行处理的经验丰富的 HPC 用户，也可能会对弹性扩展和无服务器计算的云原生概念感到困惑。

管理：大学和实验室的 IT 人员相对不熟悉云计算的管理 (与运行本地服务器相比)，这也需要新的培训。

为了实现云计算在科学领域的潜力，需要协调一致的努力来满足这些教育需求。

数据访问和隐私

像气候科学和天文学这样的领域是基于云的数据共享的早期采用者，这些领域中的数据大部分是开放访问的，没有隐私限制。因此，数据可以简单地公开并向所有人开放。

如果没有用于基于云的数据的访问控制管理的灵活开放工具，那么对隐私问题高度关注的领域将很可能被推向非模块化、不可移植的专有，垂直集成的解决方案。

尽管云提供商具有强大的权限功能，但仍需要一些技术开发 (和相应的机构资助) 来扩展此处介绍的方法，以管理对开放程度较低的数据集的访问。

总结

尽管存在这些挑战，但我们仍然对云计算在数据密集型领域进行科学研究的潜力充满热情。 我们希望，通过帮助定义云原生数据存储库的最佳实践，我们在构建基础设施方面做出了很小的贡献，以应对未来的一些重大科学挑战。

参考文献

正文结束

讨论

参考

论文原文：

https://www.authorea.com/users/372628/articles/490577-cloud-native-repositories-for-big-scientific-data