Cloudera集群JanusGraph+HBase反复调用getFilters()日志问题问询

我来帮你拆解这个问题——我之前处理过不少JanusGraph+HBase的部署场景，这个反复输出HBaseKeyColumnValueStore过滤器日志的现象其实挺常见的，下面从原因和解决办法两方面说：

为什么会反复调用HBaseKeyColumnValueStore.getFilters()？ #

这个DEBUG日志反复出现，本质是JanusGraph在和HBase交互时，每次查询（或者查询的迭代片段）都会重新生成对应的HBase过滤器，用来精准定位要读取的列族/列数据。具体触发场景通常有这几种：

• 小查询频繁触发：如果你的应用在执行Gremlin遍历的时候，没做批处理优化，每次只请求少量数据，JanusGraph就会不断向HBase发起小查询，每次查询都得重新构建FilterList（你日志里的ColumnRangeFilter+ColumnPaginationFilter组合就是典型的范围+分页过滤）。
• 旧版本的实现局限：JanusGraph v0.2的HBase存储层实现没有做过滤器缓存——不管是不是重复的查询条件，每次读取操作都会调用getFilters()重新生成过滤器，这在涉及范围扫描或者分页的场景下会特别明显。
• 查询/数据模型设计问题：如果你的JanusGraph顶点/边挂载了大量属性，或者查询经常需要跨多个属性范围做扫描，也会迫使HBase存储层反复生成过滤器来匹配目标数据。

解决办法 #

针对不同的原因，你可以按优先级尝试这些优化手段：

1. 先快速屏蔽冗余日志（治标） #

如果只是觉得日志太吵，不想看到这些DEBUG信息，可以直接调整JanusGraph的日志配置，把org.janusgraph.diskstorage.hbase.HBaseKeyColumnValueStore的日志级别从DEBUG改成INFO或者WARN。比如在你的log4j.properties里加一行：

log4j.logger.org.janusgraph.diskstorage.hbase.HBaseKeyColumnValueStore=INFO

2. 优化查询的批处理能力（治本，优先做） #

• 设置合适的batchSize：在创建Gremlin遍历器的时候，通过with("batchSize", 4096)（数值可以根据你的数据量调整）让JanusGraph一次性从HBase读取更多数据，减少查询次数，自然就减少了过滤器生成的频率。比如：

  GraphTraversalSource g = graph.traversal().with("batchSize", 4096);
  

• 避免N+1查询：检查你的应用代码，是不是有循环里逐个查询顶点/边的情况，改成批量查询（比如用g.V().hasId(Arrays.asList(vertexIds))一次性拉取多个顶点）。

3. 调整HBase存储层的缓存与分页配置 #

• 开启并调大HBase客户端缓存：在janusgraph-hbase.properties里调整这两个参数，让HBase客户端缓存更多数据，减少重复查询：

  hbase.cache.data.enabled=true
  hbase.cache.data.size=104857600 # 100MB，可根据集群内存调整
  

• 优化分页过滤器的大小：你日志里的ColumnPaginationFilter (1024, 0)表示每次取1024列，如果你的数据列数较多，可以适当增大这个值（比如改成4096），减少分页查询的次数，从而降低过滤器生成的频率。这个配置可以在JanusGraph的属性文件里通过storage.hbase.column-pagination-limit设置。

4. 升级JanusGraph版本（长期优化） #

JanusGraph v0.2是2018年的老版本了，后续的v0.5+版本对HBase存储层做了大量优化，包括过滤器缓存、查询性能提升等。如果你的Cloudera集群环境允许，升级到较新的稳定版本能从根本上减少这类频繁调用的问题。

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