周六晚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中的数据就能作为观察的数据了

sql 复制代码

SELECT @@session.time_zone;

发现返回给我的结果是SYSTEM

😅,实习生可没有那么多权限去访问线上服务器

sql 复制代码

SELECT @@global.time_zone;

还是SYSTEM

底层原理是当前会话并没有设置时区,所以也就是直接用的默认时区,即查了也没用😅

陷入困惑,回到题目

突然想到Mysql中select CURRENT_TIMESTAMEP再和我们当前北京时间确定下不就行了吗?

当然上面是运气好的情况,不然24时区一一确定也够呛

所以运气来了!正好是我电脑的时间

目前的Mysql显示的税收相关时间为2024-11-02 06:21:38

那么步骤如下:

嘿嘿!看了所有代码改动都没问题,司机照常出车完单!至少避免了P0 Bug

让我复习了挺多的,但愿这次秋招来个人收了我吧

不过上述内容都是出自于我对于hive数据库表描述没有理解出现偏差,pt字段的类型也是string,这个确实没法百分百确认,我还查了和我们国家相近的日本,发现pt字段也是1101,可能上次mentor查的时候是意外吧