༺歲月蹉跎༻

只要路是对的,就不怕路远!

0%

Flink之TableAPI和SQL

1、简介

  • 如图所示,在Flink提供的多层级API中,核心是DataStream API,这是我们开发流处理应用的基本途径;底层则是所谓的处理函数(process function),可以访问事件的时间信 息、注册定时器、自定义状态,进行有状态的流处理。DataStream API和处理函数比较通用, 有了这些API,理论上我们就可以实现所有场景的需求了。

    1670071576954

  • SQL是结构化查询语言(Structured Query Language)的缩写,是我们对关系型数据库进行查询和修改的通用编程语言。在关系型数据库中,数据是以表(table)的形式组织起来的,所以也可以认为SQL是用来对表进行处理的工具语言。无论是传统架构中进行数据存储的MySQL、PostgreSQL,还是大数据应用中的Hive,都少不了SQL的身影;而Spark作为大数据处理引擎,为了更好地支持在Hive中的SQL查询,也提供了Spark SQL作为入口。

  • Flink同样提供了对于“表”处理的支持,这就是更高层级的应用API,在Flink中被称为Table API和SQL。Table API顾名思义,就是基于“表”(Table)的一套API,它是内嵌在Java、Scala等语言中的一种声明式领域特定语言(DSL),也就是专门为处理表而设计的;在此基础上,Flink还基于Apache Calcite实现了对SQL的支持。这样一来,我们就可以在Flink程序中直接写SQL来实现处理需求了。

  • 在Flink中这两种API被集成在一起,SQL执行的对象也是Flink中的表(Table),所以我们一般会认为它们是一体的。Flink是批流统一的处理框架,无论是批处理(DataSet API)还是流处理(DataStream API),在上层应用中都可以直接使用Table API或者SQL来实现;这两种API对于一张表执行相同的查询操作,得到的结果是完全一样的。

2、快速上手

2.1 需要引入的依赖

  • 我们想要在代码中使用Table API,必须引入相关的依赖。

    1
    2
    3
    4
    5
    <dependency>
    <groupId>org.apache.flink</groupId>
    <artifactId>flink-table-api-java-bridge_${scala.binary.version}</artifactId>
    <version>${flink.version}</version>
    </dependency>
    • 这里的依赖是一个 Java 的“桥接器”(bridge),主要就是负责Table API和下层DataStream API的连接支持,按照不同的语言分为Java版和Scala版。
  • 如果我们希望在本地的集成开发环境(IDE)里运行Table API和SQL,还需要引入以下依赖:

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    <dependency>
    <groupId>org.apache.flink</groupId>
    <artifactId>flink-table-planner-blink_${scala.binary.version}</artifactId>
    <version>${flink.version}</version>
    </dependency>
    <dependency>
    <groupId>org.apache.flink</groupId>
    <artifactId>flink-streaming-scala_${scala.binary.version}</artifactId>
    <version>${flink.version}</version>
    </dependency>
    • 这里主要添加的依赖是一个“计划器”(planner),它是Table API的核心组件,负责提供运行时环境,并生成程序的执行计划。这里我们用到的是新版的blink planner。由于Flink安装包的lib目录下会自带planner,所以在生产集群环境中提交的作业不需要打包这个依赖。
    • 而在Table API的内部实现上,部分相关的代码是用Scala实现的,所以还需要额外添加一个Scala版流处理的相关依赖。
  • 另外,如果想实现自定义的数据格式来做序列化,可以引入下面的依赖:

    1
    2
    3
    4
    5
    <dependency>
    <groupId>org.apache.flink</groupId>
    <artifactId>flink-table-common</artifactId>
    <version>${flink.version}</version>
    </dependency>

2.2 一个简单示例

  • 有了基本的依赖,接下来我们就可以尝试在Flink代码中使用Table API和SQL了。比如, 我们可以自定义一些Event类型(包含了user、url和timestamp三个字段)的用户访问事件,作为输入的数据源;而后从中提取url地址和用户名user两个字段作为输出。

  • 如果使用DataStream API,我们可以直接读取数据源后,用一个简单转换算子map来做字段的提取。而这个需求直接写SQL的话,实现会更加简单:

    1
    select url, user from EventTable;
    • 这里我们把流中所有数据组成的表叫作EventTable。在Flink代码中直接对这个表执行上面的 SQL,就可以得到想要提取的数据了。
  • 在代码中具体实现如下:

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    public class TableExample {
    public static void main(String[] args) throws Exception {
    // 获取流执行环境
    StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();
    env.setParallelism(1);
    // 读取数据源
    SingleOutputStreamOperator<Event> eventStream = env.fromElements(
    new Event("Alice", "./home", 1000L),
    new Event("Bob", "./cart", 1000L),
    new Event("Alice", "./prod?id=1", 5 * 1000L),
    new Event("Cary", "./home", 60 * 1000L),
    new Event("Bob", "./prod?id=3", 90 * 1000L),
    new Event("Alice", "./prod?id=7", 105 * 1000L)
    );
    // 获取表环境
    StreamTableEnvironment tableEnv = StreamTableEnvironment.create(env);
    // 将数据流转换成表
    Table eventTable = tableEnv.fromDataStream(eventStream);
    // 用执行 SQL 的方式提取数据
    Table visitTable = tableEnv.sqlQuery("select url, user from " + eventTable);
    // 将表转换成数据流,打印输出
    tableEnv.toDataStream(visitTable).print();
    // 执行程序
    env.execute();
    }
    }

    1670072259254

    • 这里我们需要创建一个“表环境”(TableEnvironment),然后将数据流(DataStream)转换成一个表(Table);之后就可以执行SQL在这个表中查询数据了。查询得到的结果依然是一个表,把它重新转换成流就可以打印输出了。
  • Table是Table API中的核心接口类,对应着我们熟悉的“表”的概念。基于Table我们也可以调用一系列查询方法直接进行转换,这就是所谓Table API的处理方式:

    1
    2
    // 用 Table API 方式提取数据
    Table clickTable2 = eventTable.select($("url"), $("user"));
    • 这里的$符号是Table API中定义的“表达式”类Expressions中的一个方法,传入一个字段名称,就可以指代数据中对应字段。将得到的表转换成流打印输出,会发现结果与直接执行SQL完全一样。

3、基本API

3.1 程序架构

  • 在Flink中,Table API和SQL可以看作联结在一起的一套API,这套API的核心概念就是“表”(Table)。在我们的程序中,输入数据可以定义成一张表;然后对这张表进行查询, 就可以得到新的表,这相当于就是流数据的转换操作;最后还可以定义一张用于输出的表,负责将处理结果写入到外部系统。

  • 我们可以看到,程序的整体处理流程与DataStream API非常相似,也可以分为读取数据源(Source)、转换(Transform)、输出数据(Sink)三部分;只不过这里的输入输出操作不需要额外定义,只需要将用于输入和输出的表定义出来,然后进行转换查询就可以了。

  • 程序基本架构如下:

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    // 创建表环境
    TableEnvironment tableEnv = ...;

    // 创建输入表,连接外部系统读取数据
    tableEnv.executeSql("CREATE TEMPORARY TABLE inputTable ... WITH ( 'connector'
    = ... )");

    // 注册一个表,连接到外部系统,用于输出
    tableEnv.executeSql("CREATE TEMPORARY TABLE outputTable ... WITH ( 'connector'
    = ... )");

    // 执行 SQL 对表进行查询转换,得到一个新的表
    Table table1 = tableEnv.sqlQuery("SELECT ... FROM inputTable... ");

    // 使用 Table API 对表进行查询转换,得到一个新的表
    Table table2 = tableEnv.from("inputTable").select(...);

    // 将得到的结果写入输出表
    TableResult tableResult = table1.executeInsert("outputTable");
    • 与上一节中不同,这里不是从一个DataStream转换成 Table,而是通过执行DDL来直接创建一个表。这里执行的CREATE语句中用WITH指定了外部系统的连接器,于是就可以连接外部系统读取数据了。这其实是更加一般化的程序架构,因为这样我们就可以完全抛开DataStream API,直接用SQL语句实现全部的流处理过程。

3.2 创建表环境

  • 对于Flink这样的流处理框架来说,数据流和表在结构上还是有所区别的。所以使用Table API和SQL需要一个特别的运行时环境,这就是所谓的“表环境”(TableEnvironment)。它主要负责:

    • 注册Catalog和表;
    • 执行SQL查询;
    • 注册用户自定义函数(UDF);
    • DataStream和表之间的转换。
  • 这里的Catalog就是“目录”,与标准SQL中的概念是一致的,主要用来管理所有数据库(database)和表(table)的元数据(metadata)。通过Catalog可以方便地对数据库和表进行查询的管理,所以可以认为我们所定义的表都会“挂靠”在某个目录下,这样就可以快速检索。在表环境中可以由用户自定义Catalog,并在其中注册表和自定义函数(UDF)。默认的Catalog就叫作default_catalog。

  • 每个表和SQL的执行,都必须绑定在一个表环境(TableEnvironment)中。TableEnvironment是Table API中提供的基本接口类,可以通过调用静态的create()方法来创建一个表环境实例。方法需要传入一个环境的配置参EnvironmentSettings,它可以指定当前表环境的执行模式和计划器(planner)。执行模式有批处理和流处理两种选择,默认是流处理模式;计划器默认使用blink planner。

    1
    2
    3
    4
    5
    6
    7
    8
    import org.apache.flink.table.api.EnvironmentSettings;
    import org.apache.flink.table.api.TableEnvironment;

    EnvironmentSettings settings = EnvironmentSettings
    .newInstance()
    .inStreamingMode() // 使用流处理模式
    .build();
    TableEnvironment tableEnv = TableEnvironment.create(settings);
  • 对于流处理场景,其实默认配置就完全够用了。所以我们也可以用另一种更加简单的方式来创建表环境:

    1
    2
    3
    4
    5
    6
    7
    import org.apache.flink.streaming.api.environment.StreamExecutionEnvironment;
    import org.apache.flink.table.api.EnvironmentSettings;
    import org.apache.flink.table.api.bridge.java.StreamTableEnvironment;

    StreamExecutionEnvironment env =
    StreamExecutionEnvironment.getExecutionEnvironment();
    StreamTableEnvironment tableEnv = StreamTableEnvironment.create(env);
    • 这里我们引入了一个“流式表环境”(StreamTableEnvironment),它是继承自TableEnvironment的子接口。调用它的create()方法,只需要直接将当前的流执行环境 (StreamExecutionEnvironment)传入,就可以创建出对应的流式表环境了。

3.3 创建表

  • 为了方便地查询表,表环境中会维护一个目录(Catalog)和表的对应关系。所以表都是通过Catalog来进行注册创建的。表在环境中有一个唯一的ID,由三部分组成:目录(catalog)名,数据库(database)名,以及表名。在默认情况下,目录名为default_catalog,数据库名为default_database。所以如果我们直接创建一个叫作MyTable的表,它的ID就是:default_catalog.default_database.MyTable
  • 具体创建表的方式,有通过连接器(connector)和虚拟表(virtual tables)两种。

3.3.1 连接器表(Connector Tables)

  • 最直观的创建表的方式,就是通过连接器(connector)连接到一个外部系统,然后定义出对应的表结构。例如我们可以连接到Kafka或者文件系统,将存储在这些外部系统的数据以“表” 的形式定义出来,这样对表的读写就可以通过连接器转换成对外部系统的读写了。当我们在表环境中读取这张表,连接器就会从外部系统读取数据并进行转换;而当我们向这张表写入数据,连接器就会将数据输出(Sink)到外部系统中。

  • 在代码中,我们可以调用表环境的executeSql()方法,可以传入一个DDL作为参数执行SQL操作。这里我们传入一个CREATE语句进行表的创建,并通过WITH关键字指定连接到外部系统的连接器:

    1
    2
    tableEnv.executeSql("CREATE [TEMPORARY] TABLE MyTable ... WITH ( 'connector'
    = ... )");
    • 这里没有定义Catalog和Database,所以都是默认的,表的完整ID就是default_catalog.default_database.MyTable。如果希望使用自定义的目录名和库名,可以在环境中进行设置:

      1
      2
      tEnv.useCatalog("custom_catalog");
      tEnv.useDatabase("custom_database");
    • 这样我们创建的表完整ID就变成了custom_catalog.custom_database.MyTable。之后在表环境中创建的所有表,ID也会都以custom_catalog.custom_database作为前缀。

3.3.2 虚拟表(Virtual Tables)

  • 在环境中注册之后,我们就可以在SQL中直接使用这张表进行查询转换了。

    1
    Table newTable = tableEnv.sqlQuery("SELECT ... FROM MyTable... ");
    • 这里调用了表环境的sqlQuery()方法,直接传入一条SQL语句作为参数执行查询,得到的结果是一个Table对象。Table是Table API中提供的核心接口类,就代表了一个Java中定义的表实例。
  • 由于newTable是一个Table对象,并没有在表环境中注册;所以我们还需要将这个中间结果表注册到环境中,才能在SQL中使用:

    1
    tableEnv.createTemporaryView("NewTable", newTable);
    • 我们发现,这里的注册其实是创建了一个“虚拟表”(Virtual Table)。这个概念与SQL语法中的视图(View)非常类似,所以调用的方法也叫作创建“虚拟视图”(createTemporaryView)。视图之所以是“虚拟”的,是因为我们并不会直接保存这个表的内容,并没有“实体”;只是在用到这张表的时候,会将它对应的查询语句嵌入到SQL中。
  • 注册为虚拟表之后,我们就又可以在SQL中直接使用NewTable进行查询转换了。不难看到,通过虚拟表可以非常方便地让SQL分步骤执行得到中间结果,这为代码编写提供了很大的便利。

  • 另外,虚拟表也可以让我们在Table API和SQL之间进行自由切换。一个Java中的Table对象可以直接调用Table API中定义好的查询转换方法,得到一个中间结果表;这跟对注册好的表直接执行SQL结果是一样的。

3.4 表的查询

  • 创建好了表,接下来自然就是对表进行查询转换了。对一个表的查询(Query)操作,就对应着流数据的转换(Transform)处理。
  • Flink为我们提供了两种查询方式:SQL和Table API。

3.4.1 执行SQL进行查询

  • 基于表执行SQL语句,是我们最为熟悉的查询方式。Flink基于Apache Calcite来提供对SQL的支持,Calcite是一个为不同的计算平台提供标准SQL查询的底层工具,很多大数据框架比如Apache Hive、Apache Klin中的SQL支持都是通过集成Calcite来实现的。

  • 在代码中,我们只调用表环境的sqlQuery()方法,传入一个字符串形式的SQL查询语句就可以了。执行得到的结果,是一个Table对象。

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    // 创建表环境
    TableEnvironment tableEnv = ...;

    // 创建表
    tableEnv.executeSql("CREATE TABLE EventTable ... WITH ( 'connector' = ... )");

    // 查询用户 Alice 的点击事件,并提取表中前两个字段
    Table aliceVisitTable = tableEnv.sqlQuery(
    "SELECT user, url " +
    "FROM EventTable " +
    "WHERE user = 'Alice' "
    );
  • 例如,我们也可以通过GROUP BY关键字定义分组聚合,调用COUNT()、SUM()这样的函数来进行统计计算:

    1
    2
    3
    4
    5
    Table urlCountTable = tableEnv.sqlQuery(
    "SELECT user, COUNT(url) " +
    "FROM EventTable " +
    "GROUP BY user "
    );
  • 上面的例子得到的是一个新的Table对象,我们可以再次将它注册为虚拟表继续在SQL中调用。另外,我们也可以直接将查询的结果写入到已经注册的表中,这需要调用表环境的executeSql()方法来执行DDL,传入的是一个INSERT语句:

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    // 注册表
    tableEnv.executeSql("CREATE TABLE EventTable ... WITH ( 'connector' = ... )");
    tableEnv.executeSql("CREATE TABLE OutputTable ... WITH ( 'connector' = ... )");

    // 将查询结果输出到 OutputTable 中
    tableEnv.executeSql (
    "INSERT INTO OutputTable " +
    "SELECT user, url " +
    "FROM EventTable " +
    "WHERE user = 'Alice' "
    );

