在實(shí)際項(xiàng)目中，從Kafka到HDFS的數(shù)據(jù)是每天自動(dòng)生成一個(gè)文件，按日期區(qū)分。而且Kafka在不斷生產(chǎn)數(shù)據(jù)，因此看看kettle是不是需要時(shí)刻運(yùn)行？能不能按照每日自動(dòng)生成數(shù)據(jù)文件？

為了測試實(shí)際項(xiàng)目中的海豚定時(shí)調(diào)度從Kafka到HDFS的Kettle任務(wù)情況，特地提前跑一下海豚定時(shí)調(diào)度這個(gè)任務(wù)，看看到底什么情況,也給大家提供一個(gè)參考！

海豚調(diào)度任務(wù)配置

（一）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

（二）定時(shí)任務(wù)設(shè)置

定時(shí)任務(wù)設(shè)置為每天的零點(diǎn)，零點(diǎn)一到開始執(zhí)行任務(wù)

（三）最后工作流情況

啟動(dòng)工作流

工作流啟動(dòng)，成功！工作流一直在跑

相應(yīng)的任務(wù)實(shí)例也在跑！

啟動(dòng)工作流每天HDFS情況

（一）第一天為2023/8/30日

由于第一天開始執(zhí)行任務(wù)，因此自動(dòng)生成2023/08/30的HDFS文件

（二）第二天為2023/8/31日

2023/08/31早上更新

（1）04_Kafka_to_HDFS_turnratio任務(wù)

第二天的海豚任務(wù)自動(dòng)調(diào)度，自動(dòng)生成2023/08/31的HDFS文件

但問題是，除了再跑31日的任務(wù)外，30日的任務(wù)還在跑，可能是定時(shí)配置有問題，需要優(yōu)化

而且這樣搞容易把kettle搞出問題！

2023/08/31晚上更新

（1）04_Kafka_to_HDFS_turnratio任務(wù)

不設(shè)置定時(shí)任務(wù)，kettle任務(wù)一直運(yùn)行，已經(jīng)生成8月31日的文件，觀察明天會(huì)不會(huì)自動(dòng)生成9月1日的數(shù)據(jù)文件

已生成的8月31日文件

（2）01_Kafka_to_HDFS_queue任務(wù)

不設(shè)置定時(shí)任務(wù)，kettle任務(wù)一直運(yùn)行，已經(jīng)生成8月31日的文件，觀察明天會(huì)不會(huì)自動(dòng)生成9月1日的數(shù)據(jù)文件

已生成的8月31日文件

如果明早不能自動(dòng)生成9月1日的文件，那就要設(shè)置海豚定時(shí)為每天的執(zhí)行時(shí)間為0時(shí)0分0秒到23時(shí)59分59秒? 或者在腳本里設(shè)置時(shí)間? 或者在kettle里設(shè)置時(shí)間？我們試試看！

（三）第三天為2023/9/1日

2023/09/01早上更新

昨晚海豚調(diào)度的兩個(gè)kettle任務(wù)以失敗告終，沒有自動(dòng)生成9月1日的數(shù)據(jù)文件

今日再嘗試其他的方式

2023/09/01下午更新

下午嘗試用Crontab定時(shí)任務(wù)調(diào)度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  

設(shè)置每天的17點(diǎn)的6分到7分中執(zhí)行

但是日志文件顯示kettle任務(wù)卻一直再跑

當(dāng)然，HDFS中確實(shí)生成了9月1日今日的文件，而且任務(wù)運(yùn)行時(shí)間是我設(shè)置的17點(diǎn)7分

這個(gè)方法不行，后面再試試其他方法？怎么就不會(huì)設(shè)置任務(wù)停止呢

（四）第四天為2023/9/4日

2023/09/04早上更新

由于Kafka里有時(shí)間戳字段，因此在kettle任務(wù)里獲取當(dāng)前系統(tǒng)時(shí)間戳的日期字段、然后文件名直接從這個(gè)日期字段獲取

（1）當(dāng)前系統(tǒng)時(shí)間戳的日期字段

（2）HDFS輸出中文件名直接獲取這個(gè)日期字段，這樣kettle任務(wù)運(yùn)行時(shí)，是不是能自動(dòng)生成每天的數(shù)據(jù)文件？

（3）測試結(jié)果，任務(wù)可以跑通，但是HDFS生成的文件不知卻在哪？

終于查到了，原來這樣導(dǎo)出的文件不在HDFS，而在kettle的安裝文件里，即在本地

