Lansonli（蓝深李）的博客

本场景中订单和婴儿信息存储在MySQL中，对于订单表，为了方便进行分析，我们让它关联上其对应的婴儿信息，构成一张宽表。在这个例子中，我们将创建三张数据表，其中一张orders_dataset_tmp是导入数据的临时表，其他两张作为源表，体验淘宝母婴订单实时查询。导入完成之后，在SQLConsole页签中，输入如下SQL，然后单击执行，将订单数据导入到订单源表orders_dataset 中。选中代码，点击左上角运行，完成表的创建。点击提交申请后，等待审批完成，点击执行变更，返回如下结果，数据导入完成。

由于商品名称及商品价格数据存储在另一张维度表 dimension_table中，我们需要将结果视图和 dimension_table进行JOIN操作，并将「商品销售量」、「商品价格」相乘计算出「商品销售额」，并提取结果中的商品可读名称信息作为结果表。本场景将以阿里云实时计算Flink版为基础，使用Flink自带的MySQL Connector连接RDS云数据库实例，并以一个实时商品销售数据统计的例子尝试上手Connector的数据捕获、数据写入等功能。选中代码，点击调试，观察控制台的输出结果。

MySQL CDC源表在正则匹配表名时，会将您填写的 database-name，table-name 通过字符串 \\.（VVR 8.0.1前使用字符.）连接成为一个全路径的正则表达式，然后使用该正则表达式和MySQL数据库中表的全限定名进行正则匹配。MySQL的CDC源表，即MySQL的流式源表，会先读取数据库的历史全量数据，并平滑切换到Binlog读取上，保证不多读一条也不少读一条数据。在读完chunk的数据之前，chunk的数据会先缓存在内存中，因此chunk 太大，可能导致内存OOM。

Flink CDC 基于数据库日志的 Change Data Caputre 技术，实现了全量和增量的一体化读取能力，并借助 Flink 优秀的管道能力和丰富的上下游生态，支持捕获多种数据库的变更，并将这些变更实时同步到下游存储。目前，Flink CDC 的上游已经支持了 MySQL、MariaDB、PG、Oracle、MongoDB 等丰富的数据源，对 Oceanbase、TiDB、SQLServer 等数据库的支持也已经在社区的规划中。的技术，我们都可以称之为 CDC。

点击确定后，Flink开发控制台会解析UDF文件中是否使用了Flink UDF、UDAF和UDTF接口的类，并自动提取类名，填充到Function Name字段中。进入阿里云Flink开发平台，点击左侧导航栏SQL开发，点击左侧的函数页签，单击注册UDF，将udx.zip上传，如下图所示。其中udfs.py udafs.py udtfs.py分别对应了UDSF、UDAF、UDTF三个函数的示例。点击创建函数，可以看到函数页签下出现了udx目录，下面有三个自定义函数，此时自定义函数创建完成。

在目前1.15版本的 Flink 体系中，内置的系统函数没有像 Hive 内置的函数那么丰富，比如 Hive 中常见的 get_json_object 之类的，Flink 都是没有的，但是 Flink 提供了插件化 Module 的能力，能扩充一些 UDF，下一篇文章会进行介绍。由于精确函数应用一定会带上 Catalog 或者数据库名称，所以 Flink 中的精确函数引用一定是指向临时性 Catalog 函数或 Catalog 函数的。系统内置函数可以直接在 Flink 官网进行查询，这里就不多进行介绍。

4.后面几个以此类推，直到Event Time为：1648197590000的数据进来的时候，前一条数据的WaterMark为1648197589000，于是更新当前的WaterMark为1648197590000，Flink认为1648197590000之前的数据都已经到达，且达到了窗口的触发条件，开始进行计算。但是由于网络、分布式等原因，会导致数据乱序的情况。通过watermark来解决，简单来说就是延迟窗口关闭的时间，等一会迟到的数据，窗口关闭不在依据数据的时间，而是到达的watermark的时间。

