共计 4559 个字符，预计需要花费 12 分钟才能阅读完成。
以后，业内善于非结构化数据的存储形式次要是文件存储和对象存储。文件存储和对象存储各有千秋，文件存储不仅能兼顾多个利用和多个用户拜访，更突出的劣势是不便文件共享；对象存储凭借灵活性和扁平架构失去了宽泛的好评，容量达到 EB 级以上，实现实践上的对象存储容量和对象数量有限裁减。然而，因为对象存储的拜访接口协议繁多，数据拜访性能较差的问题，使其可实用的范畴受到了肯定水平的限度。以下内容是焱融科技架构师彭德跃的局部演讲实录：
明天，我将基于当前情况的背景，给大家分享一下，焱融科技是如何解决这个难题的。
为什么须要分布式文件存储
首先，咱们从业务背景开始介绍，为什么客户会须要分布式文件存储。
咱们以 AI、机器学习、主动驾驶为例，他们有一个独特特点就是须要文件接口和反对海量文件存储的文件系统。同时，只有文件系统提供极高的性能，能力满足他们对业务的需要。
以焱融科技的客户为例，客户理论业务会不停地增长，为此存储也须要随着业务一起扩大。请留神，这是客户的必要需要。因为咱们是软件定义的存储，且具备客户须要的性能。从部署上来说，咱们反对 3 个节点部署，将来在业务持续增长过程中，能够随时扩容。同时，咱们是一个 POSIX 兼容的存储，在客户业务上，不须要进行批改，能够间接在 YRCloudFile 上应用，非常便捷。
目前，上云曾经倒退了很多年了，根本属于既定事实。为了反对私有云部署，咱们基于焱融科技外围产品 YRCloudFile 推出了焱融 SaaS 文件存储，为帮忙用户在不同私有云上运行的业务创立本人的共享文件存储空间。
从高性能文件存储系统 YRCloudFile 架构图上看，能够发现咱们的下层能够撑持很多客户端连贯，通过以太网或者高速 InfiniBand 网络连接 YRCloudFile 分布式存储集群，其分布式存储集群是由规范 X86 服务器组建起来的，与大多数文件系统一样，咱们会分为元数据集群、数据集群和治理集群。另外，咱们在 X86 服务器下，对接了大多数的对象存储系统，目前曾经适配的有 AWS、腾讯云、阿里云等等。
在理解到 YRCloudFile 当前，咱们来具体说一下 S3 和文件系统的联合，以及为什么客户须要 S3。
这不仅仅是一个业务问题，它也是一个技术问题。咱们在和客户交换的时候，通常他们都会提到一个需要——在做机器学习的过程中，因为计算量特地大，所以须要很大的存储空间，为了进一步节约老本，他们心愿把局部数据存储到对象存储里。
举个例子，客户领有 10TB 的热层空间，一次计算可能只用把局部数据加载到热层里，在实现计算当前，这部分数据可能就不必了，客户心愿能将这部分数据主动上传到 S3 上。这样不仅能满足客户的业务和性能需求，又能节俭他的老本，还不须要调整业务逻辑。
除此以外，咱们还须要兼顾客户的数据流转，也就是数据的可拜访性。比方，客户将数据放到阿里云上，他们在北京、上海都能拜访到。还有一种状况是，异地调取数据，也就是当客户在北京机房产生的数据，能够上传到 S3，之后他在上海的机房，也能够读取数据，用于计算。
为了一次性满足客户这么多的需要，咱们做了两个技术设计——Tiering 和 DataLoad。接下来，我将具体和大家聊一聊这两个技术设计。
冷热分层 (Tiering) 的设计
1、分清主次
首先，咱们须要先从 YRCloudFile 自身登程。当初曾经有很多企业曾经在应用 S3 了，下面也存储了海量数据，如果咱们要和 S3 联合的话，咱们首先要思考 YRCloudFile 自身的劣势，比方性能、经验过理论的测验等等，并如何将产品自身长处和 S3 联合起来。
以后，业内的典型做法是 S3 文件网关，咱们该如何了解它呢？举个例子，假如我在阿里云上有 1 万个对象，我在文件网关给它套一个文件接口，它最次要的性能就是我能够通过文件接口去拜访数据，然而这样的做法会有一些问题：
- 难以反对读写，因为对象存储是不可批改的；
- 如果反对批改的话，解决起来会比拟麻烦。再加上为了满足性能需求，你的文件网关必定是要有本地长久化数据的；
- 在上述条件下，如果从文件网关上，把对象读到本地硬盘，那么就会存在数据安全性问题；
- 如果当本地硬盘呈现故障，那么数据就容易呈现问题，这时你又须要多做一个正本，这会让网关层变得很“厚重”。
在思考到这些问题当前，咱们很动摇地决定要在 YRCloudFile 上实现 S3 的利用。
2、文件切片
其次，咱们还须要思考文件是否要切片。举个例子，当初有一个 1GB 的文件，如果咱们要进行文件切片，那就会被拆分为 256 个对象。
尽管文件切片与否各有利弊，然而咱们从 YRCloudFile 的角度思考，如果采取文件切片的措施，可能会扭转 IO 流程，可能会对本来的性能产生影响。为此，咱们采取了逻辑切片的形式，它的劣势就是能够让咱们有更灵便的解决办法，最次要的方面就体现在它的切片大小是能够调节的。
比方，客户应用的是阿里云，并且配置了很高的带宽。为了满足这一特点，咱们能够把逻辑切片调大一些，让性能更好一些。然而如果客户业务呈现转变，可能不再应用阿里云，而是应用其余价格较低的云，这时咱们也能够“自适应”，无需做其余调整，让客户应用起来更不便、灵便。
3、性能
对于性能的局部，咱们以看电影为例，假如咱们在播放电影的时候，只想看两头的局部，实际上我能够通过 Http 接口去间接读取指定的数据段，相比物理切片来说，它的数据传输量是一样的，并不需要每次都把整个对象读取结束。这也是一个很重要的点，它能够帮忙咱们进步读写性能。
具体咱们是如何保障性能呢？这里，我给大家分享一下焱融科技的几大准则：
第一，咱们不反复传输数据，只做数据缓存。比方你当初有 1 GB 的对象在云上，我只须要拜访两头 1 MB 的数据，那么咱们会把这两头 1 MB 的数据下载到本地，后续拜访就会间接在本地实现，这也是咱们实现 Tiering 高性能最次要的一点。
第二，在咱们给文件做一个本地的索引和预读。通过本地索引，咱们清晰地晓得数据是否须要从 S3 上读取。通过预读机制，咱们能基于用户 IO 的特点，提前从 S3 上预读数据到本地。
4、缓存模式
缓存置信大家都不生疏，我在这里就简略地和大家探讨咱们要做一个什么样的缓存。
如上图所示，咱们一共有四种模式，别离是：
- Write back 缓存，可实现间接读写；
- Write through 缓存，可同时读取 YRCloudFile 和 S3；
- Write around 缓存，可从 YRCloudFile 读取，间接写在 S3；
- None 缓存，仅反对 S3。
为了满足性能要求，咱们默认采纳 write back 缓存形式，从而实现了热数据被存储在热层，来满足用户的性能需求。而冷数据会被异步地 write back 到 S3，来节俭热层存储空间和老本。
5、只读 or 读写
接下来，还有一个十分重点的问题，那就是反对只读还是读写，这个问题对产品整个设计有十分大的影响。
首先，咱们来了解一下“只读”，它指的是我从来不会批改我的业务数据，比方当初对象在 S3 上，我只会把它下载做计算，而不会批改它。
“读写”则是我不仅须要将数据下载做计算，还须要批改数据，即使是只改一个字节，那也是做了批改的操作。大家都晓得，S3 对象是不反对批改的，如果要批改，只能用批改后生成的新的 S3 对象去残缺笼罩旧的 S3 对象。
为了适应更宽泛的业务场景，去满足更灵便的客户需要，咱们保持反对“读写”，尽管从技术角度来看，“读写”的挑战会更大，然而它的灵活性是“只读”无法比拟的，会让用户应用起来更晦涩、舒服。
6、S3 计费
除了技术角度以外，咱们还思考到了客户的费用问题。上图是某私有云的计费截图，咱们能够看到 S3 的计费不仅有外网的流量费用、传输费用，还有 API 申请调用次数的费用。
如果咱们不应用逻辑切片的形式，而是做比方 4MB 大小的物理切片，那么会产生大量的 S3 对象，也会产生更多的 S3 API 调用次数，继而产生更多的费用。这也是咱们不做物理切片的起因之一。
DataLoad 的设计
从利用场景角度剖析，企业须要数据云端互通，咱们以两个典型场景为例：
第一个场景是，企业在 S3 上有一批数据，然而当初须要放在 YRCloudFile 上进行训练，并通过内置的 DataLoad 性能关联 S3 bucket，使数据间接关联到本地。
在这个场景下，咱们须要去思考，数据在关联的过程中，是否须要加载到 YRCloudFile 里，如果它不加载会呈现什么状况。另外，如果要加载的话，咱们是须要采纳同步加载，还是异步加载呢？在不同的状况下，咱们都会有相应的一个机制。
第二个场景是异地数据应用。以某家企业为例，公司总部在北京，他有一批数据须要传递到上海，通过 DataLoad 性能，他能够把北京的数据关联到 S3 上，让上海分公司能够间接拜访。
为了满足上述两个场景需要，YRCloudFile DataLoad 性能应运而生，帮忙企业实现一键同步数据，并能够间接用于计算，这对企业来说是十分敌对的。
DataLoad 具体是如何设计的呢？实际上，它的设计和 Tiering 是十分相似的，次要是场景有所不同。实际上 DataLoad 的实现简直是能残缺复用 Tiering 的实现。
我认为其中最次要的一个起因是咱们 Tiering 没有做物理切片。在不做物理切片的状况下，咱们能够间接把 5GB 的数据文件关联到 YRCloudFile，S3 对象和 YRCloudFile 文件很直观地一一对应起来，这人造满足了 DataLoad 性能的用户需要和设计需要。而在做物理切片的状况下，一个 5GB 的对象须要先切成很多小块，而后能力再写回对象存储里。
用户通过 YRCloudFile DataLoad 性能，将 S3 上的数据间接关联为 YRCloudFile 文件系统中的目录和文件，间接满足用户利用 S3 上已知数据的计算需要。
比方用户在 S3 bucket 中已有 100 万个 object，当初要应用 YRCloudFile DataLoad 的话 S3 和文件系统的连贯。DataLoad 会主动扫描 S3 bucket，依据 S3 object 的门路，在 YRCloudFile 中创立出对应的目录和文件，而后用户业务就能够像应用本地文件一样，应用这些 DataLoad 关联下来的 S3 数据集。
咱们在实现 DataLoad 时，也做了充沛的性能思考。比方 DataLoad 在创建对象和文件的关联时，咱们将其分为不同的阶段，比方扫描 S3 bucket 阶段、创立文件阶段、数据拉取阶段等，每个阶段都反对配置不同的策略，比方扫描 bucket 时，能够通过设置 pattern 去过滤须要的数据。比方在数据拉取时，咱们默认配置为异步地、按需地拉取。
另外，用户在应用 DataLoad 时，除了一开始建设起对象和文件的关联后，用户可能还须要实时感知 S3 bucket 中对象的变动，比方对象的新增和删除等。YRCloudFile DataLoad 实现了订阅机制，并适配了阿里云、腾讯云等各种云产商各异的订阅告诉机制，对用户提供统一的订阅性能体验。
总结
用户在解决非结构化数据过程的实际中，既须要利用文件存储的性能，又须要对象存储的老本和容量劣势，咱们明天探讨了 YRCloudFile Tiering 和 DataLoad 是如何满足用户业务需要的，咱们探讨了 Tieiring 和 DataLoad 产品设计和技术计划的要害思路的。心愿能给大家带来一些启发和帮忙。最初，期待下次与大家有更多的技术交换。