3.4.2 调用Table API进行查询

  • 另外一种查询方式就是调用Table API。这是嵌入在Java和Scala语言内的查询API,核心就是Table接口类,通过一步步链式调用Table的方法,就可以定义出所有的查询转换操作。每一步方法调用的返回结果,都是一个 Table。

  • 由于Table API是基于Table的Java实例进行调用的,因此我们首先要得到表的Java对象。基于环境中已注册的表,可以通过表环境的from()方法非常容易地得到一个Table对象:

    1
    Table eventTable = tableEnv.from("EventTable");
  • 传入的参数就是注册好的表名。注意这里eventTable是一个Table对象,而EventTable是在环境中注册的表名。得到Table对象之后,就可以调用API进行各种转换操作了,得到的是一个新的Table对象:

    1
    2
    3
    Table maryClickTable = eventTable
    .where($("user").isEqual("Alice"))
    .select($("url"), $("user"));
    • 这里每个方法的参数都是一个“表达式”(Expression),用方法调用的形式直观地说明了想要表达的内容;“$”符号用来指定表中的一个字段。上面的代码和直接执行SQL是等效的。
  • Table API是嵌入编程语言中的DSL,SQL中的很多特性和功能必须要有对应的实现才可以使用,因此跟直接写SQL比起来肯定就要麻烦一些。目前Table API支持的功能相对更少,可以预见未来Flink社区也会以扩展SQL为主,为大家提供更加通用的接口方式。

3.4.3 两种API的结合使用

  • 可以发现,无论是调用Table API还是执行SQL,得到的结果都是一个Table对象;所以这两种API的查询可以很方便地结合在一起。

    • 无论是哪种方式得到的Table对象,都可以继续调用Table API进行查询转换;

    • 如果想要对一个表执行SQL操作(用FROM关键字引用),必须先在环境中对它进行注册。所以我们可以通过创建虚拟表的方式实现两者的转换:

      1
      tableEnv.createTemporaryView("MyTable", myTable);
  • 另外要说明的是,在2.2节简单示例中,我们并没有将Table对象注册为虚拟表就直接在SQL中使用了:

    1
    2
    Table clickTable = tableEnvironment.sqlQuery("select url, user from " +
    eventTable);
    • 这其实是一种简略的写法,我们将Table对象名eventTable直接以字符串拼接的形式添加到SQL语句中,在解析时会自动注册一个同名的虚拟表到环境中,这样就省略了创建虚拟视图的步骤。
  • 两种API殊途同归,实际应用中可以按照自己的习惯任意选择。不过由于结合使用容易引起混淆,而Table API功能相对较少、通用性较差,所以企业项目中往往会直接选择SQL的方式来实现需求。

3.5 输出表

  • 表的创建和查询,就对应着流处理中的读取数据源(Source)和转换(Transform);而最后一个步骤 Sink,也就是将结果数据输出到外部系统,就对应着表的输出操作。

  • 在代码上,输出一张表最直接的方法,就是调用Table的方法executeInsert()方法将一个Table写入到注册过的表中,方法传入的参数就是注册的表名。

    1
    2
    3
    4
    5
    6
    7
    8
    // 注册表,用于输出数据到外部系统
    tableEnv.executeSql("CREATE TABLE OutputTable ... WITH ( 'connector' = ... )");

    // 经过查询转换,得到结果表
    Table result = ...

    // 将结果表写入已注册的输出表中
    result.executeInsert("OutputTable");
  • 在底层,表的输出是通过将数据写入到TableSink来实现的。TableSink是Table API中提供的一个向外部系统写入数据的通用接以支持不同的文件格式(比如 CSV、Parquet)、 存储数据库(比如 JDBC、HBase、Elasticsearch)和消息队列(比如 Kafka)。它有些类似于DataStream API中调用addSink()方法时传入的 SinkFunction,有不同的连接器对它进行了实现。

3.6 表和流的转换

  • 在Flink中我们可以将Table再转换成DataStream,然后进行打印输出。这就涉及了表和流的转换。

3.6.1 将表(Table)转换成流(DataStream)

  • 调用toDataStream()方法。

    • 将一个Table对象转换成DataStream非常简单,只要直接调用表环境的方法toDataStream()就可以了。例如:

      1
      2
      3
      4
      5
      6
      7
      8
      Table aliceVisitTable = tableEnv.sqlQuery(
      "SELECT user, url " +
      "FROM EventTable " +
      "WHERE user = 'Alice' "
      );

      // 将表转换成数据流
      tableEnv.toDataStream(aliceVisitTable).print();
  • 调用toChangelogStream()方法。

    • 将maryClickTable转换成流打印输出是很简单的;然而,如果我们同样希望将“用户点击次数统计”表urlCountTable进行打印输出,就会抛出一个TableException异常:

      1
      2
      3
      Exception in thread "main" org.apache.flink.table.api.TableException: Table sink
      'default_catalog.default_database.Unregistered_DataStream_Sink_1' doesn't
      support consuming update changes ...
    • 因为print本身也可以看作一个Sink操作,所以这个异常就是说打印输出的Sink操作不支持对数据进行更新。具体来说,urlCountTable这个表中进行了分组聚合统计,所以表中的每一行是会“更新”的。也就是说,Alice的第一个点击事件到来,表中会有一行(Alice, 1);第二个点击事件到来,这一行就要更新为(Alice, 2)。但之前的(Alice, 1)已经打印输出了,“覆水难收”,我们怎么能对它进行更改呢?所以就会抛出异常。

    • 解决的思路是,对于这样有更新操作的表,我们不要试图直接把它转换成DataStream打印输出,而是记录一下它的“更新日志”(change log)。这样一来,对于表的所有更新操作,就变成了一条更新日志的流,我们就可以转换成流打印输出了。

    • 代码中需要调用的是表环境的toChangelogStream()方法:

      1
      2
      3
      4
      5
      6
      7
      Table urlCountTable = tableEnv.sqlQuery(
      "SELECT user, COUNT(url) " +
      "FROM EventTable " +
      "GROUP BY user "
      );
      // 将表转换成更新日志流
      tableEnv.toChangelogStream(urlCountTable).print();
    • 与“更新日志流”(Changelog Streams)对应的,是那些只做了简单转换、没有进行聚合统计的表,例如前面提到的maryClickTable。它们的特点是数据只会插入、不会更新,所以也被叫作“仅插入流”(Insert-Only Streams)。

3.6.2 将流(DataStream)转换成表(Table)

  • 调用fromDataStream()方法。

    • 想要将一个DataStream转换成表也很简单,可以通过调用表环境的fromDataStream()方法来实现,返回的就是一个Table对象。例如,我们可以直接将事件流eventStream转换成一个表:

      1
      2
      3
      4
      5
      6
      7
      8
      9
      10
      11
      StreamExecutionEnvironment env =
      StreamExecutionEnvironment.getExecutionEnvironment();

      // 获取表环境
      StreamTableEnvironment tableEnv = StreamTableEnvironment.create(env);

      // 读取数据源
      SingleOutputStreamOperator<Event> eventStream = env.addSource(...)

      // 将数据流转换成表
      Table eventTable = tableEnv.fromDataStream(eventStream);
    • 由于流中的数据本身就是定义好的POJO类型Event,所以我们将流转换成表之后,每一行数据就对应着一个Event,而表中的列名就对应着Event中的属性。

    • 另外,我们还可以在fromDataStream()方法中增加参数,用来指定提取哪些属性作为表中的字段名,并可以任意指定位置:

      1
      2
      3
      // 提取 Event 中的 timestamp 和 url 作为表中的列
      Table eventTable2 = tableEnv.fromDataStream(eventStream, $("timestamp"),
      $("url"));
    • 需要注意的是,timestamp本身是SQL中的关键字,所以我们在定义表名、列名时要尽量避免。这时可以通过表达式的as()方法对字段进行重命名:

      1
      2
      3
      // 将 timestamp 字段重命名为 ts
      Table eventTable2 = tableEnv.fromDataStream(eventStream, $("timestamp").as("ts"),
      $("url"));
  • 调用createTemporaryView()方法。

    • 调用fromDataStream()方法简单直观,可以直接实现DataStream到Table的转换;不过如果我们希望直接在SQL中引用这张表,就还需要调用表环境的createTemporaryView()方法来创建虚拟视图了。

    • 对于这种场景,也有一种更简洁的调用方式。我们可以直接调用createTemporaryView()方法创建虚拟表,传入的两个参数,第一个依然是注册的表名,而第二个可以直接就是DataStream。之后仍旧可以传入多个参数,用来指定表中的字段:

      1
      2
      tableEnv.createTemporaryView("EventTable", eventStream,
      $("timestamp").as("ts"),$("url"));
  • 调用fromChangelogStream()方法。

    • 表环境还提供了一个方法fromChangelogStream(),可以将一个更新日志流转换成表。这个方法要求流中的数据类型只能是Row,而且每一个数据都需要指定当前行的更新类型 (RowKind);所以一般是由连接器帮我们实现的,直接应用比较少见。

3.6.3 支持的数据类型

  • 前面示例中的DataStream,流中的数据类型都是定义好的POJO类。如果DataStream中的类型是简单的基本类型,还可以直接转换成表吗?这就涉及了Table中支持的数据类型。

    • 原子类型

      • 在Flink中,基础数据类型(Integer、Double、String)和通用数据类型(也就是不可再拆分的数据类型)统一称作“原子类型”。原子类型的DataStream,转换之后就成了只有一列的Table,列字段(field)的数据类型可以由原子类型推断出。另外,还可以在fromDataStream()方法里增加参数,用来重新命名列字段。

        1
        2
        3
        4
        5
        StreamTableEnvironment tableEnv = ...;
        DataStream<Long> stream = ...;

        // 将数据流转换成动态表,动态表只有一个字段,重命名为 myLong
        Table table = tableEnv.fromDataStream(stream, $("myLong"));
    • Tuple类型

      • 当原子类型不做重命名时,默认的字段名就是“f0”,容易想到,这其实就是将原子类型看作了一元组 Tuple1的处理结果。

      • Table支持Flink中定义的元组类型Tuple,对应在表中字段名默认就是元组中元素的属性名f0、f1、f2…。所有字段都可以被重新排序,也可以提取其中的一部分字段。字段还可以通过调用表达式的 as()方法来进行重命名。

        1
        2
        3
        4
        5
        6
        7
        8
        9
        10
        11
        12
        StreamTableEnvironment tableEnv = ...;
        DataStream<Tuple2<Long, Integer>> stream = ...;

        // 将数据流转换成只包含 f1 字段的表
        Table table = tableEnv.fromDataStream(stream, $("f1"));

        // 将数据流转换成包含 f0 和 f1 字段的表,在表中 f0 和 f1 位置交换
        Table table = tableEnv.fromDataStream(stream, $("f1"), $("f0"));

        // 将 f1 字段命名为 myInt,f0 命名为 myLong
        Table table = tableEnv.fromDataStream(stream, $("f1").as("myInt"),
        $("f0").as("myLong"));
    • POJO类型

      • Flink也支持多种数据类型组合成的“复合类型”,最典型的就是简单Java对象(POJO类型)。由于POJO中已经定义好了可读性强的字段名,这种类型的数据流转换成Table就显得无比顺畅了。

      • 将POJO类型的DataStream转换成Table,如果不指定字段名称,就会直接使用原始POJO类型中的字段名称。POJO中的字段同样可以被重新排序、提却和重命名,这在之前的例子中已经有过体现。

        1
        2
        3
        4
        5
        6
        StreamTableEnvironment tableEnv = ...;
        DataStream<Event> stream = ...;
        Table table = tableEnv.fromDataStream(stream);
        Table table = tableEnv.fromDataStream(stream, $("user"));
        Table table = tableEnv.fromDataStream(stream, $("user").as("myUser"),
        $("url").as("myUrl"));
    • Row类型

      • Flink中还定义了一个在关系型表中更加通用的数据类型——行(Row),它是Table中数据的基本组织形式。Row类型也是一种复合类型,它的长度固定,而且无法直接推断出每个字段的类型,所以在使用时必须指明具体的类型信息;我们在创建Table时调用的CREATE语句就会将所有的字段名称和类型指定,这在Flink中被称为表的“模式结构”(Schema)。除 此之外,Row类型还附加了一个属性 RowKind,用来表示当前行在更新操作中的类型。这样,Row就可以用来表示更新日志流(changelog stream)中的数据,从而架起了Flink中流和表的转换桥梁。

      • 所以在更新日志流中,元素的类型必须是Row,而且需要调用ofKind()方法来指定更新类型。下面是一个具体的例子:

        1
        2
        3
        4
        5
        6
        7
        8
        9
        DataStream<Row> dataStream =
        env.fromElements(
        Row.ofKind(RowKind.INSERT, "Alice", 12),
        Row.ofKind(RowKind.INSERT, "Bob", 5),
        Row.ofKind(RowKind.UPDATE_BEFORE, "Alice", 12),
        Row.ofKind(RowKind.UPDATE_AFTER, "Alice", 100));

        // 将更新日志流转换为表
        Table table = tableEnv.fromChangelogStream(dataStream);

3.6.4 综合应用示例

  • 现在,我们可以将介绍过的所有API整合起来,写出一段完整的代码。同样还是用户的一组点击事件,我们可以查询出某个用户(例如Alice)点击的url列表,也可以统计出每个用户累计的点击次数,这可以用两句SQL 来分别实现。具体代码如下:

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    public class TableToStreamExample {
    public static void main(String[] args) throws Exception {
    // 获取流环境
    StreamExecutionEnvironment env =
    StreamExecutionEnvironment.getExecutionEnvironment();
    env.setParallelism(1);
    // 读取数据源
    SingleOutputStreamOperator<Event> eventStream = env
    .fromElements(
    new Event("Alice", "./home", 1000L),
    new Event("Bob", "./cart", 1000L),
    new Event("Alice", "./prod?id=1", 5 * 1000L),
    new Event("Cary", "./home", 60 * 1000L),
    new Event("Bob", "./prod?id=3", 90 * 1000L),
    new Event("Alice", "./prod?id=7", 105 * 1000L)
    );
    // 获取表环境
    StreamTableEnvironment tableEnv = StreamTableEnvironment.create(env);
    // 将数据流转换成表
    tableEnv.createTemporaryView("EventTable", eventStream);
    // 查询 Alice 的访问 url 列表
    Table aliceVisitTable = tableEnv.sqlQuery("SELECT url, user FROM EventTable WHERE user = 'Alice'");

    // 统计每个用户的点击次数
    Table urlCountTable = tableEnv.sqlQuery("SELECT user, COUNT(url) FROM EventTable GROUP BY user");
    // 将表转换成数据流,在控制台打印输出
    tableEnv.toDataStream(aliceVisitTable).print("alice visit");
    tableEnv.toChangelogStream(urlCountTable).print("count");

    // 执行程序
    env.execute();
    }
    }

    1670744432909

    • 这里每条数据前缀的+I就是RowKind,表示INSERT(插入)。
    • 而由于统计点击次数时用到了分组聚合,造成结果表中数据会有更新操作,所以在打印输出时需要将表 urlCountTable 转换成更新日志流(changelog stream)。
    • 这里数据的前缀出现了+I、-U和+U三种RowKind,分别表示INSERT(插入)、UPDATE_BEFORE(更新前)和UPDATE_AFTER(更新后)。当收到每个用户的第一次点击事件时,会在表中插入一条数据,例如+I[Alice, 1]、+I[Bob, 1]。而之后每当用户增加一次点击事件,就会带来一次更新操作,更新日志流(changelog stream)中对应会出现两条数据,分别表示之前数据的失效和新数据的生效;例如当Alice的第二条点击数据到来时,会出现一个-U[Alice, 1]和一个+U[Alice, 2],表示Alice的点击个数从1变成了2。
    • 这种表示更新日志的方式,有点像是声明“撤回”了之前的一条数据、再插入一条更新后的数据,所以也叫作“撤回流”(Retract Stream)。