在流处理应用中，数据是连续不断的，因此我们不可能等到所有数据都到了才开始处理。当然我们可以每来一个消息就处理一次，但是有时我们需要做一些聚合类的处理，例如：在过去的1分钟内有多少用户点击了我们的网页。在这种情况下，我们必须定义一个窗口，用来收集最近一分钟内的数据，并对这个窗口内的数据进行计算。Flink 认为 Batch 是 Streaming 的一个特例，所以 Flink 底层引擎是一个流式引擎，在上面实现了流处理和批处理。而窗口（window）就是从 Streaming 到 Batch 的一个桥梁。

以事件时间举个例子，如果只是数据携带了时间，Flink 也消费了这个数据，但是在 Flink 中没有使用数据的这个时间作为计算的触发条件，也不能把这个 Flink 任务叫做事件时间的任务。：举个例子，比如用户可以自定义每隔 10s 的本地时间，或者消费到的数据的时间戳每增大 10s，就把计算结果输出一次，时间在此类应用中也是一种标识任务进度的作用。事件时间：指的是数据本身携带的时间，这个时间是在事件产生时的时间，而且在 Flink SQL 触发计算时，也使用数据本身携带的时间。它是时间的最简单概念。

因此，Flink 是一个用于在无界和有界数据流上进行有状态计算的通用的处理框架，它既具有处理无界流的复杂功能，也具有专门的运算符来高效地处理有界流。在 Flink 中，认为所有的数据本质上都是随时间产生的流数据，把批数据看作是流数据的特例，只不过流数据是一个无界的数据流，而批数据是一个有界的数据流（例如固定大小的数据集）。（阿里云Flink全托管空间预装的是Python3.7版本，因此需要我们在Python3.7版本开发代码），如下：（需要提前安装python3.7，资料中有安装包）

编写Flink程序，读取表中的数据，并根据表中的字段信息进行统计每个单词出现的数量。编写Flink程序，接收socket的单词数据，并以逗号进行单词拆分打印。注意：socketTextStream后的ip是云服务器ecs的公网ip。注意read_text_file后的地址要与实际地址对应。安装nc: yum install -y nc）（如果没有安装可以使用yum。开启netcat，监听。在ecs依次发送单词。

因为这个表的元数据没有被持久化。那么在这个 Flink session 中，你的任务访问到这个表时，访问到的永远是临时表（即相同名称的表，临时表会屏蔽永久表）。在这个作业中，订单表作为驱动源表输入，用户信息表作为静态维表，统计结果表作为作业最终输出。表可以是临时的，并与单个 Flink session（可以理解为 Flink 任务运行一次就是一个 session）的生命周期绑定。任务状态变成运行中后，点击任务进入任务详情，点击作业探查，点击运行日志下的Task Managers，点击Path，ID实例。

在阿里云官网首页，点击右上角控制台，进入工作台。直接点击我的资源下的Flink，或者搜索Flink，进入Flink控制台。点击实例id，进入Flink项目空间。在左侧导航栏，单击SQL开发。在作业草稿下，新建文件夹：阿里云Flink。在此文件夹下，创建文件夹：快速入门。在快速入门文件夹下，单击新建作业草稿。单击空白的流作业草稿。单击下一步。在新建文件草稿对话框，填写作业信息。作业的名称。作业名称在当前项目中必须保持唯一。指定该作业的代码文件所属的文件夹。还可以在现有文件夹右侧，单击。

在实时计算控制台上，可以在Flink全托管页签，单击目标工作空间的更多>工作空间详情，查看空间名称、工作空间ID、OSS Bucket、SLB IP、专有网络名称和ID、虚拟交换机等信息。flink-savepoints：在Flink全托管开发控制台上单击Savepoint，会触发Savepoint操作，最终的Savepoint文件会被存储到该目录。在实时计算控制台上，可以在Flink全托管页签，单击目标工作空间的更多>释放资源，释放按量付费的资源，释放后将不再进行计费。

