前天在使用Druid完成一个新项目时遇到了查询时间错误的问题。就是日志一直在往Druid里灌，但是查近一个小时的数据怎么也查不到。经检查，日志消费情况，时间戳的填充也都是没有问题的。后来尝试将查询起始时间往前推了1天，总算查到了数据（查询时间巨长）。而且根据查询结果中的一些时间字段来看，还是有最近一个小时的记录的。这说明我的查询json是OK的，问题出在时间上。 尝试调整了几次interval时间后，确定了要把查询起止时间往前推8个小时才能查到预期的结果。8 这个数字引起了我的注意——我们通常采用的北京时间就是东八区时区时间。是不是向Druid写入日志时，把时间戳给处理成0时区时间了。赶紧和Druid管理员沟通，确定了如我猜测：如果写入的时间是时间戳格式就会被处理成0时区UTC时间。 再说下解决方案。大体有仨： 调整Druid时区配置 我将日志中的时间戳（13位长整型毫秒值）改为格式化后的时间（如：2019-03-01 12:12:12）。 接受现状，查询时把时间往前推8小时 接受现状是不可能的，因为不符合个人美学。 其中第一个方案，我记得Druid官方文档是有说明的，这个应该可以改。（查了下官网，具体在JVM调优这一节）。但是不能指望运维改，毕竟在线服务都跑了好久了，贸然改了默认时区线上服务是要受影响的。 因此只剩第二个选项了。和运维沟通后，确认了虽然我之前写的是时间戳，但现在直接改成格式化后的时间也是OK的，只是会损失一些数据。最终定下了就采用这种方式。（今天试了下，不能直接改，之前写入的数据被丢弃了，运维重置了元数据才搞定） 其实还可以从其他方向考虑下，大概有两种： 第一种：使用Druid SQL来查询，查询时间仍然采用长整型时间戳,下面是一个范例： 另外使用Druid SQL查询时也可以在context中通过sqlTimeZone设置查询时区（知道有，但没试过）。 但是我不喜欢使用Druid SQL（有一点点性能的考虑）。PASS！ 第二种：使用period Granularities，在查询时指定查询使用的时区。这个在官网有一个例子：Period Granularities。但是嫌繁琐，而且结果未必尽如人意，仍然PASS！ 另外，这次我还开发了一些Druid JSON查询的工具类，如果有需要可以从GitHub拉取：zhyea / druid-explore 。代码中仅包括我现在用到的功能，后续用到了其他功能（如Filter）也会继续补充。 扯点儿闲白：这篇文我从早上就开始酝酿，但是先后出现了博客服务器问题，游戏晋级，零食，水果等种种阻碍，终于才能开始着手写，然后在半个多小时的时间内一气完成——但是完成时天色已全黑。再次感叹之前多次的感叹：小事开头难，大事坚持难。 END！！