flink基于1.5的定制化开发工作就告一段落了,业务团队对flink的诉求已经超越1.5了,

主要集中在table、sql、state上,还有2phase的filesink等。

1.7 or 1.8

一个大的社区版本一般要维护1年左右。1.5的社区版我们从18年6月维护到现在,

但从去年年底开始社区就对1.5停更了,我们只能自己从其他的版本中merge一些需要的bugfix。

我们决定下一个大版本是1.8,主要基于一下几点:

  • 社区1.9的巨大投入会严重影响其他分支的更新速度,1.7已经进入暮年。

  • 1.8的一些小特性我们看来还是非常实用的,值得蹚雷。

  • 刚刚准备release-1.8.1,未来还能从社区得到3-4个小版本。

  • 1.9的更新过于巨大,真正稳定下来需要比较长的时间,1.8在未来一年多应该是首选。

合并

1.8.1的一些issue被社区移到1.8.2去完成,所以很快就进入了RC阶段。

我们在1.8分支上,进行了merge工作,主要是把我们在1.5上的定制工作迁移到1.8。

合并的工作开展速度还是挺快的,预计2周左右就可以完成,顺手可以做一些小的重构。

未来

在1.8的基础工作完成后,我们就要投入到Sql方向了。

Sql的方向需要一些铺垫,比如State的管理功能增强,数据Table化等。

State增强

flink的state是核心组件,无论是故障恢复还是恰好一次,都至关重要。

但是State的管理功能并不完善,比如如何让savepoint周期性的触发,

如何合理利用checkpoint来恢复等。

数据Table化

Flink的数据来源其实是比较集中的,大部分来自Kafka或者MQ。

再经过一些反序列化工作,应该可以映射为Pojo或者说Table。

这部分工作在其他公司里也是差不多的,做一些定制化的开发,并不难。

但是一些数据质量高的公司做这一步就非常快,比如格式比较统一等。