面向大规模数据的云端管理，百度沧海存储产品解析

导读 introduction

本文整理自同名《云智公开课》系列分享，详细介绍百度沧海·存储如何进行大规模数据，流转上云、智能分级存储、安全管理、多业务应用。

全文5657字，预计阅读时间20分钟。

GEEK TALK

01

ABC 时代下存储面临的四大挑战

我们称当前这个时代为 ABC 时代。A 指的是我们正处于人工智能的时代；B 指的是我们正处于大数据的时代；C 指的是我们正处于一个万物皆可上云的时代。

存储系统在很多年前就已经出现了，在当下存储又会面临着哪些新的挑战呢？

挑战的第一个关键词：海量。对于企业而言，以前可能只是存放一些互联网上的应用数据，最多就再有一些文本数据，备份数据。但现在，我们看到更多是以视频、音频等为载体，数据量呈现出一个爆炸式增长的态势。在这个背景之下，云服务商面临的是如何解决海量数据的上云和存储问题。换句话说，我们的物理容量如何更好地去承载数据的爆炸式增长。

挑战的第二个关键词：性价比。在这个时代当中，我们将数据视为是有价值的资产。既然数据有价值，那就要求云服务商如何在保证数据不删的前提下，如何帮助客户花小钱办大事，这个是客户以及我们都比较关心的。举个例子，十年前客户的数据是 10 PB， 10年之后它的数据发展到 50 PB，数据量是原来的 5 倍。那是否意味着客户的存储成本也是原来的 5 倍？这是不一定的，因为我们要想方设法地帮助客户去尽量减少数据存储的成本。

挑战的第三个关键词：稳定性。当分布式系统承载数以万计的客户业务时，我们如履薄冰，因为这要求我们必须去保证系统的稳定性。同时，我们的存储产品还要去帮助客户去实现一定的容灾能力，和一定的备份能力。

挑战的第四个关键词：多样性。多样性它其实体现在很多方面，最主要的一个表现是客户的业务场景日趋多样性。比如说很多年之前，客户的场景更多是数据存进去之后，在需要的时候能够把数据读出来就可以了。当下数据不只是存储，还出现了不同的场景，比如大数据分析，AI训练，混合云平台搭建等涌现，需要使用不同的存储产品和组合来满足业务需要。

针对这四个挑战，今天我主要通过五个部分和大家来分享。

GEEK TALK

02

百度沧海·存储的产品体系概览

首先给大家介绍一下百度沧海·存储。他保障了百度核心业务高效可靠地运行。比如说像我们大家熟知的百度搜索、百度网盘、百度贴吧、百家号、百度地图、百度全球领先的 AI 业务等等。

沧海的产品体系是一个矩阵式的结构。包括对象存储 BOS、块存储 CDS、文件存储 CFS、并行文件存储 PFS 等等。

另外我们也会有一些特定场景下的产品，比如说数据湖存储加速 RapidFS，它的目的是加速对象存储数据在大数据或者 AI 场景下的访问。另外包括边缘存储，以及面向传统客户的混合云存储 ABC Storage 等。

除此之外，我们还有一些工具型产品，比如说数据流转平台 CloudFlow，它解决了数据上云和流转的一些问题。另外还有像针对 IDC 企业上云的场景，我们推出月光宝盒这个产品，它可以实现数据的拷贝和物理搬迁。另外针对混合云场景，我们也提供存储网关的能力。比如一个用户的计算节点在本地，他在云端购买了对象存储，那么他可以通过存储网关来把本地和云端进行融合，对本地的资源空间在云端进行拓展。

以上是沧海的产品体系。产品体系下面是我们整体的一个技术平台。我们强调三个点，一个是存算协同，另外一个是软硬融合，还有一个是云边一体。

产品体系的上层，是我们的解决方案。我们已经服务了数万家客户，在这个过程中我们沉淀了很多解决方案，比如说云相册解决方案。大家都知道现在手机都有云相册功能，并在相册中集成一些能力，如对人脸进行分类而形成人脸相册等等。基于此我们也提供针对手机厂商的云相册解决方案。

还有像互联网的存储分发方案。比如说一部电视剧，一部电影，一段短视频，都需要分发到全球各地的终端，因此我们也推出了互联网存储分发解决方案。另外针对客户会把数据存在不同的云厂商中存储，我们也提供多云的解决方案。

另外我们也提供归档备份的方案。有些数据长期不用，但又偶尔会有访问，因此我们提供一个低成本的归档备份方案。另外，我们针对不同的行业或者说不同的场景，也会有不同的解决方案，比如说游戏存储、自动驾驶、合规存储，还有像医疗影像存储等。

GEEK TALK

03

百度沧海·存储如何解决四大挑战

3.1 数据流转全景方案，高效上云

对于上云而言，我们一般会先区分数据源端，包括：企业自有 IDC、其它云服务商（如 AWS、腾讯云或者阿里云等）。对于企业自有 IDC 这类客户而言，客户往往希望本地数据能够上到我们云端对象存储 BOS 当中。