而且這么直接以日期命名也有問題，因?yàn)橛卸鄠€(gè)Kafka，不可能僅僅以日期命名區(qū)分

2023/09/04晚上更新

因?yàn)樯衔绲乃悸酚袉栴}，導(dǎo)出的文件沒有在HDFS中，反而在本地，于是下午又換了種思路。

還是從系統(tǒng)獲得時(shí)間day，但是文件路徑直接寫成HDFS的文件路徑+day，這樣的url字段才是HDFS輸出控件中的文件名字段

（1）用海豚調(diào)度對比，定時(shí)調(diào)度01_Kafka_to_HDFS_queue任務(wù)

目前已生成生成9月4日的文件

（2）用海豚調(diào)度對比，不加定時(shí)調(diào)度04_Kafka_to_HDFS_turnratio任務(wù)

目前已生成生成9月4日的文件

（五）第五天為2023/9/5日

2023/09/05早上更新

雖然自動(dòng)生成了9月5日的文件，但是由于數(shù)據(jù)量過大、加上把hadoop.tmp.dir放在了/opt/soft/hadoop313/hadooptmp，導(dǎo)致opt文件夾磁盤溢出，使得namenode處于安全模式。

花了一上午時(shí)間終于解決NameNode的安全模式問題，發(fā)現(xiàn)應(yīng)該把HADOOP 運(yùn)行時(shí)存儲(chǔ)路徑放在home目錄下，因?yàn)閔ome的磁盤空間最大

2023/09/05晚上更新

驚喜?。。?/p>

可能已經(jīng)找到了解決方法，直接對Kafka里的時(shí)間戳字段進(jìn)行截取，然后拼接文件路徑，從而形成一個(gè)可以根據(jù)時(shí)間戳字段的日期變動(dòng)的HDFS文件，即每天自動(dòng)生成一個(gè)數(shù)據(jù)文件

（1）通過Java自定義文件名? 字段url（HDFS路徑+截取的可變的時(shí)間戳字段）

var url="hdfs://root:***@hurys22:8020/rtp/queue\_dynamic/queue\_dynamic"+substr(create_time,0,10)

（2）在HDFS輸出控件的文件就選擇url字段

（3）結(jié)果

已經(jīng)生成了9月5日的數(shù)據(jù)文件，不需要海豚定時(shí)調(diào)度，只需要海豚一直跑kettle任務(wù)即可！

雖然還是生成了9月5日的數(shù)據(jù)文件，不過我今天下午按照生成每小時(shí)維度的數(shù)據(jù)文件測試過

下午16時(shí)運(yùn)行任務(wù)，生成了16時(shí)的數(shù)據(jù)文件，然后到17時(shí)，又生成了17時(shí)的數(shù)據(jù)文件，這兩個(gè)數(shù)據(jù)文件都在跑，而且HDFS里大小顯示都為0。

不過區(qū)別是，16時(shí)的數(shù)據(jù)是完整的，17時(shí)的數(shù)據(jù)文件是不斷增加的。因?yàn)镵afka是實(shí)時(shí)的，17時(shí)只會(huì)發(fā)送17時(shí)的數(shù)據(jù)，不會(huì)發(fā)送16時(shí)數(shù)據(jù)。下面是16時(shí)的文件數(shù)據(jù)

16時(shí)的數(shù)據(jù)文件是有固定的數(shù)據(jù)，17點(diǎn)后就沒有再寫入數(shù)據(jù)。之所以看不到這個(gè)這個(gè)block的大小，是因?yàn)閷懭霐?shù)據(jù)的規(guī)模太小了，等到這個(gè)寫入的數(shù)據(jù)規(guī)模達(dá)到128MB，即一個(gè)塊大小后才會(huì)看到這個(gè)block的數(shù)據(jù)。

所以只要一直運(yùn)行這個(gè)kettle任務(wù)、不斷寫入數(shù)據(jù)即可，只要寫入的數(shù)據(jù)規(guī)模達(dá)到128MB，第一個(gè)block就會(huì)被看到。

已用海豚調(diào)度一個(gè)kettle任務(wù)，沒有定時(shí)，就一直跑。目前HDFS已生成了9月5日的數(shù)據(jù)文件，明天就可以觀察幾點(diǎn)

1、有沒有自動(dòng)生成明天9月6日的數(shù)據(jù)文件

2、今天9月5日的數(shù)據(jù)文件里面的數(shù)據(jù)是不是固定的、完整的，晚上12點(diǎn)之后不再寫入