4、流处理中的表

  • Table API和SQL本质上都是基于关系型表的操作方式;而关系型表(Table)本身是有界的,更适合批处理的场景。所以在MySQL、Hive这样的固定数据集中进行查询,使用SQL就会显得得心应手。而对于Flink这样的流处理框架来说,要处理的是源源不断到来的无界数据流,我们无法等到数据都到齐再做查询,每来一条数据就应该更新一次结果;这时如果一定要使用表和SQL进行处理,就会显得有些别扭了,需要引入一些特殊的概念。

  • 我们可以将关系型表/SQL与流处理做一个对比,如表所示。

    关系型表/SQL流处理
    处理的数据对象字段元组的有界集合字段元组的无限序列
    查询(Query)可以访问到完整的数据输入无法访问到所有数据,必须“持续”等待流式输入
    对数据的访问
    查询终止条件生成固定大小的结果集后终止永不停止,根据持续收到的数据不断更新查询结果
  • 可以看到,其实关系型表和SQL,主要就是针对批处理设计的,这和流处理有着天生的隔阂。既然“八字不合”,那Flink中的Table API和SQL又是怎样做流处理的呢?接下来我们就来深入探讨一下流处理中表的概念。

4.1 动态表和持续查询

  • 流处理面对的数据是连续不断的,这导致了流处理中的“表”跟我们熟悉的关系型数据库中的表完全不同;而基于表执行的查询操作,也就有了新的含义。
  • 如果我们希望把流数据转换成表的形式,那么这表中的数据就会不断增长;如果进一步基于表执行SQL查询,那么得到的结果就不是一成不变的,而是会随着新数据的到来持续更新。

4.1.1 动态表(Dynamic Tables)

  • 当流中有新数据到来,初始的表中会插入一行;而基于这个表定义的SQL查询,就应该在之前的基础上更新结果。这样得到的表就会不断地动态变化,被称为“动态表”(Dynamic Tables)。
  • 动态表是Flink在Table API和SQL中的核心概念,它为流数据处理提供了表和SQL支持。 我们所熟悉的表一般用来做批处理,面向的是固定的数据集,可以认为是“静态表”;而动态表则完全不同,它里面的数据会随时间变化。
  • 其实动态表的概念,我们在传统的关系型数据库中已经有所接触。数据库中的表,其实是一系列INSERT、UPDATE 和 DELETE 语句执行的结果;在关系型数据库中,我们一般把它称为更新日志流(changelog stream)。如果我们保存了表在某一时刻的快照(snapshot),那么接下来只要读取更新日志流,就可以得到表之后的变化过程和最终结果了。在很多高级关系型数据库(比如 Oracle、DB2)中都有“物化视图”(Materialized Views)的概念,可以用来缓存SQL查询的结果;它的更新其实就是不停地处理更新日志流的过程。

4.1.2 持续查询(Continuous Query)

  • 动态表可以像静态的批处理表一样进行查询操作。由于数据在不断变化,因此基于它定义的SQL查询也不可能执行一次就得到最终结果。这样一来,我们对动态表的查询也就永远不 会停止,一直在随着新数据的到来而继续执行。这样的查询就被称作“持续查询”(Continuous Query)。对动态表定义的查询操作,都是持续查询;而持续查询的结果也会是一个动态表。

  • 由于每次数据到来都会触发查询操作,因此可以认为一次查询面对的数据集,就是当前输入动态表中收到的所有数据。这相当于是对输入动态表做了一个“快照”(snapshot),当作有限数据集进行批处理;流式数据的到来会触发连续不断的快照查询,像动画一样连贯起来,就构成了“持续查询”。

  • 如图所示,描述了持续查询的过程。这里我们也可以清晰地看到流、动态表和持续查询的关系:

    1670745891481

    • 持续查询的步骤如下:
      • 流(stream)被转换为动态表(dynamic table);
      • 对动态表进行持续查询(continuous query),生成新的动态表;
      • 生成的动态表被转换成流。
    • 这样,只要API将流和动态表的转换封装起来,我们就可以直接在数据流上执行SQL查询,用处理表的方式来做流处理了。