我们提供三种方式，比如说磁盘阵列混合云，还有像刚才提到月光宝盒。它就像一个大 U 盘，这个大 U 盘把数据从本地拷贝完成后，通过物流的方式寄送到百度智能云的机房，由我们的专业操作人员帮客户完成数据的上传。

另外，可能有些客户的数据量比较大，此时也可以通过我们的专线服务来进行迁移。如在客户的 IDC 和百度智能云机房之间拉一条专线，这样可以走内网去把数据高效地传输到 BOS 当中。

对于已经上到其他云的客户，他的迁移就涉及到跨云的迁移，用户可以用数据流转平台 CloudFlow 进行可视化的、一键式地去发起数据的迁移和同步。用户只要填写一下源端信息、目的端信息，同时填写一下对性能或者对存储路径等的要求，点击确认后，就可以自动开始迁移任务了。

另外，针对一些特殊的场景，如用户希望将其他云的增量数据迁移到 BOS 中，此时可以开启镜像回源的功能。当数据被访问的时候，可以直接从其它源端把数据自动地同步到 BOS，帮助用户实现业务的连续性。

除了跨云迁移之外，我们还可以实现跨云的同步。

跨云同步，一般我们是指增量数据的跨云迁移。用户可以在 CloudFlow 中配置一个基于事件通知的功能，来完成定时扫的任务。比如说间隔一小时或者间隔一天去扫描一下源端是否又新写入了一些数据，我可以精准地把这些增量的数据迁移到 BOS 中来。

3.2 智能生命周期管理，存储最优

用户对存储的成本是比较关心的。对于对象存储 BOS 而言，它已经发展到了 EB 级别的物理空间，数万台的物理服务器，数万亿级别的文件数量，这个规模在国内是非常大的。

随着时间的推移，比如说可能在经过这个半年或者说一年、三年之后，数据可能就没有什么人访问了，但用户还必须存储。

因此针对这样的一个诉求，我们推出了分级存储，包括标准存储多 AZ、标准存储、低频存储多 AZ、低频存储，或者说冷存储还有归档存储。

不同的存储类型从左往右，它所对应的这个数据的访问频率是逐渐下降的。对于频繁使用的热数据，一般使用标准存储。随着它的访问频率降低，可以逐渐沉降低频存储、冷存储或者归档存储。尤其像归档存储，它更多针对三年访问一次的场景。比如有些数据需要长期保存，像基因数据，电商直播数据，一些为应对检查而必须保留的合规性数据等等。

对于优化成本而言，对象存储还提供了“生命周期沉降”这样的一个功能。

比如说数据最开始是热数据，即存储在标准存储中。我们可以设置一个生命周期规则，比如说在上传之后的 30 天从标准存储沉降为低频存储，再过 60 天后进一步沉降到归档存储。用户可以提前去设置这样一个规则，当沉降日期到来时，数据会自动进行沉降。具体的价格方面，我们最冷的一级归档存储只有标准存储单价的 18%，所以说通过沉降来降成本的效果是非常明显的。

除了沉降之外，我们还支持生命周期上浮。比如说现在可能有一个文件，它是一个冷存储的文件。一般而言，冷存储文件的访问频率是比较低的，但是也不排除会有一种情况，即这个文件在一段时间之内它的访问频率变得非常高。

这种情况下，用户可以设置一个生命周期上浮的规则，通过 BOS 的自动化监测，当冷数据被频繁访问时，上浮到上层存储类型如低频存储、标准存储。因此，生命周期管理的使用方式是非常灵活的，用户完全可以根据自己的需求去选择合适的存储类型，同时去设置合适的沉降规则。

一个典型的案例，比如爱奇艺的长视频，包括像电影、电视剧等都存在 BOS 里面。这个数据一开始可能是热数据，使用了标准存储。但当这个数据长期没有人访问之后，它可以自动沉降到冷存储，这个规则帮助爱奇艺节省了大量的使用成本。

与此同时，爱奇艺又通过我们的 CDN 节点来进行数据分发，来保证数据可以分发到全球各地的终端。

3.3 数据存储多级容灾，安全可靠

客户在使用云端存储的时候，如何保证数据的安全可靠呢。这里我们要讲云存储的两个指标。

第一个我们称之为可靠性。对象存储 BOS 外承诺的可靠性是 12 个 9 ，也就是99.9999999999%，这是一个非常高的水平，数据丢失的概率是千亿分之一。我们是如何实现高可靠的呢？BOS 建立了超大规模的纠删码集群，把数据均衡地分布到多个AZ，也就是说我们可以冗余 N 台交换机的故障，冗余单 AZ 的故障。

另外一个指标，我们称之为可用性。对于可用性而言，单 AZ 存储类型的可用性是99.95%，多 AZ 是 99.99%。但长期经验来看，我们真实的可用性在 99.9995%，是一个非常高的水平。