如果不小心删除了AliyunStreamAsiDefaultRole角色或者变更了授权策略导致Flink全托管服务不可用，可以按照以下操作步骤先删除资源编排服务ROS的资源栈、RAM角色和RAM权限策略后，登录实时计算控制台，重新授权。阿里云账号被正确授予AliyunStreamAsiDefaultRole角色后，Flink全托管服务才能正常地调用专有网络VPC、云服务器ECS、负载均衡SLB和应用实时监控服务ARMS等相关服务来启动Flink全托管的相关组件。3、在授权请求页面，单击前往RAM进行授权。

通过了解实时计算Flink版产品基本概念的层次结构，为后期作业开发、作业部署、作业运维和安全管理等操作提供思路。实时计算Flink版产品基本概念的层次结构如下图所示。工作空间（Workspace）工作空间是Flink全托管管理项目空间的基本单元，每个工作空间的计算资源隔离，开发控制台相互独立。创建成功后工作空间名称和OSS存储地址不可修改。项目空间（Namespace）项目空间是Flink全托管管理作业的基本单元，我们的所有配置、作业、权限均在单个项目空间下进行。

可以配置智能调优，无人值守自动监控并调整作业资源分配，并可以在指定时间段应用对应的资源计划，帮助我们平稳顺利地度过业务洪峰，同时最大程度的节省成本。更好的引擎性能和更细粒度资源配置使得整体TCO优于开源，且灵活的付费模式以及智能扩缩容，进一步提高了资源使用的精细程度。提供完整的系统检查点和作业快照生命周期管理，提供状态兼容性检查和状态数据迁移，以最大可能的复用原来的状态数据。精细化资源管理，大幅度降低成本。程序员、甚至是数据分析师都可以完成调试和上线的动作，大幅减少调试测试成本，提高作业上线速度和质量。

同时Flink还能订阅云上数据库RDS、PolarDB等关系型数据库中Binlog的更新，并利用DataHub、SLS、Kafka等产品将实时数据收集到实时计算产品中进行分析和处理。实时计算Flink版可以处理复杂的流处理和批处理任务，也提供了强大的API，执行复杂的数学计算并执行复杂事件处理规则，帮助企业对实时数据进行实时分析，提高企业的风控能力。实时ETL和数据流的目的是实时地把数据从A点投递到B点。在投递的过程中可能添加数据清洗和集成的工作，例如实时构建搜索系统的索引、实时数仓中的ETL过程等。

阿里云实时计算Flink版是一种全托管Serverless的Flink云服务，开箱即用，计费灵活。阿里云实时计算Flink版是一套基于Apache Flink构建的⼀站式实时大数据分析平台，提供端到端亚秒级实时数据分析能力，并通过标准SQL降低业务开发门槛，助力企业向实时化、智能化大数据计算升级转型。阿里云实时计算Flink版作为企业级高性能Serverless实时大数据处理系统，集成Apache Flink内核，100%兼容Apache Flink，并提供丰富的企业级增值功能。

因此如果你要做这个优化，需要提前做一下吞吐量和延迟之间的权衡，但是大多数情况下，buffer 数据的延迟都是可以被接受的。：其核心思想在于按照 distinct 的 key，即 user_id，先做数据的分桶，将数据打散，分散到 Flink 的多个 TM 上进行计算，然后再将数据合桶计算。：在聚合数据处理场景中，很可能会由于热点数据导致数据倾斜，如下 SQL 所示，当 color = RED 为 50000w 条，而 color = BLUE 为 5 条，就产生了数据倾斜，而器数据处理的算子产生性能瓶颈。

在计算 count(1)，sum(col) 场景汇总提效很高，因为 count(1)，sum(col) 在经过本地 localAggregate 之后，每个 group by 的 key 就一个结果值。Flink SQL 相关参数需要在 TableEnvironment 中设置。Flink SQL 任务在生成执行计划时，优化生成更优的执行计划。用于优化 Flink SQL 任务在执行时的任务性能。

