简介：《实时数仓入门训练营》由阿里云研究员王峰、阿里云高级产品专家刘一鸣等实时计算 Flink 版和 Hologres 的多名技术/产品一线专家齐上阵，合力搭建此次训练营的课程体系，精心打磨课程内容，直击当下同学们所遇到的痛点问题。由浅入深全方位解析实时数仓的架构、场景、以及实操利用，7 门精品课程帮忙你 5 天工夫从小白成长为大牛！
本文整顿自直播《实时计算 Flink 版 SQL 实际-李麟（海豹）》
视频链接:https://developer.aliyun.com/learning/course/807/detail/13887
内容简要：
一、实时计算Flink版SQL简介
二、实时计算Flink版SQL上手示例
三、开发常见问题和解法
实时计算Flink版SQL简介
（一）对于实时计算Flink版SQL
实时计算Flink版抉择了SQL这种申明式语言作为顶层API，比较稳定，也不便用户应用。Flink SQL具备流批对立的个性，给用户对立的开发体验，并且语义统一。另外，Flink SQL可能主动优化，包含屏蔽流计算外面State的复杂性，也提供了主动优化的Plan，并且还集成了AutoPilot主动调优的性能。Flink SQL的利用场景也比拟宽泛，包含数据集成、实时报表、实时风控，还有在线机器学习等场景。
（二）基本操作
在基本操作上，能够看到SQL的语法和规范SQL十分相似。示例中包含了根本的SELECT、FILTER操作。，能够应用内置函数，如日期的格式化，也能够应用自定义函数，比方示例中的汇率转换就是一个用户自定义函数，在平台上注册后就能够间接应用。
（三）维表 Lookup Join
在理论的数据处理过程中，维表的Lookup Join也是一个比拟常见的例子。
这里展现的是一个维表INNER JOIN示例。
例子中显示的SOURCE表是一个实时变动的订单信息表，它通过INNER JOIN去关联维表信息，这里标黄高亮的就是维表JOIN的语法，能够看到它和传统的批处理有一个写法上的差别，多了FOR SYSTEM\_TIME AS OF这个子句来表明它是一个维表JOIN的操作。SOURCE表每来一条订单音讯，它都会触发维表算子，去做一次对维表信息的查问，所以把它叫做一个Lookup Join。
（四）Window Aggregation
Window Aggregation（窗口聚合）操作也是常见的操作，Flink SQL中内置反对了几种罕用的Window类型，比方Tumble Window，Session Window，Hop Window，还有新引入的Cumulate Window。
Tumble
Tumble Window能够了解成固定大小的工夫窗口，也叫滚窗，比如说5分钟、10分钟或者1个小时的固定距离的窗口，窗口之间没有重叠。
Session
Session Window（会话窗口） 定义了一个间断事件的范畴，窗口定义中的一个参数叫做Session Gap，示意两条数据的距离如果超过定义的时长，那么前一个Window就完结了，同时生成了一个新的窗口。
Hop
Hop Window不同于滚动窗口的窗口不重叠，滑动窗口的窗口之间能够重叠。滑动窗口有两个参数：size 和 slide。size 为窗口的大小，slide 为每次滑动的步长。如果slide < size，则窗口会重叠，同一条数据可能会被调配到多个窗口；如果 slide = size，则等同于 Tumble Window。如果 slide > size，窗口之间没有重叠且有间隙。
Cumulate
Cumulate Window（累积窗口），是Flink社区1.13版本里新引入的，能够比照 Hop Window来了解，区别是从Window Start开始一直去累积。示例中Window 1、Window 2、Window 3是在一直地增长的。它有一个最大的窗口长度，比方咱们定义Window Size是一天，而后Step步长是1个小时，那么它会在一天中的每个小时产生累积到以后小时的聚合后果。
看一个具体的Window聚合解决示例。
如上图所示，比如说须要进行每5分钟单个用户的点击数统计。
源数据是用户的点击日志，咱们冀望算出每5分钟单个用户的点击总数， SQL 中应用的是社区最新的 WindowTVF语法，先对源表开窗，再 GROUP BY 窗口对应的属性 window\_start和window\_end， COUNT(*)就是点击数统计。
能够看到，当解决12:00到12:04的数据，有2个用户产生了4次点击，别离能统计进去用户Mary是3次，Bob是1次。在接下来一批数据外面，又来了3条数据，对应地更新到下一个窗口中，别离是1次和2次。
（五）Group Aggregation
绝对于Window Aggregation来说，Group Aggregation间接触发计算，并不需要等到窗口完结，实用的一个场景是计算累积值。
上图的例子是单个用户累积到以后的点击数统计。从Query上看，写法绝对简略一点，间接 GROUP BY user 去计算COUNT(*)，就是累积计数。
能够看到，在后果上和Window的输入是有差别的，在与Window雷同的前4条输出数据，Group Aggregation输入的后果是Mary的点击数已更新到3次，具体的计算过程可能是从1变成2再变成3，Bob是1次，随着前面3条数据的输出，Bob对应的点击数又会更新成2次，对后果是继续更新的过程，这和Window的计算场景是有一些区别的。
之前Window窗口外面输入的数据，在窗口完结后后果就不会再扭转，而在Group Aggregation里，同一个Group Key的后果是会产生继续更新的。
（六）Window Aggregation Vs Group Aggregation
更全面地比照一下Window和Group Aggregation的一些区别。
Window Aggregation在输入模式上是按时输入，是在定义的数据到期之后它才会输入。比方定义5分钟的窗口，后果是提早输入的，比方00:00~00:05这个时间段，它会等整个窗口数据都到齐之后，才残缺输入进去，并且后果只输入一次，不会再扭转。
Group Aggregation是数据触发，比方第一条数据来它就会输入后果，同一个Key 的第二条数据来后果会更新，所以在输入流的性质上两者也是不一样的。Window Aggregation个别状况下输入的是Append Stream，而在Group Aggregation输入的是Update Stream。
在状态State解决上两者的差别也比拟大。Window Aggregation会主动清理过期数据，用户就不须要额定再去关注 State的收缩状况。Group Aggregation是基于有限的状态去做累积，所以须要用户依据本人的计算场景来定义State的TTL，就是State保留多久。
比方统计一天内累计的PV和UV，不思考数据提早的状况，也至多要保障State的TTL要大于等于一天，这样能力保障计算的精确性。如果State的TTL定义成半天，统计值就可能不精确了。
对输入的存储要求也是由输入流的性质来决定的。在Window的输入上，因为它是Append流，所有的类型都是能够对接输入的。而Group Aggregatio输入了更新流，所以要求指标存储反对更新，能够用Hologres、MySQL或者HBase这些反对更新的存储。
实时计算 Flink 版SQL上手示例
上面通过具体的例子来看每一种SQL操作在实在的业务场景中会怎么应用，比方SQL根本的语法操作，包含一些常见的Aggregation的应用。
（一）示例场景阐明：电商交易数据 - 实时数仓场景
这里的例子是电商交易数据场景，模仿了实时数仓里分层数据处理的状况。
在数据接入层，咱们模仿了电商的交易订单数据，它包含了订单ID，商品ID，用户ID，交易金额，商品的叶子类目，交易工夫等根本信息，这是一个简化的表。
示例1会从接入层到数据明细层，实现一个数据荡涤工作，此外还会做类目信息的关联，而后数据的汇总层咱们会演示怎么实现分钟级的成交统计、小时级口径怎么做实时成交统计，最初会介绍下在天级累积的成交场景上，怎么去做准实时统计。
- 示例环境：内测版
演示环境是目前内测版的实时计算Flink产品，在这个平台能够间接做一站式的作业开发，包含调试，还有线上的运维工作。
- 接入层数据
应用 SQL DataGen Connector 生成模仿电商交易数据。
接入层数据：为了不便演示，简化了链路，用内置的SQL DataGen Connector来模仿电商数据的产生。
这外面order\_id是设计了一个自增序列，Connector的参数没有残缺贴出来。 DataGen Connector反对几种生成模式，比方能够用Sequence产生自增序列，Random模式能够模仿随机值，这里依据不同的字段业务含意，抉择了不同的生成策略。
比方order\_id是自增的，商品ID是随机选取了1~10万，用户ID是1~1000万，交易金额用分做单位， cate\_id是叶子类目ID，这里共模仿100个叶子类目，间接通过计算列对商品ID取余来生成，订单创立工夫应用以后工夫模仿，这样就能够在开发平台上调试，而不须要去创立Kafka或者DataHub做接入层的模仿。
（二）示例1-1 数据荡涤
- 电商交易数据-订单过滤
这是一个数据荡涤的场景，比方须要实现业务上的订单过滤，业务方可能会对交易金额有最大最小的异样过滤，比方要大于1元，小于1万才保留为无效数据。
交易的创立工夫是选取某个时刻之后的，通过WHERE条件组合过滤，就能够实现这个逻辑。
实在的业务场景可能会简单很多，上面来看下SQL如何运行。
这是应用调试模式，在平台上点击运行按钮进行本地调试，能够看到金额这一列被过滤，订单创立工夫也都是大于要求的工夫值。
从这个简略的荡涤场景能够看到，实时和传统的批处理相比，在写法上包含输入后果差别并不大，流作业次要的差别是运行起来之后是长周期放弃运行的，而不像传统批处理，解决完数据之后就完结了。
（三）示例1-2 类目信息关联
接下来看一下怎么做维表关联。
依据方才接入层的订单数据，因为原始数据外面是叶子类目信息，在业务上须要关联类目标维度表，维度表外面记录了叶子类目到一级类目标关联关系，ID和名称，荡涤过程须要实现的指标是用原始表外面叶子类目ID去关联维表，补齐一级类目标ID和Name。这里通过INNER JOIN维表的写法，关联之后把维表对应的字段选出来。
和批处理的写法差别仅仅在于维表的非凡语法FOR SYSTEM\_TIME AS OF。
如上所示，平台上能够上传本人的数据用于调试，比方这里应用了1个CSV的测试数据，把100个叶子类目映射到10个一级类目上。
对应叶子类目ID的个位数就是它一级类目标ID，会关联到对应的一级类目信息，返回它的名称。本地调试运行长处是速度比拟快，能够即时看到后果。在本地调试模式中，终端收到1000条数据之后，会主动暂停，避免后果过大而影响应用。
（四）示例2-1 分钟级成交统计
接下来咱们来看一下基于Window的统计。
第一个场景是分钟级成交统计，这是在汇总层比拟罕用的计算逻辑。
分钟级统计很容易想到Tumble Window，每一分钟都是各算各的，须要计算几个指标，包含总订单数、总金额、成交商品数、成交用户数等。成交的商品数和用户数要做去重，所以在写法上做了一个Distinct解决。
窗口是刚刚介绍过的Tumble Window，依照订单创立工夫去整齐分钟的窗口，而后按一级类目标维度统计每一分钟的成交状况。
- 运行模式
上图和方才的调试模式有点区别，上线之后就真正提交到集群里去运行一个作业，它的输入采纳了调试输入，间接Print到Log里。开展作业拓扑，能够看到主动开启了Local-Global的两阶段优化。
- 运行日志 - 查看调试输入后果
在运行一段时间之后，通过Task外面的日志能够看到最终的输入后果。
用的是Print Sink，会间接打到Log外面。在实在场景的输入上，比方写到Hologres/MySQL，那就须要去对应存储的数据库上查看。
能够看到，输入的数据绝对于数据的原始工夫是存在肯定滞后的。
在19:46:05的时候，输入了19:45:00这一个窗口的数据，提早了5秒钟左右输入前1分钟的聚合后果。
这5秒钟实际上和定义源表时WATERMARK的设定是有关系的，在申明WATERMARK时是绝对gmt\_create字段加了5秒的offset。这样起到的成果是，当达到的最早数据是 19:46:00 时，咱们认为水位线是到了19:45:55，这就是5秒的提早成果，来实现对乱序数据的宽容解决。
（五）示例2-2 小时级实时成交统计
第二个例子是做小时级实时成交统计。
如上图所示，当要求实时统计，间接把Tumble Window开成1小时Size的Tumble Window，这样能满足实时性吗？依照方才展现的输入后果，具备肯定的提早成果。因而开一个小时的窗口，必须等到这一个小时的数据都收到之后，在下一个小时的开始，能力输入上一个小时的后果，提早在小时级别的，满足不了实时性的要求。回顾之前介绍的 Group Aggregation 是能够满足实时要求的。
具体来看，比方须要实现小时+类目以及只算小时的两个口径统计，两个统计一起做，在传统批处理中罕用的GROUPING SETS性能，在实时Flink上也是反对的。
咱们能够间接GROUP BY GROUPING SETS，第一个是小时全口径，第二个是类目+小时的统计口径，而后计算它的订单数，包含总金额，去重的商品数和用户数。
这种写法对后果加了空值转换解决便于查看数据，就是对小时全口径的统计，输入的一级类目是空的，须要对它做一个空值转换解决。
上方为调试模式的运行过程，能够看到Datagen生成的数据实时更新到一级类目和它对应的小时上。
这里能够看到，两个不同GROUP BY的后果在一起输入，两头有一列ALL是通过空值转换来的，这就是全口径的统计值。本地调试相对来说比拟直观和不便，有趣味的话也能够到阿里云官网申请或购买进行体验。
（六）示例2-3 天级累积成交准实时统计
第三个示例是天级累计成交统计，业务要求是准实时，比如说可能承受分钟级的更新提早。
依照方才Group Aggregation小时的实时统计，容易联想到间接把Query改成天维度，就能够实现这个需要，而且实时性比拟高，数据触发之后能够达到秒级的更新。
回顾下之前提到的Window和Group Aggregation对于内置状态解决上的区别，Window Aggregation能够实现State的主动清理，Group Aggregation须要用户本人去调整 TTL。因为业务上是准实时的要求，在这里能够有一个代替的计划，比方用新引入的Cumulate Window做累积的Window计算，天级的累积而后应用分钟级的步长，能够实现每分钟更新的准实时要求。
回顾一下Cumulate Window，如上所示。天级累积的话，Window的最大Size是到天，它的Window Step就是一分钟，这样就能够表白天级的累积统计。
具体的Query如上，这里应用新的TVF语法，通过一个TABLE关键字把Windows的定义蕴含在两头，而后 Cumulate Window援用输出表，接着定义它的工夫属性，步长和size 参数。GROUP BY就是一般写法，因为它有提前输入，所以咱们把窗口的开始工夫和完结工夫一起打印进去。
这个例子也通过线上运行的形式去看Log输入。
- 运行模式
能够看到，它和之前Tumble Window运行的构造相似，也是预聚合加上全局聚合，它和Tumble Window的区别就是并不需要等到这一天数据都到齐了才输入后果。
- 运行日志 – 察看调试后果
从上方示例能够看到，在20:47：00的时候，曾经有00:00：00到20:47：00的后果累积，还有对应的4列统计值。下一个输入就是接下来的累计窗口，能够看到20:47：00到20:48：00就是一个累计的步长，这样既满足了天级别的累计统计需要，也可能满足准实时的要求。
（七）示例小结：电商交易数据-实时数仓场景
而后咱们来整体总结一下以上的示例。
在接入层到明细层的荡涤解决特点是绝对简略，也比拟明确，比方业务逻辑上须要做固定的过滤条件，包含维度的扩大，这都是十分明确和间接的。
从明细层到汇总层，例子中的分钟级统计，咱们是用了Tumble Window，而小时级因为实时性的要求，换成了Group Aggregation，而后到天级累积别离展现Group Aggregation和新引入的Cumulate Window。
从汇总层的计算特点来说，咱们须要去关注业务上的实时性要求和数据准确性要求，而后依据理论状况抉择Window聚合或者Group 聚合。
这里为什么要提到数据准确性？
在一开始比拟Window Aggregation和Group Aggregation的时候，提到Group Aggregation的实时性十分好，然而它的数据准确性是依赖于State的TTL，当统计的周期大于TTL，那么TTL的数据可能会失真。
相同，在Window Aggregation上，对乱序的容忍度有一个下限，比方最多承受等一分钟，但在理论的业务数据中，可能99%的数据能满足这样的要求，还有1%的数据可能须要一个小时后才来。基于WATERMARK的解决，默认它就是一个抛弃策略，超过了最大的offset的这些数据就会被抛弃，不纳入统计，此时数据也会失去它的准确性，所以这是一个绝对的指标，须要依据具体的业务场景做抉择。
开发常见问题和解法
（一）开发中的常见问题
上方是实时计算实在业务接触过程中比拟高频的问题。
首先是实时计算不晓得该如何下手，怎么开始做实时计算，比方有些同学有批处理的背景，而后刚开始接触Flink SQL，不晓得从哪开始。
另外一类问题是SQL写完了，也分明输出解决的数据量大略是什么级别，然而不晓得实时作业运行起来之后须要设定多大的资源
还有一类是SQL写得比较复杂，这个时候要去做调试，比方要查为什么计算出的数据不合乎预期等相似问题，许多同学反映无从下手。
作业跑起来之后如何调优，这也是一个十分高频的问题。
（二）开发常见问题解法
1.实时计算如何下手？
对于上手的问题，社区有很多官网的文档，也提供了一些示例，大家能够从简略的例子上手，缓缓理解SQL外面不同的算子，在流式计算的时候会有一些什么样的个性。
此外，还能够关注开发者社区实时计算 Flink 版、 ververica.cn网站、 B 站的Apache Flink 公众号等分享内容。
逐步相熟了SQL之后，如果想利用到生产环境中去解决实在的业务问题，阿里云的行业解决方案里也提供了一些典型的架构设计，能够作为参考。
2.简单作业如何调试？
如果遇到千行级别的简单SQL，即便对于Flink的开发同学来也不能高深莫测地把问题定位进去，其实还是须要遵循由简到繁的过程，可能须要借助一些调试的工具，比方后面演示的平台调试性能，而后做分段的验证，把小段SQL部分的后果正确性调试完之后，再一步一步组装起来，最终让这个简单作业能达到正确性的要求。
另外，能够利用SQL语法上的个性，把SQL组织得更加清晰一点。实时计算Flink产品上有一个代码构造性能，能够比拟不便地定位长SQL里具体的语句，这都是一些辅助工具。
3.作业初始资源设置，如何调优？
咱们有一个教训是依据输出的数据，初始做小并发测试一下，看它的性能如何，而后再去估算。在大并发压测的时候，依照需要的吞吐量，逐渐迫近，而后拿到预期的性能配置，这个是比拟间接但也比拟牢靠的形式。
调优这一块次要是借助于作业的运行是状况，咱们会去关注一些重点指标，比如说有没有产生数据的歪斜，维表的Lookup Join须要拜访内部存储，有没有产生IO的瓶颈，这都是影响作业性能的常见瓶颈点，须要加以关注。
在实时计算Flink产品上集成了一个叫AutoPilot的性能，能够了解为相似于主动驾驶，在这种性能下，初始资源设多少就不是一个麻烦问题了。
在产品上，设定作业最大的资源限度后，依据理论的数据处理量，该用多少资源能够由引擎主动帮咱们去调到最优状态，依据负载状况来做伸缩。
版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。