Flink 1.12.2 源码浅析 : Graph 概念梳理

怼烎@ 2022-11-17 10:05 126阅读 0赞

### . ###

*  一 .前言
 *  二 .名词解释
 *   *  2.1. StreamGraph
     *  2.2. JobGraph
     *  2.3. ExecutionGraph
     *  2.4. 物理执行图
 *  二 .Flink 四层转化流程
 *   *  2.1. Program 到 StreamGraph 的转化
     *  2.2. StreamGraph 到 JobGraph 的转化
     *  2.3. JobGraph 到 ExexcutionGraph 以及物理执行计划

# 一 .前言 #

Flink 中的执行图可以分成四层： StreamGraph -> JobGraph -> ExecutionGraph -> 物理执行图。

*  **StreamGraph**：是根据用户通过 Stream API 编写的代码生成的最初的图。用来表示程序的拓扑结构。
 *  **JobGraph**： StreamGraph 经过优化后生成了 JobGraph，提交给 JobManager 的数据结构。主要的优化为，将多个符合条件的节点 chain 在一起作为一个节点，这样可以减少数据在节点之间流动所需要的序列化/反序列化/传输消耗 。
 *  **ExecutionGraph**： JobManager 根据 JobGraph 生成 ExecutionGraph。 ExecutionGraph 是JobGraph 的**并行化版本**，是**调度层**最核心的数据结构。
 *  **物 理 执 行 图** ： JobManager 根 据 ExecutionGraph 对 Job 进 行 调 度 后 ， 在 各 个TaskManager 上部署 Task 后形成的“图”，并不是一个具体的数据结构。

**StreamGraph，JobGraph在Flink客户端生成**，然后提交给Flink集群。**JobGraph到ExecutionGraph的转换在JobMaster中完成**

*  整体执行图  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5nbG9uZ180NDQ0_size_16_color_FFFFFF_t_70]
 *  **代码示例:**  
    例如 example 里的 SocketTextStreamWordCount 并发度为 2（Source 为 1 个并发度）的四层执行图的演变过程如下图所示：

public static void main(String[] args) throws Exception { 
        // 检查输入
        final ParameterTool params = ParameterTool.fromArgs(args);
        ...
        // set up the execution environment
        final StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();
        // get input data
        DataStream<String> text =
            env.socketTextStream(params.get("hostname"), params.getInt("port"), '\n', 0);
        
        
        DataStream<Tuple2<String, Integer>> counts =
            // split up the lines in pairs (2-tuples) containing: (word,1)
            text.flatMap(new Tokenizer())
                // group by the tuple field "0" and sum up tuple field "1"
                .keyBy(0)
                .sum(1);
        counts.print();
    
        // execute program
        env.execute("WordCount from SocketTextStream Example");
    }

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5nbG9uZ180NDQ0_size_16_color_FFFFFF_t_70 1]

# 二 .名词解释 #

## 2.1. StreamGraph ##

**根据用户通过 Stream API 编写的代码生成的最初的图。**

使用DataStream API开发的应用程序，首先被转换为Transformation，然后被映射为StreamGraph，该图与具体的执行无关，核心是表达计算过程的逻辑。

StreamGraph在FlinkClient中生成，由Flink Client在提交时候触发Flink应用的main，用户编写的业务逻辑组装成Transformation流水线，在最后调用StreamExecutionEnvironment。execute（）的时候开始触发StreamGraph的构建。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5nbG9uZ180NDQ0_size_16_color_FFFFFF_t_70 2]

1.  **StreamNode**：用来代表 operator 的类，并具有所有相关的属性，如并发度、入边和出边等。

> StreamNode是StreamGraph中的节点，从Transformation转换而来，可以简单理解为一个StreamNode表示一个算子。

1.  **StreamEdge**：表示连接两个 StreamNode 的边。

> StreamEdge是StreamGraph中的边，用来连接两个StreamNode，一个StreamNode可以有多个出边，入边，StreamEdge中包含了旁路输出，分区器，字段筛选输出等信息。