Python UDTAF，即 Python TableAggregateFunction。Python UDTAF 用来针对一组数据进行聚合运算，比如同一个 window 下的多条数据、或者同一个 key 下的多条数据等，与 Python UDAF 不同的是，针对同一组输入数据，Python UDTAF 可以产生 0 条、1 条、甚至多条输出数据。

Python UDAF，即 Python AggregateFunction。Python UDAF 用来针对一组数据进行聚合运算，比如同一个 window 下的多条数据、或者同一个 key 下的多条数据等。针对同一组输入数据，Python AggregateFunction 产生一条输出数据。

Python UDTF，即 Python TableFunction，针对每一条输入数据，Python UDTF 可以产生 0 条、1 条或者多条输出数据，此外，一条输出数据可以包含多个列。如果你是使用 Scala 实现函数，不要使用 Scala 中 object 实现 UDF，Scala object 是单例的，有可能会导致并发问题。

Python UDF，即 Python ScalarFunction，针对每一条输入数据，仅产生一条输出数据。目前 Flink 自定义函数可以基于 JVM 语言（例如 Java 或 Scala）或 Python 实现，实现者可以在 UDF 中使用任意第三方库，本章聚焦于使用 Python 语言开发自定义函数。自定义函数（UDF）是一种扩展开发机制，可以用来在查询语句里调用难以用 SQL 进行 直接 表达的频繁使用或自定义的逻辑。Flink 体系也提供了类似于其他大数据引擎的 UDF 体系。

版本的 Flink 体系中，内置的系统函数没有像 Hive 内置的函数那么丰富，比如 Hive 中常见的 get_json_object 之类的，Flink 都是没有的，但是 Flink 提供了插件化 Module 的能力，能扩充一些 UDF，下一篇会进行介绍。由于精确函数应用一定会带上 Catalog 或者数据库名称，所以 Flink 中的精确函数引用一定是指向临时性 Catalog 函数或 Catalog 函数的。系统内置函数可以直接在 Flink 官网进行查询，这里就不多进行介绍。

在模糊函数引用中，用户只需在 SQL 查询中指定函数名就可以引用 UDF，例如： select myfunc(x) from mytable。当然如果系统函数和 Catalog 函数的名称是重复的，Flink 体系是会使用哪一个函数呢？请注意，在用户使用函数时，系统函数始终优先于 Catalog 函数解析，临时函数始终优先于持久化函数解析。Flink Table\SQL API 允许用户使用函数进行数据处理、字段标准化等处理。用户在 Flink 中可以通过精确、模糊两种引用方式引用函数。

如果熟悉 MySQL 的同学会非常熟悉这个子句，在 MySQL 中，USE 子句通常被用于切换库，那么在 Flink SQL 体系中，它的作用也是和 MySQL 中 USE 子句的功能基本一致，用于切换 Catalog，DataBase，使用 Module。：如果熟悉 MySQL 的同学会非常熟悉这个子句，在 MySQL 中，SHOW 子句常常用于查询库、表、函数等，在 Flink SQL 体系中也类似。：EXPLAIN 子句其实就是用于查看当前这个 sql 查询的逻辑计划以及优化的执行计划。

Deduplication 其实就是去重，也即上文介绍到的 TopN 中 row_number = 1 的场景，但是这里有一点不一样在于其排序字段一定是时间属性列，不能是其他非时间属性的普通列。在 row_number = 1 时，如果排序字段是普通列 planner 会翻译成 TopN 算子，如果是时间属性列 planner 会翻译成 Deduplication，这两者最终的执行算子是不一样的，Deduplication 相比 TopN 算子专门做了对应的优化，性能会有很大提升。可以看到其有回撤数据。

还记得上文介绍 TopN 说道的 TopN 时会出现中间结果，从而出现回撤数据的嘛？Window TopN 不会出现回撤数据，因为 Window TopN 实现是在窗口结束时输出最终结果，不会产生中间结果。而且注意，因为是窗口上面的操作，Window TopN 在窗口结束时，会自动把 State 给清除。：Window TopN 是一种特殊的 TopN，它的返回结果是每一个窗口内的 N 个最小值或者最大值。：取当前这一分钟的搜索关键词下的搜索热度前 10 名的词条数据。测试代码，并nc -lk 8888。

