在實際項目中,從Kafka到HDFS的數據是每天自動生成一個文件,按日期區分。而且Kafka在不斷生產數據,因此看看kettle是不是需要時刻運行?能不能按照每日自動生成數據文件? 為了測試實際項目中的海豚定時調度從Kafka到HDFS的Kettle任務情況,特地提前跑一下海豚定時調度這個任務,看看 ...
在實際項目中,從Kafka到HDFS的數據是每天自動生成一個文件,按日期區分。而且Kafka在不斷生產數據,因此看看kettle是不是需要時刻運行?能不能按照每日自動生成數據文件?
為了測試實際項目中的海豚定時調度從Kafka到HDFS的Kettle任務情況,特地提前跑一下海豚定時調度這個任務,看看到底什麼情況,也給大家提供一個參考!
海豚調度任務配置
(一)SHELL腳本配置
!/bin/bash
source /etc/profile
/opt/install/kettle9.2/data-integration/pan.sh -rep=hurys_linux_kettle_repository -user=admin -pass=admin -dir=/kafka_to_hdfs/ -trans=04_Kafka_to_HDFS_turnratio level=Basic >>/home/log/kettle/04_Kafka_to_HDFS_turnratio_`date +%Y%m%d`.log
(二)定時任務設置
定時任務設置為每天的零點,零點一到開始執行任務
(三)最後工作流情況
啟動工作流
工作流啟動,成功!工作流一直在跑
相應的任務實例也在跑!
啟動工作流每天HDFS情況
(一)第一天為2023/8/30日
由於第一天開始執行任務,因此自動生成2023/08/30的HDFS文件
(二)第二天為2023/8/31日
2023/08/31早上更新
(1)04_Kafka_to_HDFS_turnratio任務
第二天的海豚任務自動調度,自動生成2023/08/31的HDFS文件
但問題是,除了再跑31日的任務外,30日的任務還在跑,可能是定時配置有問題,需要優化
而且這樣搞容易把kettle搞出問題!
2023/08/31晚上更新
(1)04_Kafka_to_HDFS_turnratio任務
不設置定時任務,kettle任務一直運行,已經生成8月31日的文件,觀察明天會不會自動生成9月1日的數據文件
已生成的8月31日文件
(2)01_Kafka_to_HDFS_queue任務
不設置定時任務,kettle任務一直運行,已經生成8月31日的文件,觀察明天會不會自動生成9月1日的數據文件
已生成的8月31日文件
如果明早不能自動生成9月1日的文件,那就要設置海豚定時為每天的執行時間為0時0分0秒到23時59分59秒 或者在腳本里設置時間 或者在kettle里設置時間?我們試試看!
(三)第三天為2023/9/1日
2023/09/01早上更新
昨晚海豚調度的兩個kettle任務以失敗告終,沒有自動生成9月1日的數據文件
今日再嘗試其他的方式
2023/09/01下午更新
下午嘗試用Crontab定時任務調度Kettle腳本
\[root@hurys22 kettle\_job\_sh\]# crontab -l
SHELL=/bin/bash
\# */1 * * * * /bin/sh /opt/install/kettle9.2/kettle\_job\_sh/test2.sh
06-07 17 * * * /bin/sh /opt/install/kettle9.2/kettle\_job\_sh/01\_Kafka\_to\_HDFS\_queue.sh
設置每天的17點的6分到7分中執行
但是日誌文件顯示kettle任務卻一直再跑
當然,HDFS中確實生成了9月1日今日的文件,而且任務運行時間是我設置的17點7分
這個方法不行,後面再試試其他方法?怎麼就不會設置任務停止呢
(四)第四天為2023/9/4日
2023/09/04早上更新
由於Kafka里有時間戳欄位,因此在kettle任務里獲取當前系統時間戳的日期欄位、然後文件名直接從這個日期欄位獲取
(1)當前系統時間戳的日期欄位
(2)HDFS輸出中文件名直接獲取這個日期欄位,這樣kettle任務運行時,是不是能自動生成每天的數據文件?
(3)測試結果,任務可以跑通,但是HDFS生成的文件不知卻在哪?
終於查到了,原來這樣導出的文件不在HDFS,而在kettle的安裝文件里,即在本地
而且這麼直接以日期命名也有問題,因為有多個Kafka,不可能僅僅以日期命名區分
2023/09/04晚上更新
因為上午的思路有問題,導出的文件沒有在HDFS中,反而在本地,於是下午又換了種思路。
還是從系統獲得時間day,但是文件路徑直接寫成HDFS的文件路徑+day,這樣的url欄位才是HDFS輸出控制項中的文件名欄位
(1)用海豚調度對比,定時調度01_Kafka_to_HDFS_queue任務
目前已生成生成9月4日的文件
(2)用海豚調度對比,不加定時調度04_Kafka_to_HDFS_turnratio任務
目前已生成生成9月4日的文件
(五)第五天為2023/9/5日
2023/09/05早上更新
雖然自動生成了9月5日的文件,但是由於數據量過大、加上把hadoop.tmp.dir放在了/opt/soft/hadoop313/hadooptmp,導致opt文件夾磁碟溢出,使得namenode處於安全模式。
花了一上午時間終於解決NameNode的安全模式問題,發現應該把HADOOP 運行時存儲路徑放在home目錄下,因為home的磁碟空間最大
2023/09/05晚上更新
驚喜!!!
可能已經找到瞭解決方法,直接對Kafka里的時間戳欄位進行截取,然後拼接文件路徑,從而形成一個可以根據時間戳欄位的日期變動的HDFS文件,即每天自動生成一個數據文件
(1)通過Java自定義文件名 欄位url(HDFS路徑+截取的可變的時間戳欄位)
var url="hdfs://root:***@hurys22:8020/rtp/queue\_dynamic/queue\_dynamic"+substr(create_time,0,10)
(2)在HDFS輸出控制項的文件就選擇url欄位
(3)結果
已經生成了9月5日的數據文件,不需要海豚定時調度,只需要海豚一直跑kettle任務即可!
雖然還是生成了9月5日的數據文件,不過我今天下午按照生成每小時維度的數據文件測試過
下午16時運行任務,生成了16時的數據文件,然後到17時,又生成了17時的數據文件,這兩個數據文件都在跑,而且HDFS里大小顯示都為0。
不過區別是,16時的數據是完整的,17時的數據文件是不斷增加的。因為Kafka是實時的,17時只會發送17時的數據,不會發送16時數據。下麵是16時的文件數據
16時的數據文件是有固定的數據,17點後就沒有再寫入數據。之所以看不到這個這個block的大小,是因為寫入數據的規模太小了,等到這個寫入的數據規模達到128MB,即一個塊大小後才會看到這個block的數據。
所以只要一直運行這個kettle任務、不斷寫入數據即可,只要寫入的數據規模達到128MB,第一個block就會被看到。
已用海豚調度一個kettle任務,沒有定時,就一直跑。目前HDFS已生成了9月5日的數據文件,明天就可以觀察幾點
1、有沒有自動生成明天9月6日的數據文件
2、今天9月5日的數據文件裡面的數據是不是固定的、完整的,晚上12點之後不再寫入
3、等到寫入數據規模達到128MB看第一個block的數據大小可不可看到?
明天9月6日除了看這幾點外,還用flume去做Kafka到HDFS的採集工作,以防萬一,這兩天被這個問題搞得頭疼,kettle真是一個易入門難精通的工具!
(六)第六天為2023/9/6日
2023/09/06早上更新
由於昨晚Kafka突然有問題,導致kettle沒能導入數據到HDFS的文件,今早已重新啟動Kafka服務
(1)目前已重新啟動海豚調度的kettle服務
(2)目前已自動生成9月6日的數據文件
(3)只能明天9月7日看一下昨晚的3個問題
1、有沒有自動生成明天9月7日的數據文件
2、今天9月6日的數據文件裡面的數據是不是固定的、完整的,晚上12點之後不再寫入
3、等到寫入數據規模達到128MB看第一個block的數據大小可不可看到?
2023/09/06下午更新
(1)為了以防萬一,加了個對比測試。看看如果一天的數據放不滿一個block或者部分多餘數據放不滿一個block,可不可以正常顯示?即使它總的寫入數據量大於128MB
不僅多加了幾台模擬設備推送數據,還對動態排隊數據和靜態排隊數據兩個kettle任務進行對比
(2)動態排隊數據有自動日期分區,可以自動分成不同日期的文件,就是昨晚跑的kettle任務
(3)而靜態排隊數據沒有日期分區,就往第一個日期文件里寫入數據
目前靜態排隊數據也已經生成了9月6日的數據文件,後面會一直寫入這個文件
明早對比這兩個kettle任務的數據文件看看情況
(七)第七天為2023/9/7日
2023/09/07早上更新
A、HDFS文件有日期分區的動態排隊數據kettle任務狀況
(1)首先是自動生成9月7日的文件
(2)然後是6日的數據文件固定,沒有7日的數據
(3)6日的數據這一塊由於只有62.8MB,因此HDFS的塊沒有顯示大小
B、HDFS文件沒有日期分區的靜態排隊數據kettle任務狀況
由於寫入的HDFS文件沒有日期分區,而且數據量寫入超過了128MB,所以這一塊的數據雖然在不斷寫入,但是這一塊的文件顯示大小為128MB
疑問:現在任務依然運行,我想看看這個塊已經有128MB後,會不會在其他block寫入數據?
2023/09/07晚上更新
A、HDFS文件有日期分區的動態排隊數據kettle任務狀況
(1)今日9月7日寫入的數據量超過128MB,因此HDFS已顯示文件大小
總結一下:用kettle採集Kafka數據寫入HDFS這條路是可行的,只要設置變動的文件名、生成每日的數據文件,然後一直跑任務就好!!!
本文由 白鯨開源 提供發佈支持!