## 2.2. JobGraph ##

**StreamGraph 经过优化后生成了 JobGraph，提交给 JobManager 的数据结构。**

JobGraph可以由流计算的StreamGraph和批处理的OptimizedPlan转换而来。流计算中，在StreamGraph的基础上进行了一些优化，如果通过OperatorChain机制将算子合并起来，在执行时，调度在同一个Task线程上，避免数据的跨线程，跨网络的传递。

JobGraph的生成入口在StreamGraph中，流计算的JobGraph和批处理的JobGraph的生成逻辑不同，对于流而言，使用的是StreamingJobGraphGenerator，对于批而言，使用的是JobGraphGenerator。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5nbG9uZ180NDQ0_size_16_color_FFFFFF_t_70 3]

1.  **Operator Chains** :没有 shuffle 的多个算子合并在一个 subTask 中，就形成了 Operator Chains，类似于 Spark 中的 Pipeline。每个task被一个线程执行.

> 将算子链接成task是非常有效的优化：它能减少线程之间的切换和基于缓存区的数据交换，在减少时延的同时提升吞吐量。链接的行为可以在编程API中进行指定。

1.  **JobVertex**：经过优化后符合条件的多个 StreamNode 可能会 chain 在一起生成一个JobVertex，即一个 JobVertex 包含一个或多个 operator， JobVertex 的输入是 JobEdge，输出是IntermediateDataSet。
2.  **IntermediateDataSet**：中间数据集IntermediateDataSet是一种逻辑结构，用来表示JobVertex的输出，即该JobVertex中包含的算子会产生的数据集。不同的执行模式下，其对应的结果分区类型，决定了在执行时刻数据交换的模式。

> IntermediateDataSet的个数与该JobVertex对应的StreamNode的出边数量相同，可以是一个或者多个。

1.  **JobEdge**： JobEdge是JobGraph中连接IntermediateDataSet和JobVertex的边，表示JobGraph中的一个数据流转通道，其上游数据源是intermediatedataset，下游数据是JobVertex，即数据通过JobEdge由IntermediateDataset传递给目标JobVertex。

> Edge中的数据分发模式会直接影响执行时Task之间的数据连接关系，是点对点连接还是全连接。

## 2.3. ExecutionGraph ##

**JobManager 根据 JobGraph 生成 ExecutionGraph。 ExecutionGraph是 JobGraph 的并行化版本，是调度层最核心的数据结构。**

ExecutionGraph是调度Flink作业执行的核心数据结构，包含了作业中所有并行执行的Task的信息，Task之间的关联关系，数据流转关系。

**StreamGraph，JobGraph在Flink客户端生成**，然后提交给Flink集群。**JobGraph到ExecutionGraph的转换在JobMaster中完成**，转换过程中的重要变化如下。

1）加入并行度的概念，成为真正可调度的图结构；

2）生成了与JobVertex对应的ExecutionJobVertex和ExecutionVertex，与IntermediateDataSet对应的IntermediateResult和IntermediateResultPartition等，并行将通过这些类实现。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5nbG9uZ180NDQ0_size_16_color_FFFFFF_t_70 4]

1.  **ExecutionJobVertex** ： 该对象和JobGraph中的JobVertex一一对应。该对象还包含一组ExecutionVertex，数量与该JobVertex中所包含的StreamNode的并行度一致，假设StreamNode的并行度为5，那么该ExecutionJobVertex也会包含5个ExecutionVertex。

> ExecutionJobVertex原来将一个JobVertex封装成ExecutionJobVertex，并依次创建ExecutionVertex，Execution，IntermediateResult和IntermediateResultPartition，用于丰富ExecutionGraph。

> 在ExecutionJobVertex的构造函数中，首先是依据对应的JobVertex的并发度，生成对应个数的ExecutionVertex。其中，一个ExecutionVertex代表一个ExecutionJobVertex的并发子Task。然后是将原来JobVertex的中间结果IntermediateDataSet转化为ExecutionGraph中的IntermediateResult。

