前提
有點恐怖,上次需求上線後,部分線上資料觀測要留到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查的時候是意外吧