感谢 phylips@bmy 的辛勤工作！
Case Study GFS：Evolution on Fast-forward(译)
译者：phylips@bmy 2011-8
在Google的早期开发阶段，最初的想法并没有包含一个构建新的文件系统的计划。工作依然是通过公司最早版本的爬虫和索引系统来完成，但是，事情对于核心工程师们很快变得明朗起来，除了构建一个新的系统外他们别无选择，于是GFS(Google File System)就诞生了。
首先，由于Google的目标是要通过使用很多廉价的商品化硬件来构建一个大规模存储网络。因此它必须要假设组件失败是一种常态—这就意味着常规性的监控，错误检测，容错，自动恢复必须作为系统内完整的一部分。而且，即使是Google最早期的一些估算，该文件系统的吞吐率需求在任何人看来都是非常可观的—处理multi-gigabyte级别的文件，数据集可能包含数TB的数据及数百万个对象。很明显，这意味着必须要重新审视关于IO操作及块大小的传统假设。同时还需要关注可扩展性。这肯定是一个需要全然不同的扩展性的文件系统。当然，在早期的那些日子里，没有人能说出到底需要什么样的扩展性。但是很快他们就会明白。
虽然已过了近十年，但是Google那令人叹为观止的数据存储以及不断增长的应用仍然是建立在GFS之上。在这个过程中，该文件系统进行过很多变更—同时那些使用GFS的应用程序也不断进行着各种改变—这使得一切成为可能。
为了探索某些关键的初始设计决定以及从那时起所进行的一些改进的缘由，ACM邀请了Sean QUINLAN来揭开那些处于不断变更中的文件系统需求以及那些不断演化的思想的神秘面纱。在很多年中，Sean QUINLAN一直是GFS的技术领导人，目前已是Google的首席工程师，因此他是一个引导我们透视GFS的不二人选。为避免局限于Google的视野，ACM又邀请了Kirk MCKUSICK来推动这个讨论。他因为在BSD Unix上的工作，包括Berkeley FFS(Fast File System)的原始设计而为人熟知。
这个讨论以初始GFS实现中的单master设计决定作为开端。乍看，单个的中央Master会成为带宽瓶颈—或者，更糟的是可能产生单点失败—但是实际上呢，对于这个决定，Google的工程师们有他们自己的设计考虑。
MCKUSICK： 原始的GFS架构中有一个很有趣也很重要的设计决定就是基于一个单master。能否解释一下是什么原因导致了这个决定？
QUINLAN： 采用单master的决定实际上是最初的几个决定中的一个，最主要的是为了简化总体的设计。也就是说，直接建立一个分布式的master当时看来很困难而且会花太多时间。而且，通过这种单master策略，工程师也可以简化很多问题。这就有一个中央位置可以用来控制relication，垃圾回收和很多其他行为，这比在一个分布式的环境上更简单。因此，最后决定将这些集中到一台机器上。
MCKUSICK： 那是不是主要是因为这样就可以在一个尽量短的时间内解决很多问题。
QUINLAN： 是的。曾经参与GFS的一些工程师后来继续去实现BigTable，一个分布式的存储系统，这个系统就花了好多年。这种将最初的GFS建立在单master上的决定大大加快了其实现进度。
而且，考察了面临的使用场景之后，当时看起来单master的设计也不会引起大的问题。当时所考虑的规模大概是在数百TB数据以及数百万文件数。事实上，这个系统一开始工作的很好。
MCKUSICK： 但是，之后呢？
QUINLAN： 随着底层存储大小的增长，一些问题开始暴露出来。当从数百TB上升到PB级别，再到数10PB……这会导致master需要维护的元数据数量产生了相应规模的增长。而且，那些扫描元数据的操作也是随数据量线性增长的。这种需要master所做的工作大幅增长，所需要存储的数据量也随之增长。
另外，这对于客户端也会是一个瓶颈，即使客户端本身只产生很少的元数据操作—比如，客户端进行一个open操作时会与master通信。当有成千上万个客户端同时与master通信时，假设master每秒只能处理几千个操作，那么客户端就不能在一秒内产生这么多请求。而且需要注意的是有很多像MapReduce这样的应用程序，可能有上千个task，每个都可能打开一些文件。很明显，master需要花很长时间去处理这些请求，会承受很大的压力。
MCKUSICK： 现在，在当前的GFS模式里，一个GFS cell有一个master，对吗？
QUINLAN：是的。
MCKUSICK： 历史上，你们曾经是一个数据中心一个GFS cell，是吗？
QUINLAN： 那是最初的目标，但是那样无法进行更大的扩展—一部分是由于受单master设计的限制，一部分原因是因为在一个cell里很难做到隔离性。结果，最终每个数据中心都不止一个cell。而且后来我们也采用了一个称为”multi-cell”的策略，主要是可以把多个GFS master建立在一堆的chunkserver机器池上。通过这种方式，chunkserver机器集可以配置成多个master，比如说安排给它们8个GFS master。这样应用程序负责在不同的cell间划分数据。
MCKUSICK： 这样看来，每个程序就可以有自己的master来管理它自己的小文件系统。是这样的吗？
QUINLAN： 好吧，有对也有错。应用程序倾向于使用一个master或者一小集master。我们也提供称为名字空间的东西，它是一种静态划分名字空间的方式，人们可以用它将这些事情与实际应用程序透明。以日志处理系统为例：一旦日志超过了一个cell的存储能力，它们就会移到多个GFS cell；一个名字空间文件描述了日志如何在这些不同的cell间划分，主要让这些具体的划分与应用程序透明。但是，这都是完全静态的。
MCKUSICK： 整体来看，性能如何？
QUINLAN： 我们没有投入很多精力在优化master的性能上。在Google，很少将精力投入到对某个特殊的二进制执行程序的优化上。通常来说，我们只是让一切可以工作后，然后关注可扩展性—只要通过扩展某些东西就可以让性能得到提高。因为在这个问题中，我们有一个中央瓶颈可能会影响到很多操作，但是我们认为通过增加一些额外的努力让master变得更轻量级是更值得的事情。在将规模从数千操作扩展到数万的级别，单master还未成为瓶颈。当然在二进制程序上进行更多的优化肯定比不去做优化，更能让GFS走的更长久一些。
可以说让GFS在很短的时间内投入到产品级的应用中，为它的成功做出了贡献，同时也加速了Google走向市场的速度，最终可能导致了公司的成功。一个三人的团队负责所有的事情， 包括GFS核心，使系统可以在一年内为部署做好准备。
但是所有成功的系统都会碰到一个问题—规模和应用总是以超过任何人可以想象的速度进行扩展。在Google，这种情况则更加明显。
尽管各大公司组织没有就文件系统统计信息进行过交换共享，可以说GFS是世界上运行中的最大的文件系统。因此，即使原始的GFS架构已经提供了数倍的扩展能力，但是Google还是很快就超过了它。
另外，GFS所需要支持的应用程序数据也在急剧增长。在对原始GFS的架构者Howard Gobioff的一次采访中，他提到”我们最早的GFS版本用户主要是为爬虫和索引系统。当质量保证团队和研究团队开始大量使用GFS的时候我们迎来了第二个高峰—而且他们都是用GFS来存储大的数据，很快我们就有了50个用户，他们随时都需要技术支持”。
令人吃惊的是Google不仅构建了这样一个文件系统，而且所有的应用程序都运行在它之上。需要对GFS进行持续调整以更好的适应新的使用场景，同时应用程序本身的也在伴随着GFS的优势和缺点不断演进。”因为一切都是我们构建的，因此我们可以做任何我们想做的”，Gobioff一针见血的指出。”我们可以将问题在应用程序与文件系统之间来回考量，最后决定在哪块进行调整”。
关于规模的问题，需要一些更实质性的调整。一种上层的解决策略是使用多个跨网络的cells，它们在功能上相关但是是不同的文件系统。除了有助于解决这种扩展性问题，这对于很多来自分散的数据中心的操作也是一种有效的安排。
快速的增长也会对初始的GFS设计的另一个关键参数造成压力：选择64MB作为标准chunk大小。当然，这比普通的文件系统块大小要大很多，但是这是因为由Google的爬虫和索引系统生成的文件本身很大。但是伴随着应用程序的多样性，必须找到一种方式让系统可以高效地处理那些大量远小于64MB的文件(比如Gmail中的文件)。文件数本身不是太大的问题，但是所有的文件在中央的master节点上都有一个内存需求，因此这也将原始GFS设计的固有风险暴露出来。
MCKUSICK： 从最初的GFS论文上，可以看出文件数一直是一个关键的问题。能否深入讲一下？
QUINLAN： 文件数问题很早就碰到了。举一个具体的例子，在我在Google的早期，设计过一个日志处理系统。最初设计的模型里，前端服务器会写log，我们之后为处理和归档的需要，简单地将它拷贝到GFS上。一开始工作的很好，但是随着前端服务器的增加，每个每天都在产生日志。同时，日志的类型也在不断增加，还有前端服务器可能会陷入crash循环，这会产生更多的日志。这使得我们面对的日志规模远远超出了我们最初的估计。这成为我们必须要关注的问题。最后，我们不得不承认没有办法去应对这样的文件数增长规模。
MCKUSICK： 不知道我理解的是否正确：你们关于文件数增长带来的问题是因为你们需要在master端为每个文件保存一些元数据，而这些元数据必须能够放入master的内存。
QUINLAN： 对，是这样的。
MCKUSICK： 那么这就只能容纳不能让master内存耗尽的有限数目的文件了？
QUINLAN： 对。有两种元数据。一个用于标识文件，另一个用于组成文件的那些chunks。如果你有一个只有1MB的chunk，虽然它只占了1MB的磁盘空间，但是它仍然需要这两类放在master上的元数据。如果你的平均文件大小小于64MB，那么你能存储下的对象数就会降低。这就成了问题。
回到前面的日志系统的例子，情况很快就很清楚了，我们考虑的这种自然性的映射根本是行不通的。我们需要找到一种方式来绕过这个问题，通过将一些底层对象合并成大文件的方式。在日志系统的这个例子里，虽然它不像造一个火箭那样复杂，但是还是需要付出一些努力。
MCKUSICK： 这听起来有些像在旧时代里，IBM因为具有磁盘分配上的限制，因此就提供给用户一个工具，可以将一系列文件放在一块，然后为它生成一个内容表格。
QUINLAN： 是的。对于我们来说，每个应用程序都需要或多或少的这样去做。在某些应用程序里这可能很简单。对于其他的一些应用程序，文件数问题可能更急切。大多数情况下，对于这种应用程序最简单的解决方案就是不要使用GFS—即使最初看来文件数规模是可以接受的，但是它很快会成为一个问题。在我们开始使用更多的共享cells的时候，我们开始在文件数和存储空间上设置quota。目前为止，人们遇到的大部分限制都是因为文件数quota。与之相比，底层的存储quota很少成为一个问题。
MCKUSICK： 为了解决文件数问题，你们采取什么样的长期策略？很明显，如果master仍然需要把所有的元数据存放在内存，即使是采用分布式的master也无法解决这个问题。
QUINLAN： 分布式的master肯定会允许增加文件数，增加的数量与你想投入的机器数一致。这肯定是有帮助的。分布式多master模型有一个问题，如果你将所有的东西扩展两个数量级，然后文件平均大小降低到1-MB，这与64-MB的情况仍然是有很大的不同。在1MB的情况下，你会遇到很多需要关注的其他问题。比如如果你要读取10000个10-KB文件，比仅仅读100个1MB文件你需要进行更多的seek操作。
我的直觉是如果你的设计是面向平均1MB大小的文件，那么肯定需要提供比面向平均64MB大小的设计多得多的东西。
MCKUSICK： 那么你们做了哪些事情使得GFS可以在1MB文件的情况下工作？
QUINLAN： 我们并没有修改现有的GFS设计。我们的计划为1MB文件提供服务的分布式master系统将会是一个全新的设计。我们的目标是每个master可以处理100million级别的文件，可以有数百个master。
MCKUSICK：那么，每个master上面肯定不会有所有的数据吧？
QUINLAN： 正是如此。
随着Goolge Bigtable最近的出现，一个用于管理结构化数据的分布式存储系统，针对文件数问题的一个潜在解决方案—尽管可能不是最好的一个，但起码是可用的一个。
然而Bigtable的意义远远超过了文件数问题。尤其是，它是设计用于PB级别，跨越成千上万台机器，简化系统机器的添加以及不需要重配置就可以自动化利用这些资源。对于公司来说，使用集中电力，潜在的冗余，大规模部署商品化硬件带来的成本节省，这些都是非常明显的优势。
目前Bigtable已经用于很多Google应用程序。尽管它代表与过去的一种完全不同的系统，但是需要说明的是，Bigtable建立在、运行在GFS之上。而且很多方面的设计与大多数的GFS设计思想是一致的。这样看来，它也是使得GFS在快速和广泛的变化中继续保持活力的一种大的改进。
MCKUSICK： 你们现在已经有了Bigtable。在你的角度看是否会将它看做是一个应用程序呢？
QUINLAN： 从GFS的角度看，它的确是一个应用程序。但是很明显，它更是一种基础架构。
MCKUSICK： 不知这样的理解是否正确：Bigtable其实是一种轻量级的关系型数据库。
QUINLAN： 它并不是一个真正的关系数据库。我是说，我们没有提供SQL，实际上它也不支持像join这样的操作。Bigtable实际上是一个允许你维护大量key-value对及其schema的一个结构化的存储系统。
MCKUSICK： 实际中Bigtable的客户端都有哪些呢？
QUINLAN： Bigtable的使用还在增长中，目前它已用于爬虫和索引系统，同时还被很多client-facing的应用程序所使用。事实上，现在已经有成堆的Bigtable client。基本上，具有任何大量小数据项的app都倾向于使用Bigtable，尤其是在具有相当结构化的数据时。
MCKUSICK： 我想我这里真正想提的问题是：Bigtable是否单纯为了给应用程序提供一种处理小文件问题的尝试而提出的呢，主要方法就是通过将一堆小的东西聚合在一块？
QUINLAN： 这肯定可以算作Bigtable的一个应用场景，但是它实际上是为了解决更通用的一类问题。如果你以那种方式使用Bigtable—即，作为一种解决文件数问题的方式—那么你肯定不会充分利用Bigtable提供的功能。Bigtable实际上并不是解决这种问题的一个理想方案，因为它可能给你的操作引入很多额外资源开销。而且，它的垃圾回收策略也不是侵入性的，这就无法最有效的利用你的空间。我想说的是，那些使用Bigtable单纯来解决文件数问题的人们可能并不会感到高兴，但是毫无疑问这是解决这个问题的一个方式。
MCKUSICK： 根据我的了解，看起来这个想法只有两种基本的数据结构：logs 和SSTables(sorted string tables)。因此，我猜SSTables肯定是用来处理key-value对及排序的，这与Bigtable有何区别？
QUINLAN： 主要的区别是SSTables是不可变的，而Bigtable提供了可变的key value存储。Bigtable本身实际上是建立在logs 和SSTables之上。初始时，它会将输入数据存入一个事务日志文件，之后它会被compacted成一系列的SSTables，随着时间的进行SSTables也会被compacted。这让我想起了log-structure文件系统。不管怎样，如你所看到的，logs 和SSTables确实是我们对我们大部分数据进行结构化的底层数据结构。我们使用log文件记录变更操作。一旦到达一定数量，就可以对它们排序，把它们放入一个具有索引的结构里。
尽管GFS并没有提供一个Posix接口，它仍然有一个漂亮的通用文件系统接口，因此人们可以自由的存储他们喜欢的任意数据。只是，随着时间的推移，我们的大多数用户最后只需要使用这样两种数据结构。我们也有一个称为protocol buffer的东西，是我们的数据描述语言。在两种数据结构中的大部分的数据都会是protocol buffer的格式。
同时它也提供了压缩和checksums。即使有些人可能想重新实现这些东西，大部分的人只是直接使用这两个基本构建块有可以了。
因为GFS最初是为爬虫和索引系统设计的，吞吐率意味着一切。实际上，原始论文也明确指出了这一点。
但是Google也开发了很多面向用户的服务，对于它们来说，大部分都不符合上述情况。这使得GFS的单master设计的缺点更加迫切。一个单点失败对于面向批处理的应用来说可能不是一个灾难，但是对于延时敏感的应用来说肯定是不可忍受的，比如视频服务。即使后来增加了自动故障恢复的能力，但是服务仍可能长达1分钟的时间不可用。
当然这个对于GFS的挑战已经通过将延时敏感的应用程序建立在另一个设计在完全不同的优先级集合的文件系统上得到了解决。
MCKUSICK： 文档里说的很明确，GFS设计的最初的重点在批处理效率而不是低延迟。但是现在它已经引起了一些问题，尤其是在处理视频服务这样的东西时。你们是怎么解决这个问题的呢？
QUINLAN： GFS设计模型起初只是关注吞吐率，并没有关注应该达到怎样的延迟。举一个具体的例子，比如你准备写文件，它将会被写成一式三份的形式—意味着你实际上需要写到三个chunkserver上。如果其中一个死了或者很长时间内一直不稳定，GFS master会发现这个问题，并引发一个称为pullchunk的过程，它会再复制一份chunk出来。使得你能达到三个copy，之后系统才会将控制权交给客户端，然后继续写。
当我们执行一个pullchunk时，可能会限制在5-10MB/s的速度上。这样对于64MB，就可能需要花费10秒钟。还有很多其他的情况会花掉10秒钟到一分钟，这对于批处理类型没有问题。比如你正在进行一个MapReduce 任务，你会觉得对于一个几小时的任务来说，几分钟没什么影响。但是，如果你正在使用Gmail，然后你尝试写入一个代表用户行为的变更，然后被卡住了一分钟，这的确会很糟糕。
起初，GFS没有提供自动的故障恢复。都是一个手动的过程。尽管这不经常发生，但是一旦发生，这个GFS cell就可能down掉一个小时。尽管我们最初的master故障恢复可能需要分钟级的时间，经过这些年后，现在大概需要数十秒的级别。
MCKUSICK： 然而，对于面向用户的应用来说，这仍然是不可接受的。
QUINLAN： 是的。当我们提供了故障恢复和错误恢复后，对于批处理的情况可能可接受的了，但是站在面向用户的应用程序的角度看，这些仍然是不行的。这里存在的另一个问题是，我们为提高吞吐率所进行的优化，将数千个操作放到队列中一块处理。这提高了吞吐率，但是却不利于延迟。光在等待队列中的等待时间就可能达到数秒钟。
现在，我们的使用场景已经从基于MapReduce的世界更多的转移到依赖于诸如Bigtable这样的交互式世界中。Gmail是一个很明显的例子。视频的情况可能并不是那么糟糕，因为当你对数据进行流式传输的时候，意味着你可以进行缓冲。但是将一个交互式数据库建立在一个起初用于面向批处理操作的文件系统上，本身是一件很痛苦的事情。
MCKUSICK： 你们又是怎样处理这些情况的呢？
QUINLAN： 在GFS内部，我们会进行一定程度的改进，但主要是通过设计应用程序来处理遇到的问题。以Bigtable为例，Bigtable的事务日志实际上是将事务日志化的最大瓶颈，我们通过打开两个文件进行日志写入，之后再归并它们来解决这个问题。我们倾向于设计具有类似功能的应用程序—让它们自己来隐藏延迟问题，因为系统底层并不擅长处理这种问题。
Gmail的开发者们使用了一个多宿主模型，当你的Gamil账号所做的其中一个实例挂掉了，可以简单地通过转到另一个数据中心解决这个问题。实际上，这主要是用来保证可用性，其中一部分的原因也是为了隐藏GFS的问题。
MCKUSICK： 我觉得，通过使用一个分布式master文件系统，一定可以解决其中某些延迟问题。
QUINLAN： 这的确是我们的一个设计目标。而且，Bigtable本身是一个失败感知迅速的系统，能够对失败迅速作出反应。使用它作为我们的元数据存储系统可以帮助解决一些延时问题。
GFS做出了很多与原始文件系统不同的设计选择。对于一致性所采用的策略是其中非常明显的一个。GFS的工程师团队选择了一个与传统文件系统相比，相对松的一致性保证。因为GFS主要是作为一个append-only系统使用，而不是一个overwriting系统。
MCKUSICK： 我们来讨论下一致性吧。问题看起来好像是，要让所有的东西全部写入到所有副本想必要花大量的时间。我想在继续之前，你先说一下关于GFS必须要确保所有的都已经全部被写入后才能继续进行，这一点所带来的影响吧。
QUINLAN： 是的。
MCKUSICK： 如果这样的话，你们是怎么处理不一致的情况呢？
QUINLAN： 客户端失败可能会把事情搞地很糟糕。基本上，GFS的模型里，客户端仅仅是不断的推送写操作直到它成功为止。如果客户端在操作中crash掉，就会留下一些不确定的状态。
最初，这被认为是没有问题的，但是随着时间的推移，我们不断的压缩不一致性可以被容忍的窗口，然后不断的去降低这种不一致。只要数据处于不一致的状态，你都可能得到同一个文件的不同大小。这会导致一些问题。我们不得不在这些情况下提供一些检查文件数据一致性的接口。我们还有一个称为RecordAppend的东西，是设计用来允许多个writer并发向一个文件append的。在这里，一致性设计的很松。现在看来，这带来了比我们想象的多的痛苦。
MCKUSICK： 为什么是loose的呢？如果主副本为每次写操作选择好在哪个offset开始写，然后保证这一定会发生，不太清楚不一致性是如何产生的。
QUINLAN： 当主副本重试时就会产生。它会选择一个offset，也会执行写操作，但是其中的某个写操作可能不会被实际写入。这样这个主副本就可能已经变化了，此时它可能会选出一个不同的offset。RecordAppend也不提供任何replay保护。在一个文件里你可能得到某个数据多次。
甚至还有些情况，你可能会以不同的顺序得到数据。比如数据可能在某个chunk副本中重复出现了多次，但是其他的副本里可能没有。如果你正在读取文件，那么读取多次就可能以多种方式得到数据。在记录级别上，你读到的记录顺序依赖于你刚好读取到哪个chunk 副本。
MCKUSICK： 这是by design的吗？
QUINLAN： 当时看起来这是个好主意。但是现在看来，我认为这种一致性带来的痛苦也比它带来的好处要多。这与人们关于文件系统的期望不同，通常会让人感到很吃惊。
MCKUSICK： 现在看的话，怎么处理这种不同？
QUINLAN： 我认为让一个文件只有一个写者会更有意义。
MCKUSICK： 恩，但是当有多个人想append某个日志时该怎么办呢？
QUINLAN： 可以用一个进程将这些写操作进行串行化，来保证各副本的一致性。
MCKUSICK： 而且当你想对一个chunk进行snapshot的时候也会有这个问题。另外，还有一些情况比如你有时想替换一个副本，或者当chunkserver down掉的时候，需要替换它的文件。
QUINLAN： 事实上，这里有两种情况。第一个，如你所说，是恢复机制，肯定会引入关于文件副本的拷贝。在GFS里使用的方式是，我们撤销它上面的锁这样客户端就不能再去写它，当然这会引起一些延迟方面的问题。
还有另一个问题，是为了支持GFS的snapshot。GFS具有你所能想象的最通用的snapshot能力。你可以对任何目录进行snapshot，同时与生成的拷贝是完全等价的。它们会共享未更新的数据。因此与大多数人关于snapshot的想法相比，它更多的是clone的概念。它很有趣，但是也带来了一些困难—尤其是当你试图创建更多的分布式系统以及文件树的更大的chunks进行snapshot时。
我觉得有趣的是snapshot也很少被用到尽管它是一个很强大的feature。从文件系统的角度看，它实际上提供了一种很漂亮的功能，但是将snapshot引入文件系统，我想你也知道，实际上是很痛苦的。
MCKUSICK： 我知道，我也这样做过。的确是让人难以忍受的—尤其是在一个overwriting系统中。
QUINLAN： 是啊。无法否认的是，以实现的角度看，很难去创建真正的snapshot。然而，看起来在这种情况下，尽力而为是一个正确的决定。同样地，它也是一个与我们早期所做的其他决定有趣的对比。
不管怎样，即使是在近十年后，这个关于GFS的报告看起来依然是很有意义的。虽然存在一些问题和缺点，但是毫无疑问的是GFS在Google的成功中起到了重要作用。但是，GFS目前也面临着很多挑战。比如，在一个初始设计于批处理系统吞吐率的系统基础之上，去支持日益增长的面向用户的延时敏感的应用，其中的尴尬和问题也是很明显的。Bigtable的出现对此提供了一些帮助。然而，实际上Bigtable也并没有解决DFS的所有问题。它只是减轻了系统的单master设计的瓶颈限制。因为这样那样的原因，Google的工程师在过去的两年中一直在为实现一个新的分布式文件系统而努力，通过它来充分利用Bigtable的优势，去解决那些对于GFS来说很难解决的问题。
现在看来，为了保证GFS持续提供服务，在未来的时间里它将会依旧持续地演化。