3、等到寫入數(shù)據(jù)規(guī)模達(dá)到128MB看第一個(gè)block的數(shù)據(jù)大小可不可看到？

明天9月6日除了看這幾點(diǎn)外，還用flume去做Kafka到HDFS的采集工作，以防萬一，這兩天被這個(gè)問題搞得頭疼，kettle真是一個(gè)易入門難精通的工具！

（六）第六天為2023/9/6日

2023/09/06早上更新

由于昨晚Kafka突然有問題，導(dǎo)致kettle沒能導(dǎo)入數(shù)據(jù)到HDFS的文件，今早已重新啟動(dòng)Kafka服務(wù)

（1）目前已重新啟動(dòng)海豚調(diào)度的kettle服務(wù)

（2）目前已自動(dòng)生成9月6日的數(shù)據(jù)文件

（3）只能明天9月7日看一下昨晚的3個(gè)問題

1、有沒有自動(dòng)生成明天9月7日的數(shù)據(jù)文件

2、今天9月6日的數(shù)據(jù)文件里面的數(shù)據(jù)是不是固定的、完整的，晚上12點(diǎn)之后不再寫入

3、等到寫入數(shù)據(jù)規(guī)模達(dá)到128MB看第一個(gè)block的數(shù)據(jù)大小可不可看到？

2023/09/06下午更新

（1）為了以防萬一，加了個(gè)對比測試?？纯慈绻惶斓臄?shù)據(jù)放不滿一個(gè)block或者部分多余數(shù)據(jù)放不滿一個(gè)block，可不可以正常顯示？即使它總的寫入數(shù)據(jù)量大于128MB

不僅多加了幾臺模擬設(shè)備推送數(shù)據(jù)，還對動(dòng)態(tài)排隊(duì)數(shù)據(jù)和靜態(tài)排隊(duì)數(shù)據(jù)兩個(gè)kettle任務(wù)進(jìn)行對比

（2）動(dòng)態(tài)排隊(duì)數(shù)據(jù)有自動(dòng)日期分區(qū)，可以自動(dòng)分成不同日期的文件，就是昨晚跑的kettle任務(wù)

（3）而靜態(tài)排隊(duì)數(shù)據(jù)沒有日期分區(qū)，就往第一個(gè)日期文件里寫入數(shù)據(jù)

目前靜態(tài)排隊(duì)數(shù)據(jù)也已經(jīng)生成了9月6日的數(shù)據(jù)文件，后面會(huì)一直寫入這個(gè)文件

明早對比這兩個(gè)kettle任務(wù)的數(shù)據(jù)文件看看情況

（七）第七天為2023/9/7日

2023/09/07早上更新

A、HDFS文件有日期分區(qū)的動(dòng)態(tài)排隊(duì)數(shù)據(jù)kettle任務(wù)狀況

（1）首先是自動(dòng)生成9月7日的文件

（2）然后是6日的數(shù)據(jù)文件固定，沒有7日的數(shù)據(jù)

（3）6日的數(shù)據(jù)這一塊由于只有62.8MB，因此HDFS的塊沒有顯示大小

B、HDFS文件沒有日期分區(qū)的靜態(tài)排隊(duì)數(shù)據(jù)kettle任務(wù)狀況

由于寫入的HDFS文件沒有日期分區(qū)，而且數(shù)據(jù)量寫入超過了128MB，所以這一塊的數(shù)據(jù)雖然在不斷寫入，但是這一塊的文件顯示大小為128MB

疑問：現(xiàn)在任務(wù)依然運(yùn)行，我想看看這個(gè)塊已經(jīng)有128MB后，會(huì)不會(huì)在其他block寫入數(shù)據(jù)？

2023/09/07晚上更新

A、HDFS文件有日期分區(qū)的動(dòng)態(tài)排隊(duì)數(shù)據(jù)kettle任務(wù)狀況

（1）今日9月7日寫入的數(shù)據(jù)量超過128MB，因此HDFS已顯示文件大小

總結(jié)一下：用kettle采集Kafka數(shù)據(jù)寫入HDFS這條路是可行的，只要設(shè)置變動(dòng)的文件名、生成每日的數(shù)據(jù)文件，然后一直跑任務(wù)就好?。?！

本文由 白鯨開源 提供發(fā)布支持！文章來源地址http://www.zghlxwxcb.cn/news/detail-852391.html

到了這里，關(guān)于用海豚調(diào)度器定時(shí)調(diào)度從Kafka到HDFS的kettle任務(wù)腳本的文章就介紹完了。如果您還想了解更多內(nèi)容，請?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！