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。

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

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