morningman opened a new issue #8389:
URL: https://github.com/apache/incubator-doris/issues/8389


   ### Search before asking
   
   - [X] I had searched in the 
[issues](https://github.com/apache/incubator-doris/issues?q=is%3Aissue) and 
found no similar issues.
   
   
   ### Description
   
   ## Backgroup
   Doris currently supports both [Native 
UDF](http://doris.incubator.apache.org/zh-CN/extending-doris/udf/native-user-defined-function.html)
 and [Remote 
UDF](http://doris.incubator.apache.org/zh-CN/extending-doris/udf/remote-user-defined-function.html)
 for user-defined functions.
   
   Native UDF is written in C++ and has the best performance, but it is more 
difficult to write and debug, and may be limited by some system library 
versions(such as libc) that may not be compatible after upgrade.
   
   Remote UDF solves the language problem very well, and in theory, UDF logic 
can be written in any language. But the disadvantage is that users need to 
implement their own high-performance UDF Service, and the efficiency is not 
good because of the RPC problem.
   
   ## Motivation
   
   Support for Java UDF is motivated by the following points:
   
   1. the Java language is widely used, rich support for related library 
functions, and a low threshold for development and debugging.
   2. Some big data ecologies such as Hive, Spark, etc. already exist a large 
number of ready-made UDF, we need to be compatible with these udf to reduce the 
migration costs of users.
   3. If there is bug in UDF, it will not cause BE crash
   
   ## How to implement
   
   Need to start the JVM and call the relevant UDF logic from the BE side by 
way of JNI.
   
   ### Use case
   
   _No response_
   
   ### Related issues
   
   _No response_
   
   ### Are you willing to submit PR?
   
   - [ ] Yes I am willing to submit a PR!
   
   ### Code of Conduct
   
   - [X] I agree to follow this project's [Code of 
Conduct](https://www.apache.org/foundation/policies/conduct)
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]



---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to