Flink 靠什么征服饿了么工程师？(3)

★ 3.2 Exactly-once

[原创文章：www.11jj.com]

[好文分享：www.11jj.com]

exactly-once需要特别注意一个点：

我们必须要求数据sink到外部存储后，，offset才能commit，不管是到zk，还是mysql里面，你最好保证它在一个transaction里面，而且必须在输出到外部存储（这里最好保证一个upsert语义，根据unique key来实现upset语义）之后，然后这边源头driver再根据存储的offeset去产生kafka RDD，executor再根据kafka每个分区的offset去消费数据。如果满足这些条件，就可以实现端到端的exactly-once. 这是一个大前提。

★ 3.3 总结

1) Stateful Processing SQL ( <2.x mapWithState、updateStateByKey)：我们要实现跨批次带状态的计算的话，在1.X版本，我们通过这两个接口去做，但还是需要把这个状态存到hdfs或者外部去，实现起来比较麻烦一点。

2) Real Multi-Stream Join：没办法实现真正的多个流join的语义。

3)End-To-End Exactly-Once Semantics：它的端到端的exactly-once语义实现起来比较麻烦，需要sink到外部存储后还需要手动的在事务里面提交offset。

4. STRUCTUREDSTREAMING

我们调研然后并去使用了Spark2.X之后带状态的增量计算。下面这个图是官方网站的：

所有的流计算都参照了Google的 data flow，里面有个重要的概念：数据的processing time和event time，即数据的处理时间和真正的发生时间有个gap。于是流计算领域还有个watermark，当前进来的事件水位需要watermark来维持，watermark可以指定时间delay的范围，在延迟窗口之外的数据是可以丢弃的，在业务上晚到的数据也是没有意义的。

下面是structuredstreaming的架构图：

这里面就是把刚才Sparkstreaming讲exactly-once的步骤1，2，3都实现了，它本质上还是分批的batch方式，offset自己维护，状态存储用的hdfs，对外的sink没有做类似的幂等操作，也没有写完之后再去commit offset，它只是再保证容错的同时去实现内部引擎的exactly-once。

★ 4.1 特点

1) Stateful Processing SQL&DSL：可以满足带状态的流计算

2) Real Multi-Stream Join：可以通过Spark2.3实现多个流的join，多个流的join做法和Flink类似，你需要先定义两个流的条件(主要是时间作为一个条件)，比如说有两个topic的流进来，然后你希望通过某一个具体的schema中某个字段（通常是event time）来限定需要buffer的数据，这样可以实现真正意义上的流的join。

3）比较容易实现端到端的exactly-once的语义，只需要扩展sink的接口支持幂等操作是可以实现exactly-once的。

 

特别说一下，Structuredstreaming和原生的streaming的api有一点区别，它create表的Dataframe的时候，是需要指定表的schema的，意味着你需要提前指定schema。另外它的watermark是不支持SQL的，于是我们加了一个扩展，实现完全写sql，可以从左边到右边的转换（下图），我们希望用户不止是程序员，也希望不会写程序的数据分析师等同学也能用到。

 

★ 4.2 总结