4.2 将流转换成动态表

  • 如果把流看作一张表,那么流中每个数据的到来,都应该看作是对表的一次插入(Insert) 操作,会在表的末尾添加一行数据。因为流是连续不断的,而且之前的输出结果无法改变、只能在后面追加;所以我们其实是通过一个只有插入操作(insert-only)的更新日志(changelog)流,来构建一个表。

  • 为了更好地说明流转换成动态表的过程,我们还是用之前的例子来做分析说明。

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    // 获取流环境
    StreamExecutionEnvironment env =
    StreamExecutionEnvironment.getExecutionEnvironment();
    env.setParallelism(1);
    // 读取数据源
    SingleOutputStreamOperator<Event> eventStream = env
    .fromElements(
    new Event("Alice", "./home", 1000L),
    new Event("Bob", "./cart", 1000L),
    new Event("Alice", "./prod?id=1", 5 * 1000L),
    new Event("Cary", "./home", 60 * 1000L),
    new Event("Bob", "./prod?id=3", 90 * 1000L),
    new Event("Alice", "./prod?id=7", 105 * 1000L)
    );

    // 获取表环境
    StreamTableEnvironment tableEnv = StreamTableEnvironment.create(env);
    // 将数据流转换成表
    tableEnv.createTemporaryView("EventTable", eventStream, $("user"), $("url"),
    $("timestamp").as("ts"));

    // 统计每个用户的点击次数
    Table urlCountTable = tableEnv.sqlQuery("SELECT user, COUNT(url) as cnt FROM
    EventTable GROUP BY user");
    // 将表转换成数据流,在控制台打印输出
    tableEnv.toChangelogStream(urlCountTable).print("count");

    // 执行程序
    env.execute();
    • 我们现在的输入数据,就是用户在网站上的点击访问行为,数据类型被包装为POJO类型Event。我们将它转换成一个动态表,注册为EventTable。表中的字段定义如下:

      1
      2
      3
      4
      5
      [
      user: VARCHAR, // 用户名
      url: VARCHAR, // 用户访问的 URL
      ts: BIGINT // 时间戳
      ]
    • 如图所示,当用户点击事件到来时,就对应着动态表中的一次插入(Insert)操作, 每条数据就是表中的一行;随着插入更多的点击事件,得到的动态表将不断增长。

      1673077569663

4.3 用SQL持续查询

4.3.1 更新(Update)查询

  • 我们在代码中定义了一个SQL查询。

    1
    Table urlCountTable = tableEnv.sqlQuery("SELECT user, COUNT(url) as cnt FROM EventTable GROUP BY user");
  • 这个查询很简单,主要是分组聚合统计每个用户的点击次数。我们把原始的动态表注册为EventTable,经过查询转换后得到urlCountTable;这个结果动态表中包含两个字段,具体定义如下:

    1
    2
    3
    4
    [
    user: VARCHAR, // 用户名
    cnt: BIGINT // 用户访问 url 的次数
    ]
  • 如图所示,当原始动态表不停地插入新的数据时,查询得到的urlCountTable会持续地进行更改。由于count数量可能会叠加增长,因此这里的更改操作可以是简单的插入(Insert), 也可以是对之前数据的更新(Update)。换句话说,用来定义结果表的更新日志(changelog) 流中,包含了INSERT和UPDATE两种操作。这种持续查询被称为更新查询(Update Query), 更新查询得到的结果表如果想要转换成 DataStream,必须调用toChangelogStream()方法。

    1673077841930

    • 当查询启动时,原始动态表EventTable为空;
    • 当第一行Alice的点击数据插入EventTable表时,查询开始计算结果表,urlCountTable中插入一行数据[Alice,1]。
    • 当第二行Bob点击数据插入EventTable表时,查询将更新结果表并插入新行[Bob,1]。
    • 第三行数据到来,同样是Alice的点击事件,这时不会插入新行,而是生成一个针对已有行的更新操作。这样,结果表中第一行[Alice,1]就更新为[Alice,2]。
    • 当第四行Cary的点击数据插入到EventTable表时,查询将第三行[Cary,1]插入到结果表中。

4.3.2 追加(Append)查询

  • 上面的例子中,查询过程用到了分组聚合,结果表中就会产生更新操作。如果我们执行一个简单的条件查询,结果表中就会像原始表EventTable一样,只有插入(Insert)操作了。

    1
    Table aliceVisitTable = tableEnv.sqlQuery("SELECT url, user FROM EventTable WHERE user = 'Cary'");
  • 这样的持续查询,就被称为追加查询(Append Query),它定义的结果表的更新日志 (changelog)流中只有INSERT操作。追加查询得到的结果表,转换成DataStream调用方法没有限制,可以直接用toDataStream(),也可以像更新查询一样调用toChangelogStream()。

  • 这样看来,我们似乎可以总结一个规律:只要用到了聚合,在之前的结果上有叠加,就会产生更新操作,就是一个更新查询。但事实上,更新查询的判断标准是结果表中的数据是否会有UPDATE操作,如果聚合的结果不再改变,那么同样也不是更新查询。

  • 什么时候聚合的结果会保持不变呢?一个典型的例子就是窗口聚合。我们考虑开一个滚动窗口,统计每一小时内所有用户的点击次数,并在结果表中增加一个endT字段,表示当前统计窗口的结束时间。这时结果表的字段定义如下:

    1
    2
    3
    4
    5
    [
    user: VARCHAR, // 用户名
    endT: TIMESTAMP, // 窗口结束时间
    cnt: BIGINT // 用户访问 url 的次数
    ]
    • 如图所示,与之前的分组聚合一样,当原始动态表不停地插入新的数据时,查询得到的结果result会持续地进行更改。比如时间戳在12:00:00到12:59:59之间的有四条数据,其中Alice三次点击、Bob一次点击;所以当水位线达到13:00:00时窗口关闭,输出到结果表中的就是新增两条数据[Alice, 13:00:00, 3]和[Bob, 13:00:00, 1]。同理,当下一小时的窗口关闭时, 也会将统计结果追加到result表后面,而不会更新之前的数据。

      1673078312359

    • 所以我们发现,由于窗口的统计结果是一次性写入结果表的,所以结果表的更新日志流中只会包含插入 INSERT操作,而没有更新UPDATE操作。所以这里的持续查询,依然是一个追加(Append)查询。结果表result如果转换成DataStream,可以直接调用toDataStream()方法。

  • 需要注意的是,由于涉及时间窗口,我们还需要为事件时间提取时间戳和生成水位线。完整代码如下:

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    public class AppendQueryExample {
    public static void main(String[] args) throws Exception {
    StreamExecutionEnvironment env =
    StreamExecutionEnvironment.getExecutionEnvironment();
    env.setParallelism(1);
    // 读取数据源,并分配时间戳、生成水位线
    SingleOutputStreamOperator<Event> eventStream = env.fromElements(
    new Event("Alice", "./home", 1000L),
    new Event("Bob", "./cart", 1000L),
    new Event("Alice", "./prod?id=1", 25 * 60 * 1000L),
    new Event("Alice", "./prod?id=4", 55 * 60 * 1000L),
    new Event("Bob", "./prod?id=5", 3600 * 1000L + 60 * 1000L),
    new Event("Cary", "./home", 3600 * 1000L + 30 * 60 * 1000L),
    new Event("Cary", "./prod?id=7", 3600 * 1000L + 59 * 60 * 1000L)
    ).assignTimestampsAndWatermarks(
    WatermarkStrategy.<Event>forMonotonousTimestamps().withTimestampAssigner(new SerializableTimestampAssigner<Event>() {
    @Override
    public long extractTimestamp(Event element, long
    recordTimestamp) {
    return element.timestamp;
    }
    })
    );
    // 创建表环境
    StreamTableEnvironment tableEnv = StreamTableEnvironment.create(env);
    // 将数据流转换成表,并指定时间属性
    Table eventTable = tableEnv.fromDataStream(
    eventStream,
    $("user"),
    $("url"),
    $("timestamp").rowtime().as("ts")
    // 将 timestamp 指定为事件时间,并命名为 ts
    );
    // 为方便在 SQL 中引用,在环境中注册表 EventTable
    tableEnv.createTemporaryView("EventTable", eventTable);
    // 设置 1 小时滚动窗口,执行 SQL 统计查询
    Table result = tableEnv.sqlQuery("SELECT " +
    "user, " +
    "window_end AS endT, " + // 窗口结束时间
    "COUNT(url) AS cnt " + // 统计 url 访问次数
    "FROM TABLE( " +
    "TUMBLE( TABLE EventTable, " + // 1 小时滚动窗口
    "DESCRIPTOR(ts), " +
    "INTERVAL '1' HOUR)) " +
    "GROUP BY user, window_start, window_end "
    );
    tableEnv.toDataStream(result).print();
    env.execute();
    }
    }

    1673078534007

    • 可以看到,所有输出结果都以+I为前缀,表示都是以INSERT操作追加到结果表中的; 这是一个追加查询,所以我们直接使用toDataStream()转换成流是没有问题的。这里输出的window_end是一个 TIMESTAM 类型;由于我们直接以一个长整型数作为事件发生的时间戳, 所以可以看到对应的都是1970年1月1日的时间。

4.4 将动态表转换为流

  • 与关系型数据库中的表一样,动态表也可以通过插入(Insert)、更新(Update)和删除(Delete)操作,进行持续的更改。将动态表转换为流或将其写入外部系统时,就需要对这些更改操作进行编码,通过发送编码消息的方式告诉外部系统要执行的操作。在Flink中,Table API和SQL支持三种编码方式:

    • 仅追加(Append-only)流:仅通过插入(Insert)更改来修改的动态表,可以直接转换为“仅追加”流。这个流中发出的数据,其实就是动态表中新增的每一行。

    • 撤回(Retract)流:撤回流是包含两类消息的流,添加(add)消息和撤回(retract)消息。

      • 具体的编码规则是:INSERT插入操作编码为add消息;DELETE删除操作编码为retract消息;而UPDATE更新操作则编码为被更改行的retract消息,和更新后行(新行)的add消息。这样,我们可以通过编码后的消息指明所有的增删改操作,一个动态表就可以转换为撤回流了。

      • 可以看到,更新操作对于撤回流来说,对应着两个消息:之前数据的撤回(删除)和新数据的插入。如图所示,显示了将动态表转换为撤回流的过程。

        1673078844138

      • 这里我们用+代表add消息(对应插入INSERT操作),用-代表retract消息(对应删除DELETE操作);当Alice的第一个点击事件到来时,结果表新增一条数据[Alice, 1];而当Alice的第二个点击事件到来时,结果表会将[Alice, 1]更新为[Alice, 2],对应的编码就是删除[Alice, 1]、 插入[Alice, 2]。这样当一个外部系统收到这样的两条消息时,就知道是要对Alice的点击统计。

    • 更新插入(Upsert)流:更新插入流中只包含两种类型的消息:更新插入(upsert)消息和删除(delete)消息。 所谓的“upsert”其实是“update”和“insert”的合成词,所以对于更新插入流来说,INSERT插入操作和UPDATE更新操作,统一被编码为upsert消息;而DELETE删除操作则被编码为delete 消息。

      • 既然更新插入流中不区分插入(insert)和更新(update),那我们自然会想到一个问题:如果希望更新一行数据时,怎么保证最后做的操作不是插入呢?

      • 这就需要动态表中必须有唯一的键(key)。通过这个key进行查询,如果存在对应的数据就做更新(update),如果不存在就直接插入(insert)。这是一个动态表可以转换为更新插入流的必要条件。当然,收到这条流中数据的外部系统,也需要知道这唯一的键(key),这样才能正确地处理消息。

      • 如图所示,显示了将动态表转换为更新插入流的过程。

        1673079044574

      • 可以看到,更新插入流跟撤回流的主要区别在于,更新(update)操作由于有key的存在, 只需要用单条消息编码就可以,因此效率更高。

      • 需要注意的是,在代码里将动态表转换为DataStream时,只支持仅追加(append-only) 和撤回(retract)流,我们调用toChangelogStream()得到的其实就是撤回流;这也很好理解, DataStream中并没有key的定义,所以只能通过两条消息一减一增来表示更新操作。而连接到外部系统时,则可以支持不同的编码方法,这取决于外部系统本身的特性。

5、时间属性和窗口

  • 基于时间的操作(比如时间窗口),需要定义相关的时间语义和时间数据来源的信息。在Table API和SQL 中,会给表单独提供一个逻辑上的时间字段,专门用来在表处理程序中指示时间。
  • 所以所谓的时间属性(time attributes),其实就是每个表模式结构(schema)的一部分。 它可以在创建表的DDL里直接定义为一个字段,也可以在DataStream转换成表时定义。一旦定义了时间属性,它就可以作为一个普通字段引用,并且可以在基于时间的操作中使用。
  • 时间属性的数据类型为TIMESTAMP,它的行为类似于常规时间戳,可以直接访问并且进行计算。
  • 按照时间语义的不同,我们可以把时间属性的定义分成事件时间(event time)和处理时间(processing time)两种情况。

5.1 事件时间

  • 我们在实际应用中,最常用的就是事件时间。在事件时间语义下,允许表处理程序根据每个数据中包含的时间戳(也就是事件发生的时间)来生成结果。
  • 事件时间语义最大的用途就是处理乱序事件或者延迟事件的场景。我们通过设置水位线 (watermark)来表示事件时间的进展,而水位线可以根据数据的最大时间戳设置一个延迟时间。这样即使在出现乱序的情况下,对数据的处理也可以获得正确的结果。
  • 为了处理无序事件,并区分流中的迟到事件。Flink需要从事件数据中提取时间戳,并生成水位线,用来推进事件时间的进展。
  • 事件时间属性可以在创建表DDL中定义,也可以在数据流和表的转换中定义。

5.1.1 在创建表的DDL中定义

  • 在创建表的DDL(CREATE TABLE 语句)中,可以增加一个字段,通过WATERMARK语句来定义事件时间属性。WATERMARK语句主要用来定义水位线(watermark)的生成表达式,这个表达式会将带有事件时间戳的字段标记为事件时间属性,并在它基础上给出水位线的延迟时间。具体定义方式如下:

    1
    2
    3
    4
    5
    6
    7
    8
    CREATE TABLE EventTable(
    user STRING,
    url STRING,
    ts TIMESTAMP(3),
    WATERMARK FOR ts AS ts - INTERVAL '5' SECOND
    ) WITH (
    ...
    );
    • 这里我们把ts字段定义为事件时间属性,而且基于ts设置了5秒的水位线延迟。这里的“5 秒”是以“时间间隔”的形式定义的,格式是INTERVAL <数值> <时间单位>。这里的数值必须用单引号引起来,而单位用SECOND和SECONDS是等效的。

    • Flink中支持的事件时间属性数据类型必须为TIMESTAMP或者TIMESTAMP_LTZ。这里TIMESTAMP_LTZ是指带有本地时区信息的时间戳(TIMESTAMP WITH LOCAL TIME ZONE);一般情况下如果数据中的时间戳是“年-月-日-时-分-秒”的形式,那就是不带时区信息的,可以将事件时间属性定义为TIMESTAMP类型。

    • 而如果原始的时间戳就是一个长整型的毫秒数,这时就需要另外定义一个字段来表示事件时间属性,类型定义为TIMESTAMP_LTZ会更方便:

      1
      2
      3
      4
      5
      6
      7
      8
      9
      CREATE TABLE events (
      user STRING,
      url STRING,
      ts BIGINT,
      ts_ltz AS TO_TIMESTAMP_LTZ(ts, 3),
      WATERMARK FOR ts_ltz AS time_ltz - INTERVAL '5' SECOND
      ) WITH (
      ...
      );
      • 这里我们另外定义了一个字段ts_ltz,是把长整型的ts转换为TIMESTAMP_LTZ得到的; 进而使用 WATERMARK语句将它设为事件时间属性,并设置5秒的水位线延迟。

5.1.2 在数据流转换为表时定义

  • 事件时间属性也可以在将DataStream转换为表的时候来定义。我们调用fromDataStream()方法创建表时,可以追加参数来定义表中的字段结构;这时可以给某个字段加上.rowtime()后缀,就表示将当前字段指定为事件时间属性。这个字段可以是数据中本不存在、额外追加上去的“逻辑字段”,就像之前DDL中定义的第二种情况;也可以是本身固有的字段,那么这个字段就会被事件时间属性所覆盖,类型也会被转换为TIMESTAMP。不论那种方式,时间属性字段中保存的都是事件的时间戳(TIMESTAMP 类型)。

  • 需要注意的是,这种方式只负责指定时间属性,而时间戳的提取和水位线的生成应该之前就在DataStream上定义好了。由于DataStream中没有时区概念,因此Flink会将事件时间属性解析成不带时区的TIMESTAMP类型,所有的时间值都被当作UTC标准时间。

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    // 方法一:
    // 流中数据类型为二元组 Tuple2,包含两个字段;需要自定义提取时间戳并生成水位线
    DataStream<Tuple2<String, String>> stream =
    inputStream.assignTimestampsAndWatermarks(...);
    // 声明一个额外的逻辑字段作为事件时间属性
    Table table = tEnv.fromDataStream(stream, $("user"), $("url"),
    $("ts").rowtime());

    // 方法二:
    // 流中数据类型为三元组 Tuple3,最后一个字段就是事件时间戳
    DataStream<Tuple3<String, String, Long>> stream =
    inputStream.assignTimestampsAndWatermarks(...);
    // 不再声明额外字段,直接用最后一个字段作为事件时间属性
    Table table = tEnv.fromDataStream(stream, $("user"), $("url"),
    $("ts").rowtime());

5.2 处理时间

  • 相比之下处理时间就比较简单了,它就是我们的系统时间,使用时不需要提取时间戳 (timestamp)和生成水位线(watermark)。因此在定义处理时间属性时,必须要额外声明一个字段,专门用来保存当前的处理时间。
  • 类似地,处理时间属性的定义也有两种方式:创建表DDL中定义,或者在数据流转换成表时定义。

5.2.1 在创建表的DDL中定义

  • 在创建表的DDL(CREATE TABLE语句)中,可以增加一个额外的字段,通过调用系统内置的PROCTIME()函数来指定当前的处理时间属性,返回的类型是TIMESTAMP_LTZ。

    1
    2
    3
    4
    5
    6
    7
    CREATE TABLE EventTable(
    user STRING,
    url STRING,
    ts AS PROCTIME()
    ) WITH (
    ...
    );
    • 这里的时间属性,其实是以“计算列”(computed column)的形式定义出来的。所谓的计算列是Flink SQL中引入的特殊概念,可以用一个AS语句来在表中产生数据中不存在的列,并且可以利用原有的列、各种运算符及内置函数。在前面事件时间属性的定义中,将ts字段转换成TIMESTAMP_LTZ类型的ts_ltz,也是计算列的定义方式。

5.2.2 在数据流转换为表时定义

  • 处理时间属性同样可以在将DataStream转换为表的时候来定义。我们调用fromDataStream()方法创建表时,可以用.proctime()后缀来指定处理时间属性字段。由于处理时间是系统时间,原始数据中并没有这个字段,所以处理时间属性一定不能定义在一个已有字段上,只能定义在表结构所有字段的最后,作为额外的逻辑字段出现。

    1
    2
    3
    4
    DataStream<Tuple2<String, String>> stream = ...;
    // 声明一个额外的字段作为处理时间属性字段
    Table table = tEnv.fromDataStream(stream, $("user"), $("url"),
    $("ts").proctime());

5.3 窗口(Window)

  • 有了时间属性,接下来就可以定义窗口进行计算了。我们知道,窗口可以将无界流切割成大小有限的“桶”(bucket)来做计算,通过截取有限数据集来处理无限的流数据。在DataStream API中提供了对不同类型的窗口进行定义和处理的接口,而在Table API和SQL中,类似的功能也都可以实现。

5.3.1 分组窗口(Group Window,老版本)

  • 在Flink 1.12之前的版本中,Table API和SQL提供了一组“分组窗口”(Group Window) 函数,常用的时间窗口如滚动窗口、滑动窗口、会话窗口都有对应的实现;具体在SQL中就是调用TUMBLE()、HOP()、SESSION(),传入时间属性字段、窗口大小等参数就可以了。以滚动窗口为例:

    1
    TUMBLE(ts, INTERVAL '1' HOUR)
    • 这里的ts是定义好的时间属性字段,窗口大小用“时间间隔”INTERVAL来定义。
  • 在进行窗口计算时,分组窗口是将窗口本身当作一个字段对数据进行分组的,可以对组内的数据进行聚合。基本使用方式如下:

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    Table result = tableEnv.sqlQuery(
    "SELECT " +
    "user, " +
    "TUMBLE_END(ts, INTERVAL '1' HOUR) as endT, " +
    "COUNT(url) AS cnt " +
    "FROM EventTable " +
    "GROUP BY " + // 使用窗口和用户名进行分组
    "user, " +
    "TUMBLE(ts, INTERVAL '1' HOUR)" // 定义 1 小时滚动窗口
    );
    • 这里定义了1小时的滚动窗口,将窗口和用户user一起作为分组的字段。用聚合函数COUNT()对分组数据的个数进行了聚合统计,并将结果字段重命名为cnt;用TUPMBLE_END()函数获取滚动窗口的结束时间,重命名为endT提取出来。
    • 分组窗口的功能比较有限,只支持窗口聚合,所以目前已经处于弃用(deprecated)的状态。

5.3.2 窗口表值函数(Windowing TVFs,新版本)

  • 从1.13版本开始,Flink开始使用窗口表值函数(Windowing table-valued functions, Windowing TVFs)来定义窗口。窗口表值函数是Flink定义的多态表函数(PTF),可以将表进行扩展后返回。表函数(table function)可以看作是返回一个表的函数。

  • 目前Flink提供了以下几个窗口TVF:

    • 滚动窗口(Tumbling Windows);
    • 滑动窗口(Hop Windows,跳跃窗口);
    • 累积窗口(Cumulate Windows);
    • 会话窗口(Session Windows,目前尚未完全支持)。
  • 在窗口TVF的返回值中,除去原始表中的所有列,还增加了用来描述窗口的额外3个列: “窗口起始点”(window_start)、“窗口结束点”(window_end)、“窗口时间”(window_time)。 起始点和结束点比较好理解,这里的“窗口时间”指的是窗口中的时间属性,它的值等于window_end - 1ms,所以相当于是窗口中能够包含数据的最大时间戳。

  • 在SQL中的声明方式,与以前的分组窗口是类似的,直接调用TUMBLE()、HOP()、CUMULATE()就可以实现滚动、滑动和累积窗口,不过传入的参数会有所不同。下面我们就分别对这几种窗口TVF进行介绍。

    • 滚动窗口(TUMBLE)

      • 滚动窗口在SQL中的概念与DataStream API中的定义完全一样,是长度固定、时间对齐、无重叠的窗口,一般用于周期性的统计计算。

      • 在SQL中通过调用TUMBLE()函数就可以声明一个滚动窗口,只有一个核心参数就是窗口大小(size)。在SQL中不考虑计数窗口,所以滚动窗口就是滚动时间窗口,参数中还需要将当前的时间属性字段传入;另外,窗口 TVF 本质上是表函数,可以对表进行扩展,所以还 应该把当前查询的表作为参数整体传入。具体声明如下:

        1
        TUMBLE(TABLE EventTable, DESCRIPTOR(ts), INTERVAL '1' HOUR)
        • 这里基于时间字段ts,对表EventTable中的数据开了大小为1小时的滚动窗口。窗口会将表中的每一行数据,按照它们ts的值分配到一个指定的窗口中。
    • 滑动窗口(HOP)

      • 滑动窗口的使用与滚动窗口类似,可以通过设置滑动步长来控制统计输出的频率。在SQL中通过调用 HOP()来声明滑动窗口;除了也要传入表名、时间属性外,还需要传入窗口大小(size) 和滑动步长(slide)两个参数。

        1
        HOP(TABLE EventTable, DESCRIPTOR(ts), INTERVAL '5' MINUTES, INTERVAL '1' HOURS));
        • 这里我们基于时间属性ts,在表EventTable上创建了大小为1小时的滑动窗口,每5分钟滑动一次。需要注意的是,紧跟在时间属性字段后面的第三个参数是步长(slide),第四个参数才是窗口大小(size)。
    • 累积窗口(CUMULATE)

      • 滚动窗口和滑动窗口,可以用来计算大多数周期性的统计指标。不过在实际应用中还会遇到这样一类需求:我们的统计周期可能较长,因此希望中间每隔一段时间就输出一次当前的统计值;与滑动窗口不同的是,在一个统计周期内,我们会多次输出统计值,它们应该是不断叠加累积的。

      • 例如,我们按天来统计网站的PV(Page View,页面浏览量),如果用1天的滚动窗口, 那需要到每天24点才会计算一次,输出频率太低;如果用滑动窗口,计算频率可以更高,但统计的就变成了“过去24 小时的 PV”。所以我们真正希望的是,还是按照自然日统计每天的PV,不过需要每隔1小时就输出一次当天到目前为止的PV值。这种特殊的窗口就叫作“累 积窗口”(Cumulate Window)。

        1675578954625

      • 累积窗口是窗口TVF中新增的窗口功能,它会在一定的统计周期内进行累积计算。累积窗口中有两个核心的参数:最大窗口长度(max window size)和累积步长(step)。所谓的最大窗口长度其实就是我们所说的“统计周期”,最终目的就是统计这段时间内的数据。如图所示,开始时,创建的第一个窗口大小就是步长step;之后的每个窗口都会在之前的基础上再扩展step的长度,直到达到最大窗口长度。在SQL中可以用CUMULATE()函数来定义,具体如下:

        1
        CUMULATE(TABLE EventTable, DESCRIPTOR(ts), INTERVAL '1' HOURS, INTERVAL '1' DAYS))
        • 这里我们基于时间属性ts,在表EventTable上定义了一个统计周期为1天、累积步长为1小时的累积窗口。注意第三个参数为步长step,第四个参数则是最大窗口长度。
  • 上面所有的语句只是定义了窗口,类似于DataStream API中的窗口分配器;在SQL中窗口的完整调用,还需要配合聚合操作和其它操作。

6、聚合(Aggregation)查询

  • 在SQL中,一个很常见的功能就是对某一列的多条数据做一个合并统计,得到一个或多个结果值;比如求和、最大最小值、平均值等等,这种操作叫作聚合(Aggregation)查询。Flink中的SQL是流处理与标准SQL结合的产物,所以聚合查询也可以分成两种:流处理中特有的聚合(主要指窗口聚合),以及SQL原生的聚合查询方式。