实时任务中，Order By 子句中必须要有时间属性字段，并且时间属性必须为升序时间属性，即 WATERMARK FOR rowtime_column AS rowtime_column - INTERVAL '0.001' SECOND 或者。，但在实时任务中一般用的非常少。

TopN 其实就是对应到离线数仓中的 row_number()，可以使用 row_number() 对某一个分组的数据进行排序。

上述 SQL 在流式任务中，如果一条左流数据先来了，没有从右流集合数据中找到对应的数据时会直接输出，当右流对应数据后续来了之后，会下发回撤流将之前的数据給撤回。上述 SQL 的 In 子句其实就和之前介绍到的 Inner Join 类似。并且 In 子查询也会涉及到大状态问题，大家注意设置 State 的 TTL。

：这个其实和 Array Expansion 功能类似，但是 Table Function 本质上是个 UDTF 函数，和离线 Hive SQL 一样，我们可以自定义 UDTF 去决定列转行的逻辑。：比如某些场景下，日志是合并、攒批上报的，就可以使用这种方式将一个 Array 转为多行。：将表中 ARRAY 类型字段（列）拍平，转为多行。SQL 表值函数（Table Function）

Lookup Join 其实就是维表 Join，比如拿离线数仓来说，常常会有用户画像，设备画像等数据，而对应到实时数仓场景中，这种实时获取外部缓存的 Join 就叫做维表 Join。

比如常见的汇率数据（实时的根据汇率计算总金额），在 12:00 之前（事件时间），人民币和美元汇率是 7:1，在 12:00 之后变为 6:1，那么在 12:00 之前数据就要按照 7:1 进行计算，12:00 之后就要按照 6:1 计算。在事件时间语义的任务中，事件时间 12:00 之前的数据，要按照 7:1 进行计算，12:00 之后的数据，要按照 6:1 进行计算。事件时间的 Temporal Join 一定要把 Versioned Table 的主键包含在 Join on 的条件中。

流的上游是无限的数据，所以要做到关联的话，Flink 会将两条流的所有数据都存储在 State 中，所以 Flink 任务的 State 会无限增大，因此你需要为 State 配置合适的 TTL，以防止 State 过大。：Join 其实在我们的数仓建设过程中应用是非常广泛的。：Regular Join 其实就是和离线 Hive SQL 一样的 Regular Join，通过条件关联两条流数据输出。Join 的流程是左流新来一条数据之后，会和右流中符合条件的所有数据做 Join，然后输出。

而 Group by 聚合是没有时间语义的，不管数据迟到多长时间，只要数据来了，就把上一次的输出的结果数据撤回，然后把计算好的新的结果数据发出。而窗口聚合是在时间粒度上对数据进行分组，是纵向的。Group by 聚合涉及到了回撤流（也叫 retract 流），会产生回撤流是因为从整个 SQL 的语义来看，上游的 Kafka 数据是源源不断的，无穷无尽的，那么每次这个 SQL 任务产出的结果都是一个中间结果，所以每次结果发生更新时，都需要将上一次发出的中间结果给撤回，然后将最新的结果发下去。

这时，有离线 Hive SQL 使用经验的就会想到，如果有了 Grouping Sets，我们就可以直接用 Grouping Sets 将维度组合写在一条 SQL 中，写起来方便并且执行效率也高。对于经常需要对数据进行多维度的聚合分析的场景，您既需要对a列做聚合，也要对b列做聚合，同时要按照a、b两列同时做聚合，因此需要多次使用UNION ALL。CUBE会枚举指定列的所有可能组合作为GROUPING SETS，而ROLLUP会以按层级聚合的方式产生GROUPING SETS。也可以用于非窗口函数的场景。

由于窗口涉及到的知识内容比较多，先为大家说明介绍下面内容时的思路，大家跟着思路走。首先来看看 Flink SQL 中支持的 4 种窗口的运算。