Hive小时任务调度：Shell封装实现精准时间窗口与容错执行

1. 项目概述为什么“按小时循环执行Hive脚本”不是简单加个crontab就完事在某数据中台团队的实际运维场景里我接手过一个典型的准实时ETL任务上游业务系统每小时生成一批原始日志文件存入HDFS指定路径下游BI看板需要在每小时整点后15分钟内完成对这批数据的清洗、聚合与维度关联并将结果写入一张汇总宽表供即席查询。表面看这不就是写个Hive SQL脚本再用crontab每小时跑一次但实测三天后监控告警就炸了——凌晨2点那批数据没进数凌晨4点的又卡住导致上午9点的日报直接缺了一块。后来翻日志才发现问题根本不在Hive本身而在于时间窗口错位、任务依赖未校验、失败无兜底、资源争抢无隔离这四个被绝大多数人忽略的底层陷阱。“shell按小时循环执行hive脚本”这个标题本质不是教你怎么敲0 * * * * hive -f /path/to/script.hql而是要解决一个带状态、有时序、需容错、有边界的数据调度问题。它横跨Shell工程能力、Hive执行机制、YARN资源调度、HDFS元数据一致性、以及业务语义的时间定义是“处理上一小时数据”还是“处理当前小时已落盘数据”。关键词里的“按小时”不是指cron的触发频率而是指数据处理的时间粒度、任务调度的窗口边界、以及失败重试的回溯深度。适合三类人细读刚从离线批处理转战准实时场景的ETL工程师习惯用crontab但总被半夜告警叫醒的DBA还有正在设计轻量级调度平台、想避开Airflow/Oozie重型框架的架构师。下面我会把踩过的每一个坑、补上的每一行关键判断、压测出的最优参数全部摊开讲透。2. 整体设计思路为什么必须放弃“裸crontab”转向“带壳调度器”模式2.1 裸crontab的四大原生缺陷很多人以为crontab是万能定时器但在Hive场景下它连最基础的“可靠执行”都保障不了。我们来拆解它的硬伤时间语义模糊0 * * * *表示“每小时第0分钟触发”但Hive脚本执行耗时可能长达8分钟比如大表Join下一次触发时前序任务还在跑造成并发冲突或数据覆盖。更致命的是如果某次执行因YARN队列满而排队5分钟它实际开始时间已是整点5分但脚本里写的分区名却是dt2024052002假设2点触发而真实数据其实是1点到2点的日志——时间戳和数据内容完全错配。失败静默无感知crontab只管启动进程不管进程是否成功。Hive脚本里INSERT OVERWRITE TABLE ... PARTITION(dt...)执行失败可能只是因为目标表被锁或HDFS空间不足但crontab不会发告警也不会重试数据就永远丢失了。我们曾因此连续丢掉3天的用户行为漏斗数据直到BI同事发现转化率曲线突然断崖下跌。无资源隔离与优先级控制所有小时任务共用同一个crontab用户身份提交到YARN默认队列。当多个小时任务如0点的全量统计、6点的用户画像更新、12点的营销活动分析同时撞上YARN会按FIFO排队小任务等大任务跑完才能执行导致SLA严重超时。没有队列配额、没有抢占策略、没有内存/CPU限制等于把生产环境交给运气。无状态追踪与幂等保障crontab不记录“哪个小时窗口的数据已处理”也不校验“目标分区是否存在”。如果网络抖动导致某次执行中断下次触发时脚本会重新写入同一分区造成数据重复非幂等如果手动补数据忘了删crontab又会造成双写。我们曾因运维误操作让0点任务在凌晨3点又被手动触发一次结果当天的dt2024052000分区里混进了3个小时的数据下游所有报表全乱套。2.2 “带壳调度器”的核心设计原则针对以上缺陷我们重构为“Shell Wrapper Hive Script”双层结构核心是把调度逻辑下沉到Shell层让Hive只专注SQL计算。这个“壳”不是简单包装而是承担四大职责时间窗口精准锚定不依赖crontab触发时间而是根据当前系统时间反推待处理的业务小时。例如现在是2024-05-20 14:22:35脚本自动计算出应处理dt2024052013即13:00-14:00的数据并校验HDFS上/data/raw/log/20240520/13/目录是否存在且非空。这样即使crontab延迟触发也不会错失数据。执行状态显式管理每个任务运行前在HDFS上创建标记文件/data/.lock/dt2024052013.lock执行成功后改名为/data/.lock/dt2024052013.done。下次执行前先检查.done文件是否存在存在则跳过幂等若发现.lock但无.done说明上次失败可选择重试或告警。这个机制比数据库记录表更轻量且与Hive元数据解耦。资源与错误兜底控制Shell层封装YARN队列选择--queue etl_hourly、内存限制-hiveconf mapreduce.map.memory.mb4096、超时熔断timeout 3600s hive -f ...。一旦超时自动kill进程、清理临时文件、发送企业微信告警并退出脚本避免crontab反复拉起失败任务。失败分级响应策略不是所有失败都该重试。我们定义三级响应可重试错误如YARN队列满、HDFS NN暂时不可达等待2分钟最多重试2次需人工介入错误如Hive语法错误、目标表Schema变更记录详细日志发告警但不重试数据异常错误如源数据为空、校验行数突降90%写入异常表ods_etl_monitor触发数据质量告警但任务标记为成功避免阻塞后续窗口。这套设计让整个流程从“尽力而为”变成“确定性交付”SLA从75%提升至99.95%。下面进入实操细节。3. 核心细节解析Shell Wrapper的12个关键实现要点3.1 时间窗口计算用date命令做精准业务时间推演很多教程直接用$(date -d 1 hour ago %Y%m%d%H)获取上一小时但这在跨天、跨月时极易出错。正确做法是以当前时间为基础向下取整到小时再减去偏移量。我们的标准函数如下# 计算待处理的业务小时默认处理上一小时数据 get_business_hour() { local offset_hour${1:-1} # 可传参指定偏移如0表示处理当前小时 local now_ts$(date %s) # 向下取整到小时先取整到分钟再取整到小时 local hour_start_ts$(( (now_ts / 60) * 60 / 3600 * 3600 )) local target_ts$(( hour_start_ts - offset_hour * 3600 )) date -d ${target_ts} %Y%m%d%H } # 示例调用 dt$(get_business_hour 1) # 返回2024052013假设现在是14:22 echo Processing data for dt$dt提示date -d ${timestamp}是POSIX兼容写法比date -d 1 hour ago更稳定。我们曾在线上环境发现某些老版本CentOS的date命令对1 hour ago解析不准导致跨月时返回2024043100这种非法日期Hive建表直接报错。3.2 源数据存在性校验不止看目录还要看有效文件仅仅检查HDFS路径存在不够必须确认有符合业务规则的有效数据文件。我们约定每小时数据存于hdfs://namenode:8020/data/raw/log/${dt:0:8}/${dt:8:2}/且至少包含一个以.log结尾、大小1MB的文件排除空文件或临时文件。check_source_data() { local hdfs_pathhdfs://namenode:8020/data/raw/log/${dt:0:8}/${dt:8:2} # 列出所有.log文件过滤出大小1MB的统计行数 local valid_file_count$(hadoop fs -ls ${hdfs_path}/*.log 2/dev/null | \ awk $5 1048576 {print $8} | wc -l) if [ $valid_file_count -eq 0 ]; then echo ERROR: No valid log files found in ${hdfs_path} return 1 fi echo INFO: Found ${valid_file_count} valid log files return 0 }注意hadoop fs -ls输出格式为-rw-r--r-- 3 hdfs supergroup 123456789 2024-05-20 13:05 /path/file.log其中第5列是文件大小字节第8列是完整路径。用awk精确提取避免正则匹配失误。3.3 幂等性控制基于HDFS标记文件的状态机这是整个方案最核心的环节。我们设计了一个极简状态机仅用两个文件类型标识任务状态状态HDFS标记文件含义Shell层动作待执行/data/.lock/dt${dt}.lock任务已启动正在执行检查此文件存在则退出防并发已成功/data/.lock/dt${dt}.done任务完成且数据正确检查此文件存在则跳过本次执行执行中失败/data/.lock/dt${dt}.lock存在但无.done上次执行中断根据策略决定重试或告警关键代码init_lock_file() { local lock_file/data/.lock/dt${dt}.lock local done_file/data/.lock/dt${dt}.done # 检查是否已完成 if hadoop fs -test -e ${done_file}; then echo INFO: Task for dt${dt} already completed. Skipping. exit 0 fi # 检查是否已在执行防并发 if hadoop fs -test -e ${lock_file}; then echo WARN: Lock file ${lock_file} exists. Another instance may be running. # 这里可加逻辑检查lock文件修改时间若30分钟则认为是僵尸进程强制清理 exit 1 fi # 创建lock文件内容为当前时间戳便于排查 echo $(date %Y-%m-%d %H:%M:%S) | hadoop fs -put - ${lock_file} } cleanup_on_success() { local lock_file/data/.lock/dt${dt}.lock local done_file/data/.lock/dt${dt}.done # 将lock重命名为done原子操作 hadoop fs -mv ${lock_file} ${done_file} }提示hadoop fs -mv在HDFS上是原子操作比先-rm再-put更安全。我们曾因网络闪断导致-rm成功但-put失败留下无锁文件后续所有任务都卡死。3.4 Hive执行封装参数化、超时、队列隔离三件套Hive命令不能裸奔必须包裹三层防护run_hive_script() { local hive_script/opt/hive/scripts/etl_hourly.hql # 构建动态参数将dt、hdfs_path等注入Hive变量 local hive_vars-hivevar dt${dt} \ -hivevar raw_pathhdfs://namenode:8020/data/raw/log/${dt:0:8}/${dt:8:2} \ -hivevar target_tableods.user_behavior_d # 指定YARN队列和资源限制关键 local yarn_opts--queue etl_hourly \ -hiveconf mapreduce.map.memory.mb4096 \ -hiveconf mapreduce.reduce.memory.mb8192 \ -hiveconf hive.exec.reducers.max100 # 设置超时3600秒1小时超时自动kill timeout 3600s hive ${hive_vars} ${yarn_opts} -f ${hive_script} 21 | tee /tmp/hive_${dt}.log local exit_code$? if [ $exit_code -eq 124 ]; then echo ERROR: Hive script timed out after 3600s return 1 elif [ $exit_code -ne 0 ]; then echo ERROR: Hive script failed with exit code ${exit_code} return 1 fi return 0 }注意-hivevar传递的变量在Hive脚本中用${dt}引用-hiveconf设置的是Hive配置项。队列名etl_hourly需提前在YARN中配置好资源配额如最大内存200GB最大VCores 50避免与其他任务争抢。3.5 失败分级处理用grep精准捕获错误类型Hive日志是文本海洋不能只看exit code。我们用grep -E匹配三类关键错误模式analyze_hive_log() { local log_file/tmp/hive_${dt}.log # 可重试错误YARN队列满、连接超时、NN不可达 if grep -E (Queue.*full|Connection refused|NameNode.*not active|Timeout) ${log_file} /dev/null; then echo RETRYABLE_ERROR: Matched transient error pattern return 2 fi # 需人工介入语法错误、表不存在、权限拒绝 if grep -E (ParseException|Table not found|Permission denied|SemanticException) ${log_file} /dev/null; then echo MANUAL_ERROR: Requires DBA or dev intervention return 3 fi # 数据异常Hive日志中出现自定义校验失败标记 if grep -E DATA_QUALITY_FAIL: ${log_file} /dev/null; then echo DATA_ERROR: Data quality check failed return 4 fi # 默认成功 return 0 }提示在Hive脚本末尾主动添加校验逻辑例如SELECT COUNT(*) FROM ${target_table} WHERE dt${dt}若结果为0则INSERT INTO TABLE ods_etl_monitor ... VALUES (${dt}, row_count_0, ...)并在日志中打印DATA_QUALITY_FAIL: row count is 0。这样Shell层就能精准识别。3.6 告警与通知企业微信机器人免密推送告警信息必须包含可定位的上下文不能只说“任务失败”。我们推送的JSON包含5个关键字段send_alert() { local alert_type$1 # retryable, manual, data local msg$2 # 构建企业微信机器人JSON payload local payload$(cat EOF { msgtype: text, text: { content: 【Hive小时任务告警】\n时间$(date)\n任务ETL_HOURLY\n窗口dt${dt}\n类型${alert_type}\n详情${msg}\n日志/tmp/hive_${dt}.log\n负责人data-engineer } } EOF ) # 调用企业微信机器人APIURL已脱敏 curl -X POST https://qyapi.weixin.qq.com/cgi-bin/webhook/send?keyxxx \ -H Content-Type: application/json \ -d ${payload} /dev/null 21 }注意data-engineer是企业微信中的成员标签确保消息能到人。我们测试过纯文字告警打开率低于30%加上和具体dt值后15分钟内响应率达92%。3.7 日志归档与清理避免/tmp目录爆满每小时产生一个日志文件不清理会撑爆磁盘。我们在脚本末尾加自动归档archive_logs() { local log_file/tmp/hive_${dt}.log local archive_dir/data/logs/hive_etl # 创建归档目录按年月 hadoop fs -mkdir -p ${archive_dir}/$(date -d ${dt} %Y%m) # 上传日志到HDFS归档保留原始时间戳 hadoop fs -put -f ${log_file} ${archive_dir}/$(date -d ${dt} %Y%m)/hive_${dt}.log # 本地清理 rm -f ${log_file} # 清理30天前的本地临时文件防止crontab残留 find /tmp -name hive_*.log -mtime 30 -delete }3.8 crontab配置从“每小时触发”到“每5分钟心跳”既然Shell层已接管时间窗口计算crontab只需高频“心跳”确保不漏任务。我们设为每5分钟检查一次# 编辑crontabcrontab -e */5 * * * * /opt/shell/etl_hourly_wrapper.sh /var/log/etl_hourly_cron.log 21提示追加日志避免覆盖21将stderr合并到stdout。日志文件/var/log/etl_hourly_cron.log需定期轮转logrotate配置否则单个文件会无限增长。3.9 权限与安全最小权限原则落地脚本运行用户etl_user不能是hdfs或root。我们严格遵循最小权限HDFS路径权限/data/raw/log/目录设为drwxr-x--- etl_user:hadoop/data/.lock/设为drwxrwx--- etl_user:hadoop组可写便于其他ETL任务共享锁目录。Shell脚本权限-rwxr-x--- etl_user:hadoop /opt/shell/etl_hourly_wrapper.shHive配置禁用hive.server2.enable.doAsfalse所有任务以etl_user身份提交避免越权访问。注意hadoop fs -chmod和hadoop fs -chown命令必须由管理员执行脚本中不包含权限修改逻辑防止误操作。3.10 监控埋点暴露关键指标给Prometheus为了让运维可视化我们在脚本中输出结构化指标emit_metrics() { local metrics_file/tmp/etl_metrics.prom cat ${metrics_file} EOF # HELP etl_hourly_task_status Hourly ETL task status (0success, 1fail, 2skipped) # TYPE etl_hourly_task_status gauge etl_hourly_task_status{dt${dt},statussuccess} ${task_status_code} # HELP etl_hourly_task_duration_seconds Duration of Hive execution in seconds # TYPE etl_hourly_task_duration_seconds gauge etl_hourly_task_duration_seconds{dt${dt}} ${duration_sec} EOF # 推送到Pushgateway需提前部署 cat ${metrics_file} | curl -X POST http://pushgateway:9091/metrics/job/etl_hourly --data-binary - }提示task_status_code由主流程返回0成功1失败2跳过duration_sec用SECONDS变量计算。Prometheus抓取pushgatewayGrafana看板即可看到每小时任务成功率、耗时P95等。3.11 回滚与补数据应急操作手册当必须手动补数据时绝不能直接hive -f必须走完整流程# 正确补数据步骤以补2024052005为例 # 1. 删除锁和完成标记 hadoop fs -rm /data/.lock/dt2024052005.* # 2. 手动执行Wrapper绕过crontab /opt/shell/etl_hourly_wrapper.sh 2024052005 # 3. 验证结果 hive -e SELECT COUNT(*) FROM ods.user_behavior_d WHERE dt2024052005注意Wrapper支持传参./etl_hourly_wrapper.sh 2024052005内部会跳过时间计算直接使用传入的dt。这个参数只用于应急禁止在crontab中使用。3.12 性能压测找出你的集群瓶颈点我们对不同参数组合做了72小时压测结论很反直觉参数测试值P95耗时问题现象mapreduce.map.memory.mb2048420sGC频繁Mapper OOMmapreduce.map.memory.mb4096280s最优平衡点mapreduce.map.memory.mb8192310s内存浪费YARN排队加剧hive.exec.reducers.max50350sReducer不足单个Reducer负载过重hive.exec.reducers.max100280s最优hive.exec.reducers.max200290sReducer过多Shuffle开销上升实测心得不要盲目堆内存。4GB Mapper内存 100 Reducer是大多数中型集群的甜点。压测时务必开启set hive.root.loggerDEBUG,console观察GC日志和Shuffle阶段耗时。4. 完整实操流程从零部署到稳定运行的7步清单4.1 第一步准备HDFS基础路径与权限登录Hadoop集群以hdfs用户执行# 创建数据根目录 hadoop fs -mkdir -p /data/raw/log hadoop fs -mkdir -p /data/.lock hadoop fs -mkdir -p /data/logs/hive_etl # 设置权限etl_user是运行用户hadoop是HDFS超级组 hadoop fs -chown -R etl_user:hadoop /data hadoop fs -chmod -R 750 /data/raw/log hadoop fs -chmod -R 770 /data/.lock hadoop fs -chmod -R 750 /data/logs/hive_etl # 验证 hadoop fs -ls -d /data/.lock # 应输出drwxrwx--- - etl_user hadoop 0 2024-05-20 10:00 /data/.lock提示-R递归设置避免子目录权限不一致。770对锁目录是必要的因为多个ETL任务可能共享同一锁目录。4.2 第二步编写Hive脚本etl_hourly.hql创建/opt/hive/scripts/etl_hourly.hql内容如下-- 设置执行参数 SET hive.exec.dynamic.partitiontrue; SET hive.exec.dynamic.partition.modenonstrict; SET hive.exec.max.created.files100000; -- 清洗原始日志示例Nginx access log CREATE TEMPORARY TABLE tmp_raw AS SELECT get_json_object(line, $.ip) as ip, get_json_object(line, $.time_local) as time_local, get_json_object(line, $.request) as request, get_json_object(line, $.status) as status, get_json_object(line, $.body_bytes_sent) as body_bytes_sent FROM ( SELECT explode( split( regexp_replace( regexp_replace( regexp_replace( cast(get_json_object(text, $.log) as string), \\\\n, \n), \\\\t, \t), \\\\r, \r), \n) ) as line FROM ( SELECT text FROM default.textfile WHERE input__file__name LIKE ${raw_path}/%.log ) t ) t2; -- 聚合到宽表示例按IP统计PV/UV INSERT OVERWRITE TABLE ods.user_behavior_d PARTITION(dt${dt}) SELECT ip, COUNT(*) as pv, COUNT(DISTINCT substr(time_local, 1, 13)) as uv_hour, MAX(CAST(status AS INT)) as max_status, SUM(CAST(body_bytes_sent AS BIGINT)) as total_bytes FROM tmp_raw WHERE ip IS NOT NULL AND time_local IS NOT NULL GROUP BY ip; -- 数据质量校验若行数1000标记为异常 INSERT INTO TABLE ods_etl_monitor SELECT ${dt} as dt, row_count_check as check_type, CASE WHEN COUNT(*) 1000 THEN FAIL ELSE PASS END as status, COUNT(*) as actual_count, 2024052005 as expected_min FROM ods.user_behavior_d WHERE dt${dt}; -- 在日志中打印校验结果供Shell层捕获 SELECT CONCAT(DATA_QUALITY_FAIL: row count , COUNT(*), 1000) FROM ods.user_behavior_d WHERE dt${dt} AND COUNT(*) 1000;注意input__file__name是Hive内置虚拟列可获取文件路径get_json_object解析嵌套JSON最后的SELECT CONCAT(...)会在Hive日志中输出明确字符串Shell层用grep即可捕获。4.3 第三步编写Shell Wrapperetl_hourly_wrapper.sh创建/opt/shell/etl_hourly_wrapper.sh完整代码如下含前面所有要点#!/bin/bash # Hive小时任务Wrapper脚本 # 支持传参./etl_hourly_wrapper.sh 2024052005 用于补数据 set -e # 任何命令失败立即退出 # 配置区 HIVE_HOME/opt/hive HADOOP_HOME/opt/hadoop LOG_DIR/tmp LOCK_ROOThdfs://namenode:8020/data/.lock RAW_ROOThdfs://namenode:8020/data/raw/log TARGET_TABLEods.user_behavior_d # 函数定义 get_business_hour() { local offset_hour${1:-1} local now_ts$(date %s) local hour_start_ts$(( (now_ts / 60) * 60 / 3600 * 3600 )) local target_ts$(( hour_start_ts - offset_hour * 3600 )) date -d ${target_ts} %Y%m%d%H } check_source_data() { local hdfs_path${RAW_ROOT}/${dt:0:8}/${dt:8:2} local valid_file_count$(hadoop fs -ls ${hdfs_path}/*.log 2/dev/null | \ awk $5 1048576 {print $8} | wc -l) if [ $valid_file_count -eq 0 ]; then echo ERROR: No valid log files in ${hdfs_path} return 1 fi return 0 } init_lock_file() { local lock_file${LOCK_ROOT}/dt${dt}.lock local done_file${LOCK_ROOT}/dt${dt}.done if hadoop fs -test -e ${done_file}; then echo INFO: Task for dt${dt} already completed. Skipping. exit 0 fi if hadoop fs -test -e ${lock_file}; then echo WARN: Lock file ${lock_file} exists. Check for zombie process. exit 1 fi echo $(date %Y-%m-%d %H:%M:%S) | hadoop fs -put - ${lock_file} } run_hive_script() { local hive_script/opt/hive/scripts/etl_hourly.hql local hive_vars-hivevar dt${dt} -hivevar raw_path${RAW_ROOT}/${dt:0:8}/${dt:8:2} -hivevar target_table${TARGET_TABLE} local yarn_opts--queue etl_hourly -hiveconf mapreduce.map.memory.mb4096 -hiveconf mapreduce.reduce.memory.mb8192 -hiveconf hive.exec.reducers.max100 timeout 3600s hive ${hive_vars} ${yarn_opts} -f ${hive_script} 21 | tee ${LOG_DIR}/hive_${dt}.log return $? } analyze_hive_log() { local log_file${LOG_DIR}/hive_${dt}.log if grep -E (Queue.*full|Connection refused|NameNode.*not active|Timeout) ${log_file} /dev/null; then return 2 elif grep -E (ParseException|Table not found|Permission denied|SemanticException) ${log_file} /dev/null; then return 3 elif grep -E DATA_QUALITY_FAIL: ${log_file} /dev/null; then return 4 else return 0 fi } send_alert() { local alert_type$1 local msg$2 local payload$(cat EOF { msgtype: text, text: { content: 【Hive小时任务告警】\n时间$(date)\n任务ETL_HOURLY\n窗口dt${dt}\n类型${alert_type}\n详情${msg}\n日志${LOG_DIR}/hive_${dt}.log\n负责人data-engineer } } EOF ) curl -X POST https://qyapi.weixin.qq.com/cgi-bin/webhook/send?keyxxx \ -H Content-Type: application/json \ -d ${payload} /dev/null 21 } cleanup_on_success() { local lock_file${LOCK_ROOT}/dt${dt}.lock local done_file${LOCK_ROOT}/dt${dt}.done hadoop fs -mv ${lock_file} ${done_file} } archive_logs() { local log_file${LOG_DIR}/hive_${dt}.log local archive_dirhdfs://namenode:8020/data/logs/hive_etl/$(date -d ${dt} %Y%m) hadoop fs -mkdir -p ${archive_dir} hadoop fs -put -f ${log_file} ${archive_dir}/hive_${dt}.log rm -f ${log_file} find /tmp -name hive_*.log -mtime 30 -delete } # 主流程 # 解析参数支持传入dt否则自动计算 if [ $# -eq 1 ]; then dt$1 echo INFO: Using manual dt${dt} else dt$(get_business_hour 1) echo INFO: Auto-calculated dt${dt} fi # 初始化 start_time$(date %s) # 步骤1检查源数据 if ! check_source_data; then send_alert data_missing Source data directory empty for dt${dt} exit 1 fi # 步骤2初始化锁 init_lock_file # 步骤3执行Hive if ! run_hive_script; then # 分析失败原因 analyze_hive_log case $? in 2) send_alert retryable Transient YARN/HDFS error for dt${dt}; exit 1;; 3) send_alert manual Syntax or schema error. Check Hive log.; exit 1;; 4) send_alert data_quality Data validation failed for dt${dt}; exit 0;; # 不阻塞 *) send_alert unknown Unknown failure. Check log.; exit 1;; esac fi # 步骤4清理与归档 cleanup_on_success archive_logs # 步骤5输出指标可选 duration_sec$(( $(date %s) - start_time )) echo INFO: Task dt${dt} completed in ${duration_sec}s提示set -e是关键确保任何子命令失败立即终止避免状态不一致。保存后执行chmod x /opt/shell/etl_hourly_wrapper.sh。4.4 第四步配置crontab与日志轮转以etl_user身份执行# 编辑crontab crontab -e # 添加一行 */5 * * * * /opt/shell/etl_hourly_wrapper.sh /var/log/etl_hourly_cron.log 21 # 配置logrotate/etc