6.1 分组聚合

  • SQL中一般所说的聚合我们都很熟悉,主要是通过内置的一些聚合函数来实现的,比如SUM()、MAX()、MIN()、AVG()以及 COUNT()。它们的特点是对多条输入数据进行计算,得 到一个唯一的值,属于“多对一”的转换。比如我们可以通过下面的代码计算输入数据的个数:

    1
    Table eventCountTable = tableEnv.sqlQuery("select COUNT(*) from EventTable");
  • 而更多的情况下,我们可以通过GROUP BY子句来指定分组的键(key),从而对数据按照某个字段做一个分组统计。例如之前我们举的例子,可以按照用户名进行分组,统计每个用户点击url的次数:

    1
    SELECT user, COUNT(url) as cnt FROM EventTable GROUP BY user
  • 这种聚合方式,就叫作“分组聚合”(group aggregation)。从概念上讲,SQL中的分组聚合可以对应 DataStream API中keyBy之后的聚合转换,它们都是按照某个key对数据进行了划分,各自维护状态来进行聚合统计的。在流处理中,分组聚合同样是一个持续查询,而且是一个更新查询,得到的是一个动态表;每当流中有一个新的数据到来时,都会导致结果表的更新操作。因此,想要将结果表转换成流或输出到外部系统,必须采用撤回流(retract stream) 或更新插入流(upsert stream)的编码方式;如果在代码中直接转换成 DataStream打印输出, 需要调用toChangelogStream()。

  • 另外,在持续查询的过程中,由于用于分组的key可能会不断增加,因此计算结果所需要维护的状态也会持续增长。为了防止状态无限增长耗尽资源,Flink Table API和SQL可以在表环境中配置状态的生存时间(TTL):

    1
    2
    3
    4
    5
    TableEnvironment tableEnv = ...
    // 获取表环境的配置
    TableConfig tableConfig = tableEnv.getConfig();
    // 配置状态保持时间
    tableConfig.setIdleStateRetention(Duration.ofMinutes(60));
    • 或者也可以直接设置配置项table.exec.state.ttl:

      1
      2
      3
      TableEnvironment tableEnv = ...
      Configuration configuration = tableEnv.getConfig().getConfiguration();
      configuration.setString("table.exec.state.ttl", "60 min");
    • 这两种方式是等效的。需要注意,配置TTL有可能会导致统计结果不准确,这其实是以牺牲正确性为代价换取了资源的释放。

  • 此外,在Flink SQL的分组聚合中同样可以使用DISTINCT进行去重的聚合处理;可以使用HAVING对聚合结果进行条件筛选;还可以使用GROUPING SETS(分组集)设置多个分组情况分别统计。这些语法跟标准SQL中的用法一致,这里就不再详细展开了。

  • 可以看到,分组聚合既是SQL原生的聚合查询,也是流处理中的聚合操作,这是实际应用中最常见的聚合方式。当然,使用的聚合函数一般都是系统内置的,如果希望实现特殊需求也可以进行自定义。

6.2 窗口聚合

  • 在流处理中,往往需要将无限数据流划分成有界数据集,这就是所谓的“窗口”。之前已经介绍了窗口的声明方式,这相当于DataStrea中的窗口分配器(window assigner),只是明确了窗口的形式以及数据如何分配;而窗口具体的计算处理操作,在DataStream API中还需要窗口函数(window function)来进行定义。

  • 在Flink的Table API和SQL中,窗口的计算是通过“窗口聚合”(window aggregation) 来实现的。与分组聚合类似,窗口聚合也需要调用SUM()、MAX()、MIN()、COUNT()一类的聚合函数,通过GROUP BY子句来指定分组的字段。只不过窗口聚合时,需要将窗口信息作为分组key的一部分定义出来。在Flink 1.12版本之前,是直接把窗口自身作为分组key放在GROUP BY之后的,所以也叫“分组窗口聚合”;而1.13版本开始使用了 “窗口表值函数”(Windowing TVF),窗口本身返回的是就是一个表,所以窗口会出现在FROM后面,GROUP BY后面的则是窗口新增的字段window_start和window_end。

  • 比如,我们将5.3.1中分组窗口的聚合,用窗口TVF重新实现一下:

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    Table result = tableEnv.sqlQuery(
    "SELECT " +
    "user, " +
    "window_end AS endT, " +
    "COUNT(url) AS cnt " +
    "FROM TABLE( " +
    "TUMBLE( TABLE EventTable, " +
    "DESCRIPTOR(ts), " +
    "INTERVAL '1' HOUR)) " +
    "GROUP BY user, window_start, window_end "
    );
    • 这里我们以ts作为时间属性字段、基于EventTable定义了1小时的滚动窗口,希望统计出每小时每个用户点击url的次数。用来分组的字段是用户名user,以及表示窗口的window_start和window_end;而 TUMBLE()是表值函数,所以得到的是一个表(Table),我们的聚合查询就是在这个Table中进行的。这就是4.3.2小节中窗口聚合的实现方式。
  • Flink SQL目前提供了滚动窗口TUMBLE()、滑动窗口HOP()和累积窗口(CUMULATE) 三种表值函数(TVF)。在具体应用中,我们还需要提前定义好时间属性。下面是一段窗口聚合的完整代码,以累积窗口为例:

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    public class CumulateWindowExample {
    public static void main(String[] args) throws Exception {
    StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();
    env.setParallelism(1);
    // 读取数据源,并分配时间戳、生成水位线
    SingleOutputStreamOperator<Event> eventStream = env.fromElements(
    new Event("Alice", "./home", 1000L),
    new Event("Bob", "./cart", 1000L),
    new Event("Alice", "./prod?id=1", 25 * 60 * 1000L),
    new Event("Alice", "./prod?id=4", 55 * 60 * 1000L),
    new Event("Bob", "./prod?id=5", 3600 * 1000L + 60 * 1000L),
    new Event("Cary", "./home", 3600 * 1000L + 30 * 60 * 1000L),
    new Event("Cary", "./prod?id=7", 3600 * 1000L + 59 * 60 * 1000L)
    ).assignTimestampsAndWatermarks(
    WatermarkStrategy.<Event>forMonotonousTimestamps().withTimestampAssigner(new SerializableTimestampAssigner<Event>() {
    @Override
    public long extractTimestamp(Event element, long
    recordTimestamp) {
    return element.timestamp;
    }
    })
    );
    // 创建表环境
    StreamTableEnvironment tableEnv = StreamTableEnvironment.create(env);
    // 将数据流转换成表,并指定时间属性
    Table eventTable = tableEnv.fromDataStream(
    eventStream,
    $("user"),
    $("url"),
    $("timestamp").rowtime().as("ts")
    );
    // 为方便在 SQL 中引用,在环境中注册表 EventTable
    tableEnv.createTemporaryView("EventTable", eventTable);
    // 设置累积窗口,执行 SQL 统计查询
    Table result = tableEnv.sqlQuery(
    "SELECT " +
    "user, " +
    "window_end AS endT, " +
    "COUNT(url) AS cnt " +
    "FROM TABLE( " +
    "CUMULATE( TABLE EventTable, " + // 定义累积窗口
    "DESCRIPTOR(ts), " +
    "INTERVAL '30' MINUTE, " +
    "INTERVAL '1' HOUR)) " +
    "GROUP BY user, window_start, window_end "
    );
    tableEnv.toDataStream(result).print();
    env.execute();
    }
    }
    • 这里我们使用了统计周期为1小时、累积间隔为30分钟的累积窗口。可以看到,代码的架构和处理逻辑与 4.3.2小节中的实现完全一致,只是将滚动窗口TUMBLE()换成了累积窗口 CUMULATE()。代码执行结果如下:

      1675580349125

    • 与分组聚合不同,窗口聚合不会将中间聚合的状态输出,只会最后输出一个结果。我们可以看到,所有数据都是以INSERT操作追加到结果动态表中的,因此输出每行前面都有+I的前缀。所以窗口聚合查询都属于追加查询,没有更新操作,代码中可以直接用toDataStream()将结果表转换成流。

    • 具体来看,上面代码输入的前三条数据属于第一个半小时的累积窗口,其中Alice的访问数据有两条,Bob 的访问数据有1条,所以输出了两条结果[Alice, 1970-01-01T00:30, 2]和[Bob, 1970-01-01T00:30, 1];而之后又到来的一条Alice访问数据属于第二个半小时范围,同时也属于第一个1小时的统计周期 ,所以会在之前两条的基础上进行叠加,输出[Alice, 1970-01-01T00:30, 3],而Bob没有新的访问数据,因此依然输出[Bob, 1970-01-01T00:30, 1]。从第二个小时起,数据属于新的统计周期,就全部从零开始重新计数了。

  • 相比之前的分组窗口聚合,Flink 1.13版本的窗口表值函数(TVF)聚合有更强大的功能。 除了应用简单的聚合函数、提取窗口开始时间(window_start)和结束时间(window_end)之外, 窗口TVF还提供了一个 window_time 字段,用于表示窗口中的时间属性;这样就可以方便地进行窗口的级联(cascading window)和计算了。另外,窗口TVF还支持GROUPING SETS, 极大地扩展了窗口的应用范围。

  • 基于窗口的聚合,是流处理中聚合统计的一个特色,也是与标准SQL最大的不同之处。在实际项目中,很多统计指标其实都是基于时间窗口来进行计算的,所以窗口聚合是Flink SQL中非常重要的功能;基于窗口TVF的聚合未来也会有更多功能的扩展支持,比如窗口Top N、 会话窗口、窗口联结等等。

6.3 开窗(Over)聚合

  • 在标准SQL中还有另外一类比较特殊的聚合方式,可以针对每一行计算一个聚合值。比如说,我们可以以每一行数据为基准,计算它之前1小时内所有数据的平均值;也可以计算它之前10个数的平均值。就好像是在每一行上打开了一扇窗户、收集数据进行统计一样,这就是所谓的“开窗函数”。开窗函数的聚合与之前两种聚合有本质的不同:分组聚合、窗口TVF聚合都是“多对一”的关系,将数据分组之后每组只会得到一个聚合结果;而开窗函数是对每行都要做一次开窗聚合,因此聚合之后表中的行数不会有任何减少,是一个“多对多”的关系。

  • 与标准SQL中一致,Flink SQL中的开窗函数也是通过OVER子句来实现的,所以有时开窗聚合也叫作“OVER聚合”(Over Aggregation)。基本语法如下:

    1
    2
    3
    4
    5
    6
    7
    SELECT
    <聚合函数> OVER (
    [PARTITION BY <字段 1>[, <字段 2>, ...]]
    ORDER BY <时间属性字段>
    <开窗范围>),
    ...
    FROM ...
  • 这里OVER关键字前面是一个聚合函数,它会应用在后面OVER定义的窗口上。在OVER子句中主要有以下几个部分:

    • PARTITION BY(可选):用来指定分区的键(key),类似于GROUP BY的分组,这部分是可选的;

    • ORDER BY:OVER窗口是基于当前行扩展出的一段数据范围,选择的标准可以基于时间也可以基于数 量。不论那种定义,数据都应该是以某种顺序排列好的;而表中的数据本身是无序的。所以在OVER子句中必须用ORDER BY明确地指出数据基于那个字段排序。在Flink的流处理中,目前只支持按照时间属性的升序排列,所以这里ORDER BY后面的字段必须是定义好的时间属性。

    • 开窗范围:对于开窗函数而言,还有一个必须要指定的就是开窗的范围,也就是到底要扩展多少行来做聚合。这个范围是由BETWEEN <下界> AND <上界>来定义的,也就是“从下界到上界”的范围。目前支持的上界只能是CURRENT ROW,也就是定义一个“从之前某一行到当前行” 的范围,所以一般的形式为:

      1
      BETWEEN ... PRECEDING AND CURRENT ROW
  • 前面我们提到,开窗选择的范围可以基于时间,也可以基于数据的数量。所以开窗范围还应该在两种模式之间做出选择:范围间隔(RANGE intervals)和行间隔(ROW intervals)。

    • 范围间隔:范围间隔以RANGE为前缀,就是基于ORDER BY指定的时间字段去选取一个范围,一般就是当前行时间戳之前的一段时间。例如开窗范围选择当前行之前1小时的数据:

      1
      RANGE BETWEEN INTERVAL '1' HOUR PRECEDING AND CURRENT ROW
    • 行间隔:行间隔以ROWS为前缀,就是直接确定要选多少行,由当前行出发向前选取就可以了。例如开窗范围选择当前行之前的5行数据(最终聚合会包括当前行,所以一共6条数据):

      1
      ROWS BETWEEN 5 PRECEDING AND CURRENT ROW
      • 下面是一个具体示例:

        1
        2
        3
        4
        5
        6
        7
        SELECT user, ts,
        COUNT(url) OVER (
        PARTITION BY user
        ORDER BY ts
        RANGE BETWEEN INTERVAL '1' HOUR PRECEDING AND CURRENT ROW
        ) AS cnt
        FROM EventTable
      • 这里我们以ts作为时间属性字段,对EventTable中的每行数据都选取它之前1小时的所有数据进行聚合,统计每个用户访问url的总次数,并重命名为cnt。最终将表中每行的user,ts以及扩展出cnt提取出来。

        可以看到,整个开窗聚合的结果,是对每一行数据都有一个对应的聚合值,因此就像将表中扩展出了一个新的列一样。由于聚合范围上界只能到当前行,新到的数据一般不会影响之前数据的聚合结果,所以结果表只需要不断插入(INSERT)就可以了。执行上面SQL得到的结果表,可以用 toDataStream()直接转换成流打印输出。

  • 开窗聚合与窗口聚合(窗口TVF聚合)本质上不同,不过也还是有一些相似之处的:它们都是在无界的数据流上划定了一个范围,截取出有限数据集进行聚合统计;这其实都是“窗口”的思路。事实上,在Table API中确实就定义了两类窗口:分组窗口(GroupWindow)和开窗窗口(OverWindow);而在SQL中,也可以用 WINDOW子句来在SELECT外部单独定义一个OVER窗口:

    1
    2
    3
    4
    5
    6
    7
    8
    SELECT user, ts,
    COUNT(url) OVER w AS cnt,
    MAX(CHAR_LENGTH(url)) OVER w AS max_url
    FROM EventTable
    WINDOW w AS (
    PARTITION BY user
    ORDER BY ts
    ROWS BETWEEN 2 PRECEDING AND CURRENT ROW)
    • 上面的SQL中定义了一个选取之前2行数据的OVER窗口,并重命名 w;接下来就可以基于它调用多个聚合函数,扩展出更多的列提取出来。比如这里除统计url的个数外,还统计了url的最大长度:首先用 CHAR_LENGTH()函数计算出url的长度,再调用聚合函数MAX()进行聚合统计。这样,我们就可以方便重复引用定义好的OVER窗口了,大大增强了代码的可读性。

6.4 应用实例——Top N

  • 灵活使用各种类型的窗口以及聚合函数,可以实现不同的需求。一般的聚合函数,比如SUM()、MAX()、MIN()、COUNT()等,往往只是针对一组数据聚合得到一个唯一的值;所谓OVER聚合的“多对多”模式,也是针对每行数据都进行一次聚合才得到了多行的结果,对于每次聚合计算实际上得到的还是唯一的值。而有时我们可能不仅仅需要统计数据中的最大/最小值,还希望得到前N个最大/最小值;这时每次聚合的结果就不是一行,而是N行了。这就是经典的“Top N”应用场景。
  • Top N聚合字面意思是“最大N个”,这只是一个泛称,它不仅包括查询最大的N个值、也包括了查询最小的N个值的场景。
  • 理想的状态下,我们应该有一个TOPN()聚合函数,调用它对表进行聚合就可以得到想要选取的前N个值了。不过仔细一想就会发现,这个聚合函数并不容易实现:对于每一次聚合计算,都应该都有多行数据输入,并得到 N 行结果输出,这是一个真正意义上的“多对多”转换。这种函数相当于把一个表聚合成了另一个表,所以叫作“表聚合函数”(Table Aggregate Function)。表聚合函数的抽象比较困难,目前只有窗口TVF有能力提供直接的Top N聚合, 不过也尚未实现。
  • 所以目前在Flink SQL中没有能够直接调用的Top N函数,而是提供了稍微复杂些的变通实现方法。

