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

★ 2.1 总结

[本文来自：www.11jj.com]

1) 易用性：因为使用门槛高，从而限制了它的推广。

2)StateBackend：更多的需要外部存储，比如redis之类的kv存储。

3) 资源分配方面：用worker和slot提前设定的方式，另外由于优化点做的较少，引擎吞吐量相对比较低一点。

 

3. Sparkstreaming

有一天有个业务方过来提需求说 我们能不能写个sql，几分钟内就可以发布一个实时计算任务。 于是我们开始做Sparkstreaming。它的主要概念如下：

1) Micro-batch：需要提前设定一个窗口，然后在窗口内处理数据。

2) 延迟是秒级级别，比较好的情况是500ms左右。

3) 开发语言是java和scala。

4)streaming SQL，主要是我们的工作，我们希望提供streaming SQL的..。

特点：

1) Spark生态和SparkSQL:  这是Spark比较好的地方，技术栈是统一的，SQL，图计算，machine learning的包都是可以互调的。因为它先做的是批处理，和Flink不一样，所以它天然的实时和离线的api是统一的。

2) Checkpointon hdfs。

3) onyarn：Spark是属于hadoop生态体系，和yarn集成度高。

4) 高吞吐： 因为它是Micro-batch的方式，吞吐也是比较高的。

 

下面给大家大致展示一下我们..用户快速发布一个实时任务的操作页面，它需要哪些步骤。我们这里不是写DDL和DML语句，而是ui展示页面的方式。

页面里面会让用户选一些必要的参数， 首先会选哪一个kafka集群，每个分区消费多少，反压也是默认开启的。消费位置需要让用户每次去指定，有可能用户下一次重写实时任务的时候，可以根据业务需求去选择offset消费点。

中间就是让用户描述pipeline。 SQL就是kafka的多个topic，输出选择一个输出表，SQL把上面消费的kafka DStream..成表，然后写一串pipeline，最后我们帮用户封装了一些对外sink(刚刚提到的各种存储都支持，如果存储能实现upsert语义的话，我们都是支持了的)。

★ 3.1 MultiStream-Join

虽然刚刚满足一般无状态批次内的计算要求，但就有用户想说， 我想做流的join怎么办， 早期的Spark1.5可以参考Spark-streamingsql这个开源项目把 DStream..为一个表，然后对这个表做join的操作，但这只支持1.5之前的版本，Spark2.0推出structured streaming之后项目就废弃了。我们有一个tricky的方式：

让Sparkstreaming去消费多个topic，但是我根据一些条件把消费的DStream里面的每个批次RDD转化为DataFrame，这样就可以..为一张表，根据特定的条件，切分为两张表，就可以简单的做个join，这个join的问题完全依赖于本次消费的数据，它们join的条件是不可控的，是比较tricky的方式。比如说下面这个例子，消费两个topic，然后简单通过filer条件，拆成两个表，然后就可以做个两张表的join，但它本质是一个流。