1.  **ExecutionVertex**：表示 ExecutionJobVertex 的其中一个并发子任务，输入是ExecutionEdge，输出是 IntermediateResultPartition。

> ExecutionJobVertex中会对作业进行并行化处理，构造可以并行执行的实例，每一个并行执行的实例就是ExecutionVertex。

> 构造ExecutionVertex的同时，也会构建ExecutionVertex的输出IntermediateResult。并且将ExecutionEdge输出为IntermediateResultPartition。

> ExecutionVertex的构造函数中，首先会创建IntermediateResultPartition，并通过IntermediateResult.setPartition()建立IntermediateResult和IntermediateResultPartition之间的关系；然后生成Execution，并配置资源相关。

1.  **IntermediateResult** ：IntermediateResult又叫做中间结果集，该对象是个逻辑概念，表示ExecutionJobVertex的输出，和JobGraph中的IntermediateDataSet一一对应，同样，一个ExecutionJobVertex可以有多个中间结果，取决于当前JobVertex有几个出边（JobEdge）。

> 一个中间结果集包含多个中间结果分区IntermediateResultPartition，其个数等于该JobVertex的并发度，或者叫做算子的并行度。

1.  **IntermediateResultPartition** ：IntermediateResultPartition又叫做中间结果集分区，表示一个ExecutionVertex输出结果，与ExecutionEdge相关联。 producer 是ExecutionVertex， consumer 是若干个 ExecutionEdge。
2.  **ExecutionEdge**：表示ExecutionVertex的输入，连接上游产生的IntermediateResultPartition。一个Execution对应于唯一的一个IntermediateResultPartition和一个ExecutionVertex。一个ExecutionVertex可以有多个ExecutionEdge。 source 是 IntermediateResultPartition，target 是 ExecutionVertex。 source 和 target 都只能是一个。
3.  **Execution**：ExecutionVertex相当于每个Task的模板，在真正执行的时候，会将ExecutionVertex中的信息包装成一个Execution，执行一个ExecutionVertex的一次尝试。JobManager和TaskManager之间关于Task部署和Task执行状态的更新是通过ExecutionAttemptID来标识实例的。当发生故障或者数据需要重算的情况下 ExecutionVertex 可能会有多个 ExecutionAttemptID。一个 Execution 通过ExecutionAttemptID 来唯一标识。 JM 和 TM 之间关于 task 的部署和 task status 的更新都是通过 ExecutionAttemptID 来确定消息接受者

从这些基本概念中，也可以看出以下⼀点：  
⚫ 由于每个 JobVertex 可能有多个 IntermediateDataSet，所以每个 ExecutionJobVertex可能有多个 IntermediateResult，因此，每个 ExecutionVertex 也可能会包含多个IntermediateResultPartition；  
⚫ ExecutionEdge 这里主要的作⼀是把 ExecutionVertex 和 IntermediateResultPartition连接起来，表示它们之间的连接关系。

## 2.4. 物理执行图 ##

**JobManager 根据 ExecutionGraph 对 Job 进行调度后，在各个TaskManager 上部署 Task 后形成的“图”，并不是一个具体的数据结构。**

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5nbG9uZ180NDQ0_size_16_color_FFFFFF_t_70 5]

1.  **Task**： Execution 被调度后在分配的 TaskManager 中启动对应的 Task。 Task 包裹了具有用户执行逻辑的 operator。
2.  **ResultPartition**：代表由一个 Task 的生成的数据，和 ExecutionGraph 中的IntermediateResultPartition 一一对应。
3.  **ResultSubpartition**：是 ResultPartition 的一个子分区。每个 ResultPartition 包含多个ResultSubpartition，其数目要由下游消费 Task 数和 DistributionPattern 来决定。
4.  **InputGate**：代表 Task 的输入封装，和 JobGraph 中 JobEdge 一一对应。每个 InputGate消费了一个或多个的 ResultPartition。
5.  **InputChannel**：每个 InputGate 会包含一个以上的 InputChannel，和 ExecutionGraph中的 ExecutionEdge 一一对应，也和 ResultSubpartition 一对一地相连，即一个 InputChannel接收一个 ResultSubpartition 的输出。