6.4.1 普通Top N

  • 在Flink SQL中,是通过OVER聚合和一个条件筛选来实现Top N的。具体来说,是通过将一个特殊的聚合函数ROW_NUMBER()应用到OVER窗口上,统计出每一行排序后的行号,作为一个字段提取出来;然后再用 WHERE子句筛选行号小于等于N的那些行返回。基本语法如下:

    1
    2
    3
    4
    5
    6
    7
    8
    9
    SELECT ...
    FROM (
    SELECT ...,
    ROW_NUMBER() OVER (
    [PARTITION BY <字段 1>[, <字段 1>...]]
    ORDER BY <排序字段 1> [asc|desc][, <排序字段 2> [asc|desc]...]
    ) AS row_num
    FROM ...)
    WHERE row_num <= N [AND <其它条件>]
    • 这里的OVER窗口定义与之前的介绍基本一致,目的就是利用ROW_NUMBER()函数为每一行数据聚合得到一个排序之后的行号。行号重命名为row_num,并在外层的查询中以row_num <= N作为条件进行筛选,就可以得到根据排序字段统计的Top N结果了。需要对关键字额外做一些说明:
      • WHERE:用来指定Top N选取的条件,这里必须通过row_num <= N或者row_num < N + 1指定一 个“排名结束点”(rank end),以保证结果有界。
      • PARTITION BY:是可选的,用来指定分区的字段,这样我们就可以针对不同的分组分别统计Top N了。
      • ORDER BY:指定了排序的字段,因为只有排序之后,才能进行前N个最大/最小的选取。每个排序字 段后可以用asc或者desc来指定排序规则:asc为升序排列,取出的就是最小的N个值;desc为降序排序,对应的就是最大的N个值。默认情况下为升序,asc可以省略。
    • 之前介绍的OVER窗口不是说了,目前ORDER BY后面只能跟 时间字段、并且只支持升序吗?这里怎么又可以任意指定字段进行排序了呢?
      • 这是因为OVER窗口目前并不完善,不过针对Top N这样一个经典应用场景,Flink SQL专门用OVER 聚合做了优化实现。所以只有在Top N的应用场景中,OVER窗口ORDER BY后才可以指定其它排序字段;而要想实现Top N,就必须按照上面的格式进行定义,否则Flink SQL的优化器将无法正常解析。而且,目前Table API中并不支持ROW_NUMBER()函数,所 以也只有SQL中这一种通用的Top N实现方式。
    • 另外要注意,Top N的实现必须写成上面的嵌套查询形式。这是因为行号row_num是内部子查询聚合的结果,不可能在内部作为筛选条件,只能放在外层的WHERE子句中。
  • 下面是一个具体的示例,我们统计每个用户的访问事件中,按照字符长度排序的前两个url:

    1
    2
    3
    4
    5
    6
    7
    8
    9
    SELECT user, url, ts, row_num
    FROM (
    SELECT *,
    ROW_NUMBER() OVER (
    PARTITION BY user
    ORDER BY CHAR_LENGTH(url) desc
    ) AS row_num
    FROM EventTable)
    WHERE row_num <= 2
    • 这里我们以用户来分组,以访问url的字符长度作为排序的字段,降序排列后用聚合统计出每一行的行号,这样就相当于在EventTable基础上扩展出了一列row_num。而后筛选出行号小于等于2的所有数据,就得到了每个用户访问的长度最长的两个url。
    • 需要特别说明的是,这里的Top N聚合是一个更新查询。新数据到来后,可能会改变之前数据的排名,所以会有更新(UPDATE)操作。这是ROW_NUMBER()聚合函数的特性决定的。因此,如果执行上面的SQL得到结果表,需要调用toChangelogStream()才能转换成流打印输出。

6.4.2 窗口Top N

  • 除了直接对数据进行Top N的选取,我们也可以针对窗口来做Top N。

  • 例如电商行业,实际应用中往往有这样的需求:统计一段时间内的热门商品。这就需要先开窗口,在窗口中统计每个商品的点击量;然后将统计数据收集起来,按窗口进行分组,并按点击量大小降序排序,选取前N个作为结果返回。

  • 我们已经知道,Top N聚合本质上是一个表聚合函数,这和窗口表值函数(TVF)有天然的联系。尽管如此,想要基于窗口TVF实现一个通用的Top N聚合函数还是比较麻烦的,目前Flink SQL尚不支持。不过我们同样可以借鉴之前的思路,使用OVER窗口统计行号来实现。

  • 具体来说,可以先做一个窗口聚合,将窗口信息window_start、window_end连同每个商品的点击量一并返回,这样就得到了聚合的结果表,包含了窗口信息、商品和统计的点击量。 接下来就可以像一般的Top N那样定义OVER窗口了,按窗口分组,按点击量排序,用ROW_NUMBER()统计行号并筛选前N行就可以得到结果。所以窗口Top N的实现就是窗口聚合与OVER聚合的结合使用。

  • 下面是一个具体案例的代码实现。由于用户访问事件Event中没有商品相关信息,因此我们统计的是每小时内有最多访问行为的用户,取前两名,相当于是一个每小时活跃用户的查询。

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    public class WindowTopNExample {
    public static void main(String[] args) throws Exception {
    StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();
    env.setParallelism(1);
    // 读取数据源,并分配时间戳、生成水位线
    SingleOutputStreamOperator<Event> eventStream = env.fromElements(
    new Event("Alice", "./home", 1000L),
    new Event("Bob", "./cart", 1000L),
    new Event("Alice", "./prod?id=1", 25 * 60 * 1000L),
    new Event("Alice", "./prod?id=4", 55 * 60 * 1000L),
    new Event("Bob", "./prod?id=5", 3600 * 1000L + 60 * 1000L),
    new Event("Cary", "./home", 3600 * 1000L + 30 * 60 * 1000L),
    new Event("Cary", "./prod?id=7", 3600 * 1000L + 59 * 60 * 1000L)
    )
    .assignTimestampsAndWatermarks(WatermarkStrategy.<Event>forMonotonousTimestamps()
    .withTimestampAssigner(new SerializableTimestampAssigner<Event>() {
    @Override
    public long extractTimestamp(Event element, long recordTimestamp) {
    return element.timestamp;
    }
    })
    );
    // 创建表环境
    StreamTableEnvironment tableEnv = StreamTableEnvironment.create(env);
    // 将数据流转换成表,并指定时间属性
    Table eventTable = tableEnv.fromDataStream(
    eventStream,
    $("user"),
    $("url"),
    $("timestamp").rowtime().as("ts")
    // 将 timestamp 指定为事件时间,并命名为 ts
    );
    // 为方便在 SQL 中引用,在环境中注册表 EventTable
    tableEnv.createTemporaryView("EventTable", eventTable);
    // 定义子查询,进行窗口聚合,得到包含窗口信息、用户以及访问次数的结果表
    String subQuery = "SELECT window_start, window_end, user, COUNT(url) as cnt " +
    "FROM TABLE ( " +
    "TUMBLE( TABLE EventTable, DESCRIPTOR(ts), INTERVAL '1' HOUR )) " +
    "GROUP BY window_start, window_end, user ";
    // 定义 Top N 的外层查询
    String topNQuery = "SELECT * " +
    "FROM (" +
    "SELECT *, " +
    "ROW_NUMBER() OVER ( " +
    "PARTITION BY window_start, window_end " +
    "ORDER BY cnt desc " +
    ") AS row_num " +
    "FROM (" + subQuery + ")) " +
    "WHERE row_num <= 2";
    // 执行 SQL 得到结果表
    Table result = tableEnv.sqlQuery(topNQuery);
    tableEnv.toDataStream(result).print();
    env.execute();
    }
    }
    • 这里为了更好的代码可读性,我们将SQL拆分成了用来做窗口聚合的内部子查询,和套用Top N模板的外层查询。

      • 首先基于ts时间字段定义1小时滚动窗口,统计EventTable中每个用户的访问次数, 重命名为 cnt;为了方便后面做排序,我们将窗口信息window_start 和window_end也提取出来,与user和cnt一起作为聚合结果表中的字段。
      • 然后套用Top N模板,对窗口聚合的结果表中每一行数据进行OVER聚合统计行号。这里以窗口信息进行分组,按访问次数cnt进行排序,并筛选行号小于等于2的数据,就可以得到每个窗口内访问次数最多的前两个用户了。
    • 运行结果如下:

      1675583036253

      • 可以看到,第一个1小时窗口中,Alice有3次访问排名第一,Bob有1次访问排名第二; 而第二小时内,Cary以2次访问占据活跃榜首,Bob仍以1次访问排名第二。由于窗口的统计结果只会最终输出一次,所以排名也是确定的,这里结果表中只有插入(INSERT)操作。 也就是说,窗口Top N是追加查询,可以直接用toDataStream()将结果表转换成流打印输出。

7、联结(Join)查询

  • 在标准SQL中,可以将多个表连接合并起来,从中查询出想要的信息;这种操作就是表的联结(Join)。在Flink SQL中,同样支持各种灵活的联结(Join)查询,操作的对象是动态表。
  • 在流处理中,动态表的Join对应着两条数据流的Join操作。与上一节的聚合查询类似,Flink SQL中的联结查询大体上也可以分为两类:SQL原生的联结查询方式,和流处理中特有的联结查询。

7.1 常规联结查询

  • 常规联结(Regular Join)是SQL中原生定义的Join方式,是最通用的一类联结操作。它的具体语法与标准 SQL的联结完全相同,通过关键字JOIN来联结两个表,后面用关键字ON来指明联结条件。按照习惯,我们一般以“左侧”和“右侧”来区分联结操作的两个表。
  • 在两个动态表的联结中,任何一侧表的插入(INSERT)或更改(UPDATE)操作都会让联结的结果表发生改变。例如,如果左侧有新数据到来,那么它会与右侧表中所有之前的数据进行联结合并,右侧表之后到来的新数据也会与这条数据连接合并。所以,常规联结查询一般是更新(Update)查询。
  • 与标准SQL一致,Flink SQL的常规联结也可以分为内联结(INNER JOIN)和外联结(OUTER JOIN),区别在于结果中是否包含不符合联结条件的行。目前仅支持“等值条件”作为联结条件,也就是关键字ON后面必须是判断两表中字段相等的逻辑表达式。

7.1.1 等值内联结(INNER Equi-JOIN)

  • 内联结用INNER JOIN来定义,会返回两表中符合联接条件的所有行的组合,也就是所谓的笛卡尔积(Cartesian product)。目前仅支持等值联结条件。

  • 例如之前提到的“订单表”(定义为 Order)和“商品表”(定义为 Product)的联结查询,就可以用以下SQL实现:

    1
    2
    3
    4
    SELECT *
    FROM Order
    INNER JOIN Product
    ON Order.product_id = Product.id
    • 这里是一个内联结,联结条件是订单数据的product_id和商品数据的id相等。由于订单表中出现的商品id一定会在商品表中出现,因此这样得到的联结结果表,就包含了订单表Order中所有订单数据对应的详细信息。

7.1.2 等值外联结(OUTER Equi-JOIN)

  • 与内联结类似,外联结也会返回符合联结条件的所有行的笛卡尔积;另外,还可以将某一侧表中找不到任何匹配的行也单独返回。Flink SQL 支持左外(LEFT JOIN)、右外(RIGHT JOIN) 和全外(FULL OUTER JOIN),分别表示会将左侧表、右侧表以及双侧表中没有任何匹配的行返回。例如,订单表中未必包含了商品表中的所有 ID,为了将哪些没有任何订单的商品信息也查询出来,我们就可以使用右外联结(RIGHT JOIN)。当然,外联结查询目前也仅支持等值联结条件。具体用法如下:

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    SELECT *
    FROM Order
    LEFT JOIN Product
    ON Order.product_id = Product.id
    SELECT *
    FROM Order
    RIGHT JOIN Product
    ON Order.product_id = Product.id
    SELECT *
    FROM Order
    FULL OUTER JOIN Product
    ON Order.product_id = Product.id

7.2 间隔联结查询

  • 我们曾经学习过DataStream API中的双流Join,包括窗口联结(window join) 和间隔联结(interval join)。两条流的Join就对应着SQL中两个表的Join,这是流处理中特有的联结方式。目前Flink SQL还不支持窗口联结,而间隔联结则已经实现。

  • 间隔联结(Interval Join)返回的,同样是符合约束条件的两条中数据的笛卡尔积。只不过这里的“约束条件”除了常规的联结条件外,还多了一个时间间隔的限制。具体语法有以下要点:

    • 两表的联结:间隔联结不需要用JOIN关键字,直接在FROM后将要联结的两表列出来就可以,用逗号分隔。这与标准SQL中的语法一致,表示一个“交叉联结”(Cross Join),会返回两表中所有行的笛卡尔积。
    • 联结条件:联结条件用WHERE子句来定义,用一个等值表达式描述。交叉联结之后再用WHERE进行条件筛选,效果跟内联结INNER JOIN … ON …非常类似。
    • 时间间隔限制:我们可以在WHERE子句中,联结条件后用AND追加一个时间间隔的限制条件;做法是提取左右两侧表中的时间字段,然后用一个表达式来指明两者需要满足的间隔限制。具体定义方式有下面三种,这里分别用ltime和rtime表示左右表中的时间字段:
      • ltime = rtime
      • ltime >= rtime AND ltime < rtime + INTERVAL ‘10’ MINUTE
      • ltime BETWEEN rtime - INTERVAL ‘10’ SECOND AND rtime + INTERVAL ‘5’ SECOND
  • 判断两者相等,这是最强的时间约束,要求两表中数据的时间必须完全一致才能匹配;一般情况下,我们还是会放宽一些,给出一个间隔。间隔的定义可以用<,<=,>=,>这一类的 关系不等式,也可以用 BETWEEN … AND …这样的表达式。

  • 例如,我们现在除了订单表Order外,还有一个“发货表”Shipment,要求在收到订单后四个小时内发货。那么我们就可以用一个间隔联结查询,把所有订单与它对应的发货信息连接合并在一起返回。

    1
    2
    3
    4
    SELECT *
    FROM Order o, Shipment s
    WHERE o.id = s.order_id
    AND o.order_time BETWEEN s.ship_time - INTERVAL '4' HOUR AND s.ship_time
  • 在流处理中,间隔联结查询只支持具有时间属性的“仅追加”(Append-only)表。

  • 那对于有更新操作的表,又怎么办呢?除了间隔联结之外,Flink SQL还支持时间联结 (Temporal Join),这主要是针对“版本表”(versioned table)而言的。所谓版本表,就是记录 了数据随着时间推移版本变化的表,可以理解成一个“更新日志”(change log),它就是具有时间属性、还会进行更新操作的表。当我们联结某个版本表时,并不是把当前的数据连接合并 起来就行了,而是希望能够根据数据发生的时间,找到当时的“版本”;这种根据更新时间提取当时的值进行联结的操作,就叫作“时间联结”(Temporal Join)。

