共计 4063 个字符，预计需要花费 11 分钟才能阅读完成。
背景
HDFS 是 Hadoop 生态的默认存储系统，很多数据分析和管理工具都是基于它的 API 设计和实现的。但 HDFS 是为传统机房设计的，在云上保护 HDFS 一点也不轻松，须要投入不少人力进行监控、调优、扩容、故障复原等一系列事件，而且还费用昂扬，老本可能是对象存储是十倍以上。
在存储与计算拆散大趋势下，很多人尝试用对象存储来构建数据湖计划，对象存储也提供了用于 Hadoop 生态的 connector，但因为对象存储本身的局限性，性能和性能都十分无限，在数据增长到肯定规模后这些问题更加突出。
JuiceFS 正是为了解决这些问题而设计的，在保留对象存储的云原生特点的同时，更好地兼容 HDFS 的语义和性能，显著晋升整体性能。本文以阿里云 OSS 为例，给大家介绍一下 JuiceFS 是如何全面晋升对象存储在云上大数据场景中的体现的。
元数据性能
为了残缺兼容 HDFS 并提供极致的元数据性能，JuiceFS 应用全内存的形式来治理元数据，将 OSS 作为数据存储应用，所有的元数据操作都不须要拜访 OSS 以保障极致的性能和一致性。绝大部分元数据操作的响应工夫都在 1ms 以内，而 OSS 通常要几十到一百毫秒以上。上面是应用 NNBench 进行元数据压测的后果：
上图中的 rename 操作还只是针对单个文件的，因为它要拷贝数据所以很慢。在大数据理论的工作中通常是对目录做重命名，OSS 是 O(N) 复杂度，会随着目录里文件数量的增多显著变慢，而 JuiceFS 的 rename 的复杂度是 O(1) 的, 只是服务器端的一个原子操作，不论目录多大都能够始终这么快。
相似的还有 du 操作，它是要看一个目录里所有文件的总大小，在治理容量或者理解数据规模时十分有用。下图是对一个 100GB 数据（蕴含 3949 个子目录和文件）的目录做 du 的工夫比照，JuiceFS 比 OSS 快 76 倍！这是因为 JuiceFS 的 du 是基于服务器端内存中实时统计好的大小即时返回的，而 OSS 须要通过客户端遍历目录下的所有文件再累加求和，如果目录下的文件更多的话，性能差距会更大。
程序读写性能
大数据场景有很多原始数据是以文本格式存储的，数据以追加形式写入，读取以程序读为主（或者是程序读其中一个分块）。在拜访这类文件时，吞吐能力是一个要害指标。为了可能更好地反对这样的场景，JuiceFS 会先将它们切割成 64MB 的逻辑 Chunk，再宰割成 4MB（可配置）的数据块写入对象存储，这样能够并发读写多个数据块以晋升吞吐量。OSS 也反对分块上传，但有分块大小和分块数量的限度，而 JuiceFS 没有这些限度，单个文件可达 256PB。
同时，这类文本格式的文件还非常容易被压缩，JuiceFS 内置的 LZ4 或者 ZStandard 压缩算法能够在并行读写的同时进行压缩 / 解压缩，岂但能够升高存储老本，还能缩小网络流量，进一步晋升程序读写的性能。对于曾经被压缩过的数据，这两个算法也能自动识别，防止反复的压缩。
再联合 JuiceFS 的智能预读和回写算法，很容易充分利用网络带宽和多核 CPU 的能力，将文本文件的解决性能推向极致。下图是单线程程序 I/O 性能测试后果，显示了 JuiceFS 对大文件（应用不能被压缩的随机数据）的读写提速是十分显著的。
随机读性能
对于剖析型数仓，通常会将原始数据通过荡涤后应用更为高效的列存格局（Parquet 或者 ORC）来存储，一方面大幅节俭存储空间，还能显著晋升剖析的速度。这些列存格局的数据，在拜访模式上跟文本格式很不一样，以随机读居多，对存储系统的综合性能有更高的要求。
JuiceFS 针对这些列存格式文件的拜访特点做了很多优化，将数据分块缓存到计算节点的 SSD 盘上是其中最外围的一点。为了保障缓存数据的正确性，JuiceFS 对所有写入的数据都应用惟一的 ID 来标识 OSS 中的数据块，并且永不批改，这样缓存的数据就不须要生效，只在空间有余时依照 LRU 算法清理即可。Parquet 和 ORC 文件通常只有部分列是热点，缓存整个文件或者一个 64MB 的 Chunk 会节约空间，JuiceFS 采取的是以 1MB 分块（可配置）为单位的缓存机制。
计算集群中通常只会有一个缓存正本，通过一致性哈希算法来决定缓存的地位，并利用调度框架的本地优化机制来将计算任务调度到有数据缓存的节点，达到跟 HDFS 的数据本地化一样甚至更好的成果，因为 HDFS 的三个正本通常是随机调度的，操作系统页缓存的利用率会比拟低，JuiceFS 的数据缓存会尽量调度到同一个节点，零碎页缓存的利用率会更高。
当调度零碎不能做本地化调度时，比方 SparkSQL 在读小文件时，会随机地把多个小文件合并到同一个工作中，就丢失了本地化个性，即便应用 HDFS 也是如此。JuiceFS 的分布式缓存很好地解决了这个问题，当计算工作未能调度到缓存所在节点时，JuiceFS 客户端会通过外部的 P2P 机制来拜访缓存的数据，大幅提高缓存命中率和性能。
咱们选取查问工夫比拟有代表性的 q2 来测试不同分块大小和缓存设置状况的减速成果：
当没有启用缓存时，应用 1MB 的分块比 4MB 的分块性能更好，因为 4MB 的分块会产生更多的读放大，导致随机读变慢，也会节约很多网络带宽导致网络拥挤。
启用缓存后，Spark 能够间接从缓存的数据块上做随机读，大大的进步了随机读性能。因为 SparkSQL 会将小文件随机合并到一个工作中，导致大部分文件没方法调度到有缓存的那个节点，缓存命中率很低，局部未命中缓存的读申请只能读对象存储，重大拖慢了整个工作。
在启用了分布式缓存后，不论计算任务调度到哪，JuiceFS 客户端都可能通过固定的节点读到缓存的速度，缓存命中率十分高，速度也十分快（通常第二次查问就能取得显著减速成果）。
JuiceFS 还反对随机写，但大数据场景不须要这个能力，OSS 也不反对，就不做比照了。
综合性能
TPC-DS 是大数据分析场景的典型测试集，咱们用它来测试一下 JuiceFS 对 OSS 的性能晋升成果，包含不同数据格式和不同剖析引擎。
测试环境
咱们在阿里云上应用 CDH 5.16（预计是应用最为宽泛的版本）搭建了一个集群，具体配置和软件版本如下：
Apache Spark 2.4.0.cloudera2
Apache Impala 2.12
Presto 0.234
OSS-Java-SDK 3.4.1
JuiceFS Hadoop SDK 0.6-beta
Master: 4 CPU 32G 内存，1 台
Slave: 4 CPU 16G 内存，200G 高效云盘 x 2，3 台
Spark 参数：master yarn
driver-memory 3g
executor-memory 9g
executor-cores 3
num-executors 3
spark.locality.wait 100
spark.dynamicAllocation.enabled false测试数据集应用 100GB 的 TPC-DS 数据集，多种存储格局和参数。残缺跑完 99 条测试语句须要太多工夫，咱们选取了后面 10 条语句作为代表，曾经包含各种类型的查问。
写入性能
通过读写同一张表来测试写入性能，应用的 SQL 语句是：
INSERT OVERWRITE store_sales SELECT * FROM store_sales;咱们比照了未分区的文本格式和按日期分区的 Parquet 格局，JuiceFS 都有显著性能晋升，尤其是分区的 Parquet 格局。通过剖析发现，OSS 花了很多工夫在 Rename 上，它须要拷贝数据，还不能并发，而 Rename 在 JuiceFS 里是一个原子操作，霎时实现。
SparkSQL 查问性能
Apache Spark 的应用十分宽泛，咱们应用 SparkSQL 来测试文本、Parquet 和 ORC 这 3 种文件格式下 JuiceFS 的提速成果，其中文本格式是未分区的，Parquet 和 ORC 格局是依照日期分区的。
对于未分区的文本格式，须要扫描全副文本数据，次要瓶颈在 CPU，JuiceFS 的提速成果无限，最高能晋升 3 倍。须要留神的是，如果应用 HTTPS 拜访 OSS，Java 的 TLS 库比 JuiceFS 应用的 Go 的 TLS 库慢很多，同时 JuiceFS 对数据做了压缩，网络流量也会小很多，因而在两者都启用 HTTPS 来拜访 OSS 时，JuiceFS 成果更好。
上图阐明了在应用 HTTPS 的状况下，JuiceFS 的性能简直没有变动，而 OSS 却降落很多。
对于交互式查问，常常要对热点数据做重复查问的，上图是同一个查问反复 3 次后的后果，JuiceFS 依附缓存的热点数据大幅晋升性能，10 个查问中的 8 个有几倍的性能晋升，晋升幅度起码的 q4 也晋升了 30%。
对 ORC 格局的数据集的提速成果跟 Parquet 格局相似，最高提速 11 倍，起码提速 40%。
对所有的数据格式，JuiceFS 都能显著晋升 OSS 的查问性能，最高超过 10 倍。
Impala 查问性能
Impala 是性能十分好的交互剖析引擎，对 I/O 本地化和 I/O 调度有十分好的优化，不须要应用 JuiceFS 的分布式缓存就可能取得很好的成果： 为 OSS 提速 42 倍！
Presto 是与 Impala 相似的查问引擎，但因为测试环境下配置的 OSS 不能跟 Presto 工作（起因未知），JuiceFS 没方法与 OSS 做比拟。
总结
汇总下面的测试后果，JuiceFS 在所有场景中都能为 OSS 显著提速，当存储格局为 Parquet 和 ORC 这类列存格局时提速尤为显著，写入晋升 8 倍，查问晋升可达 10 倍以上。这显著的性能晋升，岂但节俭了数据分析人员的宝贵时间，还能大幅缩小计算资源的应用，降低成本。
以上只是以阿里云的 OSS 为实例做了性能比照，JuiceFS 的提速能力实用于所有云的对象存储，包含亚马逊的 S3、谷歌云的 GCS、腾讯云的 COS 等，也包含各种公有云或者自研的对象存储，JuiceFS 能显著晋升它们在数据湖场景下的性能。此外，JuiceFS 还提供了更好的 Hadoop 兼容性（比方权限管制、快照等）和残缺的 POSIX 拜访能力，是云上数据湖的现实抉择。
如有帮忙的话欢送关注咱们我的项目 Juicedata/JuiceFS 哟！(0ᴗ0✿)