Status

Current state: "Under Discussion"

Discussion thread: http://apache-flink-mailing-list-archive.1008284.n3.nabble.com/Discussion-FLIP-79-Flink-Function-DDL-Support-td33965.html

JIRA: https://issues.apache.org/jira/browse/FLINK-7151

Released: 

Please keep the discussion on the mailing list rather than commenting on the wiki (wiki discussions get unwieldy fast).

Motivation

This proposal aims to support function DDL with the consideration of SQL syntax, language compliance, and advanced external UDF lib registration.

The Flink DDL is initialized and discussed in the design [1] by Shuyi Chen and Timo. As the initial discussion mainly focused on the table, type and view.

FLIP-69 [2] extend it with a more detailed discussion of DDL for catalog, database, and function. Original the function DDL was under the scope of FLIP-69.

After some discussion with the community, we found that there are several ongoing efforts, such as FLIP-64 [3], FLIP-65 [4], and FLIP-78 [5]. As they will

directly impact the SQL syntax of function DDL, the proposal wants to describe the problem clearly with the consideration of existing works and make sure

the design aligns with efforts of API change of temporary objects and type inference for UDF defined by different languages.

Proposed Changes

Requirements

Before deep into the DDL SQL, we want to discuss the major requirements for defining a function within Flink runtime by related FLIPs:

• External lib registration. The requirements come from the hive integration that enhances the adoption of Flink batch. HQL supports syntax like:

• Language distinction. Due to bytecode language specifics in Scala, there are some limitations to extract type information from scala function. 

           At the same time, support python UDF in table runtime is another ongoing effort. Thus, the SQL syntax needs to consider supporting multiple languages.

           Mysql create function syntax support language in this way: 

• Temporary Function Support. FLIP-57 proposes to distinguish temporary and non-temporary functions for both catalog and system.

           As a temporary function will be registered only for the current session. It requires a flag from DDL to distinguish the function resolution order.

• Function Qualifier. Functions identifiers resolution consider object scopes whether in particular catalog, database or just current catalog and database.

          Thus, all of the function DDL needs to support 3-part path.

Function DDL SQL Syntax

Create Function Statement

Drop Function Statement

Alter Function Statement

Show Function Statement

Use Cases

We want to use the function syntax to support all potential use cases. Below we list some obvious use cases that can be achieved.

Load UDF from Classpath

In this case, the assumption is that the UDF classes are already in the classpath. Thus, we just need to get the class object by reflection, determine whether it is UDF, UDAF or UDTF,  and register it to TableEnvironment.

Load UDF from a remote resource

n this case, the user can use a class that is not the local classpath. In the example above, the function NestedOutput is contained in a jar that is released to artifactory.

Using this type of model, we can split the user level logic from the platform. Each team can write and own its own UDF library. A Flink platform is just responsible to load it into classpath and use it.

We will discuss how to achieve it in the later section. Basically, the resource URL will be added as a user library in the execution environment. It will be added into a job graph,

and ship to the storage layer, such as hdfs before job submission.

Load python UDF from a remote resource

New or Changed Public Interfaces

The first change needed is to add more functions in CatalogFunction interface.

In order to support loading external libraries and create UDFs from external libraries, we need to add a function in ExecutionEnvironment to register external libraries.

Before the job submission, register user jars will be added into StreamGraph, and then be added into JobGraph in the JobGraphGenerator. 

To consider the isolation of class loading of different session, we can use Add a new interface in {Stream}ExecutionEnvironment. 

           registerUserJarFiles(name, jarFiles...) 

The interface register a set of Jar files with key name. Internally, it uses similar path as registerCachedFile(), which distributes the Jar files to runtime using Flink’s Blob Server. 

Also, add a new interface in RuntimeContext to create and cache a custom userCodeClassLoader using the Jar file set registered under name. 

          getClassLoaderWithName(name)

During code generation of the UDF function call, it will load the set of Jar files that are associated with the library into a custom classLoader, and invoke the function reflectively.

Also, inside RuntimeContext implementation, we will keep a cached of all loaded custom classLoader so we wont load the same library multiple times.

For different language support, the implementation will be different, here we just discuss the API needed for java/scala libs.

Implementation plan

From an implementation perspective, we want to provide function syntax align with multiple language support, but limit the scope only in java and scala.

The python udd related support will be discussed and implemented in the scope of FLIP-78. The concrete action items include

Flink 1.10 Release

1. Add function related syntax in Flink SQL parser.
2. Define SqlCreateFunction and SqlDropFunction in flink-sql-parser module
3. Bridge DDL to register the function into Table environment

After Flink 1.10

1. Support UDF loading from an external resource for java
2. Add scala function related support

As FLIP-65  New type inference for Table API UDFs is a blocker for adding scala function into TableEnvImpl. 1), 2) and 3) will only support language java. 4) is for adding a function

into the table environment with remote resources.  Once the FLIP-65 is done, we can continue the work of supporting language Scala, and corresponding function registration into TableEnvImpl.

Migration Plan and Compatibility

It is a new feature for Flink DDL, there is no migration needed.

Rejected Alternatives

The function DDL syntax considered about existing requirements. No rejected alternatives yet.

References 

[1] Flink SQL DDL Design  

[2] FLIP-69 Flink SQL DDL Enhancement

[3] FLIP-64 Support for Temporary Objects in Table module

[4] FLIP-65 New type inference for Table API UDFs

[5] FLIP-78 Flink Python UDF Environment and Dependency Management