关于UDF可扩展性的思考

UDF按照我们日常使用分为三类：

工具类UDF

比如 MD5, ip解析，字符串转json等
一般而言工具类udf包括自身自带的udf(max, min, string转换等)，还包括第三方需要添加的特殊udf(比如userid加解密，自定义编码，hash，json等)

单独业务解析UDF

比如acm打点日志转换成json, url特殊转换
单独业务解析的UDF，只适用于某一种业务场景，比如针对acm打点解析json以及各种容错处理，或者一些需要调用第三方存储动态适配的场景。

动态业务UDF

针对记录中的不同字段动态确定一种业务类型
动态业务UDF主要针对一些动态适配的场景，比如电商的场景下有直播，内容，导购，电商等等业务类型，不同的业务类型都包含不同字段不同的的匹配方式。

使用场景

绝大多数的使用场景是hive, sparkSql, flinkSql,或者是dsl中。
我们一般的使用方式主要是代码打成jar包，jar可以用过临时加载或者永久加载的方式。jar包放到hdfs或者maven仓库中。

针对实时和离线的场景下，以及不同引擎加载方式的不同，一般而言只要有通用的文档说明，以及代码的统一管理，问题一般是不大的。

一般业务解析UDF都是有一定的业务含义，只能用在某些场景下。一般而言，UDF的通常是由数据平台同学开发的。具体的口径通过数仓同学口述而来。

举个例子，实时数据Flink有自己的UDF, 离线数据hive有自己的UDF. 在某一天某一块业务变更，有多个地方使用不同的UDF来解决相同的问题，而这些UDF有些是历史的包袱，有些是不同平台开发的。在修改的时候，总会存在gap.

在举个例子， 在离线数仓的场景下，离线模型一般都是按照ods -> dwd -> dws，在业务比较小的时候，一般都是一两个人开发，但是在业务已经很大的情况下，势必会根据业务线进行划分，在dws层可能会根据不同的业务线形成自己的数据集市。但是这些表大部分数据都是相同的，只有一些特殊的字段解析，如果未来又增加一些其他的业务线，是否还需要新的开发同学去开发？

思考

所以未来在UDF扩展性上面需要考虑一下几个问题：

• 数据是根据业务线分开管理还是在上游整合到一起。
• UDF能否快速适应业务变更的需求。
• 口径的管理怎么统一化。

关于业务线整合的问题，其实一直都有争论，分开和结合都是有利有弊。以下我只以小厂的经验来谈，在小厂里面业务变化迭代速度是很快的，在人员有限的情况下，如果上新的业务，怎么才能保障实时，离线口径的统一，怎么才能以最小的成本查询新的业务指标。其实这个还是和数仓建模密不可分。

UDF要能适应业务变更，一般来说不是普通的数据解析，而是解析的过程涉及到各种不同的业务，必须要做到动态配置，配置的所有权归于业务方(比如数仓)。所以在这种情况下就需要做一个配置平台，所有UDF 匹配的条件，匹配的结果都能过配置平台的方式对业务方提供服务，只要配置就能够及时生效，业务就能够做到自动化。

口径的问题是一个老大难的问题，对于不同的语言，UDF的封装方式都是不一样的，但是核心的逻辑是一样的，如果能保障统一性，我觉得重要的方式就是通过代码的继承和复用的关系，同一个工程，同一套代码来保障。更高级的方式是不同的计算引擎能够兼容不同的UDF, 比如flink能够兼容hive的UDF。这样就更好点。