Presto 自定义函数 @SqlNullable 血泪史

qianmoQ

看到标题我们会想到是由于@SqlNullable注解引发的问题，我们先看一段代码，正是这段有意思的代码，让我纠结了2个多小时，引发了Presto的问题。

@Description("user_id")
@ScalarFunction("user_id")
@SqlType(StandardTypes.VARCHAR)
public static Slice userId(@SqlType(StandardTypes.VARCHAR) Slice value) {
    String _value = value.toStringUtf8();
    if (StringUtils.containsWhitespace(_value)) {
        _value = StringUtils.replace(_value, " ", "+");
    } 
    return Slices.utf8Slice(makeErrorMsgBase64(_value));
}

这段代码很简单，就是我们将传递进来的base64的字符串解码成实际的字符串，单单从代码上看是不会有什么问题的。当我们实际运行这个函数的时候问题就出现了，以下是一个使用示例：

select user_id(str) from temp.users limit 100;

看执行的SQL似乎也没有什么异常，但就是这么简简单单的一个函数引发了Presto的问题，那就是java.lang.NullPointerException: undefined错误，这个错误的具体内容如下

java.lang.NullPointerException: undefined
	at io.prestosql.type.VarcharOperators.equal(VarcharOperators.java:53)
	at io.prestosql.$gen.CursorProcessor_20200927_063218_2398.filter(Unknown Source)
	at io.prestosql.$gen.CursorProcessor_20200927_063218_2398.process(Unknown Source)
	at io.prestosql.operator.ScanFilterAndProjectOperator$RecordCursorToPages.process(ScanFilterAndProjectOperator.java:323)
	at io.prestosql.operator.WorkProcessorUtils$ProcessWorkProcessor.process(WorkProcessorUtils.java:372)
	at io.prestosql.operator.WorkProcessorUtils.getNextState(WorkProcessorUtils.java:221)
	at io.prestosql.operator.WorkProcessorUtils$YieldingProcess.process(WorkProcessorUtils.java:181)
	at io.prestosql.operator.WorkProcessorUtils$ProcessWorkProcessor.process(WorkProcessorUtils.java:372)
	at io.prestosql.operator.WorkProcessorUtils.getNextState(WorkProcessorUtils.java:221)
	at io.prestosql.operator.WorkProcessorUtils.lambda$processStateMonitor$2(WorkProcessorUtils.java:200)
	at io.prestosql.operator.WorkProcessorUtils$ProcessWorkProcessor.process(WorkProcessorUtils.java:372)
	at io.prestosql.operator.WorkProcessorUtils.lambda$flatten$6(WorkProcessorUtils.java:277)
	at io.prestosql.operator.WorkProcessorUtils$3.process(WorkProcessorUtils.java:319)
	at io.prestosql.operator.WorkProcessorUtils$ProcessWorkProcessor.process(WorkProcessorUtils.java:372)
	at io.prestosql.operator.WorkProcessorUtils$3.process(WorkProcessorUtils.java:306)
	at io.prestosql.operator.WorkProcessorUtils$ProcessWorkProcessor.process(WorkProcessorUtils.java:372)
	at io.prestosql.operator.WorkProcessorUtils.getNextState(WorkProcessorUtils.java:221)
	at io.prestosql.operator.WorkProcessorUtils.lambda$processStateMonitor$2(WorkProcessorUtils.java:200)
	at io.prestosql.operator.WorkProcessorUtils$ProcessWorkProcessor.process(WorkProcessorUtils.java:372)
	at io.prestosql.operator.WorkProcessorUtils.getNextState(WorkProcessorUtils.java:221)
	at io.prestosql.operator.WorkProcessorUtils.lambda$finishWhen$3(WorkProcessorUtils.java:215)
	at io.prestosql.operator.WorkProcessorUtils$ProcessWorkProcessor.process(WorkProcessorUtils.java:372)
	at io.prestosql.operator.WorkProcessorSourceOperatorAdapter.getOutput(WorkProcessorSourceOperatorAdapter.java:149)
	at io.prestosql.operator.Driver.processInternal(Driver.java:379)
	at io.prestosql.operator.Driver.lambda$processFor$8(Driver.java:283)
	at io.prestosql.operator.Driver.tryWithLock(Driver.java:675)
	at io.prestosql.operator.Driver.processFor(Driver.java:276)
	at io.prestosql.execution.SqlTaskExecution$DriverSplitRunner.processFor(SqlTaskExecution.java:1076)
	at io.prestosql.execution.executor.PrioritizedSplitRunner.process(PrioritizedSplitRunner.java:shichengoooo@163.com)
	at io.prestosql.execution.executor.TaskExecutor$TaskRunner.run(TaskExecutor.java:484)
	at io.prestosql.$gen.Presto_341____20200925_110330_2.run(Unknown Source)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
	at java.base/java.lang.Thread.run(Thread.java:834)

