有需求,给几百条记录疑似信息被外界通过某api探测出是否我行客户,进行了相关的诈骗。
需分析可能是那些api访问探测的。
数据仓库中五六千个api,就算定位含相关字段的接口也有近千个,并非每个映射成了某标准化字段,没有映射标准化的字段,都使用json嵌套放置在单独的一列了。
即需要标准化的用户id进行in查询,也需要在混合所有非标准化数据的那列进行 like查询,得到所有记录。
然后presto sql爆了compile failed。
怀疑是sql太长了,二分法、手动调整 or like 查询个数极限。然后减少其他字符的长度,例如 api in的查询 集合大小,再增加一个 or like 条件,还是会compile failed。
说明,有些查询引擎,不仅有长度限制、也有条件组合个数限制。