多流转换可分为“分流”和“合流”两大类。
目前分流操作一般是通过侧输出流（side output）来实现，而合流的算子比较丰富，根据不同的需求可调用 union()、connect()、join() 等接口进行连接合并操作。
8.1 分流
所谓“分流”，就是将一条数据流拆分成完全独立的两条、甚至多条流。也就是基于一个 DataStream，得到完全平等的多个子 DataStream，如图 8-1 。一般来说，我们会定义一些筛选条件，将符合条件的数据拣选出来放到对应的流里。
8.1.1 简单实现
其实根据条件筛选数据的需求，本身容易实现：只要针对同一条流多次独立调用 filter()方法进行筛选，就可得到拆分后的流。 例如，我们可以将电商网站收集到的用户行为数据进行一个拆分，根据类型（type）的不同，分为“Mary”的浏览数据、“Bob”的浏览数据等等。那么代码可这样实现：
import com.atguigu.chapter05.ClickSource
import org.apache.flink.streaming.api.scala._
object SplitStreamByFilterExample {
def main(args: Array[String]): Unit = {
val env = StreamExecutionEnvironment.getExecutionEnvironment
env.setParallelism(1)
val stream = env.addSource(new ClickSource)
val maryStream = stream.filter(_.user == "Mary")
val bobStream = stream.filter(_.user == "Bob")
val elseStream = stream.filter(r => !(r.user == "Mary") && !(r.user == "Bob"))
maryStream.print("Mary pv")
bobStream.print("Bob pv")
elseStream.print("else pv")
env.execute()
}
}输出结果：
Bob pv> Event{user='Bob', url='./home', timestamp=2021-06-23 17:30:57.388}
else pv> Event{user='Alice', url='./home', timestamp=2021-06-23 17:30:58.399}
else pv> Event{user='Alice', url='./home', timestamp=2021-06-23 17:30:59.409}
Bob pv> Event{user='Bob', url='./home', timestamp=2021-06-23 17:31:00.424}
else pv> Event{user='Alice', url='./prod?id=1', timestamp=2021-06-23
17:31:01.441}
else pv> Event{user='Alice', url='./prod?id=1', timestamp=2021-06-23
17:31:02.449}
Mary pv> Event{user='Mary', url='./home', timestamp=2021-06-23 17:31:03.465}8.1.2 使用侧输出流
Flink 1.13 版本中，已弃用 split()方法，取而代之的是直接用处理函数（process function）的侧输出流（side output）。 简单来说，只需要调用上下文 ctx 的 output()方法，就可输出任意类型的数据。而侧输出流的标记和提取，都离不开一个“输出标签”（OutputTag），它就相当于 split()分流时的“戳”， 指定了侧输出流的 id 和类型。 我们可以使用侧输出流将上一小节的分流代码改写如下：
import org.apache.flink.streaming.api.functions._
import org.apache.flink.streaming.api.scala._
import org.apache.flink.util.Collector
object SplitStreamBySideOutputExample {
// 实例化侧输出标签
val maryTag = OutputTag[(String, String, Long)]("Mary-pv")
val bobTag = OutputTag[(String, String, Long)]("Bob-pv")
def main(args: Array[String]): Unit = {
val env = StreamExecutionEnvironment.getExecutionEnvironment
env.setParallelism(1)
val stream = env.addSource(new ClickSource)
val processedStream = stream
.process(new ProcessFunction[Event, Event] {
override def processElement(value: Event, ctx: ProcessFunction[Event,
Event]#Context, out: Collector[Event]): Unit = {
// 将不同的数据发送到不同的侧输出流
if (value.user == "Mary") {
ctx.output(maryTag, (value.user, value.url, value.timestamp))
} else if (value.user == "Bob") {
ctx.output(bobTag, (value.user, value.url, value.timestamp))
} else {
out.collect(value)
}
}
})
// 打印各输出流中的数据
processedStream.getSideOutput(maryTag).print("Mary pv")
processedStream.getSideOutput(bobTag).print("Bob pv")
processedStream.print("else pv")
env.execute()
}
}8.2 基本合流操作
一条流可分开，自然多条流就可合并。在实际应用中，经常会遇到来源不同的多条流，需将它们的数据进行联合处理。所以 Flink 中合流的操作会更普遍，对应的 API 也更丰富。
8.2.1 联合（Union）
最简单的合流操作，直接将多条流合在一起，叫作流的“联合”（union），如图 8-2 。
联合操作要求必须流中的数据类型必须相同，合并后的新流会包括所有流中元素， 数据类型不变。这种合流简单粗暴，就像公路上多个车道汇在一起。
在代码中，只要基于 DataStream 直接调用 union()方法，传入其他 DataStream 作参数，就可实现流的联合；得到的依然是一个 DataStream：
stream1.union(stream2, stream3, ...)注意：union()的参数可是多个 DataStream，所以联合操作可实现多条流合并。
8.2.2 连接（Connect）
流的联合虽然简单，不过受限于数据类型不能改变，灵活性大打折扣，所以实际应用较少出现。
除了联合（union），Flink 提供了另外一种方便的合流操作——连接（connect）。顾名思义，这种操作就是直接把两条流像接线一样对接起来。
1. 连接流（ConnectedStreams）
为处理更加灵活，连接操作允许流的数据类型不同。但我们知道一个 DataStream 中的数据只能有唯一的类型，所以连接得到的并不是 DataStream，而是一个“连接流” （ConnectedStreams）。连接流可看成是两条流形式上的“统一”，被放在一个同一个流中； 事实上内部仍保持各自的数据形式，彼此间相互独立。
要想得到新的 DataStream， 还需进一步定义一个“同处理”（co-process）转换操作，用来说明对不同来源、不同类型的数据，怎样分别进行处理转换、得到统一的输出类型。
所以整体上来，两条流的连接就像是 “一国两制”，两条流可保持各自的数据类型、处理方式也可不同，不过最终还是会统一到同一个 DataStream 中，如图 8-3 。
在代码实现上，需分为两步：首先基于一条 DataStream 调用 connect()方法，传入另外一条 DataStream 作为参数，将两条流连接起来，得到一个 ConnectedStreams；
然后再调用同处理方法得到 DataStream。这里可以调用同处理的方法有 map()/flatMap()，以及 process()方法。
import org.apache.flink.streaming.api.functions.co.CoMapFunction
import org.apache.flink.streaming.api.scala._
object CoMapExample {
def main(args: Array[String]): Unit = {
val env = StreamExecutionEnvironment.getExecutionEnvironment
env.setParallelism(1)
val stream1 = env.fromElements(1,2,3)
val stream2 = env.fromElements(1L,2L,3L)
val connectedStreams = stream1.connect(stream2)
val result = connectedStreams
.map(new CoMapFunction[Int, Long, String] {
// 处理来自第一条流的事件
override def map1(in1: Int): String = "Int: " + in1
// 处理来自第二条流的事件
override def map2(in2: Long): String = "Long: " + in2
})
result.print()
env.execute()
}
}输出结果：
Integer: 1
Integer: 2
Integer: 3
Long: 1
Long: 2
Long: 3上面的代码中，ConnectedStreams 有两个类型参数，分别表示内部包含的两条流各自的数据类型；由于需要“一国两制”，因此调用 map()方法时传入的不是一个简单的 MapFunction， 而是一个 CoMapFunction，表示分别对两条流中的数据执行 map 操作。
这个接口有三个类型参数，依次表示第一条流、第二条流，以及合并后流中的数据类型。需要实现的方法也非常直白：map1()方法是对第一条流中数据的 map 操作，map2()方法是针对第二条流。
两条流的连接（connect），与联合（union）操作相比，最大优势就是可处理不同类型的流的合并，使用灵活、应用广泛。当然它也有限制，就是合并流的数量只能是 2，而 union() 可同时进行多条流合并。这也非常容易理解：union()限制类型不变，所以直接合并 ；而 connect()是“一国两制”，后续处理的接口只定义了两个转换方法，如果扩展需要重新定义接口，所以不能“一国多制”。
2. CoProcessFunction
对连接流 ConnectedStreams 的处理操作，需分别定义对两条流的处理转换，因此接口中就会有两个相同的方法需要实现，用数字“1”“2”区分，在两条流中的数据到来时分别调用。
我们把这种接口叫作“协同处理函数”（co-process function）。与 CoMapFunction 类似，如果是调用 flatMap() 就需要传入一个 CoFlatMapFunction，需要实现 flatMap1()、flatMap2()两个 方法；而调用 process()时，传入的则是一个 CoProcessFunction。 抽象类 CoProcessFunction 在源码中定义如下：
public abstract class CoProcessFunction<IN1, IN2, OUT> extends
AbstractRichFunction {
...
public abstract void processElement1(IN1 value, Context ctx, Collector<OUT>
out) throws Exception;
public abstract void processElement2(IN2 value, Context ctx, Collector<OUT>
out) throws Exception;
public void onTimer(long timestamp, OnTimerContext ctx, Collector<OUT> out)
138
throws Exception {}
public abstract class Context {...}
...
}可以看到，CoProcessFunction 也是“处理函数”家族中的一员，用法相似。它需要实现的就是 processElement1()、processElement2()两个方法，在每个数据到来时， 会根据来源的流调用其中的一个方法进行处理。CoProcessFunction 同样可通过上下文 ctx 来 访问 timestamp、水位线，并通过 TimerService 注册定时器；另外也提供了 onTimer()方法，用于定义定时触发的处理操作。
下面是 CoProcessFunction 的具体示例：我们可以实现一个实时对账的需求，也就是 app 的支付操作和第三方的支付操作的一个双流 join。App 的支付事件和第三方的支付事件将会互相等待 5 秒钟，如果等不来对应的支付事件，那么就输出报警信息。程序如下：
import org.apache.flink.api.common.state.ValueStateDescriptor
import org.apache.flink.streaming.api.functions.co._
import org.apache.flink.streaming.api.scala._
import org.apache.flink.util.Collector
object BillCheckExample {
def main(args: Array[String]): Unit = {
val env = StreamExecutionEnvironment.getExecutionEnvironment
env.setParallelism(1)
// 来自 app 的支付日志
val appStream = env
.fromElements(
("order-1", "app", 1000L),
("order-2", "app", 2000L)
)
.assignAscendingTimestamps(_._3)
// 来自第三方支付平台的支付日志
val thirdPartyStream = env
.fromElements(
("order-1", "third-party", "success", 3000L),
("order-3", "third-party", "success", 4000L)
)
.assignAscendingTimestamps(_._4)
// 检测同一支付单在两条流中是否匹配，不匹配就报警
appStream.connect(thirdPartyStream)
.keyBy(_._1, _._1)
.process(new OrderMatchResult)
139
.print()
env.execute()
}
// 自定义实现 CoProcessFunction
class OrderMatchResult extends CoProcessFunction[(String, String, Long),
(String, String, String, Long), String] {
// 定义状态变量，用来保存已经到达的事件；使用 lazy 定义是一种简洁的写法
lazy val appEvent = getRuntimeContext.getState(
new ValueStateDescriptor[(String, String, Long)]("app", classOf[(String,
String, Long)])
)
lazy val thirdPartyEvent = getRuntimeContext.getState(
new ValueStateDescriptor[(String, String, String, Long)]("third-party",
classOf[(String, String, String, Long)])
)
override def processElement1(value: (String, String, Long), ctx:
CoProcessFunction[(String, String, Long), (String, String, String, Long),
String]#Context, out: Collector[String]): Unit = {
if (thirdPartyEvent.value() != null) {
// 如果对应的第三方支付事件的状态变量不为空，则说明第三方支付事件先到达，对账成功
out.collect(value._1 + " 对账成功")
// 清空保存第三方支付事件的状态变量
thirdPartyEvent.clear()
} else {
// 如果是 app 支付事件先到达，就把它保存在状态中
appEvent.update(value)
// 注册 5 秒之后的定时器，也就是等待第三方支付事件 5 秒钟
ctx.timerService.registerEventTimeTimer(value._3 + 5000L)
}
}
// 和上面的逻辑是对称的关系
override def processElement2(value: (String, String, String, Long), ctx:
CoProcessFunction[(String, String, Long), (String, String, String, Long),
String]#Context, out: Collector[String]): Unit = {
if (appEvent.value() != null) {
out.collect(value._1 + " 对账成功")
appEvent.clear()
} else {
thirdPartyEvent.update(value)
ctx.timerService.registerEventTimeTimer(value._4 + 5000L)
}
}
override def onTimer(timestamp: Long, ctx: CoProcessFunction[(String, String,
140
Long), (String, String, String, Long), String]#OnTimerContext, out:
Collector[String]): Unit = {
// 如果 app 事件的状态变量不为空，说明等待了 5 秒钟，第三方支付事件没有到达
if (appEvent.value() != null) {
out.collect(appEvent.value()._1 + " 对账失败，订单的第三方支付信息未到")
appEvent.clear()
}
// 如果第三方支付事件没有到达，说明等待了 5 秒钟，app 事件没有到达
if (thirdPartyEvent.value() != null) {
out.collect(thirdPartyEvent.value()._1 + " 对账失败，订单的 app 支付信息未到")
thirdPartyEvent.clear()
}
}
}}输出结果是：
order-1 对账成功
order-2 对账失败，订单的第三方支付信息未到
order-3 对账失败，订单的 app 支付信息未到在程序中，我们声明了两个状态变量分别来保存 App 的支付信息和第三方的支付信息。 App 的支付信息到达后，会检查对应的第三方支付信息是否已经先到达（先到达会保存在对应状态变量中），如果第三方支付消息到达了，那么对账成功，直接输出对账成功的信息，并将保存第三方支付消息的状态变量清空。如果 App 对应的第三方支付信息没有到来，那么会注册 一个 5 秒钟后的定时器，也就是说等待第三方支付事件 5 秒钟。当定时器触发时，检查保存 App 支付信息的状态变量是否还在，如果还在，说明对应的第三方支付信息没有到来，输出报警信息。
3. 广播连接流（BroadcastConnectedStream）
关于两条流的连接，还有一种比较特殊的用法：DataStream 调用.connect()方法时，传入的参数也可以不是一个 DataStream，而是一个“广播流”（BroadcastStream），这时合并两条流得到的就变成了一个“广播连接流”（BroadcastConnectedStream）。
这种连接方式往往用在需要动态定义某些规则或配置的场景。因为规则是实时变动的，所以我们可以用一个单独的流来获取规则数据；而这些规则或配置是对整个应用全局有效的，所以不能只把这数据传递给一个下游并行子任务处理，而是要“广播”（broadcast）给所有的并行子任务。而下游子任务收到广播出来的规则，会把它保存成一个状态，这就是所谓的“广播状态”（broadcast state）。
广播状态底层是用一个“映射”（map）结构来保存的。在代码实现上，可以直接调用 DataStream 的 broadcast()方法，传入一个“映射状态描述器”（MapStateDescriptor）说明状态 的名称和类型，就可以得到规则数据的“广播流”（BroadcastStream）：
val ruleStateDescriptor = new MapStateDescriptor[](...);
val ruleBroadcastStream = ruleStream
.broadcast(ruleStateDescriptor)接下来我们就可以将要处理的数据流，与这条广播流进行连接（connect），得到的就是所谓的“广播连接流”（BroadcastConnectedStream）。基于 BroadcastConnectedStream 调用 process() 方法，就可以同时获取规则和数据，进行动态处理了。
这里既然调用了 process()方法，当然传入的参数也应是处理函数大家族中一员——如果对数据流调用过 keyBy()进行了按键分区，那么要传入的就是 KeyedBroadcastProcessFunction； 如果没有按键分区，就传入 BroadcastProcessFunction。
val output = stream
.connect(ruleBroadcastStream)
.process( new BroadcastProcessFunction[]() {...} )BroadcastProcessFunction 与 CoProcessFunction 类似，同样是一个抽象类，需实现两个方法，针对合并的两条流中元素分别定义处理操作。区别在于这里一条流是正常处理数据，而另一条流则是要用新规则来更新广播状态，所以对应的两个方法叫作 processElement()和 processBroadcastElement()。源码中定义如下：
public abstract class BroadcastProcessFunction<IN1, IN2, OUT> extends
BaseBroadcastProcessFunction {
...
public abstract void processElement(IN1 value, ReadOnlyContext ctx,
Collector<OUT> out) throws Exception;
public abstract void processBroadcastElement(IN2 value, Context ctx,
Collector<OUT> out) throws Exception;
...
}8.3 基于时间的合流——双流联结（Join）
对于两条流的合并，很多情况并不是简单地将所有数据放在一起，而是希望根据某个字段的值将它们联结起来，“配对”去做处理。
这种需求与关系型数据库中表的 join 操作相近。事实上，Flink 中两条流的 connect()操作，就可以通过 keyBy()指定键进行分组后合并， 实现了类似于 SQL 中的 join 操作；另外 connect()支持处理函数，可以使用自定义状态和 TimerService 灵活实现各种需求，已经能够处理双流合并的大多数场景。
不过处理函数是底层接口，所以尽管 connect()能做的事情多，但在一些具体应用场景下还是显得太过抽象。比如，如果我们希望统计固定时间内两条流数据的匹配情况，那就需要设置定时器、自定义触发逻辑来实现——其实这完全可以用窗口（window）来表示。
为更方便地实现基于时间的合流操作，Flink 的 DataStrema API 提供了两种内置的 join()算子。 注：SQL 中 join 一般会翻译为“连接”；我们这里为了区分不同的算子，一般的合流操作 connect()翻译为“连接”，而把 join()翻译为“联结”。
8.3.1 窗口联结（Window Join）
基于时间的操作，最基本的就是时间窗口。我们之前已经介绍过 Window API 的用 法，主要是针对单一数据流在某些时间段内的处理计算。
那如果希望将两条流的数据进行合并、且同样针对某段时间进行处理和统计，又该怎么做呢？ Flink 为这种场景专门提供了一个窗口联结（window join）算子，可以定义时间窗口，并将两条流中共享一个公共键（key）的数据放在窗口中进行配对处理。
1. 窗口联结的调用
窗口联结在代码中的实现，首先需要调用 DataStream 的 join()方法来合并两条流，得到一 个 JoinedStreams；接着通过 where()和 equalTo()方法指定两条流中联结的 key；然后通过 window()开窗口，并调用 apply()传入联结窗口函数进行处理计算。通用调用形式如下：
stream1.join(stream2)
.where(<KeySelector>)
.equalTo(<KeySelector>)
.window(<WindowAssigner>)
.apply(<JoinFunction>)上面代码中.where()的参数是键选择器（KeySelector），用来指定第一条流中的 key；而 equalTo()传入的 KeySelector 则指定了第二条流中的 key。两者相同的元素，如果在同一窗口 中，就可以匹配起来，并通过一个“联结函数”（JoinFunction）进行处理。
这里 window()传入的就是窗口分配器，之前讲到的三种时间窗口都可以用在这里：滚动窗口（tumbling window）、滑动窗口（sliding window）和会话窗口（session window）。 而后面调用 apply()可以看作实现了一个特殊的窗口函数。注意这里只能调用 apply()，没有其他替代的方法。
传入的 JoinFunction 也是一个函数类接口，使用时需要实现内部的 join()方法。这个方法有两个参数，分别表示两条流中成对匹配的数据。JoinFunction 在源码中的定义如下：
public interface JoinFunction<IN1, IN2, OUT> extends Function, Serializable {
OUT join(IN1 first, IN2 second) throws Exception;
}这里需要注意，JoinFunciton 并不是真正的“窗口函数”，它只是定义了窗口函数在调用时对匹配数据的具体处理逻辑。 当然，既然是窗口计算，在 window()和 apply()之间也可以调用可选 API 去做一些自定义， 比如用 trigger()定义触发器，用 allowedLateness()定义允许延迟时间，等等。
2. 窗口联结的处理流程
JoinFunction 中的两个参数，分别代表了两条流中的匹配的数据。 窗口中每有一对数据成功联结匹配，JoinFunction 的 join()方法就会被调用一次，并输出一 个结果。
除了 JoinFunction，在 apply()方法中还可以传入 FlatJoinFunction，用法非常类似，只是内部需要实现的 join()方法没有返回值。结果的输出是通过收集器（Collector）来实现的，所以对于一对匹配数据可以输出任意条结果。
其实仔细观察可以发现，窗口 join 的调用语法和我们熟悉的 SQL 中表的 join 非常相似：
SELECT * FROM table1 t1, table2 t2 WHERE t1.id = t2.id;这句 SQL 中 where 子句的表达，等价于 inner join ... on,所以本身表示的是两张表基于 id 的“内连接”（inner join）。而 Flink 中的 window join，同样类似于 inner join。也就是说，最后处理输出的，只有两条流中数据按 key 配对成功的那些；如果某个窗口中一条流的数据没有任何另一条流的数据匹配，那么就不会调用 JoinFunction 的 join()方法，也就没有任何输出。
3. 窗口联结实例
在电商网站中，往往需要统计用户不同行为之间的转化，这就需要对不同的行为数据流，按照用户 ID 进行分组后再合并，以分析它们之间的关联。如果这些是以固定时间周期（比如 1 小时）来统计的，那我们就可以使用窗口 join 来实现这样的需求。
下面是一段示例代码：
import org.apache.flink.api.common.eventtime.{SerializableTimestampAssigner,
WatermarkStrategy}
import org.apache.flink.api.common.functions.JoinFunction
import org.apache.flink.streaming.api.scala._
import
org.apache.flink.streaming.api.windowing.assigners.TumblingEventTimeWindows
import org.apache.flink.streaming.api.windowing.time.Time
object WindowJoinExample {
def main(args: Array[String]): Unit = {
val env = StreamExecutionEnvironment.getExecutionEnvironment
env.setParallelism(1)
val stream1 = env.fromElements(
("a", 1000L),
("b", 1000L),
("a", 2000L),
("b", 2000L)
).assignAscendingTimestamps(_._2)
val stream2 = env.fromElements(
("a", 3000L),
("b", 3000L),
("a", 4000L),
144
("b", 4000L)
).assignAscendingTimestamps(_._2)
stream1
.join(stream2)
.where(_._1) // 指定第一条流中元素的 key
.equalTo(_._1) // 指定第二条流中元素的 key
// 开窗口
.window(TumblingEventTimeWindows.of(Time.seconds(5)))
.apply(new JoinFunction[(String, Long), (String, Long), String] {
// 处理来自两条流的相同 key 的事件
override def join(first: (String, Long), second: (String, Long)) = {
first + "=>" + second
}
}).print()
env.execute()
}}输出结果：
(a,1000)=>(a,3000)
(a,1000)=>(a,4000)
(a,2000)=>(a,3000)
(a,2000)=>(a,4000)
(b,1000)=>(b,3000)
(b,1000)=>(b,4000)
(b,2000)=>(b,3000)
(b,2000)=>(b,4000)可以看到，窗口的联结是笛卡尔积。
8.3.2 间隔联结（Interval Join）
Flink 提供了一种叫作“间隔联结”（interval join）的合流操作。顾名思义，间隔联结的思路就是针对一条流的每个数据，开辟出其时间戳前后的一段时间间隔，看这期间是否有来自另一条流的数据匹配。
1. 间隔联结的原理
间隔联结具体的定义方式是，我们给定两个时间点，分别叫作间隔的“上界”（upperBound） 和下界”（lowerBound）；于是对于一条流（不妨叫作 A）中的任意一个数据元素 a，就可以开辟一段时间间隔：[a.timestamp + lowerBound, a.timestamp + upperBound],即以 a 的时间戳为中心，下至下界点、上至上界点的一个闭区间：我们就把这段时间作为可以匹配另一条流数据 的“窗口”范围。
所以对于另一条流（不妨叫 B）中的数据元素 b，如果它的时间戳落在了这个区间范围内，a 和 b 就成功配对，进而进行计算输出结果。所以匹配的条件为： a.timestamp + lowerBound <= b.timestamp <= a.timestamp + upperBound
这里需要注意，做间隔联结的两条流 A 和 B，也必须基于相同的 key；下界 lowerBound 应该小于等于上界 upperBound，两者都可正可负；间隔联结目前只支持事件时间语义。
如图 8-4 ，可以清楚地看到间隔联结的方式。下方的流 A 去间隔联结上方的流 B， 所以基于 A 的每个数据元素，都可开辟一个间隔区间。
我们这里设置下界为-2 毫秒，上界为 1 毫秒。于是对于时间戳为 2 的 A 中元素，它的可匹配区间就是[0, 3],流 B 中有时间戳为 0、1 的两个元素落在这个范围内，所以就可以得到匹配数据对(2, 0)和(2, 1)。同样地，A 中时间戳为 3 的元素，可匹配区间为[1, 4]，B 中只有时间戳为 1 的一个数据可以匹配，于是得到匹 配数据对(3, 1)。
所以可以看到，间隔联结同样是一种内连接（inner join）。与窗口联结不同的是，interval join 做匹配的时间段是基于流中数据的，所以并不确定；而且流 B 中的数据可以不只在一个区间内被匹配。
2. 间隔联结的调用
间隔联结在代码中，基于 KeyedStream 的联结（join）操作。DataStream 在 keyBy()得到 KeyedStream 后，可以调用 intervalJoin()来合并两条流，传入的参数同样是一个 KeyedStream， 两者的 key 类型应该一致；得到的是一个 IntervalJoin 类型。
后续的操作同样是完全固定的： 先通过 between()方法指定间隔的上下界，再调用 process()方法，定义对匹配数据对的处理操 作。调用 process()需要传入一个处理函数，这是处理函数家族的最后一员：“处理联结函数” ProcessJoinFunction。
通用调用形式如下：
stream1
.keyBy(_._1)
.intervalJoin(stream2.keyBy(_._1))
.between(Time.milliseconds(-2),Time.milliseconds(1))
.process(new ProcessJoinFunction[(String, Long), (String, Long), String] {
override def processElement(left: (String, Long), right: (String, Long), ctx:
ProcessJoinFunction[(String, Long), (String, Long), String]#Context, out:
Collector[String]) = {
out.collect(left + "," + right)
}
});可以看到，抽象类 ProcessJoinFunction 就像是 ProcessFunction 和 JoinFunction 的结合，内部同样有一个抽象方法 processElement()。与其他处理函数不同的是，它多了一个参数，这自然是因为有来自两条流的数据。参数中 left 指的就是第一条流中的数据，right 则是第二条流中与它匹配的数据。每当检测到一组匹配，就会调用这里的 processElement()方法，经处理转换 之后输出结果。
3. 间隔联结实例
在电商网站中，某些用户行为往往会有短时间内的强关联。
这里举一个例子，有两条流，一条是下订单的流，一条是浏览数据的流。我们可以针对同一个用户，来做这样一个联结。也就是使用一个用户的下订单的事件和这个用户的最近十分钟的浏览数据进行一个联结查询。
下面是一段示例代码：
import org.apache.flink.streaming.api.functions.co.ProcessJoinFunction
import org.apache.flink.streaming.api.scala._
import org.apache.flink.streaming.api.windowing.time.Time
import org.apache.flink.util.Collector
//基于间隔的 join
object IntervalJoinExample {
def main(args: Array[String]): Unit = {
val env = StreamExecutionEnvironment.getExecutionEnvironment
env.setParallelism(1)
// 订单事件流
val orderStream: DataStream[(String, String, Long)] = env
.fromElements(
("Mary", "order-1", 5000L),
("Alice", "order-2", 5000L),
("Bob", "order-3", 20000L),
("Alice", "order-4", 20000L),
("Cary", "order-5", 51000L)
).assignAscendingTimestamps(_._3)
147
// 点击事件流
val pvStream: DataStream[Event] = env
.fromElements(
Event("Bob", "./cart", 2000L),
Event("Alice", "./prod?id=100", 3000L),
Event("Alice", "./prod?id=200", 3500L),
Event("Bob", "./prod?id=2", 2500L),
Event("Alice", "./prod?id=300", 36000L),
Event("Bob", "./home", 30000L),
Event("Bob", "./prod?id=1", 23000L),
Event("Bob", "./prod?id=3", 33000L)
).assignAscendingTimestamps(_.timestamp)
// 两条流进行间隔联结，输出匹配结果
orderStream
.keyBy(_._1)
.intervalJoin(pvStream.keyBy(_.user))
// 指定间隔
.between(Time.minutes(-5), Time.minutes(10))
.process(
new ProcessJoinFunction[(String, String, Long), Event, String] {
override def processElement(left: (String, String, Long), right: Event,
ctx: ProcessJoinFunction[(String, String, Long), Event, String]#Context, out:
Collector[String]): Unit = {
out.collect(left + "=>" + right)
}
})
.print()
env.execute()
}
}输出结果：
Event(Alice,./prod?id=100,3000)=>(Alice,order-2,5000)
Event(Alice,./prod?id=200,3500)=>(Alice,order-2,5000)
Event(Bob,./home,30000)=>(Bob,order-3,20000)
Event(Bob,./prod?id=1,23000)=>(Bob,order-3,20000)
