记一次处理bug经历

最新推荐文章于 2024-05-30 11:43:13 发布

weixin_34128237

最新推荐文章于 2024-05-30 11:43:13 发布

阅读量86

点赞数

文章标签： python 大数据

原文链接：https://my.oschina.net/u/1240328/blog/599693

版权

2019独角兽企业重金招聘Python工程师标准>>>

这次问题设计组件稍复杂，这里大致说一下，我们是做过车信息查询的。负责大数据模块，有另外一个组专门负责卡口，数据是由他们从各卡口抽取，然后插入到hbase中。再通过协处理器，将数据在写进hbase之前发送到AMQ消息队列，然后再消费建立solr索引，架构基本就是这样的。

基于这个，在元旦前后，数据出现点小问题。在元旦前高速卡口上的数据都是可以通过solr查询到的，而元旦之后的数据无法查询到的。当时发现问题时我们自信的认为肯定是抽数据那块出现问题了，后来经查，高速卡口的数据确实抽取到数据了。然后我们逐个组件查找问题，首先我们从hbase开始。由于抽数据那边不确却的知道具体是那些数据丢失，只知道卡口有个编号这些编号都属于高速上的，给我们查询带来一些不便。我首先想到一个简便的方法查询，就是通过hive建一个外部表然后映射到hbase中我需要查询的表，这里可以选择新的只用映射几个我需要知道的字段。

映射语句如下：

CREATE EXTERNAL TABLE xx(
rowkey string, 
aa string, 
bb string) 
STORED BY 'org.apache.hadoop.hive.hbase.HBaseStorageHandler'
WITH SERDEPROPERTIES ("hbase.columns.mapping" = "
:key,
cf:aa,
cf:bb")
TBLPROPERTIES("hbase.table.name" = "table");

然后，我们就可以通hive很容易就查出我们需要的数据。

在hbase这确实查到有高速卡口的数据。然后我们有想到，消费AMQ中数据的程序是我们自己写的，可不可能是在消费的时候出现问题。经查看我们消费程序的日志，没有异常日志。为了确认不是在消费这个节点上出现问题，我现场在代码中加入一个条件，如果遇到高速卡口的数据就日志打印出来。重启消费程序后，验证结果是始终没有高速卡口的数据出现。

至此基本把问题缩小到协处理器和AMQ上。当时当时负责协处理器的同事当时不在，一时半会也无法通过代码验证。然后只有硬着头皮先去查看协处理器的日志，这一看日志，果真发现有问题，发现我们RS有一节点上的日志中有协处理器的几条日志，日志是我们自己定义的，大致意思就是协处理器在region上没有挂载成功。问题是找到了，当时该如何解决。继续在日志里面查找，发现有报找不到类的异常，缺少AMQ的jar包，因为协处理器中是把数据发送到AMQ的，所以需要AMQ相关的包连接AMQ。然后我们添加上AMQ相关包，重启该节点上的RegionServer,OK了，solr中能查到高速卡口的数据。

至此问题解决了，通过这次查找问题，一个是经验积累。另一方面也明白了，规范的重要性，之所有出现这样的情况时因为，元旦前添加了个节点，也就是出问题的节点。我们有添加节点的文档，但是很零散。一旦有遗漏就是给自己挖了一大坑，所以把流程规范是不可或缺的。

转载于:https://my.oschina.net/u/1240328/blog/599693