Nifi使用PutHBaseJson插入HBase数据占用空间大于原始数据如何优化

1. PutHBaseJson默认写入模式的冗余开销
   PutHBaseJson默认会将JSON的每一个顶级字段拆分为独立的HBase Cell（键值对）存储，每个Cell都会重复存储如下信息：RowKey、列族名、列限定符（即JSON字段名）、8字节时间戳、Cell类型标识。你提供的测试JSON包含近20个字段，相当于上述开销会重复计算20次，仅这部分就会带来超过1KB的额外占用。
2. HBase原生存储架构开销
   HBase基于LSM树架构存储数据，天然存在写入放大：数据写入时会先写WAL日志、再写MemStore，MemStore刷盘生成HFile，后台Compaction合并HFile的过程会产生2~3倍的写入放大。你统计的总占用还包含了HFile块索引、布隆过滤器、临时多版本数据等元数据开销。如果未开启压缩，存储占用还会进一步升高。
3. RowKey设计的额外开销
   你采用UUID作为RowKey，如果存储的是字符串格式的UUID，单RowKey长度就达36字节，每个Cell都会携带该RowKey，进一步放大了存储开销。

Nifi侧优化 #

• 调整PutHBaseJson写入逻辑：取消按JSON字段拆分存储的配置，将整条JSON序列化为字节后作为单个Cell的值写入，仅需1个KV即可存完整条数据，直接消除多Cell带来的重复开销。可固定配置列限定符为data，将整条JSON写入该列即可。
• 优化RowKey生成规则：将字符串格式的UUID改为二进制格式存储，RowKey长度直接从36字节压缩到16字节；如果业务允许，优先使用JSON自带的_id作为RowKey，二进制存储仅需12字节，开销更低。
• 开启批量写入：调大PutHBaseJson的批次写入阈值，减少RPC请求的额外开销，同时降低HBase侧的写入放大。

HBase侧优化 #

• 开启列族压缩：给目标表的列族配置压缩算法，推荐使用SNAPPY或ZSTD，压缩率可达3:1~5:1，可直接降低数倍存储占用。配置命令参考：

alter '你的表名', {NAME => '你的列族名', COMPRESSION => 'SNAPPY'}

配置完成后新写入的数据会自动采用压缩存储。

• 精简列族配置：如果不需要多版本存储，将列族的VERSIONS参数设置为1；将布隆过滤器类型调整为ROW（默认是ROWCOL），减少元数据占用；如果单条查询占比高，可以将HFile块大小从默认64KB下调到8KB~16KB，降低块元数据开销。
• 优化Compaction策略：写密集场景下可切换为Tiered Compaction策略，降低Compaction过程的写入放大；写入完成后可手动执行一次Major Compaction，合并小HFile、清理冗余的多版本数据和删除标记，进一步释放存储空间。

内容的提问来源于stack exchange，提问作者ashok