周六晚11实习生上线数据观测突发问题(涉及MYSQL,Hive等)
前提
有点恐怖,上次需求上线后,部分线上数据观测要留到11月初,上次是一个税收相关的需求,已有功能的线上数据观察已经完成,还剩下部分只有在十一月初才可以观察
简单提一嘴(非技术相关)
之前把hive sql发给了mentor,结果hive sql里的pt居然写成了20251011,人都麻了,搞得我这次一直没发现,一直以为查出数据集为空只是数据还没生成😅
并且意外发生了,之前mentor是当天晚上7点左右就有了对应的数据而我突然想起忘了执行,现在晚上11点执行了好几次都没有数据生成,人麻了😅
这时候告诉mentor除了打电话估计也没人响应了,所以只能死马当活马医
尝试梳理情况解决问题
转机出现
发现数据平台标明了表产出时间的描述
表产出时间是在T+1产出,今天产出昨天的数据,时间分区为当前国家首都时间
产生好奇
在Mysql数据库查到的任务拒绝或者通过时间都是11/2开头的,诶那这是否有点不对
由于之前的我很喜欢分析数据库表,并且之前听到mentor们讨论过数据库的时间字段是时间戳
回忆
立马想起了时间戳有鬼(感恩之前了解过timestamp和datatime等等的区别,在脑子里留下了点印象)
通过AI验证后发现确实如此
timeStamp是会随着MySQL会话时区而自动变换查询的结果
记得当时听mentor说,用timestamp,是因为跨多个国家业务,所以使用timestamp来统一,这里查了下我之前做的笔记,不用datetime是因为datetime存在存储时的时区不一样,那么拿出来后的时区也不一样,也就是不统一啦,不统一对于之后线上bug确定这会更麻烦
那么接下来问题就只剩
确认下当前的时区是否是北京时区,如果是北京时区那hive中的数据就能作为观察的数据了
如何查时区
- 第一次尝试
SELECT @@session.time_zone;
发现返回给我的结果是SYSTEM
😅,实习生可没有那么多权限去访问线上服务器
- 第二次尝试
SELECT @@global.time_zone;
还是SYSTEM
底层原理是当前会话并没有设置时区,所以也就是直接用的默认时区,即查了也没用😅
陷入困惑,回到题目
突然想到Mysql中select CURRENT_TIMESTAMEP再和我们当前北京时间确定下不就行了吗?
当然上面是运气好的情况,不然24时区一一确定也够呛
所以运气来了!正好是我电脑的时间
解决问题
目前的Mysql显示的税收相关时间为2024-11-02 06:21:38
那么步骤如下:
- 找个网站时间换算
- 只要时间换算完成对应MX的时间是11-01即可,那么数据就是对应的(万幸正好是01号前)
嘿嘿!看了所有代码改动都没问题,司机照常出车完单!至少避免了P0 Bug
让我复习了挺多的,但愿这次秋招来个人收了我吧
不过上述内容都是出自于我对于hive数据库表描述没有理解出现偏差,pt字段的类型也是string,这个确实没法百分百确认,我还查了和我们国家相近的日本,发现pt字段也是1101,可能上次mentor查的时候是意外吧
