flink sql 知其所以然（十八）：在 flink 中还能使用 hive udf？附源码

1.序篇

源码公众号后台回复1.13.2 sql hive udf获取。

废话不多说，咱们先直接上本文的目录和结论，小伙伴可以先看结论快速了解博主期望本文能给小伙伴们带来什么帮助：

1. 背景及应用场景介绍：博主期望你能了解到，其实很多场景下实时数仓的建设都是随着离线数仓而建设的（相同的逻辑在实时数仓中重新实现一遍），因此能够在 flink sql 中复用 hive udf 是能够大大提高人效的。

2. flink 扩展支持 hive 内置 udf：flink sql 提供了扩展 udf 的能力，即 module，并且 flink sql 也内置了 HiveModule（需要你主动加载进环境），来支持一些 hive 内置的 udf （比如 get_json_object）给小伙伴们使用。

3. flink 扩展支持用户自定义的 hive udf：主要介绍 flink sql 流任务中，不能使用 create temporary function 去引入一个用户自定义的 hive udf。因此博主只能通过 flink sql 提供的 module 插件能力，自定义了 module，来支持引入用户自定义的 hive udf。

2.背景及应用场景介绍

其实大多数公司都是从离线数仓开始建设的。相信大家必然在自己的生产环境中开发了非常多的 hive udf。随着需求对于时效性要求的增高，越来越多的公司也开始建设起实时数仓。很多场景下实时数仓的建设都是随着离线数仓而建设的。实时数据使用 flink 产出，离线数据使用 hive\spark 产出。

那么回到我们文章标题的问题：为什么需要 flink 支持 hive udf 呢？

博主分析了下，结论如下：

站在数据需求的角度来说，一般会有以下两种情况：

1. 以前已经有了离线数据链路，需求方也想要实时数据。如果直接能用已经开发好的 hive udf，则不用将相同的逻辑迁移到 flink udf 中，并且后续无需费时费力维护两个 udf 的逻辑一致性。

2. 实时和离线的需求都是新的，需要新开发。如果只开发一套 udf，则事半功倍。