共计 2792 个字符，预计需要花费 7 分钟才能阅读完成。
作者简介
- 王振华，趣头条大数据总监，趣头条大数据负责人。
- 王海胜，趣头条大数据工程师，10 年互联网工作教训，曾在 eBay、唯品会等公司从事大数据开发相干工作，有丰盛的大数据落地教训。
- 高昌健，Juicedata 解决方案架构师，十年互联网行业从业经验，曾在知乎、即刻、小红书多个团队负责架构师职位，专一于分布式系统、大数据、AI 畛域的技术钻研。
背景
趣头条大数据平台目前有一个近千节点的 HDFS 集群，承载着存储最近几个月热数据的性能，每日新增数据达到了百 TB 规模。日常的 ETL 和 ad-hoc 工作都会依赖这个 HDFS 集群，导致集群负载继续攀升。特地是 ad-hoc 工作，因为趣头条的业务模式须要频繁查问最新的数据，每天大量的 ad-hoc 查问申请进一步减轻了 HDFS 集群的压力，也影响了 ad-hoc 查问的性能，长尾景象显著。集群负载高居不下，对很多业务组件的稳定性也造成了影响，如 Flink 工作 checkpoint 失败、Spark 工作 executor 失落等。
因而须要一种计划使得 ad-hoc 查问尽量不依赖 HDFS 集群的数据，一方面能够升高 HDFS 集群的整体压力，保障日常 ETL 工作的稳定性，另一方面也能缩小 ad-hoc 查问耗时的稳定，优化长尾景象。
方案设计
趣头条的 ad-hoc 查问次要依附 Presto 计算引擎，JuiceFS 的 Hadoop SDK 能够无缝集成到 Presto 中，无需改变任何代码，以不侵入业务的形式主动剖析每一个查问，将须要频繁读取的数据主动从 HDFS 拷贝至 JuiceFS，后续的 ad-hoc 查问就能够间接获取 JuiceFS 上已有的缓存数据，防止对 HDFS 产生申请，从而升高 HDFS 集群压力。
另外因为 Presto 集群是部署在 Kubernetes 上，有弹性伸缩集群的需要，因而须要可能将缓存数据长久化。如果应用独立的 HDFS 或者某些缓存计划的话，老本会很高，此时 OSS 成为最现实的抉择。
整体方案设计如下图所示。绿色局部示意 JuiceFS 的组件，次要蕴含两局部：JuiceFS 元数据服务（下图中的 JuiceFS Cluster）及 JuiceFS Hadoop SDK（下图与 Presto worker 关联的组件）。
JuiceFS 元数据服务用于治理文件系统中所有文件的元信息，如文件名、目录构造、文件大小、批改工夫等。元数据服务是一个分布式集群，基于 Raft 一致性协定，保障元数据强一致性的同时，还能确保集群的可用性。
JuiceFS Hadoop SDK（以下简称 SDK）是一个客户端库，能够无缝集成到所有 Hadoop 生态组件中，这里的计划即是集成到 Presto worker 中。SDK 反对多种应用模式，既能够代替 HDFS 将 JuiceFS 作为大数据平台的底层存储，也能够作为 HDFS 的缓存零碎。这个计划应用的便是后一种模式，SDK 反对在不改变 Hive Metastore 的前提下，将 HDFS 中的数据通明缓存到 JuiceFS 中，ad-hoc 查问的数据如果命中缓存将不再须要申请 HDFS。同时 SDK 还能保障 HDFS 与 JuiceFS 间数据的一致性，也就是说当 HDFS 中的数据产生变更时，JuiceFS 这边的缓存数据也能同步更新，不会对业务造成影响。这是通过比拟 HDFS 与 JuiceFS 中文件的批改工夫（mtime）来实现的，因为 JuiceFS 实现了残缺的文件系统性能，所以文件具备 mtime 这个属性，通过比拟 mtime 保障了缓存数据的一致性。
为了避免缓存占用过多空间，须要定期清理缓存数据，JuiceFS 反对依据文件的拜访工夫（atime）来清理 N 天前的数据，之所以抉择用 atime 是为了确保那些常常被拜访的数据不会被误删除。须要留神的是，很多文件系统为了保障性能都不会实时更新 atime，例如 HDFS 是通过设置 dfs.namenode.accesstime.precision 来管制更新 atime 的工夫距离，默认是最快 1 小时更新 1 次。缓存的建设也有肯定的规定，会联合文件的 atime、mtime 和大小这些属性来决定是否缓存，防止缓存一些不必要的数据。
测试计划
为了验证以上计划的整体成果，包含但不限于稳定性、性能、HDFS 集群的负载等，咱们将测试流程分为了多个阶段，每个阶段负责收集及验证不同的指标，不同阶段之间可能也会进行数据的横向比拟。
测试后果
HDFS 集群负载
咱们设计了两个阶段别离开启和敞开 JuiceFS 的性能。在开启阶段随机选取 10 台 HDFS DataNode，统计这一阶段每台 DataNode 均匀每天的磁盘读 I/O 吞吐，平均值约为 3.5TB。在敞开阶段同样抉择这 10 个节点，统计下来的平均值约为 4.8TB。因而 应用 JuiceFS 当前能够升高 HDFS 集群约 26% 的负载，如下图所示。
从另一个维度也能反映 HDFS 集群负载升高的成果，在这两个阶段咱们都统计了读取及写入 JuiceFS 的 I/O 总量。JuiceFS 的读 I/O 示意为 HDFS 集群升高的 I/O 量，如果没有应用 JuiceFS 那么这些申请将会间接查问 HDFS。JuiceFS 的写 I/O 示意从 HDFS 拷贝的数据量，这些申请会增大 HDFS 的压力。读 I/O 总量应该越大越好，而写 I/O 总量越小越好 。下图展现了某几天的读写 I/O 总量，能够看到读 I/O 根本是写 I/O 的 10 倍以上，也就是说 JuiceFS 数据的命中率在 90% 以上，即 超过 90% 的 ad-hoc 查问都不须要申请 HDFS。
均匀查问耗时
在某一阶段将各 50% 流量的查问申请调配给未对接和已对接 JuiceFS 的两个集群，并别离统计均匀查问耗时。从下图能够看到，应用 JuiceFS 当前均匀查问耗时升高约 13%。
测试总结
JuiceFS 的计划在不改变业务配置的前提下，以对业务通明的形式大幅升高了 HDFS 集群的负载，超过 90% 的 Presto 查问不再须要申请 HDFS，同时还升高了 13% 的 Presto 均匀查问耗时，超出最后设定的测试指标预期。之前长期存在的大数据组件不稳固的问题也失去解决。
值得注意的是，整个测试流程也很顺畅，JuiceFS 仅用数天就实现了测试环境的根底性能和性能验证，很快进入到生产环境灰度测试阶段。在生产环境中 JuiceFS 的运行也十分安稳，接受住了全量申请的压力，过程中遇到的一些问题都能很快失去修复。
将来瞻望
展望未来还有更多值得尝试和优化的中央：
- 进一步晋升 JuiceFS 缓存数据的命中率，升高 HDFS 集群负载。
- 增大 Presto worker 本地缓存盘的空间，晋升本地缓存的命中率，优化长尾问题。
- Spark 集群接入 JuiceFS，笼罩更多 ad-hoc 查问场景。
- 将 HDFS 平滑迁徙至 JuiceFS，齐全实现存储和计算拆散，升高运维老本，晋升资源利用率。
我的项目地址 ：
Github（https://github.com/juicedata/juicefs）如有帮忙的话 欢送 star (0ᴗ0✿)，激励激励咱们哟！