我们是如何保证这个可用性？BOS 使用了四层负载均衡，集群模式无单点。而数据 EC 编码也保证了多冗余读取。而且接入访问层可以水平拓展，也进一步提高了产品的可用性。

我们提供了多个级别的容灾能力。

首先，BOS 具备物理机级别的容灾。BOS 底层采用分布式存储架构，并采用 EC 编码技术。如果某一台物理机因为网络原因或其他原因导致临时宕机时，业务可以自动切换，而用户根本感知不到物理机宕机的情况。

其次，我们推出了多 AZ 存储类型。比如说像刚才提到的标准存储多 AZ，低频存储多AZ，我们把数据是在多个机房同时存储。当某一个机房突然间因为自然灾害等原因导致机房不可用时，BOS 可以实现机房级别的容灾切换。另外，我们也可以实现跨地域的备份和容灾。我们在北京、苏州、广州、保定等区域都提供服务，用户可以提前把数据同步到其他区域。

最后，我们提供数据镜像回源的能力。当数据在主源站中不存在时，会自动到备源站中去捞取数据。

3.4 多产品数据流联动，简单易用

最后一个部分，给大家介绍一下前面提到的应用多样化。单一产品越来越无法满足客户的需求，需要提供多个产品来形成一整套的解决方案，进而帮助用户去解决问题。

这里今天重点给大家介绍这个三种解决方案。第一个是大数据场景下的数据湖加速方案，另一个是混合云存储场景下的方案，第三个是 AI 场景下的 HPC 存储。

首先第一个是大数据场景下的数据湖加速方案。我们数据湖加速是以 BOS 作为整个数据湖的底座，同时我们会有一个数据湖存储加速产品叫做 RapidFS，打通大数据场景下面计算和存储间的数据高速公路。

不管是 MapReduce 这样的大数据场景，还是 AI 场景，底层其实都可以选择对象存储 BOS 来承接海量数据的存储能力。对于大数据场景而言，常见的场景包括离线计算场景和线计算场景。

离线计算场景中，典型的像网站内容推荐。用户在一个网站上面的浏览行为会形成很多浏览数据。对于网站厂商而言，往往会在晚上对用户这些行为进行分析，从而当用户下一次浏览网站时，为其做内容推荐。我们称之为是一个离线训练的场景。

还有就是在线计算场景。典型的比如说我们在用一些 APP，或者说用一些网页的时候，我们点了一个搜索框希望搜索某些东西，网站/APP会在线的对用户的一系列行为进行在线计算，优化搜索结果。

离线场景往往对计算的延迟要求较低，因此推荐使用 BOS 的原生层级 Namespace 架构。相比采用平坦 Namespace 的 S3 存储，采用层级 Namespace 的对象存储，其 prefix 具备操作的原子性，对大量小文件的频繁访问会更加友好。同时，可以通过 RapidFS，在近计算节点做热数据缓存，进一步达到数据访问加速的能力。

对于在线计算的场景，客户可以在 VPC 内安装 RapidFS 组件。除了进行缓存之外，也可以开启 VPC 内的层级 Namespace。由于层级 Namespace 部署到了 VPC 内，因此相比下图左边的方案，右边方案的加速效果会更好，对于大数据场景下常见的rename、list、delete 等操作，访问性能会有较大的提升。

另外一个是我们的混合云存储。比如说像这个客户会有自己的 IDC。因为本地的容量是有限的，所以客户希望将老旧的冷数据，通过某种方式同步到云端。这样做的话，既可以节省自己本地的一些空间，又可以在云上使用 BOS 的分级存储和生命周期能力，降低存储的成本。

在这个场景下，我们提供存储网关 BSG 这样一款产品。用户可以把 BSG 部署到自己本地的 IDC 当中，一键打通本地和云端。比如说，BSG 部署在 IDC 后，用户可以通过 BSG 来挂载 BOS 的一个存储桶，这样用户在往本地 IDC 写数据的时候，他看到的可能是写到自己本地 IDC 的一个路径，但其实已经把这个数据写到了云端。我们可以做到不同协议的兼容，在不改变用户使用习惯的前提下，帮助用户去建立混合云存储。

最后一个场景，我们专门针对 AI 场景。在这个场景中，我们也是推荐使用对象存储BOS 作为数据底座，同时在上层搭配并行文件系统 PFS。AI 场景下，更多操作以读数据为主，比如 AI 训练时会有很多读数据集的操作。

具体而言，这个方案会有三个特点。首先，我们包含兼容 POSIX 接口的加速层，基于本地盘和全闪硬件的 PFS；另外，我们可以实现资源和数据集的准备自动化，和调度器深度融合，降低使用的复杂度；第三，在训练数据时，支持配置不同的数据加载策略，比如说预加载、首次访问时加载等等。

本期公开课回放链接：https://cloud.baidu.com/live/59

点击阅读原文，了解百度沧海更多内容。

 END

推荐阅读：

一键三连，好运连连，bug不见👇