如何提升Hive SQL脚本的可组合性与复用性？求INCLUDE/IMPORT类方案

作为常年和Hive ETL打交道的开发者，我太懂重复写相同逻辑的痛苦了。下面分享几个我和团队实践过的、能有效解决DRY问题的方案，覆盖从原生Hive特性到工程化手段的不同场景：

一、用Hive原生source命令实现"伪导入" #

Hive虽然没有官方的INCLUDE/IMPORT，但自带的source命令完全可以满足基础的代码复用需求：

• 把重复的通用逻辑（比如分区配置、UDF注册、常用过滤条件）单独存成独立的.hql文件，比如common_configs.hql：

  -- common_configs.hql
  SET hive.exec.dynamic.partition=true;
  SET hive.exec.dynamic.partition.mode=nonstrict;
  -- 定义通用的近7天过滤条件
  SET hiveconf:filter_recent_7d = dt >= date_sub(current_date(), 7);
  

• 在主ETL脚本里通过source引入这个文件，直接复用里面的配置和变量：

  -- main_user_etl.hql
  source /etl/scripts/common_configs.hql;
  
  SELECT id, name, phone
  FROM raw.user_info
  WHERE ${hiveconf:filter_recent_7d};
  

• 运行时还能通过-hiveconf覆盖变量，适配不同的业务场景：

  hive -hiveconf filter_recent_7d="dt >= '2024-01-01'" -f main_user_etl.hql
  

二、用视图/物化视图封装重复查询逻辑 #

对于频繁出现的子查询或数据清洗逻辑，视图是最直接的复用方式：

• 把常用的清洗、过滤逻辑封装成视图：

  CREATE VIEW vw_cleaned_order_data AS
  SELECT
    order_id,
    user_id,
    regexp_replace(addr, '[^\\u4e00-\\u9fa50-9]', '') AS clean_addr,
    pay_amount,
    dt
  FROM raw.order_info
  WHERE pay_status = 'success';
  

• 后续所有需要用到清洗后订单数据的ETL任务，直接引用这个视图即可，不用重复写清洗逻辑：

  SELECT user_id, sum(pay_amount) AS total_spend
  FROM vw_cleaned_order_data
  WHERE dt >= '2024-01-01'
  GROUP BY user_id;
  

• 如果数据量较大、查询频繁，可以改用物化视图预先计算结果，既复用逻辑又提升查询性能。

三、用自定义UDF封装业务计算逻辑 #

对于重复出现的字段转换、复杂计算（比如手机号脱敏、金额换算），封装成UDF是更优雅的解决方案：

• 比如我们团队经常需要对手机号做脱敏处理，就写了一个mask_phone UDF，注册后在所有脚本里直接调用：

  SELECT mask_phone(phone_number) AS masked_phone, name
  FROM raw.user_info;
  

• UDF的注册语句可以放在通用脚本里，通过source统一引入，避免每次都重复写注册代码。

四、工程化进阶：用预处理器实现灵活的脚本导入 #

如果你的团队有一定工程化能力，可以用Python/Shell写一个简单的预处理器，实现类似模板引擎的导入功能：

• 比如在主脚本模板里用{{ include 'common_filters.hql' }}标记需要导入的片段，然后用Python脚本替换成实际内容：

  # preprocess_hql.py
  with open("main_etl.template.hql", "r") as f:
      content = f.read()
      # 替换导入标记
      content = content.replace("{{ include 'common_filters.hql' }}", open("common_filters.hql").read())
  # 生成最终可执行的HQL文件
  with open("main_etl.hql", "w") as f:
      f.write(content)
  

• 这种方式还能支持变量替换、条件编译，适合复杂的多场景ETL任务。

五、团队规范层面：维护公共脚本库与模板 #

最后，制定团队统一的规范也很重要：

• 建立共享的公共脚本仓库，把通用的配置片段、视图定义、UDF注册语句都放在里面，所有人都可以直接引用。
• 定义统一的ETL脚本模板，比如固定开头的环境配置、中间的通用过滤、结尾的分区写入逻辑，新任务直接基于模板修改，减少重复编写基础代码。

我自己日常工作中，主要是source命令+视图+UDF的组合拳：通用配置用source引入，复杂查询逻辑用视图封装，业务计算用UDF。对于跨任务的通用逻辑，我们团队维护了一个公共脚本库，新任务直接拿过来用，能省不少重复劳动。

内容的提问来源于stack exchange，提问作者bcollins