# 二 .Flink 四层转化流程 #

Flink 有四层转换流程，  
第一层为 Program 到 StreamGraph；  
第二层为 StreamGraph 到 JobGraph；  
第三层为 JobGraph 到 ExecutionGraph；  
第四层为 ExecutionGraph 到物理执行计划。

通过对 Program 的执行，能够生成一个 DAG 执行图，即逻辑执行图。如下：

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5nbG9uZ180NDQ0_size_16_color_FFFFFF_t_70 1]

*  第一层 StreamGraph 从 Source 节点开始，每一次 transform 生成一个 StreamNode，两个 StreamNode 通过 StreamEdge 连接在一起,形成 StreamNode 和 StreamEdge 构成的DAG。
 *  第二层 JobGraph，依旧从 Source 节点开始，然后去遍历寻找能够嵌到一起的 operator，如果能够嵌到一起则嵌到一起，不能嵌到一起的单独生成 jobVertex，通过 JobEdge 链接上下游 JobVertex，最终形成 JobVertex 层面的 DAG。

\-第三层 JobVertex DAG 提交到任务以后，从 Source 节点开始排序,根据 JobVertex 生成ExecutionJobVertex，根据 jobVertex的IntermediateDataSet 构建IntermediateResult，然后 IntermediateResult 构建上下游的依赖关系，形成 ExecutionJobVertex 层面的 DAG 即 ExecutionGraph。

*  最后通过 ExecutionGraph 层到物理执行层。

## 2.1. Program 到 StreamGraph 的转化 ##

Program 转换成 StreamGraph 具体分为三步：

*  从 StreamExecutionEnvironment.execute 开始执行程序，将 transform 添加到 StreamExecutionEnvironment 的 transformations。
 *  调用 StreamGraphGenerator 的 generateInternal 方法，遍历 transformations 构建 StreamNode 及 StreamEage。
 *  通过 StreamEdge 连接 StreamNode。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5nbG9uZ180NDQ0_size_16_color_FFFFFF_t_70 6]

通过 WindowWordCount 来看代码到 StreamGraph 的转化，在 **flatMap transform 设置 slot 共享组为 flatMap\_sg，并发设置为 4**，在聚合的操作中设置 slot 共享组为 sum\_sg， sum() 和 counts() 并发设置为 3，这样设置主要是为了演示后面如何嵌到一起的，跟上下游节点的并发以及上游的共享组有关。

WindowWordCount 代码中可以看到，在 readTextFile() 中会生成一个 transform，且 transform 的 ID 是 1；然后到 flatMap() 会生成一个 transform， transform 的 ID 是 2；接着到 keyBy() 生成一个 transform 的 ID 是 3；再到 sum() 生成一个 transform 的 ID 是 4；最后到 counts()生成 transform 的 ID 是 5。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5nbG9uZ180NDQ0_size_16_color_FFFFFF_t_70 7]

transform 的结构如图所示，第一个是 flatMap 的 transform，第二个是 window 的 transform，第三个是 SinkTransform 的 transform。除此之外，还能在 transform 的结构中看到每个 transform 的 input 是什么。

接下来介绍一下 StreamNode 和 StreamEdge。

*  StreamNode 是用来描述 operator 的逻辑节点，其关键成员变量有 slotSharingGroup、jobVertexClass、inEdges、outEdges以及transformationUID；
 *  StreamEdge 是用来描述两个 operator 逻辑的链接边，其关键变量有 sourceVertex、targetVertex。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5nbG9uZ180NDQ0_size_16_color_FFFFFF_t_70 8]  
