博睿数据-企业应用性能管理服务商,赋能IT运营智能化

源于10年大数据项目实践经验,博睿数据开源海量小文件存储技术

博睿数据10年深耕APM技术领域,致力于技术创新,推出了众多行业领先产品,如Bonree SDK、Bonree Browser、Bonree Server等,这些产品每天都会回收大量的数据文件进行存储,如网页截图、网络抓包、代码堆栈快照等,由于此类文件体积小但数量多的特点,导致在存储上会遇到很多问题。如使用系统原生文件系统进行存储,则会遇到Linux索引节点(inode)耗尽导致磁盘存储空间无法有效利用的问题,同时也无法原生支持分布式及高可用的要求。但如果采用HDFS或HBASE方案存储,则一方面硬件资源开销较大,NameNode内存开销过大的问题,同时该方案读写效率也不足够高效,尤其当内部进行块文件合并时集群I/O压力过大的时候,读写效率更是难以保证。

 

博睿数据以10年大数据项目实践经验,针对海量(10亿个文件以上)小文件(普遍大小在1KB-50KB)的分布式存储的场景,打磨出BRFS(即:Bonree Distributed FileSystem)系统,以满足博睿数据目前各产品线对海量小文件数据存储需求。

 

目前,此项目已在Github上开源(https://github.com/zhangnianli/BRFS),欢迎Star、Fork和PR。作为博睿数据对那些拥有海量小文件存储需求公司的一份帮助,分享给大家。

解锁BRFS

 

BRFS是一个主要针对海量小文件(快照、图片、语音等)存储而设计的高可用、高性能、易扩展的分布式文件系统。BRFS对存储的文件格式没有限制和要求,任何格式的文件都会以byte字节流的方式进行存储。

 

此系统功能不仅包含了现有其他开源产品具备的权限控制、数据增删读、多副本备份、数据检验等基础功能,同时博睿数据还设计了独特且高效的副本自动迁移和平衡策略、多应用数据隔离且独立配置,系统资源管理插件、集群状态可视化监控与报警等功能。

 

BRFS系统包含如下三个部分:

 

1、FS_Server.jar:在集群每个节点上运行的核心服务模块。在模块运行时会启动若干ReginNode(管理节点)和DataNode(数据节点)进程来提供服务。其中ReginNode进程主要职责是管理存储域元信息、管理数据节点、把用户数据分配到不同的数据节点上进行处理;DataNode进程主要职责是用户数据文件的写入和读取、副本自动平衡恢复、执行定时任务(副本数校验、CRC校验、数据删除、数据归并)执行等。

 

2、FS_ResouceManager.jar:系统资源管理模块,用于实时收集和监控集群各节点资源负载情况,以支持系统可根据节点负载情况分配资源,解决各节点资源利用和负载不均衡问题。BRFS系统内部默认提供了一组资源管理的策略,主要包含CPU、内存、I/O、磁盘容量等负载指标。目前此模块采用可热插拔的设计方式,但如果用户有特殊需求,可自定义此插件,自行实现集群资源的分配和管理。

 

3、server.properties.example:用于后台服务运行时所有的关键控制参数的默认值配置,如果想变更参数值,可以复制一个名为server.properties的文件,并把需要修改的属性和值添加到此文件中即可,程序运行时server.properties文件中的配置的参数值会覆盖server.properties.example文件中参数的默认值。

 

同时,用户如需调用BRFS服务,则需要在工程中引入FS_Client.jar,并在代码中调用相关的接口对BRFS系统进行操作;BRFS分布式文件系统接收的数据形式可以是快照、图片或者任何以byte数组方式进行存储的数据文件。

 

BRFS的价值

 

1、文件存储采用写时合并机制,帮助客户解决环境IO瓶颈的问题;

 

2、文件副本自动平衡恢复,帮助客户解决数据的安全性的问题;

 

3、硬件资源负载管理,帮助客户解决集群资源使用热点的问题;

 

4、引入应用分区的概念,帮助客户解决不同业务数据个性化处理的问题;

 

5、集群横向扩容,帮助客户解决集群扩容不方便的问题。

 

BRFS与FASTDFS的功能对比

 

以开源产品FastDFS为参考,我们在二者功能设计上做了如下对比:

从上面对比可知,FastDFS引入了一个group组的概念,可以简化数据副本的备份策略,但在并发访问、写入、磁盘利用及集群扩展方面就带来一定局限。另外,在资源控制和副本动态恢复和平衡等方面BRFS的在设计上也优于FastDFS。

 

压力测试性能对比

 

集群规模:由2台物理机器组成集群,数据保存一副本;

单台配置:CPU:4核、内存:18G、磁盘:STAT盘 4T 7.2K;

网络:千兆;

压测结果指标:QPS、CPU、MEMORY、IO。

压测方式:分别使用1个/2个/3个/5个/8个/10个JMeter客户端对BRFS和FastDFS进行压测,每个JMeter客户端开启50个并发线程;

目标文件:随机生成1KB和5KB数据文件;

 

1、1KB数据文件
1-1.数据写入

此轮压测结论:
通过上面压测对比来看,在处理海量1KB的数据文件并发写入时,BRFS的写入性能要明显优于FASTDFS,平均效率是FastDFS的5倍以上。FASTDFS在写入数据时,硬件资源明显没有被充分利用。
 

1-2.数据读取

此轮压测结论:
FastDFS:8个Jmeter客户端压测时IO占用100%,带宽也打满,到了机器的极限,QPS达到了12.9万,但当增加到11个Jmeter客户端时QPS反而降到了12万,说明已经到了极限;

BRFS:在11 jemter压测时,CPU占用91%,带宽占用53MB,QPS达到10万;由于压测机器数量不足,BRFS机器资源还没有测到极限,QPS应该还有上升的空间;

通过此轮对比来看,在处理海量1KB大小的数据文件并发读取时,BRFS的读取性能基本与FastDFS持平。

 

2、5KB数据文件
2-1.数据写入

此轮压测结论:
FastDFS:1个Jmeter压测时I/O占用接近80%,增加到3个时I/O基本满了; 

BRFS:在1个、2个、3个jemter压测时,QPS均要明显优于FastDFS;同时BRFS的QPS、TPS、I/O、CPU等指标是随着Jmeter压力增加而线性提高的;

通过上述对比来看,在处理海量5KB文件并发写入时,BRFS的写入性能要明显优于FASTDFS,性能提升约2-3倍。FASTDFS在写入数据时,明显硬件资源没有被合理的利用起来。

 

2-2.数据读取

此轮压测结论:
FastDFS:1个jmeter压测时的QPS要优于BRFS,带宽也基本达到瓶颈;增加到3个时QPS没有明显提高;

BRFS:QPS、I/O、CPU等指标随着Jmeter个数增加而线性提高的,在3个时的QPS要优于FastDFS;在3个Jmeter时未到带宽瓶颈,再增加jmeter时QPS应还会有提高的空间;

通过上述对比来看,在处理海量5KB文件的并发读取时,BRFS的读取性能会随着并发数的提高性能优势逐渐体现出来,BRFS在读取性能方面占有优势。

 

BRFS整体系统架构

此系统主要由Zookeeper、Client、Server以及可视化监控UI等四部分模块组成。

 

BRFS使用Zookeeper来管理集群服务,同步节点状态,确保服务高可用。Zookeeper上保存具体信息包括:机器节点信息、Storage信息、SID信息、任务信息、副本信息、lock锁信息、用户信息、临时信息等元数据信息。

 

Client即用户客户端,它是以Jar的形式被用户在用户工程代码中引用,并通过调用其相应的接口对BRFS进行数据添加、修改、读取等操作。

 

Server即后台集群服务,包括RegionNode和DataNode两组进程。主要功能包含了安全认证、副本管理、磁盘管理、任务(副本数校验、crc校验、删除、归并等)管理、节点资源管理和副本自动平衡与恢复、可视化监控与报警等功能模块。后台服务运行的相关进程是通过zookeeper进行管理的。

 

可视化监控与报警,它是把集群节点上存储的文件情况、后台任务执行情况、资源负载情况、服务运行状态等都通过可视化监控直观的观察到,当某些状态达到阀值后可以自动触发报警。

 

BRFS核心运行机制

使用BRFS只需简单四步

 

BRFS系统除依赖JDK等基础组件外,其他组件只依赖Zookeeper服务进行集群状态同步,且核心服务只有两个Jar文件,因此安装部署极为简单,部署安装只需简单四步:

 

1、安装基础组件,主要包括Zookeeper、JDK等;

2、根据业务需要配置server.properties文件;

3、启动各节点FS_Server.jar服务;

4、通过测试客户端,测试读写功能是否正常。

 

从未停止技术创新的脚步

 

未来,BRFS新版本还将进行两方面升级,一是对大文件存储的支持和优化,不再区分大文件或是小文件,而定位为海量非结构化数据分布式存储系统;二是解决目前所有类似服务都存在的需要用户保存文件FID的问题,对于用户来说,存储海量文件的FID同样是个很大的开销,BRFS将开发一款全新的基于磁盘的key-value系统,以解决海量FID和文件元数据关联存储的问题。

技术是博睿数据发展的驱动力,10年从未停止技术创新的脚步,未来持续与大家分享更多、更先进的技术理念和方法,让世界变得更美好!

 

博睿数据-企业应用性能管理服务商,赋能IT运营智能化