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

1 需求

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

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

2 环境信息

Hadoop2.6，HBase1.2，Elasticsearch6.0

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

3 方案设计

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

3.1 HDFS之SequenceFile解决方案：

3.1.1 选型依据

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

2、sequenceFile可以很好的支持压缩，减少磁盘占用

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

3.1.2 实现方案

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

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

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

4、HDFS上的sequenceFile支持按天老化

3.1.3 查询接口变更

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

3.1.4 实现依赖

需要CDH或者Hadoop环境

3.2 HBase之MOB解决方案：

3.2.1 选型依据

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

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

3、HBase数据查询速度比sequenceFile查询速度要快

3.2.2 实现方案

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

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

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

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

3.2.3 查询接口变更

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

3.2.4 实现依赖

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

3.3 最后结论：

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

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