分布式的大数据平台进行存储和检索的方式逐渐成为主流的主要原因是多源传感器数据具有种类繁多、大小不一、存储与检索困难等特点。传统的数据库和数据存储方案无法满足数据的存储、检索需求。大数据平台能够支持采用物理设备动态扩展资源，从而支撑数据量的线性增长。

基于多传感器的海量数据的存储与检索功能及性能需求，采用图中技术体系搭建大数据平台，实现分布式的数据存储和数据检索。

其技术体系架构主要分为以下几层：

（1）基础支撑层

在相关硬件和操作系统的基础环境之上，采用IDEA作为开发环境，使用Maven管理项目内与项目间Jar包的依赖关系，使用Git作为项目管理和代码托管平台，基于Java JDK1.8进行整个项目的开发，Ngix用于部署运行编写完善稳定的代码。

（2）通用大数据平台层：

通过Ambari搭建大数据平台，更方便地管理各个组件的版本对应关系及集群整体健康状况。

• 基于Zookeeper实现大数据平台的高可用（HA），提高集群的可靠性。

• 通过Kerberos和Ranger实现数据的用户认证和权限管理，大数据平台管理系统的用户管理和权限管理功能基于该组件进行开发。

• Yarn作为资源管理器，是一个通用资源管理系统，可为大数据平台上的应用提供统一的资源管理和调度。

• HDFS是大数据管理系统开发的核心组件，主要用于存储各种文件，实现文件上传、下载、移动、复制等文件管理功能。

• Mysql作为传统的关系型数据库，用于存储文件的索引信息，用于实现数据检索功能，同时作为系统的元数据库，存储大数据平台和管理系统的配置参数等信息。

• Hbase作为一种大容量的可实时读写的列式分布式数据库，可用于后期存储文件内容，以便于对内容进行检索。

（3）数据服务层：

在通用大数据平台的基础上，根据业务需求基于Springboot对大数据平台各组件的API进行封装，开发Restful风格的后端接口，供前端页面调用。Springboot与Mybatis结合使用，通过XML或注解来配置和映射原生信息，可将接口和Java的POJO类映射成数据库中的记录。基于Springcloud可对开发的后端接口进行统一配置管理，如服务注册发现、负载均衡等，保证微服务的稳定性和可靠性。

（4）应用层：

用户需要采集海量的传感器数据，并对多源传感数据用不同的算法进行处理以及对算法中的参数进行调整，因此会产生大量源数据、中间文件及结果文件。这些文件的大小不一，较小且比较重要，需要追加检索小文件，这种应用场景不适合一次写入多次读取的场景。大量的小文件会对元节点的内存造成较大压力，同时小文件过多造成存储系统的寻道时间过长大于读写时间，使得整个存储系统的读写缓慢。因此在大数据平台体系下解决小文件存储问题需要作为一个关键技术来进行研究。

常用的技术方案一般采用（1）-（3），通过数据打包后进行块存储来解决读写缓慢的问题，但都存在各自的缺陷或问题，不适用海量多源传感器的存储与检索应用，因此推荐方案（4）通过Hbase的rowkey方式来解决该技术问题。

（1）Archive小文件存储方案：

Archive命令将文件系统的某个或多个目录下的小文件打包成以*.har为结尾的文件，该命令是通过MapReduce的方式合并文件，归档文件中包含元数据信息和小文件内容，即从一定程度上将元节点管理的元数据信息下沉到数据节点上的归档文件中，避免元数据的膨胀。但是该文件一旦创建就无法修改，因此不能在当前的基础上追加合并小文件，能够适应应用场景有限。

（2）SequenceFile小文件存储方案：

SequenceFile本质上是一种二进制文件格式，类似key-value存储，通过编程将需要合并的小文件合并成一个以.seq为结尾的大文件（以文件名为key，文件内容为value）。这种方式的灵活性较高，可以选择要合并的小文件，但是.seq文件一旦生成也无法修改，无法追加合入新的小文件，如果当write流不关闭的时候，没有办法构造read流。也就是在执行文件写操作的时候，该文件是不可读取的，同时二进制文件，合并后不方便查看。因此当前SequenceFile合并小文件也不适合当前的应用场景。

（3）CombinedFile存储方案：

其原理也是基于MapReduce将原文件进行转换，首先通过CombineFileInputFormat类将多个文件分别打包到一个split中，每个mapper处理一个split,提高并发处理效率，其优点是适用于处理大量比block小的文件和内容比较少的文件合并，尤其是文本类型/sequencefile等文件合并，其缺点是：如果没有合理的设置maxSplitSize，minSizeNode，minSizeRack，则可能会导致一个map任务需要大量访问非本地的Block造成网络开销，反而比正常的非合并方式更慢。因此这种小文件存储方案应用较少。

（4）Hbase小文件存储方案：

HBase主要是key/value存储结构，一个key对应多个列族的多个列值。HBase可以很方便地将图片、文本等文件以二进制的方式进行存储。虽然HBase一般可以处理从1字节到10MB大小的二进制对象，但是HBase通常对于读写路径的优化主要是针对小于100KB的值。当HBase处理数据为100KB~10MB时，由于分裂（split)和压缩（compaction）会引起写的放大，从而会降低HBase性能。所以在HBase2.0+引入了MOB特性，这样保持了HBase的高性能、强一致性和低开销。MOB的出现大大提高了我们使用HBase存储小文件的效率，这样无须关注底层HDFS是怎么存储的，只要关注上层逻辑即可，HBase的强大优势也能保证存储的高可靠和稳定性，管理也方便。MOB还可以设置MOB压缩策略，为了减少MOB Files的数量以提升性能，HBase可以定期做MOB 压缩，默认是按天压缩，也可以修改成按星期或按月压缩。以文件路径+文件名为rewkey，以文件内容为cell。

小文件存储示意图

通过rowkey可以快速检索到文件，同时利用hbase的时间戳实现文件的删除、更新操作。因为Hbase的存储只支持文本，我们下载文件后原始文件里的格式会发生变化，为了保持原文件的格式，我们可以在上传文件的时候将文件流转换成BASE64的编码，这样上传和下载仍是原文件。为了web端的文件目录结构，在MySQL里存储一个用户目录的树形结构，通过MySQL将各种传感器的原始数据，图像数据和算法处理后的数据进行关联，用于信息检索。

通过本期的知识分享，大家了解到基于多源传感器的海量小文件存储和检索的技术体系、数据存储及检索的关键技术，可以更好地应对海量小文件的智能检索，帮助用户提取数据、分析数据，实现数据价值。