8、函数

  • Flink的Table API和SQL同样提供了函数的功能。两者在调用时略有不同:Table API中的函数是通过数据对象的方法调用来实现的;而SQL则是直接引用函数名称,传入数据作为参数。例如,要把一个字符串str转换成全大写的形式,Table API的写法是调用str这个String对象的upperCase()方法:

    1
    str.upperCase();
  • 而SQL中的写法就是直接引用UPPER()函数,将str作为参数传入:

    1
    UPPER(str)
  • 由于Table API是内嵌在Java语言中的,很多方法需要在类中额外添加,因此扩展功能比较麻烦,目前支持的函数比较少;而且Table API也不如SQL的通用性强,所以一般情况下较少使用。下面我们主要介绍Flink SQL中函数的使用。

  • Flink SQL中的函数可以分为两类:一类是SQL中内置的系统函数,直接通过函数名调用就可以,能够实现一些常用的转换操作,比如之前我们用到的COUNT()、CHAR_LENGTH()、UPPER()等等;而另一类函数则是用户自定义的函数(UDF),需要在表环境中注册才能使用。 接下来我们就对这两类函数分别进行介绍。

8.1 系统函数

  • 系统函数(System Functions)也叫内置函数(Built-in Functions),是在系统中预先实现好的功能模块。我们可以通过固定的函数名直接调用,实现想要的转换操作。Flink SQL提供了大量的系统函数,几乎支持所有的标准SQL中的操作,这为我们使用SQL编写流处理程序提供了极大的方便。
  • Flink SQL中的系统函数又主要可以分为两大类:标量函数(Scalar Functions)和聚合函数(Aggregate Functions)。

8.1.1 标量函数(Scalar Functions)

  • 所谓的“标量”,是指只有数值大小、没有方向的量;所以标量函数指的就是只对输入数据做转换操作、返回一个值的函数。这里的输入数据对应在表中,一般就是一行数据中1个或多个字段,因此这种操作有点像流处理转换算子中的map。另外,对于一些没有输入参数、直 接可以得到唯一结果的函数,也属于标量函数。
  • 标量函数是最常见、也最简单的一类系统函数,数量非常庞大,很多在标准SQL中也有 定义。所以我们这里只对一些常见类型列举部分函数,做一个简单概述,具体应用可以查看官网的完整函数列表。
    • 比较函数(Comparison Functions)。比较函数其实就是一个比较表达式,用来判断两个值之间的关系,返回一个布尔类型的值。 这个比较表达式可以是用 <、>、= 等符号连接两个值,也可以是用关键字定义的某种判断。 例如:
      • value1 = value2:判断两个值相等;
      • value1 <> value2:判断两个值不相等;
      • value IS NOT NULL:判断value不为空。
    • 逻辑函数(Logical Functions)。逻辑函数就是一个逻辑表达式,也就是用与(AND)、或(OR)、非(NOT)将布尔类型的值连接起来,也可以用判断语句(IS、IS NOT)进行真值判断;返回的还是一个布尔类型的值。例如:
      • boolean1 OR boolean2:布尔值boolean1与布尔值boolean2取逻辑或;
      • boolean IS FALSE:判断布尔值boolean是否为false;
      • NOT boolean:布尔值boolean取逻辑非。
    • 算术函数(Arithmetic Functions)。进行算术计算的函数,包括用算术符号连接的运算,和复杂的数学运算。例如:
      • numeric1 + numeric2:两数相加;
      • POWER(numeric1, numeric2):幂运算,取数numeric1的numeric2次方;
      • RAND():返回(0.0, 1.0)区间内的一个double类型的伪随机数。
    • 字符串函数(String Functions)。进行字符串处理的函数。例如:
      • string1 || string2:两个字符串的连接;
      • UPPER(string):将字符串string转为全部大写;
      • CHAR_LENGTH(string):计算字符串string的长度。
    • 时间函数(Temporal Functions)。进行与时间相关操作的函数。例如:
      • DATE string:按格式”yyyy-MM-dd”解析字符串string,返回类型为SQL Date;
      • TIMESTAMP string:按格式”yyyy-MM-dd HH:mm:ss[.SSS]”解析,返回类型为SQL timestamp;
      • CURRENT_TIME:返回本地时区的当前时间,类型为SQL time(与LOCALTIME等价);
      • INTERVAL string range:返回一个时间间隔。string 表示数值;range可以是DAY,MINUTE,DAT TO HOUR等单位,也可以是YEAR TO MONTH这样的复合单位。如“2 年10个月”可INTERVAL ‘2-10’ YEAR TO MONTH。

8.1.2 聚合函数(Aggregate Functions)

  • 聚合函数是以表中多个行作为输入,提取字段进行聚合操作的函数,会将唯一的聚合值作为结果返回。聚合函数应用非常广泛,不论分组聚合、窗口聚合还是开窗(Over)聚合,对数据的聚合操作都可以用相同的函数来定义。

  • 标准SQL中常见的聚合函数Flink SQL都是支持的,目前也在不断扩展,为流处理应用提供更强大的功能。例如:

    • COUNT(*):返回所有行的数量,统计个数。
    • SUM([ ALL | DISTINCT ] expression):对某个字段进行求和操作。默认情况下省略了关键字ALL,表示对所有行求和;如果指定DISTINCT,则会对数据进行去重,每个值只叠加一次。
    • RANK():返回当前值在一组值中的排名。
    • ROW_NUMBER():对一组值排序后,返回当前值的行号。与RANK()的功能相似。

8.2 自定义函数(UDF)

  • Flink的Table API和SQL提供了多种自定义函数的接口,以抽象类的形式定义。当前UDF主要有以下几类:
    • 标量函数(Scalar Functions):将输入的标量值转换成一个新的标量值;
    • 表函数(Table Functions):将标量值转换成一个或多个新的行数据,也就是扩展成一个表;
    • 聚合函数(Aggregate Functions):将多行数据里的标量值转换成一个新的标量值;
    • 表聚合函数(Table Aggregate Functions):将多行数据里的标量值转换成一个或多个新的行数据。

8.2.1 整体调用流程

  • 要想在代码中使用自定义的函数,我们需要首先自定义对应UDF抽象类的实现,并在表环境中注册这个函数,然后就可以在Table API和SQL中调用了。

    • 注册函数。注册函数时需要调用表环境的createTemporarySystemFunction()方法,传入注册的函数名以及UDF类的Class对象:

      1
      2
      // 注册函数
      tableEnv.createTemporarySystemFunction("MyFunction", MyFunction.class);
      • 我们自定义的UDF类叫作MyFunction,它应该是上面四种UDF抽象类中某一个的具体实现;在环境中将它注册为名叫MyFunction的函数。
      • 这里createTemporarySystemFunction()方法的意思是创建了一个“临时系统函数”,所以MyFunction函数名是全局的,可以当作系统函数来使用;我们也可以用createTemporaryFunction()方法,注册的函数就依赖于当前的数据库(database)和目录(catalog)了,所以这就不是系统函数,而是“目录函数”(catalog function),它的完整名称应该包括所属的database和catalog。
    • 使用Table API调用函数。在Table API中,需要使用call()方法来调用自定义函数:

      1
      tableEnv.from("MyTable").select(call("MyFunction", $("myField")));
      • 这里call()方法有两个参数,一个是注册好的函数名MyFunction,另一个则是函数调用时本身的参数。这里我们定义MyFunction在调用时,需要传入的参数是myField字段。此外,在Table API中也可以不注册函数,直接用“内联”(inline)的方式调用UDF:

        1
        tableEnv.from("MyTable").select(call(SubstringFunction.class, $("myField")));
        • 区别只是在于call()方法第一个参数不再是注册好的函数名,而直接就是函数类的Class对象了。
    • 在SQL中调用函数。当我们将函数注册为系统函数之后,在SQL中的调用就与内置系统函数完全一样了:

      1
      tableEnv.sqlQuery("SELECT MyFunction(myField) FROM MyTable");

8.2.2 标量函数(Scalar Functions)

  • 自定义标量函数可以把0个、1个或多个标量值转换成一个标量值,它对应的输入是一行数据中的字段,输出则是唯一的值。所以从输入和输出表中行数据的对应关系看,标量函数是“一对一”的转换。

  • 想要实现自定义的标量函数,我们需要自定义一个类来继承抽象类ScalarFunction,并实现叫作eval()的求值方法。标量函数的行为就取决于求值方法的定义,它必须是公有的(public), 而且名字必须是eval。求值方法eval可以重载多次,任何数据类型都可作为求值方法的参数和返回值类型。

  • 这里需要特别说明的是,ScalarFunction抽象类中并没有定义eval()方法,所以我们不能直接在代码中重写(override);但Table API的框架底层又要求了求值方法必须名字为eval()。这是Table API和SQL目前还显得不够完善的地方,未来的版本应该会有所改进。

  • ScalarFunction以及其它所有的UDF接口,都在org.apache.flink.table.functions中。下面我们来看一个具体的例子。我们实现一个自定义的哈希(hash)函数HashFunction, 用来求传入对象的哈希值。

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    public static class HashFunction extends ScalarFunction {
    // 接受任意类型输入,返回 INT 型输出
    public int eval(@DataTypeHint(inputGroup = InputGroup.ANY) Object o) {
    return o.hashCode();
    }
    }
    // 注册函数
    tableEnv.createTemporarySystemFunction("HashFunction", HashFunction.class);
    // 在 SQL 里调用注册好的函数
    tableEnv.sqlQuery("SELECT HashFunction(myField) FROM MyTable");
    • 这里我们自定义了一个ScalarFunction,实现了eval()求值方法,将任意类型的对象传入,得到一个Int类型的哈希值返回。当然,具体的求哈希操作就省略了,直接调用对象的hashCode()方法即可。
    • 另外注意,由于Table API在对函数进行解析时需要提取求值方法参数的类型引用,所以我们用 DataTypeHint(inputGroup = InputGroup.ANY)对输入参数的类型做了标注,表示eval的参数可以是任意类型。

8.2.3 表函数(Table Functions)

  • 跟标量函数一样,表函数的输入参数也可以是0个、1个或多个标量值;不同的是,它可以返回任意多行数据。“多行数据”事实上就构成了一个表,所以“表函数”可以认为就是返回一个表的函数,这是一个“一对多”的转换关系。之前我们介绍过的窗口TVF,本质上就是表函数。

  • 类似地,要实现自定义的表函数,需要自定义类来继承抽象类TableFunction,内部必须要实现的也是一个名为eval的求值方法。与标量函数不同的是,TableFunction类本身是有一 个泛型参数T的,这就是表函数返回数据的类型;而eval()方法没有返回类型,内部也没有return语句,是通过调用collect()方法来发送想要输出的行数据的。多么熟悉的感觉——回忆一下DataStream API中的FlatMapFunction和ProcessFunction,它们的flatMap和 processElement方法也没有返回值,也是通过out.collect()来向下游发送数据的。

  • 我们使用表函数,可以对一行数据得到一个表,这和Hive中的UDTF非常相似。那对于原先输入的整张表来说,又该得到什么呢?一个简单的想法是,就让输入表中的每一行,与它转换得到的表进行联结(join),然后再拼成一个完整的大表,这就相当于对原来的表进行了扩展。在Hive的SQL语法中,提供了“侧向视图”(lateral view,也叫横向视图)的功能,可以将表中的一行数据拆分成多行;Flink SQL也有类似的功能,是用LATERAL TABLE语法来实现的。

  • 在SQL中调用表函数,需要使用LATERAL TABLE()来生成扩展的“侧向表”,然后与原始表进行联结(Join)。这里的 Join 操作可以是直接做交叉联结(cross join), 在FROM后用逗号分隔两个表就可以;也可以是以ON TRUE为条件的左联结(LEFT JOIN)。

  • 下面是表函数的一个具体示例。我们实现了一个分隔字符串的函数SplitFunction,可以将一个字符串转换成(字符串,长度)的二元组。

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    // 注意这里的类型标注,输出是 Row 类型,Row 中包含两个字段:word 和 length。
    @FunctionHint(output = @DataTypeHint("ROW<word STRING, length INT>"))
    public static class SplitFunction extends TableFunction<Row> {
    public void eval(String str) {
    for (String s : str.split(" ")) {
    // 使用 collect()方法发送一行数据
    collect(Row.of(s, s.length()));
    }
    }
    }
    // 注册函数
    tableEnv.createTemporarySystemFunction("SplitFunction", SplitFunction.class);

    // 在 SQL 里调用注册好的函数
    // 1. 交叉联结
    tableEnv.sqlQuery(
    "SELECT myField, word, length " +
    "FROM MyTable, LATERAL TABLE(SplitFunction(myField))");
    // 2. 带 ON TRUE 条件的左联结
    tableEnv.sqlQuery(
    "SELECT myField, word, length " +
    "FROM MyTable " +
    "LEFT JOIN LATERAL TABLE(SplitFunction(myField)) ON TRUE");
    // 重命名侧向表中的字段
    tableEnv.sqlQuery(
    "SELECT myField, newWord, newLength " +
    "FROM MyTable " +
    "LEFT JOIN LATERAL TABLE(SplitFunction(myField)) AS T(newWord, newLength) ON TRUE");
    • 这里我们直接将表函数的输出类型定义成了 ROW,这就是得到的侧向表中的数据类型;每行数据转换后也只有一行。我们分别用交叉联结和左联结两种方式在SQL中进行了调用, 还可以对侧向表的中字段进行重命名。

8.2.4 聚合函数(Aggregate Functions)

  • 用户自定义聚合函数(User Defined AGGregate function,UDAGG)会把一行或多行数据 (也就是一个表)聚合成一个标量值。这是一个标准的“多对一”的转换。

  • 聚合函数的概念我们之前已经接触过多次,如SUM()、MAX()、MIN()、AVG()、COUNT()都是常见的系统内置聚合函数。而如果有些需求无法直接调用系统函数解决,我们就必须自定义聚合函数来实现功能了。

  • 自定义聚合函数需要继承抽象类AggregateFunction。AggregateFunction有两个泛型参数 ,T表示聚合输出的结果类型,ACC则表示聚合的中间状态类型。

  • Flink SQL中的聚合函数的工作原理如下:

    • 首先,它需要创建一个累加器(accumulator),用来存储聚合的中间结果。这与DataStream API中的AggregateFunction非常类似,累加器就可以看作是一个聚合状态。调用createAccumulator()方法可以创建一个空的累加器。
    • 对于输入的每一行数据,都会调用accumulate()方法来更新累加器,这是聚合的核心过程。
    • 当所有的数据都处理完之后,通过调用getValue()方法来计算并返回最终的结果。所以,每个AggregateFunction都必须实现以下几个方法:
      • createAccumulator():这是创建累加器的方法。没有输入参数,返回类型为累加器类型ACC。
      • accumulate():这是进行聚合计算的核心方法,每来一行数据都会调用。它的第一个参数是确定的,就是当前的累加器,类型为ACC,表示当前聚合的中间状态;后面的参数则是聚合函数调用时传入的参数,可以有多个,类型也可以不同。这个方法主要是更新聚合状态,所以没有返回类型。 需要注意的是,accumulate()与之前的求值方法eval()类似,也是底层架构要求的,必须为public, 方法名必须为accumulate,且无法直接override、只能手动实现。
      • getValue():这是得到最终返回结果的方法。输入参数是ACC类型的累加器,输出类型为T。
  • 下面举一个具体的示例。在常用的系统内置聚合函数里,可以用AVG()来计算平均值;如 果我们现在希望计算的是某个字段的“加权平均值”,又该怎么做呢?系统函数里没有现成的 实现,所以只能自定义一个聚合函数WeightedAvg来计算了。比如我们要从学生的分数表ScoreTable中计算每个学生的加权平均分。为了计算加权平均值,应该从输入的每行数据中提取两个值作为参数:要计算的分数值score,以及它的权重weight。而在聚合过程中,累加器(accumulator)需要存储当前的加权总和sum,以及目前数据的个数count。这可以用一个二元组来表示,也可以单独定义一个类WeightedAvgAccum, 里面包含sum和count两个属性,用它的对象实例来作为聚合的累加器。

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    // 累加器类型定义
    public static class WeightedAvgAccumulator {
    public long sum = 0; // 加权和
    public int count = 0; // 数据个数
    }

    // 自定义聚合函数,输出为长整型的平均值,累加器类型为 WeightedAvgAccumulator
    public static class WeightedAvg extends AggregateFunction<Long,WeightedAvgAccumulator>{
    @Override
    public WeightedAvgAccumulator createAccumulator() {
    return new WeightedAvgAccumulator(); // 创建累加器
    }
    @Override
    public Long getValue(WeightedAvgAccumulator acc) {
    if (acc.count == 0) {
    return null; // 防止除数为 0
    } else {
    return acc.sum / acc.count; // 计算平均值并返回
    }
    }
    // 累加计算方法,每来一行数据都会调用
    public void accumulate(WeightedAvgAccumulator acc, Long iValue, Integer iWeight){
    acc.sum += iValue * iWeight;
    acc.count += iWeight;
    }
    }
    // 注册自定义聚合函数
    tableEnv.createTemporarySystemFunction("WeightedAvg", WeightedAvg.class);
    // 调用函数计算加权平均值
    Table result = tableEnv.sqlQuery("SELECT student, WeightedAvg(score, weight) FROM ScoreTable GROUP BY student");

