博睿数据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年从未停止技术创新的脚步，未来持续与大家分享更多、更先进的技术理念和方法，让世界变得更美好！
