一个由TimeZone引发的BUG

数据平台的数据流水线如下图所示，最近的平台的数据出现异常，数据导入过程中随机出现Impala中的数据比Loghub中的数据少了很多。从数据流水线来看只有两种可能：1.从MQ上消费数据存入HBase的过程有遗漏；2.从HBase中导入数据到Impala中时数据有遗漏。

数据流水线 首先想到找几个主要的业务把最近一段时间各个步骤的原始数据列出来，看看到底是哪个环节丢了数据。

实测发现主要是HBase导入Impala的过程数据丢失比较严重。暂且认为MQ的消费程序是没有问题的。

找了数据丢失比较严重一天（10月30号），重新跑数据导入任务，惊奇的发现有的项目的数据变多了，有的项目数据变少了。我们对HBase是没有删除操作的，所以基本锁定问题出在HBase导入数据到Impala时出了问题。难道是Hive的Bug ?

对比了两次导入的SQL语句惊奇的发现筛选条件居然不一样：

正常数据的筛选条件 异常数据的筛选条件

上面的$id是HBase的行键，通过日期来计算得到的，日期明明都是2017-10-30得到的$id却是不同的。那么，很显然问题出在通过日期获取时间戳这里。暂时还是猜想，写个小Demo验证一下。

通过日期获取时间戳的Demo

上面的代码逻辑很简单，从控制台获取一个日期字符串，然后解析成Date对象，然后输出时间戳。然后拷贝到NodeManager所在的节点上运行一下。不出所料，结果是不一样的。

011上得到运行结果 012上的运行结果

到底哪个是对的呢，找个Web的Unix时间戳解析工具测了一下012上的结果是对的，011上的结果解析出来是2017-10-30 12:00:00。那么这很有可能是一个时区问题。下意识查看了一下系统时间：

011上的系统时间 012上的系统时间

发现两台机器上的语言和时区是不同的。修改上面的Demo程序，手动指定时区。

动态指定时区
通过java属性指定时区

通过上述办法设置时区后，在011上也能得到正确的结果。

总结：在数据平台的当前架构中，定时任务通过OOZIE来启动，OOZIE将任务通过ResourceManager分发到不同的NodeManager中运行。为了保证java程序在不同环境下运行结果相同，时区和文件编码不应该是用默认值。而应当在使用时显示的指定时区和编码，避免程序出现不可预料的运行结果。