以前的定時(shí)任務(wù)都是使用 for循環(huán)加 sleep ，這種偽裝的定時(shí)任務(wù) 有很大的局限性，為了 更好的使用數(shù)據(jù)流傳輸 到 hdfs，我們?cè)诓唤柚ぞ叩那疤嵯?使用 scp expect hadoop 等多個(gè)linux非原生的 命令組合的腳本 完成了 數(shù)據(jù)的傳輸，當(dāng)然為了實(shí)現(xiàn)自動(dòng)化傳輸 ，必須借助 linux的 crontab 定時(shí)任務(wù) 組件命令 在執(zhí)行腳本，
腳本的執(zhí)行有 按天 執(zhí)行 按小時(shí)執(zhí)行 ，未來也會(huì)有按周或者 按月執(zhí)行的。
在使用crontab 我也遇到了一些問題，當(dāng)然這些問題 有crontab自身的小bug，和對(duì) crontab應(yīng)用不熟悉造成的，做一個(gè)小的流水賬記錄一下
1.定時(shí)任務(wù) 是和 linux的用戶綁定的，root 設(shè)置的定時(shí)任務(wù) 只有 root 用戶才可以執(zhí)行設(shè)置和切換到root 用戶才能查看，其他用戶設(shè)置的定時(shí)任務(wù)也只有本用戶自己可以執(zhí)行設(shè)置和查看，要使用哪個(gè)用戶執(zhí)行 要心中有數(shù) ，使用 crontab -e ,設(shè)置定時(shí)任務(wù)
2.使用定時(shí)任務(wù)要執(zhí)行的腳本 需要 修改其權(quán)限，使之 有權(quán)限執(zhí)行腳本
chmod 777 *.sh
3.首先 crontab 的配置文件 /etc/crontab 的環(huán)境變量 和 root 用戶下/etc/profile 、 普通用戶 下 ~/.bashrc不共通的，這也是造成 為什么在shell 中直接執(zhí)行沒有問題，但是到crontab 就無法執(zhí)行 或根本沒有執(zhí)行，或者執(zhí)行出錯(cuò)，比如 就 scp expect hadoop 這些命令 crontab 的環(huán)境變量是沒有的，不可能識(shí)別，為了 被識(shí)別 可以通過兩種方式
1.全局修改 全局生效 在 crontab的配置文件 把 環(huán)境變量補(bǔ)充到和 /etc/profile 、 普通用戶 下 ~/.bashrc 一致的PATH 變量,一般 缺少 /usr/local/bin /usr/local/sbin ，然后把 一些 特殊的 命令 比如 scp 和except 找到他們的執(zhí)行全路徑
which scp
which except
把得到的全路徑 以 alias 形式 寫入到 /etc/crontab中 即可
比如 scp=/usr/bin/scp
這樣就可以執(zhí)行 scp 命令
- 局部修改 局部起效 ，把要執(zhí)行的 命令的全路徑在 你要執(zhí)行的腳本中 做一下聲明 ，就可以直接使用 ，比如
聲明：
HADOOP=/usr/local/hadoop/bin/hadoop
我在使用時(shí) 就是
$HADOOP fs -put ./* /pathdir
4.另外就是 定時(shí)任務(wù)設(shè)定的時(shí)間，以前總聽 大家講按天 執(zhí)行 腳本的定時(shí)任務(wù)都是設(shè)置在后半夜 凌晨?jī)扇c(diǎn)的，這樣做能盡可能的不影響線上業(yè)務(wù) ，得到的信息可能也是比較容易計(jì)算 的不會(huì)多少?？墒俏覄傞_始也這么做了，結(jié)果沒有拿到數(shù)據(jù)，我不知道為什么，還以為是腳本沒被執(zhí)行或者執(zhí)行錯(cuò)誤，但最后通過觀察 源文件目錄的生成時(shí)間原來是下午一點(diǎn)多，當(dāng)然非?？尚?，人家都沒有生成 ，我能捉到了才怪呢，所以這個(gè)腳本的執(zhí)行時(shí)間 一定是受源文件的生成時(shí)間有關(guān)的，一定是在源文件生成之后完整后才可以抓取，這樣一來 執(zhí)行的時(shí)間也是考究的，不一定非要后半夜 ，折中一下選擇更合適的時(shí)間
5.存儲(chǔ)和刪除
我們的定時(shí)任務(wù)這期主要是中轉(zhuǎn)數(shù)據(jù)，數(shù)據(jù)量 每天大概有600G 左右，有時(shí)候需要修補(bǔ)數(shù)據(jù)，每天產(chǎn)生的數(shù)據(jù)就更多了，我們?cè)谥修D(zhuǎn)機(jī)器上掛載了 一個(gè)2T 的硬盤，按道理裝兩天的肯定夠，不過還是經(jīng)常能碰到 數(shù)據(jù)傳輸?shù)臅r(shí)候，磁盤就剩20G了，稍微不注意，磁盤被占滿，數(shù)據(jù)傳輸被阻塞 ，使用scp 是不支持中斷傳輸?shù)?，?shù)據(jù)流 最煩的就是傳了一半半半兒的，修補(bǔ)數(shù)據(jù)使用 通配符 或者正則匹配都多多少少有點(diǎn)小麻煩，很多人推薦使用 rsync 傳輸 ，支持中斷和 update 覆蓋，存儲(chǔ)是限量的，所以 必要的定時(shí)刪除也是必要的，刪除的時(shí)機(jī)也很重要，比如按天分類目錄的，我們?cè)谇耙惶斓娜罩?傳輸完整 數(shù)據(jù)完整性驗(yàn)證后 并上傳到 目的地 完成相應(yīng)的存儲(chǔ)和計(jì)算任務(wù) 后，并 新一天的數(shù)據(jù)開始正常傳輸后的一到兩個(gè)小時(shí)內(nèi) 刪除即可，這是整體一口氣刪除，當(dāng)然這個(gè)時(shí)候 可能 部分?jǐn)?shù)據(jù)會(huì)占用一天的磁盤時(shí)間，假如我們是按小時(shí)傳輸 驗(yàn)證的，也完全可以在每小時(shí) 傳輸驗(yàn)證后的 十分鐘內(nèi)刪除 掉上一個(gè)時(shí)間段的中轉(zhuǎn)數(shù)據(jù)，這樣做的節(jié)省磁盤空間 ，缺點(diǎn)是出現(xiàn)異常 修補(bǔ)數(shù)據(jù)可能需要重新從源機(jī)器傳輸，另外 rm -rf file 刪除大文件也是一個(gè)非常耗時(shí)的，耗 cpu 的，600G 的數(shù)據(jù)一口氣刪完 ，對(duì)于8核16G的 centos 來說可能也需要 20分鐘。
6.打印日志 ，
當(dāng) 把 寫腳本 設(shè)置定時(shí)任務(wù)走一遍 ，突然發(fā)現(xiàn) 好像 正常的日志流工具也是這么操作的，算是更加熟悉了 ，在我們?cè)趫?zhí)行腳本時(shí) 有時(shí)候 甚至大部分不在電腦前 半夜凌晨三點(diǎn)還在睡覺，所以追蹤track 定時(shí)任務(wù)的執(zhí)行情況很重要 ，有了這些日志才可能在出現(xiàn)異常是及時(shí)捕獲到，可以悠閑滴 喝著拿鐵 查看監(jiān)控，最簡(jiǎn)單的 就是
echo "$Date( "%y%m%d %H:%M:%S") track message " >> data.log
對(duì)于異常 信息 當(dāng)然更需要被捕獲
這樣清晰明了 ，我在定位問題的關(guān)鍵節(jié)省了很多功夫，排除了很多障礙物
7 數(shù)據(jù)完整性驗(yàn)證
數(shù)據(jù)在傳輸?shù)倪^程中就必然會(huì)遭遇到 數(shù)據(jù)的丟失和失敗，比如 就剛才的 磁盤滿了，傳輸阻塞，某些文件傳輸?shù)揭话刖捅?咔嚓掉了，假如你沒有驗(yàn)證就把他當(dāng)成完整數(shù)據(jù)來處理，帶來的損失可能非常大，首先數(shù)據(jù)完整性是一個(gè)工程性的話題，一你要盡最大努力保證 數(shù)據(jù)傳輸?shù)姆€(wěn)定和可靠，我們使用except >>eof 確保 讀原始數(shù)據(jù)讀完，然后在傳輸?shù)?目的地后 通過簡(jiǎn)單的 wc -l 比對(duì)行數(shù) 或者 文件字節(jié)大小 du -h ./file ,如果時(shí)間充裕或者性能 高亢，我們還可以通過MD5 或者其他 算法 驗(yàn)證文件中途是否遭遇被篡改，數(shù)據(jù)完整性驗(yàn)證后 通過一個(gè) 標(biāo)志性 success.log空文件 作為 目錄驗(yàn)證通過的標(biāo)志。
8 郵件監(jiān)控和報(bào)警
作為某些leader 他總有各種強(qiáng)迫癥，希望可以喝著咖啡 查收郵件 來確認(rèn)工作的進(jìn)度，在我們 批量的定時(shí)任務(wù)執(zhí)行后 數(shù)據(jù)驗(yàn)證成功 ，按道理 為了安撫領(lǐng)導(dǎo)的小情緒，我們只有按照一定的套路來讓他放心，就是數(shù)據(jù)最后的狀態(tài)信息郵件發(fā)給他，email的中文
前一行 是醒目的 紅色 success 或者 黑色的failed ，剩下的從 傳輸日志中抓取到的日志信息，讓他看個(gè)夠，最好是夠喝一杯星巴克的時(shí)間，還有大部分為了數(shù)據(jù)安全，沒有公網(wǎng)只有 內(nèi)網(wǎng)，這個(gè)郵件服務(wù)還是需要中轉(zhuǎn)一下，挺頭痛的。
9.定時(shí)任務(wù)隊(duì)列
在我們執(zhí)行定時(shí)任務(wù)是 ，有時(shí)候不單單是一個(gè)定時(shí)任務(wù)，可能是很多，比如 我昨天就還開始了 17個(gè)定時(shí)任務(wù)，我們的建議是 定時(shí)任務(wù) 要有高內(nèi)聚 低耦合的意識(shí)，同一個(gè)流程的盡量寫在一個(gè)腳本里 ，這樣也可以做一些類似數(shù)據(jù)庫事務(wù)的處理，不是一個(gè)流程 的盡量在不同的腳本中，防止一個(gè)流程任務(wù)的失敗 影響到其他任務(wù)。
當(dāng)然 任務(wù)的開啟就像是打印機(jī)的打印流程，先來后到總是有的， 按小時(shí)執(zhí)行的 我們盡量安排在 一個(gè)時(shí)刻內(nèi)的05到-45之間，因?yàn)? 一個(gè)任務(wù)不可能是立馬執(zhí)行結(jié)束的，需要一些時(shí)間，太早了怕是元數(shù)據(jù)沒有，太晚了，會(huì)影響到下一個(gè)時(shí)刻的定時(shí)任務(wù)，我們能做到的就是盡量在一個(gè)時(shí)刻內(nèi)解決掉本時(shí)刻的所有任務(wù)，不要拖累下一個(gè)時(shí)刻，不然累積就是一個(gè)大問題 ，造成越來越多的任務(wù)延后執(zhí)行，甚至宕機(jī)。
10后臺(tái)進(jìn)程
我們的任務(wù)
11.腳本管理
剛才說了 我一天就開了17個(gè)定時(shí)任務(wù)，大致寫了20個(gè)腳本，如果腳本很散亂，可能不便于管理，假如哪天不小心刪除了，想死的心 和想殺人的怒火，哎，好吧我收斂一下。。。
我的建議是 有一個(gè)專門的目錄 比如 scripts 做腳本管理，腳本的命名最好也是有規(guī)律的，可以一目了然之意的。做好腳本的備份和 gitlab的版本控制
12 修補(bǔ)數(shù)據(jù) 和 流程管理 維護(hù)
剛才也說了 數(shù)據(jù)有時(shí)候就像我們的褲子，修修補(bǔ)補(bǔ)又三年，數(shù)據(jù)丟失 傳輸失敗，肯定要修補(bǔ)一下，怎么修補(bǔ) 和我們的數(shù)據(jù)文件定義有很大關(guān)系，比如我們的源數(shù)據(jù)是按小時(shí) 按機(jī)器生成的，我們?cè)谛扪a(bǔ)的時(shí)候直接修補(bǔ)丟失時(shí)刻的數(shù)據(jù)即可，但是千萬不要刻舟求劍。
另外 一臺(tái)中轉(zhuǎn)機(jī)器一天800G 數(shù)據(jù)的傳輸，肯定要使用內(nèi)網(wǎng)傳輸，大數(shù)據(jù)量對(duì)于單臺(tái)機(jī)器來說 占用相當(dāng)大的帶寬 ，也會(huì)造成一些 延時(shí)操作 等等問題。我們還要錯(cuò)開傳輸?shù)母叻迤?br>
13 半夜23點(diǎn)之痛
這個(gè)主要是針對(duì)我們按小時(shí)生成的元數(shù)據(jù)，我們一般都是延后一個(gè)小時(shí)去抓取上一個(gè)時(shí)刻的數(shù)據(jù)，比如8點(diǎn)十分去抓取 七點(diǎn)一個(gè)小時(shí)的元數(shù)據(jù) ，這個(gè)延后一小時(shí)會(huì)有一定的影響，比如 到了凌晨12點(diǎn) 在linux就是00時(shí)刻，就是第二天了，但是我們還要去抓取 上一天的23點(diǎn)的數(shù)據(jù)， 有時(shí)候我腦子就錯(cuò)亂了，這個(gè)時(shí)候就需要 針對(duì) 23點(diǎn)做一個(gè) if處理 ，通過教訓(xùn)，為了最小化腳本的代碼，有些 腳本 的中出現(xiàn)的 數(shù)值 字符串 一定要 變量話，這樣在流程管理中 會(huì)節(jié)省很大功夫，也不容易出錯(cuò)
14 壓縮和解壓之痛
gzip 壓縮可以達(dá)到 八倍，在加上tarball ，其實(shí)能夠很好的處理數(shù)據(jù)，但是 解壓時(shí)間超級(jí)長(zhǎng)，比如說 tarball 是 10G ，解壓后 100G ，這個(gè)解壓過程其實(shí)有半個(gè)小時(shí)左右，很長(zhǎng)很嚇人，我們本想使用snappy ，但是在linux上操作還有點(diǎn)問題，我們的原始數(shù)據(jù)是隔天打包，大前天打包 ，昨天的不壓縮，所以只能爭(zhēng)取盡快在沒壓縮之前傳輸，另外 爭(zhēng)取 使用snappy 更好 更快。