通过上面错误我们推算出应该是由于数据导致空指针异常，那么问题出在哪里呢？问题就出在查询str这个字段中，这个字段我们经过实际的查询发现是有’'的数据，在做转换的时候出现了空指针问题，于是我们修改UDF的源码为

@Description("user_id")
@ScalarFunction("user_id")
@SqlType(StandardTypes.VARCHAR)
@SqlNullable
public static Slice userId(@SqlNullable @SqlType(StandardTypes.VARCHAR) Slice value) {
    String _value = value.toStringUtf8();
    if (StringUtils.containsWhitespace(_value)) {
        _value = StringUtils.replace(_value, " ", "+");
    } 
    return Slices.utf8Slice(makeErrorMsgBase64(_value));
}

我们在方法和参数上添加了@SqlNullable注解用于标记此函数可以接收空的数据，这似乎看着也没有问题，我们将该函数重新发布，再次执行SQL发现还存在相同的问题，于是又将代码修改为以下内容

@Description("user_id")
@ScalarFunction("user_id")
@SqlType(StandardTypes.VARCHAR)
public static Slice userId(@SqlNullable @SqlType(StandardTypes.VARCHAR) Slice value) {
    String _value = value.toStringUtf8();
    if (StringUtils.containsWhitespace(_value)) {
        _value = StringUtils.replace(_value, " ", "+");
    } 
    return Slices.utf8Slice(makeErrorMsgBase64(_value));
}

删除了方法上的@SqlNullable注解，再次运行发现不会再出现这个错误，但是Presto服务中不断的报出空指针错误，只是不在反馈给查询客户端，原本以为此问题已经解决，然而更有意思的事情发生了，我们使用了343版本测试成功后，线上版本是341，升级线上后发现此问题再次复现，如果再次在方法上加上@SqlNullable注解在341版本上又会修复这个问题，目前已将这个问题反馈给官方，推荐大家使用343版本！

小助手

标题：Presto 自定义函数 @SqlNullable 血泪史：是进步还是陷阱？

近年来，Presto 数据处理引擎在大数据领域中获得了广泛的关注和使用。然而，其自定义函数 @SqlNullable 的引入引起了一些争议和讨论。在这篇文章中，我们将探讨这一功能的价值、问题和可能的解决方案。

Presto 引入 @SqlNullable 的初衷是为了处理与 NULL 值相关的语义问题。然而，该功能在实际使用中却遭遇了许多困扰。一方面，@SqlNullable 可以使开发人员在函数定义中指定参数是否接受 NULL 值。这为数据处理提供了更大的灵活性和兼容性。另一方面，这也导致了一些难以解决的问题。

让我们通过一些真实案例来看看这一争议的本质。用户A在论坛上提出了一个问题：为什么在使用带有 @SqlNullable 注解的函数时，Presto 在处理 NULL 值时会抛出异常，而不是返回 NULL 值呢？用户B认为这是Presto自定义函数处理NULL值语义的一个缺陷，应该被修复。然而，用户C则表示，异常的抛出是为了避免潜在的错误和数据不一致性。他认为，如果函数在接受 NULL 值的情况下返回 NULL 值，可能会导致不符合预期的结果，并掩盖潜在的错误。

这引发了一场激烈的讨论，涉及了Presto引擎设计团队、开发者和用户社区。有人主张保留抛出异常的行为，以确保代码的健壮性和数据处理的准确性。而另一些人则持有修改引擎行为的观点，认为返回NULL值更符合用户预期和常见的编程习惯。双方围绕@SqlNullable 的效果和预期目标展开了激烈的争论。

面对这个问题，Presto 引擎团队面临着一个艰难的抉择。是维持当前的异常抛出行为，以确保数据处理的可靠性，还是修改引擎，使其返回 NULL 值，从而更符合用户预期？这不仅涉及到技术和语义层面的考量，也关乎到一种编程语言和工具的哲学。

无论最终如何决定，Presto 引擎团队值得感谢的是，他们通过引入 @SqlNullable 功能，促使了这一重要的讨论。这个争论不仅展示了开发者和用户对于数据处理语义问题的关注，也为 Presto 引擎的未来发展提供了指引和启示。

在这个快速发展的技术世界中，每一个新功能都可能伴随着问题和讨论。正是通过这些讨论和争议，我们才能不断优化和改进技术，使其更加适应真实需求。希望Presto 引擎团队能够在这些争议中找到最佳的解决方案，为我们提供更加强大和灵活的数据处理工具。