8.2.5 表聚合函数(Table Aggregate Functions)

  • 用户自定义表聚合函数(UDTAGG)可以把一行或多行数据(也就是一个表)聚合成另 一张表,结果表中可以有多行多列。很明显,这就像表函数和聚合函数的结合体,是一个“多对多”的转换。

  • 自定义表聚合函数需要继承抽象类TableAggregateFunction。TableAggregateFunction的结构和原理与 AggregateFunction非常类似,同样有两个泛型参数,用一个ACC类型的累加器(accumulator)来存储聚合的中间结果。聚合函数中必须实现的三个方法,在TableAggregateFunction中也必须对应实现:

    • createAccumulator():创建累加器的方法,与AggregateFunction中用法相同。
    • accumulate():聚合计算的核心方法,与AggregateFunction中用法相同。
    • emitValue():所有输入行处理完成后,输出最终计算结果的方法。这个方法对应着AggregateFunction 中的getValue()方法;区别在于emitValue没有输出类型,而输入参数有两个:第一个是ACC类型的累加器,第二个则是用于输出数据的“收集器”out,它的类型为Collect。所以很明显,表聚合函数输出数据不是直接return,而是调用out.collect()方法,调用多次就可以输出多行数据了;这一点与表函数非常相似。另外,emitValue()在抽象类中也没有定义,无法override,必须手动实现。
  • 表聚合函数得到的是一张表;在流处理中做持续查询,应该每次都会把这个表重新计算输出。如果输入一条数据后,只是对结果表里一行或几行进行了更新(Update),这时我们重新计算整个表、全部输出显然就不够高效了。为了提高处理效率,TableAggregateFunction还提供了一个emitUpdateWithRetract()方法,它可以在结果表发生变化时,以“撤回”(retract)老数据、发送新数据的方式增量地进行更新。如果同时定义了 emitValue()和 emitUpdateWithRetract()两个方法,在进行更新操作时会优先调用 emitUpdateWithRetract()。

  • 表聚合函数相对比较复杂,它的一个典型应用场景就是Top N查询。比如我们希望选出一组数据排序后的前两名,这就是最简单的TOP-2查询。没有现成的系统函数,那么我们就可以自定义一个表聚合函数来实现这个功能。在累加器中应该能够保存当前最大的两个值,每当来一条新数据就在accumulate()方法中进行比较更新,最终在emitValue()中调用两次out.collect()将前两名数据输出。

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    // 聚合累加器的类型定义,包含最大的第一和第二两个数据
    public static class Top2Accumulator {
    public Integer first;
    public Integer second;
    }
    // 自定义表聚合函数,查询一组数中最大的两个,返回值为(数值,排名)的二元组
    public static class Top2 extends TableAggregateFunction<Tuple2<Integer, Integer>,
    Top2Accumulator> {
    @Override
    public Top2Accumulator createAccumulator() {
    Top2Accumulator acc = new Top2Accumulator();
    acc.first = Integer.MIN_VALUE; // 为方便比较,初始值给最小值
    acc.second = Integer.MIN_VALUE;
    return acc;
    }

    // 每来一个数据调用一次,判断是否更新累加器
    public void accumulate(Top2Accumulator acc, Integer value) {
    if (value > acc.first) {
    acc.second = acc.first;
    acc.first = value;
    } else if (value > acc.second) {
    acc.second = value;
    }
    }
    // 输出(数值,排名)的二元组,输出两行数据
    public void emitValue(Top2Accumulator acc, Collector<Tuple2<Integer, Integer>> out) {
    if (acc.first != Integer.MIN_VALUE) {
    out.collect(Tuple2.of(acc.first, 1));
    }
    if (acc.second != Integer.MIN_VALUE) {
    out.collect(Tuple2.of(acc.second, 2));
    }
    }
    }
  • 目前SQL中没有直接使用表聚合函数的方式,所以需要使用Table API的方式来调用:

    1
    2
    3
    4
    5
    6
    7
    // 注册表聚合函数函数
    tableEnv.createTemporarySystemFunction("Top2", Top2.class);
    // 在 Table API 中调用函数
    tableEnv.from("MyTable")
    .groupBy($("myField"))
    .flatAggregate(call("Top2", $("value")).as("value", "rank"))
    .select($("myField"), $("value"), $("rank"));
    • 这里使用了flatAggregate()方法,它就是专门用来调用表聚合函数的接口。对MyTable中数据按myField 字段进行分组聚合,统计value值最大的两个;并将聚合结果的两个字段重命名为value和rank,之后就可以使用select()将它们提取出来了。

9、连接到外部系统

  • 在Table API和SQL编写的Flink程序中,可以在创建表的时候用WITH子句指定连接器(connector),这样就可以连接到外部系统进行数据交互了。

  • 架构中的TableSource负责从外部系统中读取数据并转换成表,TableSink则负责将结果表写入外部系统。在 Flink 1.13的API调用中,已经不去区分TableSource和TableSink,我们只要建立到外部系统的连接并创建表就可以,Flink自动会从程序的处理逻辑中解析出它们的用途。

  • Flink的Table API和SQL支持了各种不同的连接器。当然,最简单的其实就是上一节中提到的连接到控制台打印输出:

    1
    2
    3
    4
    5
    6
    CREATE TABLE ResultTable (
    user STRING,
    cnt BIGINT
    WITH (
    'connector' = 'print'
    );

9.1 Kafka

  • Kafka的SQL连接器可以从Kafka的主题(topic)读取数据转换成表,也可以将表数据写入Kafka的主题。换句话说,创建表的时候指定连接器为Kafka,则这个表既可以作为输入表,也可以作为输出表。

    • 引入依赖。想要在Flink程序中使用Kafka连接器,需要引入如下依赖:

      1
      2
      3
      4
      5
      <dependency>
      <groupId>org.apache.flink</groupId>
      <artifactId>flink-connector-kafka_${scala.binary.version}</artifactId>
      <version>${flink.version}</version>
      </dependency>
      • 这里我们引入的Flink和Kafka的连接器,与之前DataStream API中引入的连接器是一样的。如果想在SQL客户端里使用Kafka连接器,还需要下载对应的jar包放到lib目录下。

      • 另外,Flink为各种连接器提供了一系列的“表格式”(table formats),比如CSV、JSON、 Avro、Parquet等等。这些表格式定义了底层存储的二进制数据和表的列之间的转换方式,相当于表的序列化工具。对于Kafka而言,CSV、JSON、Avro等主要格式都是支持的,根据Kafka连接器中配置的格式,我们可能需要引入对应的依赖支持。以CSV为例:

        1
        2
        3
        4
        5
        <dependency>
        <groupId>org.apache.flink</groupId>
        <artifactId>flink-csv</artifactId>
        <version>${flink.version}</version>
        </dependency>
      • 由于SQL客户端中已经内置了CSV、JSON的支持,因此使用时无需专门引入;而对于没有内置支持的格式(比如 Avro),则仍然要下载相应的jar包。

    • 创建连接到Kafka的表。创建一个连接到Kafka表,需要在CREATE TABLE的DDL中在WITH子句里指定连接器为Kafka,并定义必要的配置参数。

      1
      2
      3
      4
      5
      6
      7
      8
      9
      10
      11
      12
      CREATE TABLE KafkaTable (
      `user` STRING,
      `url` STRING,
      `ts` TIMESTAMP(3) METADATA FROM 'timestamp'
      ) WITH (
      'connector' = 'kafka',
      'topic' = 'events',
      'properties.bootstrap.servers' = 'localhost:9092',
      'properties.group.id' = 'testGroup',
      'scan.startup.mode' = 'earliest-offset',
      'format' = 'csv'
      )
      • 这里定义了Kafka连接器对应的主题(topic),Kafka服务器,消费者组ID,消费者起始模式以及表格式。需要特别说明的是,在KafkaTable的字段中有一个ts,它的声明中用到了METADATA FROM,这是表示一个“元数据列”(metadata column),它是由Kafka连接器的元数据“timestamp”生成的。这里的timestamp其实就是Kafka中数据自带的时间戳,我们把 \它直接作为元数据提取出来,转换成一个新的字段ts。
    • Upsert Kafka。

      • 正常情况下,Kafka作为保持数据顺序的消息队列,读取和写入都应该是流式的数据,对 应在表中就是仅追加(append-only)模式。如果我们想要将有更新操作(比如分组聚合)的结果表写入 Kafka,就会因为Kafka无法识别撤回(retract)或更新插入(upsert)消息而导致异常。
      • 为了解决这个问题,Flink专门增加了一个“更新插入Kafka”(Upsert Kafka)连接器。这个连接器支持以更新插入(UPSERT)的方式向Kafka的topic中读写数据。
      • 具体来说,Upsert Kafka连接器处理的是更新日志(changlog)流。如果作为TableSource, 连接器会将读取到的topic中的数据(key, value),解释为对当前key的数据值的更新(UPDATE), 也就是查找动态表中key对应的一行数据,将value更新为最新的值;因为是Upsert操作,所以如果没有key对应的行,那么也会执行插入(INSERT)操作。另外,如果遇到value为空 (null),连接器就把这条数据理解为对相应key那一行的删除(DELETE)操作。
      • 如果作为TableSink,Upsert Kafka连接器会将有更新操作的结果表,转换成更新日志 (changelog)流。如果遇到插入(INSERT)或者更新后(UPDATE_AFTER)的数据,对应的是一个添加(add)消息,那么就直接正常写入Kafka主题;如果是删除(DELETE)或者更新前的数据,对应是一个撤回(retract)消息,那么就把value为空(null)的数据写入Kafka。 由于Flink是根据键(key)的值对数据进行分区的,这样就可以保证同一个key上的更新和删除消息都会落到同一个分区中。
  • 下面是一个创建和使用Upsert Kafka表的例子:

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    CREATE TABLE pageviews_per_region (
    user_region STRING,
    pv BIGINT,
    uv BIGINT,
    PRIMARY KEY (user_region) NOT ENFORCED
    ) WITH (
    'connector' = 'upsert-kafka',
    'topic' = 'pageviews_per_region',
    'properties.bootstrap.servers' = '...',
    'key.format' = 'avro',
    'value.format' = 'avro'
    );

    CREATE TABLE pageviews (
    user_id BIGINT,
    page_id BIGINT,
    viewtime TIMESTAMP,
    user_region STRING,
    WATERMARK FOR viewtime AS viewtime - INTERVAL '2' SECOND
    ) WITH (
    'connector' = 'kafka',
    'topic' = 'pageviews',
    'properties.bootstrap.servers' = '...',
    'format' = 'json'
    );

    -- 计算 pv、uv 并插入到 upsert-kafka 表中
    INSERT INTO pageviews_per_region
    SELECT
    user_region,
    COUNT(*),
    COUNT(DISTINCT user_id)
    FROM pageviews
    GROUP BY user_region;
    • 这里我们从Kafka表pageviews中读取数据,统计每个区域的PV(全部浏览量)和UV(对用户去重),这是一个分组聚合的更新查询,得到的结果表会不停地更新数据。为了将结果表写入Kafka的pageviews_per_region主题,我们定义了一个Upsert Kafka表,它的字段中需要用PRIMARY KEY来指定主键,并且在WITH子句中分别指定key和value的序列化格式。

9.2 文件系统

  • 另一类非常常见的外部系统就是文件系统(File System)了。Flink提供了文件系统的连接器,支持从本地或者分布式的文件系统中读写数据。这个连接器是内置在Flink中的,所以使用它并不需要额外引入依赖。

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    CREATE TABLE MyTable (
    column_name1 INT,
    column_name2 STRING,
    ...
    part_name1 INT,
    part_name2 STRING
    ) PARTITIONED BY (part_name1, part_name2) WITH (
    'connector' = 'filesystem', -- 连接器类型
    'path' = '...', -- 文件路径
    'format' = '...' -- 文件格式
    )
    • 这里在WITH前使用了PARTITIONED BY对数据进行了分区操作。文件系统连接器支持对分区文件的访问。

9.3 JDBC

  • 关系型数据表本身就是SQL最初应用的地方,所以我们也会希望能直接向关系型数据库中读写表数据。Flink 提供的JDBC连接器可以通过JDBC驱动程序(driver)向任意的关系型数据库读写数据,比如MySQL、PostgreSQL、Derby等。

  • 作为TableSink向数据库写入数据时,运行的模式取决于创建表的DDL是否定义了主键(primary key)。如果有主键,那么JDBC连接器就将以更新插入(Upsert)模式运行,可以向外部数据库发送按照指定键(key)的更新(UPDATE)和删除(DELETE)操作;如果没有定义主键,那么就将在追加(Append)模式下运行,不支持更新和删除操作。

    • 引入依赖。

      1
      2
      3
      4
      5
      <dependency>
      <groupId>org.apache.flink</groupId>
      <artifactId>flink-connector-jdbc_${scala.binary.version}</artifactId>
      <version>${flink.version}</version>
      </dependency>
      • 此外,为了连接到特定的数据库,我们还用引入相关的驱动器依赖,比如MySQL:

        1
        2
        3
        4
        5
        <dependency>
        <groupId>mysql</groupId>
        <artifactId>mysql-connector-java</artifactId>
        <version>5.1.38</version>
        </dependency>
    • 创建JDBC表。

      1
      2
      3
      4
      5
      6
      7
      8
      9
      10
      11
      12
      13
      14
      15
      -- 创建一张连接到 MySQL 的 表
      CREATE TABLE MyTable (
      id BIGINT,
      name STRING,
      age INT,
      status BOOLEAN,
      PRIMARY KEY (id) NOT ENFORCED
      ) WITH (
      'connector' = 'jdbc',
      'url' = 'jdbc:mysql://localhost:3306/mydatabase',
      'table-name' = 'users'
      );
      -- 将另一张表 T 的数据写入到 MyTable 表中
      INSERT INTO MyTable
      SELECT id, name, age, status FROM T;
      • 这里创建表的DDL中定义了主键,所以数据会以Upsert模式写入到MySQL表中;而到MySQL的连接,是通过WITH子句中的url定义的。要注意写入MySQL中真正的表名称是users,而MyTable是注册在Flink表环境中的表。