Flink Sql DDL创建kafka avro格式问题 （Caused by: java.lang.ArrayIndexOutOfBoundsException: 14 Flink avro）

按照官网给出模板进行搭建 创表

create table dwd_pv_realtime( ip STRING  , uid STRING , oid STRING , `day` STRING ) with( 'connector' = 'kafka',  'topic' = 'flink_test',  'properties.bootstrap.servers' = 'x',  'properties.group.id' = 'testGroup',  'scan.startup.mode' = 'latest-offset',  'format' = 'avro' )   tableEnv.sqlUpdate(pvsql)

配置项都跟着官网走，结果配置运行直接出错。

 

一看我的天，数组下标越界？？？ 我测试总共才4个字段 怎么可能的啊。

一开始怀疑是在创建字段的时候使用了 其 保留的关键字 day, 所以导致它内部解析异常之类的。 然后简单的去掉发现 并没有任何改变依旧报错。

这时候只能先去官方看是不是有别的format 关于avro的 或者 别的参数可以设置。 有两点发现：

1. 在官方文档1.10的时候 我们可以设置 avro的schema， 但是我们使用的是最新的1.12版本 （放弃）
2. format还支持另一种格式的avro   confluent avro 一种定制的格式【（需要搭建schema register 服务）我们在序列化的时候都没有使用到，反序列化更不可能是这个问题】

没有更多的资料了。。谷歌 百度也没有合适的解释 只是简单的说字段名没匹配 或者 需要使用 confluent avro。 

解决

最后只能去源码一步一步debug， 然后就有了惊奇的发现。

发现的readFiled的时候 它总是会匹配到 union这个类型， 我们命名定义的是string, int 基础类型。

 

关于avro的schema 再次去确认了一下我们之前定义了，并没有这种数组类型【null, string】， 所以就只可能是flink在解析的时候 自动生成的了。

我们继续前推，看是如何生成的。 

 

我们直接找到Scheam这个类 然后看相关的生成代码，发现在匹配我们字段类型的时候 会有第一个是否为null的判断 布尔值 （这里默认一般为true）， 然后下面就是 flink 与 avro对应的字段类型然后进行匹配返回。

 

可以看到具体的返回 值 跟nullable有关系， 上面默认为true 那就是返回第一个 nullableSchema(str) 我们进去看下具体逻辑

 

发现这返回的不就是我们最开始的那个scheam type数据组嘛， 好家伙 就是在这里给生成的。 然后看为什么 原因是scheam.isNullable() 这个判断是说 我们的当前字段类型是否为null 那我们是string 所以不是null类型，所以就返回后者的值 【null, string】

然后返回到上一步

 

因为上面nullable默认是true， 所以会给我们返回nullableSchema方法的值 得到一个类型数组 导致后续的一个报错。

这个时候我们就有两个解决方案：

1. 在nullableSchema(str) 方法让其返回 string， 刚刚也看到这个函数方法判断是 当前字段类型是否为null类型， 这个怎么也达不到啊。故放弃
2. 使我们的nullable 为false 然后直接返回其string类型。 这个可行，具体实施手段  在创建ddl的时候  字段后面加not null

困扰了3天的问题终于找到。。。 各种排查 字段类型，字段名称不匹配， 在序列化的写入kafka时候，jar包冲突 都不行。 最终通过排查源码的方式解决

最终sql

create table dwd_pv_realtime( ip STRING  not null, uid STRING not null, oid STRING not null ) with( 'connector' = 'kafka',  'topic' = 'flink_test',  'properties.bootstrap.servers' = 'x',  'properties.group.id' = 'testGroup',  'scan.startup.mode' = 'latest-offset',  'format' = 'avro' )

最后看到结果输出的时候 眼泪都要掉下来了