一文解决大数据环境下小文件的存储和索引相关的需求

1,345 阅读4分钟

本文已参与「新人创作礼」活动,一起开启掘金创作之路。

需求

本文档描述大段落文本信息的存储,查询功能实现

需求:能够从Web页面上通过各种条件查看大段文本信息,能够下载完整文本信息

环境信息

Hadoop2.6,HBase1.2,Elasticsearch6.0

当前大段文本信息直接作为field存储在Elasticsearch中

方案设计

根据需求,可以有两套方案可供参考,具体实现和依赖我会在下面详细说明

HDFS之SequenceFile解决方案:

选型依据

  • HDFS存储海量小文件导致块过多,namenode内存需求增大,导致namenode节点负载变高,稳定性受影响,sequenceFile可以很好的解决该问题

  • sequenceFile可以很好的支持压缩,减少磁盘占用

  • sequenceFile可以分块存储,不会影响诸如mapreduce、spark以及Flink等组件的高效使用

实现方案

  • 为了方便管理,sequenceFile按天创建,采用块压缩(Block Compression)来进行压缩,当天文本信息数据按照kv的方式进行存储写在sequenceFile中,key为唯一标识该文本数据的id,value为文本数据的明细信息

  • elasticsearch中的数据正常存储支持前端的查询,将原本的data字段文本明细数据的字段修改成sequenceFile中该崩文本信息对应的key(如果上面1中的key如果可以通过该条数据其他字段拼接而成的话,那么该字段可以直接删掉)

  • 查询时可以保留原查询接口,通过查询到的数据去HDFS对应的sequenceFile查询取得文本信息;如果遇到列表展示,则建议将文本信息作成lazy load,节省带宽并提高响应速度

  • HDFS上的sequenceFile支持按天老化

查询接口变更

前端和后端的接口不变,后端从Elasticsearch中的document取文本数据的逻辑改成从sequenceFile中获取

实现依赖

需要CDH或者Hadoop环境

HBase之MOB解决方案:

选型依据

  • HBase的MOB是HBase专门为存储小对象而设计的解决方案,10M以下的小文件存储效果和效率比sequenceFile要好很多

  • HBase底层存储的优化能保证文本信息稳定高效的存储

  • HBase数据查询速度比sequenceFile查询速度要快

实现方案

  • HBase专门创建一个table用于存储崩溃栈信息,该表的列族启用MOB属性,采用snappy进行压缩,可以根据需求设置数据存储的ttl,rowkey为唯一标识该崩溃栈数据的id,value为文本的明细信息

  • elasticsearch中的数据正常存储支持前端的查询,将原本的data字段存文本明细数据的字段修改成HBase中该文本信息对应的rowkey(如果上面1中的key如果可以通过该条数据其他字段拼接而成的话,那么该字段可以直接删掉)

  • 查询时可以保留原查询接口,通过查询到的数据去HBase对应的table中查询取得文本信息;如果遇到列表展示,则建议将文本信息作成lazy load,节省带宽并提高响应速度

  • HBase上文本数据按配置的ttl进行老化,老化粒度优于sequenceFile方案

查询接口变更

前端和后端的接口不变,后端从Elasticsearch中的document中取文本数据的逻辑改成从HBase中获取

实现依赖

需要CDH或者Hadoop环境,并且HDFS要支持HFile v3,HBase版本要升级到2.X

最后结论

  • 在HDFS以及HBase版本未升级的情况下,只能采用sequenceFile方案进行处理,如果版本升级的情况下,建议使用HBase的MOB方案

  • 优于两种方案的接口设计是兼容的,所以可以先采取sequenceFile方案对文本数据进行处理,后续版本升级后根据需求决定是否将方案迁移到HBase上,迁移的代价可控可接受

文章到这里就结束了,最后路漫漫其修远兮,大数据之路还很漫长。如果想一起大数据的小伙伴,欢迎点赞转发加关注,下次学习不迷路,我们在大数据的路上共同前进!