WindowWordCount transform 到 StreamGraph 转化如图所示，StreamExecutionEnvironment 的 transformations 存在 3 个 transform，分别是 Flat Map（Id 2）、Window（Id 4）、Sink（Id 5）。

transform 的时候首先递归处理 transform 的 input，生成 StreamNode，然后通过 StreamEdge 链接上下游 StreamNode。需要注意的是，有些 transform 操作并不会生成StreamNode 如 PartitionTransformtion，而是生成个虚拟节点。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5nbG9uZ180NDQ0_size_16_color_FFFFFF_t_70 9]  
在转换完成后可以看到，streamNodes 有四种 transform 形式，分别为 Source、Flat Map、Window、Sink。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5nbG9uZ180NDQ0_size_16_color_FFFFFF_t_70 10]  
每个 streamNode 对象都携带并发个数、slotSharingGroup、执行类等运行信息。

## 2.2. StreamGraph 到 JobGraph 的转化 ##

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5nbG9uZ180NDQ0_size_16_color_FFFFFF_t_70 11]

**StreamGraph 到 JobGraph 的转化步骤：**

*  设置调度模式，Eager 所有节点立即启动。
 *  广度优先遍历 StreamGraph，为每个 streamNode 生成 byte 数组类型的 hash 值。
 *  从 source 节点开始递归寻找嵌到一起的 operator，不能嵌到一起的节点单独生成 jobVertex，能够嵌到一起的开始节点生成 jobVertex，其他节点以序列化的形式写入到 StreamConfig，然后 merge 到 CHAINED\_TASK\_CONFIG，再通过 JobEdge 链接上下游 JobVertex。
 *  将每个 JobVertex 的入边(StreamEdge)序列化到该 StreamConfig。
 *  根据 group name 为每个 JobVertext 指定 SlotSharingGroup。
 *  配置 checkpoint。
 *  将缓存文件存文件的配置添加到 configuration 中。
 *  设置 ExecutionConfig。

**从 source 节点递归寻找嵌到一起的 operator 中，嵌到一起需要满足一定的条件，具体条件介绍如下：**

*  下游节点只有一个输入。
 *  下游节点的操作符不为 null。
 *  上游节点的操作符不为 null。
 *  上下游节点在一个槽位共享组内。
 *  下游节点的连接策略是 ALWAYS。
 *  上游节点的连接策略是 HEAD 或者 ALWAYS。
 *  edge 的分区函数是 ForwardPartitioner 的实例。
 *  上下游节点的并行度相等。
 *  可以进行节点连接操作。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5nbG9uZ180NDQ0_size_16_color_FFFFFF_t_70 12]  
JobGraph 对象结构如上图所示，taskVertices 中只存在 Window、Flat Map、Source 三个 TaskVertex，Sink operator 被嵌到 window operator 中去了。

**为什么要为每个 operator 生成 hash 值？**  
Flink 任务失败的时候，各个 operator 是能够从 checkpoint 中恢复到失败之前的状态的，恢复的时候是依据 JobVertexID（hash 值)进行状态恢复的。相同的任务在恢复的时候要求 operator 的 hash 值不变，因此能够获取对应的状态。

**每个 operator 是怎样生成 hash 值的？**  
如果用户对节点指定了一个散列值，则基于用户指定的值能够产生一个长度为 16 的字节数组。如果用户没有指定，则根据当前节点所处的位置，产生一个散列值。

考虑的因素主要有三点：

*  一是在当前 StreamNode 之前已经处理过的节点的个数，作为当前 StreamNode 的 id，添加到 hasher 中；
 *  二是遍历当前 StreamNode 输出的每个 StreamEdge，并判断当前 StreamNode 与这个 StreamEdge 的目标 StreamNode 是否可以进行链接，如果可以，则将目标 StreamNode 的 id 也放入 hasher 中，且这个目标 StreamNode 的 id 与当前 StreamNode 的 id 取相同的值；
 *  三是将上述步骤后产生的字节数据，与当前 StreamNode 的所有输入 StreamNode 对应的字节数据，进行相应的位操作，最终得到的字节数据，就是当前 StreamNode 对应的长度为 16 的字节数组。

