问题描述

Presto Join 查询导致 Internal error

qianmoQ

—

通过字面意思我们可以判断出来是系统内部出现了问题？那么该问题是怎么产生的呢？

该问题产生是一般是在使用Presto进行了Join关联查询，导致关联的两个表中的关联字段不一致导致的。

问题复原

—

比如我有两个数据表，分别是t1表和t2表，他们的表结构分别是：

t1表结构

列名	类型
c1	bigint
c2	bigint

t2表结构

列名	类型
c1	bigint
c2	varchar (hive中是string)

当我们使用以下两个SQL查询时，会出现不通的结果

select
    t1.c1, t2.c1
from t1 as t1
left join t2 as t2
on t1.c1 = t2.c1
limit 1

在Presto中我们运行以上sql是可以正确拿到查询结果的，但我们换作以下SQL就会出现不同的结果

select
    t1.c2, t2.c2
from t1 as t1
left join t2 as t2
on t1.c2 = t2.c2
limit 1

此时运行SQL就会出现Internal error错误信息

解决思路

—

单单通过返回Internal error的错误信息我们是无法获取到有效的信息的，但是我们细心观察会发现

在t1表中的c2字段的类型是bigint，然而在t2表中的c2字段是varchar类型的

这样我们会的出一个结论就是由于两个表的字段类型不一致而产生了这个错误，既然知道了错误，解决也就简单了

我们尝试对关联表的关联字段做cast转换，转换为同一类型，修改后的sql如下

select
    t1.c2, t2.c2
from t1 as t1
left join t2 as t2
on cast(t1.c2 as varchar) = cast(t2.c2 as varchar)
limit 1

运行修改后的sql可以正常查询出来有效的结果，为了方便用户，建议写SQL的时候做一下操作(前提是使用Presto引擎查询)

在做关联查询的时候，将双表的关联字段做成cast(xxxx as varchar), 当然转换为其他的类型也可以

小助手

标题：Presto Join 查询导致 Internal error：谁该为此负责？

Dear论坛用户，

今天我要讨论一个与Presto Join 查询相关的问题，即导致Internal error的情况。在最近的论坛讨论中，众多用户纷纷抱怨他们在使用Presto Join 查询时遇到了问题，并收到了Internal error的错误消息。这引发了一场关于谁该为此负责的争论。

一方面，有人认为Presto Join 查询出错是由于该查询引擎本身的问题造成的。他们指出，Presto是一个分布式SQL查询引擎，被广泛用于处理大规模数据处理和分析。作为一个开源项目，Presto的稳定性和性能一直是用户们关注的焦点。如果Presto Join 查询导致了Internal error，这可能意味着Presto在处理复杂的Join操作时出现了一些内部bug。因此，他们认为Presto的开发者应该要承担起修复该问题的责任，并尽快解决这个bug。

另一方面，也有人认为问题并不完全是Presto自身的错。他们指出，Join操作的复杂度很高，需要在多个表进行数据匹配，这很容易导致资源消耗过多，从而引发Internal error。因此，他们主张查询的设计者和开发者也应该对查询的性能和稳定性负责。他们认为在进行Join查询时应该慎重考虑数据量和服务器资源，以避免超出系统的承载能力。

这场讨论引发了对Presto Join 查询的一些问题的思考。例如，我们应该如何确保数据的合理性和完整性？是否存在其他解决Join查询问题的方法，例如分布式数据库或增加服务器资源？希望在讨论中能有更多的专业人士和开发者加入，为解决这个问题提供更多的见解和建议。

总的来说，Presto Join 查询导致Internal error的问题引起了广泛的关注和讨论。无论是Presto的开发者还是查询的设计者和开发者，都应该对此负起责任。通过共同努力，我们有理由相信这个问题将会得到解决，从而提升各种数据处理和分析任务的效率和稳定性。

谢谢。

（讨论参与者：Presto用户、开发者、查询设计者、数据分析师等）