介绍Blink SQL的几个关键技术，以及实现原理，并通过两个实例来阐述具体的功能效果。

六个特点和背景介绍

(Blink架构)

Blink作为一个纯流式的计算平台，具备秒级甚至毫秒级的延时，能够快速容错，比如在某个计算节点挂掉的时候可以快速恢复。它还支持动态扩容，针对流计算场景做了大量优化，具备高吞吐和高资源利用率的极致性能，同时解决了非常明显的数据乱序的问题，并且支持大数据量的流计算请求。

什么是BlinkSQL

BlinkSQL是在FlinkSQL基础上新增了大量的丰富功能和性能优化。SQL作为声明式的可优化的语言具备很大的优势，Blink的SQL查询优化器会对用户SQL进行优化，制定最优的执行计划以获取高性能。同时SQL易于理解，用它编写的业务逻辑清晰明了。

虽然SQL被更多的用于批处理，但是在流计算场景下同样也适用。从处理的数据集合来看，流处理的数据是无穷的，而批处理面对的是有限集合。从内部处理逻辑来看，批处理是单次作业，流处理的运作持续不断，并且会对历史数据进行修正。

上图展示的是一个携带时间戳和用户名的点击事件流，我们先对这些事件流进行流式统计，同时在最后的流事件上触发批计算。流计算中每接收一个数据都会触发一个结果，可以看到最后的事件无论是在流还是批上计算结果都是6。这说明只要SQL语句和数据源相同，流和批的计算结果就不会存在差异。相同的SQL在流和批这两种模式下，语义相同，最终结果就会一致。

五个概念和一个实现

1. 流表对偶性

流表对偶性是指流表转换信息无损，具有对偶性。

传统数据库表有两个最明显的特征schema和data，流同样也有schema和data，另外还有一个重要属性time，随着时间的推移数据会不断涌入流中。

上图中在对一个用户名关系表进行DML操作，每insert一条语句后会触发一个统计查询，按user维度分组做count统计。图中插入第一条数据后，输入的是(mary , 1)，接着再插入数据就会输出(Bob , 2)、(mary , 1)，在进行操作的时候虽然没有显示的涉及到时间，但是其实都隐含了一个操作时间，从本质上讲，传统数据库表中也有time属性。

这样的话单就属性来看数据库表和流式就是一样的，我们可以把一个具体的表可以看做是流上某一时间切片的数据。

2. 动态表

随着时间变化不断变化的表可以称之为动态表，这个概念不适用于传统数据库表。因为传统数据库有着事务控制，在执行查询的那一刻表的内容不会有变化，所以是静态表。而流上的数据即使在查询的时候也还是在变化，数据进行回放的时候，可以Replay成一张动态表，而动态表的changelog又形成了流。

3. 持续查询 & 增量计算

持续查询是流计算特有的，不断更新结果，执行运行的查询。它是保证低延迟和数据更新的基础。

增量计算是一种可以提高流计算性能的计算实现，流上的每一条数据都会利用上一条计算结果进行聚合和统计计算。

4. Early Emit & Retraction

Early Emit是为了保证流计算的低延时需求，将计算结果尽早的流到下游。由于流计算的结果会随着时间改变，因此即使上游的计算结果在发出的那一刻是正确的，但是随后又会产生新的结果，这样下游当初接收的数据就是陈旧的。Retraction解决的就是这一问题，为了保障流计算语义正确性，将Early Emit的计算结果撤回并发出正确的计算结果。

5. 双流JOIN实现

对于双流join，由于流上的流速不一定相同，有可能会出现查询的时候数据不存在，后续才出现数据的情况。上图是Blink的join方案，将左边的数据存储在一个state中，并且对右边的state做join查询。同理右边的数据处理也是一样，先存储在一个state中，然后join查询另一个state。

这样的流程存在一个问题，即在join另一边的state时可能没有数据，传统数据库的做法是将它留空，而流上的数据会实时变化，此刻没有join数据不代表下一刻还没有。这就需要利用Retraction机制，在正确数据到来的时候撤回之前的空数据并重新填入新数据，如上图所示。

6. 总结

这里我们对这5个概念做下总结。首先有了流表对偶性，流表转换才有理论支撑，流表才能互转;有了动态表的概念，SQL才能作用于流上，才能进行持续查询;有了持续查询的概念，才能真正解释流式SQL计算永不结束，结果永远在更新;增量计算配合查询和引擎优化，才有了Blink的高性能;Early Emit和Retraction，一个使用Blink有了无限逼近秒级毫秒级的低延时，一个保证了流式语义的正确性。

两个案例和总结

案例1 - 无key热点

对于有多区块的数据源，每个区块都会由对应的节点来处理。理想情况下每个节点的处理量相同，负载是均衡的，但是实际场景下可能会出现不均衡处理的情况，比如某个节点无法处理所负载的量，对此我们要将该节点无法处理的部分分配给其他节点。

Blink为此提供了Dynamic Rebalance，它会感知下游节点的压力情况，进而将繁忙的节点处理不过来的数据分发给空闲节点。需要注意的是目前的这种情况是无key节点，这意味着数据在哪个节点处理都可以。

案例2 - keyed热点

Keyed就是对数据按key分组，相同的key必须到同一个节点上。这时候虽然框架也能感知到反压，但是不可以使用反压机制再分配节点上的数据。

这时候要用到Local-Global Aggregation，数据热点优化的另一个方案，也是由系统内部的查询优化器来完成，让用户无感知。它会先将每个节点的数据在本地进行Local Agg聚合，图中不同的颜色表示不同的key，他们在本地会做局部的聚合，这样原先上游的4条记录就变成的1条，很大程度上减轻了下游节点的压力。

总结

Blink SQL拥有标准的语义，完全支持标准的ANSI SQL，同时有丰富的功能，比如UDF、JOIN、双流JOIN等。有更优的性能，在ANSI SQL的各个语法功能基础上做了大量的性能优化。提供了一站式平台，集开发、测试、部署、监控、升级于一体，让用户专注于自己的业务。

演讲视频可查看：https://pan.baidu.com/s/1kF_onBreXzcEMAtrtYEN9A

【本文为51CTO专栏作者“金竹”原创稿件，转载请联系原作者】

戳这里，看该作者更多好文

【编辑推荐】

商品标题这么长长长长长，阿里工程师如何解决？

万字长文揭秘：阿里如何实现海量数据实时分析？

阿里巴巴的大数据之路：JStorm与Blink的发展史

能力与态度：以阿里云PolarDB为例

为什么阿里巴巴要求程序员谨慎修改serialVersionUID 字段的值