## 2.3. JobGraph 到 ExexcutionGraph 以及物理执行计划 ##

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5nbG9uZ180NDQ0_size_16_color_FFFFFF_t_70 13]

JobGraph 到 ExexcutionGraph 以及物理执行计划的流程：

*  将 JobGraph 里面的 jobVertex 从 Source 节点开始排序。
 *  在 executionGraph.attachJobGraph(sortedTopology)方法里面，根据 JobVertex 生成 ExecutionJobVertex，在 ExecutionJobVertex 构造方法里面，根据 jobVertex 的 IntermediateDataSet 构建 IntermediateResult，根据 jobVertex 并发构建 ExecutionVertex，ExecutionVertex 构建的时候，构建 IntermediateResultPartition（每一个 Execution 构建 IntermediateResult 数个IntermediateResultPartition ）；将创建的 ExecutionJobVertex 与前置的 IntermediateResult 连接起来。
 *  构建 ExecutionEdge ，连接到前面的 IntermediateResultPartition，最终从 ExecutionGraph 到物理执行计划。

参考信息:  
《Flink内核原理与实现》 - 冯飞  
https://ververica.cn/developers/advanced-tutorial-2-flink-job-execution-depth-analysis/  
http://www.whitewood.me/2018/06/17/FLIP6-%E8%B5%84%E6%BA%90%E8%B0%83%E5%BA%A6%E6%A8%A1%E5%9E%8B%E9%87%8D%E6%9E%84/

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5nbG9uZ180NDQ0_size_16_color_FFFFFF_t_70]: /images/20221022/fb7213029d00486c85ccab8ce9f60723.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5nbG9uZ180NDQ0_size_16_color_FFFFFF_t_70 1]: /images/20221022/15547844dc7d4dd79813b6a580f900ec.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5nbG9uZ180NDQ0_size_16_color_FFFFFF_t_70 2]: /images/20221022/1b0b1a3022504ba8aa07130deda11035.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5nbG9uZ180NDQ0_size_16_color_FFFFFF_t_70 3]: /images/20221022/9270e2e962684748b633fd632cf8d92d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5nbG9uZ180NDQ0_size_16_color_FFFFFF_t_70 4]: /images/20221022/a09e674bb0c74f48bfd55d93c1beefe7.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5nbG9uZ180NDQ0_size_16_color_FFFFFF_t_70 5]: /images/20221022/9f17fa4e68284d26bfa2c4196549064b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5nbG9uZ180NDQ0_size_16_color_FFFFFF_t_70 6]: /images/20221022/4d8294f5179647bdbf37ff5483a5ccb4.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5nbG9uZ180NDQ0_size_16_color_FFFFFF_t_70 7]: /images/20221022/32bd19b945764107926704be05b4751f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5nbG9uZ180NDQ0_size_16_color_FFFFFF_t_70 8]: /images/20221022/cfe809b9039a4914a9cede43941f4dcc.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5nbG9uZ180NDQ0_size_16_color_FFFFFF_t_70 9]: /images/20221022/35323621885041abbe6abcd77ec86adb.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5nbG9uZ180NDQ0_size_16_color_FFFFFF_t_70 10]: /images/20221022/62ed81acfd784dde9548222272a9e15e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5nbG9uZ180NDQ0_size_16_color_FFFFFF_t_70 11]: /images/20221022/056eed17f8654a6488f9662064ddef55.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5nbG9uZ180NDQ0_size_16_color_FFFFFF_t_70 12]: /images/20221022/cadd1a94898447ae9f1fd8e74b29db3e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5nbG9uZ180NDQ0_size_16_color_FFFFFF_t_70 13]: /images/20221022/aa092c00f618491c9bba54e77ea42a5b.png