共计 7113 个字符，预计需要花费 18 分钟才能阅读完成。
Hadoop 的诞生扭转了企业对数据的存储、解决和剖析的过程，减速了大数据的倒退，受到宽泛的利用，给整个行业带来了改革意义的扭转；随着云计算时代的到来，存算拆散的架构受到青眼，企业开开始对 Hadoop 的架构进行革新。
明天与大家一起简略回顾 Hadoop 架构以及目前市面上不同的存算拆散的架构计划，他们的利弊各有哪些，心愿能够给正在存算拆散架构革新的企业一些参考和启发。
Hadoop 存算耦合架构回顾
2006 年 Hadoop 刚公布，这是一个 all-in-one 的套装，最早有三个外围的组件：MapReduce 负责计算，YARN 负责资源调度，HDFS 分布式文件系统，负责存数据。
在这三个组件中，倒退最迅速和多元的是计算组件这一层，最早只有一个 MapReduce，但业界很快在计算层下面各显神通，造出了一大堆的轮子，包含有 MapReduce，Tez，Spark 这样的计算框架，Hive 这类数据仓库，还有 Presto、Impala 查问引擎，各种各样的组件。配合这些组件的，还有像 scoop 这样的数据流转采集的组件也很丰盛，一共有几十款。
底层存储通过了大略 10 年左右的工夫，始终是 HDFS 一枝独秀，带来的一个后果就是它会成为所有计算组件默认的设计抉择。下面提到的这些大数据生态里倒退进去的各种组件，都是面向 HDFS API 去做设计的。有些组件也会十分深刻的利用 HDFS 的一些能力，比方深刻看 Hbase，在写 WAL log 的时候就间接利用了 HDFS 的一些很内核的能力，能力达到一个低时延的写入；比如说像最早的 MapReduce 和 Spark 也提供了数据亲和性（Data Locality）的能力，这些都是 HDFS 提供的一些非凡的 API。
这些大数据组件面向 HDFS API 设计的做法，为后续数据平台上云带来了潜在的挑战。
上面是一个简化的部分的架构图，通过这张图疾速了解 Hadoop 存算耦合架构。在这张图有三个节点，每个节点外面它都承载了 HDFS DataNode 的存数据的角色，但同时 YARN 也会在这里布一个 Node Manager 的过程。有了 Node Manager 之后，YARN 就会认为 HDFS DataNode 的节点，在其治理范畴之内，当须要计算工作能够散发到这个节点上来实现。存储工作和数据就在同一个机器里了，计算的时候就能够间接读到磁盘上的数据。
为什么 Hadoop 在设计之初是一个存储计算耦合的架构？
一个不能疏忽的重要的起因是，网络通讯和硬件的局限。2006 年，过后云计算简直还没有倒退，亚马逊才公布第一个服务而已。
在机房外面，过后咱们面对的最大的问题就是网卡，支流的还是百兆网卡，刚开始用千兆网卡。这个时候，大数据应用的磁盘，吞吐大略是 50MB/s，对网络带宽来说要乘以 8，也就是 400M bps；如果一个节点里放 8 块盘，吞吐都跑起来，就须要几千兆带宽传输了，然而网卡最高也就 1Gb。这就意味着每一个节点网络带宽基本不够，无奈让这个节点外面的所有的磁盘的能力都施展进去。所以如果计算工作在网络的一端，数据在数据节点在网络的另一端，计算工作须要说通过网络传输来进行，网络带宽是一个最显著的瓶颈。
存算拆散的需要呈现
首先从，企业的需要看，从 2006 年倒退到 2016 年左右，这十年咱们看到了一些新的变动，第一企业数据增长很快，然而算力的需要其实长得没那么快。这些工作靠人开发，不会产生一天一倍的去涨的状况，然而产生的数据的速度是是十分快的，有可能是指数型的；而且有些数据产生进去，也不肯定马上晓得怎么用，但将来会用，所以企业都会先把数据尽可能全量的去存起来，再去开掘它的价值。
在这个背景下，存算耦合的硬件的拓扑的架构就给扩容带来了一个影响，当存储不够，就要去加机器。然而不能只加机器，不能只有硬盘，因为在存算耦合的架构上，数据的节点还须要负责计算，所以 CPU 和内存也不能太差。因而配置的机器都是计算与存储配置十分均衡的机器，在提供足够存储容量的同时，也提供了等量的算力。但理论场景中算力的需要没涨。这样扩进去的算力对企业来说造成了更大的节约，整个集群在存储和 I/O 上的资源利用率可能是十分不均衡的，当集群越大，这种不均衡就越重大。而且另外买机器也挺难的，购买的机器必须是计算与存储均衡的。
而且，数据调度亲和性的策略在理论的业务中未必能发挥作用，因为数据有可能会有很显著的歪斜，可能会有很部分的热点，须要十分多的算力。大数据平台的工作可能调度到无限节点上，I/O 依然有可能成为瓶颈。
在这个过程中硬件也有变动，给存算拆散架构带来了可行性。首先，10Gb 万兆网卡遍及了，明天机房里或者包含云上也开始有更多的 20Gb、40Gb，甚至 50Gb，有些 AI 的场景甚至有 100Gb 的网卡，网络的带宽其实加大了比以前晋升了 100 倍之多。
存储方面，在明天大的数据集群外面，许多企业还是应用磁盘来存储，磁盘的吞吐晋升了一倍，从 50MB/s 每秒晋升到 100MB/s。一个配置了万兆的网卡的实例，能够反对差不多 12 块磁盘的峰值吞吐，对于大部分企业来说曾经够用了，以前网络传输的瓶颈就根本不存在了。
不仅网卡，磁盘也在变动，软件也在变动。最早的时候，咱们可能用 csv 或者打一个 zip 包，当初有了更高效的压缩算法，比如说有 snappy、lz4、zstandard 这些。而且有了 Avro、Parquet、Orc 这些列存格局。
这些变动加在一起，都进一步减小了须要传输的数据量。同时，网卡在晋升，再加上硬硬盘自身的吞吐没减少多少，企业以前已经要面对的 I/O 的瓶颈就逐步的在弱化甚至打消，保障了存算拆散的可行性。
如何实现存算拆散？
最后的尝试：在云上独立部署 HDFS
从 2013、2014 年，行业内开始看到一些存算拆散架构的尝试。最后的计划比较简单，就是独立部署 HDFS，不再和负责计算 worker 去混合部署。这个计划在 Hadoop 生态里，没有引入任何的新组件。
从上面的示意图能够看到，DataNode 节点上不再部署 Node Manager，意味着不再把计算工作发送到 DataNode 节点上。存储成为一个独立集群，计算须要用到的数据都会通过网络来传输，端到端的万兆网卡去反对，网络传输线没有在下图标出。
在这个扭转里，只管 HDFS 最奇妙的数据本地性这个设计被舍弃了，但因为网络通讯速度的进步，给集群的配置带来更大的便当。Juicedata 创始人 Davies，2013 年在 Facebook 工作期间，团队就做了这样的试验，发现这样的一个存算拆散的革新，对整个平台性能的影响是仅仅是几个百分点，然而给集群的配置管理带来了一个还很大的便当，能够独立的部署和治理计算节点了。
然而这个尝试没有失去进一步倒退，是什么起因呢？最大的一个起因，当在机房做这样的革新是可行的，但 当咱们去应用云上资源的时候，这个计划的弊病就露出了。
首先，源自 HDFS 的多正本机制在云上会减少企业的老本。过来，企业在机房应用裸硬盘去搭建一套 HDFS，为了解决裸硬损坏的危险，HDFS 设计了多正本的机制，来保证数据安全性；同时多正本还承载着保证数据可用性的作用。除了磁盘损坏，当某一个 DataNode 的节点长期宕机了，这个节点上的数据拜访不到了？多正本机制在可靠性和可用性上都发挥作用。当数据被迁徙到云上时，云提供给用户的是通过多正本机制存储的云盘，不再是裸硬盘了，企业用这块云盘去搭一个 HDFS，又要做 3 正本，企业数据在云上要存 9 正本，老本立马飙升了好几倍。
起初，云也会提供一些有裸硬盘的机型，然而这类机型往往都非常少，比如说云上有 100 款虚拟机，云盘能够任意配置，然而有裸盘的机型只有 5~10 款，抉择余地比拟少，这些型号不肯定能匹配企业的集群须要。
第二个起因，这个计划不能让企业失去云上的独特价值，比方开箱即用，弹性伸缩，以及按量付费这些云上最大的劣势。在云上部署 HDFS，须要本人创立机器，手动部署和保护，本人监控和运维，而且还不能不便地扩缩容。这种状况下，HDFS 上云实现存算拆散，依然有其痛点。
第三个起因，HDFS 自身的局限。首先是，NameNode，只能垂直扩大，并不能分布式扩大说扩出更多的 NameNode 节点，限度了 HDFS 单集群去治理的文件数量。
当 NameNode 的资源占用比拟多，负载又高的时候就有可能会触发 FullGC（Garbage Collection)。一旦触发这个问题之后，它会影响到整个 HDFS 集群可用性。零碎存储可能宕机，不能读，又无奈干涉 GC 的过程，零碎卡多久无奈确定。这个也是 HDFS 高负载集群始终以来的痛点。
依据理论运维教训，个别在 3 亿文件以内，运维 HDFS 还是比拟轻松的，3 亿文件之后运维的复杂度就会显著晋升，峰值可能就在 5 亿文件左右，就达到单机群的天花板了。文件量更多，须要引入 HDFS 的 Federation 联邦的机制，然而它就减少了很多的运维和治理的老本。
私有云 + 对象存储
随着云计算技术的成熟，企业存储又多了一个选项，对象存储。不同的云厂商有不同的英文缩写名，例如阿里云的对象存储服务叫做 OSS，华为云 OBS，腾讯云 COS，七牛 Kodo；对象存储实用于大规模存储非结构化数据的数据存储架构，其设计的初衷是想满足非常简单的上传下载数据，企业存储系统领有超级弱小的弹性伸缩的能力，还能保障低成本的存储。
最早从 AWS 开始，起初所有的云厂商其实都在往这个方向倒退，开始推动用对象存储去代替 HDFS。这些计划首先带来了两个 HDFS 无奈实现的最显著的益处：
- 第一，对象存储是服务化的，开箱即用，不必做任何的部署监控运维这些工作，特地省事儿。
- 第二，弹性伸缩，企业能够按量付费，不必思考任何的容量布局，开一个对象存储的 bucket，有多少数据写多少数据，不必放心写满。
这些计划相比在云上独立部署 HDFS，运维方面是有了很大的简化。但当对象存储被用来去反对简单的 Hadoop 这样的数据系统，就会发现如下的一些问题。
- 文件 Listing 的性能比拟弱。Listing 是文件系统中最根底的一个操作。咱们在文件系统中 List 目录，包含 HDFS 外面 List 目录，都是十分轻量快的操作。它的性能是源于在文件系统中，数据是一个树形构造。
对象存储没有树形构造的，它的整个存储构造是扁平的。当用户须要存储成千上万，甚至数亿个对象，对象存储须要做的是用 Key 去建设一份索引，Key 能够了解为文件名是该对象惟一标识符。如果用户要执行 Listing，只能在这个索引外面去搜寻，搜寻的性能相比树形构造的查找弱很多。
- 对象存储没有原子 Rename，影响工作的稳定性和性能。在 ETL 的计算模型中，每个子工作实现会将后果写入长期目录，等到整个工作实现后，把长期目录改名为正式目录名即可。
这样的改名操作在 HDFS 和其余文件系统中是原子的，速度快，而且有事务性保障。但因为对象存储没有原生目录构造，解决 rename 操作是一个模仿过程，会蕴含大量零碎外部的数据拷贝，会耗时很多，而且没有事务保障。
用户在应用对象存储时，罕用文件系统中的门路写法作为对象的 Key，比方“/order/2-22/8/10/detail”。改名操作时，须要搜寻出所有 Key 中蕴含目录名的对象，用新的目录名作为 Key 复制所有的对象，此时会产生数据拷贝，性能会比文件系统差很多，可能慢一两个数量级，而且这个过程因为没有事务保障，所以过程中有失败的危险，造成数据不正确。这样看起来很细节的差别对整个工作 pipeline 的性能和稳定性都会有影响。
对象存储数据最终一致性的机制，会升高计算过程的稳定性和正确性。举个例子，比方多个客户端在一个门路下并发创立文件，这是调用 List API 失去的文件列表可能并不能蕴含所有创立好的文件列表，而是要等一段时间让对象存储的外部零碎实现数据一致性同步。这样的拜访模式在 ETL 数据处理中常常用到，最终一致性可能会影响到数据的正确性和工作的稳定性。
为了解决对象存储存在无奈放弃强数据一致性的问题。AWS 公布过一个名为 EMRFS 的产品。AWS EMRFS 的做法是，因为晓得 Listing 后果可能不对，所以另外筹备一个 DynamoDB 数据库，比方 Spark 在写文件的时候，同时也写一份文件列表到 DynameDB 里，再建设一个机制，一直调用对象存储的 List API，和数据库外面存下来的后果做比拟，直到相等了再返回。但这个机制的稳定性不好，它会受对象存储所在的区域的负载高下影响忽快忽慢，不是一个现实的解决形式。
除了上述因为文件系统和对象存储自身差别带来的问题外，在对象存储上应用 Hadoop 的另一大问题，就是对象存储对于 Hadoop 组件的兼容性绝对弱。在文章结尾 Hadoop 架构介绍中提到了 HDFS 是 Hadoop 生态晚期简直惟一的存储抉择，下层各种各样的组件都是面向 HDFS API 开发的。而到了对象存储上，数据存储的构造变了，API 也变了。
云厂商为了可能与现有的这些 Hadoop 组件适配，一方面须要去革新组件和云对象存储之间的 connector，另一方面还须要给下层的组件去打 patch，对于每一个组件都一一的去验证兼容性，这对私有云厂商来说意味着微小的工作量。所以，目前私有云它提供的大数据组件外面能蕴含的计算组件是有是无限的，个别只能蕴含 Spark、Hive、Presto 三个罕用组件，而且还只能蕴含少数几个版本。这样就会给将大数据平台迁徙上云，或者有须要应用本人的发行版和组件需要的用户带来了挑战。
企业如何可能享受到对象存储的弱小性能，同时又兼顾文件系统的准确性？
对象存储 + JuiceFS
当用户想在对象存储下来进行简单的数据计算、剖析训练这些场景的时候，对象存储的确无奈满足企业的需要；这也是咱们去做 JuiceFS 的一个出发点，心愿可能站在对象存储之下来补充他不善于的局部，与对象存储一起以比拟低廉的价格服务好密集性的数据计算、剖析、训练这些场景。
JuiceFS + 对象存储是如何工作的呢？通过下图 JuiceFS 在 Hadoop 集群中的部署形式，简略介绍原理。
从上面这个简略的示意图看到，YARN 治理的这些执行节点上，都带一个 JuiceFS Hadoop SDK，这个 SDK 能够保障残缺兼容 HDFS。图片下方能够看到，SDK 它须要拜访两个局部，左侧是 JuiceFS Meta Engine，右侧是 S3 bucket。Metadata engine 就相当于 HDFS 里的 NameNode，整个文件系统的元数据信息会存储在这里，元数据信息包含目录数、文件名，权限工夫戳这些信息，并且相应的解决掉了 HDFS NameNode 扩展性、GC 这些的痛点。
另外一边，数据存在 S3 bucket 外面，这里的 S3 bucket 等同于 HDFS 中的 DataNode，能够将它看成一大堆海量的磁盘来用，它会治理好的数据存储和正本的相干工作。JuiceFS 就是三个组件组成，JuiceFS Hadoop SDK，Metadata Engine 和 S3 Bucket。
相较于间接应用对象存储，JuiceFS 还有哪些劣势呢？
- HDFS 100% 残缺兼容。这得益于咱们最后残缺兼容 POSIX 的这个设计。POSIX API 的笼罩水平以及复杂程度是大于 HDFS 的，HDFS 在设计的时候就是去简化了 POSIX，因为最先去实现简单的 API 集，再去简化它就变得非常容易了，所以这也是 JuiceFS 能实现 100% 实现 HDFS 残缺兼容性的一个起因。
同时，用户能够和 HDFS 一起应用，无需齐全替换 HDFS。这也得益于 Hadoop 零碎的设计，在一个 Hadoop 集群里，能够配置多个文件系统，JuiceFS 和 HDFS 能够同时应用，并不是相互代替的关系，而是能够互相合作。这样的架构给咱们咱们现有的集群带来的益处是用户不必残缺代替现有的 HDFS 集群，残缺代替的工作量和危险上都太大了。用户能够联合着业务，联合着集群的状况，分步分批的去做交融。
- 元数据性能弱小，JuiceFS 将元数据引擎独立进去不再依赖于 S3 外面的原数据性能，保障了元数据的性能。应用 JuiceFS 的时候，对底层对象存储的调用简化到只是 get、put、delete 这三个最根底的操作，像 listing, update 等命令都用不到，在这样的架构下，用户就避开了对象存储元数据性能弱的问题，最终一致性这些问题也都不再存在了。
- 原子 rename, 因为有独立的原数据引擎，JuiceFS 也能够反对原子 rename。
- 缓存，无效晋升热数据的拜访性能，提供了 data locality 个性。缓存能够让热数据缓存到执行器 worker 节点本地的一些磁盘空间上。有了缓存后，会重复拜访的热数据，不须要每次都通过网络去对象存储外面读数据。而且 JuiceFS 特意实现了 HDFS 特有的数据本地性的 API，让所有反对数据本地性的下层组件都能从新取得数据亲和性的感知，这会让 YARN 把本人的工作优先调度到曾经建设缓存的节点下面，综合的性能能够和存储计算耦合的 HDFS 相当的。
- 兼容 POSIX，与机器学习、AI 相干的工作利用联合不便。JuiceFS 还兼容 POSIX，能够和机器学习，AI 相干的这些业务更便捷地交融。
小结
随同着企业需要的更迭、根底技术的倒退，存储和计算的架构在变，从最后的耦合到拆散；实现存算拆散形式多样，各有利弊，从间接将 HDFS 部署到云上，到应用私有云提供兼容 Hadoop 的计划，再到私有云 + JuiceFS 这样的适宜在云上进行简单大数据计算和存储的计划。对于企业来说，没有银弹，联合本身需要做架构选型才是要害。
但无论选什么，放弃简略都不会错。
如有帮忙的话欢送关注咱们我的项目 Juicedata/JuiceFS 哟！(0ᴗ0✿)
