乐趣区

关于数据库:JuiceFS-如何帮助趣头条超大规模-HDFS-降负载

作者简介

  • 王振华,趣头条大数据总监,趣头条大数据负责人。
  • 王海胜,趣头条大数据工程师,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✿),激励激励咱们哟!

退出移动版