flink.txt

1.1 大数据处理架构演进历程 1
1.2 案例分析 8
1.2.1 SK 电信驾驶安全性评分 8
1.2.2 流式机器学习应用 12
1.3 流式数据架构基本概念 17
1.3.1 流 17
1.3.2 时间 18
1.3.3 窗口 21
1.3.4 水印 23
1.3.5 触发器 23
1.3.6 数据处理模式 23
1.3.7 如何理解流式数据架构的内在机制 27
1.4 根据事件时间开滚动窗口 28
1.4.1 what：转换／where：窗口 29
1.4.2 when：水印 29
1.4.3 when：触发器 32
1.4.4 when：迟到生存期 34
1.4.5 how：累加模式 35
1.5 一致性 37
1.5.1 有状态计算 37
1.5.2 exactly-once 语义 38
1.5.3 异步屏障快照 39
1.5.4 保存点 44
1.6 思考题 45
第2 章 编程基础 46
2.1 Flink 概述 46
2.2 让轮子转起来 47
2.2.1 本书约定 47
2.2.2 搭建单机版环境 48
2.2.3 配置IDEA 51
2.3 编程模型 53
2.3.1 分层组件栈 53
2.3.2 流式计算模型 54
2.3.3 流处理编程 57
2.4 运行时 62
2.4.1 运行时结构 62
2.4.2 任务调度 66
2.4.3 物理执行计划 69
2.5 思考题 70
第3 章 流处理API 71
3.1 流处理API 概述 71
3.2 时间处理 73
3.2.1 时间 73
3.2.2 水印 74
3.2.3 周期性水印生成器 75
3.2.4 间歇性水印生成器 77
3.2.5 递增式水印生成器 78
3.3 算子 79
3.3.1 算子函数 80
3.3.2 数据分区 83
3.3.3 资源共享 85
3.3.4 RichFunction 85
3.3.5 输出带外数据 86
3.4 窗口 86
3.4.1 窗口分类 87
3.4.2 窗口函数 90
3.4.3 触发器 94
3.4.4 清除器 96
3.4.5 迟到生存期 96
3.5 连接器 97
3.5.1 HDFS 连接器 98
3.5.2 Kafka 99
3.5.3 异步I/O 102
3.6 状态管理 104
3.6.1 状态分类 104
3.6.2 托管的Keyed State 104
3.6.3 状态后端配置 106
3.7 检查点 107
3.8 思考题 108
第4 章 批处理API 109
4.1 批处理API 概述. 109
4.1.1 程序结构 110
4.1.2 Source 111
4.1.3 Sink 112
4.1.4 连接器 112
4.2 算子 113
4.2.1 算子函数 113
4.2.2 广播变量 121
4.2.3 文件缓存 122
4.2.4 容错 123
4.3 迭代 123
4.3.1 深度神经网络训练 123
4.3.2 网络社团发现算法 125
4.3.3 Bulk Iteration 127
4.3.4 Delta Iteration 的迭代形式 128
4.4 注解 130
4.4.1 直接转发 130
4.4.2 非直接转发 131
4.4.3 触达 132
4.5 思考题 132
第5 章 机器学习引擎架构与应用编程 133
5.1 概述 133
5.1.1 数据加载 134
5.1.2 多项式曲线拟合的例子 135
5.2 流水线 137
5.2.1 机器学习面临的架构问题 137
5.2.2 Scikit-learn 架构实践总结 138
5.2.3 FlinkML 实现 140
5.3 深入分析多项式曲线拟合 170
5.3.1 数值计算的底层框架 170
5.3.2 向量 172
5.3.3 数据预处理 178
5.3.4 特征变换 184
5.3.5 线性拟合 188
5.4 分类算法 190
5.4.1 最优超平面 190
5.4.2 凸优化理论 193
5.4.3 求解最优超平面 198
5.4.4 核方法 200
5.4.5 软间隔 205
5.4.6 优化解法 208
5.4.7 SVM 的FlinkML 实现 211
5.4.8 SVM 的应用 220
5.5 推荐算法 221
5.5.1 推荐系统的分类 221
5.5.2 ALS-WR 算法 223
5.5.3 FlinkML 实现 225
5.5.4 ALS-WR 的应用 230
5.6 思考题 230
第6 章 关系型API 234
6.1 为什么需要关系型API 234
6.2 Calcite 235
6.3 关系型API 概述. 236
6.3.1 程序结构 236
6.3.2 Table 运行时 239
6.3.3 表注册 241
6.3.4 TableSource 与TableSink 242
6.3.5 查询 244
6.3.6 相互转换 244
6.4 动态表概述 247
6.4.1 流式关系代数 247
6.4.2 动态表 248
6.4.3 持续查询 250
6.5 思考题 255
第7 章 复杂事件处理 256
7.1 什么是复杂事件处理 256
7.1.1 股票异常交易检测 256
7.1.2 重新审视DataStream 与Table API 258
7.2 复杂事件处理的自动机理论 259
7.2.1 有穷自动机模型NFA 259
7.2.2 NFAb 模型 261
7.2.3 带版本号的共享缓存 263
7.3 FlinkCEP API 265
7.3.1 基本模式 266
7.3.2 模式拼合 267
7.3.3 模式分组 268
7.3.4 匹配输出 269
7.4 基于FlinkCEP 的股票异常交易检测的实现 270
7.5 思考题 274
第8 章 监控与部署 275
8.1 监控 275
8.1.1 度量指标 275
8.1.2 指标的作用域 279
8.1.3 监控配置 279
8.2 集群部署模式 281
8.2.1 Standalone 281
8.2.2 YARN 281
8.2.3 高可用 284
8.3 访问安全 284

第 1章　为何选择Flink 1
1．1　流处理欠佳的后果 2
1．1．1　零售业和市场营销 2
1．1．2　物联网 3
1．1．3　电信业 5
1．1．4　银行和金融业 5
1．2　连续事件处理的目标 6
1．3　流处理技术的演变 6
1．4　初探Flink 9
1．5　生产环境中的Flink 12
1．5．1　布衣格电信 13
1．5．2　其他案例 14
1．6　Flink的适用场景 15
第 2章　流处理架构 17
2．1　传统架构与流处理架构 17
2．2　消息传输层和流处理层 18
2．3　消息传输层的理想功能 19
2．3．1　兼具高性能和持久性 20
2．3．2　将生产者和消费者解耦 20
2．4　支持微服务架构的流数据 21
2．4．1　数据流作为中心数据源 22
2．4．2　欺诈检测：流处理架构用例 22
2．4．3　给开发人员带来的灵活性 24
2．5　不限于实时应用程序 24
2．6　流的跨地域复制 26
第3章　Flink 的用途 29
3．1　不同类型的正确性 29
3．1．1　符合产生数据的自然规律 29
3．1．2　事件时间 31
3．1．3　发生故障后仍保持准确 32
3．1．4　及时给出所需结果 33
3．1．5　使开发和运维更轻松 33
3．2　分阶段采用Flink 34
第4章　对时间的处理 35
4．1　采用批处理架构和Lambda 架构计数 35
4．2　采用流处理架构计数 38
4．3　时间概念 40
4．4　窗口 41
4．4．1　时间窗口 41
4．4．2　计数窗口 43
4．4．3　会话窗口 43
4．4．4　触发器 44
4．4．5　窗口的实现 44
4．5　时空穿梭 44
4．6　水印 45
4．7　真实案例：爱立信公司的Kappa 架构 47
第5章　有状态的计算 49
5．1　一致性 50
5．2　检查点：保证exactly-once 51
5．3　保存点：状态版本控制 59
5．4　端到端的一致性和作为数据库的流处理器 62
5．5　Flink 的性能 65
5．5．1　Yahoo! Streaming Benchmark 65
5．5．2　变化1：使用Flink 状态 66
5．5．3　变化2：改进数据生成器并增加吞吐量 67
5．5．4　变化3：消除网络瓶颈 68
5．5．5　变化4：使用MapR Streams 69
5．5．6　变化5：增加key 基数 69
5．6　结论 71
第6章　批处理：一种特殊的流处理 73
6．1　批处理技术 75
6．2　案例研究：Flink 作为批处理器 76
附录　其他资源 79

About the Author
About the Reviewers
www.PacktPub.com
Why subscribe?
Customer Feedback
Preface
What this book covers
What you need for this book
Who this book is for
Conventions
Reader feedback
Customer support
Downloading the example code
Downloading the color images of this book
Errata
Piracy
Questions
1. Introduction to Apache Flink
History
Architecture
Distributed execution
Job Manager
Actor system
Scheduler
Check pointing
Task manager
Job client
Features
High performance
Exactly-once stateful computation
Flexible streaming windows
Fault tolerance
Memory management
Optimizer
Stream and batch in one platform
Libraries
Event time semantics
Quick start setup
Pre-requisite
Installing on Windows
Installing on Linux
Cluster setup
SSH configurations
Java installation
Flink installation
Configurations
Starting daemons
Adding additional Job/Task Managers
Stopping daemons and cluster
Running sample application
Summary
2. Data Processing Using the DataStream API
Execution environment
Data sources
Socket-based
File-based
Transformations
Map
FlatMap
Filter
KeyBy
Reduce
Fold
Aggregations
Window
Global windows
Tumbling windows
Sliding windows
Session windows
WindowAll
Union
Window join
Split
Select
Project
Physical partitioning
Custom partitioning
Random partitioning
Rebalancing partitioning
Rescaling
Broadcasting
Data sinks
Event time and watermarks
Event time
Processing time
Ingestion time
Connectors
Kafka connector
Twitter connector
RabbitMQ connector
ElasticSearch connector
Embedded node mode
Transport client mode
Cassandra connector
Use case - sensor data analytics
Summary
3. Data Processing Using the Batch Processing API
Data sources
File-based
Collection-based
Generic sources
Compressed files
Transformations
Map
Flat map
Filter
Project
Reduce on grouped datasets
Reduce on grouped datasets by field position key
Group combine
Aggregate on a grouped tuple dataset
MinBy on a grouped tuple dataset
MaxBy on a grouped tuple dataset
Reduce on full dataset
Group reduce on a full dataset
Aggregate on a full tuple dataset
MinBy on a full tuple dataset
MaxBy on a full tuple dataset
Distinct
Join
Cross
Union
Rebalance
Hash partition
Range partition
Sort partition
First-n
Broadcast variables
Data sinks
Connectors
Filesystems
HDFS
Amazon S3
Alluxio
Avro
Microsoft Azure storage
MongoDB
Iterations
Iterator operator
Delta iterator
Use case - Athletes data insights using Flink batch API
Summary
4. Data Processing Using the Table API
Registering tables
Registering a dataset
Registering a datastream
Registering a table
Registering external table sources
CSV table source
Kafka JSON table source
Accessing the registered table
Operators
The select operator
The where operator
The filter operator
The as operator
The groupBy operator
The join operator
The leftOuterJoin operator
The rightOuterJoin operator
The fullOuterJoin operator
The union operator
The unionAll operator
The intersect operator
The intersectAll operator
The minus operator
The minusAll operator
The distinct operator
The orderBy operator
The limit operator
Data types
SQL
SQL on datastream
Supported SQL syntax
Scalar functions
Scalar functions in the table API
Scala functions in SQL
Use case - Athletes data insights using Flink Table API
Summary
5. Complex Event Processing
What is complex event processing?
Flink CEP
Event streams
Pattern API
Begin
Filter
Subtype
OR
Continuity
Strict continuity
Non-strict continuity
Within
Detecting patterns
Selecting from patterns
Select
flatSelect
Handling timed-out partial patterns
Use case - complex event processing on a temperature sensor
Summary
6. Machine Learning Using FlinkML
What is machine learning?
Supervised learning
Regression
Classification
Unsupervised learning
Clustering
Association
Semi-supervised learning
FlinkML
Supported algorithms
Supervised learning
Support Vector Machine
Multiple Linear Regression
Optimization framework
Recommendations
Alternating Least Squares
Unsupervised learning
k Nearest Neighbour join
Utilities
Data pre processing and pipelines
Polynomial features
Standard scaler
MinMax scaler
Summary
7. Flink Graph API - Gelly
What is a graph?
Flink graph API - Gelly
Graph representation
Graph nodes
Graph edges
Graph creation
From dataset of edges and vertices
From dataset of tuples representing edges
From CSV files
From collection lists
Graph properties
Graph transformations
Map
Translate
Filter
Join
Reverse
Undirected
Union
Intersect
Graph mutations
Neighborhood methods
Graph validation
Iterative graph processing
Vertex-Centric iterations
Scatter-Gather iterations
Gather-Sum-Apply iterations
Use case - Airport Travel Optimization
Summary
8. Distributed Data Processing with Flink and Hadoop
Quick overview of Hadoop
HDFS
YARN
Flink on YARN
Configurations
Starting a Flink YARN session
Submitting a job to Flink
Stopping Flink YARN session
Running a single Flink job on YARN
Recovery behavior for Flink on YARN
Working details
Summary
9. Deploying Flink on Cloud
Flink on Google Cloud
Installing Google Cloud SDK
Installing BDUtil
Launching a Flink cluster
Executing a sample job
Shutting down the cluster
Flink on AWS
Launching an EMR cluster
Installing Flink on EMR
Executing Flink on EMR-YARN
Starting a Flink YARN session
Executing Flink job on YARN session
Shutting down the cluster
Flink on EMR 5.3+
Using S3 in Flink applications
Summary
10. Best Practices
Logging best practices
Configuring Log4j
Configuring Logback
Logging in applications
Using ParameterTool
From system properties
From command line arguments
From .properties file
Naming large TupleX types
Registering a custom serializer
Metrics
Registering metrics
Counters
Gauges
Histograms
Meters
Reporters
Monitoring REST API
Config API
Overview API
Overview of the jobs
Details of a specific job
User defined job configuration
Back pressure monitoring
Summary

第一部分（第1~2章）

主要介绍了Flink的核心概念、特性、应用场景、基本架构，开发环境的搭建和配置，以及源代码的编译。

第二部分（第3~9章）

详细讲解了Flink的编程范式，各种编程接口的功能、应用场景和使用方法，以及核心模块和组件的原理和使用。

第三部分（第10章）

重点讲解了Flink的监控和优化，参数调优，以及对反压、Checkpoint和内存的优化。


第1 章 流式数据架构理论 1
1.1 大数据处理架构演进历程 1
1.2 案例分析 8
1.2.1 SK 电信驾驶安全性评分 8
1.2.2 流式机器学习应用 12
1.3 流式数据架构基本概念 17
1.3.1 流 17
1.3.2 时间 18
1.3.3 窗口 21
1.3.4 水印 23
1.3.5 触发器 23
1.3.6 数据处理模式 23
1.3.7 如何理解流式数据架构的内在机制 27
1.4 根据事件时间开滚动窗口 28
1.4.1 what：转换／where：窗口 29
1.4.2 when：水印 29
1.4.3 when：触发器 32
1.4.4 when：迟到生存期 34
1.4.5 how：累加模式 35
1.5 一致性 37
1.5.1 有状态计算 37
1.5.2 exactly-once 语义 38
1.5.3 异步屏障快照 39
1.5.4 保存点 44
1.6 思考题 45
第2 章 编程基础 46
2.1 Flink 概述 46
2.2 让轮子转起来 47
2.2.1 本书约定 47
2.2.2 搭建单机版环境 48
2.2.3 配置IDEA 51
2.3 编程模型 53
2.3.1 分层组件栈 53
2.3.2 流式计算模型 54
2.3.3 流处理编程 57
2.4 运行时 62
2.4.1 运行时结构 62
2.4.2 任务调度 66
2.4.3 物理执行计划 69
2.5 思考题 70
第3 章 流处理API 71
3.1 流处理API 概述 71
3.2 时间处理 73
3.2.1 时间 73
3.2.2 水印 74
3.2.3 周期性水印生成器 75
3.2.4 间歇性水印生成器 77
3.2.5 递增式水印生成器 78
3.3 算子 79
3.3.1 算子函数 80
3.3.2 数据分区 83
3.3.3 资源共享 85
3.3.4 RichFunction 85
3.3.5 输出带外数据 86
3.4 窗口 86
3.4.1 窗口分类 87
3.4.2 窗口函数 90
3.4.3 触发器 94
3.4.4 清除器 96
3.4.5 迟到生存期 96
3.5 连接器 97
3.5.1 HDFS 连接器 98
3.5.2 Kafka 99
3.5.3 异步I/O 102
3.6 状态管理 104
3.6.1 状态分类 104
3.6.2 托管的Keyed State 104
3.6.3 状态后端配置 106
3.7 检查点 107
3.8 思考题 108
第4 章 批处理API 109
4.1 批处理API 概述. 109
4.1.1 程序结构 110
4.1.2 Source 111
4.1.3 Sink 112
4.1.4 连接器 112
4.2 算子 113
4.2.1 算子函数 113
4.2.2 广播变量 121
4.2.3 文件缓存 122
4.2.4 容错 123
4.3 迭代 123
4.3.1 深度神经网络训练 123
4.3.2 网络社团发现算法 125
4.3.3 Bulk Iteration 127
4.3.4 Delta Iteration 的迭代形式 128
4.4 注解 130
4.4.1 直接转发 130
4.4.2 非直接转发 131
4.4.3 触达 132
4.5 思考题 132
第5 章 机器学习引擎架构与应用编程 133
5.1 概述 133
5.1.1 数据加载 134
5.1.2 多项式曲线拟合的例子 135
5.2 流水线 137
5.2.1 机器学习面临的架构问题 137
5.2.2 Scikit-learn 架构实践总结 138
5.2.3 FlinkML 实现 140
5.3 深入分析多项式曲线拟合 170
5.3.1 数值计算的底层框架 170
5.3.2 向量 172
5.3.3 数据预处理 178
5.3.4 特征变换 184
5.3.5 线性拟合 188
5.4 分类算法 190
5.4.1 最优超平面 190
5.4.2 凸优化理论 193
5.4.3 求解最优超平面 198
5.4.4 核方法 200
5.4.5 软间隔 205
5.4.6 优化解法 208
5.4.7 SVM 的FlinkML 实现 211
5.4.8 SVM 的应用 220
5.5 推荐算法 221
5.5.1 推荐系统的分类 221
5.5.2 ALS-WR 算法 223
5.5.3 FlinkML 实现 225
5.5.4 ALS-WR 的应用 230
5.6 思考题 230
第6 章 关系型API 234
6.1 为什么需要关系型API 234
6.2 Calcite 235
6.3 关系型API 概述. 236
6.3.1 程序结构 236
6.3.2 Table 运行时 239
6.3.3 表注册 241
6.3.4 TableSource 与TableSink 242
6.3.5 查询 244
6.3.6 相互转换 244
6.4 动态表概述 247
6.4.1 流式关系代数 247
6.4.2 动态表 248
6.4.3 持续查询 250
6.5 思考题 255
第7 章 复杂事件处理 256
7.1 什么是复杂事件处理 256
7.1.1 股票异常交易检测 256
7.1.2 重新审视DataStream 与Table API 258
7.2 复杂事件处理的自动机理论 259
7.2.1 有穷自动机模型NFA 259
7.2.2 NFAb 模型 261
7.2.3 带版本号的共享缓存 263
7.3 FlinkCEP API 265
7.3.1 基本模式 266
7.3.2 模式拼合 267
7.3.3 模式分组 268
7.3.4 匹配输出 269
7.4 基于FlinkCEP 的股票异常交易检测的实现 270
7.5 思考题 274
第8 章 监控与部署 275
8.1 监控 275
8.1.1 度量指标 275
8.1.2 指标的作用域 279
8.1.3 监控配置 279
8.2 集群部署模式 281
8.2.1 Standalone 281
8.2.2 YARN 281
8.2.3 高可用 284
8.3 访问安全 284
8.4 思考题 286
参考资料 287

第 1章　为何选择Flink 1
1．1　流处理欠佳的后果 2
1．1．1　零售业和市场营销 2
1．1．2　物联网 3
1．1．3　电信业 5
1．1．4　银行和金融业 5
1．2　连续事件处理的目标 6
1．3　流处理技术的演变 6
1．4　初探Flink 9
1．5　生产环境中的Flink 12
1．5．1　布衣格电信 13
1．5．2　其他案例 14
1．6　Flink的适用场景 15
第 2章　流处理架构 17
2．1　传统架构与流处理架构 17
2．2　消息传输层和流处理层 18
2．3　消息传输层的理想功能 19
2．3．1　兼具高性能和持久性 20
2．3．2　将生产者和消费者解耦 20
2．4　支持微服务架构的流数据 21
2．4．1　数据流作为中心数据源 22
2．4．2　欺诈检测：流处理架构用例 22
2．4．3　给开发人员带来的灵活性 24
2．5　不限于实时应用程序 24
2．6　流的跨地域复制 26
第3章　Flink 的用途 29
3．1　不同类型的正确性 29
3．1．1　符合产生数据的自然规律 29
3．1．2　事件时间 31
3．1．3　发生故障后仍保持准确 32
3．1．4　及时给出所需结果 33
3．1．5　使开发和运维更轻松 33
3．2　分阶段采用Flink 34
第4章　对时间的处理 35
4．1　采用批处理架构和Lambda 架构计数 35
4．2　采用流处理架构计数 38
4．3　时间概念 40
4．4　窗口 41
4．4．1　时间窗口 41
4．4．2　计数窗口 43
4．4．3　会话窗口 43
4．4．4　触发器 44
4．4．5　窗口的实现 44
4．5　时空穿梭 44
4．6　水印 45
4．7　真实案例：爱立信公司的Kappa 架构 47
第5章　有状态的计算 49
5．1　一致性 50
5．2　检查点：保证exactly-once 51
5．3　保存点：状态版本控制 59
5．4　端到端的一致性和作为数据库的流处理器 62
5．5　Flink 的性能 65
5．5．1　Yahoo! Streaming Benchmark 65
5．5．2　变化1：使用Flink 状态 66
5．5．3　变化2：改进数据生成器并增加吞吐量 67
5．5．4　变化3：消除网络瓶颈 68
5．5．5　变化4：使用MapR Streams 69
5．5．6　变化5：增加key 基数 69
5．6　结论 71
第6章　批处理：一种特殊的流处理 73
6．1　批处理技术 75
6．2　案例研究：Flink 作为批处理器 76
附录　其他资源 79

Learning Apache Flink
Credits
About the Author
About the Reviewers
www.PacktPub.com
Why subscribe?
Customer Feedback
Preface
What this book covers
What you need for this book
Who this book is for
Conventions
Reader feedback
Customer support
Downloading the example code
Downloading the color images of this book
Errata
Piracy
Questions


=========================

Apache Flink 源码解析（一）入口，bash脚本
2018.10.14 09:45 920浏览
概述
因为自己在阅读源码的过程中曾经遇到过很多问题，现在稍微有一点点的经验希望分享给很多从零开始的人。Apache的项目代码量很大，很难做到彻底通读，我也是一步一步的先从整体的架构来分析。阅读源码的好处有很多，在此就不一一赘述。

介绍
首先介绍以下flink，它是一个分布式，高容错，能保证每条消息只被处理一次的流处理引擎，也是对Google Dataflow模型的一个较好的开源实现，虽然还是有一些不足之处。虽然在runtime中用的是同一个引擎，但是却提供了针对stream和batch的两套api，不过在后续的更新中应该更好地加入了对sql的支持来完成统一。

本次解析参考的代码是flink1.2版本。

另外Flink是使用Scala和Java混编，关于Scala和分布式工具包Akka的学习资料后续我会补充。

入口
首先是找到入口。因为一个项目中可能有几个主函数，而且大数据相关的项目还会兼容Yarn和Mesos，入口的话就更多了。在这里我会用Local模式和Standalone Cluster模式来讲解，一方面对Yarn和Mesos相关的背景就不需要怎么介绍（事实是我还没学 : ( ...），另一方面入门门槛也稍低一些，还省略了很多代码可以以后再分析。

要找入口，那就要去找启动脚本，建议大家可以稍微学一下bash， 不说能写的多好，最起码能看懂启动脚本就行。

Flink的启动脚本源码在flink-dist/src/main/flink-bin/bin文件夹下，其中有start-cluster和start-local。其中start-local的代码很简单





start-local.sh代码片段

就是调用同文件夹下的jobmanager.sh脚本，因为是本地模式，所以输入参数是local。其中taskmanager的启动时嵌入在同一个jvm中，后面会做解析。

而start-cluster集群模式下的运行就较为复杂





start-cluster.sh代码片段

在这里不会对Zookeeper下的高可用模式进行介绍，只介绍普通集群模式，所以直接参考else后面的语句，同样是运行jobmanager脚本，只是第二个命令行参数变成了cluster。所以接下来去看jobmanager.sh。jobmanager.sh在对入参进行了一系列判断之后，会到以下代码块。





jobmanager.sh代码片段



不管是前台运行还是后台运行，都会调用flink-daemon.sh脚本，下面就是启动脚本的核心。





flink-daemon.sh代码片段判断部分

在flink中，他会根据先前运行的脚本调用daemon脚本，所以需要运行的可能不只是jobmanager，在这儿因为我们是从jobmanager.sh中进入daemon，所以需要运行的class是org.apache.flink.runtime.jobmanaer.JobManager，所以我们看源码的入口也就在这个类。

以下是启动jvm将该类作为主程序的运行，其中很多事jvm的启动参数，不做细讲。





flink-daemon.sh代码片段运行部分

总结
至此，flink的local与cluster启动脚本应该已经比较清晰，如果想开始阅读源码的话就从org.apache.flink.runtime.jobmanaer.JobManager这个类开始看起。因为flink中基于akka的部分大部分是使用scala实现，所以建议可以先去看scala文档，或者runoob.com的scala入门教程，后续还可以研读Scala In Depth这本书。


============
Apache Flink 源码解析（二）系统架构, 启动与注册
2018.10.14 09:44 447浏览
概述
这篇文章侧重于分析JobManager和TaskManager的启动过程以及注册，还有Flink的implementation中所用到的设计模式。本文从本地与standalone模式进行解析。

Akka 简介
因为组件之间的信息传递是通过Akka工具包，所以在这儿我做一个简单的解释

首先参考Akka官方文档给出的一个抽象的图





image

如图就是对ActorSystem的一个高度抽象，所有的Actor成树状，user actor的子孙就是用户创建的Actor，system下面是Akka的监管与支持的Actor，往往不需要用户过多参与

Actor之间如果持有对方的ActorRef则可以向对方发送消息

父Actor负责监管子Actor抛出的异常能被父Actor处理，则父Actor可以重启或者废弃它，如果不能处理，会继续向上抛异常。一个Actor如果推出，那么它的所有子Actor都会退出。

它们共同组成了一个ActorSystem

Flink的架构
首先上一张从Flink官方文档拿来的架构图





process-model.png

这次我会从JobManager和TaskManager着手来解析Flink的启动过程

Flink中JobManager与TaskManager，JobManager与Client的交互是基于Akka工具包的，是通过消息驱动，这样就把中心放到了消息的接收，发送与处理，而且由于对每个Akka中的Actor来说，消息是同步的，排在一个队列中，极大地简化了多线程程序设计的复杂度，关于Akka的一些学习资料我会放在文章最后

下面的启动过程我会分为入口，ActorSystem的创建，JobManager的启动，TaskManager的启动和注册这几块来讲

入口
ActorSystem创建
JobManager
TaskManager
TaskManager的注册
AcknowledgeRegistration注册成功，如果isConnected为true则是已连接，判断该消息是否由当前链接的JobManager发送并写入日志，如果未连接，调用associateWithJobManager进行接收消息钱的准备工作（后续会深入解析）





ackRegistration.png

AlreadyRegistered重复注册，写入日志，逻辑与 AcknowledgeRegistration消息的处理相同

RefuseRegistration注册失败，如果JobManager地址存在，则发送新的TriggerTaskManagerRegistration， 重复到TaskManager注册部分的福州，如果没有地址，则验证如果发送消息的JobManager是否是当前已连接的JobManager写入日志，对结果没有影响

根据消息找到相应的TaskManager地址

一旦JobManager接收到RegisterTaskManager消息，先想ResourceManager注册（这边不做介绍，这边的？是Akka里面发送ask消息并期望得到一个返回值），如果Resource注册失败则向发送ReconnectResourceManager消息进行重试

如果该TaskManager已经注册在instanceManager中，则发送AlreadyRegistered消息给相应的TaskManager

如果还未注册，则向instanceManager注册该TaskManager，并发送AcknowledgeRegistration给相应的TaskManager

出现异常则拒绝注册，发送RefuseRegistration消息

在handleJobManagerLeaderAddress中触发了triggerTaskManagerRegistration注册函数

在该函数中，提取超时信息设置，以及当前尝试的ID，清空已经在调度器中应该被废弃的注册消息，并向自身发送尝试次数为第一次的TriggerTaskManagerRegistration消息





triggerTaskManagerRegistration.png

因为TriggerTaskManagerRegistration是在TaskManager Actor接收到RegistrationMessage的子类，所以在接收到该消息时，根据RegistrationMessage来匹配，并调用handleRegistrationMessage方法





handleRegistrationMessage.png

匹配到TriggerTaskManagerRegistration消息后，先判断该消息有没有失效，如果没有，则有三种情况





handleTriggerTaskManagerRegistration.png

如果已连接成功，写入日志

如果超时，写入日志并推出

除此之外，进行下一次尝试，向JobManager Actor发送RegisterTaskManager消息，并在调度其中注册下一次TriggerTaskManagerRegistration的消息的发送，知道出现第一种情况注册成功或第二种情况注册失败为止

在TaskManager的注册中，设计了与JobManager的消息交互，所以单独分开来讲

TaskManager中的发送注册请求

JobManager接收到注册请求消息





handleRegisterTaskManager.png

TaskManager接到返回消息





TaskManager Actor一旦接收到该Message要不就是刚启动，要不就是JobManager的Leader发生了改变，调用handleJobManagerLeaderAddress函数



handleGrantLeadershipMessage.png

在handleJobManagerLeaderAddress函数中，先断开连接，然后出发TaskManager的注册操作





handleJobManagerLeaderAddressMessage.png

首先启动leaderRetrievalService，和LeaderElection一样使用了策略模式来处理是否高可用两种情况，观察者模式来接收对象变化并调用callback方法





startLeaderRetrievalService.png

这边同样关注Standalone版本的Implementation，在start中调用TaskManager的notifyLeaderAddress回调方法，并将jobManager地址作为参数传入





ldeaderRetrievalServiceStart.png

在TaskManager实现的notifyLeaderAddress方法中发送JobManagerLeaderAddress消息给自己





notifyLeaderAddress.png

如果为本地模式，则直接调用startTaskManagerComponentAndActor方法，如果是用脚本启动，则会进入TaskManager的main函数

对于standalone模式

在startTaskManagerComponentsAndActor创建ioManager，network，leaderRetrievalService等创建TaskManager所需要的参数，通过actorSystem来创建TaskManager Actor





createTaskManager.png

在main函数中解析完命令行参数并生成配置文件对象后，会生成resourceID作为身份





resourceIDGenerate.png

接下来会新建一个Callable对象并调用selectNetworkInterfaceAndRunTaskManager方法





selectNetworkAndRunTaskManager.png

在selectNetworkInterfaceAndRunTaskManager方法中，先绑定地址与端口号，建立远程ActorSystem，然后调用runTaskManager方法





runTaskManager1.png

在runTaskManager方法中通过调用startTaskManagerComponentsAndActor并传入远程ActorSystem，至此与local模式的启动一致，区别在于ActorSystem是与JobManager一致还是远程另外一个ActorSystem，但对于开发者来说对Actor之间的消息传递方法并没有任何区别





startTaskManagerComponentsAndActorRemote.png

TaskManager Actor创建

prestart

handleMessage（启动相关）

根据消息的类型进行匹配，当接收到GrantLeadership的Message后，会匹配到如下代码





handleGrantLeadershipMessage.png



首先确认身份，再判断是否为高可用模式，如果是高可用模式还需要发送恢复任务的消息，如果不是，JobManager的启动已完成

启动leaderElectionService，将JobManager本身作为参数传入





startLeaderElectionService.png



这边值得一提的是设计模式，策略模式与观察者模式，因为leaderElectionService是一个Java的接口，在生产环境中有非高可用（单点失败）的Implementation与基于Zookeeper的高可用模式，可以再运行时更改该接口的行为。JobManager还实现了LeaderContender接口，实现了多个CallBack方法，当leaderElectionService被修改时，会通知JobManager来调整，典型的观察者模式，适用于在高可用模式下作为Leader的JobManager被更改的情况。

接着是启动SubmittedJobGraph服务，失败恢复服务与Metrics，这些会在以后讲到

在这儿调用了leaderElectionService，对高可用模式的解析可能会在以后补上，现在侧重于Standalone模式下的解析，在StandaloneLeaderElectionService中，因为只有一个JobManager，所以直接在start时调用LeaderContentder中的callback方法，也就是JobManager的grantLeadership方法





grantLeadership Method.png

在该方法中向JobManager Actor本身发送了一条消息，从而在handleMessage中进行接收处理（！在Scala的Akka包中是发送消息的方法）

对于JobManager与TaskManager的启动与关闭，会有三个环节，preStart，handleMessage与postStop

对于每一个Actor，必须Override抽象方法handleMessage，也就是Actor针对收到的message做的业务逻辑，可以选择Override preStart和postStop方法，做一些启动前准备与结束时的清理

（关于Scala的多重继承，以及菱形继承的问题我这边不做过多讨论，网上有一些帖子，也可以通过阅读Scala In Depth来获得更深入了解，这对Java程序员来说是一个新的概念）

首先是启动前准备preStart

handleMessage（启动相关）





在这里Flink做了一个Akka的工具类来简化逻辑，本质上就是从Configuration配置文件类中提取Akka启动所需配置信息，并根据配置建立ActorSystem，ActorSystem可以是本机的，也可以是跨多台机器的，具体逻辑都在AkkaUtils中，有兴趣可以研究



startJobManagerSystem.png

建立JobManager的可视化WebMonitor，这里不做介绍

重点出现，在这里通过ActorSystem建立了JobManager的Actor，并建立了一个JobManager process reaper来做简单的失败检测





createJobManager.png

（*）如果实在Local模式下的话，则启动一个内嵌的TaskManager，如果不是，则需要在另一个JVM中启动TaskManager，通过taskmanager.sh脚本来完成





localTaskManager.png

针对每一个TaskManager Actor再启动一个WebMonitor可视化界面

如果看过该系列上一篇文章，应该知道怎么找到在Local和Standalone模式下程序的入口

这里我直接给出来，就是org.apache.flink.runtime.jobmanager 中的main方法

main方法主要可以分为，一是启动环境的准备





JobManager Startup.png

二是处理输入的命令行参数，并准备好包含配置信息的Configuration对象，以及host地址与端口号，还有运行模式





configuration prepare.png

三是新建一个Callable对象，在另一个线程上运行runJobManager方法





mainRunJobManager.png

runJobManager有 个重载方法，第一个方法中绑定了端口号并建立了socket链接，并调用第二个重载方法





bindport.png

第二个重载方法根据本机硬件情况建立futureExecutor（对Future类不了解的话可以简单理解成Java中带返回值的Runnable，细节不做讨论）， ioExecutor，并调用startActorSystemAndJobManagerActors方法建立ActorSystem并等待结束





startActorSystem.png

总结
至此，JobManager和TaskManager的启动过程以及TaskManager的注册过程解析已经完成。解析中没有办法做到面面俱到，把自己觉得重要的点挑了出来，主要是能再时间上形成一个线，方便理解。
下面还有一个根据时间线来做的思维导图，侧重于Local模式下的启动，虚线代表调用或者是消息。





Flink start up.jpg

============
Apache Flink源码解析 （三）Flink On Yarn (1) YarnSessionClusterEntrypoint
2018.10.14 09:43 493浏览
杂谈
有一段时间没有写技术博客了，正好之前花了一周的时间解决了一个Flink在Yarn上部署的问题，也将Flink在Yarn上运行的机制与源码了解了个大概。Flink在Yarn上部署涉及到的东西比较多，肯定不会一次写完，我应该会分几篇文章按几个模块来详细阐述，这样看起来也会比较轻松一些，而版本是基于Flink刚发布的release-1.5.0。

概述
Flink在Yarn上有两种模式，一种是cluster模式，即像Yarn申请一定量的资源，有点类似于Standalone模式，当然我觉得缺点应该很明显（这里我也不是很肯定，因为我使用的不是这种模式），就是资源的浪费，以及扩容的时候需要重启，影响业务。另一种是Single Job模式，即将一个单独的Job提交到Yarn集群，由Yarn来根据配置分配Container。在使用这个模式的时候踩了一些坑，以后有机会细讲。

在这篇文章中我假定大家对Yarn已经有了一定的认识，不会在Yarn的概念上进行展开描述。

ApplicationMaster
首先是JobManager和ApplicationMaster。在Flink on Yarn中，JobManager和ApplicationMaster是在同一个jvm进程中的，这个进程的入口就是YarnSessionClusterEntrypoint类。首先来看一下这个类，它继承了SessionClusterEntrypoint类。





YarnSessionClusterEntrypointUML



SessionClusterEntrypoint是一个抽象类，它又继承了ClusterEntrypoint这个抽象类。

那么这三个类到底是干什么的呢？首先是ClusterEntrypoint，它封装了Cluster启停的逻辑，还有根据配置文件来创建RpcService，HaService, HeartbeatService, MetricRegistry等等服务的逻辑，同时它也提供了几个抽象方法给不同的模式下的特定的ClusterEntrypoint来实现。这四个方法分别是createDispatcher，createResourceManager， createRestEndpoint，createSerializableExecutionGraphStore。关于Dispatcher，ResourceManager和SerializableExecutionGraphStore，后面会有单独的文章来详细讲述，现在可以顾名思义，根据它的名字大致就能知道它们提供了怎样的功能。

而SessionClusterEntrypoint继承了这个类，并且实现了部分方法createSerializableExecutionGraphStore，createRestEndpoint，createDispatcher。为什么没有实现createResourceManager方法呢？从SessionClusterEntrypoint的子类就可以看出来，分别是YarnSessionClusterEntrypoint，MesosSessionClusterEntrypoint，StandaloneSessionClusterEntrypoint，这三者都是跟如何去调度资源相关的，所以createResourceManager由这些子类来实现。

这里我只会分析YarnSessionClusterEntrypoint。在这个类中，除了提供启动的main函数以外，最重要的是实现createResourceManager方法，在这个方法中，直接实例化了一个YarnResourceManager的对象并返回。

YarnSessionClusterEntrypoint启动流程
下面来看一下YarnSessionClusterEntrypoint的启动流程。首先入口是main函数，在main函数中新建了YarnSessionClusterEntrypoint的一个对象。





main method of YarnSessionClusterEntrypoint

构造这个对象的构造参数是配置信息和目录。紧接着就调用了startCluster方法。之前也提到，Cluster的启停逻辑是在父类ClusterEntrypoint中。至此，YarnSessionClusterEntrypoint的最重要的任务已经完成。





startCluster method of ClusterEntrypoint



在startCluster方法中，异步的调用了runCluster方法。



runCluster method of ClusterEntrypoint

在runCluster函数中，主要做了三件事：

第一件事是根据配置文件初始化RpcService，HaService, HeartbeatService, MetricRegistry，BlobServer，ResourceManager，SerializableExecutionGraphStore等模块，并将它们赋值给ClusterEntrypoint中相应的instance variables。其中createSerializableExecutionGraphStore，createRestEndpoint，createDispatcher的逻辑由SessionClusterEntrypoint实现，createResourceManager的逻辑由YarnSessionClusterEntrypoint实现。

第二件事就是在startClusterComponents函数中启动这些服务.其中RpcService负责各个模块之间的rpc调用，本质上是基于Akka的（关于Akka我在之前的文章中概述过）。ResourceManager主要是负责与Yarn的ResourceManager进行交互，通过Yarn提供的AMRMAsyncClient，进行一些资源分配与释放的操作。HaService的任务主要有ResourceManager，JobManager，Dispatcher，WebMonitor的Leader选举，checkpoint的元数据的持久化以及checkpoint的注册与跟踪，Blob数据的持久化，任务的状态监控，总而言之就是服务高可用相关的功能。HeartbeatService是负责心跳的发送与接收，被多个模块用来监控其他节点是否丢失。MetricRegistry负责指标的监控。BlobServer负责处理对Blob数据的请求与返回。而SerializableExecutionGraphStore则负责储存序列化之后的执行计划。

最后一件事就是就是启动Dispatcher, Dispatcher主要负责就收Client提交的任务，启动并将任务传递给JobManager，以及Master节点挂掉的失败恢复。
*对于上述提到的各个模块，以后会有文章单独的去剖析。

总结
综上，YarnSessionClusterEntrypoint可以理解为Flink在Yarn上的ApplicationMaster，同时也是JobManager。它们之间分属两个线程，之间的交互通过Akka的消息驱动的模式来实现任务调度与资源分配的分离，而对应的JobManager与ResourceManager也有相应的子模块组成。
============
Apache Flink源码解析 （四）Stream Operator
2018.11.24 12:26 584浏览
概述
以Flink算子的视角为入口，解析它们是如何设计和工作的。

重点在AbstractStreamOperator

实现StreamOperator的接口和抽象类
首先是StreamOperator接口，方法1-4是生命周期相关的。方法5-6是容错与状态相关的，方法7-8是负责从StreamRecord中获取Key的信息的，应用需要shuffle的算子中。方法9-10是与flink的Operator Chaining 优化相关设置。方法11是跟监控相关。除此之外，StreamOperator还继承了CheckpointListener接口（notifyCheckpointComplete方法，checkpoint结束之后的回调方法），KeyContext接口（key的getter setter方法）。



StreamOperator

继承了StreamOperator的扩展接口则有OneInputStreamOperator，TwoInputStreamOperator（这两个接口基本上能做到顾名思义）。
实现了StreamOperator的抽象类有AbstractStreamOperator以及它的子类AbstractStreamUdfOperator。



StreamOperator

OneInputStreamOperator与TwoInputStreamOperator接口
这两个接口非常类似，本质上就是处理流上存在的三种元素StreamRecord，Watermark和LatencyMarker。一个用作单流输入，一个用作双流输入。除了StreamSource以外的所有Stream算子都必须实现并且只能实现其中一个接口。



OneInputStreamOperator



TwoInputStreamOperator

AbstractStreamOperator
AbstractStreamOperator抽象类
AbstractStreamOperator实现类（没有继承AbstractUdfStreamOperator）

  public void processElement(StreamRecord<IN> element) throws Exception {      for (int i = 0; i < this.numFields; i++) {
          outTuple.setField(((Tuple) element.getValue()).getField(fields[i]), i);
      }
      output.collect(element.replace(outTuple));
  }
StreamProject实现了投影的功能，覆盖了了open方法，创建了一个输出Tuple的实例，processElement方法中将需要的field从输入Tuple中提取出来加入输出Tuple，将StreamRecord中的元素替换成输出Tuple，通过AbstractStreamOperator中定义的output发送到下游。

最后，虽然没有实现OneInputStreamOperator或TwoInputStreamOperator接口，但是对processWatermark和ProcessLatencyMarker的方法都做了实现。启动对watermark的处理是通过InternalTimeServiceManager，具体不作展开。

两个setKeyConextElement方法，借助对应的成员变量stateKeySelector将Key从StreamRecord里面提取出来. 这两个方法的调用链为processInput(StreamInputProcessor || StreamTwoInputProcessor) -> streamOperator.setKeyContextElement1. 值得注意的是，在这个方法调用后紧跟着的就是processElement方法。所以这个方法的作用就是在处理Record之前将stateBackend切换到相应的Key的状态。

snapshotState的简化的调用链是triggerCheckpoint(CheckpointCoordinater) -> triggerCheckpoint(Execution) -(AkkaMsg: TriggerCheckpoint)-> (triggerCheckpointBarrier)TaskManager->checkpointStreamOperator(StreamTask) -> snapshotState，从这条链路可以看到checkpoint是由Master节点发起，通过akka触发TaskManager对所有StreamTask做checkpoint，然后最后由算子执行snapshot，在这一层将TimerService做备份，防止触发器丢失，并且调用operatorStateBackend和keyedStateBackend的snapshot方法将stateBackend的备份到用户指定的文件系统。

initializeState是空方法，留给子类去覆盖，作用是从checkpoint中恢复状态。

getPartitionedState（无namespace）方法创建了一个partitioned state的句柄，使得聚合类的方法可以操作状态，并且这些状态会在snapshotState被调用的时候被checkpoint(AbstractKeyedStateBackend的注释里提到)。在该方法中，调用了重载方法（参数有namespace和相应Serializer）并且传入VoidNamespace相应参数。

getOrCreateKeyedState，该方法会被WindowOperator调用，由于同一个key不同的window会对应不同的值，所以每个Window就是一个namespace，在处理具体Element前不仅要切换Key，还要切换namespace。本质上与上一个方法的区别就在于取得的state是否有namespace。

notifyCheckpointComplete方法调用了keyStateBackend的同名方法，通知其执行checkpoint完成之后的逻辑。

之后是状态与容错相关的方法

setup的调用链是invoke(StreamTask) -> constructor(OperatorChain) -> setup。在调用setup方法时，StreamTask已经在各个TaskManager节点上，StreamTask在启动是会创建OperatorChain，OperatorChain会一一调用所包含的算子的setup方法。而在setup方法中，通过StreamTask的Environment和UserCodeClassLoader将上述的大部分成员变量进行初始化。

open和close方法是空方法，由继承的类实现

dispose方法是算子生命周期的最后一环，当StreamTask被取消或者出现异常时调用，负责释放与operator状态相关的资源。

首先是算子生命周期相关的方法：

在AbstractStreamOperator实现的方法中，有一部分是上述变量的getter， setter，还有就是对StreamOperator的实现。

配置相关的成员变量有chainingStrategy，决定了能否在生成JobGraph时对算子进行Chaining优化。

状态相关的成员变量：对于stateKeySelector1， stateKeySelector2这两个变量，它们是用于将Key从StreamRecord中提取出来，keySelector是否为null取决于这个算子有几个流有key。keyedStateBackend就是用户指定的state backend，是将状态放在Heap里还是RocksDB里。keyedStateStore是在state backend上做一层抽象，使其能通过StateDescriptor直接获取State。operatorStateBackend是算子相关的状态。

运行时相关的成员变量有container，该算子在运行时所属的StreamTask，以及任务配置信息StreamConfig，算子的输出句柄output，还有运行的上下文runtimeContext。

时间相关的成员变量有timeServiceManager，提供了定时触发的服务，在状态清理上有很重要的作用。

监控相关的成员变量有metrics，注册的一些关于算子的监控信息，还有latencyStats，通过LatencyMarker来获取延时信息。

在AbstractStreamOperator中有一些重要的成员变量，总体来说可以分为几类，一类是运行时相关的，一类是状态相关的，一类是配置相关的，一类是时间相关的，还有一类是监控相关的。

AbstractUdfStreamOperator抽象类
OneInputStreamOperator

  ValueStateDescriptor<IN> stateId = new ValueStateDescriptor<>(STATE_NAME, serializer);
  values = getPartitionedState(stateId);
其中ProcessOperator对ProcessFunction的实现是只支持获取currentProcessingTime和wartermark，不支持Timer的注册。

LegacyKeyedProcessOperator对ProcessFunction的实现是支持Timer的注册的。同时它实现了Triggerable接口中的onEventTime和onProcessingTime方法，这两个方法是由InternalTimerService调用的回调方法，在这两个方法中，会去调用用户在ProcessFunction中实现的onTimer方法来实现定时触发的。LegacyKeyedProcessOperator现在被标记为Deprecated，由KeyedProcessOperator类替代，但是由于很多Function是基于ProcessFunction实现的，而KeyedProcessFunction在1.5.2中还没有什么实现类，所以还是会经常被用到。

KeyedProcessOperator实现与LegacyKeyedProcessOperator非常类似，不过UDF是KeyedProcessFunction。

ProcessOperator， LegacyKeyedProcessOperator提供了对ProcessFunction的支持, KeyedProcessOperator提供了对KeyedProcessFunction的支持。ProcessFunction是比较灵活的UDF，允许用户通过在processElement的时候可以通过传入的Conext（这个Conext是由算子实现的）操作TimerService，注册ProcessingTimeTimer和EventTimeTimer，并且通过实现方法onTimer就可以在Timer被触发的时候执行回调的逻辑。

StreamSink除了在processElement方法中调用SinkFunction方法外，还提供了SimpleContext，可以获取processingTime，watermark和element的时间戳。

GenericWriteAheadSink提供了一个可以被实现为Exactly once的sink的抽象类，这边不展开研究。

AsyncWaitOperator提供了异步处理的能力，是一个比较特殊的算子，对元素的处理和备份恢复都比较特殊。element的输出通过一个Emitter对象来实现。有机会单独针对这个算子写一篇文章。

TimestampsAndPeriodicWatermarksOperator与TimestampsAndPunctuatedWatermarksOperator通过TimestampAssigner提取timestamp并生按照规则生成watermark。

windowOperator可能是flink实现的最复杂的operator，可以参考vinoyang的Flink流处理之窗口算子分析。后续也有可能针对这个operator写一篇解析。

StreamFilter，StreamMap与StreamFlatMap算子在实现的processElement分别调用传入的FilterFunction，MapFunction， FlatMapFunction的udf将element传到下游。其中StreamFlatMap用到了TimestampedCollector，它是output的一层封装，将timestamp加入到StreamRecord中发送到下游。

StreamGroupedReduce与StreamGroupedFold算子相似的点是都涉及到了操作状态, 所以在覆盖open方法时通过创建一个状态的描述符以及调用AbstractStreamOperator实现的getPartitionedState方法获取了一个stateBackend的操作句柄。在processElement方法中借助这个句柄获取当前状态值，在用UDF将新的元素聚合进去并更新状态值，最后输出到下游。不同的是Fold的输出类型可能不一样（所以实现了OutputTypeConfigurable接口的setOutputType方法），并且有初始值。

TwoInputStreamOperator的实现类相对较少，作用于双流的各种操作。

此外它还实现了ProcessJoinFunction的Conext抽象类，提供了获取左右两个流元素timestamp的功能。关于BufferEntry的实现这里略过。



TwoInputStreamOperatorChildren.jpg

CoStreamMap， CoStreamFlatMap基本与单流的逻辑没什么区别，只是针对两个流的Function做类似的处理。

IntervalJoinOperator对双流的元素根据提供的ProcessJoinFunction做内连接，并且每个元素都有失效时间。在processElement方法中，每当一个流的元素到达，会将它加入对应流的buffer，并且遍历另一个流的buffer找到所有join的选项。最后再根据失效时间注册一个状态清理的Timer防止buffer无限增长。

CoProcessOperator和KeyedCoProcessOperator本质上与单流的处理也没有什么区别，但是提供了双流之间共享状态的可能。CoProcessOperator也被用来实现NonWindowJoin。

CoBroadcastWithKeyedOperator和CoBroadcastWithNonKeyedOperator提供了对(Keyed)BroadcastProcessFunction的支持，和CoProcess有一些类似，只是Broadcast的Stream只有读权限，没有写权限。并且可以通过context直接获得BroadcastState。

StreamSource因为没有输入，所以没有实现InputStreamOperator的接口。比较特殊的是ChainingStrategy初始化为HEAD。在运行时由SourceStreamTask调用run方法。在run方法中，他首先出事话LatencyMarksEmitter用来产生延迟监控的LatencyMarker，接着根据用户选择的时间模式（EventTime，IngestionTime和ProcessingTime）来生成相应的SourceConext（包含了产生element关联的timestamp的方法和生成watermark的方法）。最后调用SourceFunction的run方法来启动source。

AbstractStreamOperator实现类

还是算子生命周期相关的方法：首先调用了前文提到的AbstractStreamOperator相应方法，然后为userFunction提供runtimeContext，Configuration，并且调用function的open和close方法。

状态和checkpoint相关的方法： 首先调用父类相应方法，完成算子状态的别分与恢复，然后调用实现了Checkpoint相关的接口的userFunction的相关方法。

AbstractUdfStreamOperator继承了AbstractStreamOperator，对其部分方法做了增强，多了一个成员变量UserFunction，并提供get方法。此外还实现了OutputTypeConfigurable接口的setOutputType方法对输出数据的类型做了设置。

总结
本文从StreamOperator接口开始一层一层往上解析，重点关注了AbstractStreamOperator和AbstractUdfStreamOperator这两个抽象类，覆盖了大部分的算子的功能与设计。

了解算子如何工作可以对运行的任务有更深的了解，借助AbstractUdfStreamOperator，也可以较低成本的定制出特殊的算子。
===============
Apache Flink源码解析 （五）DataStream API
2018.10.14 09:41 704浏览
概述
这篇文章是但不仅仅是官方文档的中文翻译，还有里面每一个方法对应的Transformation和运行时对Task的影响。

Prerequisites
关于算子想说的有很多，在这篇文章中，把算子理解为包含了一个函数（Flink实现的或自己实现的，比如MapFunction，FilterFunction）的持续获得输入并且将结果输出出去的任务就好。

图中的Task表示一个节点，或者说是一个TaskManager中一个Slot执行的任务

流程图中红色代表这个方法在生成Transformation和实际运行时对Task产生的影响

DataStream
Map
DataStream<Integer> dataStream = //...dataStream.map(new MapFunction<Integer, Integer>() {    @Override
    public Integer map(Integer value) throws Exception {        return 2 * value;
    }
});
Transformation: 生成一个OneInputTransformation并包含StreamMap算子





StreamMapTransformation

Runtime:





StreamMapTask

消费一个元素并产出一个元素

参数 MapFunction

返回DataStream

例子：

FlatMap
dataStream.flatMap(new FlatMapFunction<String, String>() {
    @Override
    public void flatMap(String value, Collector<String> out)
        throws Exception {        for(String word: value.split(" ")){
            out.collect(word);
        }
    }
});
Transformation: 生成一个OneInputTransformation并包含StreamFlatMap算子





StreamFlatMapTransformation

Runtime：





StreamFlatMapTask

消费一个元素并产生零到多个元素

参数 FlatMapFunction

返回 DataStream

例子：

Filter
dataStream.filter(new FilterFunction<Integer>() {    @Override
    public boolean filter(Integer value) throws Exception {        return value != 0;
    }
});
Transformation：生成一个OneInputTransformation并包含StreamFilter算子





StreamFilterTransformation

Runtime：





StreamFilterTask

根据FliterFunction返回的布尔值来判断是否保留元素，true为保留，false则丢弃

参数 FilterFunction

返回DataStream

例子：

KeyBy
dataStream.keyBy("someKey") // Key by field "someKey"dataStream.keyBy(0) // Key by the first element of a Tuple
Transformation: KeyBy会产生一个PartitionTransformation，并且通过KeySelector创建一个KeyGroupStreamPartitioner，目的是将输出的数据分区。此外还会把KeySelector保存到KeyedStream的属性中，在下一个Transformation创建时时将KeySelector注入进去。





KeyByTransformation

Runtime: 生成StreamGraph时会将PartitionTransformation中的Partitioner 注入到StreamEdge当中，此外还会在下一个StreamNode创建过程中注入KeySelector用于提取元素的Key。之后将Partitioner注入StreamRecordWriter中用于将上一个Task的输出元素指定到某一个ResultSubParition中，此外KeySelector也被注入到下一个Task的算子当中。





KeyBy Runtime

根据指定的Key将元素发送到不同的分区，相同的Key会被分到一个分区（这里分区指的就是下游算子多个并行的节点的其中一个）。keyBy()是通过哈希来分区的。

只能使用KeyedState（Flink做备份和容错的状态）

参数 String，tuple的索引，覆盖了hashCode方法的POJO，不能使数组

返回KeyedStream

例子：

WindowAll
dataStream.windowAll(TumblingEventTimeWindows.of(Time.seconds(5))); // Last 5 seconds of data
Transformation：返回AllWindowedStream，不产生Transformation，详情见AllWindowedStream

Runtime：详情见AllWindowedStream

将元素按照某种特性聚集在一起（如时间：滑动窗口，翻转窗口，会话窗口，又如出现次数：计数窗口）

参数 WindowAssigner

返回 AllWindowedStream

例子：

Union
dataStream.union(otherStream1, otherStream2, ...);
Transformation: 从所有相关的stream中获取Transformation并注入到UnionTransformation的inputs中





UnionTransformation

Runtime：这些Inputs会在下一个Transformation创建时被作为Input来穿件StreamEdge，如果上下游并行度一致则会生成ForwardPartitioner，不一致则是RebalancePartitioner。由于Partitioner是在处理下游Transformation生成的，所以这里没有图。

将两个或多个datastream合并，创造一个新的流包含这些datastream的所有元素

参数DataStream（一个或多个）

返回UnionStream

例子：

Join
dataStream.join(otherStream)
    .where(<key selector>).equalTo(<key selector>)
    .window(TumblingEventTimeWindows.of(Time.seconds(3)))
    .apply (new JoinFunction () {...});
Transformation：1. 调用join方法后生成JoinedStream，JoinedStream保存了两个input  2. 调用where方法生成一个内部类Where对象，注入KeySelector1 3. 调用equalTo生成内部类EqualTo对象，注入KeySelector2 4. 调用window升成内部静态类WithWindow，并且注入WindowAssigner（在该对象中还可以注入Trigger和Evictor 5. 最后调用apply方法将（Flat)JoinFunction注入并且用一个(Flat)JoinCoGroupFunction封装起来，而在这一步会将所有注入的对象用在coGroup上。详情见下一个Window CoGroup的解析。

Runtime： 与Window CoGroup相同，详情见下一个WIndow CoGroup解析

将两个DataStream按照key和window join在一起

参数：1. KeySelector1 2. KeySelector2 3. DataStream 4. WindowAssigner 5. JoinFunction/FlatJoinFunction

返回DataStream

例子：

Window CoGroup
dataStream.coGroup(otherStream)
    .where(0).equalTo(1)
    .window(TumblingEventTimeWindows.of(Time.seconds(3)))
    .apply (new CoGroupFunction () {...});
Transformation：生成一个TaggedUnion类型和unionKeySelector，里面分别包含了两个流的元素类型和两个流的KeySelector。将两个流通过map分别输出为类型是TaggedUnion的两个流（map详情见StreamMap），再Union在一起（详情见Union），再使用合并过后的流和unionKeySelector生成一个KeyedStream（详情见KeyBy），最后使用KeyedStream的window方法并传入WindowAssigner生成WindowedStream，并apply CoGroupFunction来处理（详情见WindowedStream Apply方法）。总体来说，Flink对这个方法做了很多内部的转换，最后生成了两个StreamMapTransformation，一个PartitionTransformation和一个包含了WindowOperator的OneInputTransformation。





CoGroupTransformation

Runtime：参考每个Transformation对应的Runtime情况

根据Key和window将两个DataStream的元素聚集在两个集合中，根据CoGroupFunction来处理这两个集合，并产出结果

参数 1. DataStream 2. KeySelector1 3. KeySelector2 4. WindowAssigner 5. CoGroupFunction

返回DataStream

例子：

Connect
DataStream<Integer> someStream = //...DataStream<String> otherStream = //...ConnectedStreams<Integer, String> connectedStreams = someStream.connect(otherStream);
Transformation：在这一步会生成一个包含了两个DataStream的ConnectedStreams对象，不会有Transformation产生。详情见后续ConnectedStreams的API详解。

将两个DataStream连接在一起，使得他们之间可以共享状态

参数 DataStream

返回ConnectedStreams

例子：

Split
SplitStream<Integer> split = someDataStream.split(new OutputSelector<Integer>() {    @Override
    public Iterable<String> select(Integer value) {
        List<String> output = new ArrayList<String>();        if (value % 2 == 0) {
            output.add("even");
        }        else {
            output.add("odd");
        }        return output;
    }
});
Transformation：在这一步会生成一个SplitTransformation，里面包含了OutputSelector。





SplitTransformation

Runtime: 在生成StreamGraph时找到父Transformation，并将OutputSelector注入到父StreamNode中。生成JobGraph的时候在注入到对应的JobNode中，最后在运行时封装到OperatorChain的OutputCollector中并且注入算子。





SplitRuntime

按照一个规则将一个流的元素产出到两个或多个支流（每个元素可以发送到不止一个支流）

参数 OutputSelector

返回 SplitStream

例子：

Iterate
IterativeStream<Long> iteration = initialStream.iterate();
DataStream<Long> iterationBody = iteration.map (/*do something*/);
DataStream<Long> feedback = iterationBody.filter(new FilterFunction<Long>(){    @Override
    public boolean filter(Integer value) throws Exception {        return value > 0;
    }
});
iteration.closeWith(feedback);
DataStream<Long> output = iterationBody.filter(new FilterFunction<Long>(){    @Override
    public boolean filter(Integer value) throws Exception {        return value <= 0;
    }
});
Iterate不展开讲解

通过将一个算子的输出重定向到某个输入Operator上来创个一个循环。非常适合用来持续更新一个模型。

过程 DataStream IterativeStream DataStream

例子：

ExtractTimestamps
stream.assignTimestamps (new TimeStampExtractor() {...});
Transformation：assignTimestamps会将TimeStampExtractor注入进刚创建的ExtractTimestampsOperator，再通过ExtractTimestampsOperator生成一个OneInputTransformation





ExtractTimestampsTransformation

Runtime：





ExtractTimestampsTask

从元素中提取timestamp来用作事件时间（EventTime）。

参数 TimeStampExtractor

返回 DataStream

例子：

Project
DataStream<Tuple3<Integer, Double, String>> in = // [...]DataStream<Tuple2<String, Integer>> out = in.project(2,0);
Transformation：生成一个OneInputTransformation并包含StreamProjection算子





StreamProjectionTransformation

Runtime





StreamProjectionTask

如果元素是Tuple，直接通过index提取出Tuple中的字段组成新的Tuple，并产出结果

参数 Tuple中的index（int， 一个或多个）

返回 DataStream

例子：

Custom partitioning
dataStream.partitionCustom(partitioner, "someKey");dataStream.partitionCustom(partitioner, 0);
Transformation：partitionCustom类似于KeyBy，不过partitioner是由自己定制并且输出的不是KeyedStream。首先会通过KeySelector和用户实现的Partitioner生成一个CustomPartitionerWrapper（StreamPartitioner），再讲它注入到PartitionTransformation。





CustomPartitioningTransformation

Runtime：将Partitioner注入StreamRecordWriter中用于将上一个Task的输出元素指定到某一个ResultSubParition中





CustomPartitioningTask

通过用户定义的流分区器（Partitioner）将每个元素传输到指定的subtask

参数 Partitioner， Tuple索引/POJO属性名/KeySelector

返回 DataStream

例子：

Random partitioning
dataStream.shuffle();
Transformation: 将partitioner换成ShufflePartitioner，其余同上

Runtime：同上

将元素按照均匀分布打散到下游

返回 DataStream

例子：

Rebalancing (Round-robin partitioning)
dataStream.rebalance();
Transformation: 将partitioner换成RebalancePartitioner，其余同上

Runtime：同上

通过轮询调度（Round-robin）将元素均匀的分配到下游

返回 DataStream

例子

Rescaling
dataStream.rescale();
Transformation: 将partitioner换成RescalePartitioner，其余同上

Runtime：同上

通过轮询调度将元素从上游的task一个子集发送到下游task的一个子集

返回 DataStream

原理：第一个task并行度为2，第二个task并行度为6，第三个task并行度为2。从第一个task到第二个task，Src的子集Src1 和 Map的子集Map1，2，3对应起来，Src1会以轮询调度的方式分别向Map1，2，3发送记录。从第二个task到第三个task，Map的子集1，2，3对应Sink的子集1，这三个流的元素只会发送到Sink1。
假设我们每个TaskManager有三个Slot，并且我们开了SlotSharingGroup，那么通过rescale，所有的数据传输都在一个TaskManager内，不需要通过网络。



rescale.png

例子

Broadcasting
dataStream.broadcast();
将元素广播到每个分区

返回DataStream

例子：

KeyedStream
Reduce
keyedStream.reduce(new ReduceFunction<Integer>() {    @Override
    public Integer reduce(Integer value1, Integer value2)
    throws Exception {        return value1 + value2;
    }
});
Transformation：生成一个OneInputTransformation并包含StreamGroupedReduce算子





KeyedReduceTransformation

Runtime：





KeyedReduceTask

根据ReduceFunction将元素与上一个reduce后的结果合并，产出合并之后的结果。

参数 ReduceFunction

返回 DataStream

例子：

Fold
DataStream<String> result =
  keyedStream.fold("start", new FoldFunction<Integer, String>() {
    @Override
    public String fold(String current, Integer value) {        return current + "-" + value;
    }
  });
Transformation：将StreamGroupedReduce换成StreamGroupedFold，其余同Reduce

Runtime：将StreamGroupedReduce换成StreamGroupedFold，其余同Reduce

根据FoldFunction和初始值，将元素与上一个fold过后的结果合并，产出合并之后的结果。

参数 FoldFunction

返回 DataStream

例子：

Aggregations
keyedStream.sum(0);keyedStream.sum("key");keyedStream.min(0);keyedStream.min("key");keyedStream.max(0);keyedStream.max("key");keyedStream.minBy(0);keyedStream.minBy("key");keyedStream.maxBy(0);keyedStream.maxBy("key");
Transformation：StreamGroupedReduce里注入了Flink内置的Aggregation方法实现，同Reduce

Transformation：同Reduce

Flink实现的一系列聚合方法，具体作用由方法名就可以得知

返回 DataStream

例子：

Window
dataStream.window(TumblingEventTimeWindows.of(Time.seconds(5))); // Last 5 seconds of data
Transformation: 生成一个WindowedStream，不产生Transformation，详情见WindowedStream详解

Runtime：详情见WindowedStream

窗口将同一个key的元素按照某种特性聚集在一起（如时间：滑动窗口，翻转窗口，会话窗口，又如出现次数：计数窗口）

返回WindowedStream

参数WindowAssigner

例子：

Interval Join
// this will join the two streams so that// key1 == key2 && leftTs - 2 < rightTs < leftTs + 2keyedStream.intervalJoin(otherKeyedStream)
    .between(Time.milliseconds(-2), Time.milliseconds(2)) // lower and upper bound
    .upperBoundExclusive(true) // optional
    .lowerBoundExclusive(true) // optional
    .process(new IntervalJoinFunction() {...});
给定一个时间间隔，将两个流中的元素按照key来做join

满足条件e1.timestamp + lowerBound <= e2.timestamp <= e1.timestamp + upperBound

参数 1. KeyedStream 2. Time: LowerBound and UpperBound 3. boolean(optional) 4. boolean(optional) 5. IntervalJoinFunction

返回DataStream

例子：

WindowedStream
Apply
windowedStream.apply (new WindowFunction<Tuple2<String,Integer>, Integer, Tuple, Window>() {    public void apply (Tuple tuple,
            Window window,
            Iterable<Tuple2<String, Integer>> values,
            Collector<Integer> out) throws Exception {        int sum = 0;        for (value t: values) {
            sum += t.f1;
        }
        out.collect (new Integer(sum));
    }
});
Transformation：





WindowApplyTransformation

Runtime：





WindowApply Task

使用WindowFunction对window重的元素做处理（例如聚合操作）并产出结果

参数 WindowFunction

返回 DataStream

例子：

Reduce
windowedStream.reduce (new ReduceFunction<Tuple2<String,Integer>>() {
    public Tuple2<String, Integer> reduce(Tuple2<String, Integer> value1, Tuple2<String, Integer> value2) throws Exception {        return new Tuple2<String,Integer>(value1.f0, value1.f1 + value2.f1);
    }
});
Transformation：基本同上，将ReduceFunction注入到WindowOperator中（具体注入方式要看有没有evictor，这边不作赘述）。

Runtime：同上

根据ReduceFunction将窗口中的元素按照key和window合并，并产出结果

参数 ReduceFunction

返回DataStream

例子

Aggregations
windowedStream.sum(0);windowedStream.sum("key");windowedStream.min(0);windowedStream.min("key");windowedStream.max(0);windowedStream.max("key");windowedStream.minBy(0);windowedStream.minBy("key");windowedStream.maxBy(0);windowedStream.maxBy("key");
Transformation：WindowOperator里注入了Flink内置的Aggregation方法实现，其余同上

Runtime：同上

Flink实现的一系列聚合方法，具体作用由方法名就可以得知，需要注意的是他们被分别作用在按key和window分割过后的元素集合上

返回 DataStream

例子：

AllWindowedStream
Apply
// applying an AllWindowFunction on non-keyed window streamallWindowedStream.apply (new AllWindowFunction<Tuple2<String,Integer>, Integer, Window>() {    public void apply (Window window,
            Iterable<Tuple2<String, Integer>> values,
            Collector<Integer> out) throws Exception {        int sum = 0;        for (value t: values) {
            sum += t.f1;
        }
        out.collect (new Integer(sum));
    }
});
Transformation：AllWindowedStream.apply()与WindowedStream.apply()基本是一致的，只是没有KeySelector

Runtime：通WindowedStream.apply()

使用WindowFunction对window重的元素做处理（例如聚合操作）并产出结果

与WindowedStream的区别在于是否有key

参数 WindowFunction

返回 DataStream

例子

ConnectedStreams
CoMap, CoFlatMap
connectedStreams.map(new CoMapFunction<Integer, String, Boolean>() {    @Override
    public Boolean map1(Integer value) {        return true;
    }
    @Override
    public Boolean map2(String value) {        return false;
    }
});
connectedStreams.flatMap(new CoFlatMapFunction<Integer, String, String>() {   @Override
   public void flatMap1(Integer value, Collector<String> out) {
       out.collect(value.toString());
   }   @Override
   public void flatMap2(String value, Collector<String> out) {       for (String word: value.split(" ")) {
         out.collect(word);
       }
   }
});
Transformation：ConnectedStream并不会产生Transformation，只会保存两个Input DataStream，从inputs中的DataStream获取父Transformation，并生成一个CoStream(Flat)Map算子。KeySelector依赖于父Transformation注入（如果是PartitionTransformation的话）。





Co(Flat)MapTransformation

Runtime: Task会具体负责调用processElement1方法还是processElement2方法。





CoStream(Flat)MapTask

同时对两个流进行Map或FlatMap操作

参数 CoMapFunction, CoFlatMapFunction

返回 DataStream

例子：

SplitStream
Select
SplitStream<Integer> split;
DataStream<Integer> even = split.select("even");
DataStream<Integer> odd = split.select("odd");
DataStream<Integer> all = split.select("even","odd");
Transformation：生成SelectTransformation，里面包含了OutputSelector





SelectTransformation

Runtime：生成StreamGraph时会将OutputNames注入到新生成的StreamEdge中，然后注入到对应的JobEdge中，最后用它来生成OutputCollector中的outputMap，发送消息时根据相应的selectedName发送到相应的下游Task





Select Runtime

根据SplitStream中OutputSelector设定的规则获取一个或多个DataStream

参数 OutputNames

返回 DataStream

例子：



======================
Apache Flink源码解析 （六）执行计划生成之StreamGraph-上半篇: 通过DataStream API
2018.10.13 11:46 675浏览
概述
根据可以得知每一个方法生成的Transformation和实际运行中对Task的影响。事实上从Transformation到实际运行的Task中间还要经过StreamGraph，JobGraph，ExecutionGraph这三个转换

Prerequisites
DataStream API
下图是不同类型的DataStream之间的转换关系。为了清晰的表达这种转换关系，在每两个流的转换中我选取了比较代表性的方法，此外还有红线表示这层转换对API的使用者是屏蔽的。关于API详细信息还是参考上一篇文章



DataStream

执行计划生成
下图就是官方给出的执行计划的生成过程例图

在执行计划的生成过程中，会经历四个阶段，StreamGraph，JobGraph，ExecutionGraph，Execution。其中在客户端生成的是StreamGraph和JobGraph， 在JobManager中生成的是ExecutionGraph，最后实际运行在各个节点上的这张物理执行图事实上是一个抽象的图。



flink job graphs.jpg

StreamGraph
如上图所示，StreamGraph是执行计划生成的第一张图，它包含两个重要元素，StreamNode和StreamEdge。

StreamGraph的生成发生在用户调用了env.execute() 方法之后，而在这之前，用户编写的应用程序会转换成一个包含了Transformation的集合，关于具体的Transformation接下来就会介绍。接着根据这个Transformation集合来生成相应的StreamNode并且用StreamEdge连接起来形成一张图。

Transformation
迭代型的Transformation不展开讨论
SplitTransformation，SelectTransformation

SideOutputTransformation

UnionTransformation

这两者总是配对使用，SplitTransformation当中有用户注入的OutputSelector来决定数据会被发送到哪几个流中（命名的逻辑流），SelectTransformation中根据用户注入的selectedNames来连接到对应的上游。

包含了用户指定的OutputTag，根据OutputTag连接到指定的下游。

包含了一个输入流的集合，把它们一起连接到指定的下游。

连接型Transformation
PartitionTransformation

Partitioner决定了数据以什么样的方式发送到下游（例如轮询，hash），如果没有ParitionTransformation，那么就会默认使用ForwardPartitioner（类似于Spark中的窄依赖）。

包含Partitioner的Transformation
OneInputTransformation，TwoInputTransformation

SourceTransformation，SinkTransformation

这两者顾名思义，分别包含了OneInputStreamOperator和TwoInputStreamOperator 算子（在StreamOperator 一文当中详细介绍），并且分别对应着一个输入流和两个输入流。

这两者也很容易看出来包含了StreamSource和StreamSink算子。区别在于SourceTransformation没有输入。

包含算子的Transformation
每一个StreamTransformation都包含了一些标识信息（id和name等），还有输出的类型信息以及并行度和资源相关的信息。

我个人将Transformation分为四大类：包含算子的Transformation，包含Partitioner的Transformation，连接型的Transformation，迭代型的Transformation。

StreamNode
就如StreamNode类的注释所说，它表示了一个算子以及它的属性。

下图是StreamNode中的所有属性，最重要的当然是operator，从这里也可以看出最后StreamNode是和包含算子的Transformation一一对应的。

除此之外，还有几个重要的属性是包含算子的Transformation所不具备的，那就是statePartitioner，outputSelectors，inEdges，outEdges。这些属性是如何被注入的就是生成过程中所要讲解的重要部分。



StreamNode fields

StreamEdge
StreamEdge相对来说要简单的多，它起到了连接两个StreamNode的作用。

下图是StreamEdge的所有属性。比较重要的属性有sourceVertex（起点），targetVertex（终点），selectedNames（SelectTransformation当中用户注入的名字集合），outputTag（SideOutputTransformation当中用户指定的OutputTag）， outputPartitioner（默认ForwardPartitioner，可由PartitionTransformation指定）。



StreamEdge fields

生成过程
  @Override
  public JobExecutionResult execute(String jobName) throws ProgramInvocationException {
      StreamGraph streamGraph = getStreamGraph();
      streamGraph.setJobName(jobName);
      transformations.clear();      return executeRemotely(streamGraph, jarFiles);
  }
  public StreamGraph getStreamGraph() {      if (transformations.size() <= 0) {          throw new IllegalStateException("No operators defined in streaming topology. Cannot execute.");
      }      return StreamGraphGenerator.generate(this, transformations);
  }
  private StreamGraph generateInternal(List<StreamTransformation<?>> transformations) {      for (StreamTransformation<?> transformation: transformations) {
          transform(transformation);
      }      return streamGraph;
  }
  private <T> Collection<Integer> transformPartition(PartitionTransformation<T> partition) {
      StreamTransformation<T> input = partition.getInput();
      List<Integer> resultIds = new ArrayList<>();

      Collection<Integer> transformedIds = transform(input);
      for (Integer transformedId: transformedIds) {
          int virtualId = StreamTransformation.getNewNodeId();
          streamGraph.addVirtualPartitionNode(transformedId, virtualId, partition.getPartitioner());
          resultIds.add(virtualId);
      }

      return resultIds;
  }
当所有Transformation被遍历过后，完整的StreamGraph就生成了。

在addEdgeInternal方法中，会递归地处理OutputTag，SelectedNames，Partitioner（如果没有则生成ForwardPartitioner），最后生成StreamEdge，并加入到上游的outEdges和下游的为inEdges集合中。

addEdge。在StreamNode生成之前，会调用所有上游的Transformation的transform方法，相应的Partitioner， SelectedNames，OutputTag都已经在上述的三个Map中。

private void addEdgeInternal(Integer upStreamVertexID,
        Integer downStreamVertexID,        int typeNumber,
        StreamPartitioner<?> partitioner,
        List<String> outputNames,
        OutputTag outputTag) {    if (virtualSideOutputNodes.containsKey(upStreamVertexID)) {        int virtualId = upStreamVertexID;
        upStreamVertexID = virtualSideOutputNodes.get(virtualId).f0;        if (outputTag == null) {
            outputTag = virtualSideOutputNodes.get(virtualId).f1;
        }
        addEdgeInternal(upStreamVertexID, downStreamVertexID, typeNumber, partitioner, null, outputTag);
    } else if (virtualSelectNodes.containsKey(upStreamVertexID)) {        int virtualId = upStreamVertexID;
        upStreamVertexID = virtualSelectNodes.get(virtualId).f0;        if (outputNames.isEmpty()) {            // selections that happen downstream override earlier selections
            outputNames = virtualSelectNodes.get(virtualId).f1;
        }
        addEdgeInternal(upStreamVertexID, downStreamVertexID, typeNumber, partitioner, outputNames, outputTag);
    } else if (virtualPartitionNodes.containsKey(upStreamVertexID)) {        int virtualId = upStreamVertexID;
        upStreamVertexID = virtualPartitionNodes.get(virtualId).f0;        if (partitioner == null) {
            partitioner = virtualPartitionNodes.get(virtualId).f1;
        }
        addEdgeInternal(upStreamVertexID, downStreamVertexID, typeNumber, partitioner, outputNames, outputTag);
    } else {
        StreamNode upstreamNode = getStreamNode(upStreamVertexID);
        StreamNode downstreamNode = getStreamNode(downStreamVertexID);        // If no partitioner was specified and the parallelism of upstream and downstream
        // operator matches use forward partitioning, use rebalance otherwise.
        if (partitioner == null && upstreamNode.getParallelism() == downstreamNode.getParallelism()) {
            partitioner = new ForwardPartitioner<Object>();
        } else if (partitioner == null) {
            partitioner = new RebalancePartitioner<Object>();
        }        if (partitioner instanceof ForwardPartitioner) {            if (upstreamNode.getParallelism() != downstreamNode.getParallelism()) {                throw new UnsupportedOperationException("Forward partitioning does not allow " +                        "change of parallelism. Upstream operation: " + upstreamNode + " parallelism: " + upstreamNode.getParallelism() +                        ", downstream operation: " + downstreamNode + " parallelism: " + downstreamNode.getParallelism() +                        " You must use another partitioning strategy, such as broadcast, rebalance, shuffle or global.");
            }
        }

        StreamEdge edge = new StreamEdge(upstreamNode, downstreamNode, typeNumber, outputNames, partitioner, outputTag);

        getStreamNode(edge.getSourceId()).addOutEdge(edge);
        getStreamNode(edge.getTargetId()).addInEdge(edge);
    }
}
SplitTransformation的transform过程中会获取所有的Input（所有包含StreamOperator的父Transformation Id），将OutputSelector注入到Input的StreamNode中。

SelectTransformation同PartitionTransformation，只是将新建的虚拟节点和（Input, SelectedNames)的映射加入到了叫virtualSelectNodes的Map中

SideOutputTransformation同PartitionTransformation，只是将新建的虚拟节点和(Input，OutputTag）的映射加入到了叫virtualSideOutputNodes的Map中

UnionTransformation则简单的将所有的Input的id的集合返回，为下游节点准备好所有的Input

对于连接型的Transformation

    for (int inputId : resultIds) {
        streamGraph.addOutputSelector(inputId, split.getOutputSelector());
    }
对于transform包含Partitioner的Transformation，首先获取所有的Input（调用tranform input最后只会返回所有包含StreamOperator的父Transformation Id），再将其遍历生成一个虚拟节点并将这个虚拟节点和（Input，partitioner）的映射加入到一个叫virtualPartitionNodes的Map中。

在addOperator中，根据StreamOperator类型调用addNode方法生成相应的StreamNode，并注入相应的输入和输出序列化器（上文中StreamNode中的属性）和输入输出类型。

addNode方法具体执行了生成StreamNode的任务。

除此之外就是将Transformation中包含的信息（如并行度，资源）注入到生成好的StreamNode中。并且对每个input通过addEdge生成StreamEdge（在讲完接下来的Transformation之后会详细讲如何生成StreamEdge）。

就如之前介绍Transformation，先从transform包含算子的Transformation开始。首先递归调用input的transform方法（SourceTransformation除外），之后将算子加入到StreamGraph中，核心方法是addOperator（addCoOperator）, addNode和addEdge。

public <IN, OUT> void addOperator(
        Integer vertexID,
        String slotSharingGroup,
        @Nullable String coLocationGroup,
        StreamOperator<OUT> operatorObject,
        TypeInformation<IN> inTypeInfo,
        TypeInformation<OUT> outTypeInfo,
        String operatorName) {    if (operatorObject instanceof StoppableStreamSource) {
        addNode(vertexID, slotSharingGroup, coLocationGroup, StoppableSourceStreamTask.class, operatorObject, operatorName);
    } else if (operatorObject instanceof StreamSource) {
        addNode(vertexID, slotSharingGroup, coLocationGroup, SourceStreamTask.class, operatorObject, operatorName);
    } else {
        addNode(vertexID, slotSharingGroup, coLocationGroup, OneInputStreamTask.class, operatorObject, operatorName);
    }

    TypeSerializer<IN> inSerializer = inTypeInfo != null && !(inTypeInfo instanceof MissingTypeInfo) ? inTypeInfo.createSerializer(executionConfig) : null;

    TypeSerializer<OUT> outSerializer = outTypeInfo != null && !(outTypeInfo instanceof MissingTypeInfo) ? outTypeInfo.createSerializer(executionConfig) : null;

    setSerializers(vertexID, inSerializer, null, outSerializer);    if (operatorObject instanceof OutputTypeConfigurable && outTypeInfo != null) {        @SuppressWarnings("unchecked")
        OutputTypeConfigurable<OUT> outputTypeConfigurable = (OutputTypeConfigurable<OUT>) operatorObject;        // sets the output type which must be know at StreamGraph creation time
        outputTypeConfigurable.setOutputType(outTypeInfo, executionConfig);
    }    if (operatorObject instanceof InputTypeConfigurable) {
        InputTypeConfigurable inputTypeConfigurable = (InputTypeConfigurable) operatorObject;
        inputTypeConfigurable.setInputType(inTypeInfo, executionConfig);
    }    if (LOG.isDebugEnabled()) {
        LOG.debug("Vertex: {}", vertexID);
    }
}
protected StreamNode addNode(Integer vertexID,
    String slotSharingGroup,
    @Nullable String coLocationGroup,    Class<? extends AbstractInvokable> vertexClass,    StreamOperator<?> operatorObject,    String operatorName) {    if (streamNodes.containsKey(vertexID)) {        throw new RuntimeException("Duplicate vertexID " + vertexID);
    }

    StreamNode vertex = new StreamNode(environment,
        vertexID,
        slotSharingGroup,
        coLocationGroup,
        operatorObject,
        operatorName,        new ArrayList<OutputSelector<?>>(),
        vertexClass);

    streamNodes.put(vertexID, vertex);    return vertex;
}


transform*

在transform方法中，会首先判断是否已经处理过该Transformation来防止重复处理，然后根据Transformation类型去掉用相应的子方法处理，子方法如下图。（迭代在这里不做介绍）

在StreamGraphGenerator中，会遍历Transformation集合并调用transform方法来完成Transformation向StreamGraph的转换。

在getStreamGraph中，会将用户程序生成的Transformation集合作为生成StreamGraph的参数

在用户调用了env.execute() ，会调用StreamExecutionEnvironment中的getStreamGraph方法。

总结
详细讲解了StreamGraph的构建过程，因为有很多的递归调用，所有逻辑相对来说比较复杂。

本文与上两篇文章都有一定的关联性，还详细的讲解了Transformation，概念比较多，不好理解，建议多看两遍。

=============
Apache Flink源码解析 （七）Flink RPC的底层实现
2018.11.16 12:21 382浏览
Prerequisites
Flink的RPC服务是基于Akka Remote实现的。一个简单的Akka Remoting ActorSystem的配置如下:

akka {
  actor {
    provider = remote
  }
  remote {
    enabled-transports = ["akka.remote.netty.tcp"]
    netty.tcp {
      hostname = "127.0.0.1"
      port = 2552
    }
 }
}
从这份配置文件可以看出，要建立一个ActorSystem，首先需要提供ActorSystem运行的机器的地址和端口。

参考Akka Remoting的文档，获取远程节点的Actor有两条途径。

akka {
  actor {
    deployment {
      /sampleActor {
        remote = "akka.tcp://sampleActorSystem@127.0.0.1:2553"
      }
    }
  }
}
第一条，通过actorSelection(path)，在这儿需要知道远程节点的地址。获取到了ActorSelection就已经可以发送消息过去，也可以通过回信获取这个Actor的ActorRef。

第二条，通过配置，配置文件如下。通过这种方式，远程系统的daemon会被请求建立这个Actor，ActorRef可以直接通过system.actorOf(new Props(...)获取。

定义RPC协议
RPC协议是客户端和服务端的通信接口。如下所示定义了一个BaseGateway的通信接口。

  public interface BaseGateway extends RpcGateway {      CompletableFuture<Integer> foobar();
  }
在Flink中，RPC协议的定义通过实现RpcGateway.

public interface RpcGateway {    /**
     * Returns the fully qualified address under which the associated rpc endpoint is reachable.
     *
     * @return Fully qualified (RPC) address under which the associated rpc endpoint is reachable
     */
    String getAddress();    /**
     * Returns the fully qualified hostname under which the associated rpc endpoint is reachable.
     *
     * @return Fully qualified hostname under which the associated rpc endpoint is reachable
     */
    String getHostname();
}
这个接口需要实现两个方法，分别是getAddress和getHostname。原因如下：

如上文所述，想要通过ActorSystem获取远程Actor，必须要有地址。而在Flink中，例如Yarn这种模式下，JobMaster会先建立ActorSystem，这时TaskExecutor的Container都还没有分配，自然无法在配置中指定远程Actor的地址，所以一个远程节点提供自己的地址是必须的。

实现RPC协议
Flink的RPC协议一般定义为一个Java接口，服务端需要实现这个接口。如下是上面定义的BaseGateway的实现。

  public static class BaseEndpoint extends RpcEndpoint implements BaseGateway {      private final int foobarValue;      protected BaseEndpoint(RpcService rpcService, int foobarValue) {          super(rpcService);          this.foobarValue = foobarValue;
      }      @Override
      public CompletableFuture<Integer> foobar() {          return CompletableFuture.completedFuture(foobarValue);
      }      @Override
      public CompletableFuture<Void> postStop() {          return CompletableFuture.completedFuture(null);
      }
  }
RpcEndpoint是rpc请求的接收端的基类。RpcEndpoint是通过RpcService来启动的。

构造并启动RpcService
RpcService会在每一个ClusterEntrypoint(JobMaster)和TaskManagerRunner(TaskExecutor)启动的过程中被初始化并启动。

RpcService主要负责启动RpcEndpoint(也就是服务端)，连接到远程的RpcEndpoint并提供一个代理(也就是客户端)。

此外，为了防止状态的concurrent modification，RpcEndpoint上所有的Rpc调用都只会运行在主线程上，RpcService提供了运行在其它线程的方法。

构造并启动RpcEndpoint(服务端)
每一个RpcEndpoint在初始化阶段会通过该节点的RpcService的startServer方法来初始化服务。

  @Override
  public <C extends RpcEndpoint & RpcGateway> RpcServer startServer(C rpcEndpoint) {
      ...      // 新建一个包含了rpcEndpoint的AkkaRpcActor，负责接收封装成Akka消息的rpc请求
          akkaRpcActorProps = Props.create(AkkaRpcActor.class, rpcEndpoint, terminationFuture, getVersion());
      ...
          actorRef = actorSystem.actorOf(akkaRpcActorProps, rpcEndpoint.getEndpointId());
      ...
  }
      ...      // 获取这个Endpoint的所有Gateway，也就是所有RPC协议的接口
      Set<Class<?>> implementedRpcGateways = new HashSet<>(RpcUtils.extractImplementedRpcGateways(rpcEndpoint.getClass()));
      ...      // 新建一个InvocationHandler，用于将rpc请求包装成LocalRpcInvocation消息并发送给RpcServer(本地)

      final InvocationHandler akkaInvocationHandler;
      ...
          akkaInvocationHandler = new AkkaInvocationHandler(akkaAddress, hostname, actorRef, timeout, maximumFramesize, terminationFuture);
      ...
      // 生成一个包含这些接口的代理，将调用转发到InvocationHandler
      @SuppressWarnings("unchecked")
      RpcServer server = (RpcServer) Proxy.newProxyInstance(classLoader, implementedRpcGateways.toArray(new Class<?>[implementedRpcGateways.size()]), akkaInvocationHandler);      return server;
  }
通过Rpc接口和InvocationHandler构造一个代理对象，这个代理对象存在RpcEndpoint的RpcServer变量中，是给RpcEndpoint所在的JVM本地调用使用

接下来生成一个本地的InvocationHandler，用于将调用转换成消息发送到相应的RpcEndpoint(具体细节在下一节发送Rpc请求会详细介绍)

在该方法中创建了一个Akka的Actor，这个Actor也是Rpc调用的实际接收者，Rpc的请求会在客户端被封装成RpcInvocation对象以Akka消息的形式发送。

启动RpcEndpoint

实际上就是启动构造阶段生成的RpcServer的start方法，这个方法由AkkaInvocationHandler实现，实际上就是向绑定的RpcEndpoint的Actor发送一条START消息，通知它服务已启动。

构造Rpc客户端
Rpc的客户端实际上是一个代理对象，构造这个代理对象，需要提供实现的接口和InvocationHandler，在Flink中有AkkaInvocationHandler的实现。

在构造RpcEndpoint的过程中实际上已经生成了一个供本地使用的Rpc客户端。并且通过RpcEndpoint的getSelfGateway方法可以直接获取这个代理对象。

而在远程调用时，则通过RpcService的connect方法获取远程RpcEndpoint的客户端(也是一个代理)。connect方法需要提供Actor的地址。(至于地址是如何获得的，可以通过LeaderRetrievalService，在这个部分不多做介绍。)

<C extends RpcGateway> CompletableFuture<C> connect(
    String address,
    Class<C> clazz);
private <C extends RpcGateway> CompletableFuture<C> connectInternal(        final String address,        final Class<C> clazz,        Function<ActorRef, InvocationHandler> invocationHandlerFactory) {
    ...    // 通过地址获取ActorSelection, 并获取ActorRef引用
    final ActorSelection actorSel = actorSystem.actorSelection(address);
    final Future<ActorIdentity> identify = Patterns
        .ask(actorSel, new Identify(42), timeout.toMilliseconds())
        .<ActorIdentity>mapTo(ClassTag$.MODULE$.<ActorIdentity>apply(ActorIdentity.class));
    final CompletableFuture<ActorIdentity> identifyFuture = FutureUtils.toJava(identify);
    final CompletableFuture<ActorRef> actorRefFuture = identifyFuture.thenApply(
    ...
    // 发送handshake消息
    final CompletableFuture<HandshakeSuccessMessage> handshakeFuture = actorRefFuture.thenCompose(
        (ActorRef actorRef) -> FutureUtils.toJava(
            Patterns
                .ask(actorRef, new RemoteHandshakeMessage(clazz, getVersion()), timeout.toMilliseconds())
                .<HandshakeSuccessMessage>mapTo(ClassTag$.MODULE$.<HandshakeSuccessMessage>apply(HandshakeSuccessMessage.class))));
    // 根据ActorRef引用生成InvocationHandler
    return actorRefFuture.thenCombineAsync(
        handshakeFuture,
        (ActorRef actorRef, HandshakeSuccessMessage ignored) -> {
            InvocationHandler invocationHandler = invocationHandlerFactory.apply(actorRef);
            ClassLoader classLoader = getClass().getClassLoader();
            @SuppressWarnings("unchecked")
            C proxy = (C) Proxy.newProxyInstance(
                classLoader,                new Class<?>[]{clazz},
                invocationHandler);            return proxy;
        },
        actorSystem.dispatcher());
}
Tuple2<String, String> addressHostname = extractAddressHostname(actorRef);return new AkkaInvocationHandler(addressHostname.f0, addressHostname.f1, actorRef, timeout, maximumFramesize, null);
而invocationHandlerFactory.apply方法如下

最后根据ActorRef，通过InvocationHandlerFactory生成AkkaInvocationHandler并构造代理

通过ActorSelection获取ActorRef并发送握手消息

首先通过地址获取ActorSelection，在Prerequisite中也介绍了这是连接远程Actor的方法之一

发送Rpc请求
上文中客户端会提供代理对象，而代理对象会调用AkkaInvocationHandler的invoke方法并传入Rpc调用的方法和参数信息。

    public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
而在AkkaInvocationHandler对该方法的实现中，会判断方法属于哪个类，如果是Rpc方法的话就会调用invokeRpc方法。

首先将方法封装成一个RpcInvocation，它有两种实现，一种是本地的LocalRpcInvocation，不需要序列化，另一种是远程的RemoteRpcInvocation。根据当前AkkaInvocationHandler和对应的RpcEndpoint是否在同一个JVM中来判断生成哪一个。

private Object invokeRpc(Method method, Object[] args) throws Exception {
    ...    final RpcInvocation rpcInvocation = createRpcInvocationMessage(methodName, parameterTypes, args);
根据返回类型判断使用tell还是ask的形式发送akka消息

    Class<?> returnType = method.getReturnType();    final Object result;    if (Objects.equals(returnType, Void.TYPE)) {
        tell(rpcInvocation);
        result = null;
    } else if (Objects.equals(returnType, CompletableFuture.class)) {        // execute an asynchronous call
        result = ask(rpcInvocation, futureTimeout);
    } else {        // execute a synchronous call
        CompletableFuture<?> futureResult = ask(rpcInvocation, futureTimeout);
        result = futureResult.get(futureTimeout.getSize(), futureTimeout.getUnit());
    }
    return result;
}
Rpc请求的处理
首先Rpc消息是通过RpcEndpoint所绑定的Actor的ActorRef发送的，所以接收到消息的就是RpcEndpoint构造期间生成的AkkRpcActor

akkaRpcActorProps = Props.create(AkkaRpcActor.class, rpcEndpoint, terminationFuture, getVersion());
actorRef = actorSystem.actorOf(akkaRpcActorProps, rpcEndpoint.getEndpointId());
AkkaRpcActor接收到的消息总共有三种

一种是握手消息，如上文所述，在客户端构造时会通过ActorSelection发送过来。收到消息后会检查接口，版本，如果一致就返回成功

第二种是启停消息。例如在RpcEndpoint调用start方法后，就会向自身发送一条Processing.START消息，来转换当前Actor的状态为STARTED。STOP也类似。并且只有在Actor状态为STARTED时才会处理Rpc请求

第三种就是Rpc请求消息，通过解析RpcInvocation获取方法名和参数类型，并从RpcEndpoint类中找到Method对象，并通过反射调用该方法。如果有返回结果，会以Akka消息的形式发送回sender。






==================

     Flink SQL概述

     编辑 ·
      · 我的收藏
     Flink SQL是阿里云实时计算为简化计算模型，降低用户使用实时计算门槛而设计的一套符合标准 SQL语义的开发语言。

     本章节通过以下方面，为您介绍实时计算Flink SQL的使用方法。

     基本概念
     关键字
     数据类型
     DDL语句
     DML语句
     QUERY语句
     数据视图
     窗口函数
     逻辑函数
     内置函数
     自定义函数




本页目录
关键字常用类型
命名规则
保留关键字
本文为您介绍实时计算中已保留的关键字和使用关键字字符的方法。

关键字常用类型
常用类型	关键字
数据类型	VARCHAR、INT、BIGINT、DOUBLE 、DATE 、BOOLEAN 、TINYINT、 SMALLINT 、FLOAT 、DECIMAL、VARBINARY
DDL	CREATE TABLE、CREATE FUNCTION 、CREATE VIEW
DML	INSERT INTO
SELECT 子句	SELECT FROM、WHERE、GROUP BY 、JOIN
命名规则
源表名称、结果表名称、视图表名称、别名名称遵循标准数据库命名规则定义。必须以字母开头，并且只能包含字母、数字和下划线。

保留关键字
以下字符串组合已经被保留为关键字，以备将来使用。如果您想使用以下字符串作为字段名称，请在关键字两端添加`，例如｀value｀。

A,ABS,ABSOLUTE,ACTION,ADA,ADD,ADMIN,AFTER,ALL,ALLOCATE,ALLOW,ALTER,ALWAYS,AND,ANY,ARE,ARRAY,AS,ASC,ASENSITIVE,ASSERTION,ASSIGNMENT,ASYMMETRIC,AT,ATOMIC,ATTRIBUTE,ATTRIBUTES,AUTHORIZATION,AVG,BEFORE,BEGIN,BERNOULLI,BETWEEN,BIGINT,BINARY,BIT,BLOB,BOOLEAN,BOTH,BREADTH,BY,C,CALL,CALLED,CARDINALITY,CASCADE,CASCADED,CASE,CAST,CATALOG,CATALOG_NAME,CEIL,CEILING,CENTURY,CHAIN,CHAR,CHARACTER,CHARACTERISTICTS,CHARACTERS,CHARACTER_LENGTH,CHARACTER_SET_CATALOG,CHARACTER_SET_NAME,CHARACTER_SET_SCHEMA,CHAR_LENGTH,CHECK,CLASS_ORIGIN,CLOB,CLOSE,COALESCE,COBOL,COLLATE,COLLATION,COLLATION_CATALOG,COLLATION_NAME,COLLATION_SCHEMA,COLLECT,COLUMN,COLUMN_NAME,COMMAND_FUNCTION,COMMAND_FUNCTION_CODE,COMMIT,COMMITTED,CONDITION,CONDITION_NUMBER,CONNECT,CONNECTION,CONNECTION_NAME,CONSTRAINT,CONSTRAINTS,CONSTRAINT_CATALOG,CONSTRAINT_NAME,CONSTRAINT_SCHEMA,CONSTRUCTOR,CONTAINS,CONTINUE,CONVERT,CORR,CORRESPONDING,COUNT,COVAR_POP,COVAR_SAMP,CREATE,CROSS,CUBE,CUME_DIST,CURRENT,CURRENT_CATALOG,CURRENT_DATE,CURRENT_DEFAULT_TRANSFORM_GROUP,CURRENT_PATH,CURRENT_ROLE,CURRENT_SCHEMA,CURRENT_TIME,CURRENT_TIMESTAMP,CURRENT_TRANSFORM_GROUP_FOR_TYPE,CURRENT_USER,CURSOR,CURSOR_NAME,CYCLE,DATA,DATABASE,DATE,DATETIME_INTERVAL_CODE,DATETIME_INTERVAL_PRECISION,DAY,DEALLOCATE,DEC,DECADE,DECIMAL,DECLARE,DEFAULT,DEFAULTS,DEFERRABLE,DEFERRED,DEFINED,DEFINER,DEGREE,DELETE,DENSE_RANK,DEPTH,DEREF,DERIVED,DESC,DESCRIBE,DESCRIPTION,DESCRIPTOR,DETERMINISTIC,DIAGNOSTICS,DISALLOW,DISCONNECT,DISPATCH,DISTINCT,DOMAIN,DOUBLE,DOW,DOY,DROP,DYNAMIC,DYNAMIC_FUNCTION,DYNAMIC_FUNCTION_CODE,EACH,ELEMENT,ELSE,END,END-EXEC,EPOCH,EQUALS,ESCAPE,EVERY,EXCEPT,EXCEPTION,EXCLUDE,EXCLUDING,EXEC,EXECUTE,EXISTS,EXP,EXPLAIN,EXTEND,EXTERNAL,EXTRACT,FALSE,FETCH,FILTER,FINAL,FIRST,FIRST_VALUE,FLOAT,FLOOR,FOLLOWING,FOR,FOREIGN,FORTRAN,FOUND,FRAC_SECOND,FREE,FROM,FULL,FUNCTION,FUSION,G,GENERAL,GENERATED,GET,GLOBAL,GO,GOTO,GRANT,GRANTED,GROUP,GROUPING,HAVING,HIERARCHY,HOLD,HOUR,IDENTITY,IMMEDIATE,IMPLEMENTATION,IMPORT,IN,INCLUDING,INCREMENT,INDICATOR,INITIALLY,INNER,INOUT,INPUT,INSENSITIVE,INSERT,INSTANCE,INSTANTIABLE,INT,INTEGER,INTERSECT,INTERSECTION,INTERVAL,INTO,INVOKER,IS,ISOLATION,JAVA,JOIN,K,KEY,KEY_MEMBER,KEY_TYPE,LABEL,LANGUAGE,LARGE,LAST,LAST_VALUE,LATERAL,LEADING,LEFT,LENGTH,LEVEL,LIBRARY,LIKE,LIMIT,LN,LOCAL,LOCALTIME,LOCALTIMESTAMP,LOCATOR,LOWER,M,MAP,MATCH,MATCHED,MAX,MAXVALUE,MEMBER,MERGE,MESSAGE_LENGTH,MESSAGE_OCTET_LENGTH,MESSAGE_TEXT,METHOD,MICROSECOND,MILLENNIUM,MIN,MINUTE,MINVALUE,MOD,MODIFIES,MODULE,MONTH,MORE,MULTISET,MUMPS,NAME,NAMES,NATIONAL,NATURAL,NCHAR,NCLOB,NESTING,NEW,NEXT,NO,NONE,NORMALIZE,NORMALIZED,NOT,NULL,NULLABLE,NULLIF,NULLS,NUMBER,NUMERIC,OBJECT,OCTETS,OCTET_LENGTH,OF,OFFSET,OLD,ON,ONLY,OPEN,OPTION,OPTIONS,OR,ORDER,ORDERING,ORDINALITY,OTHERS,OUT,OUTER,OUTPUT,OVER,OVERLAPS,OVERLAY,OVERRIDING,PAD,PARAMETER,PARAMETER_MODE,PARAMETER_NAME,PARAMETER_ORDINAL_POSITION,PARAMETER_SPECIFIC_CATALOG,PARAMETER_SPECIFIC_NAME,PARAMETER_SPECIFIC_SCHEMA,PARTIAL,PARTITION,PASCAL,PASSTHROUGH,PATH,PERCENTILE_CONT,PERCENTILE_DISC,PERCENT_RANK,PLACING,PLAN,PLI,POSITION,POWER,PRECEDING,PRECISION,PREPARE,PRESERVE,PRIMARY,PRIOR,PRIVILEGES,PROCEDURE,PUBLIC,QUARTER,RANGE,RANK,READ,READS,REAL,RECURSIVE,REF,REFERENCES,REFERENCING,REGR_AVGX,REGR_AVGY,REGR_COUNT,REGR_INTERCEPT,REGR_R2,REGR_SLOPE,REGR_SXX,REGR_SXY,REGR_SYY,RELATIVE,RELEASE,REPEATABLE,RESET,RESTART,RESTRICT,RESULT,RETURN,RETURNED_CARDINALITY,RETURNED_LENGTH,RETURNED_OCTET_LENGTH,RETURNED_SQLSTATE,RETURNS,REVOKE,RIGHT,ROLE,ROLLBACK,ROLLUP,ROUTINE,ROUTINE_CATALOG,ROUTINE_NAME,ROUTINE_SCHEMA,ROW,ROWS,ROW_COUNT,ROW_NUMBER,SAVEPOINT,SCALE,SCHEMA,SCHEMA_NAME,SCOPE,SCOPE_CATALOGS,SCOPE_NAME,SCOPE_SCHEMA,SCROLL,SEARCH,SECOND,SECTION,SECURITY,SELECT,SELF,SENSITIVE,SEQUENCE,SERIALIZABLE,SERVER,SERVER_NAME,SESSION,SESSION_USER,SET,SETS,SIMILAR,SIMPLE,SIZE,SMALLINT,SOME,SOURCE,SPACE,SPECIFIC,SPECIFICTYPE,SPECIFIC_NAME,SQL,SQLEXCEPTION,SQLSTATE,SQLWARNING,SQL_TSI_DAY,SQL_TSI_FRAC_SECOND,SQL_TSI_HOUR,SQL_TSI_MICROSECOND,SQL_TSI_MINUTE,SQL_TSI_MONTH,SQL_TSI_QUARTER,SQL_TSI_SECOND,SQL_TSI_WEEK,SQL_TSI_YEAR,SQRT,START,STATE,STATEMENT,STATIC,STDDEV_POP,STDDEV_SAMP,STREAM,STRUCTURE,STYLE,SUBCLASS_ORIGIN,SUBMULTISET,SUBSTITUTE,SUBSTRING,SUM,SYMMETRIC,SYSTEM,SYSTEM_USER,TABLE,TABLESAMPLE,TABLE_NAME,TEMPORARY,THEN,TIES,TIME,TIMESTAMP,TIMESTAMPADD,TIMESTAMPDIFF,TIMEZONE_HOUR,TIMEZONE_MINUTE,TINYINT,TO,TOP_LEVEL_COUNT,TRAILING,TRANSACTION,TRANSACTIONS_ACTIVE,TRANSACTIONS_COMMITTED,TRANSACTIONS_ROLLED_BACK,TRANSFORM,TRANSFORMS,TRANSLATE,TRANSLATION,TREAT,TRIGGER,TRIGGER_CATALOG,TRIGGER_NAME,TRIGGER_SCHEMA,TRIM,TRUE,TYPE,UESCAPE,UNBOUNDED,UNCOMMITTED,UNDER,UNION,UNIQUE,UNKNOWN,UNNAMED,UNNEST,UPDATE,UPPER,UPSERT,USAGE,USER,USER_DEFINED_TYPE_CATALOG,USER_DEFINED_TYPE_CODE,USER_DEFINED_TYPE_NAME,USER_DEFINED_TYPE_SCHEMA,USING,VALUE,VALUES,VARBINARY,VARCHAR,VARYING,VAR_POP,VAR_SAMP,VERSION,VIEW,WEEK,WHEN,WHENEVER,WHERE,WIDTH_BUCKET,WINDOW,WITH,WITHIN,WITHOUT,WORK,WRAPPER,WRITE,XML,YEAR,ZONE

-------------------------

时区
更新时间：2019-04-23 14:54:06

编辑 ·
 · 我的收藏
本页目录
时区简介
示例
支持的时区列表
本文为您介绍如何设置实时计算作业的时区。

说明 本文档适用于实时计算引擎 1.6及以上版本。
时区简介
在实时计算平台的作业参数中，您可配置Job的时区（如：blink.job.timeZone=America/New_York），默认配置为东八区。时区配置格式Asia/Shanghai、America/New_York或UTC等，详细列表见文章最后。

您可以单独对于Source/Sink表配置时区。例如，您要读/写MySQL，但MySQL的Time/Date/Timestamp列的数据是用 America/New_York（美国时区），而Job计算需要的时区是 Asia/Shanghai（中国时区），则可以如下单独配置source/Sink的时区。
CREATE TABLE mysql_source_my_table (
 -- ...
) WITH (
timeZone='America/New_York'
 -- ...
)
示例
在实时计算引擎 1.6及以上版本中，时区相关函数语义上都是自定义的时区。下面以自定义时区是 Asia/Shanghai为例进行说明。
字符串转时间类型（to_timestamp、timestamp和unix_timestamp）
-- Scalar function
TO_TIMESTAMP("2018-03-14 19:01:02.123")
-- SQL Literal

TIMESTAMP '2018-03-14 19:01:02.123'
-- 输出:
-- 实时计算引擎1.6.0及以上版本： `1521025262123`。
-- 实时计算引擎1.5.x 版本： `1520996462123`。
-- 类似的还有 UNIX_TIMESTAMP，区别是单位为秒。
时间类型转字符串（from_timestamp和data_format）
说明 当参数​为timestamp时，输出结果取决于自定义设定的时区。
SELECT DATE_FORMAT(TO_TIMESTAMP(1520960523000), 'yyyy-MM-dd HH:mm:ss')
-- 输出:
-- 实时计算引擎1.6.0及以上版本： `2018-03-14 01:02:03`。
-- 实时计算引擎1.5.x 版本： `2018-03-13 17:02:03`。

S​ELECT DATE_FORMAT(TO_TIMESTAMP(1520960523000), 'yyyy-MM-dd HH:mm:ss')
-- 输出:
-- 实时计算引擎1.6.0及以上版本：`2018-03-14 01:02:03`。
-- 实时计算引擎1.5.x 版本： `2018-03-13 17:02:03`。


--另外，注意下面例子，实时计算引擎1.6.0和实时计算引擎1.5结果都是一致的，因为输入输出时间字符串是同一个时区计算。

DATE_FORMAT('2018-03-14 01:02:03', 'yyyy-MM-dd HH:mm:ss', 'yyyy/MM/dd HH:mm:ss')
FROM_UNIXTIME(1521025200000/1000)
-- 输出:
-- 实时计算引擎1.6.0及以上版本： `2018-03-14 19:00:00`。
-- 实时计算引擎1.5.x 版本： `2018-03-14 11:00:00`。
时间相关计算函数
当参数​为timestamp时，extract、floor、ceil、date_diff等函数输出结果取决于自定义的时区。当输入参数时间为字符串类型，实时计算引擎 1.6.0和实时计算引擎 1.5结果都是一致的，因为输入输出时间字符串是同一个时区计算。
-- 1521503999000 2018-03-19T23:59:59+0000, 2018-03-20T07:59:59+0800
 EXTRACT(DAY FROM TO_TIMESTAMP(1521503999000))
-- 输出:
-- 实时计算引擎1.6.0及以上版本： `20`。意思为东八区的20号。
-- 实时计算引擎1.5.x 版本： `19` 。
当前时间函数（LOCALTIMESTAMP()、CURRENT_TIMESTAMP()、NOW()、UNIX_TIMESTAMP()）
实时计算引擎 1.6.0版本中 LOCALTIMESTAMP语义有所改变，返回的时间戳当前时刻的时间戳。而在实时计算引擎 1.5版本中，因为 DATE_FORMAT中没有时区，为了让 DATE_FORMAT(CURRENT_TIMESTAMP) 结果正确， LOCALTIMESTAMP被错误的额外加上了默认时区的 offset。
-- 当前时间是 2018-04-03 16:56:10 (Asia/Shanghai)
SELECT DATE_FORMAT(CURRENT_TIMESTAMP, ‘yyyy-MM-dd HH:mm:ss’);
-- 输出:
-- 实时计算引擎1.6.0及以上版本： `2018-04-03 16:56:10`。
-- 实时计算引擎1.5.x 版本： `2018-04-03 08:56:10`。

SELECT DATE_FORMAT(LOCALTIMESTAMP, ‘yyyy-MM-dd HH:mm:ss’);
-- 输出:
-- 实时计算引擎1.6.0：`2018-04-03 16:56:10`。
-- 实时计算引擎1.5：`2018-04-03 16:56:10`。
-- 输出结果1.5/1.6中相同, 但是要注意到LOCALTIMESTAMP输出的时间戳实际是不同的，
SELECT FROM_UNIXTIME(NOW()); SELECT FROM_UNIXTIME(UNIX_TIMESTAMP());
-- 输出:
-- 实时计算引擎1.6.0及以上版本： 输出`2018-04-03 16:56:10`。
-- 实时计算引擎1.5.x 版本： 输出`2018-04-03 08:56:10`。
-- 实时计算引擎1.5 / 实时计算引擎1.6.0中 NOW()、UNIX_TIMESTAMP()语义没有变化都是当前时间戳（单位秒）。输出结果不同是因为FROM_UNIXTIME语义在1.6.0中考虑了时区，以前版本没有考虑时区。
Date/Time 类型
对于Date/Time类型，SQL内部用整数来表示和计算。Date指的是epoch days，Time指的是用户时区的当天的零点开始的毫秒数。如果UDF里对Date、Time进行计算，需要注意的是，从内部类型转换到java.sql.Date、java.sql.Time类型时，java对象里已经加上时区偏移。

支持的时区列表
Africa/Abidjan
Africa/Accra
Africa/Addis_Ababa
Africa/Algiers
Africa/Asmara
Africa/Asmera
Africa/Bamako
Africa/Bangui
Africa/Banjul
Africa/Bissau
Africa/Blantyre
Africa/Brazzaville
Africa/Bujumbura
Africa/Cairo
Africa/Casablanca
Africa/Ceuta
Africa/Conakry
Africa/Dakar
Africa/Dar_es_Salaam
Africa/Djibouti
Africa/Douala
Africa/El_Aaiun
Africa/Freetown
Africa/Gaborone
Africa/Harare
Africa/Johannesburg
Africa/Juba
Africa/Kampala
Africa/Khartoum
Africa/Kigali
Africa/Kinshasa
Africa/Lagos
Africa/Libreville
Africa/Lome
Africa/Luanda
Africa/Lubumbashi
Africa/Lusaka
Africa/Malabo
Africa/Maputo
Africa/Maseru
Africa/Mbabane
Africa/Mogadishu
Africa/Monrovia
Africa/Nairobi
Africa/Ndjamena
Africa/Niamey
Africa/Nouakchott
Africa/Ouagadougou
Africa/Porto-Novo
Africa/Sao_Tome
Africa/Timbuktu
Africa/Tripoli
Africa/Tunis
Africa/Windhoek
America/Adak
America/Anchorage
America/Anguilla
America/Antigua
America/Araguaina
America/Argentina/Buenos_Aires
America/Argentina/Catamarca
America/Argentina/ComodRivadavia
America/Argentina/Cordoba
America/Argentina/Jujuy
America/Argentina/La_Rioja
America/Argentina/Mendoza
America/Argentina/Rio_Gallegos
America/Argentina/Salta
America/Argentina/San_Juan
America/Argentina/San_Luis
America/Argentina/Tucuman
America/Argentina/Ushuaia
America/Aruba
America/Asuncion
America/Atikokan
America/Atka
America/Bahia
America/Bahia_Banderas
America/Barbados
America/Belem
America/Belize
America/Blanc-Sablon
America/Boa_Vista
America/Bogota
America/Boise
America/Buenos_Aires
America/Cambridge_Bay
America/Campo_Grande
America/Cancun
America/Caracas
America/Catamarca
America/Cayenne
America/Cayman
America/Chicago
America/Chihuahua
America/Coral_Harbour
America/Cordoba
America/Costa_Rica
America/Creston
America/Cuiaba
America/Curacao
America/Danmarkshavn
America/Dawson
America/Dawson_Creek
America/Denver
America/Detroit
America/Dominica
America/Edmonton
America/Eirunepe
America/El_Salvador
America/Ensenada
America/Fort_Nelson
America/Fort_Wayne
America/Fortaleza
America/Glace_Bay
America/Godthab
America/Goose_Bay
America/Grand_Turk
America/Grenada
America/Guadeloupe
America/Guatemala
America/Guayaquil
America/Guyana
America/Halifax
America/Havana
America/Hermosillo
America/Indiana/Indianapolis
America/Indiana/Knox
America/Indiana/Marengo
America/Indiana/Petersburg
America/Indiana/Tell_City
America/Indiana/Vevay
America/Indiana/Vincennes
America/Indiana/Winamac
America/Indianapolis
America/Inuvik
America/Iqaluit
America/Jamaica
America/Jujuy
America/Juneau
America/Kentucky/Louisville
America/Kentucky/Monticello
America/Knox_IN
America/Kralendijk
America/La_Paz
America/Lima
America/Los_Angeles
America/Louisville
America/Lower_Princes
America/Maceio
America/Managua
America/Manaus
America/Marigot
America/Martinique
America/Matamoros
America/Mazatlan
America/Mendoza
America/Menominee
America/Merida
America/Metlakatla
America/Mexico_City
America/Miquelon
America/Moncton
America/Monterrey
America/Montevideo
America/Montreal
America/Montserrat
America/Nassau
America/New_York
America/Nipigon
America/Nome
America/Noronha
America/North_Dakota/Beulah
America/North_Dakota/Center
America/North_Dakota/New_Salem
America/Ojinaga
America/Panama
America/Pangnirtung
America/Paramaribo
America/Phoenix
America/Port-au-Prince
America/Port_of_Spain
America/Porto_Acre
America/Porto_Velho
America/Puerto_Rico
America/Punta_Arenas
America/Rainy_River
America/Rankin_Inlet
America/Recife
America/Regina
America/Resolute
America/Rio_Branco
America/Rosario
America/Santa_Isabel
America/Santarem
America/Santiago
America/Santo_Domingo
America/Sao_Paulo
America/Scoresbysund
America/Shiprock
America/Sitka
America/St_Barthelemy
America/St_Johns
America/St_Kitts
America/St_Lucia
America/St_Thomas
America/St_Vincent
America/Swift_Current
America/Tegucigalpa
America/Thule
America/Thunder_Bay
America/Tijuana
America/Toronto
America/Tortola
America/Vancouver
America/Virgin
America/Whitehorse
America/Winnipeg
America/Yakutat
America/Yellowknife
Antarctica/Casey
Antarctica/Davis
Antarctica/DumontDUrville
Antarctica/Macquarie
Antarctica/Mawson
Antarctica/McMurdo
Antarctica/Palmer
Antarctica/Rothera
Antarctica/South_Pole
Antarctica/Syowa
Antarctica/Troll
Antarctica/Vostok
Arctic/Longyearbyen
Asia/Aden
Asia/Almaty
Asia/Amman
Asia/Anadyr
Asia/Aqtau
Asia/Aqtobe
Asia/Ashgabat
Asia/Ashkhabad
Asia/Atyrau
Asia/Baghdad
Asia/Bahrain
Asia/Baku
Asia/Bangkok
Asia/Barnaul
Asia/Beirut
Asia/Bishkek
Asia/Brunei
Asia/Calcutta
Asia/Chita
Asia/Choibalsan
Asia/Chongqing
Asia/Chungking
Asia/Colombo
Asia/Dacca
Asia/Damascus
Asia/Dhaka
Asia/Dili
Asia/Dubai
Asia/Dushanbe
Asia/Famagusta
Asia/Gaza
Asia/Harbin
Asia/Hebron
Asia/Ho_Chi_Minh
Asia/Hong_Kong
Asia/Hovd
Asia/Irkutsk
Asia/Istanbul
Asia/Jakarta
Asia/Jayapura
Asia/Jerusalem
Asia/Kabul
Asia/Kamchatka
Asia/Karachi
Asia/Kashgar
Asia/Kathmandu
Asia/Katmandu
Asia/Khandyga
Asia/Kolkata
Asia/Krasnoyarsk
Asia/Kuala_Lumpur
Asia/Kuching
Asia/Kuwait
Asia/Macao
Asia/Macau
Asia/Magadan
Asia/Makassar
Asia/Manila
Asia/Muscat
Asia/Nicosia
Asia/Novokuznetsk
Asia/Novosibirsk
Asia/Omsk
Asia/Oral
Asia/Phnom_Penh
Asia/Pontianak
Asia/Pyongyang
Asia/Qatar
Asia/Qyzylorda
Asia/Rangoon
Asia/Riyadh
Asia/Saigon
Asia/Sakhalin
Asia/Samarkand
Asia/Seoul
Asia/Shanghai
Asia/Singapore
Asia/Srednekolymsk
Asia/Taipei
Asia/Tashkent
Asia/Tbilisi
Asia/Tehran
Asia/Tel_Aviv
Asia/Thimbu
Asia/Thimphu
Asia/Tokyo
Asia/Tomsk
Asia/Ujung_Pandang
Asia/Ulaanbaatar
Asia/Ulan_Bator
Asia/Urumqi
Asia/Ust-Nera
Asia/Vientiane
Asia/Vladivostok
Asia/Yakutsk
Asia/Yangon
Asia/Yekaterinburg
Asia/Yerevan
Atlantic/Azores
Atlantic/Bermuda
Atlantic/Canary
Atlantic/Cape_Verde
Atlantic/Faeroe
Atlantic/Faroe
Atlantic/Jan_Mayen
Atlantic/Madeira
Atlantic/Reykjavik
Atlantic/South_Georgia
Atlantic/St_Helena
Atlantic/Stanley
Australia/ACT
Australia/Adelaide
Australia/Brisbane
Australia/Broken_Hill
Australia/Canberra
Australia/Currie
Australia/Darwin
Australia/Eucla
Australia/Hobart
Australia/LHI
Australia/Lindeman
Australia/Lord_Howe
Australia/Melbourne
Australia/NSW
Australia/North
Australia/Perth
Australia/Queensland
Australia/South
Australia/Sydney
Australia/Tasmania
Australia/Victoria
Australia/West
Australia/Yancowinna
Brazil/Acre
Brazil/DeNoronha
Brazil/East
Brazil/West
CET
CST6CDT
Canada/Atlantic
Canada/Central
Canada/Eastern
Canada/Mountain
Canada/Newfoundland
Canada/Pacific
Canada/Saskatchewan
Canada/Yukon
Chile/Continental
Chile/EasterIsland
Cuba
EET
EST5EDT
Egypt
Eire
Etc/GMT
Etc/GMT+0
Etc/GMT+1
Etc/GMT+10
Etc/GMT+11
Etc/GMT+12
Etc/GMT+2
Etc/GMT+3
Etc/GMT+4
Etc/GMT+5
Etc/GMT+6
Etc/GMT+7
Etc/GMT+8
Etc/GMT+9
Etc/GMT-0
Etc/GMT-1
Etc/GMT-10
Etc/GMT-11
Etc/GMT-12
Etc/GMT-13
Etc/GMT-14
Etc/GMT-2
Etc/GMT-3
Etc/GMT-4
Etc/GMT-5
Etc/GMT-6
Etc/GMT-7
Etc/GMT-8
Etc/GMT-9
Etc/GMT0
Etc/Greenwich
Etc/UCT
Etc/UTC
Etc/Universal
Etc/Zulu
Europe/Amsterdam
Europe/Andorra
Europe/Astrakhan
Europe/Athens
Europe/Belfast
Europe/Belgrade
Europe/Berlin
Europe/Bratislava
Europe/Brussels
Europe/Bucharest
Europe/Budapest
Europe/Busingen
Europe/Chisinau
Europe/Copenhagen
Europe/Dublin
Europe/Gibraltar
Europe/Guernsey
Europe/Helsinki
Europe/Isle_of_Man
Europe/Istanbul
Europe/Jersey
Europe/Kaliningrad
Europe/Kiev
Europe/Kirov
Europe/Lisbon
Europe/Ljubljana
Europe/London
Europe/Luxembourg
Europe/Madrid
Europe/Malta
Europe/Mariehamn
Europe/Minsk
Europe/Monaco
Europe/Moscow
Europe/Nicosia
Europe/Oslo
Europe/Paris
Europe/Podgorica
Europe/Prague
Europe/Riga
Europe/Rome
Europe/Samara
Europe/San_Marino
Europe/Sarajevo
Europe/Saratov
Europe/Simferopol
Europe/Skopje
Europe/Sofia
Europe/Stockholm
Europe/Tallinn
Europe/Tirane
Europe/Tiraspol
Europe/Ulyanovsk
Europe/Uzhgorod
Europe/Vaduz
Europe/Vatican
Europe/Vienna
Europe/Vilnius
Europe/Volgograd
Europe/Warsaw
Europe/Zagreb
Europe/Zaporozhye
Europe/Zurich
GB
GB-Eire
GMT
GMT0
Greenwich
Hongkong
Iceland
Indian/Antananarivo
Indian/Chagos
Indian/Christmas
Indian/Cocos
Indian/Comoro
Indian/Kerguelen
Indian/Mahe
Indian/Maldives
Indian/Mauritius
Indian/Mayotte
Indian/Reunion
Iran
Israel
Jamaica
Japan
Kwajalein
Libya
MET
MST7MDT
Mexico/BajaNorte
Mexico/BajaSur
Mexico/General
NZ
NZ-CHAT
Navajo
PRC
PST8PDT
Pacific/Apia
Pacific/Auckland
Pacific/Bougainville
Pacific/Chatham
Pacific/Chuuk
Pacific/Easter
Pacific/Efate
Pacific/Enderbury
Pacific/Fakaofo
Pacific/Fiji
Pacific/Funafuti
Pacific/Galapagos
Pacific/Gambier
Pacific/Guadalcanal
Pacific/Guam
Pacific/Honolulu
Pacific/Johnston
Pacific/Kiritimati
Pacific/Kosrae
Pacific/Kwajalein
Pacific/Majuro
Pacific/Marquesas
Pacific/Midway
Pacific/Nauru
Pacific/Niue
Pacific/Norfolk
Pacific/Noumea
Pacific/Pago_Pago
Pacific/Palau
Pacific/Pitcairn
Pacific/Pohnpei
Pacific/Ponape
Pacific/Port_Moresby
Pacific/Rarotonga
Pacific/Saipan
Pacific/Samoa
Pacific/Tahiti
Pacific/Tarawa
Pacific/Tongatapu
Pacific/Truk
Pacific/Wake
Pacific/Wallis
Pacific/Yap
Poland
Portugal
ROK
Singapore
SystemV/AST4
SystemV/AST4ADT
SystemV/CST6
SystemV/CST6CDT
SystemV/EST5
SystemV/EST5EDT
SystemV/HST10
SystemV/MST7
SystemV/MST7MDT
SystemV/PST8
SystemV/PST8PDT
SystemV/YST9
SystemV/YST9YDT
Turkey
UCT
US/Alaska
US/Aleutian
US/Arizona
US/Central
US/East-Indiana
US/Eastern
US/Hawaii
US/Indiana-Starke
US/Michigan
US/Mountain
US/Pacific
US/Pacific-New
US/Samoa
UTC
Universal
W-SU
WET
Zulu

时间属性
更新时间：2019-04-16 16:10:16

编辑 ·
 · 我的收藏
本页目录
Event Time
Processing Time
时间属性字段传递
本文为您介绍Flink SQL支持的Event Time和Processing Time数据类型。

Flink SQL支持2种时间类型Event Time和Processing Time。
Event Time：您提供的事件时间（通常是数据的最原始的创建时间），Event time必须是您提供在Schema里的数据。
Processing Time：系统对事件进行处理的本地系统时间。
下图是不同时间属性在实时计算流程中的位置。

从上图的定义可以看出，Ingestion Time和Processing Time是系统为流式记录增加的时间属性，您并不能控制。Event Time则是流记录本身携带的时间属性。由于数据本身存在乱序以及网络抖动等其它原因，Event Time为t1（对应partition1）时刻的纪录，有可能会晚于t2（对应prtition2）时刻的被Flink处理，即t2 > t1。

Event Time
EventTime也称为rowtime。EventTime时间属性必须在源表DDL中声明，可以将源表中的某一字段声明成 EventTime。目前只支持将TIMESTAMP类型（将来会支持 LONG 类型）声明成rowtime字段。如果不是TIMESTAMP类型，需要借助计算列，基于现有列构造出一个TIMESTAMP类型的列。

但由于数据本身会有乱序，加之网络抖动或其它原因，数据到达的顺序和被处理的顺序可能是不一致的（乱序）。因此定义一个rowtime字段，需要显示地定义一个Watermark计算方法。

窗口函数基于Event Time聚合的示例如下。
CREATE TABLE tt_stream(
  a VARCHAR,
  b VARCHAR,
  c TIMESTAMP,
  WATERMARK wk1 FOR c as withOffset(c, 1000)  --watermark计算方法
) WITH (
  type = 'sls',
  topic = 'yourTopicName',
  accessId = 'yourAccessId',
  accessKey = 'yourAccessSecret'
);

CREATE TABLE rds_output(
  id VARCHAR,
  c TIMESTAMP,
  f TIMESTAMP,
  cnt BIGINT
) WITH (
  type = 'rds',
  url = 'jdbc:mysql://****3306/test',
  tableName = 'yourTableName',
  userName = 'yourUserName',
  password = 'yourPassword'
);

INSERT INTO rds_output
SELECT a AS id,
     SESSION_START(c, INTERVAL '1' SECOND) AS c,
     CAST(SESSION_END(c, INTERVAL '1' SECOND) AS TIMESTAMP) AS f,
     COUNT(a) AS cnt
FROM tt_stream
GROUP BY SESSION(c, INTERVAL '1' SECOND), a


Processing Time
Processing Time是系统产生的，不在您的原始数据中，您需要在数据源表的声明中显式的定义一个Processing Time列。
filedName as PROCTIME()
窗口函数基于Processing Time聚合的示例如下。
CREATE TABLE mq_stream (
  a VARCHAR,
  b VARCHAR,
  c BIGINT,
  d AS PROCTIME()   ---在数据源表的声明中显式的定义一个Processing Time列
) WITH (
  type = 'mq',
  topic = 'yourTopic',
  accessId = 'yourAccessId',
  accessKey = 'yourAccessSecret'
);

CREATE TABLE rds_output (
  id VARCHAR,
  c TIMESTAMP,
  f TIMESTAMP,
  cnt BIGINT
) with (
  type = 'rds',
  url = 'yourDatebaseURL',
  tableName = 'yourDatabasTableName',
  userName = 'yourUserName',
  password = 'yourPassword'
);


INSERT INTO rds_output
SELECT a AS id,
     SESSION_START(d, INTERVAL '1' SECOND) AS c,
     SESSION_END(d, INTERVAL '1' SECOND) AS f,
     COUNT(a) AS cnt
FROM mq_stream
GROUP BY SESSION(d, INTERVAL '1' SECOND), a

时间属性字段传递
目前，时间属性字段经过如下两种操作后会失去时间属性 ：
非window的group by
双流join
如果经过以上两种操作后，继续使用该时间属性字段进行窗口函数运算会出现类似 org.apache.flink.table.api.ValidationException: Window can only be defined over a time attribute column.的报错。

Watermark
更新时间：2019-03-18 09:38:50

编辑 ·
 · 我的收藏
实时计算可以基于时间属性对数据进行窗口聚合。基于的Event Time时间属性的窗口函数作业中，数据源表的声明中需要使用watermark方法。

watermark是一种衡量Event Time进展的机制，它是数据本身的一个隐藏属性，watermark的定义是数据源表DDL定义的一部分。Flink提供了如下语法定义watermark。

说明 实时计算时间属性详情，请参见时间属性。
WATERMARK [watermarkName] FOR <rowtime_field> AS withOffset(<rowtime_field>, offset)
参数	说明
watermarkName	标识watermark的名字，可选。
<rowtime_field>	必须是表中已定义的一列（当前仅支持为TIMESTAMP类型），含义是基于该列生成watermark，并且标识该列为Event Time列，可以在后续query中用来定义窗口。
withOffset	是目前提供的watermark的生成策略，是根据<rowtime_field> - offset生成watermark的值。withOffset的第一个参数必须是<rowtime_field>。
offset	单位为毫秒，含义为watermark值与Event Time值的偏移量。
通常一条记录中的某个字段就代表了该记录的发生时间。例如，表中有个rowtime字段，类型为TIMESTAMP，其中某个字段为1501750584000（2017-08-03 08:56:24.000）。如果您需要定义一个基于该rowtime列的watermark，watermark策略为偏移4秒，需要如下定义。

WATERMARK FOR rowtime AS withOffset(rowtime, 4000)
在这种情况下，这条数据的watermark时间为 1501750584000 - 4000 = 1501750580000（2017-08-03 08:56:20.000）。这条数据的watermark时间含义即：时间戳小于1501750580000（2017-08-03 08:56:20.000）的数据，都已经到达了。

说明
在使用Event Time Watermark时的rowtime必须是TIMESTAMP类型。当前支持毫秒级别的、在Unix时间戳里是13位。如果是其他类型或是在Unix时间戳不是13位，建议使用计算列来做转换。
Event Time和Processing Time的声明只能在源表上声明。
watermark使用总结
Watermark含义是所有时间戳t'< t 的事件都已经发生。假如watermarkt已经生效，那么后续Event Time小于t的记录都会被丢弃掉（目前实时计算的处理方式是丢弃这些来的更晚的数据，后续支持用户配置让更晚的数据也能继续更新）。
针对乱序的的流，watermark至关重要。即使一些事件延迟到达，也不至于过于影响窗口计算的正确性。
并行数据流中，当算子（Operator）有多个输入流时，算子的Event Time以最小流Event Time为准。

计算列
更新时间：2019-03-18 09:39:36

编辑 ·
 · 我的收藏
本页目录
计算列概念
计算列的用途
计算列语法
计算列示例
计算列可以使用其它列的数据，计算出其所属列的数值。如果您的数据源表中没有TIMESTAMP类型的列，可以使用计算列方法从其它类型的字段进行转换。

计算列概念
计算列是虚拟列，并非实际存储在表中。计算列可以通过表达式、内置函数、或是自定义函数等方式，使用其它列的数据，计算出其所属列的数值。计算列在Flink SQL中可以像普通字段一样被使用。

计算列的用途
目前watermark的Event Time（也称为rowtime）列只支持TIMESTAMP类型（未来会支持LONG类型）。watermark只能定义在源表DDL中，如果您的源表中没有TIMESTAMP类型的列，可以使用计算列从其他类型的字段进行转换。

计算列语法
column_name AS computed_column_expression
计算列示例
watermark的rowtime必须是TIMESTAMP数据类型。当前实时计算支持毫秒级别的、在Unix时间戳里是13位TIMESTAMP数据类型。如果DataHub的TIME字段是微秒级别的（16位Unix时间戳），可以用计算列方法转换为13位的时间戳，如下所示。


CREATE TABLE test_stream(
  a INT,
  b BIGINT,
  `TIME` BIGINT,
  ts AS TO_TIMESTAMP(TIME/1000), --利用计算列，将16位时间戳转换为13位时间戳。
  WATERMARK FOR ts AS WITHOFFSET(ts, 1000)
) WITH (
  type = 'datahub',
  ...
);
如上示例中所示，源表数据中的字段TIME包含时间信息，为BIGINT类型。用计算列的功能将字段TIME转换成了TIMESTAMP类型的ts字段，并将ts字段作为watermark的rowtime字段

数据类型概述
更新时间：2019-03-15 09:23:10

编辑 ·
 · 我的收藏
本页目录
实时计算支持的数据类型
数据类型转换
类型转换示例
本文为您介绍实时计算支持的数据类型以及数据类型之间的转换方法。

实时计算支持的数据类型
数据类型	说明	值域
VARCHAR	可变长度字符串	最大容量为4Mb
BOOLEAN	逻辑值	取值为TRUE、FALSE或UNKNOWN。
TINYINT	微整型，1字节整数。	-128到127
SMALLINT	短整型，2字节整数。	-32768到32767
INT	整型，4字节整数。	-2147483648到2147483647
BIGINT	长整型，8字节整数。	-9223372036854775808到9223372036854775807
FLOAT	4字节浮点型	6位数字精度
DECIMAL	小数类型	示例：123.45是DECIMAL(5,2)的值。
DOUBLE	浮点型，8字节浮点型	15位十进制精度
DATE	日期类型	示例：DATE'1969-07-20'。
TIME	时间类型	示例：TIME '20：17：40'。
TIMESTAMP	时间戳，日期和时间	示例：TIMESTAMP '1969-07-20 20:17:40'。
VARBINARY	二进制数据	byte[] 数组
数据类型转换
数据类型转换
类型转换示例
测试数据

var1（VARCHAR）	big1（BIGINT）
1000	323
测试语句

cast (var1 as bigint) as AA;
cast (big1 as varchar) as BB;
测试结果

AA（BIGINT）	BB（VARCHAR）
1000	323

数据类型之间运算关系
更新时间：2019-03-06 18:46:50

编辑 ·
 · 我的收藏
本页目录
数学运算和逻辑运算
本文为您介绍实时计算数据类型之间的数学运算和逻辑运算。

数学运算和逻辑运算
运算语句	描述	numeric1和numeric2支持的数据类型	示例
numeric1 + numeric2	返回前后两数字数学运算的和	INT,DOUBLE,DECIMAL,BIGINT	2+4.2
numeric1 - numeric2	返回前后两数字数学运算差值	3-5.3
numeric1 * numeric2	返回前后两数字数学运算积值	2*4
numeric1 / numeric2	返回前后两数字数学运算商值	2.4/5
numeric1 > numeric2	返回前后两数字是否大于的逻辑运算值	2.4>5
numeric1 < numeric2	返回前后两数字是否小于逻辑运算值	2.4<5
numeric1 >= numeric2	返回前后两数字是否大于等于的逻辑运算值	2.4>=5
numeric1 <= numeric2	返回前后两数字是否小于等于的逻辑运算值	2.4<=5
numeric1 = numeric2	返回前后两数字是否相同（等）逻辑运算值	INT,DOUBLE,DECIMAL,BIGINT,VARCHAR	‘iphone’ = 5
numeric1 <> numeric2	返回前后两数字是否不相同（等）逻辑运算值	‘iphone’ <> 5
说明 同一运算语句中numeric1和numeric2的数据类型需要保持一致。

创建数据视图
更新时间：2019-03-15 09:23:28

编辑 ·
 · 我的收藏
本页目录
语法
示例1
示例2
您可以通过创建实时计算数据视图简化开发过程。

语法
如果计算的逻辑比较复杂，您可以通过实时计算定义视图的方式创建数据视图，简化开发过程。
说明 数据视图仅用于辅助计算逻辑的描述，不会产生数据的物理存储。
CREATE VIEW viewName[ (columnName[ , columnName]*
) ] AS queryStatement;
示例1
CREATE VIEW LargeOrders (r, t, c, u) AS
SELECT
    rowtime,
    productId,
    c,
    units
FROM
    orders;
INSERT INTO
    rds_output
SELECT
    r,
    t,
    c,
    u
FROM
    LargeOrders;
示例2
测试数据
a（VARCHAR）	b（BIGINT）	c（ TIMESTAMP）
test1	1	1506823820000
test2	1	1506823850000
test1	1	1506823810000
test2	1	1506823840000
test2	1	1506823870000
test1	1	1506823830000
test2	1	1506823860000
测试语句
CREATE TABLE datahub_stream (
   a VARCHAR,
   b BIGINT,
   c TIMESTAMP,
   d AS PROCTIME()
) WITH (
  TYPE='datahub',
  ...
);
CREATE TABLE rds_output (
   a VARCHAR,
   b TIMESTAMP,
   cnt BIGINT,
   PRIMARY KEY(a)
)WITH(
  TYPE = 'rds',
  ...
);
CREATE VIEW rds_view AS
SELECT a,
   CAST(
      HOP_START(d, INTERVAL '5' SECOND, INTERVAL '30' SECOND) AS TIMESTAMP
   ) AS cc,
   SUM(b) AS cnt
FROM
   datahub_stream
GROUP BY
    HOP(d, INTERVAL '5' SECOND, INTERVAL '30' SECOND),a;
INSERT INTO
   rds_output
SELECT
   a,
   cc,
   cnt
FROM
   rds_view
WHERE
   cnt=4
测试结果
a(VARCHAR)	b (TIMESTAMP)	cnt (BIGINT)
test2	2017-11-06 16:54:10	4




创建数据总线（DataHub）源表
更新时间：2019-03-27 17:37:40

编辑 ·
本页目录
什么是数据总线
示例
属性字段
WITH参数
类型映射
本文为您介绍如何为实时计算创建数据总线（DataHub）源表以及创建过程涉及到的属性字段、with参数和类型映射。

什么是数据总线
DataHub作为流式数据总线，为阿里云数加平台提供了大数据的入口服务。实时计算可以使用DataHub作为流式数据存储的源头和输出的目的端。

示例
DataHub可以作为实时计算的数据输入，示例如下。
CREATE TABLE datahub_stream(
  name VARCHAR,
  age BIGINT,
  birthday BIGINT
) WITH (
  type='datahub',
  endPoint='******',
  project='******',
  topic='******',
  accessId='******',
  accessKey='******',
  startTime='2017-07-21 00:00:00'
);
属性字段
Flink SQL支持获取DataHub的属性字段。通过读取属性字段可以获得每条信息写入DataHub的系统时间（System Time），如下图所示。
System Time
字段名	注释说明
timestamp	每条记录写入DataHub的系统时间（System Time）属性字段使用说明
为了获取这些属性字段，除了按照正常逻辑声明外，还需要在类型声明后面加上header关键字以示区分。

例如，DataHub属性字段timestamp并不存在于DataHub的字段声明。想获取每条记录入DataHub的系统时间，可以将timestamp作为字段名，在后面加上header。示例如下。

测试数据
name(VARCHAR)	MsgID(VARCHAR)
ens_altar_flow	ems0a
测试语句
CREATE TABLE datahub_log (
  `timestamp`  VARCHAR HEADER,
  name     VARCHAR，
  MsgID    VARCHAR
)
WITH
(
  type ='datahub'

);

CREATE TABLE RDS_out (
  `timestamp`     VARCHAR,
  MsgID    VARCHAR,
  name  VARCHAR
)
WITH
(
  type ='RDS'

);

INSERT INTO RDS_out
SELECT
`timestamp`,
MsgID,
name
FROM datahub_log;
测试结果
TIME(VARCHAR)	MsgID(VARCHAR)	name(VARCHAR)
1522652455625	ems0a	ens_altar_flow
WITH参数
目前只支持tuple模式的topic。

参数	注释说明	备注
endPoint	消费端点信息	参见DataHub域名列表 。
accessId	读取的accessId	无
accessKey	读取的密钥	无
project	读取的项目	无
topic	project下的具体的topic	无
startTime	启动位点的时间	格式为yyyy-MM-dd hh:mm:ss。
maxRetryTimes	读取最大尝试次数	可选，默认值为20。
retryIntervalMs	重试间隔	可选，默认值为1000，单位为毫秒。
batchReadSize	单次读取条数	可选，默认值为10，可设置的最大值为1000。
lengthCheck	单行字段条数检查策略	可选，默认值为NONE，表示：
解析出的字段数大于定义字段数时，按从左到右的顺序，取定义字段数量的数据。
解析出的字段数小于定义字段数时，跳过这行数据。
其它可选值为SKIP、EXCEPTION和PAD。
SKIP：解析出的字段数和定义字段数不同时跳过这行数据。
EXCEPTION：解析出的字段数和定义字段数不同时提示异常。
PAD：按从左到右顺序填充。
解析出的字段数大于定义字段数时，按从左到右的顺序，取定义字段数量的数据。
解析出的字段数小于定义字段数时，在行尾用null填充缺少的字段。
columnErrorDebug	是否开启调试功能	可选，默认值为false，表示关闭调试功能。开启调试功能参数值为true，将打印解析异常的日志。
类型映射
DataHub和实时计算字段类型对应关系如下，建议使用该对应关系时进行DDL声明:

DataHub字段类型	实时计算字段类型
BIGINT	BIGINT
TIMESTAMP
STRING	VARCHAR
DOUBLE	DOUBLE
BOOLEAN	BOOLEAN
DECIMAL	DECIMAL
说明 DataHub的TIMESTAMP是精确到微妙级别的，在Unix时间戳里是16位的。而实时计算定义的TIMESTAMP是精确到毫秒级别的，在Unix时间戳里是13位的所以建议大家使用BIGINT来映射。如果一定是要用TIMESTAMP建议使用计算列来做转换。






创建日志服务（LogService）源表
更新时间：2019-04-18 14:04:36

编辑 ·
本页目录
什么是日志服务
属性字段
W参数
类型映射
本文为您介绍如何为实时计算创建日志服务（Log Service）源表以及创建过程涉及到的属性字段、with参数和类型映射。

什么是日志服务
日志服务（LogService）是针对日志类数据的一站式服务，在阿里巴巴集团经历大量大数据场景锤炼而成。 日志服务本身是流数据存储，实时计算能将其作为流式数据输入。对于日志服务而言，数据格式类似JSON，示例如下。

{
	"a": 1000,
	"b": 1234,
	"c": "li"
}

对于实时计算而言，我们需要定义的DDL如下（代码中的sls代表LogService）。

create table sls_stream(
  a int,
  b int,
  c VARCHAR
) with (
  type ='sls',
  endPoint ='yourEndpoint',
  accessId ='yourAccessId',
  accessKey ='yourAccessKey',
  startTime = 'yourStartTime',
  project ='yourProjectName',
  logStore ='yourLogStoreName',
  consumerGroup ='yourConsumerGroupName'
);

属性字段
目前Flink SQL默认支持3个LogServic属性字段的获取，也支持其它自定义字段的写入。

字段名	注释说明
__source__	消息源
__topic__	消息主题
__timestamp__	日志时间属性字段使用说明
为了获取这些属性字段，除了正常逻辑声明外，还需要在类型声明后加上HEADER关键字。示例如下。

测试数据
     __topic__:  ens_altar_flow
        result:  {"MsgID":"ems0a","Version":"0.0.1"}
测试语句
CREATE TABLE sls_log (
  __topic__  VARCHAR HEADER,
  result     VARCHAR
)
WITH
(
  type ='sls'
);
CREATE TABLE sls_out (
  name     VARCHAR,
  MsgID    VARCHAR,
  Version  VARCHAR
)
WITH
(
  type ='RDS'
);
INSERT INTO sls_out
SELECT
__topic__,
JSON_VALUE(result,'$.MsgID'),
JSON_VALUE(result,'$.Version')
FROM
sls_log
测试结果
name(VARCHAR)	MsgID(VARCHAR)	Version(VARCHAR)
ens_altar_flow	ems0a	0.0.1
W参数
参数	注释说明	备注
endPoint	消费端点信息	服务入口
accessId	LogService读取的accessKey	无
accessKey	LogService读取的密钥	无
project	读取的LogService项目	无
logStore	Project下的具体的LogStore名称	无
consumerGroup	消费组名	用户可以自定义消费组名（没有固定格式）
startTime	消费日志开始的时间点	无
heartBeatIntervalMills	可选，消费客户端心跳间隔时间	默认为10s
maxRetryTimes	读取最大尝试次数	可选，默认为5。
batchGetSize	单次读取logGroup条数	可选，默认为10。
lengthCheck	单行字段条数检查策略	可选，默认值为NONE，表示：
解析出的字段数大于定义字段数时，按从左到右的顺序，取定义字段数量的数据。
解析出的字段数小于定义字段数时，跳过这行数据。
其它可选值为SKIP、EXCEPTION和PAD。
SKIP：解析出的字段数和定义字段数不同时跳过这行数据。
EXCEPTION：解析出的字段数和定义字段数不同时提示异常。
PAD：按从左到右顺序填充。
解析出的字段数大于定义字段数时，按从左到右的顺序，取定义字段数量的数据。
解析出的字段数小于定义字段数时，在行尾用null填充缺少的字段。
columnErrorDebug	是否打开调试开关	可选，默认为false，不打开。如果选择打开，会把解析异常的log打印出来
directMode	是否使用LogService的直连模式	可选 ，默认为false，不开启LogService直连模式。开启后作业直接连接LogService的nginx服务器，网络可通时，连接效率能够提升。
说明
LogService暂不支持MAP类型的数据。
字段顺序支持无序（建议字段顺序和表中定义一致）。
输入数据源为JSON形式时，注意定义分隔符，并且需要采用内置函数JSON_VALUE分析，否则就会解析失败。报错如下:
2017-12-25 15:24:43,467 WARN [Topology-0 (1/1)] com.alibaba.blink.streaming.connectors.common.source.parse.DefaultSourceCollector - Field missing error, table column number: 3, data column number: 3, data filed number: 1, data: [{"lg_order_code":"LP00000005","activity_code":"TEST_CODE1","occur_time":"2017-12-10 00:00:01"}]
batchGetSize设置不能超过1000，否则会报错。
batchGetSize指明的是logGroup获取的数量，如果单条logItem的大小和batchGetSize都很大，有可能会导致频繁的垃圾回收（Garbage Collection)，这种情况下该参数应调小。
类型映射
日志服务和实时计算字段类型对应关系如下。建议您使用该对应关系进行DDL声明:

日志服务字段类型	实时计算字段类型
STRING	VARCHAR

创建消息队列（MQ）源表
更新时间：2019-04-18 20:02:41

编辑 ·
本页目录
什么是消息队列MQ
示例
CSV类格式
二进制格式
WITH参数
类型映射
本文为您介绍如何为实时计算创建消息队列（MQ）源表以及创建过程涉及到的CSV类格式、with参数和类型映射。

什么是消息队列MQ
消息队列（Message Queue），简称MQ，是阿里云专业消息中间件，是企业级互联网架构的核心产品。实时计算可以将消息队列作为流式数据输入，示例如下。

示例
create table mq_stream(
 x varchar,
 y varchar,
 z varchar
) with (
 type='mq',
 topic='yourTopicName',
 endpoint='yourEndpoint',
 pullIntervalMs='1000',
 accessId='yourAccessId',
 accessKey='yourAccessSecret',
 startMessageOffset='1000',
 consumerGroup='yourConsumerGroup',
 fieldDelimiter='|'
);
说明 MQ实际上是一个非结构化存储格式，对于数据的Schema不提供强制定义，完全由业务层指定。目前实时计算支持类CSV格式文本和二进制格式。
CSV类格式
假设您的1条CSV格式消息记录如下。

1,name,male
2,name,female
说明 1条MQ消息可以包括0条到多条数据记录，记录之间使用 \n分隔。
在实时计算作业中，声明MQ数据源表的DDL如下。

create table mq_stream(
 id varchar,
 name varchar,
 gender varchar
) with (
 type='mq',
 topic='yourTopicName',
 endpoint='yourEndpoint',
 pullIntervalMs='1000',
 accessId='*yourAccessId',
 accessKey='yourAccessSecret',
 startMessageOffset='1000',
 consumerGroup='yourConsumerGroup*',
 fieldDelimiter='|'
);
二进制格式
二进制格式测试代码如下。

create table source_table (
  mess varbinary
) with (
  type = 'mq',
  endpoint = 'yourEndpoint',
  pullIntervalMs='500',
  accessId='yourAccessId',
  accessKey='yourAccessSecret',
  topic = 'yourTopicName',
  consumerGroup='yourConsumerGroup'
);
create table out_table (
  commodity varchar
)with(
  type='print'
);
INSERT INTO out_table
SELECT
  cast(mess as varchar)
FROM source_table
说明
cast(mess as varbinary) 需在实时计算2.0及以上版本使用，若版本低于2.0，请先升级。
VARBINARY只能入参一次。
WITH参数
参数	注释说明	备注
topic	topic名称	无
endPoint	endPoint地址
公共云内网接入（阿里云经典网络/VPC）：华东1、华东2、华北1、华北2、华南1、香港的区域endpoint的地址是：onsaddr-internal.aliyun.com:8080
公共云公网接入地址是：http://onsaddr-internet.aliyun.com/rocketmq/nsaddr4client-internet
accessId	accessId	无
accessKey	accessKey	无
consumerGroup	订阅消费group名称	无
pullIntervalMs	拉取时间间隔	单位为毫秒
startTime	消息消费启动的时间点	可选
startMessageOffset	消息开始的偏移量	可选，如果填写，将优先以startMessageoffset的位点开始加载。
tag	订阅的标签	可选
lineDelimiter	解析block时行分隔符	可选，默认为 \n
fieldDelimiter	字段分隔符	可选，默认为\u0001 。表示在只读模式下以 \u0001（\u0001在只读模式不可见）作为分隔符；在编辑模式下以^A作为分隔符。
encoding	编码格式	可选，默认为 utf-8
lengthCheck	单行字段条数检查策略	可选，默认值为NONE，表示：
解析出的字段数大于定义字段数时，按从左到右的顺序，取定义字段数量的数据。
解析出的字段数小于定义字段数时，跳过这行数据。
其它可选值为SKIP、EXCEPTION和PAD。
SKIP：解析出的字段数和定义字段数不同时跳过这行数据。
EXCEPTION：解析出的字段数和定义字段数不同时提示异常。
PAD：按从左到右顺序填充。
解析出的字段数大于定义字段数时，按从左到右的顺序，取定义字段数量的数据。
解析出的字段数小于定义字段数时，在行尾用null填充缺少的字段。
columnErrorDebug	是否打开调试开关	可选，默认为false。如果设置为ture，则打印解析异常的log。
类型映射
MQ字段类型	实时计算字段类型
STRING	VARCHAR

数据结果表概述
更新时间：2019-04-19 10:26:28

编辑 ·
本页目录
结果表语法
结果表示例
实时计算使用CREATE TABLE作为输出结果数据的格式定义，同时定义数据如何写入到目的数据结果表。

实时计算结果表有Append类型和Update类型。

Append类型：如果输出存储是日志系统、消息系统、或未定义主键的RDS数据库，数据流的输出结果会以追加的方式写入到存储中，不会修改存储中原有的数据。
Update类型：如果输出存储是声明了主键（primary key）的数据库（例如，RDS和HBase），数据流的输出结果有以下2种情况。
如果根据主键查询的数据在数据库中不存在，则会将该数据插入数据库。
如果根据主键查询的数据在数据库中存在，则会根据主键更新数据。
结果表语法
CREATE TABLE tableName
    (columnName dataType [, columnName dataType ]*)
    [ WITH (propertyName=propertyValue [, propertyName=propertyValue ]*) ];
结果表示例
CREATE TABLE rds_output(
id INT,
len INT,
content VARCHAR,
PRIMARY KEY(id)
) WITH (
type='rds',
url='yourDatabaseURL',
tableName='yourTableName',
userName='yourDatabaseUserName',
password='yourDatabasePassword'
);

创建分析型数据库（AnalyticDB）结果表
更新时间：2019-04-19 19:56:56

编辑 ·
本页目录
什么是分析型数据库（AnalyticDB）
DDL定义
WITH参数
类型映射
本文为您介绍如何创建实时计算分析型数据库（AnalyticDB）结果表以及分析型数据库和实时计算字段类型之间的映射关系。

什么是分析型数据库（AnalyticDB）
分析型数据库（AnalyticDB）是阿里巴巴自主研发的海量数据实时高并发在线分析（Realtime OLAP）云计算服务，使得您可以在毫秒级时单位时间内，对千亿级数据进行即时的多维分析透视和业务探索。

DDL定义
实时计算支持使用AnalyticDB作为结果输出。示例代码如下。
CREATE TABLE stream_test_hotline_agent (
id INTEGER,
len BIGINT,
content VARCHAR，
PRIMARY KEY(id)
) WITH (
type='ads',
url='yourDatabaseURL',
tableName='yourDatabaseTableName',
userName='yourDatabaseUserName',
password='yourDatabasePassword',
batchSize='20'
);
说明
建议使用存储注册功能，参见注册分析型数据库（AnalyticDB）。
实时计算AnalyticDB声明中的主键primary key要和AnalyticDB数据库里的主键一致，大小写敏感。不一致会导致数组索引越界的异常现象。
WITH参数
参数	注释说明	备注
url	jdbc连接地址	AnalyticDB数据库地址 。示例：url ='jdbc:mysql://databaseName****-cn-shenzhen-a.ads.aliyuncs.com:10014/databaseName'。
说明
AnalyticDB数据库连接信息参见注册分析型数据库（AnalyticDB）中URL地址查询。
AnalyticDB数据库名称（databaseName）即AnalyticDB实例名称。
tableName	表名	无
username	账号	无
password	密码	无
maxRetryTimes	写入重试次数	可选，默认为10
bufferSize	流入多少条数据后开始去重	可选，默认为5000，表示输入的数据达到5000条就开始输出。
batchSize	一次批量写入的条数	可选，默认值为1000。
batchWriteTimeoutMs	写入超时时间	可选，单位为毫秒，默认值为5000。表示如果缓存中的数据在等待5秒后，依然没有达到输出条件，系统会自动输出缓存中的所有数据。
connectionMaxActive	单连接池最大连接数	可选，默认值30
ignoreDelete	是否忽略delete操作	默认为false
说明 如果错代码是20015，则表示batchSize设置的过大。AnalyticDB单次batch不能超过1M。例如，batchSize设置为 1000，平均每条记录大小不能超过1Kb。
类型映射
建议使用AnalyticDB和实时计算字段类型对应关系进行DDL声明。

AnalyticDB字段类型	实时计算字段类型
BOOLEAN	BOOLEAN
TINYINT	INT
SAMLLINT
INT
BIGINT	BIGINT
DOUBEL	DOUBLE
VARCHAR	VARCHAR
DATE	DATE

创建数据总线（DataHub）结果表
更新时间：2019-03-27 17:39:14

编辑 ·
本页目录
什么是数据总线（DataHub）
DDL定义
WITH参数
本文为您介绍如何创建实时计算数据总线（DataHub）结果表。

什么是数据总线（DataHub）
DataHub作为流式数据总线，为阿里云数加平台提供了大数据的入口服务。实时计算通常使用DataHub作为流式数据存储输入源和输出目的端。

DDL定义
实时计算支持使用DataHub作为数据输出结果表，DataHub结果表声明示例如下。

create table datahub_output(
  name VARCHAR,
  age BIGINT,
  birthday BIGINT
)with(
  type='datahub',
  endPoint='******',
  project='******',
  topic='******',
  accessId='******',
  accessKey='******',
  batchSize='******',
  batchWriteTimeoutMs='******'
);
说明 建议使用存储注册功能，参见注册大数据总线（DataHub）。
WITH参数
参数	注释说明	备注
endPoint	Endpoint地址	参见DataHub的Endpoint地址。
project	DataHub项目名称	无
topic	DataHub中topic名称	无
accessId	accessId	无
accessKey	accessKey	无
maxRetryTimes	最大重试次数	可选，默认值为3。
batchSize	一次批量写入的条数	可选，默认值为300。
batchWriteTimeoutMs	缓存数据的超时时间	可选，单位为毫秒，默认值为5000。表示如果缓存中的数据在等待5秒后，依然没有达到输出条件，系统会自动输出缓存中的所有数据。
maxBlockMessages	每次写入的最大Block数	可选，默认值为100。
 上一篇：创建分析型数据库（AnalyticDB）结果表

 创建日志服务（Log Service）结果表
 更新时间：2019-03-21 17:29:42

 编辑 ·
 本页目录
 什么是日志服务
 DDL定义
 WITH参数
 本文为您介绍如何创建实时计算日志服务（Log Service）结果表。

 什么是日志服务
 日志服务（Log Service）是针对日志类数据的一站式服务，在阿里巴巴集团经历大量大数据场景锤炼而成。

 DDL定义
 实时计算支持使用日志服务作为结果输出，志服务结果表声明示例如下。

 create table sls_stream(
  name VARCHAR,
  age BIGINT,
  birthday BIGINT
 )with(
  type='sls',
  endPoint='******',
  accessId='******',
  accessKey='******',
  project='******',
  logStore='******'
 );
 说明 建议使用日志服务存储注册功能，参见注册日志服务（Log Service）。
 WITH参数
 参数	注释说明	备注
 endPoint	endPoint地址	服务入口
 project	项目名	无
 topic	topic表名	无
 accessId	accessId	无
 accessKey	accessKey	无
 mode	写入方式	可选，默认为random模式，选择partition则会按分区写入。
 partitionColumn	分区列	如果mode为partition则必填。
 topic	日志服务的topic	可选，默认为空。
 source	日志的来源地，例如产生该日志机器的IP地址。	可选，默认为空。

创建消息队列（MQ）结果表
更新时间：2019-04-01 14:59:56

编辑 ·
本页目录
什么是消息列队（MQ）
CSV类格式
二进制格式
WITH参数
本文为您介绍如何创建实时计算消息队列（MQ）结果表。

什么是消息列队（MQ）
消息队列（Message Queue）简称MQ，是阿里云商用的专业消息中间件，是企业级互联网架构的核心产品。消息列队是基于高可用分布式集群技术，搭建了包括发布订阅、消息轨迹、资源统计、定时（延时）、监控报警等一套完整的消息云服务。 实时计算可以将消息队列作为流式数据输出，如下所示。
CREATE TABLE stream_test_hotline_agent (
id INTEGER,
len BIGINT,
content VARCHAR
) WITH (
type='mq',
endpoint='******',
accessID='******',
accessKey='******',
topic='******',
producerGroup='******',
tag='******',
encoding='utf-8',
fieldDelimiter=',',
retryTimes='5',
sleepTimeMs='500'
);
CSV类格式

CREATE TABLE stream_test_hotline_agent (
id INTEGER,
len BIGINT,
content varchar
) WITH (
type='mq',
endpoint='******',
accessID='******',
accessKey='******',
topic='******',
producerGroup='******',
tag='******',
encoding='utf-8',
fieldDelimiter=',',
retryTimes='5',
sleepTimeMs='500'
);
二进制格式
二进制格式测试代码如下。


CREATE TABLE source_table (
  commodity VARCHAR
)WIHT(
  type='random'
);

CREATE TABLE result_table (
  mess VARBINARY
) WITH (
  type = 'mq',
  topic = '******',
  endpoint = '******',
  accessId='******',
  accessKey='******',
  producerGroup='******'
);

INSERT INTO result_table
SELECT
CAST(SUBSTRING(commodity,0,5) AS VARBINARY) AS mess
FROM source_table
说明
cast(varchar as varbinary) 需在实时计算2.0及以上版本使用，若版本低于2.0，请先升级。
varbinary只能入参一次。
WITH参数
参数	说明	备注
topic	Message Queue队列名称	无
endpoint	地址
公共云内网接入（阿里云经典网络/VPC）：华东1、华东2、华北1、华北2、华南1香港的区域的endpoint地址为onsaddr-internal.aliyun.com:8080 。
公共云公网接入地址为http://onsaddr-internet.aliyun.com/rocketmq/nsaddr4client-internet。
accessID	填写阿里云accessID	无　
accessKey	填写阿里云accessKey	无
producerGroup	写入的群组	无
tag	写入的标签	可选，默认为空。
fieldDelimiter	字段分割符	可选，默认为\u0001 。表示在只读模式下以 \u0001（\u0001在只读模式不可见）作为分隔符；在编辑模式下以^A作为分隔符。
encoding	编码类型	可选，默认为utf-8。
retryTimes	写入的重试次数	可选，默认为10。
sleepTimeMs	重试间隔时间	可选，默认为1000（毫秒）。

创建表格存储（Table Store）结果表
更新时间：2019-04-19 19:57:25

编辑 ·
本页目录
什么是表格存储（Table Store）
DDL定义
WITH参数
类型映射
本文为您介绍如何创建实时计算表格存储（Table Store）结果表以及表格存储和实时计算字段类型之间的映射关系。

什么是表格存储（Table Store）
表格存储（Table Store），简称OTS，是构建在阿里云飞天分布式系统之上的分布式NoSQL数据存储服务。表格存储通过数据分片和负载均衡技术，实现数据规模与访问并发上的无缝扩展，提供海量结构化数据的存储和实时访问服务。

DDL定义
实时计算支持使用TableStore作为结果输出，示例代码如下。

CREATE TABLE stream_test_hotline_agent (
 name VARCHAR,
 age BIGINT,
 birthday BIGINT,
 PRIMARY KEY (name,age)
) WITH (
 type='ots',
 instanceName='yourInstanceName',
 tableName='yourTableName',
 accessId='yourAccessId',
 accessKey='yourAccessSecret',
 endPoint='yourEndpoint',
 valueColumns='birthday'
);
说明
推荐使用数据存储注册功能，参见表格存储注册表格存储（TableStore）。
valueColumns的值不能是声明的主键，可以是主键之外的任意字段。
WITH参数
参数	说明	备注
instanceName	实例名	无
tableName	表名	无
endPoint	实例访问地址	参见服务地址 。
accessId	访问的id	无
accessKey	访问的键	无
valueColumns	指定插入的字段列名	插入多个字段以,分割。如'ID,NAME'。
bufferSize	流入多少条数据后开始去重	可选，默认值5000，表示输入的数据达到5000条就开始输出。
batchWriteTimeoutMs	写入超时的时间	可选，单位为毫秒，默认值为5000。表示如果缓存中的数据在等待5秒后，依然没有达到输出条件，系统会自动输出缓存中的所有数据。
batchSize	一次批量写入的条数	可选，默认值100。
retryIntervalMs	重试间隔时间	可选，单位毫秒，默认值1000。
maxRetryTimes	最大重试次数	可选，默认值100。
ignoreDelete	是否忽略delete操作	默认为false。
类型映射
OTS字段类型	实时计算字段类型
INTEGER	BIGINT
STRING	VARCHAR
BOOLEAN	BOOLEAN
DOUBLE	DOUBLE
说明 TableStore结果表须定义有 primary key，输出数据以update方式写入到现有TableStore表。update方式说明请参见数据结果表概述中 Update类型。

创建云数据库（RDS和DRDS）结果表
更新时间：2019-04-19 19:57:54

编辑 ·
本页目录
关系型数据库（RDS）
DDL定义
WITH参数
类型映射
JDBC连接参数
FAQ
本文为您介绍如何创建实时计算云数据库（RDS和DRDS）结果表以及云数据库（RDS和DRDS）和实时计算字段类型之间的映射关系。

关系型数据库（RDS）
阿里云关系型数据库（Relational Database Service）简称RDS，是一种稳定可靠、可弹性伸缩的在线数据库服务。RDS基于阿里云分布式文件系统和高性能存储，支持MySQL、SQL Server、PostgreSQL和PPAS（Postgre Plus Advanced Server）引擎，并且提供了容灾、备份、恢复、监控、迁移等方面的全套解决方案。

DDL定义
实时计算支持使用RDS/DRDS作为结果输出（目前仅支持MySQL数据存储类型）。示例代码如下。

CREATE TABLE rds_output(
 id INT,
 len INT,
 content VARCHAR,
 PRIMARY KEY (id,len)
) WITH (
 type='rds',
 url='yourDatabaseURL',
 tableName='yourDatabaseTable',
 userName='yourDatabaseUserName',
 password='yourDatabasePassword'
);
说明
实时计算写入RDS/DRDS数据库结果表原理：针对实时计算每行结果数据，拼接成一行SQL语句，输入至目标端数据库，进行执行。如果使用批量写，需要在URL后面加上参数 ?rewriteBatchedStatements=true，以提高系统性能。
RDS MySQL数据库支持自增主键。如果需要让实时计算写入数据支持自增主键，在DDL中不声明该自增字段即可。例如，ID是自增字段，实时计算DDL不写出该自增字段，则数据库在一行数据写入过程中会自动填补相关的自增字段。
如果DRDS有分区表，拆分键必须在实时计算DDL里primary key（）中声明，否则拆分的表无法写入。关于DRDS分库分表的概念可参见DRDS分库分表。
建议使用数据存储注册方式，参见注册云数据库（RDS）。
WITH参数
参数	说明	备注
url	地址	地址请参见：
RDS的URL地址
DRDS的URL地址
tableName	表名	无
userName	用户名	无
password	密码	无
maxRetryTimes	最大重试次数	可选，默认值为3。
batchSize	一次批量写入的条数	可选，默认值为50。
bufferSize	流入多少条数据后开始去重	可选，需要指定主键才生效。默认值为1000，表示输入的数据达到1000条即开始输出。
flushIntervalMs	清空缓存的时间间隔	可选，单位为毫秒，默认值为5000。表示如果缓存中的数据在等待5秒后，依然没有达到输出条件，系统会自动输出缓存中的所有数据。
excludeUpdateColumns	忽略指定字段的更新	可选，默认值为空（默认忽略primary key字段）。表示更新主键值相同的数据时，忽略指定字段的更新。
ignoreDelete	是否忽略delete操作	可选，默认为false，表示支持delete功能。
partitionBy	分区	可选，默认为空。表示写入Sink节点前，会根据该值做hash。数据会流向相应的hash节点。
类型映射
RDS字段类型	实时计算字段类型
INTEGER	INT
FLOAT	FLOAT
DECIMAL	DECIAML
LONG	BIGINT
DOUBLE	DOUBLE
TEXT	VARCHAR
BYTE
DATE
DATETIME
TIMESTAMP
TIME
YEAR
CHAR
JDBC连接参数
参数名称	参数说明	默认值	最低版本要求
useUnicode	是否使用Unicode字符集，如果参数characterEncoding设置为gb2312或gbk，本参数值必须设置为true。	false	1.1g
characterEncoding	当useUnicode设置为true时，指定字符编码。比如可设置为gb2312或gbk。	false	1.1g
autoReconnect	当数据库连接异常中断时，是否自动重新连接。	false	1.1
autoReconnectForPools	是否使用针对数据库连接池的重连策略。	false	3.1.3
failOverReadOnly	自动重连成功后，连接是否设置为只读。	true	3.0.12
maxReconnects	autoReconnect设置为true时，重试连接的次数。	3	1.1
initialTimeout	autoReconnect设置为true时，两次重连之间的时间间隔，单位为秒。	2	1.1
connectTimeout	和数据库服务器建立socket连接时的连接超时时长，单位为毫秒。 0表示永不超时，适用于JDK 1.4及更高版本。	0	3.0.1
socketTimeout	socket操作（读写）超时，单位：毫秒。 0表示永不超时。	0	3.0.1
FAQ
Q：实时计算的结果数据写入RDS表，是按主键更新的，还是生成1条新的记录？

A：如果在DDL中定义了主键，会采用insert into on duplicate key update的方式更新记录，也就意味着对于不存在的主键字段会直接插入，存在的主键字段则更新相应的值。 如果DDL中没有声明primary key，则会用insert into 方式插入记录，追加数据。

Q：使用RDS表中的唯一索引做group by需要注意什么？

A：
需要在作业中的primary key中声明这个唯一索引。
RDS中只有一个自增主键，实时计算作业中不能声明为primary key。

创建MaxCompute（ODPS）结果表
更新时间：2019-04-10 09:55:41

编辑 ·
本页目录
DDL定义
WITH参数
常见问题
本文为您介绍如何创建MaxCompute（ODPS）结果表以及创建过程中的常见问题。

DDL定义
实时计算支持使用ODPS作为结果输出，示例代码如下。

create table odps_output(
    id INT,
    user_name VARCHAR,
    content VARCHAR
) with (
    type = 'odps',
    endPoint = 'http://service.cn.maxcompute.aliyun-inc.com/api',
    project = 'projectName',
    tableName = 'tableName',
    accessId = 'yourAccessKeyId',
    accessKey = 'yourAccessKeySecret',
    `partition` = 'ds=2018****'
);
WITH参数
参数	说明	备注
endPoint	ODPS服务地址	必选，参见MaxCompute开通Region和服务连接对照表。
tunnelEndpoint	MaxCompute Tunnel服务的连接地址	可选，参见MaxCompute开通Region和服务连接对照表。
说明 VPC环境下为必填。
project	ODPS项目名称	必选
tableName	表名	必选
accessId	accessId	必选
accessKey	accessKey	必选
partition	分区名	可选，如果存在分区表则必填。具体分区信息可在数据地图查看。例如: 一个表的分区信息为ds=20180905，则可以写 `partition` = 'ds=20180905'。多级分区之间用逗号分隔，*`partition` = 'ds=20180912,dt=xxxyyy'。
isOverwrite	写入sink之前会把结果表或者结果表的数据清空。
blink-3.2以下版本默认参数值为true。
blink-3.2版本默认参数值为false。
说明 isOverwrite参数不支持版本内修改。如果需要修改，请升级或回滚blink版本。
说明
实时计算数据写入ODPS的方式是每次做checkPoint的时候将缓存数据进行输入。

常见问题
Q: Stream模式的ODPS Sink是否支持isOverwrite为true的情况？
A：isOverwrite为true功能默认开启，即写入sink之前会把结果表或者结果数据清空。作业每次启动后和暂停恢复后、写入之前会把原来结果表或者结果分区里的内容删除。流上暂停恢复后清空数据会导致数据丢失。

Q: MaxCompute中的数据类型和实时计算中数据类型的对应关系是什么？
A：如下表。
MaxCompute	Blink
TINYINT	TINYINT
SMALLINT	SMALLINT
INT	INT
BIGINT	BIGINT
FLOAT	FLOAT
DOUBLE	DOUBLE
BOOLEAN	BOOLEAN
DATETIME	TIMESTAMP
TIMESTAMP	TIMESTAMP
STRING	VARCHAR
DECIMAL	DECIMAL
BINARY	VARBINARY
说明
其他MaxCompute类型，ODPS connector暂时还不支持转换。
VARCHAR是ODPS新增加的类型，Blink connectors暂不支持，建议您将ODPS的Schema中的VARCHAR类型设置为STRING类型。


创建云数据库（HBase）结果表
更新时间：2019-04-26 19:55:31

编辑 ·
本页目录
DDL定义
WITH参数
本文为您介绍如何创建实时计算云数据库（HBase）结果表。

说明 本文档仅适用于实时计算独享模式。
DDL定义
实时计算支持使用HBase作为结果输出。示例代码如下。
create table liuxd_user_behavior_test_front (
    row_key varchar,
    from_topic varchar,
    origin_data varchar,
    record_create_time varchar,
    primary key (row_key)
) with (
    type = 'cloudhbase',
    zkQuorum = '2',
    columnFamily = 'yourColumnFamily',
    tableName = 'yourTableName',
    batchSize = '500'
)
说明
primary key支持定义多个字段。多个字段会按照rowkeyDelimiter（默认为:）拼接起来作为row_key。
HBase做撤回删除操作时，如果Column定义了多版本，会把所有版本的值清空。
WITH参数
参数	注释说明	备注
zkQuorum	HBase集群配置的zk地址	可以在hbase-site.xml文件中找到hbase.zookeeper.quorum相关配置
zkNodeParent	集群配置在zk上的路径	可以在hbase-site.xml文件中找到hbase.zookeeper.quorum相关配置
tableName	HBase表名	无
userName	用户名	无
password	密码	无
partitionBy	是否使用joinKey进行分区	可选，默认为False。设置为True时，使用joinKey进行分区，将数据分发到各JOIN节点，提高缓存命中率。
shuffleEmptyKey	是否将上游EMPTY KEY随机发送到下游节点	可选，默认为False。参数意义如下：
False：如果上游有多个EMPTY KEY，将会将所有EMPTY KEY发送大同一个JOIN节点。
Te：如果上游有多个EMPTY KEY，将会将所有EMPTY KEY随机发送到各个JOIN节点。
说明 shuffleEmptyKey在partitionedJoin生效后才是使用。
columnFamily	列族名	目前只支持插入同一列族
maxRetryTimes	最大尝试次数	可选，默认为10
bufferSize	流入多少条数据后进行去重	默认为5000
batchSize	一次批量写入的条数	可选，默认为100
flushIntervalMs	最长插入时间	可选，默认为2000
writePkValue	是否写入主键值	可选，默认为false
stringWriteMod	是否都按照string插入	可选，默认为false
rowkeyDelimiter	rowKey的分隔符	可选，默认为:
isDynamicTable	是否为动态表	可选，默认为false
说明 建议batchSize参数值设置在200到300之间。过大的batchSize值可能导致任务OOM（内存不足）报错。

创建ElasticSearch（ES）结果表
KB: 94716 ·
更新时间：2019-04-19 19:58:22

编辑 ·
本页目录
DDL定义
WITH参数
动态索引相关 WITH 参数
本文为您介绍如何创建实时计算ElasticSearch（ES）结果表。

说明 本文档仅适用于独享模式。
DDL定义
ElasticSearch结果表的实现使用REST API，理论上兼容ElasticSearch的各个版本。实时计算支持使用ES作为结果输出。示例代码如下。

 CREATE TABLE es_stream_sink(
  field1 LONG,
  field2 VARBINARY,
  field3 VARCHAR,
  PRIMARY KEY(field1)
) WIHT (
  type ='elasticsearch',
  endPoint = 'yourEndPoint',
  accessId = 'yourAccessId',
  accessKey = 'yourAccessSecret',
  index = 'yourIndex',
  typeName = 'yourTypeName'
);
说明 ES支持根据primary key进行update，primary key只能为1个字段。
指定primary key后，document的id为primaryKey字段的值。
未指定primary key的document对应的id为随机，详情请参见Index API。
full更新模式下，后面的doc会完全覆盖之前的doc，不会原地更新字段。
inc更新模式下，会依据传入的字段值更新对应的字段。
所有的更新默认为upsert语义，即insert or update。
WITH参数
通用配置:

参数	注释说明	默认值	Required
endPoint	server地址，例：http://127.0.0.1:9211	无	是
accessId	访问实例ID	无	是
accessKey	访问实例密钥	无	是
index	索引名称，类似于数据库database的名称。	无	是
typeName	type 名称，类似于数据库的table名称。	无	是
bufferSize	流入多少条数据后开始去重	1000	否
maxRetryTimes	异常重试次数	30	否
timeout	读超时，单位为毫秒。	600000	否
discovery	是否开启节点发现。如果开启客户端会 5 分钟刷新一次 server list。	false	否
compression	是否使用 GZIP 压缩 request bodies	true	否
multiThread	是否开启 JestClient 多线程	true	否
ignoreWriteError	是否忽略写入异常	false	否
settings	创建index的settings配置	无	否
updateMode	指定 primary key 后的更新模式	full
说明
full：全量覆盖
inc：增量更新
否
动态索引相关 WITH 参数
参数	注释说明	默认值	Required
dynamicIndex	是否开启动态索引	false(true/false)	否
indexField	抽取索引的字段名	/	dynamicIndex 为 true 时必填，只支持类型 Timestamp/Date/Long(秒为单位的 timestamp)
indexInterval	切换索引的周期	d	dynamicIndex 为 true时必填
d：天
m：月
w：周
说明
仅实时计算2.2.7及以上版本支持动态索引功能。
当开启动态索引后， 基本配置中的index名称会作为后续创建索引的统一Alias，Alias和索引为一对多关系。
不同的indexInterval对应的真实索引名称：
d -> Alias + "yyyyMMdd"
m -> Alias + "yyyyMM"
w -> Alias + "yyyyMMW"
对于单个的真实索引可以使用 Index API修改，但是对于Alias只能get，若想更新Alias，请参见Index Aliases。

创建高性能时间序列数据库（HiTSDB）结果表
更新时间：2019-01-18 10:50:44

编辑 ·
本页目录
什么是高性能时间序列数据库（HiTSDB）
DDL定义
WITH参数
常见问题
本文为您介绍如何创建实时计算高性能时间序列数据库（HiTSDB）结果表。

什么是高性能时间序列数据库（HiTSDB）
高性能时间序列数据库 (High-Performance Time Series Database)简称HiTSDB。是一种高性能，低成本，稳定可靠的在线时序数据库服务。HiTSDB提供高效读写，高压缩比存储、时序数据插值及聚合计算，广泛应用于物联网（IoT）设备监控系统 ，企业能源管理系统（EMS），生产安全监控系统，电力检测系统等行业场景。

DDL定义
实时计算支持使用HiTSDB作为结果输出，示例代码如下。
说明 实时计算引用高性能时间序列数据库（HiTSDB）结果表需要配置数据存储白名单。
CREATE TABLE stream_test_hitsdb (
    metric varchar,
    timestamp INTEGER,
    value DOUBLE,
    tagk1 varchar
) WITH (
    type='hitsdb',
    host='xxxxxx',
    virtualDomainSwitch = 'xxxxxx',
    httpConnectionPool = 'xxxxxx',
    batchPutSize = 'xxxxxx'
);

建表默认格式：

第0列：metric（VARCHAR）
第1列：timestamp（INTEGER），单位：秒 。
第2列：value（DOUBLE）
第3列：tag（VARCHAR）
第4~N列：fieldName作为TagKey，fieldValue作为TagValue。
说明 metric、 timestamp、 value必须声明，且数据类型与HiTSDB保持一致。 tag可以为多列。详情请参见HiTSDB建表规范。
WITH参数
参数	注释说明	备注
host	ip或vip域名	填写注册实例的host，具体请查看：连接实例。
port	端口	默认为8242。
virtualDomainSwitch	是否使用VIPServer	默认为false，若需要使用VIPServer，则设置为true。
httpConnectionPool	HTTP连接池	默认为10。
httpCompress	使用GZIP压缩	默认为false，即不压缩。
httpConnectTimeout	HTTP连接超时时间	默认为0。
ioThreadCount	IO线程数	默认为1。
batchPutBufferSize	缓冲区大小	默认为10000。
batchPutRetryCount	写入重试次数	默认为3。
batchPutSize	每次提交数据量	默认每次提交500个数据点。
batchPutTimeLimit	缓冲区等待时间	默认为200ms。
batchPutConsumerThreadCount	序列化线程数	默认为1。
常见问题
Q：Failover中报错，LONG类型不能转换成INT类型。

A：实时计算2.2.5以下版本只能支持到INT类型。实时计算2.2.5及以上版本支持BIGINT类型。


创建Kafka结果表
更新时间：2019-04-19 19:58:50

编辑 ·
本页目录
DDL定义
WITH参数
Kafka版本对应关系
示例
本文档为您介绍如何创建实时计算Kafka结果表。

说明 本文档仅适用于独享模式。
DDL定义
Kafka结果表需要定义的DDL如下。
create table sink_kafka (
    messageKey VARBINARY,
    `message` VARBINARY,
    PRIMARY KEY (messageKey)
) with (
    type = 'kafka010',
    topic = 'yourTopicName',
    bootstrap.servers = 'yourServerAddress'
);
说明
创建Kafka结果表时，必须显示的指定primary key (messageKey)。
实时计算仅在2.2.6及以上版本中，支持阿里云Kafka或自建Kafka的TPS、RPS等指标信息的显示。
WITH参数
通用配置

参数	注释说明	备注
type	Kafka对应版本	必选，必须是 Kafka08、Kafka09、Kafka010、Kafka011中的一种，版本对应关系参见Kafka版本对应关系。
topic	写入的topic	topic名称
必选配置
Kafka08必选配置:
参数	注释说明	备注
zookeeper.connect	zk链接地址	zk连接ID
Kafka09/Kafka010/Kafka011必选配置：
参数	注释说明	备注
bootstrap.servers	Kafka集群地址	Kafka集群地址
说明 Kafka集群地址
如果您使用的Kafka是阿里云商业版，请参见Kafka商业版准备配置文档。
如果您使用的Kafka是阿里云公测版，请参见Kafka公测版准备配置文档。
可选配置参数

consumer.id
socket.timeout.ms
fetch.message.max.bytes
num.consumer.fetchers
auto.commit.enable
auto.commit.interval.ms
queued.max.message.chunks
rebalance.max.retries
fetch.min.bytes
fetch.wait.max.ms
rebalance.backoff.ms
refresh.leader.backoff.ms
auto.offset.reset
consumer.timeout.ms
exclude.internal.topics
partition.assignment.strategy
client.id
zookeeper.session.timeout.ms
zookeeper.connection.timeout.ms
zookeeper.sync.time.ms
offsets.storage
offsets.channel.backoff.ms
offsets.channel.socket.timeout.ms
offsets.commit.max.retries
dual.commit.enabled
partition.assignment.strategy
socket.receive.buffer.bytes
fetch.min.bytes
说明 其它可选配置项参考Kafka官方文档进行配置。
Kafka09
Kafka010
Kafka011
Kafka版本对应关系
type	Kafka 版本
Kafka08	0.8.22
Kafka09	0.9.0.1
Kafka010	0.10.2.1
Kafka011	0.11.0.2
示例
create table datahub_input (
id VARCHAR,
nm VARCHAR
) with (
type = 'datahub'
);

create table sink_kafka (
 messageKey VARBINARY,
`message` VARBINARY,
 PRIMARY KEY (messageKey)
) with (
    type = 'kafka010',
    topic = 'yourTopicName',
    bootstrap.servers = 'yourServerAddress'
);


INSERT INTO
    sink_kafka
SELECT
   cast(id as VARBINARY) as messageKey,
   cast(nm as VARBINARY) as `message`
FROM
    datahub_input;


创建云数据库（HybridDB for MySQL）结果表
更新时间：2019-04-19 19:59:18

编辑 ·
本页目录
什么是云数据库（HybridDB for MySQL）
DDL定义
WITH参数
本文为您介绍如何创建实时计算云数据库（HybridDB for MySQL）结果表。

什么是云数据库（HybridDB for MySQL）
云数据库HybridDB for MySQL（原名PetaData）是同时支持在线事务（OLTP）和在线分析（OLAP）的关系型 HTAP 类数据库。HTAP是Hybrid Transaction/Analytical Processing的简写，意为将数据的事务处理（TP）与分析（AP）混合处理，从而实现对数据的实时处理分析。

HybridDB for MySQL兼容MySQL的语法及函数，并且增加了对Oracle常用分析函数的支持。完全兼容TPC-H和TPC-DS测试标准。

DDL定义
实时计算支持使用HybridDB for MySQL作为结果输出。示例代码如下。

create table petadata_output(
 id INT,
 len INT,
 content VARCHAR,
 primary key(id,len)
) with (
 type='petaData',
 url='yourDatabaseURL',
 tableName='yourTableName',
 userName='yourDatabaseUserName',
 password='yourDatabasePassword'
);
说明
实时计算写入PetaData数据库结果表原理：针对实时计算每行结果数据，拼接成一行SQL向目标端数据库进行执行。
bufferSize默认值是1000，如果到达bufferSize阈值的话（buffer hashmap size），也会触发写出。因此您配置batchSize的同时还需要配上bufferSize。bufferSize和batchSize大小相同即可。
建议设置batchSize='4096'，batchSize数值不建议设置过大。
WITH参数
参数	注释说明	备注
url	地址	切换网络类型
tableName	表名	无
userName	用户名	无
password	密码	无
maxRetryTimes	最大重试次数	可选，默认为3。
batchSize	一次批量写入的条数	可选，默认值1000 ，表示每次写多少条。
bufferSize	流入多少条数据后开始去重	可选
flushIntervalMs	写超时时间	可选，单位为毫秒，默认值为3000。表示如果缓存中的数据在等待5秒后，依然没有达到输出条件，系统会自动输出缓存中的所有数据。
ignoreDelete	是否忽略delete操作	默认为false


创建自定义结果表
更新时间：2019-03-14 15:49:24

编辑 ·
本页目录
JAR包下载
2.0以上的版本依赖
接口说明
本文为您介绍如何创建实时计算自定义结果表。

说明 本文档仅适用于独享模式。
为满足各种差异化的输出需求，实时计算平台现支持用户自定义Sink插件。Maven工程需要引用以下依赖包，scope设置为<scope>provided</scope>。

JAR包下载
blink-connector-common-blink-2.2.4
blink-connector-custom-blink-2.2.4
blink-table-blink-2.2.4
flink-table_2.11-blink-2.2.4
flink-core-blink-2.2.4
2.0以上的版本依赖

   <dependencies>
    <dependency>
      <groupId>com.alibaba.blink</groupId>
      <artifactId>blink-table</artifactId>
      <version>blink-2.2.4-SNAPSHOT</version>
      <scope>provided</scope>
    </dependency>
    <dependency>
      <groupId>org.apache.flink</groupId>
      <artifactId>flink-table_2.11</artifactId>
      <version>blink-2.2.4-SNAPSHOT</version>
      <scope>provided</scope>
    </dependency>
    <dependency>
      <groupId>org.apache.flink</groupId>
      <artifactId>flink-core</artifactId>
      <version>blink-2.2.4-SNAPSHOT</version>
      <scope>provided</scope>
    </dependency>
    <dependency>
      <groupId>com.alibaba.blink</groupId>
      <artifactId>blink-connector-common</artifactId>
      <version>blink-2.2.4-SNAPSHOT</version>
      <scope>provided</scope>
    </dependency>
    <dependency>
      <groupId>com.alibaba.blink</groupId>
      <artifactId>blink-connector-custom</artifactId>
      <version>blink-2.2.4-SNAPSHOT</version>
      <scope>provided</scope>
    </dependency>
  </dependencies>
接口说明
自定义结果表class需要继承自定义Sink插件的基类，并实现如下方法：

protected Map<String,String> userParamsMap;// 用户在SQL with语句中定义的键值对，但所有的键均为小写
protected Set<String> primaryKeys;// 自定义的主键字段名
protected List<String> headerFields;// 标记为header的字段列表
protected RowTypeInfo rowTypeInfo;//字段类型和名称
/**
 * 初始化方法。每次初始建立和Failover的时候会调用一次
 *
 * @param taskNumber 当前节点的编号
 * @param numTasks   Sink节点的总数
 * @throws IOException
 */
public abstract void open(int taskNumber,int numTasks) throws IOException;

/**
 * close方法，释放资源
 *
 * @throws IOException
 */
public abstract void close() throws IOException;

/**
 * 处理插入单行数据
 *
 * @param row
 * @throws IOException
 */
public abstract void writeAddRecord(Row row) throws IOException;

/**
 * 处理删除单行数据
 *
 * @param row
 * @throws IOException
 */
public abstract void writeDeleteRecord(Row row) throws IOException;

/**
 * 如果进行批量插入，该方法需要把线程中缓存的数据全部刷入下游存储；若无，可不实现此方法。
 *
 * @throws IOException
 */
public abstract void sync() throws IOException;

/**
* 返回类名
*/
public String getName();
在实时计算平台上传JAR包，引用资源之后，对于自定义的Sink插件，需要指明 type = 'custom'，并且指明实现接口的class，如下以自定义的Redis结果表（Demo下载）为例。
create table in_table(
    kv varchar
)with(
    type = 'random'
);

create table out_table(
    `key` varchar,
    `value` varchar
)with(
    type = 'custom',
    class = 'com.alibaba.blink.connector.custom.demo.RedisSink',
    -- **可以定义更多的用户参数, 在 open 函数中可以通过 userParamsMap 获取**
    host = 'r-ufXXXXXXX.redis.rds.aliyuncs.com',
    port = '6379',
    db = '0',
    batsize = '10',
    password = 'xxxxxx'
);

insert into out_table
select
substring(kv,0,4) as `key`,
substring(kv,0,6) as `value`
from in_table;
Redis Sink插件的参数说明如下。
参数	说明	是否必填	备注
host	redis实例内网连接地址（host）	是	无
port	redis实例端口号	是	无
password	redis连接密码	是	无
db	db编号	否	默认值为0，代表db0
batchsize	批量写入大小	否	默认值为1，代表不攒批写入

创建SQL Server结果表
更新时间：2019-04-22 16:45:31

编辑 ·
本页目录
DDL定义
WITH参数
本文为您介绍如何创建实时计算SQL Server结果表。

DDL定义
实时计算支持使用SQL Server作为结果输出。示例代码如下。
create table ss_output(
 id INT,
 len INT,
 content VARCHAR,
 primary key(id,len)
) with (
 type='jdbc',
 url='jdbc:sqlserver://ip:port;database=****',
 tableName='yourDatabaseTableName',
 userName='yourDatabaseUserName',
 password='yourDatabasePassword'
);
说明 实时计算引用的SQL Server真实表需要定义主键，否则初始化阶段会产生NPE（NullPointerException）报错。
WITH参数
参数	注释说明	备注
url	jdbc连接地址	地址请参见：
RDS的URL地址
DRDS的URL地址
tableName	表名	无
username	账号	无
password	密码	无
maxRetryTimes	写入重试次数	可选，默认为3
bufferSize	流入多少条数据后开始去重	可选，默认为500，表示输入的数据达到500条就开始输出。
flushIntervalMs	清空缓存的时间间隔	可选，单位为毫秒，默认值为5000。表示如果缓存中的数据在等待5秒后，依然没有达到输出条件，系统会自动输出缓存中的所有数据。
excludeUpdateColumns	忽略指定字段的更新	可选，默认值为空（默认忽略primary key字段）。表示更新主键值相同的数据时，忽略指定字段的更新。
ignoreDelete	是否忽略delete操作	默认为false
 上一篇：创建自定义结果表

数据维表概述
更新时间：2019-01-29 09:55:35

编辑 ·
本页目录
示例
INDEX语法
维表、源表和结果表的区别
实时计算中没有专门为维表设计的DDL语法，增加一行PERIOD FOR SYSTEM_TIME的声明，即可使用标准的CREATE TABLE语法。这行声明定义了维表的变化周期，即表明该表是一张会变化的表。

示例
CREATE TABLE white_list (
  id varchar,
  name varchar,
  age int,
  PRIMARY KEY (id),  -- 用作维表时，必须有声明的主键。
  PERIOD FOR SYSTEM_TIME  -- 定义维表的变化周期
) with (
  type = 'xxxxxx',
  ...
)
说明
声明一个维表的时候，必须要指名主键。维表Join的时候，on的条件必须包含所有主键的等值条件。
目前只支持源表INNER JOIN或LEFT JOIN维表。
维表的唯一键（UK）必须为数据库中的唯一键。维表声明的唯一键如果不是数据库表的唯一键会产生以下2点影响。
维表的读取变慢。
维表JOIN时，会从第一条数据做JOIN，在加入Job的过程中，相同Key的多条记录在DB中按顺序发生变化，可能导致JOIN结果的错误。
INDEX语法
说明 建议在实时计算2.2.7及以上版本使用 INDEX语法。
在2.2版本之前，维表定义要求声明 PRIMARY KEY，这种情况下只能实现一对一连接。为支持一对多连接的需求，引入了 INDEX语法。（非 cache All的维表Join目前是通过 INDEX LOOKUP的方式实现的，Batch作业后续可能根据 COST选择 SCAN的方式）。
CREATE TABLE Persons (
    ID bigint,
    LastName varchar,
    FirstName varchar,
    Nick varchar,
    Age int,
    [UNIQUE] INDEX(LastName,FirstName,Nick), --定义 index,不需要具体的类型(如 fulltext/clustered...)
    PERIOD FOR SYSTEM_TIME
) with (
  type='xxx',
  ...
);
UNIQUE INDEX表示 一对一连接，而 INDEX表示 一对多连接。
说明
UNIQUE CONSTRAINT（UNIQUE KEY）在2.2.7及以后版本中支持（和大部分RDBMS一样，声明了UNIQUE CONSTRAINT后，间接提供了UNIQUE INDEX属性），之前版本可以使用PRIMARY KEY的定义。
在生成执行计划时，引擎优先采用UNIQUE INDEX，即若DDL中使用INDEX，但Join等值连接条件中同时包含UNIQUE/NON-UNIQUE INDEX时，会优先使用UNIQUE INDEX进行右表数据查找。
支持一对多连接的维表类型包括RDS，ODPS（仅支持cache All模式，不支持随机访问）。
可增加了maxJoinRows参数，表示一对多连接时，左表一条记录连接右表的最大记录数（默认值为1024），注意一对多连接的记录数过多时，需要考虑对Cache的内存需求变大（cacheSize限制的是左表key个数），单条左表记录对应的右表记录较多时，可能会极大的影响流任务的性能。
维表、源表和结果表的区别
源表	结果表	维表
是否能驱动计算	是	否	否
是否能读取数据	是，直接读取。	否	是，仅通过源表和维表join读取。
是否能写入数据	否	是	否
是否支持Cache	否	否	是

创建表格存储（Table Store）维表
更新时间：2018-12-27 18:56:02


本页目录
什么是表格存储（Table Store）
示例
WITH参数
CACHE参数
测试案例
本文为您介绍如何创建实时计算表格存储（Table Store）维表。

什么是表格存储（Table Store）
表格存储（Table Store）简称OTS，是根据99.99%的高可用以及11个9的数据可靠性的设计标准，构建在阿里云飞天分布式系统之上的分布式NoSQL数据存储服务。表格存储通过数据分片和负载均衡技术，实现数据规模与访问并发上的无缝扩展，提供海量结构化数据的存储和实时访问服务。

示例
实时计算支持表格存储（Table Store）作为维表，示例如下。

CREATE TABLE ots_dim_table (
 id int,
 len int,
 content VARCHAR,
 PRIMARY KEY (id),
 PERIOD FOR SYSTEM_TIME--定义了维表的变化周期，即表明该表是一张会变化的表。
) WITH (
 type='ots',
 endPoint='xxxxxx'
 instanceName='yourInstanceName',
 tableName='yourTableName',
 accessId='xxxxxx',
 accessKey='xxxxxx',
);
说明 声明一个维表的时候，必须要指名主键。维表JOIN的时候，ON的条件必须包含所有主键的等值条件。OTS的主键即表的rowkey。
WITH参数
参数	注释说明
instanceName	实例名
tableName	表名
endPoint	实例访问地址
accessId	访问的ID
accessKey	访问的键
CACHE参数
参数	注释说明	备注
cache	缓存策略	默认为 None, 可选 LRU。
cacheSize	缓存大小	当选择 LRU缓存策略后，可以设置缓存大小，默认为10000 行。
cacheTTLMs	缓存超时时间，单位为毫秒。	当选择 LRU缓存策略后，可以设置缓存失效的超时时间。
测试案例
CREATE TABLE datahub_input1 (
id            BIGINT,
name        VARCHAR,
age           BIGINT
) WITH (
type='datahub'
);

create table phoneNumber(
name VARCHAR,
phoneNumber bigint,
primary key(name),
PERIOD FOR SYSTEM_TIME--定义维表的变化周期
)with(
type='ots'
);

CREATE table result_infor(
id bigint,
phoneNumber bigint,
name VARCHAR
)with(
type='rds'
);

INSERT INTO result_infor
SELECT
t.id
,w.phoneNumber
,t.name
FROM datahub_input1 as t
JOIN phoneNumber FOR SYSTEM_TIME AS OF PROCTIME() as w --维表JOIN必须指定
ON t.name = w.name;
关于维表详细语法请参见维表JOIN语句。

创建云数据库（RDS和DRDS）维表
更新时间：2018-12-27 18:56:21


本页目录
云数据库RDS版
示例
WITH参数
Cache 参数
测试案例
本文为您介绍如何创建实时计算云数据库（RDS和DRDS）维表。

云数据库RDS版
阿里云关系型数据库（Relational Database Service，简称 RDS）是一种稳定可靠、可弹性伸缩的在线数据库服务。基于阿里云分布式文件系统和高性能存储，RDS支持MySQL、SQL Server、PostgreSQL和PPAS（Postgre Plus Advanced Server，一种高度兼容 Oracle 的数据库）引擎，并且提供了容灾、备份、恢复、监控、迁移等方面的全套解决方案，彻底解决数据库运维的烦恼。

说明 云数据库(RDS/DRDS)插件中的WITH参数一致，可以通用。 在使用云数据库(RDS和DRDS)作为维表时，RDS或DRDS中必须要有真实的表存在。
示例
实时计算支持使用RDS或DRDS作为维表（注意：目前仅支持MySQL数据存储类型），示例代码如下。

CREATE TABLE rds_dim_table(
 id int,
 len int,
 content VARCHAR,
 PRIMARY KEY (id),
 PERIOD FOR SYSTEM_TIME--定义维表的变化周期，表明该表是一张会变化的表。
) with (
 type='rds',
 url='xxxxxx',
 tableName='xxxxxx',
 userName='xxxxxx',
 password='xxxxxx'
);
说明 声明一个维表时，必须要指名主键。维表JOIN的时候，ON的条件必须包含所有主键的等值条件。RDS或DRDS的主键可以定义为表的主键或是唯一索引列。
WITH参数
参数	注释说明	备注
url	地址	地址请参见
RDS的URL地址
DRDS的URL地址
tableName	表名	无
userName	用户名	无
password	密码	无
maxRetryTimes	最大尝试插入次数	可选，默认为3。
Cache 参数
参数	注释说明	备注
cache	缓存策略	默认为 None, 可选 LRU或ALL。
cacheSize	缓存大小	当选择 LRU 缓存策略后，可以设置缓存大小，默认 10000 行。
cacheTTLMs	缓存超时时间，单位为毫秒。	当选择 LRU 缓存策略后，可以设置缓存失效的超时时间，默认不过期。当选择 ALL 策略，则为缓存reload 的间隔时间，默认不重新加载。
cacheReloadTimeBlackList	缓存策略选择ALL 时启用。更新时间黑名单，防止在此时间内做cache 更新。（如双11场景。）	可选，默认为空。自定义输入格式为2017-10-24 14:00 -> 2017-10-24 15:00, 2017-11-10 23:30 -> 2017-11-11 08:00。用逗号,来分隔多个黑名单，用箭头->来分割黑名单的起始结束时间。
目前RDS/DRDS提供如下三种缓存策略。

None：无缓存。
LRU：最近使用策略缓存。需要配置相关参数：缓存大小（cacheSize）和 缓存超时时间（cacheTTLMs）。
ALL：全量缓存策略。在Job运行前会将远程表中所有数据load到内存中，之后所有的维表查询都会通过 cache进行。cache命中不到则不存在，并在缓存过期后重新加载一遍全量缓存。全量缓存策略适合远程表数据量小、miss key多的场景。全量缓存相关配置：缓存更新间隔（cacheTTLMs），更新时间黑名单（cacheReloadTimeBlackList）。
说明
因为会异步reload，使用cache all的时候，需要将维表JOIN的节点增加一些内存，增加的内存大小为远程表两倍的数据量。
使用cache all，请特别注意节点的内存，防止内存溢出。
测试案例
CREATE TABLE datahub_input1 (
id            BIGINT,
name        VARCHAR,
age           BIGINT
) WITH (
type='datahub'
);
create table phoneNumber(
name VARCHAR,
phoneNumber bigint,
primary key(name),
PERIOD FOR SYSTEM_TIME--定义维表的变化周期
)with(
type='rds'
);
CREATE table result_infor(
id bigint,
phoneNumber bigint,
name VARCHAR
)with(
type='rds'
);
INSERT INTO result_infor
SELECT
t.id
,w.phoneNumber
,t.name
FROM datahub_input1 as t
JOIN phoneNumber FOR SYSTEM_TIME AS OF PROCTIME() as w --维表JOIN必须指定
ON t.name = w.name;
关于维表详细语法请参见维表JOIN语句。

创建云数据库（HBase）维表
更新时间：2018-12-27 18:56:40


本页目录
示例
参数
CACHE参数
本文为您介绍如何创建实时计算云数据库（HBase）维表。

说明 云数据库（HBase）维表的JOIN语法详见： 维表JOIN语句。
示例
CREATE TABLE hbase (
   `key` varchar,
   `name` varchar,
    PRIMARY KEY (`key`), -- hbase中的rowkey 字段
    PERIOD FOR SYSTEM_TIME --维表标识。
   ) with (
    TYPE = 'cloudhbase',
    zkQuorum = 'xxxxxx',
    columnFamily = 'xxxxxx',
    tableName = 'xxxxxx'
);
说明 声明维表时，必须要指名主键。维表JOIN的时候，ON的条件必须包含所有主键的等值条件。HBase中的主键即rowkey。
参数
参数	注释说明	备注
zkQuorum	HBase集群配置的zk地址,是以,分隔的主机列表。	可以在hbase-site.xml文件中找到hbase.zookeeper.quorum相关配置。
zkNodeParent	集群配置在zk上的路径	可以在hbase-site.xml文件中找到hbase.zookeeper.quorum相关配置。
tableName	HBase表名	无
columnFamily	列族名	目前只支持插入同一列族
userName	用户名	无
password	密码	无　
maxRetryTimes	最大尝试次数	默认10次
partitionedJoin	设置为true之后会在用joinKey做partition，将数据分发到join节点，提高缓存命中率。	可选，默认关闭。
shuffleEmptyKey	设置为true之后遇到空key会随机往下游做shuffle，否则往0号下游发。	建议打开
CACHE参数
参数	注释说明	备注
cache	缓存策略	默认 None, 可选 LRU, ALL。
cacheSize	缓存大小	当选择 LRU 缓存策略后，可以设置缓存大小，默认 10000 行。
cacheTTLMs	缓存超时时间，单位为毫秒。	当选择 LRU 缓存策略后，可以设置缓存失效的超时时间，默认不过期。当选择 ALL 策略，则为缓存reload 的间隔时间，默认不重新加载。
cacheReloadTimeBlackList	缓存策略选择ALL时启用。更新时间黑名单，防止在此时间内做cache更新。（如双11场景。）	可选，默认为空。自定义输入格式为
为2017-10-24 14:00 -> 2017-10-24 15:00, 2017-11-10 23:30 -> 2017-11-11
            08:00
。用逗号,来分隔多个黑名单，用箭头->来分割黑名单的起始结束时间。
cacheScanLimit	缓存策略选择ALL时启用。load全量HBase数据，服务端一次RPC返回给客户端的行数。	可选，默认100条。
目前RDS和DRDS提供如下三种缓存策略。

None：无缓存。
LRU：最近使用策略缓存。需要配置相关参数：缓存大小（cacheSize）和 缓存超时时间（cacheTTLMs）。
ALL：全量缓存策略。在Job运行前会将远程表中所有数据load到内存中，之后所有的维表查询都会通过cache进行。cache命中不到，则会在缓存过期后重新加载一遍全量缓存。全量缓存策略适合远程表数据量小、miss key多的场景。全量缓存相关配置：缓存更新间隔（cacheTTLMs），更新时间黑名单（cacheReloadTimeBlackList）。
说明 因为会异步reload，使用cache all的时候，需要将维表JOIN的节点增加一些内存，增加的内存大小为远程表2倍的数据量。

创建MaxCompute（ODPS）维表
更新时间：2019-04-10 09:56:22

编辑 ·
本页目录
创建MaxCompute（ODPS）维表示例
WITH参数
Cache参数
METRIC
如何查看ODPS分区名
常见问题
说明
推荐实时计算2.1.1及以上版本使用。
维表的Query语法参见： 维表JOIN语句。
使用ODPS表作为维表，要先赋权读权限给ODPS账号。
创建MaxCompute（ODPS）维表示例
CREATE TABLE white_list (
  id varchar,
  name varchar,
  age int,
  PRIMARY KEY (id),
  PERIOD FOR SYSTEM_TIME --定义了维表的标识。
) WITH (
  type = 'odps',
  endPoint = 'http://service.cn.maxcompute.aliyun-inc.com/api',
  project = 'projectName',
  tableName = 'tableName',
  accessId = 'yourAccessKeyId',
  accessKey = 'yourAccessKeySecret',
  `partition` = 'ds=2018****',
  cache = 'ALL'
)
说明
声明维表时，必须要指名主键，维表JOIN的时候，ON的条件必须包含所有主键的等值条件。
ODPS维表主键必须有唯一性，否则会被去重。
parition是关键字，使用时需要使用反引号注释`partition`。
如果是分区表，目前不支持将分区列写入到schema定义中。
实时计算2.2.0及以上版本支持加载最新分区表，配置方法为partition='max_pt()'，max_pt()为所有分区的字典序最大值。
WITH参数
参数	注释说明	备注
endPoint	ODPS服务地址	必选，参见MaxCompute开通Region和服务连接对照表。
tunnelEndpoint	MaxCompute Tunnel服务的连接地址	可选，参见MaxCompute开通Region和服务连接对照表。
说明 VPC环境下为必填。
project	ODPS项目名称	必选
tableName	表名	必选
accessId	accessId	必选
accessKey	accessKey	必选
partition	分区名	可选，分区表必填，具体分区信息到数据地图查看。例如: 一个表的分区信息为ds=20180905，则可以写 `partition` = 'ds=20180905'。多级分区之间用逗号分隔，示例: `partition` = 'ds=20180912,dt=xxxyyy'
maxRowCount	可加载的最大表格数量	可选，默认为100000。
说明 如果您的数据超过100000，需要设置maxRowCount参数。建议设定值比实际值大。
Cache参数
参数	注释说明	备注
cache	缓存策略	默认None, 可选 LRU, ALL
cacheSize	缓存大小	当选择LRU缓存策略后，可以设置缓存大小，ODPS默认缓存值为100000行。
cacheTTLMs	缓存超时时间，单位毫秒。	当选择LRU 缓存策略后，可以设置缓存失效的超时时间，默认为不过期。当选择 ALL 策略，则为缓存reload的间隔时间，默认为不重新加载。
cacheReloadTimeBlackList	ALL Cache时启用，更新时间黑名单，防止在此时间内做cache更新（如双11场景）。	可选，默认为空，格式为2017-10-24 14:00 -> 2017-10-24 15:00, 2017-11-10 23:30 -> 2017-11-11 08:00。用逗号,来分隔多个黑名单，用箭头->来分割黑名单的起始结束时间。
cacheScanLimit	ALL Cache 时启用，load全量HBase数据，服务端一次RPC返回给客户端的行数。	可选，默认为100条。
目前ODPS维表只支持ALL全量缓存策略，必须显式声明。

ALL: 全量缓存策略。即在Job运行前会将远程表中所有数据load到内存中，之后所有的维表查询都会走cache，cache命中不到则不存在，并在缓存过期后重新加载一遍全量缓存。全量缓存策略适合远程表不大、miss key特别多的场景。全量缓存策略需要配置：缓存更新间隔（ cacheTTLMs）和更新时间黑名单（ cacheReloadTimeBlackList）。
说明 注意：使用ALL Cache的时候，由于会进行异步Reload，需要将维表JOIN的节点增加内存，增加的内存大小为远程表两倍的数据量。
METRIC
维表JOIN可以查看关联率，缓存命中率等METRIC信息。目前Bayes平台还不能查看，只能通过kmonitor。
查询语句	说明
fetch qps	查询维表总qps，包括命中和不命中。对应的Metric Name：blink.projectName.jobName.dimJoin.fetchQPS 。
fetchHitQPS	维表命中qps，包括换成命中和查询物理维表命中，对应Metric Name：blink.projectName.jobName.dimJoin.fetchHitQPS。
cacheHitQPS	维表缓存命中qps，对应Metric Name：blink.projectName.jobName.dimJoin.cacheHitQPS
dimJoin.fetchHit	维表关联率，对应Metric Name： blink.projectName.jobName.dimJoin.fetchHit 。
dimJoin.cacheHit	维表缓存关联率，对应Metric Name：blink.projectName.jobName.dimJoin.cacheHit 。
如何查看ODPS分区名
进入数据地图。
搜索表名。
在数据表详情界面的明细信息 > 分区信息中进行查看。例如：adm_dim_csn_trans_shift的分区是ds=20180905

。
常见问题
Q：任务出现了RejectedExecutionException: Task java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTas的Failover该怎么处理？

A：实时计算1.x版本中维表JOIN存在一定的问题，推荐升级到2.1.1及以上实时计算版本。如果需要继续使用原有版本，需要对作业进行暂停恢复操作，根据failover history中第一次出现failover的具体报错信息进行排查。

Q：MaxCompute中的数据类型和实时计算中数据类型的对应关系是什么？

A：如下表。
MaxCompute	Blink
TINYINT	TINYINT
SMALLINT	SMALLINT
INT	INT
BIGINT	BIGINT
FLOAT	FLOAT
DOUBLE	DOUBLE
BOOLEAN	BOOLEAN
DATETIME	TIMESTAMP
TIMESTAMP	TIMESTAMP
VARCHAR	VARCHAR
STRING	STRING
DECIMAL	DECIMAL
BINARY	VARBINARY
说明 其他MaxCompute类型，ODPS connector暂时还没有支持转换。

INSERT INTO语句
更新时间：2019-01-27 16:27:11

编辑 ·
 · 我的收藏
本页目录
语法
示例
操作约束
本文为您介绍如何在实时使计算中使用INSERT INTO语句以及INSERT INTO的操作约束。

语法
INSERT INTO tableName
      [ (columnName[ , columnName]*) ]
          queryStatement;
示例
INSERT INTO LargeOrders
SELECT * FROM Orders WHERE units > 1000;
INSERT INTO Orders(z, v)
SELECT c,d FROM OO;
说明
单个实时计算作业支持在一个SQL作业里面包含多个DML操作，同样也允许包含多个数据源、多个数据目标端、多个维表。例如，在一个作业文件里面包含两段完全业务上独立的SQL，分别写出到不同的数据目标端。
实时计算不支持单独的SELECT查询，必须有CREATE VIEW或这是在INSERT INTO内才能操作。
INSERT INTO支持UPDATA更新。例如，向RDS的表插入一个KEY值。如果这个KEY值存在就会更新，如果不存在就会插入一条新的KEY值。
操作约束
表类型	操作约束
源表	只能引用（FROM），不可执行INSERT。
维表	只能引用（JOIN），不可执行INSERT。
结果表	仅支持INSERT操作。
视图	只能引用（FROM）。

SELECT语句
更新时间：2019-01-24 14:12:17

编辑 ·
 · 我的收藏
本页目录
语法
测试数据
示例一
示例二
示例三
子查询
SELECT语句用于从表中选取数据。

语法
SELECT [ DISTINCT ]
{ * | projectItem [, projectItem ]* }
FROM tableExpression;
测试数据
a（VARCHAR）	b（INT）	c（DATE）
a1	211	1990-02-20
b1	120	2018-05-12
c1	89	2010-06-14
a1	46	2016-04-05
示例一
测试语句
SELECT * FROM 表名；
测试结果
a（VARCHAR）	b（INT）	c（DATE）
a1	211	1990-02-20
b1	120	2018-05-12
c1	89	2010-06-14
a1	46	2016-04-05
示例二
测试语句
SELECT a, c AS d FROM 表名；
测试结果
a（VARCHAR）	d（DATE）
a1	1990-02-20
b1	2018-05-12
c1	2010-06-14
a1	2016-04-05
示例三
测试语句
SELECT DISTINCT a FROM 表名；
测试结果
a（VARCHAR）
a1
b1
c1
子查询
普通的SELECT是从几张表中读数据，如SELECT column_1, column_2 … FROM table_name，但查询的对象也可以是另外一个SELECT操作。

说明 当查询的对象是另一个SELECT操作时，必须为子查询加别名。示例如下。
示例语句
INSERT INTO result_table
SELECT * FROM
               (SELECT   t.a,
                         sum(t.b) AS sum_b
                FROM     t1 t
                GROUP BY t.a
               ) t1
WHERE  t1.sum_b > 100;

示例结果
a（VARCHAR）	b（INT）
a1	211
b1	120
a1	257

WHERE语句
更新时间：2018-12-27 18:58:14


本页目录
语法
示例
WHERE语句可用于对SELECT语句中的数据进行筛选。

语法
SELECT [ ALL | DISTINCT ]
{ * | projectItem [, projectItem ]* }
FROM tableExpression
[ WHERE booleanExpression ];
下面的运算符可在WHERE语句中使用。
操作符	描述
=	等于
<>	不等于
>	大于
>=	大于等于
<	小于
<=	小于等于
示例
测试数据
Address	City
Oxford Street	Beijing
Fifth Avenue	Beijing
Changan Street	shanghai
测试语句
SELECT * FROM XXXX WHERE City='Beijing'

测试结果
Address	City
Oxford Street	Beijing
Fifth Avenue	Beijing


HAVING语句
更新时间：2019-01-27 12:42:52

编辑 ·
 · 我的收藏
本页目录
语法
示例
在使用聚合函数时，您需要添加HAVING语句，以实现与WHERE语句一样的过滤效果。

语法
  SELECT [ ALL | DISTINCT ]{ * | projectItem [, projectItem ]* }
  FROM tableExpression
  [ WHERE booleanExpression ]
  [ GROUP BY { groupItem [, groupItem ]* } ]
  [ HAVING booleanExpression ];
示例
测试数据
Customer	OrderPrice
Bush	1000
Carter	1600
Bush	700
Bush	300
Adams	2000
Carter	100
测试语句
SELECT Customer,SUM(OrderPrice) FROM XXX
GROUP BY Customer
HAVING SUM(OrderPrice)<2000;
测试结果
Customer	SUM（OrderPrice）
Carter	1700


GROUP BY语句
更新时间：2018-12-27 18:59:24


本页目录
语法
示例
GROUP BY语句用于根据一个或多个列对结果集进行分组。

语法
SELECT [ DISTINCT ]
{ * | projectItem [, projectItem ]* }
FROM tableExpression
[ GROUP BY { groupItem [, groupItem ]* } ];
示例
测试数据
Customer	OrderPrice
Bush	1000
Carter	1600
Bush	700
Bush	300
Adams	2000
Carter	100
测试语句
SELECT Customer,SUM(OrderPrice) FROM xxx
GROUP BY Customer;
测试结果
Customer	SUM(OrderPrice)
Bush	2000
Carter	1700
Adams	2000

JOIN语句
更新时间：2019-04-19 10:32:29

编辑 ·
 · 我的收藏
本页目录
语法
示例1
示例2
实时计算的JOIN和传统批处理JOIN的语义一致，都用于将两张表联系起来。区别的是实时计算联系的是两张动态表，联系的结果也会动态更新以保证最终结果和批处理结果保持一致。

语法
tableReference [, tableReference ]* | tableexpression
[ LEFT ] JOIN tableexpression [ joinCondition ];

说明
只支持等值连接，不支持不等连接。
只支持INNER JOIN和LEFT OUTER JOIN两种JOIN方式。
示例1
测试数据
Orders：

rowtime	productId	orderId	units
10:17:00	30	5	4
10:17:05	10	6	1
10:18:05	20	7	2
10:18:07	30	8	20
11:02:00	10	9	6
11:04:00	10	10	1
11:09:30	40	11	12
11:24:11	10	12	4
Products：

productId	name	unitPrice
30	Cheese	17
10	Beer	0.25
20	Wine	6
30	Cheese	17
10	Beer	0.25
10	Beer	0.25
40	Bread	100
10	Beer	0.25
测试语句
  SELECT o.rowtime, o.productId, o.orderId, o.units,p.name, p.unitPrice
  FROM Orders AS o
  JOIN Products AS p
  ON o.productId = p.productId;

测试结果
rowtime	productId	orderId	units	name	unitPrice
10:17:00	30	5	4	Cheese	17
10:17:05	10	6	1	Beer	0.25
10:18:05	20	7	2	Wine	6
10:18:07	30	8	20	Cheese	17
11:02:00	10	9	6	Beer	0.25
11:04:00	10	10	1	Beer	0.25
11:09:30	40	11	12	Bread	100
11:24:11	10	12	4	Beer	0.25
示例2
测试数据
datahub_stream1：

a（BIGINT）	b（BIGINT）	c（VARCHAR）
0	10	test11
1	10	test21
datahub_stream2：

a（BIGINT）	b（BIGINT）	c（VARCHAR）
0	10	test11
1	10	test21
0	10	test31
1	10	test41
测试语句
SELECT s1.c,s2.c
FROM datahub_stream1 AS s1
JOIN datahub_stream2 AS s2
ON s1.a =s2.a
WHERE s1.a = 0;

测试结果
s1.c（VARCHAR）	s2.c（VARCHAR）
test11	test11
test11	test31

维表JOIN语句
更新时间：2019-01-27 16:27:35

编辑 ·
 · 我的收藏
本页目录
维表JOIN语法
示例
维表是一张不断变化的表，因此在JOIN维表的时候，需指明这条记录关联维表快照的时刻。目前维表JOIN仅支持对当前时刻维表快照的关联。（未来会支持关联左表rowtime所对应的维表快照。）

维表JOIN语法
SELECT column-names
FROM table1  [AS <alias1>]
[LEFT] JOIN table2 FOR SYSTEM_TIME AS OF PROCTIME() [AS <alias2>]
ON table1.column-name1 = table2.key-name1
例如，事件流JOIN白名单维表的SQL如下。

SELECT e.*, w.*
FROM event AS e
JOIN white_list FOR SYSTEM_TIME AS OF PROCTIME() AS w
ON e.id = w.id
说明
维表支持INNER JOIN和LEFT JOIN，不支持RIGHT JOIN或FULL JOIN。
必须加上FOR SYSTEM_TIME AS OF PROCTIME()，表示JOIN维表当前时刻所看到的每条数据。
JOIN行为只发生在处理时间（processing time），即使维表中的数据新增、更新或删除，已关联的数据也不会被改变或撤回。
ON条件必须包含维表PRIMARY KEY的等值条件（且要求与真实表定义一致），但除此之外，ON条件中也可以有其他等值条件。
维表和维表不能做JOIN。
示例
测试数据
nameinfo：

id（bigint）	name（varchar）	age（bigint）
1	lilei	22
2	hanmeimei	20
3	libai	28
phoneNumber：

name（varchar）	phoneNumber（bigint）
dufu	18867889855
baijuyi	18867889856
libai	18867889857
lilei	18867889858
测试语句
CREATE TABLE datahub_input1 (
id            BIGINT,
name        VARCHAR,
age           BIGINT
) WITH (
type='datahub'
);

create table phoneNumber(
name VARCHAR,
phoneNumber bigint,
primary key(name),
PERIOD FOR SYSTEM_TIME
)with(
type='rds'
);

CREATE table result_infor(
id bigint,
phoneNumber bigint,
name VARCHAR
)with(
type='rds'
);

INSERT INTO result_infor
SELECT
t.id,
w.phoneNumber,
t.name
FROM datahub_input1 as t
JOIN phoneNumber FOR SYSTEM_TIME AS OF PROCTIME() as w
ON t.name = w.name;
测试结果
id（bigint）	phoneNumber（bigint）	name（varchar）
1	18867889858	lilei
3	18867889857	libai

UNION ALL语句
更新时间：2019-01-24 14:12:58

编辑 ·
 · 我的收藏
本页目录
语法
示例
UNION ALL语句将两个流式数据合并。要求两个流式数据的字段完全一致，包括字段类型和字段顺序。

语法
select_statement
UNION ALL
select_statement;
说明 实时计算同样支持 UNION函数。 UNION ALL允许重复值， UNION不允许重复值。在实时计算底层， UNION是 UNION ALL + Distinct ，运行效率较低，一般不推荐使用 UNION。
示例
测试数据
test_source_union1：

a（varchar）	b（bigint）	c（bigint）
test1	1	10
test_source_union2：

a（varchar）	b（bigint）	c（bigint）
test1	1	10
test2	2	20
test_source_union3：

a（varchar）	b（bigint）	c（bigint）
test1	1	10
test2	2	20
test1	1	10
测试语句
SELECT
    a,
    sum(b),
    sum(c)
FROM
    (SELECT * from test_source_union1
    UNION ALL
    SELECT * from test_source_union2
    UNION ALL
    SELECT * from test_source_union3
    )t
 GROUP BY a;
测试结果
d（varchar）	e（bigint）	f（bigint）
test1	1	10
test2	2	20
test1	2	20
test1	3	30
test2	4	40
test1	4	40

TopN语句
更新时间：2019-03-12 17:41:51

编辑 ·
 · 我的收藏
本页目录
语法
示例1
示例2
无排名优化
TopN语句用于对实时数据中某个指标的前N个最值的筛选。Flink SQL可以基于OVER窗口操作灵活地完成TopN的功能。

语法
SELECT *
FROM (
  SELECT *,
    ROW_NUMBER() OVER ([PARTITION BY col1[, col2..]]
    ORDER BY col1 [asc|desc][, col2 [asc|desc]...]) AS rownum
  FROM table_name)
WHERE rownum <= N [AND conditions]
说明
ROW_NUMBER()：行号计算函数OVER的窗口，行号计算从1开始。
PARTITION BY col1[, col2..] ： 指定分区的列，可以不指定。
ORDER BY col1 [asc|desc][, col2 [asc|desc]...]：指定排序的列和每列的排序方向。
如上语法所示，TopN需要两层query。

查询中使用 ROW_NUMBER() 窗口函数来对数据根据排序列进行排序并标上排名。
外层查询中对排名进行过滤，只取前N条。例如N=10即为取前10条的数据。
在执行过程中，Flink SQL会对输入的数据流根据排序键进行排序。如果某个分区的前N条记录发生了改变，则会将改变的那几条数据以更新流的形式发给下游。

说明 如果需要将TopN的数据输出到外部存储，后接的结果表必须是一个带主键的表。
WHERE条件的限制

为了使Flink SQL能识别出这是一个TopN的query，外层循环中必须要指定 rownum <= N的格式来指定前N条记录，不能使用rownum - 5 <= N 这种将rownum至于某个表达式中。当然，WHERE条件中，可以额外带上其他条件，但是必须是以AND连接。

示例1
如下示例，先统计查询流中每小时、每个城市和关键字被查询的次数。然后输出每小时、每个城市被查询最多的前100个关键字。在输出表中，小时、城市、排名三者可以唯一确定一条记录，所以需要将这三列声明成联合主键（需要在外部存储中也有同样的主键设置）。

CREATE TABLE rds_output (
  rownum BIGINT,
  start_time BIGINT,
  city VARCHAR,
  keyword VARCHAR,
  pv BIGINT,
  PRIMARY KEY (rownum, start_time, city)
) WITH (
  type = 'rds',
  ...
)

INSERT INTO rds_output
SELECT rownum, start_time, city, keyword, pv
FROM (
  SELECT *,
     ROW_NUMBER() OVER (PARTITION BY start_time, city ORDER BY pv desc) AS rownum
  FROM (
        SELECT SUBSTRING(time_str,1,12) AS start_time,
            keyword,
            count(1) AS pv,
            city
        FROM tmp_search
        GROUP BY SUBSTRING(time_str,1,12), keyword, city
    ) a
)
WHERE rownum <= 100
示例2
测试数据
ip（VARCHAR）	time（VARCHAR）
192.168.1.1	100000000
192.168.1.2	100000000
192.168.1.2	100000000
192.168.1.3	100030000
192.168.1.3	100000000
192.168.1.3	100000000
测试语句
CREATE TABLE source_table (
  IP VARCHAR,
  `TIME` VARCHAR
)WITH(
  type='datahub',
  endPoint='xxxxxxx',
  project='xxxxxxx',
  topic='xxxxxxx',
  accessId='xxxxxxx',
  accessKey='xxxxxxx'
);

CREATE TABLE result_table (
  rownum BIGINT,
  start_time VARCHAR,
  IP VARCHAR,
  cc BIGINT,
  PRIMARY KEY (start_time, IP)
) WITH (
  type = 'rds',
  url='xxxxxxx',
  tableName='blink_rds_test',
  userName='xxxxxxx',
  password='xxxxxxx'
);
INSERT INTO result_table
SELECT rownum,start_time,IP,cc
FROM (
  SELECT *,
     ROW_NUMBER() OVER (PARTITION BY start_time ORDER BY cc DESC) AS rownum
  FROM (
        SELECT SUBSTRING(`TIME`,1,2) AS start_time,--可以根据真实时间取相应的数值，这里取得是测试数据
        COUNT(IP) AS cc,
        IP
        FROM  source_table
        GROUP BY SUBSTRING(`TIME`,1,2), IP
    )a
)
WHERE rownum <= 3 --可以根据真实top值取相应的数值，这里取得是测试数据


测试结果
rownum（BIGINT）	start_time（VARCHAR）	ip（VARCHAR）	cc（BIGINT）
1	10	192.168.1.3	6
2	10	192.168.1.2	4
3	10	192.168.1.1	2
无排名优化
无排名优化解决数据膨胀问题
数据膨胀问题

根据TopN的语法，rownum字段会作为结果表的主键字段之一写入结果表。但是这可能导致数据膨胀的问题。例如，收到一条原排名9的更新数据，更新后排名上升到1，那么从1到9的数据排名都发生变化了。需要将这些数据作为更新都写入结果表。这样就产生了数据膨胀，可能导致结果表因为收到了太多的数据而降低更新速度。
无排名优化方法

结果表中不保存 rownum，最终的 rownum 由前端计算。因为TopN的数据量通常不会很大，前端排序100个数据很快。当收到一条原排名9，更新后排名上升到1的数据，也只需要发送这一条数据，而不用把排名1到9的数据全发送下去。这种优化能够提升结果表的更新速度。
无排名优化语法
SELECT col1, col2, col3
FROM (
 SELECT col1, col2, col3
   ROW_NUMBER() OVER ([PARTITION BY col1[, col2..]]
   ORDER BY col1 [asc|desc][, col2 [asc|desc]...]) AS rownum
 FROM table_name)
WHERE rownum <= N [AND conditions]

语法与上文类似，只是在外层查询中将rownum字段裁剪掉即可。

说明 在无rownum的场景，结果表主键的定义一定要特别注意。如果定义有误，会直接导致TopN结果的不正确。 无rownum场景的主键应为 TopN上游GROUP BY节点的KEY列表。
无排名优化示例
本示例来自某视频行业用户的真实业务（精简后）。用户每个视频在分发时会产生大量流量，依据视频产生的流量可以分析出最热门的视频。如下示例用于统计出每分钟流量最大的Top5的视频。

测试语句
--从SLS读取数据原始存储表
CREATE TABLE sls_cdnlog_stream (
vid VARCHAR, -- video id
rowtime TIMESTAMP, -- 观看视频发生的时间
response_size BIGINT, -- 观看产生的流量
WATERMARK FOR rowtime as withOffset(rowtime, 0)
) WITH (
type='sls',
...
);

--1分钟窗口统计vid带宽数
CREATE VIEW cdnvid_group_view AS
SELECT vid,
TUMBLE_START(rowtime, INTERVAL '1' MINUTE) AS start_time,
SUM(response_size) AS rss
FROM sls_cdnlog_stream
GROUP BY vid, TUMBLE(rowtime, INTERVAL '1' MINUTE);

--存储表
CREATE TABLE hbase_out_cdnvidtoplog (
vid VARCHAR,
rss BIGINT,
start_time VARCHAR,
   -- 注意结果表中不存储rownum字段
   -- 特别注意该主键的定义，为TopN上游GROUP BY的keys
PRIMARY KEY(start_time, vid)
) WITH (
type='RDS',
...
);

-- 统计每分钟Top5消耗流量的vid，并输出
INSERT INTO hbase_out_cdnvidtoplog

-- 注意次外层查询，不选出rownum字段
SELECT vid, rss, start_time FROM
(
SELECT
vid, start_time, rss,
ROW_NUMBER() OVER (PARTITION BY start_time ORDER BY rss DESC) as rownum,
FROM
cdnvid_group_view
)
WHERE rownum <= 5;

测试数据
vid（VARCHAR）	rowtime（Timestamp）	response_size（BIGINT）
10000	2017-12-18 15:00:10	2000
10000	2017-12-18 15:00:15	4000
10000	2017-12-18 15:00:20	3000
10001	2017-12-18 15:00:20	3000
10002	2017-12-18 15:00:20	4000
10003	2017-12-18 15:00:20	1000
10004	2017-12-18 15:00:30	1000
10005	2017-12-18 15:00:30	5000
10006	2017-12-18 15:00:40	6000
10007	2017-12-18 15:00:50	8000
测试结果
start_time（VARCHAR）	vid（VARCHAR）	rss（BIGINT）
2017-12-18 15:00:00	10000	9000
2017-12-18 15:00:00	10007	8000
2017-12-18 15:00:00	10006	6000
2017-12-18 15:00:00	10005	5000
2017-12-18 15:00:00	10002	4000


复杂事件处理（CEP）语句
更新时间：2019-03-08 10:03:07

编辑 ·
 · 我的收藏
本页目录
语法
示例
复杂事件处理（CEP）语句MATCH_RECOGNIZE用于从输入流中识别符合指定规则的事件，并按照指定的方式输出。

语法
SELECT [ ALL | DISTINCT ]
{ * | projectItem [, projectItem ]* }
FROM tableExpression
[MATCH_RECOGNIZE (
[PARTITION BY {partitionItem [, partitionItem]*}]
[ORDER BY {orderItem [, orderItem]*}]
[MEASURES {measureItem AS col [, measureItem AS col]*}]
[ONE ROW PER MATCH|ALL ROWS PER MATCH|ONE ROW PER MATCH WITH TIMEOUT ROWS|ALL ROWS PER MATCH WITH TIMEOUT ROWS]
[AFTER MATCH SKIP]
PATTERN (patternVariable[quantifier] [ patternVariable[quantifier]]*) WITHIN intervalExpression
DEFINE {patternVariable AS patternDefinationExpression [, patternVariable AS patternDefinationExpression]*}
)];
参数	说明
PARTITION BY	分区的列，可选项。
ORDER BY	可指定多列，但是必须以EVENT TIME列或者PROCESS TIME列作为排序的首列，可选项。
MEASURES	定义如何根据匹配成功的输入事件构造输出事件。
ONE ROW PER MATCH	对于每一次成功的匹配，只会产生一个输出事件。
ONE ROW PER MATCH WITH TIMEOUT ROWS	除了匹配成功的时候产生输出外，超时的时候也会产生输出。超时时间由PATTERN语句中的WITHIN语句定义。
ALL ROW PER MATCH	对于每一次成功的匹配，对应于每一个输入事件，都会产生一个输出事件。
ALL ROW PER MATCH WITH TIMEOUT ROWS	除了匹配成功的时候产生输出外，超时的时候也会产生输出。超时时间由PATTERN语句中的WITHIN语句定义。
[ONE ROW PER MATCH|ALL ROWS PER MATCH|ONE ROW PER MATCH WITH TIMEOUT ROWS|ALL ROWS PER MATCH WITH TIMEOUT ROWS]	为可选项，默认为ONE ROW PER MATCH。
AFTER MATCH SKIP TO NEXT ROW	匹配成功之后，从匹配成功的事件序列中的第一个事件的下一个事件开始进行下一次匹配。
AFTER MATCH SKIP PAST LAST ROW	匹配成功之后，从匹配成功的事件序列中的最后一个事件的下一个事件开始进行下一次匹配。
AFTER MATCH SKIP TO FIRST patternItem	匹配成功之后，从匹配成功的事件序列中第一个对应于patternItem的事件开始下一次匹配。
AFTER MATCH SKIP TO LAST patternItem	匹配成功之后，从匹配成功的事件序列中最后一个对应于patternItem的事件开始下一次匹配。
PATTERN	定义待识别的事件序列需要满足的规则，需要定义在()中，由一系列自定义的patternVariable构成。
说明
patternVariable之间若以空格间隔，表示符合这两种patternVariable的事件中间不存在其他事件。
patternVariable之间若以->间隔，表示符合这两种patternVariable的事件之间可以存在其它事件。
quantifier
quantifier用于指定符合patternVariable定义的事件的出现次数。

参数	参数意义
*	0次或多次
+	1次或多次
?	0次或1次
{n}	n次
{n,}	大于等于n次
{n, m}	大于等于n次，小于等于m次
{,m}	小于等于m次
默认为贪婪匹配。比如对于pattern: A -> B+，输入：a b1, b2, b3，输出为：a b1, a b1 b2, a b1 b2 b3。可以在quantifier符号后面加？来表示非贪婪匹配。

*?
+?
{n}?
{n,}?
{n, m}?
{,m}?
此时对于上面例子中的pattern及输入，产生的输出为：a b1, a b2, a b1 b2, a b3, a b2 b3, a b1 b2 b3。

说明
WITHIN 定义符合规则的事件序列的最大时间跨度。
静态窗口格式：INTERVAL ‘string’ timeUnit [ TO timeUnit ] 示例：INTERVAL ‘10’ SECOND, INTERVAL ‘45’ DAY, INTERVAL ‘10:20’ MINUTE TO SECOND, INTERVAL ‘10:20.10’ MINUTE TO SECOND, INTERVAL ‘10:20’ HOUR TO MINUTE, INTERVAL ‘1-5’ YEAR TO MONTH
动态窗口格式： INTERVAL intervalExpression 示例： INTERVAL A.windowTime + 10，其中A为pattern定义中第一个patternVariable。 在intervalExpression的定义中，可以使用pattern定义中出现过的patternVariable。当前只能使用第一个patternVariable。intervalExpression中可以使用UDF，intervalExpression的结果必须为long，单位为millisecond，表示窗口的大小。
DEFINE 定义在PATTERN中出现的patternVariable的具体含义，若某个patternVariable在DEFINE中没有定义，则认为对于每一个事件，该patternVariable都成立。
MEASURES和DEFINE语句函数
函数	函数意义
Row Pattern Column References	形式为：patternVariable.col。表示访问patternVariable所对应的事件的指定的列。
PREV	只能用在DEFINE语句中，一般与Row Pattern Column References合用。用于访问指定的pattern所对应的事件之前偏移指定的offset所对应的事件的指定的列。示例：对于DOWN AS DOWN.price < PREV(DOWN.price)，PREV(A.price)表示当前事件的前一个事件的price列的值。注意，DOWN.price等价于PREV(DOWN.price, 0)。 PREV(DOWN.price)等价于PREV(DOWN.price, 1)。
FIRST、LAST	一般与Row Pattern Column References合用，用于访问指定的PATTERN所对应的事件序列中的指定偏移位置的事件。示例：FIRST(A.price, 3)表示PATTERN A所对应的事件序列中的第4个事件。LAST(A.price, 3)表示PATTERN A所对应的事件序列中的倒数第4个事件。
输出列
函数	输出列
ONE ROW PER MATCH	包括PARTITION BY中指定的列及MEASURES中定义的列。 对于PARTITION BY中已经指定的列，在MEASURES中无需重复定义。
ONE ROW PER MATCH WITH TIMEOUT ROWS	除匹配成功的时候产生输出外，超时的时候也会产生输出，超时时间由PATTERN语句中的WITHIN语句定义。
说明
定义PATTERN的时候，最好也定义WITHIN，否则可能会造成STATE越来越大。
ORDER BY中定义的首列必须为EVENT TIME列或者PROCESS TIME列。
示例
示例语法
SELECT *
FROM Ticker MATCH_RECOGNIZE (
PARTITION BY symbol
ORDER BY tstamp
MEASURES STRT.tstamp AS start_tstamp,
LAST(DOWN.tstamp) AS bottom_tstamp,
LAST(UP.tstamp) AS end_tstamp
ONE ROW PER MATCH
AFTER MATCH SKIP TO NEXT ROW
PATTERN (STRT DOWN+ UP+) WITHIN INTERVAL '10' SECOND
DEFINE
DOWN AS DOWN.price < PREV(DOWN.price),
UP AS UP.price > PREV(UP.price)
) MR
ORDER BY MR.symbol, MR.start_tstamp;
测试数据
timestamp（TIMESTAMP）	card_id(VARCHAR)	location（VARCHAR）	action（VARCHAR）
2018-04-13 12:00:00	1	WW	Tom
2018-04-13 12:05:00	1	WW1	Tom
2018-04-13 12:10:00	1	WW2	Tom
2018-04-13 12:20:00	1	WW	Tom
测试案例语法
CREATE TABLE datahub_stream (
	`timestamp`               TIMESTAMP,
	card_id                   VARCHAR,
	location                  VARCHAR,
	`action`                  VARCHAR,
    WATERMARK wf FOR `timestamp` AS withOffset(`timestamp`, 1000)
) WITH (
	type = 'datahub'
	...
);
CREATE TABLE rds_out (
	start_timestamp               TIMESTAMP,
	end_timestamp                 TIMESTAMP,
	card_id                       VARCHAR,
	event                         VARCHAR
) WITH (
	type= 'rds'
	...
);

--案例描述
-- 当相同的card_id在十分钟内，从两个不同的location发生刷卡现象，就会触发报警机制，以便于监测信用卡盗刷等现象

-- 定义计算逻辑
insert into rds_out
select
`start_timestamp`,
`end_timestamp`,
card_id, `event`
from datahub_stream
MATCH_RECOGNIZE (
    PARTITION BY card_id   -- 按card_id分区，将相同卡号的数据分到同一个计算节点上。
    ORDER BY `timestamp`   -- 在窗口内，对事件时间进行排序。
    MEASURES               --定义如何根据匹配成功的输入事件构造输出事件。
        e2.`action` as `event`,
        e1.`timestamp` as `start_timestamp`,   --第一次的事件时间为start_timestamp。
        LAST(e2.`timestamp`) as `end_timestamp`--最新的事件时间为end_timestamp。
    ONE ROW PER MATCH           --匹配成功输出一条。
    AFTER MATCH SKIP TO NEXT ROW--匹配后跳转到下一行。
    PATTERN (e1 e2+) WITHIN INTERVAL '10' MINUTE  -- 定义两个事件，e1和e2。
    DEFINE                     --定义在PATTERN中出现的patternVariable的具体含义。
        e1 as e1.action = 'Tom',    --事件一的action标记为Tom。
        e2 as e2.action = 'Tom' and e2.location <> e1.location --事件二的action标记为Tom，且事件一和事件二的location不一致。

);
测试结果
start_timestamp（TIMESTAMP）	end_timestamp（TIMESTAMP）	card_id（VARCHAR）	event（VARCHAR）
2018-04-13 20:00:00.0	2018-04-13 20:05:00.0	1	Tom
2018-04-13 20:05:00.0	2018-04-13 20:10:00.0	1	Tom


EMIT语句
更新时间：2019-04-19 10:32:56

编辑 ·
 · 我的收藏
本页目录
策略
用途
语法
例子
Delay 的概念
目前状态和未来计划
说明 支持实时计算 2.0 以上版本
策略
EMIT 策略是指在Flink SQL 中，query的输出策略（如能忍受的延迟）可能在不同的场景有不同的需求，而这部分需求，传统的 ANSI SQL 并没有对应的语法支持。比如用户需求：1小时的时间窗口，窗口触发之前希望每分钟都能看到最新的结果，窗口触发之后希望不丢失迟到一天内的数据。针对这类需求，抽象出了EMIT语法，并扩展到了SQL语法。

用途
EMIT语法的用途目前总结起来主要提供了：控制延迟、数据精确性，两方面的功能。
控制延迟。针对大窗口，设置窗口触发之前的EMIT输出频率，减少用户看到结果的延迟。
数据精确性。不丢弃窗口触发之后的迟到的数据，修正输出结果。
在选择EMIT策略时，还需要与处理开销进行权衡。因为越低的输出延迟、越高的数据精确性，都会带来越高的计算开销。
语法
EMIT 语法是用来定义输出的策略，即是定义在输出（INSERT INTO）上的动作。当未配置时，保持原有默认行为，即 window 只在 watermark 触发时 EMIT 一个结果。语法：
INSERT INTO tableName
query
EMIT strategy [, strategy]*

strategy ::= {WITH DELAY timeInterval | WITHOUT DELAY}
                [BEFORE WATERMARK |AFTER WATERMARK]

timeInterval ::='string' timeUnit

WITH DELAY：声明能忍受的结果延迟，即按指定 interval 进行间隔输出。
WITHOUT DELAY：声明不忍受延迟，即每来一条数据就进行输出。
BEFORE WATERMARK：窗口结束之前的策略配置，即watermark 触发之前。
AFTER WATERMARK：窗口结束之后的策略配置，即watermark 触发之后。
注：
其中 strategy可以定义多个，同时定义before和after的策略。 但不能同时定义两个 before 或 两个after 的策略。
若配置了AFTER WATERMARK 策略，需要显式地配上 blink.state.ttl.ms 标识能忍受的最大迟到时间。
例子
-- 窗口结束之前，按1分钟延迟输出，窗口结束之后无延迟输出
EMIT
  WITH DELAY '1'MINUTE BEFORE WATERMARK,
  WITHOUT DELAY AFTER WATERMARK

-- 窗口结束之前不输出，窗口结束之后无延迟输出
EMIT WITHOUT DELAY AFTER WATERMARK

-- 全局都按1分钟的延迟输出 (minibatch)
EMIT WITH DELAY '1'MINUTE
-- 窗口结束之前按1分钟延迟输出
EMIT WITH DELAY '1'MINUTE BEFORE WATERMARK

最大容忍迟到时间

当配置AFTER 的策略，即表示会接收迟到的数据，窗口的状态就会一直保留以等待迟到数据，那么会等待多久呢？这是一个用户能自定义的参数，即 blink.state.ttl.ms 状态的超时时间，默认未配置，如启用了 AFTER 策略，必须显式地配上 blink.state.ttl.ms 参数 。例如： blink.state.ttl.ms=3600000 最多容忍1小时的迟到数据，超过这个时间的数据会直接丢弃。
Example

例如，我们有一个一小时的滚动窗口 tumble_window 。
CREATE VIEW tumble_window AS
SELECT
  id,
  TUMBLE_START(rowtime, INTERVAL '1' HOUR) as start_time,
  COUNT(*) as cnt
FROM source
GROUP BY id, TUMBLE(rowtime, INTERVAL '1' HOUR)

默认 tumble_window 的输出是需要等到一小时结束才能看到结果，我们希望能尽早能看到窗口的结果（即使是不完整的结果）。例如，我们希望每分钟看到最新的窗口结果：
INSERT INTO result
SELECT * FROM tumble_window
EMIT WITH DELAY '1' MINUTE BEFORE WATERMARK -- 窗口结束之前，每隔1分钟输出一次更新结果

另外，默认 tumble_window 会忽略并丢弃窗口结束后到达的数据，而这部分数据对我们来说很重要，希望能统计进最终的结果里。而且我们知道我们的迟到数据不会太多，且迟到时间不会超过一天以上，并且希望收到迟到的数据立刻就更新结果：
INSERT INTO result
SELECT * FROM tumble_window
EMIT WITH DELAY '1' MINUTE BEFORE WATERMARK,
     WITHOUT DELAY AFTER WATERMARK  -- 窗口结束后，每收到一条数据输出一次更新结果

-- 增加一天的 state TTL 配置
blink.state.ttl.ms = 86400000

Delay 的概念
本文的 Delay 指的是用户能忍受的延迟，该延迟是指用户的数据从进入实时计算统，到看到结果数据（出实时计算系统）的时间，不管 mode 是Event Time 还是Processing Time。延迟的计算都是基于系统时间的。动态表（流在实时计算内部的存储）中的任意一行记录发生了变化，到结果表（实时计算外部的存储）中能看到这行新记录的时间间隔，称为延迟。

假设实时计算系统的处理耗时是0，那么会产生延迟的地方有 minibatch 的攒批，window 的等待窗口数据。如果用户指定了最多延迟30秒，那这30秒可以用来给 minibatch 攒批。如果query 是一个一小时的窗口，那么最多延迟30秒的含义是，每隔30秒要 EMIT 变化的行，也就是window结果的trigger interval。

例如配置 EMIT WITH DELAY '1' MINUTE ，如果普通groupby 聚合，则会用1分钟做 minibatch 攒批。如果有window且window 的size大于1分钟，则window 会每隔1分钟发射一次，否则忽略这个配置，因为窗口依靠watermark 的输出就能保证这个latency SLA。

又例如配置 EMIT WITHOUT DELAY 。如果是group by，则不会启用minibatch，每来一条数据都触发计算和输出。如果是window，则也是每来一条数据都触发计算和输出。

目前状态和未来计划
目前状态和未来计划·
目前EMIT策略只支持TUMBLE，HOP窗口，暂不支持SESSION窗口。
目前一个Job若有多个输出，多个输出的EMIT需要定义成一样的策略。未来会支持不一样的策略。
目前EMIT 语法还不能用来配置minibatch的allowLateness，未来打算使用EMIT 策略来声明allowLateness。
=================


窗口函数概述
更新时间：2019-04-11 11:58:23

编辑 ·
 · 我的收藏
本页目录
窗口函数
时间属性
级联窗口
本文为您介绍Flink SQL支持的窗口函数以及窗口函数支持的时间属性和窗口类型。

窗口函数
窗口函数Flink SQL支持基于无限大窗口的聚合（无需显式定义在SQL Query中添加任何的窗口）以及对一个特定的窗口的聚合。例如，需要统计在过去的1分钟内有多少用户点击了某个的网页，可以通过定义一个窗口来收集最近1分钟内的数据，并对这个窗口内的数据进行计算。

Flink SQL支持的窗口聚合主要是两种：Window Aggregate和Over Aggregate。本文档主要介绍Window Aggregate。Window Aggregate支持两种时间属性做窗口：Event Time和Processing Time。每种时间属性类型下，又分别支持三种窗口类型：滚动窗口（TUMBLE）、滑动窗口（HOP）和会话窗口（SESSION）。

时间属性
Flink SQL支持以下2种时间属性。实时计算可以基于这2种时间属性对数据进行窗口聚合。
Event Time：您提供的事件时间(通常是数据的最原始的创建时间)，Event Time一定是您提供在Schema里的数据。
Processing Time：对事件进行处理的本地系统时间。
实时计算时间属性详情，请参见时间属性。

级联窗口
由于rowtime列在经过窗口后，其event time属性会丢失。您可以使用辅助函数TUMBLE_ROWTIME、HOP_ROWTIME或SESSION_ROWTIME来获取窗口中的rowtime列的最大值max(rowtime)作为时间窗口的rowtime，其类型是具有rowtime attribute的TIMESTAMP，取值为 window\_end - 1 。 例如[00:00, 00:15) 的窗口，返回值为00:14:59.999 。

级联窗口示例如下。示例逻辑为：基于1分钟的滚动窗口聚合结果，进行1小时的滚动窗口聚合。
CREATE TABLE user_clicks(
  username varchar,
  click_url varchar,
  ts timeStamp,
  WATERMARK wk FOR ts as withOffset(ts, 2000)  --为rowtime定义watermark
) with (
  type='datahub',
  ...
);

CREATE TABLE tumble_output(
  window_start TIMESTAMP,
  window_end TIMESTAMP,
  username VARCHAR,
  clicks BIGINT
) with (
  type='print'
);

CREATE VIEW one_minute_window_output as
SELECT
  // 使用TUMBLE_ROWTIME作为二级window的聚合时间
  TUMBLE_ROWTIME(ts, INTERVAL '1' MINUTE) as rowtime,
  username,
  COUNT(click_url) as cnt
FROM window_input
GROUP BY TUMBLE(ts, INTERVAL '1' MINUTE), username;

INSERT INTO tumble_output
SELECT
  TUMBLE_START(rowtime, INTERVAL '1' HOUR),
  TUMBLE_END(rowtime, INTERVAL '1' HOUR),
  username,
  SUM(cnt)
FROM one_minute_window_output
GROUP BY TUMBLE(rowtime, INTERVAL '1' HOUR), username



滚动窗口
更新时间：2019-04-11 16:34:27

编辑 ·
 · 我的收藏
本页目录
什么滚动窗口
语法
标识函数
示例1
示例2
本文为您介绍如何使用实时计算滚动窗口函数。

什么滚动窗口
滚动窗口（TUMBLE）将每个元素分配到一个指定大小的窗口中。通常滚动窗口有一个固定的大小，并且不会出现重叠。例如：如果指定了一个5分钟大小的滚动窗口，无限流的数据会根据时间划分成 [0:00 - 0:05)、 [0:05, 0:10)、 [0:10, 0:15)等窗口。如下图，展示了一个大小划分为30秒的滚动窗口。
滚动窗口
语法
TUMBLE函数用在GROUP BY子句中，用来定义滚动窗口。

TUMBLE(<time-attr>, <size-interval>)
<size-interval>: INTERVAL 'string' timeUnit
说明
<time-attr> 参数必须是流中的一个合法的时间属性字段，指定为Processing Time或Event Time。 请参见窗口函数概述，了解如何定义时间属性和Watermark。

标识函数
使用标识函数选出窗口的起始时间或者结束时间，窗口的时间属性用于下级Window的聚合。

窗口标识函数	返回类型	描述
TUMBLE_START(time-attr, size-interval)	TIMESTAMP	返回窗口的起始时间（包含边界）。如[00:10, 00:15) 的窗口，返回 00:10 。
TUMBLE_END(time-attr, size-interval)	TIMESTAMP	返回窗口的结束时间（包含边界）。如[00:00, 00:15] 的窗口，返回 00:15。
TUMBLE_ROWTIME(time-attr, size-interval)	TUMBLE_ROWTIME(time-attr, size-interval)	返回窗口的结束时间（不包含边界）。如 [00:00, 00:15] 的窗口，返回 00:14:59.999 。返回值是一个 rowtime attribute，即可以基于该字段做时间属性的操作，如级联窗口。只能用在基于event time 的window 上。
TUMBLE_PROCTIME(time-attr, size-interval)	TUMBLE_ROWTIME(time-attr, size-interval)	返回窗口的结束时间（不包含边界）。如 [00:00, 00:15] 的窗口，返回 00:14:59.999 。返回值是一个 proctime attribute，即可以基于该字段做时间属性的操作，如级联窗口。 只能用在基于processing time 的window上。
示例1
以下示例为使用event time统计每个用户每分钟在指定网站的点击数。

测试数据
username （VARCHAR）	click_url （VARCHAR）	ts （TIMESTAMP）
Jark	http://taobao.com/xxx	2017-10-10 10:00:00.0
Jark	http://taobao.com/xxx	2017-10-10 10:00:10.0
Jark	http://taobao.com/xxx	2017-10-10 10:00:49.0
Jark	http://taobao.com/xxx	2017-10-10 10:01:05.0
Jark	http://taobao.com/xxx	2017-10-10 10:01:58.0
Timo	http://taobao.com/xxx	2017-10-10 10:02:10.0
测试语句
CREATE TABLE user_clicks(
username varchar,
click_url varchar,
ts timeStamp,
WATERMARK wk FOR ts as withOffset(ts, 2000) -- 为rowtime定义watermark
) with (
type='datahub',
...
);

CREATE TABLE tumble_output(
window_start TIMESTAMP,
window_end TIMESTAMP,
username VARCHAR,
clicks BIGINT
) with (
type='RDS'
);

INSERT INTO tumble_output
SELECT
TUMBLE_START(ts, INTERVAL '1' MINUTE),
TUMBLE_END(ts, INTERVAL '1' MINUTE),
username,
COUNT(click_url)
FROM user_clicks
GROUP BY TUMBLE(ts, INTERVAL '1' MINUTE), username
测试结果
window_start （TIMESTAMP）	window_end （TIMESTAMP）	username （VARCHAR）	clicks （BIGINT）
2017-10-10 10:00:00.0	2017-10-10 10:01:00.0	Jark	3
2017-10-10 10:01:00.0	2017-10-10 10:02:00.0	Jark	2
2017-10-10 10:02:00.0	2017-10-10 10:03:00.0	Timo	1
示例2
以下示例为使用processing time统计每个用户每分钟在指定网站的点击数。

测试数据
username （VARCHAR）	click_url （VARCHAR）
Jark	http://taobao.com/xxx
Jark	http://taobao.com/xxx
Jark	http://taobao.com/xxx
Jark	http://taobao.com/xxx
Jark	http://taobao.com/xxx
Timo	http://taobao.com/xxx
测试语句
CREATE TABLE window_test (
  username              VARCHAR,
  click_url             VARCHAR,
    ts as PROCTIME()
) WITH (
  type = 'datahu ...c = xxx'
);


CREATE TABLE tumble_output(
window_start TIMESTAMP,
window_end TIMESTAMP,
username VARCHAR,
clicks BIGINT
) with (
type='print'
);

INSERT INTO tumble_output
SELECT
TUMBLE_START(ts, INTERVAL '1' MINUTE),
TUMBLE_END(ts, INTERVAL '1' MINUTE),
username,
COUNT(click_url)
FROM window_test
GROUP BY TUMBLE(ts, INTERVAL '1' MINUTE), username
测试结果
window_start （TIMESTAMP）	window_end （TIMESTAMP）	username （VARCHAR）	clicks （BIGINT）
2019-04-11 14:43:00.000	2019-04-11 14:44:00.000	Jark	5
2019-04-11 14:43:00.000 	2019-04-11 14:44:00.000	Timo	1


滑动窗口
更新时间：2019-04-16 17:40:15

编辑 ·
 · 我的收藏
本页目录
什么是滑动窗口
滑动窗口函数语法
滑动窗口标识函数
示例
本文为您介绍如何使用实时计算滑动窗口函数。

说明 实时计算滑动窗口（HOP）暂不支持与last_value、first_value或TopN函数共同使用。
什么是滑动窗口
滑动窗口（HOP），也被称作Sliding Window。不同于滚动窗口，滑动窗口的窗口可以重叠。

滑动窗口有两个参数：slide和size。slide为每次滑动的步长，size为窗口的大小。

slide < size，则窗口会重叠，每个元素会被分配到多个窗口。
slide = size，则等同于滚动窗口（TUMBLE）。
slide > size，则为跳跃窗口，窗口之间不重叠且有间隙。
通常情况下大部分元素符合多个窗口情景，窗口是重叠的。因此，滑动窗口在计算移动平均数（moving averages）时很实用。例如，计算过去5分钟数据的平均值，每10秒钟更新一次，可以设置slide为10秒，size为5分钟。下图为您展示间隔为30秒，窗口大小为1分钟的滑动窗口。
滑动窗口
滑动窗口函数语法
HOP函数用在group by子句中，用来定义滑动窗口。

HOP(<time-attr>, <slide-interval>,<size-interval>)
<slide-interval>: INTERVAL 'string' timeUnit
<size-interval>: INTERVAL 'string' timeUnit

说明
<time-attr> 参数必须是流中的一个合法的时间属性字段，指定为Processing Time或Event Time。 请参见窗口函数概述，了解如何定义时间属性和Watermark。

滑动窗口标识函数
使用滑动窗口标识函数选出窗口的起始时间或者结束时间，窗口的时间属性用于下级Window的聚合。

窗口标识函数	返回类型	描述
HOP_START（<time-attr>, <slide-interval>, <size-interval>）	TIMESTAMP	返回窗口的起始时间（包含边界）。如[00:10, 00:15) 的窗口，返回 00:10 。
HOP_END（<time-attr>, <slide-interval>, <size-interval>）	TIMESTAMP	返回窗口的结束时间（包含边界）。如[00:00, 00:15) 的窗口，返回 00:15。
HOP_ROWTIME（<time-attr>, <slide-interval>, <size-interval>）	TIMESTAMP（rowtime-attr）	返回窗口的结束时间（不包含边界）。如 [00:00, 00:15) 的窗口，返回 00:14:59.999 。返回值是一个 rowtime attribute，也就是可以基于该字段做时间类型的操作，如级联窗口。只能用在基于event time的window上。
HOP_PROCTIME（<time-attr>, <slide-interval>, <size-interval>）	TIMESTAMP（rowtime-attr）	返回窗口的结束时间（不包含边界）。如 [00:00, 00:15) 的窗口，返回 00:14:59.999 。返回值是一个 proctime attribute，也就是可以基于该字段做时间类型的操作，如级联窗口。只能用在基于 processing time的window 上。
示例
统计每个用户过去1分钟的点击次数，每30秒更新一次。即一分钟的窗口，30秒滑动一次。

测试数据
username（VARCHAR）	click_url（VARCHAR）	ts（TIMESTAMP）
Jark	http://taobao.com/xxx	2017-10-10 10:00:00.0
Jark	http://taobao.com/xxx	2017-10-10 10:00:10.0
Jark	http://taobao.com/xxx	2017-10-10 10:00:49.0
Jark	http://taobao.com/xxx	2017-10-10 10:01:05.0
Jark	http://taobao.com/xxx	2017-10-10 10:01:58.0
Timo	http://taobao.com/xxx	2017-10-10 10:02:10.0
测试语句
CREATE TABLE user_clicks (
    username VARCHAR,
    click_url VARCHAR,
    ts TIMESTAMP,
    WATERMARK wk FOR ts AS WITHOFFSET (ts, 2000)--为rowtime定义watermark
) WITH ( TYPE = 'datahub',
        ...);
CREATE TABLE hop_output (
    window_start TIMESTAMP,
    window_end TIMESTAMP,
    username VARCHAR,
    clicks BIGINT
) WITH (TYPE = 'rds',
        ...);
INSERT INTO
    hop_output
SELECT
    HOP_START (ts, INTERVAL '30' SECOND, INTERVAL '1' MINUTE),
    HOP_END (ts, INTERVAL '30' SECOND, INTERVAL '1' MINUTE),
    username,
    COUNT (click_url)
FROM
    user_clicks
GROUP BY
    HOP (ts, INTERVAL '30' SECOND, INTERVAL '1' MINUTE),
    username

测试结果
window_start （TIMESTAMP）	window_end （TIMESTAMP）	username （VARCHAR）	clicks （BIGINT）
2017-10-10 10:00:00.0	2017-10-10 10:01:00.0	Jark	3
2017-10-10 10:00:30.0	2017-10-10 10:01:30.0	Jark	2
2017-10-10 10:01:00.0	2017-10-10 10:02:00.0	Jark	2
2017-10-10 10:01:30.0	2017-10-10 10:02:30.0	Jark	1
2017-10-10 10:01:30.0	2017-10-10 10:02:30.0	Timo	1
2017-10-10 10:02:00.0	2017-10-10 10:03:00.0	Timo	1



会话窗口
更新时间：2019-04-11 11:59:11

编辑 ·
 · 我的收藏
本页目录
什么是会话窗口
会话窗口函数语法
会话窗口标识函数
示例
本文为您介绍如何使用实时计算会话窗口函数。

什么是会话窗口
会话窗口（SESSION）通过Session活动来对元素进行分组。会话窗口与滚动窗口和滑动窗口相比，没有窗口重叠，没有固定窗口大小。相反，当它在一个固定的时间周期内不再收到元素，即会话断开时，这个窗口就会关闭。

会话窗口通过一个间隔时间（Gap）来配置，这个间隔定义了非活跃周期的长度。例如，一个表示鼠标点击活动的数据流可能具有长时间的空闲时间，并在其间散布着高浓度的点击。 如果数据在最短指定的间隔持续时间之后到达，则会开始一个新的窗口。

下图展示了一个会话窗口，注意每个Key由于不同的数据分布有不同的Window。

会话窗口函数语法
SESSION函数用在GROUP BY子句中定义会话窗口。

SESSION(<time-attr>, <gap-interval>)
<gap-interval>: INTERVAL 'string' timeUnit
说明
<time-attr> 参数必须是流中的一个合法的时间属性字段，指定为Processing Time或Event Time。 请参见窗口函数概述，了解如何定义时间属性和Watermark。

会话窗口标识函数
使用标识函数选出窗口的起始时间或者结束时间，窗口的时间属性用于下级Window的聚合。

窗口标识函数	返回类型	描述
SESSION_START（<time-attr>, <gap-interval>）	Timestamp	返回窗口的起始时间（包含边界）。如[00:10, 00:15) 的窗口，返回 00:10 。
SESSION_END（<time-attr>, <gap-interval>）	Timestamp	返回窗口的结束时间（包含边界）。如[00:00, 00:15) 的窗口，返回 00:15。
SESSION_ROWTIME（<time-attr>, <gap-interval>）	Timestamp（rowtime-attr）	返回窗口的结束时间（不包含边界）。如 [00:00, 00:15) 的窗口，返回00:14:59.999 。返回值是一个 rowtime attribute，也就是可以基于该字段做时间类型的操作，如级联窗口。只能用在基于event time 的window 上。
SESSION_PROCTIME（<time-attr>, <gap-interval>）	Timestamp（rowtime-attr）	返回窗口的结束时间（不包含边界）。如 [00:00, 00:15) 的窗口，返回 00:14:59.999 。返回值是一个 proctime attribute，也就是可以基于该字段做时间类型的操作，如级联窗口。只能用在基于 processing time的window 上。
示例
统计每个用户在每个活跃会话期间的点击次数，会话超时时间30秒。

测试数据
username （VARCHAR）	click_url （VARCHAR）	ts （TIMESTAMP）
Jark	http://taobao.com/xxx	2017-10-10 10:00:00.0
Jark	http://taobao.com/xxx	2017-10-10 10:00:10.0
Jark	http://taobao.com/xxx	2017-10-10 10:00:49.0
Jark	http://taobao.com/xxx	2017-10-10 10:01:05.0
Jark	http://taobao.com/xxx	2017-10-10 10:01:58.0
Timo	http://taobao.com/xxx	2017-10-10 10:02:10.0
测试语句
CREATE TABLE user_clicks(
username varchar,
click_url varchar,
ts timeStamp,
WATERMARK wk FOR ts as withOffset(ts, 2000) -- 为rowtime定义watermark
) with (
type='datahub',
...
);

CREATE TABLE session_output(
window_start TIMESTAMP,
window_end TIMESTAMP,
username VARCHAR,
clicks BIGINT
) with (
type='rds'
);

INSERT INTO session_output
SELECT
SESSION_START(ts, INTERVAL '30' SECOND),
SESSION_END(ts, INTERVAL '30' SECOND),
username,
COUNT(click_url)
FROM user_clicks
GROUP BY SESSION(ts, INTERVAL '30' SECOND), username
测试结果
window_start （TIMESTAMP）	window_end （TIMESTAMP）	username （VARCHAR）	clicks （BIGINT）
2017-10-10 10:00:00.0	2017-10-10 10:00:40.0	Jark	2
2017-10-10 10:00:49.0	2017-10-10 10:01:35.0	Jark	2
2017-10-10 10:01:58.0	2017-10-10 10:02:28.0	Jark	1
2017-10-10 10:02:10.0	2017-10-10 10:02:40.0	Timo	1



OVER窗口
更新时间：2019-01-24 14:14:05

编辑 ·
 · 我的收藏
本页目录
语法
类型
属性
Rows OVER Window语义
RANGE OVER Window语义
OVER窗口（OVER Window）是传统数据库的标准开窗，OVER Window不同于Group By Window，OVER Window中每1个元素都对应1个窗口。窗口元素是与当前元素相邻的元素集合，流上元素会在多个窗口中。在Flink SQL Window的实现中，每个触发计算的元素所确定的行，都是该元素所在窗口的最后一行。

在应用OVER Window的流式数据中，每1个元素都对应1个OVER Window。每1个元素都触发一次数据计算。在实时计算的底层实现中，OVER Window的数据进行全局统一管理（数据只存储一份），逻辑上为每1个元素维护1个OVER Window，为每1个元素进行窗口计算，完成计算后会清除过期的数据。

语法
SELECT
    agg1(col1) OVER (definition1) AS colName,
    ...
    aggN(colN) OVER (definition1) AS colNameN
FROM Tab1
说明
agg1到aggN所对应的OVER definition1必须相同。
AS的别名可供外层SQL进行查询。
类型
Flink SQL中对OVER Window的定义遵循标准SQL的定义语法，传统OVER Window没有对其进行更细粒度的窗口类型命名划分。本节为了方便您理解OVER Window的语义，将OVER Window按照计算行的定义方式划分为如下两类。

ROWS OVER Window：每一行元素都视为新的计算行，即每一行都是一个新的窗口。
RANGE OVER Window：具有相同时间值的所有元素行视为同一计算行，即具有相同时间值的所有行都是同一个窗口。
属性
正交属性	proctime	eventtime
rows	√	√
range	√	√
rows：按照实际元素的行进行确定窗口。
range：按照实际的元素值（时间戳值）进行确定窗口。
Rows OVER Window语义
窗口数据
ROWS OVER Window的每个元素都确定一个窗口。ROWS OVER Window也有Unbounded和Bounded的两种情况。

Unbounded ROWS OVER Window数据如下图所示。

UnBounded ROWS OVER Window
说明 上图所示窗口user1的w7和w8，user2的窗口w3和w4，虽然元素都是同一时刻到达，但是它们仍然是在不同的窗口，这一点有别于RANGE OVER Window。
Bounded ROWS OVER Window数据以3个元素（2 PRECEDING）的窗口为例，如下图所示。

Bounded ROWS OVER Window
说明 上图所示窗口user1的w5和w6，user2的窗口w2和w3，虽然有元素都是同一时刻到达，但是它们仍然是在不同的窗口，这一点有别于RANGE OVER Window。
窗口语法
SELECT
    agg1(col1) OVER(
     [PARTITION BY (value_expression1,..., value_expressionN)]
     ORDER BY timeCol
     ROWS
     BETWEEN (UNBOUNDED | rowCount) PRECEDING AND CURRENT ROW) AS colName, ...
FROM Tab1
value_expression：分区值表达式。
timeCol：用于元素排序的时间字段。
rowCount：是定义根据当前行开始向前追溯几行元素。
案例
以Bounded ROWS OVER Window场景示例，假设，有一张商品上架表，包含有商品ID、商品类型、商品上架时间、商品价格数据。假设，求在当前商品上架之前同类的3个商品中的最高价格。

测试数据

商品ID	商品类型	上架时间	销售价格
ITEM001	Electronic	2017-11-11 10:01:00	20
ITEM002	Electronic	2017-11-11 10:02:00	50
ITEM003	Electronic	2017-11-11 10:03:00	30
ITEM004	Electronic	2017-11-11 10:03:00	60
ITEM005	Electronic	2017-11-11 10:05:00	40
ITEM006	Electronic	2017-11-11 10:06:00	20
ITEM007	Electronic	2017-11-11 10:07:00	70
ITEM008	Clothes	2017-11-11 10:08:00	20
测试代码

CREATE TABLE tmall_item(
   itemID VARCHAR,
   itemType VARCHAR,
   onSellTime TIMESTAMP,
   price DOUBLE,
   WATERMARK onSellTime FOR onSellTime as withOffset(onSellTime, 0)
)
WITH (
  type = 'sls',
   ...
) ;

SELECT
    itemID,
    itemType,
    onSellTime,
    price,
    MAX(price) OVER (
        PARTITION BY itemType
        ORDER BY onSellTime
        ROWS BETWEEN 2 preceding AND CURRENT ROW) AS maxPrice
  FROM tmall_item
测试结果

itemID	itemType	onSellTime	price	maxPrice
ITEM001	Electronic	2017-11-11 10:01:00	20	20
ITEM002	Electronic	2017-11-11 10:02:00	50	50
ITEM003	Electronic	2017-11-11 10:03:00	30	50
ITEM004	Electronic	2017-11-11 10:03:00	60	60
ITEM005	Electronic	2017-11-11 10:05:00	40	60
ITEM006	Electronic	2017-11-11 10:06:00	20	60
ITEM007	Electronic	2017-11-11 10:07:00	70	70
ITEM008	Clothes	2017-11-11 10:08:00	20	20
RANGE OVER Window语义
窗口数据
RANGE OVER Window所有具有共同元素值（元素时间戳）的元素行确定一个窗口，RANGE OVER Window也有Unbounded和Bounded的两种情况。

Unbounded RANGE OVER Window 数据如下图所示。
UnBounded RANGE OVER Window
注意: 上图所示窗口user1的w7， user2的窗口w3 ，两个元素同一时刻到达，他们属于相同的window，这一点有别于ROWS OVER Window。

Bounded RANGE OVER Window 数据，以3秒中数据(INTERVAL '2' SECOND)的窗口为例，如下图所示。

Bounded RANGE OVER Window
说明 上图所示窗口user1的w6， user2的窗口w3，元素都是同一时刻到达，他们属于相同的window，这一点有别于ROWS OVER Window。
窗口语法
SELECT
    agg1(col1) OVER(
     [PARTITION BY (value_expression1,..., value_expressionN)]
     ORDER BY timeCol
     RANGE
     BETWEEN (UNBOUNDED | timeInterval) PRECEDING AND CURRENT ROW) AS colName,
...
FROM Tab1
value_expression：进行分区的字表达式。
timeCol：用于元素排序的时间字段。
timeInterval：是定义根据当前行开始向前追溯指定时间的元素行。
案例
以Bounded RANGE OVER Window场景示例，假设有一张商品上架表，包含有商品ID、商品类型、商品上架时间、商品价格数据。假设求比当前商品上架时间早2分钟的同类商品中的最高价格。

测试数据

商品ID	商品类型	上架时间	销售价格
ITEM001	Electronic	2017-11-11 10:01:00	20
ITEM002	Electronic	2017-11-11 10:02:00	50
ITEM003	Electronic	2017-11-11 10:03:00	30
ITEM004	Electronic	2017-11-11 10:03:00	60
ITEM005	Electronic	2017-11-11 10:05:00	40
ITEM006	Electronic	2017-11-11 10:06:00	20
ITEM007	Electronic	2017-11-11 10:07:00	70
ITEM008	Clothes	2017-11-11 10:08:00	20
测试代码

CREATE TABLE tmall_item(
   itemID VARCHAR,
   itemType VARCHAR,
   onSellTime TIMESTAMP,
   price DOUBLE,
   WATERMARK onSellTime FOR onSellTime as withOffset(onSellTime, 0)
)
WITH (
  type = 'sls',
   ...
) ;

SELECT
    itemID,
    itemType,
    onSellTime,
    price,
    MAX(price) OVER (
        PARTITION BY itemType
        ORDER BY onSellTime
        RANGE BETWEEN INTERVAL '2' MINUTE preceding AND CURRENT ROW) AS maxPrice
  FROM tmall_item

测试结果

itemID	itemType	onSellTime	price	maxPrice
ITEM001	Electronic	2017-11-11 10:01:00	20	20
ITEM002	Electronic	2017-11-11 10:02:00	50	50
ITEM003	Electronic	2017-11-11 10:03:00	30	50
ITEM004	Electronic	2017-11-11 10:03:00	60	60
ITEM005	Electronic	2017-11-11 10:05:00	40	60
ITEM006	Electronic	2017-11-11 10:06:00	20	40
ITEM007	Electronic	2017-11-11 10:07:00	70	70
ITEM008	Clothes	2017-11-11 10:08:00	20	20

本文为您介绍如何使用实时计算逻辑运算函数=。

语法
 A = B
入参
参数	数据类型
A	INT
B	INT
功能描述
如果A等于B，返回TRUE，否则返回FALSE。

示例
测试数据
int1(INT)	int2(INT)	int3(INT)
97	65	65
测试语句
SELECT int1 as aa
FROM T1
WHERE int3 = int2;
测试结果
aa(int)
97



本文为您介绍如何使用实时计算逻辑运算函数>。

语法
 A > B
入参
参数	数据类型
A	INT
B	INT
功能描述
如果A大于B，返回TRUE，否则返回FALSE。
示例
测试数据
int1(INT)	int2(INT)	int3(INT)
97	65	100
测试语句
SELECT int1 as aa
FROM T1
WHERE int3 > int2;
测试结果
aa(int)
97

>=
更新时间：2018-12-27 19:08:01


本页目录
语法
入参
功能描述
示例
本文为您介绍如何使用实时计算逻辑运算函数>=。

语法
 A >= B
入参
参数	数据类型
A	INT
B	INT
功能描述
如果A大于等于B，返回TRUE，否则返回FALSE。
示例
测试数据
int1(INT)	int2(INT)	int3(INT)
97	65	65
9	6	61
测试语句
SELECT int1 as aa
FROM T1
WHERE int3 >= int2;
测试结果
aa(int)
97
9

<=
更新时间：2018-12-28 11:03:46


本页目录
语法
入参
功能描述
示例
本文为您介绍如何使用实时计算逻辑运算函数<=。

语法
 A <= B
入参
参数	数据类型
A	INT
B	INT
功能描述
如果A小于等于B，返回TRUE，否则返回FALSE。
示例
测试数据
int1(INT)	int2(INT)	int3(INT)
97	66	65
9	6	5
测试语句
SELECT int1 as aa
FROM T1
WHERE int3 <= int2;
测试结果
aa(int)
97
9

<
更新时间：2018-12-27 19:11:17


本页目录
语法
入参
功能描述
示例
本文为您介绍如何使用实时计算逻辑运算函数<。

语法
 A < B
入参
参数	数据类型
A	INT
B	INT
功能描述
如果A小于B，返回TRUE，否则返回FALSE。
示例
测试数据
int1(INT)	int2(INT)	int3(INT)
97	66	65
9	6	5
测试语句
SELECT int1 as aa
FROM T1
WHERE int3 < int2;
测试结果
aa(int)
97
9

<>
更新时间：2018-12-27 19:11:35


本页目录
语法
入参
功能描述
示例
本文为您介绍如何使用实时计算逻辑运算函数<>。

语法
 A <> B
入参
参数	数据类型
A	INT
B	INT
功能描述
如果A不等于B，返回TRUE，否则返回FALSE。
示例
测试数据
int1(INT)	int2(INT)	int3(INT)
97	66	6
测试语句
SELECT int1 as aa
FROM T1
WHERE int3 <> int2;
测试结果
aa(int)
97

AND
更新时间：2018-12-27 19:11:56


本页目录
语法
入参
功能描述
示例
本文为您介绍如何使用实时计算逻辑运算函数AND。

语法
 A AND B
入参
参数	数据类型
A	BOOLEAN
B	BOOLEAN
功能描述
如果A和B均为TRUE，则为TRUE，否则为FALSE。
示例
测试数据
int1(INT)	int2(INT)	int3(INT)
255	97	65
测试语句
SELECT int2 as aa
FROM T1
WHERE int1=255 AND int3=65;
测试结果
aa(int)
97

BETWEEN AND
更新时间：2019-04-19 10:33:32

编辑 ·
本页目录
语法
入参
功能描述
示例1
示例2
示例3
本文为您介绍如何使用实时计算逻辑运算函数BETWEEN AND。

语法
 A BETWEEN AND B

入参
参数	数据类型
A	DOUBLE，BIGINT，INT，VARCHAR，DATE，TIMESTAMP，TIME
B	DOUBLE，BIGINT，INT，VARCHAR，DATE，TIMESTAMP，TIME
C	DOUBLE，BIGINT，INT，VARCHAR，DATE，TIMESTAMP，TIME
功能描述
BETWEEN操作符用于选取介于两个值之间的数据范围内的值。

示例1
测试数据
int1(INT)	int2(INT)	int3(INT)
90	80	100
11	10	7
测试语句
SELECT int1 as aa
FROM T1
WHERE int1 BETWEEN int2 AND int3;

测试结果
aa(int)
90
示例2
测试数据
var1(varchar)	var2(varchar)	var3(varchar)
b	a	c
测试语句
SELECT var1 as aa
FROM T1
WHERE var1 BETWEEN var2 AND var3;

测试结果
aa(varchar)
b
示例3
测试数据
TIMESTAMP1(TIMESTAMP)	TIMESTAMP2(TIMESTAMP)	TIMESTAMP3(TIMESTAMP)
1969-07-20 20:17:30	1969-07-20 20:17:20	1969-07-20 20:17:45
测试语句
SELECT TIMESTAMP1 as aa
FROM T1
WHERE TIMESTAMP1 BETWEEN TIMESTAMP2 AND TIMESTAMP3;

测试结果
aa(TIMESTAMP)
1969-07-20 20:17:30

IS NOT FALSE
更新时间：2018-12-27 19:12:33


本页目录
语法
入参
功能描述
示例
本文为您介绍如何使用实时计算逻辑运算函数IS NOT FALSE。

语法
A IS NOT FALSE
入参
参数	数据类型
A	BOOLEAN
功能描述
如果A是TRUE，返回TRUE。如果A是FALSE，返回FALSE。

示例
测试数据
int1(INT)	int2(INT)
255	97
测试语句
SELECT int2 as aa
FROM T1
WHERE int1=255 IS NOT FALSE;
测试结果
aa(int)
97


IS NOT NULL
更新时间：2018-12-27 19:12:50


本页目录
语法
入参
功能描述
示例
本文为您介绍如何使用实时计算逻辑运算函数IS NOT NULL。

语法
value IS NOT NULL
入参
参数	数据类型
value	任意数据类型
功能描述
如果 value为NULL，返回FALSE，否则返回TRUE。

示例
测试数据
int1(INT)	int2(VARCHAR)
97	无
9	ww123
测试语句
SELECT int1 as aa
FROM T1
WHERE int2 IS NOT NULL;
测试结果
aa(int)
9

IS NOT TRUE
更新时间：2018-12-27 19:14:12


本页目录
语法
入参
功能描述
示例
本文为您介绍如何使用实时计算逻辑运算函数IS NOT TRUE。

语法
A IS NOT TRUE
入参
参数	数据类型
A	BOOLEAN
功能描述
如果A是TRUE，返回FALSE。如果A是FALSE，返回TRUE。

示例
测试数据
int1(INT)	int2(INT)
255	97
测试语句
SELECT int1 as aa
FROM T1
WHERE int1=25 IS NOT TRUE;
测试结果
aa(int)
97

IS NOT UNKNOWN
更新时间：2018-12-27 19:14:30


本页目录
语法
入参
功能描述
示例一
示例二
本文为您介绍如何使用实时计算逻辑运算函数IS NOT UNKNOWN。

语法
A IS NOT UNKNOWN
入参
参数	数据类型
A	BOOLEAN
功能描述
A为逻辑比较表达式，例如： 6<8。

正常情况下数值型与数值型作逻辑比较时，A值为TRUE或者FALSE。当其中一个不为数值型数据类型时，就会出现无法比较的情况。IS NOT UNKNOWN 就是判断这种情况是否存在。 当两边无法进行正常的逻辑判断时，即A值既不是TRUE也不是FALSE，返回 FALSE。可正常逻辑判断时，即A值为TRUE或者FALSE，返回 TRUE 。

示例一
测试数据
int1(INT)	int2(INT)
255	97
测试语句
SELECT int2 as aa
FROM T1
WHERE int1=25 IS NOT UNKNOWN;
测试结果
aa(int)
97
示例二
测试数据
int1(INT)	int2(INT)
255	97
测试语句
SELECT int2 as aa
FROM T1
WHERE int1 < null IS NOT UNKNOWN;
测试结果
aa(int)
空

IS NULL
更新时间：2018-12-27 19:14:48


本页目录
语法
入参
功能描述
示例
本文为您介绍如何使用实时计算逻辑运算函数IS NULL。

语法
value IS NULL
入参
参数	数据类型
value	任意数据类型
功能描述
如果 value为NULL，返回TURE，否则返回FALSE。

示例
测试数据
int1(INT)	int2(VARCHAR)
97	无
9	www
测试语句
SELECT int1 as aa
FROM T1
WHERE int2 IS NULL;
测试结果
aa(int)
97

IS TRUE
更新时间：2018-12-27 19:15:34


本页目录
语法
入参
功能描述
示例
本文为您介绍如何使用实时计算逻辑运算函数IS TURE。

语法
A IS TRUE
入参
参数	数据类型
A	BOOLEAN
功能描述
如果A是TRUE，返回TURE。如果A是FALSE，返回FALSE。

示例
测试数据
int1(INT)	int2(INT)
255	97
测试语句
SELECT int1 as aa
FROM T1
WHERE int1=255 IS TRUE;
测试结果
aa(int)
97

IS UNKNOWN
更新时间：2018-12-27 19:15:53


本页目录
语法
入参
功能描述
示例一
示例二
本文为您介绍如何使用实时计算逻辑运算函数IS UNKNOWN。

语法
A IS UNKNOWN
入参
参数	数据类型
A	BOOLEAN
功能描述
当两边无法进行正常的逻辑判断时，即A(逻辑比较表达式)值既不是TRUE也不是FALSE，返回 TRUE。可正常逻辑判断时，即A值为TRUE或者FALSE，返回 FALSE。正常情况下数值型 与数值型作逻辑比较时(例如6<>8)，A值为TRUE或者FALSE。但是，当其中一个不为数值型数据类型时，就会出现无法比较的情况。IS UNKNOWN就是判断这种情况是否存在。

示例一
测试数据
int1(INT)	int2(INT)
255	97
测试语句
SELECT int2 as aa
FROM T1
WHERE int1=25 IS UNKNOWN;
测试结果
aa(int)
空
示例二
测试数据
int1(INT)	int2(INT)
255	97
测试语句
SELECT int2 as aa
FROM T1
WHERE int1 > null IS UNKNOWN;
测试结果
aa(int)
97

LIKE
更新时间：2019-04-19 10:33:57

编辑 ·
本页目录
语法
入参
功能描述
示例1
示例2
本文为您介绍如何使用实时计算逻辑运算函数LIKE。

语法
A LIKE B

入参
参数	数据类型
A	VARCHAR
B	VARCHAR
功能描述
如果匹配，返回TRUE，否则返回FALSE。
说明 %可用于定义通配符。
示例1
测试数据
int1(INT)	VARCHAR2(VARCHAR)	VARCHAR3(VARCHAR)
90	ss97	97ss
99	ss10	7ho7
测试语句
SELECT int1 as aa
FROM T1
WHERE VARCHAR2 LIKE 'ss%';

测试结果
aa(int)
90
99
示例2
测试数据
int1(INT)	VARCHAR2(VARCHAR)	VARCHAR3(VARCHAR)
90	ss97	97ss
99	ss10	7ho7
测试语句
SELECT int1 as aa
FROM T1
WHERE VARCHAR3 LIKE '%ho%';

测试结果
aa(int)
99

NOT
更新时间：2018-12-27 19:16:36


本页目录
语法
入参
功能描述
示例
本文为您介绍如何使用实时计算逻辑运算函数NOT。

语法
NOT A
入参
参数	数据类型
A	BOOLEAN
功能描述
如果A是TRUE，返回FALSE。如果A是FALSE，返回TRUE。

示例
测试数据
int2(INT)	int3(INT)
97	65
测试语句
SELECT int2 as aa
FROM T1
WHERE NOT int3=62;
测试结果
aa(int)
97


NOT BETWEEN AND
更新时间：2019-04-19 10:34:28

编辑 ·
本页目录
语法
入参
功能描述
示例1
示例2
示例3
本文为您介绍如何使用实时计算逻辑运算函数NOT BETWEEN AND。

语法
A NOT BETWEEN B AND C

入参
参数	数据类型
A	DOUBLE、BIGINT、INT、VARCHAR、DATE、TIMESTAMP、TIME
B	DOUBLE、BIGINT、INT、VARCHAR、DATE、TIMESTAMP、TIME
C	DOUBLE、BIGINT、INT、VARCHAR、DATE、TIMESTAMP、TIME
功能描述
NOT BETWEEN AND操作符用于选取不存在与两个值之间的数据范围内的值。

示例1
测试数据
int1(INT)	int2(INT)	int3(INT)
90	97	80
11	10	7
测试语句
SELECT int1 as aa
FROM T1
WHERE int1 NOT BETWEEN int2 AND int3;

测试结果
aa(int)
11
示例2
测试数据
var1(varchar)	var2(varchar)	var3(varchar)
d	a	c
测试语句
SELECT int1 as aa
FROM T1
WHERE var1 NOT BETWEEN var2 AND var3;

测试结果
aa(varchar)
d
示例3
测试数据
TIMESTAMP1(TIMESTAMP)	TIMESTAMP2(TIMESTAMP)	TIMESTAMP3(TIMESTAMP)
1969-07-20 20:17:30	1969-07-20 20:17:40	1969-07-20 20:17:45
测试语句
SELECT TIMESTAMP1 as aa
FROM T1
WHERE TIMESTAMP1 NOT BETWEEN TIMESTAMP2 AND TIMESTAMP3;

测试结果
aa(TIMESTAMP)
1969-07-20 20:17:30

===========

DDL概述
更新时间：2019-03-27 17:37:21

编辑 ·
 · 我的收藏
本页目录
语法
说明
字段映射
处理大小写敏感
相关章节
本文为您介绍实时计算DDL语法以及在DDL使用过程中需要注意的字段映射和大小写敏感问题。

语法
CREATE TABLE tableName
      (columnName dataType [, columnName dataType ]*)
      [ WITH (propertyName=propertyValue [, propertyName=propertyValue ]*) ];
说明
阿里云实时计算本身不带有数据存储功能，所有涉及表创建DDL的操作，实际上均是对于外部数据表、存储的引用声明，如下所示。

CREATE TABLE mq_stream(
 a VARCHAR,
 b VARCHAR,
 c VARCHAR
) WITH (
 type='mq',
 topic='blink_mq_test',
 accessID='xxxxxx',
 accessKey='xxxxxx'
);

以上代码不是在Flink SQL中创建消息队列（MQ）源表的topic，而是声明了一个名称为mq_stream的表引用。下游所有对这个MQ的topic相关的DML操作中，均可以用别名mq_stream来代替topic名。

实时计算声明表的作用域是当前作业（1个SQL文件提交后生成1个实时计算作业），即上述有关mq_stream的声明仅在当前SQL有效。相同实时计算项目下的不同SQL文件同样可以声明名称为mq_stream的表。
按照SQL标准定义，DDL语法中关键字、表名、列名等不区分大小写。
表名、列名必须以字母或者数字开头，并且名称中只能包含字母、数字或下划线。
DDL声明不完全根据名称进行映射（取决于上游插件的性质）。建议您引用声明的字段名称、字段个数和外部表保持一致，避免因定义混乱而导致的数据错乱情况。
说明 对于声明表和外部表，如果插件支持根据key取值，则不要求两者字段数量一致，但字段名称需要一致。如果上游插件不支持根据key取值，则需要字段数量和字段顺序一致。
字段映射
声明表的字段映射根据外部数据源是否有Shema，分为两大类别。
顺序映射
适用于以MQ为代表的不带有Schema系统。这类系统通常是非结构化存储系统，不支持根据key取值。建议您在DDL SQL声明中对字段名称进行自定义，并且和外部表的字段类型、字段数量保持一致。

如下以MQ的1条记录为例。

asavfa,sddd32,sdfdsv
按照命名规范设置MQ的字段名。

CREATE TABLE mq_stream(
 a VARCHAR,
 b VARCHAR,
 c VARCHAR
) WITH (
 type='mq',
 topic='blink_mq_test',
 accessID='XXXXXX',
 accessKey='XXXXXX'
);
名称映射
适用于带有Schema的系统。这类系统在表存储级别定义了字段名称以及字段类型，支持根据key取值。建议您在Flink SQL的声明中保持和外部数据存储Schema定义一致，包括字段名称、字段数量以及字段的顺序。
说明 如果外部数据存储的字段名称是大小写敏感类型（如表格存储），则需要在区分大小写的字段名称处使用反引号 ｀｀进行转换。在DDL语法中，声明表的字段名和外部表的字段名需要一致。
DataHub定义的Schema如下：

字段名	类型
name	STRING
age	BIGINT
value	STRING
说明 DataHub中的STRING数据类型对应的是在实时计算中的VARCHAR类型。
关于上述DataHub声明的DDL如下：


create  table stream_result (
    `name` varchar,
    age bigint,
    `value` varchar
  ) with (
      type='datahub',
      endpoint='http://dh-cn-hangzhou.aliyuncs.com',
      accessId='xxxxxx',
      accessKey='xxxxxx',
      project='project',
      topic='topic'
  );
说明 建议您将所有列进行声明引用。声明引用时可以减少字段，不能新增字段。
处理大小写敏感
SQL标准定义中，大小写是不敏感的。如下所示，2段语句的含义相同。

create table stream_result (
    name varchar,
    value varchar
);
create table STREAM_RESULT (
    NAME varchar,
    VALUE varchar
);
但实时计算引用的大量外部数据源中，存在要求大小写敏感的数据源。例如，表格存储（Table Store）对于大小写是敏感的。如果需要在Table Store定义大写NAME字段，我们应该如下定义。

create  table STREAM_RESULT (
    `NAME` varchar,
    `VALUE` varchar
);
在之后所有的DML操作中，对于这个字段的引用均需要添加反引号｀｀，如下所示。

INSERT INTO xxx
SELECT
  `NAME`,
  `VALUE`
FROM
  XXX;

https://help.aliyun.com/knowledge_detail/62520.html
数据源表概述
更新时间：2019-03-18 09:40:12

编辑 ·
本页目录
语法
示例
获取数据源表属性字段
包含窗口函数的数据源表
支持创建的数据源表类型
实时计算的数据源表是指流式数据存储。流式数据存储驱动实时计算的运行，因此每个实时计算作业必须提供至少1个流式数据存储。

语法
  CREATE TABLE tableName
      (columnName dataType [, columnName dataType ]*)
      [ WITH (propertyName=propertyValue [, propertyName=propertyValue ]*) ];
示例
CREATE TABLE  datahub_stream(
  name VARCHAR,
  age BIGINT,
  birthday BIGINT
) WITH (
  type='datahub',
  endPoint='xxxxxx',
  project='xxxxxx',
  topic='xxxxxx',
  accessId='xxxxxx',
  accessKey='xxxxxx',
  startTime='2017-07-21 00:00:00'
);
获取数据源表属性字段
获取数据源表属性字段语法
实时计算在源表的DDL语句中提供 HEADER 关键字，用于获取源表中的属性字段。

CREATE TABLE sourcetable
(
 `timestamp`  VARCHAR HEADER,
  name        VARCHAR，
  MsgID       VARCHAR
)WITH(
     type='XXX'
);
上面示例中 `timestamp`字段定义为 HEADER，可从数据的属性字段读取数值，后续当成普通字段使用。
说明 不同的源表（DataHub/Log Service/MQ等）存在不同的默认属性字段，部分源表支持设置自定义的属性字段，具体请参见对应的源表文档。
获取源表属性字段示例
以日志服务（Log service）为例，为您介绍如何获取源表属性字段。目前日志服务默认支持如下3个属性字段。

字段名	说明
__source__	消息源
__topic__	消息主题
__timestamp__	日志时间
说明 获取属性字段，除了按照正常逻辑声明外，还需要在类型声明后面加上 HEADER。
示例如下：

示例数据
__topic__:  ens_altar_flow
        result:  {"MsgID":"ems0a","Version":"0.0.1"}
示例语句
CREATE TABLE sls_log (
  __topic__  VARCHAR HEADER,
  result     VARCHAR
)WITH(
  type ='sls'
);
CREATE TABLE sls_out (
  name     varchar,
  MsgID    varchar,
  Version  varchar
)WITH(
  type ='RDS'
);
INSERT INTO sls_out
SELECT
__topic__,
JSON_VALUE(result,'$.MsgID'),
JSON_VALUE(result,'$.Version')
FROM
sls_log
测试结果
name(VARCHAT)	MsgID(VARCHAT)	Version(VARCHAT)
ens_altar_flow	ems0a	0.0.1


包含窗口函数的数据源表
实时计算可以基于Event Time和Processing Time这2种时间属性对数据进行窗口聚合。包含窗口函数的作业中，数据源表的声明中需要使用到watermark和计算列方法。实时计算基于时间属性的聚合详情，请参见时间属性。

支持创建的数据源表类型
实时计算支持创建多种类型的数据源表。详情请参见以下文档。
创建数据总线（DataHub）源表
创建日志服务（Log Service）源表
创建消息队列（MQ）源表
创建消息队列（Kafka）源表













-----------

阿里云实时计算(Alibaba Cloud Realtime Compute)是一套基于Apache Flink构建的一站式、高性能实时大数据处理平台，广泛适用于流式数据处理、离线数据处理、DataLake计算等多种场景。阿里云实时计算产品彻底规避繁重的底层流式处理逻辑开发工作，助力中国企业向实时化、智能化大数据计算升级转型。

阿里实时计算开发平台为实时计算产品Flink SQL作业提供了一站式的存储管理、作业开发、作业调试、运维管理和监控报警的功能。

Flink SQL开发指南主要包含以下内容：

数据存储
提供了实时计算主流的上下游存储（RDS、DataHub、OTS等）的管理界面，通过存储注册方式引入的上下存储，可以实现数据预览、数据抽样以及自动生成DDL的功能，请参见数据存储概述。
若共享模式集群需访问阿里云VPC网络下的存储资源，请参见VPC访问授权。
若实时计算访问的上下游存储存在白名单机制，请参见如何配置数据存储白名单。
作业开发
介绍Flink SQL作业开发、上线到启动的整个流程。

作业调试
介绍Flink SQL作业调试功能，包括本地调试和线上调试。

数据运维
介绍作业状态、数据曲线、Failover等数据运维相关内容。

监控报警
介绍如何创建和启动报警规则。

配置调优
介绍Flink SQL作业的调优功能，主要包括SQL调优、autoconf自动调优、autoscale自动调优和手动配置调优。

Flink SQL介绍
Flink SQL语法，具体请参见Flink SQL概述

数据存储概述
更新时间：2019-04-15 16:34:15

编辑 ·
 · 我的收藏
本页目录
明文方式
存储注册方式
阿里云实时计算提供包括RDS、DataHub、OTS等各类数据存储系统的管理界面，为您提供一站式云上数据存储管理。

数据存储有两层含义，一方面代表的是实时计算产品上下游生态对应的数据存储系统/数据库表（以下简称存储资源，具体见产品生态），另一方面代表实时计算产品对上下游存储资源的管理功能（以下简称数据存储功能）。实时计算产品使用上下游存储资源有两种方式，第一种我们称之为明文方式，第二种我们称之为存储注册方式，下面我们分别做介绍。
说明 实时计算使用存储资源前需要提前授权，即需要您授权实时计算访问存储资源的权限。是否已授权及授权方法请您参看角色授权。
明文方式
您通过在作业的DDL语句的with参数中直接使用AccessId/AccessKey来引用上下游存储资源。具体方法见Flink SQL-DDL语句。明文方式不仅仅支持同账号（包括主子账号）授权，同时还支持跨账号授权。如当前实时计算的A用户(包括A下所属的子账户)，若需要使用用户B的存储资源，则可以通过如下明文方式定义DDL：

试用
CREATE TABLE in_stream(
  a varchar,
  b varchar,
  c timestamp
)with(
type='datahub',
  endPoint='http://dh-cn-hangzhou.aliyuncs.com',
  project='dataHubProjectName',
  topic='dataHubTopicName',
  accessId='accessIdOfUserB',
  accessKey='accessKeyOfUserB');
存储注册方式
为了方便用户管理上下游存储资源，实时计算产品提供了数据存储管理功能，通过提前将上下游存储资源注册到实时计算开发平台，您能够享受到数据预览、数据抽样、自动生成DDL等功能，让您一站式管理您的云上存储资源。

说明 实时计算数据存储功能当前仅支持同账号属主下的存储资源，即当前使用实时计算的A用户(包括A用户的子账户)所注册的存储资源，必须是A购买的存储资源。不支持跨账号授权，对于跨账号授权使用存储资源，请使用明文方式。
注册数据存储
点击开发界面左侧的数据存储，选择右上角的注册与网络，即可进入注册数据存储界面。


目前实时计算产品仅支持注册如下五种存储资源，具体方法请点击以下产品链接：

注册Datahub
注册分析型数据库（AnalyticDB）
注册表格存储（TableStore）
注册云数据库（RDS）
注册日志服务（Log Service）
数据预览
对于已经注册的存储资源，实时计算提供数据预览功能，点击数据存储，选择某个数据存储类型，即可预览数据。


数据抽样
对于已经注册的存储资源，实时计算提供数据抽样功能，点击数据存储，选择某个数据存储类型，点击数据抽样即可进入数据抽样界面。对于抽样的数据结果，可点击右上方的下载数据进行下载。


自动生成DDL
对于已经注册的存储资源，实时计算提供自动生成DDL的功能，在作业编辑界面，点击数据存储，选择某个数据存储类型，点击作为输入表引用（或作为结果表引用、作为维表引用）即可自动生成DDL。


自动生成的DDL仅包含基本的with参数保证实时计算与存储资源的连通性，您可在此基础上增加其他with参数。

网络探测
实时计算的数据存储功能还提供网络探测功能，用于探测实时计算产品与被探测的存储资源的网络连通性。点击数据存储 > 注册与网络，并打开网络探测模式开关即可使用网络探测功能。

注册大数据总线（DataHub）
更新时间：2019-03-15 09:22:29

编辑 ·
本页目录
注册
常见问题
本文为您介绍如何注册实时计算大数据总线（DataHub）数据存储，以及注册存储过程中的常见问题。

注册
DataHub作为一个流式数据总线，为阿里云数加平台提供了大数据的入口服务。结合阿里云众多云产品，可以构建一站式的数据处理平台。实时计算通常使用DataHub作为流式数据存储头和输出目的端。

说明 DataHub在公有云使用需要用户授予实时计算代为用户访问DataHub权限，具体请参见共享模式角色授权。否则可能出现报错 No Permission。
22
说明 如何进入注册数据存储界面请参见注册数据存储。
Endpoint
填写Datahub的Endpoint。需要注意，不同地域下DataHub有不同的Endpoint，具体请参见

Datahub访问控制。
说明 http://dh-cn-hangzhou.aliyun-inc.com不要使用 /结尾。
共享模式：使用经典网络ECS Endpoint。如华东1（杭州）使用http://dh-cn-hangzhou.aliyun-inc.com。共享模式大集群所在的区域与Datahub所在区域不要求一致，但不一致可能额外增加网络延时。
独享模式：使用VPC ECS Endpoint。如华东1（杭州）使用http://dh-cn-hangzhou.aliyun-inc.com。独享模式小集群所在的区域与Datahub所在区域要求一致。
有关专有云的Endpoint填写，请联系您的专有云系统管理员，咨询有关DataHub Endpoint地址。
Project
填写DataHub的Project。

说明 跨属主的数据存储不能注册。例如A用户拥有DataHub的ProjectA，但B用户希望在实时计算使用ProjectA，目前实时计算暂不支持这类使用场景下注册，若需使用可使用明文方式，具体参考数据存储概述-明文方式明文方式。
常见问题
Q: 为什么我注册失败，失败原因提示XXX？

A: 实时计算的数据存储页面能够协助您完成数据管理，其本身就是使用相关存储SDK代为访问各类存储。因此很多情况下可能是您注册过程出现问题导致，请排查如下原因。

请确认是否已经开通并拥有DataHub的Project。请登录DataHub控制台，公有云客户可以访问DataHub控制台看您是否有权限访问您的Project。
请确认您是DataHub Project的属主。跨属主的数据存储不能注册。
请确认您填写的DataHub的Endpoint和Project完全正确。DataHub Endpoint必须以http开头，且不能以(/)结尾。例如，http://dh-cn-hangzhou-internal.aliyuncs.com是正确的，但http://dh-cn-hangzhou-internal.aliyuncs.com/是错误的。
请确认您填写的DataHub Endpoint是经典网络地址，而非VPC地址。目前实时计算暂不支持VPC内部地址。
请不要重复注册，实时计算提供注册检测机制，避免您重复注册。
Q: 为什么数据抽样仅仅针对时间抽样，不支持其他字段抽样？

A: DataHub定位是流数据存储，对外提供的接口也只有时间参数。因此，实时计算也只能提供基于时间的抽样。


注册分析型数据库（AnalyticDB）
更新时间：2019-03-21 14:46:00

编辑 ·
本页目录
注册
本文为您介绍如何使用存储注册的方式连接分析型数据库（AnalyticDB）数据存储。

注册

信息填写如下
URL：AnalyticDB控制台链接信息串。
共享模式：请使用AnalyticDB的经典网络的连接点
独享模式：请使用AnalyticDB的VPC网络的连接点。
Database：AnalyticDB数据库名称，即ADS实例名称。
AccessId：阿里云账号安全信息页面的AccessID。
AccessKey：阿里云账号安全信息页面的AccessKey。
说明
URL​地址查询
登录AnalyticDB 控制台。
点击对应的实例名称，进入基本信息页面。
在连接信息 > 连接地址中查看相应的连接地址。
AccessId、AccessKey信息查询参见如何查看AccessID、AccessKey信息。

注册日志服务（Log Service）
更新时间：2019-04-01 16:04:09

编辑 ·
本页目录
注册
常见问题
本文为您介绍实时计算如何使用存储注册的方式连接日志服务（Log Service），以及存储注册过程中的常见问题。

注册
日志服务（Log Service）简称LOG，原称SLS。是针对日志场景的一站式解决方案。提供海量日志数据采集、订阅、转储与查询功能。日志服务是阿里云的日志管理平台。在您使用日志服务完成了对ECS日志的管理的前提下，实时计算可以直接对接日志服务的LogHub存储，无需对数据进行迁移。

说明 日志服务在公有云使用时，需要您授予实时计算代为您访问日志服务的权限（具体请参看角色授权），否则可能出现报错 No Permission。
4
Endpoint
填写日志服务的Endpoint。不同的地域下日志服务有不同的Endpoint，请参见日志服务服务入口服务入口。
说明
Endpoint需增加http://开头，且不能使用/结尾，如http://cn-hangzhou-intranet.log.aliyuncs.com。
实时计算和日志服务同处于阿里云内网，建议您填写经典网络或VPC网络服务入口。为了避免消耗大量外网带宽和导致可能的性能问题，不建议填写公网服务入口。
有关专有云日志服务的Endpoint填写，请咨询专有云系统管理员。
Project
填写日志服务的Project。

说明 跨属主的数据存储不能注册。例如A用户拥有日志服务的Project A，但B用户希望在实时计算使用Project A。目前，实时计算暂不支持这类场景下的数据存储注册方式，您可以使用明文方式，具体参见明文方式。
常见问题
Q: 为什么我注册失败，失败原因提示XXX？

A: 实时计算的数据存储页面能够协助您完成数据管理，其本身就是使用相关存储SDK代为访问各类存储。因此很多情况下可能是您注册过程出现问题导致。请排查如下原因。

请确认是否已经开通并拥有日志服务的Project。请登录日志服务控制台，公有云用户可以访问日志服务控制台看您是否有权限访问您的Project。
请确认您是日志服务Project的属主。跨属主的数据存储不能注册。
请确认您填写的日志服务的Endpoint和Project完全正确。特别注意的是日志服务 Endpoint必须以http开头，且不能以/结尾，例如http://cn-hangzhou.log.aliyuncs.com是正确的，但http://cn-hangzhou.log.aliyuncs.com/是错误的。
请不要重复注册。实时计算提供注册检测机制，避免您重复注册。
Q: 为什么数据抽样仅仅针对时间抽样，不支持其他字段抽样？

A: 日志服务定位是流数据存储，对外提供的接口也只有时间参数。因此，实时计算也只能提供基于时间的抽样。如果希望使用日志服务的检索功能，请登录并确认是否已经开通并拥有日志服务的Project。请登录日志服务控制台使用检索。

注册云数据库（RDS）
更新时间：2019-01-22 17:30:38

编辑 ·
本页目录
注册
常见问题
本文为您介绍如何使用存储注册的方式连接云数据库（RDS）数据存储，以及连接过程中的常见问题。

云数据库RDS（ApsaraDB for RDS，简称RDS）是一种稳定可靠、可弹性伸缩的在线数据库服务。目前实时计算支持包括MySQL在内的RDS引擎。

说明
RDS在公有云使用需要您授予实时计算访问RDS的权限，具体请参看角色授权。否则可能出现报错No Permission的情况。
在实时计算中，下游数据库使用MySQL等关系数据库（对应的CONNECTOR为TDDL和RDS），当实时计算频繁写某个表或者资源时，存在死锁风险。高QPS/TPS或高并发写入情况场景，一般不建议使用TDDL或者RDS作为实时计算作业的结果表，建议使用表格存储（TableStore）作为结果表，可以避免死锁的问题。
注册
说明 存储注册过程中系统会为RDS自动配置IP白名单。
74
信息填写：
Region
选择RDS的地域，请您选择RDS所在地域。

Instance
填写RDS实例ID。
说明 请填写实例ID，不是实例名称。
DBName
填写RDS下DataBase的名称。
说明 DataBase是RDS的数据库名称，不是Instance的名称。
Username
数据库登录名称。

Password
数据库登录密码。

白名单授权
目前RDS使用白名单进行安全保证，实时计算存储注册方式为RDS自动添加IP白名单。

常见问题
Q：存储注册过程中出现报错操作错误：未在VPC中授权？

66
A：引起该报错的原因是，您在创建RDS实例时选择的不是经典网络，而是专有网络（VPC模式）。对于这种实例应该进行VPC访问授权。请参看VPC访问授权。

注册表格存储（TableStore）
更新时间：2019-01-22 17:32:03

编辑 ·
本页目录
注册
本文为您介绍实时计算如何用存储注册的方式连接表格存储（TableStore）。

注册
表格存储（Table Store）是构建在阿里云飞天分布式系统之上的NoSQL数据存储服务。能够提供海量结构化数据的存储服务和实时访问服务。实时计算对于请求访问时延要求较高，同时对于关系型代数需求又较低。因此，实时计算非常适合使用TableStore作为数据维表和结果表。
说明 若您在使用Table Store时，出现 No Permission类似错误，请参见角色授权授予实时计算访问TableStore的权限。
65
Endpoint
填写TableStore的Endpoint。请在OTS控制台查看TableStore的Endpoint信息，填写TableStore私网地址。具体步骤请参见表格存储（TableStore）Endpoint。

TableStore访问网络类型设置为允许任意网络访问。登录OTS控制台选择实例详情 > 实例网络类型 > 更改 > 允许任意网络访问。如下图:
实例名称
填写TableStore的实例名称。

开发
更新时间：2019-04-10 16:58:05

编辑 ·
 · 我的收藏
本页目录
开发流程
语法检查
作业参数
SQL辅助
SQL版本管理
本文为您介绍阿里实时计算平台作业开发流程以及在作业开发过程中涉及到的其他功能如：语法检查、SQL辅助、SQL版本管理和引擎版本切换功能。

实时计算用户主要使用Flink SQL进行作业开发，Flink SQL开发手册参见Flink SQL。

开发流程
在开发界面点击新建作业。
进入作业编辑界面，编写SQL代码。
说明
可以在作业右侧代码结构查看SQL代码结构。
建议使用左侧数据存储管理上下游存储，具体参见数据存储概述。
语法检查
点击作业开发页面顶部的 语法检查可检测SQL语句并显示出错误SQL语句的错误信息。
说明
对作业进行保存操作也可以触发SQL语法检查功能。
请编写完整的SQL逻辑后再进行语法检查，否则语法检查不生效。
作业参数
您可在开发界面右侧作业参数页面配置作业所需参数。

SQL辅助
Flink SQL语法检查
您在修改IDE文本后即可进行自动保存。保存操作可以触发SQL语法检查功能。语法校验出错误后，将在IDE界面提示出错行数、列数以及错误原因。

Flink SQL智能提示
您在输入Flink SQL过程中，IDE提供包括关键字、内置函数、表、字段智能记忆等提示功能。

Flink SQL语法高亮
针对Flink SQL关键字，提供不同颜色的语法高亮功能，以区分Flink SQL不同结构。

SQL版本管理
数据开发为您提供代码版本管理功能。您每次提交即可生成一个代码版本。代码版本用于版本追踪、版本修改以及后期版本回滚。

点击 版本信息页面 操作字段下的 更多，选择相应的版本管理功能：
对比：查看最新代码和指定版本的差异
回滚：使用回滚功能回滚到指定版本。
删除：实时计算公共云默认版本数上限是20。如果生成的版本超过最大值，系统将不允许该作业的提交请求，并提示您删除部分旧版本作业。
说明 版本数低于或等于版本上限数后可再次提交作业。
锁定：锁定当前作业版本，解锁前无法提交新版本。

上线
更新时间：2019-03-22 15:21:34

编辑 ·
 · 我的收藏
本页目录
上线步骤
本文为您介绍实时计算作业的上线步骤。

您完成开发、调试，经验证Flink SQL正确无误之后，点击上线，即可将数据发布到生产系统。

上线步骤
资源配置
选择对应的资源配置方式。第一次启动建议使用系统默认配置。
说明 阿里实时计算平台提供手动资源配置和自动资源配置2方式
手动资源配置参见
自动资源配置参见

autoconf自动配置，支持blink 1.x和2.x版本。
autoscale自动配置，支持blink 3.x版本。
数据检查
数据检查通过后，点击下一步 。

上线作业
点击上线 。作业上线后只是将作业提交至集群，并没有启动作业。启动作业请参见

启动
更新时间：2019-03-22 15:24:17

编辑 ·
 · 我的收藏
作业开发、上线后即可在运维界面启动作业。

点击运维进入运维界面。
选择对应的作业，点击启动，如下图。
上线启动
指定读取数据时间（启动位点），点击确定，完成作业启动。如下图。作业启动完成后即可进入作业运维阶段。
说明 启动位点表示从source表中读取数据的时间点，若选择当前时间则表示从当前时间开始读取数据；若选择过去的某个时间点，则表示从过去时间点开始读取数据，一般用于回追历史数据。

本地调试
更新时间：2019-04-18 20:00:13

编辑 ·
 · 我的收藏
本页目录
作业调试
Flink SQL在调试环境中的特点
本文为您介绍实时计算本地调试流程及本地调试环境的特点。

阿里实时计算开发平台提供了一套模拟的运行环境，您可以在调试环境中自定义上传数据，模拟运行，检查输出结果从而验证业务逻辑的正确性。

作业调试
作业调试步骤如下。

进入调试页面。
调试页面
准备数据。提供两种准备数据的方式。
本地上传方式
下载模板
根据模板，准备数据。
数据上传 。完成后可在数据预览界面查看已上传数据。
说明 默认数据分隔符为逗号，如果需要自定义分隔符请参见调试数据分隔符。
线上抽样方式
点击随机抽样线上数据或顺序抽样线上数据。
抽样成功后可在数据预览界面查看抽样数据。
点击确定，启动调试，查看调试输出结果。
调试输出
Flink SQL在调试环境中的特点
与生产环境完全隔离
调试环境下，所有的Flink SQL将在独立的调试容器运行，且所有的输出将被直接改写到调试结果屏幕。不会对线上的生产流、实时计算作业和线上生产的数据存储系统造成任何影响。 数据调试结果实际上不会真正写入到外部数据存储，而是被实时计算拦截输出到屏幕。因此，在实时计算调试完成的代码是在调试容器中完成。
说明 线上运行过程中可能由于对目标数据存储写入格式的不同导致运行失败。这类错误在调试阶段无法完全规避，在线上运行时才能发现。例如，您将结果数据输出到RDS系统。其中某些字段输出字符串数据长度大于RDS建表最大值，在Debug环境下我们无法测试出该类问题。但实际生产运行过程中会有引发异常。后续，实时计算将提供针对本地调试运行，支持写出到真实数据存储的功能，有效辅助您缩短调试和生产的差距，有助于在调试阶段解决问题。
83
调试数据分隔符
默认情况下，调试文件使用逗号作为分隔符。例如，您构造了如下的测试数据。

试用
id,name,age
1,alicloud,13
2,stream,1
在不指定调试分隔符情况下，默认使用了逗号进行分隔。假设您需要使用JSON文件作为字段内容，字段内容已经包含了逗号。此时您需要指定其他字符作为分隔符。

说明 实时计算仅支持指定单个英文字符（如下图中的 |）为分隔符。不允许字符串，例如 aaa作为分隔符。
试用
id|name|age
1|alicloud|13
2|stream|1
此时您需要设置如下参数（以分隔符|为例）。

试用
debug.input.delimiter = |
2134

线上调试
更新时间：2019-03-25 17:30:16

编辑 ·
 · 我的收藏
本页目录
线上调试Connector
线上调试结果查询
本文为您介绍实时计算线上调试功能以及线上调试结果查询方法。

线上调试Connector
为了方便您进行线上调试，阿里实时计算平台提供了两种特殊的Connector。
random源表：用于周期性生成对应类型的随机数据。
print结果表：用于输出计算结果。
Random表参数
参数	说明
type	必选，取值唯一且为random
interval	可选，产生数据的时间间隔（单位：ms），默认值为500ms
Print表参数
参数	说明
type	必选，取值唯一且为print
ignoreWrite	可选，如果您想用print来当成一个空结果表而不输出日志，可以配上参数ignoreWrite='true' （默认值为false）
示例
测试语句
试用
CREATE TABLE random_source (
  instr               VARCHAR
) WITH (
  type = 'random'
);

CREATE TABLE print_sink(
  instr VARCHAR,
  substr VARCHAR,
  num INT
)with(
  type = 'print'
);

INSERT INTO print_sink
SELECT
  instr,
  SUBSTRING(instr,0,5) AS substr,
  CHAR_LENGTH(instr) AS num
FROM random_sourceceROM random_source
测试结果
线上调试测试结果如下图。

线上调试结果查询
说明
查询线上调试结果前，请先确保作业上线和启动。
线上调试会消耗一定的CU。
线上调试结果查询查看步骤如下。

点击顶部导航栏的运维，进入运维页面。
点击作业名称下对应的作业，进入作业运维页面。
在Vertex拓扑区域，点击相应结果表节点。
点击SubTask List > 查看日志，进入日志查看窗口。
查看相应的日志。
Print结果表输出
点击taskmanager.out右侧的查看日志。

UDX日志输出
如果您使用UDX，在Java代码中有两种调试方法：system out/err和SLF4J的Logger。

system out/err方法
点击taskmanager.out或taskmanager.err右侧的查看日志。

SLF4J的Logger方法
点击taskmanager.log右侧的查看日志。


据在缓冲区的交换，减少了延迟的同时提高整体的吞吐量。 operator代表的是每个计算逻辑的算子，而task代表是多个operator的集合。

视图模式
为了方便您理解，阿里实时计算平台把底层计算逻辑抽象成为如下视图。
13
Task的详细的信息如下。您也可以将鼠标移动到Task显示详情的信息。

名称	信息描述
ID	表示在运行拓扑图的编码。
PARALLEL	表示的并发量。
TPS	表示每秒读取上游数据的BLOCK数。
LATENCY	表示Task节点的计算耗时。
DELAY	表示Task节点的业务延时。
IN_Q	表示Task节点的输入队列的百分比。
OUT_Q	表示Task节点的输出队列的百分比。
点击Task节点，可以进入详情页面查看Task的里线程的列表。
1324
阿里实时计算平台提供每个Task的曲线指标图。点击Task节点进入曲线图。
234
列表模式
实时计算不仅提供视图模式，同样也提供每个Task的列表模式。
13
点击Task节点，可以进入详情页面查看Task的里线程的列表。
1324
名称	信息描述
ID	表示在运行拓扑图的编码。
Name	表示每个Task的详情信息。
Status	表示每个Task的运行的状态。
InQ max	表示Task节点的输入队列，单位是百分比。
OutQ max	表示Task节点的输出队列，单位是百分比。
RecvCnt sum	表示Task节点接收到的数据量。
SendCnt sum	表示Task节点的发送的数据量。
TPS sum	表示每秒读取上游的信息量。
Delay max	表示Task节点的业务延时。
StartTime	表示Task节点的启动时间。
Duration(s)	表示Task节点的运行时间。
Task	表示每个Task节点的并发的运行状态。


数据曲线
更新时间：2019-04-26 13:54:45

编辑 ·
 · 我的收藏
本页目录
概述
Advanced View
WaterMark
Delay
Throughput
Queue
Tracing
Process
JVM
阿里云实时计算提供了当前作业的核心指标概览页面。您可以通过数据曲线对作业的运行情况的进行一键式的诊断。未来实时计算还会提供更多基于作业现状的深度智能分析算法，以辅助您进行智能化和自动化诊断。

目前的作业诊断图如下。

说明
上述所有指标在实时计算作业运行状态下才提供显示，暂停以及停止状态均不提供显示。
作业指标是实时计算系统异步后台采集，有一定延迟。作业启动1分钟后，各项指标才能逐步采集并显示到数据曲线。
概述
Failover Rate
Failover Rate指的是当前Job的出现Failover（错误或者异常）的频率。计算方法：当前Failover时间点的前1分钟内出现Failover的累计次数除以60。（例如 ，最近1分钟Failover了一次，1/60=0.01667。）

Delay
实时计算提供了三种延时指标用于衡量当前实时计算全链路的一个时效情况，用于评估当前实时计算作业是否存在反压等性能问题。


业务延时（delay）：delay = 当前系统时间 – 当前系统处理的最后一条数据的事件时间（event time）。如果后续没有数据再进入上游存储，由于当前系统时间在不断往前推进，业务延时也会随之逐渐增大。
数据滞留时间（fetched_delay）：fetched_delay = 数据进入实时计算的时间 - 数据事件时间（event time）。即使后续没有数据再进入上游存储，数据滞留时间也不会随之逐渐增大。一般用数据滞留时间来评估当前实时计算作业是否存在反压。
数据间隔时间（no_data_delay）：no_data_delay = delay – fetched_delay。在实时计算没有反压（即fetched_delay较小且平稳）时，数据间隔时间可以反映数据源数据间的稀疏程度，在实时计算存在反压（即fetched_delay较大或不平稳）时，此参数没有实质性参考意义。
说明
实时计算是分布式计算框架，以上3类延时指标的Metric首先是针对Source的单个分区（Shard/Partition等）进行计算，然后汇报所有分区中的最大值呈现到前端页面上，因此前端页面上显示的汇聚后的no_data_delay并不精确等于delay – fetched_delay。
如果Source中的某个分区没有新的数据，将会导致delay逐渐增大。
目前底层算法实现时，当no_data_delay小于10秒时，会将no_data_delay设置为0，进行上报。
各Source的TPS数据输入

数据输入功能对实时计算作业所有的流式数据输入进行统计，记录每秒读取数据源表的Block的数，让您直观的了解数据存储TPS（Transactions Per Second）的情况。与RPS（Record Per Second）不同，RPS是读取数据源TPS的Block数解析后的数据，单位是条/秒。（例如，日志服务，1秒读取5个LogGroup，那么TPS=5，如果每个LogGroup解析出来8个日志记录，那么一共解析出40个日志记录，RPS=40。）
各Sink的数据输出

数据输出功能对实时计算作业所有的数据输出（并非是流式数据存储，而是全部数据存储）做出进行统计，让您直观的了解数据存储RPS（Record Per Second）的情况。通常，在系统运维过程中，如果出现没有数据输出的情况，除了检查上游是否存在数据输入，同样要检查下游是否真的存在数据输出。
各Source的RPS数据输入

数据输入对实时计算作业所有的流式数据输入进行统计，让您直观的了解数据存储RPS（Record Per Second）情况。通常，我们在系统运维过程中，如果出现没有数据输出的情况，就需要查看该值是否从源头数据输入就已经没有数据了。
各Source的数据流量输入

流量输入对实时计算作业所有的流式数据输入进行统计，记录每秒读取输入源表的流量的统计，让您直观的了解数据流量BPS（Byte Per Second）情况。
各Source的脏数据

为您显示实时计算Source各时间段脏数据条数。
Advanced View
阿里云实时计算提供可以恢复数据流应用到一致状态的容错机制。容错机制的核心就是持续创建分布式数据流及其状态的一致快照。这些快照在系统遇到故障时，充当可以回退的一致性检查点（checkpoint）。

分布式快照的核心概念之一就是数据栅栏（barrier）。这些barrier被插入到数据流中，作为数据流的一部分和数据一起向下流动。barrier不会干扰正常数据，数据流严格有序。一个barrier把数据流分割成两部分：一部分进入到当前快照，另一部分进入下一个快照。每一个barrier都带有快照 ID，并且barrier之前的数据都进入了此快照。barrier不会干扰数据流处理，所以非常轻量。多个不同快照的多个barrier会在流中同时出现，即多个快照可能同时创建。

barrier在数据源端插入，当snapshot n的barrier插入后，系统会记录当前snapshot位置值 n （用Sn表示）。然后barrier继续往下流动，当一个operator从其输入流接收到所有标识snapshot n的 barrier时，它会向其所有输出流插入一个标识snapshot n的barrier。当sink operator （DAG 流的终点）从其输入流接收到所有barrier n时，operator向检查点协调器确认snapshot n 已完成。当所有sink都确认了这个快照，快照就被标识为完成。

以下就是记录Checkpoint的各种参数配置。
Checkpoint Duration

表示每次做Checkpoint保存状态所花费的时间，单位是MS。
CheckpointSize

表示每次做Checkpoint所消耗的内存大小。
CheckpointAlignmentTime

checkpointAlignmentTime表示当前节点做checkpoint的时候等待上游所有节点到达当前节点的时间， 也就是当sink operator（DAG 流的终点）从其输入流接收到所有barrier n时，它向the checkpoint coordinator确认snapshot n已完成。当所有sink都确认了这个快照，快照就被标识为完成。这个等待的时间就是checkpointAlignmentTime。
CheckpointCount

表示一定时间内Checkpoint的数量。
Get

在一定时间内每个SubTask Get操作ROCKSDB所花费的时间（最大值）。
Put

表示在一定时间内每个SubTask Put操作ROCKSDB所花费的时间（最大值）。
Seek

表示在一定时间内每个SubTask Seek操作ROCKSDB所花费的时间（最大值）。
State Size

表示在一定时间内Job内部state存储大小（如果增量过快JOB是异常的）。
CMS GC Time

表示在一定时间内Job底层container进行GC花费的时间。
CMS GC Rate

表示在一定时间内Job底层container进行GC的频率。
WaterMark
WaterMark Delay

表示WaterMark 距离系统时间的差值。
数据迟到丢弃TPS

表示当某个数据的时间晚于watermark到达window，那么这个数据会被丢弃，该指标统计的是每秒迟到丢弃数。
数据迟到累计丢弃数

表示当某个数据的时间晚于Watermark到达window，那么这个数据会被丢弃，该指标统计的是累计迟到丢弃数。

Delay
Source SubTask 最大延迟 Top 15

表示每个Source的并发的业务延时的时间。
Throughput
Task Input TPS

表示作业级别所有的Task的数据的输入。
Task Output TPS

表示作业级别所有的Task的数据的输出。
Queue
Input Queue Usage

表示作业级别所有的Task的数据的输入队列。
Output Queue Usage

表示作业级别所有的Task的数据的输出队列。
Tracing
以下为进阶参数：
Time Used In Processing Per Second

表示task级别的每秒处理所花费的时间。
Time Used In Waiting Output Per Second

表示task级别的每秒等待输出的时间。
TaskLatency Histogram Mean

表示作业级别的每个task的计算延时的曲线。
WaitOutput Histogram Mean

表示task级别的等待输出的曲线。
WaitInput Histogram Mean

表示Task级别的等待输入的曲线
PartitionLatency Mean

表示Partition里每个并发的延时曲线。
Process
Process MEM Rss

表示进程级别的每个进程内存的使用曲线。
CPU Usage

表示进程级别的每个进程CPU的使用曲线。
JVM
Memory Heap Used

表示整个Job使用的JVM heap存储量。
Memory NonHeap Used

表示整个Job使用的JVM 非heap存储量。
Threads Count

表示整个Job的线程数。
GC（CMS）

表示整个Job GC的次数。

FailOver
更新时间：2018-12-27 18:43:28


本页目录
Latest FailOver
Failover History
阿里云实时计算提供了当前作业的FailOver页面，您可以在FailOver页面了解当前运行作业的运行情况。

作业正常运行图
作业正常
作业异常图
作业异常
Latest FailOver
Latest FailOver表示的是当前的报错信息。

Failover History
Failover History表示的是作业的历史报错信息。

CheckPoints
更新时间：2018-12-27 18:43:45


本页目录
Completed Checkpoints
Task Latest Completed Checkpoint
阿里云实时计算提供可以恢复数据流并和应用保持一致状态的容错机制。容错机制的核心就是持续创建分布式数据流及其状态的快照。这些快照在系统遇到故障时，充当可以回退的一致性检查点（Checkpoint）。

456
Completed Checkpoints
Completed Checkpoints表示的是已经完成的CheckPoints的信息。

名称	详情描述
ID	CheckPoint的ID编号
StartTime	开始的时间
Durations(ms)	花费的时间
Task Latest Completed Checkpoint
Task Latest Completed Checkpoint表示的最新一次Checkpoint的详细信息。

名称	详情描述
SubTask ID	SubTask的ID编号
State Size	CheckPoint的大小
Durations(ms)	花费的时间

JobManager
更新时间：2018-12-27 18:44:03


本页目录
JobManager的用途
JobManager的参数信息
本文为您介绍JobManager的用途以及在实时计算集群启动流程中的作用。

JobManager是实时计算集群的启动过程不可或缺的一部分。实时计算集群的启动流程如下。

实时计算集群启动一个JobManger和一个或多个的TaskManager。
Client提交任务给JobManager。
JobManager调度任务给各个TaskManager。
TaskManager将心跳和统计信息汇报给JobManager。
JobManager的用途
JobManager主要负责调度Job并协调Task做Checkpoint，职责上很像Storm的Nimbus。从Client处接收到Job和JAR包等资源后，会生成优化后的执行计划，并以Task为单元调度到各个TaskManager去执行。
JobManager的参数信息
213
 上一篇：CheckPoints
下一篇：TaskExecutor

TaskExecutor
更新时间：2019-04-18 20:01:10

编辑 ·
 · 我的收藏
本页目录
背景
TaskExecutor界面
本文为您介绍TaskExecutor在实时计算集群启动过程中的作用以及TaskExecutor的界面。

背景
当实时计算集群启动后，首先会启动一个JobManger和一个或多个的TaskManager。由Client提交任务给JobManager，JobManager再调度任务到各个TaskManager去执行，然后TaskManager将心跳和统计信息汇报给JobManager。TaskManager之间以流的形式进行数据的传输。

TaskManager在启动的时候就设置好了槽位数（Slot），每个Slot能启动一个Task线程。从JobManager处接收需要部署的Task，部署启动后，与上游建立Netty连接，接收数据并处理。

TaskExecutor界面
TaskExecutor界面为您提供Task列表以及Task详情的接口。

123
 上一篇：JobManager


血缘关系
更新时间：2018-12-27 18:44:49


本页目录
数据抽样
实时计算作业的血缘关系集中反映了一个实时计算作业上下游数据的依赖关系。对于作业较为复杂的上下游业务依赖，血缘关系中的数据拓扑图能够清晰地反映出上下游依赖信息。

214
数据抽样
血缘关系为作业上下游提供了数据抽样功能，该功能和数据开发页面保持一致，方便您在数据运维页面进行随时数据探测，定位问题。

开启数据抽样方法

在作业上下游中点击表名。
数据抽样
点击页面下方的数据抽样也可打开数据抽样功能，如下图。
xieyuan


属性参数
更新时间：2019-04-18 20:01:39

编辑 ·
 · 我的收藏
本页目录
作业代码
资源配置
作业属性
运行参数
历史记录
作业参数
属性参数提供了当前作业的详情信息，包括当前运行信息以及历史运行记录。

属性参数页面如下图。
4356
作业代码
可以预览整个SQL作业。可点击编辑作业跳转到开发页面。

资源配置
资源配置提供了Job运行的的所有资源的配置，如CPU、MEM、并发数等。

作业属性
运行属性提供了所有Job的最基本的运行信息。

序号	详细描述
1	作业名称
2	作业ID
3	引用资源
4	运行引擎
5	最近操作人
6	操作动作
7	创建人员
8	创建时间
9	最近修改人
10	最近修改时间
运行参数
包含了底层checkpoint、启动时间、作业运行参数等。

历史记录
记录了作业操作的所有版本信息，包括操作人、启动时间、停止时间等。

作业参数
额外的作业参数，比如调试用的分割符。

监控报警
更新时间：2019-03-18 13:39:53

编辑 ·
 · 我的收藏
本页目录
监控报警背景
监控报警操作
创建报警规则
启动报警规则
本文为您介绍实时计算监控报警的操作以及流程报警规则的创建和启动。

监控报警背景
实时计算对接了云监控平台，帮助您实时监控Job的健康度。云监控服务可用于收集获取阿里云资源的监控指标或您自定义的监控指标，探测服务可用性，以及针对指标设置警报。让您全面了解阿里云上的资源使用情况、业务的运行状况和健康度，并及时收到异常报警做出反应，保证应用程序顺畅运行。

实时计算现支持以下5种类型报警：

业务延时
读入RPS
写出RPS
FailoverRate
数据滞留时间
监控报警操作
登录云监控
登录阿里云官网，进入阿里云云监控，进入管理控制台。
监控1
点击实时计算运维页面的监控也可以跳转到云监控页面。
12455
查看实时计算监控报警
选择需要监控的Job，点击查看。
监控2
在云服务监控页面点击监控图表查看监控图表。
说明 如果没有设置报警规则，可以通过以下方法进入报警规则创建页面。
选中需要设置报警的Job名称,点击批量设置报警。
监控3
点击报警规则窗口的这里或者创建报警规则。
监控4
创建报警规则
创建报警规则分为以下三个步骤：

关联资源选择实时计算产品、Project、Job，点击Job下拉框进行单个或者批量选择。
监控5
设置报警规则
报警规则分为以下类型。

规则	单位
业务延时	秒
读入RPS	条
写出RPS	条
FailoverRate	秒/次
说明
FailoverRate表示过去平均每秒Failover的次数。例如，最近1分钟Failover了1次，FailoverRate为1/60=0.01667=1.667%。
参数的配置界面FailoverRate的阈值需转化为百分比后进行填写。
数据滞留时间	秒
建议配置为以下参数，示例如下图。
监控6
通知方式
通知对象
您可在通知对象页面快速创建联系人组，还可以将其他人添加到已经存在的联系人通知组。

添加新的报警联系人步骤
通知方式页面快速创建联系人组。
建
在新建联系人组页面点击新建联系人。
建1
填写报警联系人信息。
建3
通知方式
手机+邮箱+旺旺+钉钉机器人
邮箱+旺旺+钉钉机器人
报警回调
您可以通过自己的实际业务来选择配置。
建4
启动报警规则
选中规则名称点击启动。
Q2
启动后的报警状态如下图。
Q2


===================================

高性能Flink SQL优化技巧
更新时间：2019-04-18 20:02:07

编辑 ·
 · 我的收藏
本页目录
Group Aggregate优化技巧
TopN优化技巧
高效去重方案
高效的内置函数
网络传输的优化
推荐的优化配置方案
本文为您介绍提升性能的Flink SQL推荐写法、推荐配置、推荐函数。

Group Aggregate优化技巧
开启MicroBatch/MiniBatch （提升吞吐）
MicroBatch和MiniBatch都是微批处理，只是微批的触发机制上略有不同。原理上都是缓存一定的数据后再触发处理，以减少对state的访问从而提升吞吐和减少数据的输出量。

MiniBatch主要依靠在每个task上注册的timer线程来触发微批，需要消耗一定的线程调度性能。MicroBatch是MiniBatch的升级版，主要基于事件消息来触发微批，事件消息会按您指定的时间间隔在源头插入。MicroBatch在攒批效率、反压表现、吞吐和延迟性能上都要优于胜于MiniBatch。

适用场景
微批处理是增加延迟来换取高吞吐的策略，如果您有超低延迟的要求的话，不建议开启微批处理。一般对于聚合的场景，微批处理可以显著的提升系统性能，建议开启。
说明 MicroBatch模式也能解决之前一直困扰您的两级Agg数据抖动问题。
开启方式
MicroBatch/MiniBatch默认关闭，开启方式：
试用
# 攒批的间隔时间，使用microbatch策略时需要加上该配置，且建议和blink.miniBatch.allowLatencyMs保持一致
blink.microBatch.allowLatencyMs=5000
# 使用microbatch时需要保留以下两个minibatch 配置
blink.miniBatch.allowLatencyMs=5000
# 防止OOM设置每个批次最多缓存数据的条数
blink.miniBatch.size=20000
开启LocalGlobal（解决常见数据热点问题）
LocalGlobal优化即将原先的Aggregate分成Local+Global 两阶段聚合，也就是在MapReduce模型中熟知的Combine+Reduce 处理模式。第一阶段在上游节点本地攒一批数据进行聚合（localAgg），并输出这次微批的增量值（Accumulator），第二阶段再将收到的Accumulator merge起来，得到最终的结果（globalAgg）。

LocalGlobal本质上能够靠localAgg的聚合筛除部分倾斜数据，从而降低globalAgg的热点，从而提升性能。LocalGlobal如何解决数据倾斜问题可以结合下图理解。

适用场景

LocalGlobal适用于提升如sum、count、max、min和avg等普通agg上的性能，以及解决这些场景下的数据热点问题。
说明 开启LocalGlobal需要UDAF实现merge方法。
开启方式

在 实时计算2.0版本开始，LocalGlobal是默认开启的，参数是： blink.localAgg.enabled=true，但是需要在microbatch/minibatch开启的前提下才能生效。
如何判断是否生效

观察最终生成的拓扑图的节点名字中是否包含GlobalGroupAggregate或LocalGroupAggregate
开启PartialFinal（解决count_distinct热点）
上述的LocalGlobal优化能针对常见普通agg有较好的效果（如sum、count、max、min和avg）。但是对于count distinct收效不明显，原因是count distinct在local聚合时，对于distinct key的去重率不高，导致在global节点仍然存在热点。

在旧版本用户为了解决count distinct的热点问题时，一般会手动改写成两层聚合（增加按distinct key 取模的打散层），自2.2.0版本开始，实时计算提供了count distinct自动打散，我们称之为PartialFinal优化，您无需自己改写成两层聚合。PartialFinal和LocalGlobal的原理对比请参见下图。

适用场景

使用count distinct且aggregate节点性能无法满足时。
说明
PartialFinal优化方法不能在包含UDAF的Flink SQL中使用。
数据量不大的情况下不建议使用PartialFinal优化方法。PartialFinal优化会自动打散成两层聚合，引入额外的网络shuffle，在数据量不大的情况下，可能反而会浪费资源。
开启方式

默认不开启，使用参数显式开启blink.partialAgg.enabled=true
如何判断是否生效

观察最终生成的拓扑图的节点名中是否包含Expand节点，或者原来一层的aggregate变成了两层的aggregate。
改写成 agg with filter 语法（提升大量count distinct场景性能）
说明 仅支持实时计算 2.2.2 及以上版本。
统计作业需要计算各种维度的UV，比如全网UV、来自手淘的UV、来自PC的UV等等。建议使用更标准的agg with filter语法来代替case when实现多维度统计的功能。实时计算目前的SQL优化器能分析出filter 参数，从而同一个字段上计算不同条件下的count distinct能共享state，减少对state的读写操作。性能测试中，使用agg with filter语法来代替case when能够能够使性能提高1倍。
适用场景

我建议用户将agg with case when的语法都替换成agg with filter的语法，尤其是对同一个字段上计算不同条件下的count distinct结果时有极大的性能提升。
原始写法
试用
COUNT(distinct visitor_id)as UV1,COUNT(distinctcasewhen is_wireless='y'then visitor_id elsenullend)as UV2
优化写法
试用
COUNT(distinct visitor_id)as UV1,COUNT(distinct visitor_id) filter (where is_wireless='y')as UV2
TopN优化技巧
TopN算法
当TopN的输入是非更新流（如source），TopN 只有一种算法AppendRank。当TopN的输入是更新流时（如经过了Agg/Join计算），TopN有3种算法，性能从高到低分别是：UpdateFastRank >> UnaryUpdateRank >> RetractRank。算法名字会显示在拓扑图的节点名字上。其中：
UpdateFastRank ：最优算法，需要具备2个条件：1.输入流有PK信息。2.排序字段的更新是单调的，且单调方向与排序方向相反。如order by count/count_distinct/sum（正数） desc。
说明 order by sum（正数）desc时，要加上正数的过滤条件。且已知sum的参数不可能有负数，那么需要加上过滤条件从而告诉优化器这个信息，才能优化出UpdateFastRank算法（仅支持实时计算 2.2.2及以上版本），如下所示。
试用
SELECT cate_id, seller_id, stat_date, pay_ord_amt  # 不输出 rownum 字段，能减小对结果表的输出量
FROM(SELECT*
      ROW_NUMBER ()OVER(PARTITIONBY cate_id, stat_date   # 注意要有时间字段，否则state过期会导致数据错乱
ORDERBY pay_ord_amt DESC## 根据上游 sum 结果排序)AS rownum
  FROM(SELECT cate_id, seller_id, stat_date,# 重点。声明sum的参数都是正数，所以sum的结果是单调递增的，所以TopN能用优化算法
sum(total_fee) filter (where total_fee >=0)as pay_ord_amt
    FROMWHERE total_fee >=0GROUPBY cate_name, seller_id, stat_date)WHERE rownum <=100))
UnaryUpdateRank：仅次于UpdateFastRank的算法。需要具备1个条件：输入流存在PK信息。如order by avg。
RetractRank：普通算法，性能最差，不建议在生产环境使用该算法。请检查输入流是否存在PK信息，如果存在可进行UnaryUpdateRank或UpdateFastRank优化。
TopN优化方法
无排名优化

TopN的输出不要带上rownum，最终前端显式时做1次排序，这样能极大地减少输入结果表的数据量。 无排名优化方法详情请参见TopN语句。
增加TopN的cache大小

TopN为了提升性能有一个state cache层，cache层能提升对state的访问效率。TopN的cache命中率的计算公式为：
试用

cache_hit = cache_size*parallelism/top_n/partition_key_num
例如，Top100配置缓存10000条，并发50，当您的patitionBy的key维度较大时，如10万级别时，cache命中率只有10000*50/100/100000=5%，命中率会很低，导致大量的请求都会击中state（磁盘），性能会大幅下降。因此当partitionKey维度特别大时，可以适当加大TopN的cache size，相对应的也建议适当加大TopN节点的heap memory（参见手动配置调优）。
试用
默认10000条，调整TopN cahce到20万，那么理论命中率能达 200000*50/100/100000 = 100%
blink.topn.cache.size=200000
partitionBy的字段中要有时间类字段

比如每天的排名，要带上day字段。否则TopN的结果到最后会由于state ttl有错乱。
高效去重方案
使用FirstRow语法替换 first_value 函数

说明 仅支持实时计算 2.2.2及以上版本。
FirstRow的作用是去重，且只保留该主键下第一条出现的数据，之后出现的数据会被丢弃掉。因为其state中只存储了key数据，所以替换first_value函数后一般能有一倍的性能提升。
说明 FirstRow和first_value的区别：FirstRow 是作用在一整行上的，是取该key下收到的第一行数据，无论行中的字段是否为null。first_value 是作用在字段上的，是取该key下该字段第一个非null的数据。
原始写法（使用first_value去重）：
试用
select biz_order_id, first_value(seller_id), first_value(buyer_id), first_value(total_fee)from tt_source
groupby biz_order_id;
优化写法（使用FirstRow语法）： 需要给源表增加PRIMARY KEY属性，并加上fetchFirstRow='true'的配置。
试用
CREATETABLE tt_source (
biz_order_id varchar,
seller_id varchar,
buyer_id varchar,
total_fee doublePRIMARYKEY(biz_order_id # 1. 声明主键，可以是联合主键，即根据什么主键去重
)WITH(
type='tt',fetchFirstRow='true' # 2. 声明成只保留首行，默认为false，即保留末行...)
使用LastRow语法替换last_value函数

LastRow的作用是也是去重，且只保留该主键下最后一条出现的数据。其性能略胜于使用 last_value 函数。
说明 LastRow 和last_value的区别：LastRow 是作用在一整行上的，是取该key下收到的最后一行数据，无论行中的字段是否为null。last_value 是作用在字段上的，是取该key下该字段最后一个非null的数据。
原始写法（使用last_value去重）：
试用
select biz_order_id,
 last_value(seller_id),
 last_value(buyer_id),
 last_value(total_fee)
from tt_source
group by biz_order_id;
优化写法（使用LastRow语法）： 需要给源表增加primary key属性，并加上 fetchFirstRow='false' 的配置。
试用
CREATE TABLE tt_source (
biz_order_id varchar,
seller_id varchar,
buyer_id varchar,
total_fee doublePRIMARYKEY(biz_order_id)# 1. 声明主键，可以是联合主键，即根据什么主键去重
)WITH(type='tt',
fetchFirstRow='false',# 2. 声明成保留末行，默认为 false，即保留末行...)
高效的内置函数
使用内置函数替换自定义函数

请尽量使用内置函数。在老版本时，由于内置函数不齐全，很多用户都用的三方包的自定义函数。在实时计算2.x 中，我们对内置函数做了很多的优化（主要是节省了序列化/反序列化、以及直接对 bytes 进行操作），但是自定义函数无法享受到这些优化。
KEY VALUE 函数使用单字符的分隔符

KEY VALUE 的签名是：KEYVALUE(content, keyValueSplit, keySplit, keyName)，当keyValueSplit和KeySplit是单字符时，如:、,会使用优化的算法，会在二进制数据上直接寻找所需的keyName 的值，而不会将整个content做切分。性能约有30%提升。
多KEYVALUE场景使用MULTI_KEYVALUE
说明 仅支持实时计算- 2.2.2及以上版本
如果在query中有对同一个content 做大量KEYVALUE 的操作，比如content中包含10个key-value对，希望把10个value 的值都取出来作为字段。用户经常会写10个KEY VALUE函数，那么就会对content 做10次解析。在这种场景建议使用 MULTI_KEYVALUE，这是一个表值函数。使用该函数可以只对content 做一次 split 解析。性能约有 50%~100%的性能提升。
LIKE 操作注意事项
如果想做startWith的操作，用LIKE 'xxx%'。
如果想做endWith的操作，用LIKE '%xxx'。
如果想做contains的操作，用LIKE '%xxx%'。
如果是做equals操作，用LIKE 'xxx'，其实和str = 'xxx'等价。
如果想匹配 _ 字符，请注意要做转义 LIKE '%seller/id%' ESCAPE '/'。因为 _ 在 SQL 中是个单字符的通配符，能匹配上任何字符，如果声明成 LIKE '%seller_id%'，那么 不单单会匹配 seller_id 还会匹配seller#id, sellerxid, seller1id 等等，可能会导致结果不是预期的，而且在运行时会使用正则来匹配，效率就会特别慢。
慎用正则函数（REGEXP）

正则表达式是非常耗时的操作，对比加减乘除通常有百倍的性能开销，而且正则表达式在某些极端情况下可能会进入无限循环，导致作业卡住。建议使用LIKE。正则函数包括：REGEXP, REGEXP_EXTRACT, REGEXP_REPLACE。
网络传输的优化
目前常见的Partitioner 策略包括：
KeyGroup/Hash：根据指定的key分配。
Rebalance：轮询分配给各个channel。
Dynamic-Rebalance：根据下游负载情况动态选择分配给负载较低的channel。
Forward：未chain一起时，同Rebalance。chain一起时是一对一分配。
Rescale：上游与下游一对多或多对一。
使用Dynamic-Rebalance替代Rebalance

Dynamic Rebalance，它可以根据当前各subpartition中堆积的buffer的数量，选择负载较轻的subpartition进行写入，从而实现动态的负载均衡。相比于静态的rebalance策略，在下游各任务计算能力不均衡时，可以使各任务相对负载更加均衡，从而提高整个作业的性能。例如，在使用rebalance时，发现下游各个并发负载不均衡时，可以考虑使用 Dynamic-Rebalance。参数：task.dynamic.rebalance.enabled=true， 默认关闭。
使用Rescale替代Rebalance

说明 仅支持实时计算 2.2.2及以上版本。
例如上游是5个并发，下游是10个并发。当使用Rebalance时，上游每个并发会轮询发给下游10个并发。当使用Rescale时，上游每个并发只需轮询发给下游2个并发。因为 channel个数变少了，subpartition的buffer填充速度能变快，能提高网络效率。当上游的数据比较均匀时，且上下游的并发数成比例时，可以使用Rescale替换Rebalance。参数：enable.rescale.shuffling=true，默认关闭。
推荐的优化配置方案
综上所述，作业建议使用如下的推荐配置：
试用
# excatly-once语义
blink.checkpoint.mode=EXACTLY_ONCE
# checkpoint间隔时间，单位毫秒
blink.checkpoint.interval.ms=180000
blink.checkpoint.timeout.ms=600000
# 2.x使用niagara作为statebackend，以及设定state数据生命周期，单位毫秒
state.backend.type=niagara
state.backend.niagara.ttl.ms=129600000
# 2.x开启5秒的microbatch（使用窗口函数不能设置该参数）
blink.microBatch.allowLatencyMs=5000
# 表示整个job允许的延迟
blink.miniBatch.allowLatencyMs=5000
# 单个batch的size
blink.miniBatch.size=20000
# local 优化，2.x默认已经开启，1.6.4需手动开启
blink.localAgg.enabled=true
# 2.x开启partial优化，解决count distinct热点
blink.partialAgg.enabled=true
# union all 优化
blink.forbid.unionall.as.breakpoint.in.subsection.optimization=true
# object reuse 优化，默认已开启
#blink.object.reuse=true
# GC 优化（SLS做源表不能设置该参数）
blink.job.option=-yD heartbeat.timeout=180000 -yD env.java.opts='-verbose:gc -XX:NewRatio=3 -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:ParallelGCThreads=4'
# 时区设置
blink.job.timeZone=Asia/Shanghai

============
AutoConf自动配置调优
更新时间：2019-04-03 10:35:58

编辑 ·
 · 我的收藏
本页目录
背景及功能范围
操作
常见问题
调优建议
如何判断自动配置调优功能生效或出现问题？
异常信息问题
为了增加用户的体验度，实时计算团队开发了自动配置调优（AutoConf）功能。

说明 AutoConf自动配置调优功能支持blink1.x和2.x版本。
背景及功能范围
在您作业的各个算子和流作业上下游性能达标和稳定的前提下，自动配置调优功能可以帮助您更合理的分配各算子的资源和并发度等配置。 全局优化您的作业，调节作业吞吐量不足、作业全链路的反压等性能调优的问题。

出现下列情况时，自动配置调优功能可以作出优化，但无法彻底解决流作业的性能瓶颈，需要您自行解决或联系实时计算产品支持团队解决性能瓶颈。

流作业上下游有性能问题。
流作业上游的数据Source存在性能问题。例如，DataHub分区不足、MQ吞吐不够等需要您扩大相应Source的分区。
流作业下游的数据Sink存在性能问题。例如，RDS死锁等。
流作业的自定义函数 （UDF、UDAF和UDTF） 有性能问题。
操作
新作业
上线作业
完成SQL开发，通过语法检查后，点击上线，即可出现如下上线新版本界面。
上线新版本
点击智能CU配置。第一次不需要指定CU数直接使用系统默认配置。
智能配置：指定使用CU AutoConf算法会基于系统默认配置，生成CU数，进行优化资源配置。如果是第一次运行，算法会根据经验值生成一份初始配置。建议作业运行了5-10分钟以上，确认Source RPS等Metrics稳定2-3分钟后，再使用智能配置，重复3到5次才能调优出最佳的配置。
使用上次资源配置：即使用最近一次保存的资源配置。如果上一次是智能配置的，就使用上一次智能配置的结果。如果上一次是手工配置的，就使用上次手工配置的结果。
使用默认配置启动作业
使用默认配置启动作业，出现如下的界面。
上线
启动作业。
启动作业
示例如下。第一次默认配置生成的资源配置为71个CU。
说明 请您确保作业已经运行10分钟以上，并且Source RPS等数据曲线稳定2-3分钟后，再使用智能CU配置。
CU
使用智能配置启动作业
资源调优
例如，您手动配置40CU，使用智能模式启动。40的CU数是您自行指定调整的，您可以根据具体的作业情况适当的增加或者是减小CU数，来达到资源调优的目的。

CU的最小配置
CU的最小配置建议不小于默认配置总数的50%，CU数不能小于1CU。假设智能配置默认CU数为71，则建议最小CU数为36CU。 71*50% = 35.5CU。

CU增加数量
假如无法满足作业理想的吞吐量就需要增加适量的CU数。每次增加的CU数，建议是上一次CU总数的30%以上。例如，上一次配置是10CU，下次就需要增加到13CU。

可多次调优
如果第一次调优不满足您的需求，可以调优多次。可以根据每次调优后Job的状态来增加或减少资源数。

多次调优
调优后的结果如下图。
调优后的结果
说明 如果是新任务，请不要选择 使用上次资源配置，否则会报错。
上次资源配置
已存在作业
调优流程示意图
调优流程示意图
说明
已存在的作业在进行调优前，您一定要检查是否是有状态的计算。因为在调优的过程中可能会清除之前作业保存的状态，请您谨慎操作。
当您的作业有改动时（例如，您对作业的SQL有修改，或更改了实时计算版本），自动配置调优功能不保证能按照之前的运行信息进行调优。原因是这些改动会导致拓扑信息变化，造成数据曲线无法对应和状态无法复用等问题。自动配置调优功能无法根据运行历史信息作出调优判断。此时再使用自动配置调优会报异常。这时您需要将改动后的任务当做新任务，重新进行操作。
调优流程
暂停任务。
312567
重复新作业的调优步骤，使用最新的配置启动作业。
按最新配置恢复
常见问题
以下几点可能会影响自动调优的准确性：

任务运行的时间较短，会造成采样得到的有用信息较少，会影响AutoConf算法的效果。建议延长运行时间，确认source rps等数据曲线稳定2-3分钟后即可。
任务运行有异常（failover），会影响结果的准确性。建议用户检查和修复failover的问题。
任务的数据量比较少，会影响结果的准确性。建议回追足够多的历史数据。
影响的因素有很多，自动调优AutoConf不能保证下一次生成的配置一定比上一次的好。如果还不能满足需求，用户参考手动配置调优，进行手动调优。
调优建议
每次触发智能配置前任务稳定运行超过10分钟。这样有利于AutoConf准确搜集的任务运行时的指标信息。
AutoConf可能需要3-5次迭代才能见效。
使用AutoConf时，您可以设置让任务回追数据甚至造成反压。这样会更有利于快速体现调优成功。
如何判断自动配置调优功能生效或出现问题？
自动配置调优功能通过JSON配置文件与实时计算交互。您在调优后，可以通过查看JSON配置文件了解自动配置调优功能的运行情况。

查看JSON配置文件的两种方式
通过作业编辑界面，如下图。
编辑界面
通过作业运维界面，如下图。
2
JSON配置解释
试用
"autoconfig" : {
    "goal": {  // AutoConf 目标
        "maxResourceUnits": 10000.0,  // 单个Blink作业最大可用CU数，不能修改，查看时可忽略
        "targetResoureUnits": 20.0  // 用户指定CU数。用户指定20CU，这里就是20.0
    }，
    "result" : {  // AutoConf 结果。这里很重要
      "scalingAction" : "ScaleToTargetResource",  // AutoConf 的运行行动 *
      "allocatedResourceUnits" : 18.5, // AutoConf 分配的总资源
      "allocatedCpuCores" : 18.5,      // AutoConf 分配的总CPU
      "allocatedMemoryInMB" : 40960    // AutoConf 分配的总内存
      "messages" : "xxxx"  // 很重要。 *
    }
}
scalingAction：InitialScale代表初次运行， ScaleToTargetResource代表非初次运行。
如果没有messages，代表运行正常。如果有messages，代表需要分析：messages有两种，如下所示：
warning 提示：表示正常运行情况但有潜在问题，需要用户注意，如source的分区不足等。
error或者exception提示，常伴有Previous job statistics and configuration will be used，代表AutoConf失败。失败也有两种原因：
用户作业或blink版本有修改，AutoConf无法复用以前的信息。
有exception代表AutoConf遇到问题，需要跟据信息、日志等综合分析。如没有足够的信息，请提交工单。
异常信息问题
IllegalStateException异常
出现如下的异常说明内部状态state无法复用，需要停止任务清除状态后重追数据。

如果无法切到备链路，担心对线上业务有影响，可以在开发界面右侧的作业属性里面选择上个版本进行回滚，等到业务低峰期的时候再重追数据。

试用
java.lang.IllegalStateException: Could not initialize keyed state backend.
	at org.apache.flink.streaming.api.operators.AbstractStreamOperator.initKeyedState(AbstractStreamOperator.java:687)
	at org.apache.flink.streaming.api.operators.AbstractStreamOperator.initializeState(AbstractStreamOperator.java:275)
	at org.apache.flink.streaming.runtime.tasks.StreamTask.initializeOperators(StreamTask.java:870)
	at org.apache.flink.streaming.runtime.tasks.StreamTask.initializeState(StreamTask.java:856)
	at org.apache.flink.streaming.runtime.tasks.StreamTask.invoke(StreamTask.java:292)
	at org.apache.flink.runtime.taskmanager.Task.run(Task.java:762)
	at java.lang.Thread.run(Thread.java:834)
Caused by: org.apache.flink.api.common.typeutils.SerializationException: Cannot serialize/deserialize the object.
	at com.alibaba.blink.contrib.streaming.state.AbstractRocksDBRawSecondaryState.deserializeStateEntry(AbstractRocksDBRawSecondaryState.java:167)
	at com.alibaba.blink.contrib.streaming.state.RocksDBIncrementalRestoreOperation.restoreRawStateData(RocksDBIncrementalRestoreOperation.java:425)
	at com.alibaba.blink.contrib.streaming.state.RocksDBIncrementalRestoreOperation.restore(RocksDBIncrementalRestoreOperation.java:119)
	at com.alibaba.blink.contrib.streaming.state.RocksDBKeyedStateBackend.restore(RocksDBKeyedStateBackend.java:216)
	at org.apache.flink.streaming.api.operators.AbstractStreamOperator.createKeyedStateBackend(AbstractStreamOperator.java:986)
	at org.apache.flink.streaming.api.operators.AbstractStreamOperator.initKeyedState(AbstractStreamOperator.java:675)
	... 6 more
Caused by: java.io.EOFException
	at java.io.DataInputStream.readUnsignedByte(DataInputStream.java:290)
	at org.apache.flink.types.StringValue.readString(StringValue.java:770)
	at org.apache.flink.api.common.typeutils.base.StringSerializer.deserialize(StringSerializer.java:69)
	at org.apache.flink.api.common.typeutils.base.StringSerializer.deserialize(StringSerializer.java:28)
	at org.apache.flink.api.java.typeutils.runtime.RowSerializer.deserialize(RowSerializer.java:169)
	at org.apache.flink.api.java.typeutils.runtime.RowSerializer.deserialize(RowSerializer.java:38)
	at com.alibaba.blink.contrib.streaming.state.AbstractRocksDBRawSecondaryState.deserializeStateEntry(AbstractRocksDBRawSecondaryState.java:162)
	... 11 more


	AutoScale自动配置调试
    更新时间：2019-04-03 10:36:18

    编辑 ·
     · 我的收藏
    本页目录
    资源配置方法
    查看自动配置调优数据曲线
    FAQ
    为了解决客户使用autoconf自动配置调优功能时需频繁的启停作业的问题，在blink3.x版本提供了AutoScale自动配置调优功能。作业启动后，系统会根据资源配置规则，自动进行作业的调优，直到满足设定的调优目标，全程无需人工介入。

    说明 AutoScale自动配置调优功能仅支持blink3.x及以上版本。
    资源配置方法
    在作业上线时 资源配置方式选择 作业自动调优即进入AutoScale自动配置调试设置， 如下图。
    最大CU数
    设置作业允许使用的最大CU数，最大CU数需小于项目可用CU数。

    调优策略
    系统会根据选择的策略和期望值对作业自动调优以达到期望值（目前策略只支持数据滞留时间）。

    期望值
    预期选定的策略下作业需要达到的策略值。

    初始资源
    系统分配
    初次上线作业使用系统默认配置，已上线作业使用最后一次调优后的配置，更多自定义资源需求可在手动配置资源中设置

    手动资源配置
    手动获取并修改作业启动的资源配置，需要您已经在作业属性中的手动资源配置页面配置完成

    例如：调优策略设置数据滞留时间的期望值：5（秒）。假如，此时作业的数据滞留时间大于5秒，系统会不断进行自动调优，直至数据滞留时间降至小于5秒。

    查看自动配置调优数据曲线
    完成资源配置，进行作业上线、启动后，即可通过以下曲线，查看自动配置调优的状态。
    AutoScale的成功和失败数
    记录整个Job进行AutoScale调优成功和失败的次数。 作业按系统计算出的所需资源启动定义为成功，未按照系统计算出的所需资源启动定义为失败。


    AutoScale使用的CPU
    记录Job进行AutoScale调优时，所申请的CPU总量。

    AutoScale使用的MEM
    记录Job进行AutoScale调优时，所申请的MEM总量。

    FAQ
    Q：作业运行中怎么开启或关闭AutoScale？开启或关闭需要重启作业吗？

    A：通过 运维界面左侧的 作业列表找到对应作业，作业中有动态开关（您可自行根据需求选择开启或关闭）。开启或关闭不需要重启作业 。

    Q：AutoScale失败对作业有什么影响，会一直失败吗？

    A：AutoScale失败作业会报出Failover，不会一直失败，只会是一段时间失败。AutoScale会根据上次调优失败的配置再次进行调优。

     上一篇：AutoConf自动配置调优

     手动配置调优
     更新时间：2019-01-27 16:25:49

     编辑 ·
      · 我的收藏
     本页目录
     手动配置调优
     作业参数调优
     资源调优
     上下游参数调优
     重新启用新的配置
     本文档涉及到的相关名词解释
     本文为您介绍实时计算作业手动配置调优。

     手动配置调优
     手动配置调优的内容主要有3种类型：

     作业参数调优：主要对作业中的miniBatch等参数进行调优；
     资源调优：主要对作业中的Operator的并发数（arallelism）、CPU（Core）、堆内存（heap_memory）等参数进行调优；
     上下游参数调优：主要对作业中的上下游存储参数进行调优。
     下面通过3个章节对以上3类调优进行介绍，参数调优后将生成新的配置，JPb需重新上线启动/恢复才能使用新的配置，本文最后章节将讲述如何重新启用新的配置。

     作业参数调优
     miniBatch设置：该设置只能优化group by。Flink SQL纯流模式下，每来一条数据都会去操作state，io消耗较大，设置miniBatch后，同一个key的一批数据只访问一次state，且只输出最新的一条数据，即减少了state访问也减少了向下游的数据更新。miniBatch设置如下：如果是新增加的作业参数建议用户停止重启，如果是改变作业参数大小暂停恢复即可。

     试用
     # excatly-once语义
     blink.checkpoint.mode=EXACTLY_ONCE
     # checkpoint间隔时间，单位毫秒
     blink.checkpoint.interval.ms=180000
     blink.checkpoint.timeout.ms=600000
     # 2.x使用niagara作为statebackend，以及设定state数据生命周期，单位毫秒
     state.backend.type=niagara
     state.backend.niagara.ttl.ms=129600000
     # 2.x开启5秒的microbatch（窗口函数不要设置这个参数。）
     blink.microBatch.allowLatencyMs=5000
     # 表示整个job允许的延迟
     blink.miniBatch.allowLatencyMs=5000
     # 单个batch的size
     blink.miniBatch.size=20000
     # local 优化，2.x默认已经开启，1.6.4需手动开启
     blink.localAgg.enabled=true
     # 2.x开启partial优化，解决count distinct热点
     blink.partialAgg.enabled=true
     # union all 优化
     blink.forbid.unionall.as.breakpoint.in.subsection.optimization=true
     # GC 优化（SLS做源表不能设置。）
     blink.job.option=-yD heartbeat.timeout=180000 -yD env.java.opts='-verbose:gc -XX:NewRatio=3 -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:ParallelGCThreads=4'
     # 时区设置
     blink.job.timeZone=Asia/Shanghai
     资源调优
     分析问题
     通过job的拓扑图查看到2号的TASK节点的输入队列已达到100%造成数据堆积反压到它的上游1号的TASK节点，输出队列造成数据堆积。

     单击2号的TASK节点，找到队列已达到100%的TaskExecutor。


     查看TaskExecutor的CPU和内存的使用量，根据使用量来调大相应的CPU和MEM。
     性能调优
     进入调优窗口
     打开可视化编辑

     找到2号task对应的Group（若有）或Operator，可以按Group批量修改或对单个Operator进行参数修改。
     按Group批量修改：

     单个Operator修改：


     找到对应的Operator进行修改：


     配置参数后点击右上角的应用当前配置并关闭窗口，即可保存当前配置。
     说明
     如果在调优的过程中发现虽然调大了某个Group的资源配置但是并没有太大的效果，首先需要确认该节点是否有数据倾斜现象，如果有数据倾斜，首要解决数据倾斜；其次如果没有数据倾斜需要把其中复杂运算的Operator节点（如：group by、window、join等）拆开，来判断到底是哪个子节点有异常。如果找到了该子节点只需调优该节点就好。将Operator子节点拆开的方法：点击需要修改的Operator，将其参数chainingStrategy修改为HEAD，若其已为HEAD，需要将其后面的第一个Operator修改为HEAD。 chainingStrategy三个参数的解释如下：

     ALWAYS：代表把单个的节点合并成一个大的GROUP里面。
     NEVER：保持不变
     HEAD ：表示把在合并成一个GROUP里面单个节点查分出来。
     资源参数的配置原则和建议
     可调参数
     parallelism
     source
     说明 source的并发不能大于source的shard数。
     资源根据上游Partition数来。
     例如SOURCE的个数是16，那么source的并发可以配置为16、8或4等，不要超过16。
     中间的处理节点
     根据预估的QPS计算。
     对于小任务来说，和source一样的并发度就够了。
     QPS高的任务，可以配大点，例如 64，128 或者 256。
     sink节点
     并发度和下游存储的Partition数相关，一般是下游Partition个数的2~3倍。
     如果配置太大会导致写超时或失败。例如下游SINK的个数是16，那么建议sink的并发最大可以配置48。
     CORE
     CPU，默认 0.1，根据实际CPU使用配置（但最好能被1整除），一般建议0.25

     heap_memory
     堆内存，默认 256MB，根据实际内存使用配置 点击GROUP就可以编辑以上参数。

     存在GROUP BY的TASK节点可配置参数
     state_size：state大小，默认0。如果operator有用state，需要把state_size配成1，表示该operator会用state，job在申请资源的时候会额外为该operator申请内存，供state访问使用；如果不配成1，job可能被yarn kill。（state_size需要配成1的operator有：group by、 join、over和window）虽然有这么多配置项，对普通用户来说，只需要关心：core，parallelism和heap_memory。整个job 建议core:mem=1:4，即一个核对应4G内存。

     说明
     调parallelism和memory，有什么规则吗？

     一个operator的总CU=并发*core 一个operator的总mem=并发*heap_mem 一个group中的core取最大值，mem取各个operator的sum，CPU和MEM的关系是1：4的关系；比如您的core给的是1CU，mem给的是3G，那么最终分配的是1CU+4G。您的core给的是1CU，mem给的是5G，那么最终分配的是1.25CU+5G。

     上下游参数调优
     由于实时计算的特性，每条数据均会触发上下游存储的读写，会对上下游存储形成性能压力，可以通过设置batchsize，批量的读写上下游存储数据来降低对上下游存储的压力，支持batchsize参数的上下游存储如下：

     名称	参数	详情	设置参数值
     DATAHUB源表	batchReadSize	单次读取条数	可选，默认为10
     DATAHUB结果表	batchSize	单次写入条数	可选，默认为300。
     日志服务（Log Service）源表	batchGetSize	单次读取logGroup条数	可选，默认为10。
     分析型数据库（AnalyticDB）结果表	batchSize	每次写的批次大小	可选，默认为1000。
     云数据库（RDS）结果表	batchSize	每次写的批次大小	可选，默认为50。
     云数据库HybridDB for MySQL（petaData）结果表	batchSize	每次写的批次大小	可选，默认值1000 ，表示每次写多少条，经验建议最大设置4096。
     bufferSize	去重的buffer大小，需要指定主键才生效。	可选。设置batchSize必须设置bufferSize，经验建议最大设置4096。
     示例：

     重新启用新的配置
     通过1-3章节完成配置后，需要重新启动/恢复作业才能使新配置生效。

     上线作业，配置方式必须选择使用上次资源配置 。

     暂停原作业。

     恢复原作业。

     选择按最新配置恢复，否则新配置无法生效。

     重新恢复后，可通过运维 > 运行信息 > Vertex拓扑查看新的配置是否生效。
     说明
     一般情况下我们不建议采用先停止job再启动的方式使新配置生效，因为job停止后status状态会消除，可能会导致计算结果不一致。

     本文档涉及到的相关名词解释
     global
     isChainingEnabled ：表示是否启用chain策略，默认为 true，不需要修改。
     nodes
     id：节点id号，自动生成，唯一，不需要修改。
     uid： 节点uid号，用于计算operator id，如果不设置，会使用id。
     pact：节点类型，例如Data Source，Operator，Data Sink等等，不需要修改。
     name：节点名字，用户可以自定义。
     slotSharingGroup：default，不需要修改。
     chainingStrategy：chain的策略，有 HEAD、ALWAYS和NEVER，根据需要修改。
     parallelism：并发度，默认为1，可以根据实际数据量改大点。
     core：CPU，默认0.1，根据实际CPU使用配置（但最好能被1整除），一般建议0.25。
     heap_memory：堆内存，默认256MB，根据实际内存使用配置。
     direct_memory：jvm堆外内存，默认0，建议不要修改。
     native_memory：jvm堆外内存，jni使用，默认0，建议用10MB。
     chain
     Flink SQL任务是一个DAG图，会有很多个节点（Operator），有些上下游的节点在运行时是可以合成一个点的，这称之为chain。对于chain之后的点，CPU取最大的最大值，内存取总和。例如Node1如果operator有用state，Node2{128MB，0.5core}，Node3{128MB，0.25core}，那么这三个点chain后的CPU是 0.5core，内存是 512MB。chain的规则简单来说就是：并发度需要一样。但是，有些节点之间是不能合在一起的，比如groupBy。一般来说，尽可能的让节点都chain在一起，减少网络传输。

=============================================================================================================================

场景一：语法检查报错
更新时间：2018-08-15 18:42:53


场景描述：
用户在编写完SQL时首先要进行语法检查，保证SQL的正确性，当语法检查出现报错提示需要及时更改SQL才能上线运行。

1.无完整的job逻辑
解决方案：
无完整的job逻辑无法通过语法检查，请先确保已编写一个完整的job逻辑，包括定义source和sink，有完整的DML和Query语句。

2.insert时的字段与sink表中字段的数量、类型、顺序不一致导致语法检查报错
解决方案：
参考insert与sink字段不一致的解决方案

3.RDS不能做源表导致语法检查报错
解决方案：
参考RDS不能做源表报错的解决方案

4.使用了中文字符
解决方案：
注意将中文的“，”改为英文的“,”。

场景二：调试报错
更新时间：2018-07-18 11:41:07


场景描述
用户在编写完SQL后，语法检查通过的前提下，会使用本地调试模式，来检测SQL能否达到业务需求。调试时会产生一些报错导致没有调试结果输出，具体报错场景请参考下文。

1.参数类型不匹配导致调试报错
解决方案：

请参考参数类型不匹配报错的解决方案文档

2.类型转换异常导致调试报错
解决方案：

请参考类型转换异常报错的解决方案文档



场景三：作业无法上线
更新时间：2018-07-18 11:41:07


场景描述
用户在语法检查通过后，提交上线作业时报错该如何排查？

排查流程
1.查看是否有错误信息？

解决方案：

如果有failover错误信息可以参阅SQL常见问题！

2.作业一直在提交中，但是等了好久也无法提交上线，最后的报错信息如下：

code:[30017],  brief  info:[get  app  plan  failed],  context  info:[detail:[java.lang.StackOverflowError
at  java.util.HashMap.hash(HashMap.java:338)
at  java.util.HashMap.get(HashMap.java:556)
at  GeneratedMetadataHandler_RowCount.getRowCount(Unknown  Source)
at  org.apache.calcite.rel.metadata.RelMetadataQuery.getRowCount(RelMetadataQuery.java:236)
at  org.apache.calcite.rel.metadata.RelMdUtil.estimateFilteredRows(RelMdUtil.java:718)
at  org.apache.calcite.rel.metadata.RelMdRowCount.getRowCount(RelMdRowCount.java:123)
at  GeneratedMetadataHandler_RowCount.getRowCount_$(Unknown  Source)
at  GeneratedMetadataHandler_RowCount.getRowCount(Unknown  Source)
at  org.apache.calcite.rel.metadata.RelMetadataQuery.getRowCount(RelMetadataQuery.java:236)
at  org.apache.calcite.rel.metadata.RelMdRowCount.getRowCount(RelMdRowCount.java:71)
at  GeneratedMetadataHandler_RowCount.getRowCount_$(Unknown  Source)
at  GeneratedMetadataHandler_RowCount.getRowCount(Unknown  Source)
at  org.apache.calcite.rel.metadata.RelMetadataQuery.getRowCount(RelMetadataQuery.java:236)
at  org.apache.calcite.rel.metadata.RelMdRowCount.getRowCount(RelMdRowCount.java:132)
at  GeneratedMetadataHandler_RowCount.getRowCount_$(Unknown  Source)
at  GeneratedMetadataHandler_RowCount.getRowCount(Unknown  Source)
at  org.apache.calcite.rel.metadata.RelMetadataQuery.getRowCount(RelMetadataQuery.java:236)
at  org.apache.calcite.rel.metadata.RelMdRowCount.getRowCount(RelMdRowCount.java:71)
解决方案：

在作业参数中增加以下参数。

client.jvm.option=-Xss20m
blink.job.submit.timeoutInSeconds=300
blink.job.option=-yD env.java.opts='-Xss20m'


==================================

场景四：作业无法启动
KB: 85654 ·
更新时间：2018-08-14 10:12:21


本页目录
场景描述
场景描述
用户在完成作业开发上线以后，在运维页面无法启动作业。

排查流程
1.作业有Failover的情况
排查指引：
查看Failover报错信息，分析job运行异常原因。一般Failover有以下报错：

Slot allocation request timed out
解决方案：
这个问题一般是由于资源不足引起的，如果遇到，先检查资源够不够，不够的话先扩容。

2.资源不足
排查指引：
在运行信息里有如下的报错提示：

Submit blink job failed, name: test_copy, errcode:30011, errmsg:code:[30011], brief info:[error occur while run app], context info:[details:[资源不足，请手动停止任务提交，并联系管理员扩容.(yarn resource not available, so here try to kill it to avoid long time waiting)java.lang.Exception: shell cmd execute failed
解决方案：
查看总览里面的资源够不够，一般都是已使用CU接近已购买CU的时候，作业CU又比较大，导致启动不起来。需要增加资源，公有云版本需要购买新的资源，集团内部需要找Blink Pre的值班人员增加资源。

3.获取资源配置失败
排查指引：
在运行信息里有如下的报错提示：

errcode:30011, errmsg:code:[30011], brief info:[error occur while run app], context info:[details:[任务提交失败，请检查详细日志输出.（submit app failed)java.lang.UnsupportedOperationException: Cannot set chaining strategy on Union Transformation.
报错截图如下：

peizhi

解决方案：
重新获取资源配置。BlinkSQL任务开发完成后，需要点『资源配置』，通过『获取自动生成JSON配置』来生成一份默认的配置文件。

4.无作业指标
排查指引：
在作业运维曲线上没有任何指标，作业一直处于created状态，也没有failover报错。这种情况主要是由于jm没有起来。

解决方案：
先检查是否是资源不足的问题，如果资源足够，手动指定增加CU重启。




场景五：作业无数据输出
更新时间：2018-07-18 11:41:07


本页目录
场景描述
场景描述
用户在上线运行JOB时，出现下游结果表中没有数据输出的情况。

排查流程图：
image | left

1.作业有Failover情况
排查指引：
查看Failover报错信息，分析job运行异常原因。

解决方案：
解决Failover问题，使作业正常运行。

2.源表没有数据进入流计算的情况
排查指引：
这种情况下没有Failover，数据延时会很大，请查看数据曲线，检查各source输入是否有数据。

解决方案：
检查源表，保证上游有数据进入流计算。

3.数据被某个节点过滤的情况
排查指引：

在作业状态页面查看每个节点的 RecvCnt（输入） 和 SendCnt（输出），如果输入有数据，输出为0，就说明数据被这个节点过滤了。
点击对应节点的Name进去后，再点击对应的到 Metrics的页面，可以查看更细的Metrics。

查看 xxx.IO.numRecordsIn_sum 和 xxx.IO.numRecordsOut_sum 这个指标
如果输入有数据，输出为0，就说明数据是被 xxx 这个operator过滤了。
看数据曲线，是否有数据进入流计算

a：没有，是不是启动位点设置的不对

b：有，检查是否用了数据存储的方式引入

解决方案：

检查数据过滤节点，看看在哪个逻辑上导致没有输出。

常见的数据被过滤情况如下：

join后没有输出
wiondow把数据过滤掉了（检查watermark的字段是否有效）
where条件将数据过滤掉了
4.排除JOB的业务逻辑异常后，可能是下游的默认缓存机制缓存了数据导致
解决方案：

调整下游存储的batchsize的大小设置为1.（添加该参数可能会造成下游数据库IO压力过大、存在性能瓶颈的风险）

with(
type ='DATAHUB',
endpoint = 'XXXX',
batchsize = '1'
)
5.下游使用RDS，可能出现RDS死锁导致没有数据输出的情况
解决方案：

请参考死锁问题的文档。



写MySQL(TDDL/RDS)出现死锁（DeadLock）
更新时间：2018-10-22 17:57:15


本页目录
报错信息：Caused by: com.mysql.jdbc.exceptions.jdbc4.MySQLTransactionRollbackException: Deadlock found when trying to get lock; try restarting transaction
死锁形成的示例
RDS/TDDL、OTS数据库引擎锁的区别
死锁的解决方案
报错信息：Caused by: com.mysql.jdbc.exceptions.jdbc4.MySQLTransactionRollbackException: Deadlock found when trying to get lock; try restarting transaction
在实时计算 Flink中，下游数据库使用Mysql等关系数据库（对应的connector为TDDL和RDS），当实时计算频繁写某个表或者资源时，存在死锁风险。

死锁形成的示例
假设完成一次insert需要依次抢占(A, B) 2个锁。A是一个范围锁，有2个事务（T1，T2），表的schema为(id(自增主键), nid(唯一键))。T1包含2条insert（null, 2）,(null, 1), T2包含1条insert(null, 2)。

t时刻, T1第一条insert插入，此时T1持有(A, B)2个锁。
t+1时刻T2开始插入，需要等待锁A来锁住(-inf, 2], 此时A被T1拥有，且锁住了（-inf, 2]，区间存在包含关系，所以T2依赖T1释放A。
t+2时刻T1第二条insert执行，需要A锁住(-inf, 1], 该区间属于(-inf, 2]，所以需要排队等T2释放锁，所以T1依赖T2释放A。
当T1和T2相互依赖且相互等待时死锁形成。

RDS/TDDL、OTS数据库引擎锁的区别
RDS、TDDL：——InnoDB的行锁是针对索引加的锁，不是针对单条记录加的锁，所以虽然是访问不同行的记录，但是如果是使用相同的索引键，是会出现锁冲突的，造成了一整个区域的数据都无法更新。
OTS：——单行锁，不影响其他数据更新。
死锁的解决方案
高QPS/TPS或高并发写入情况场景，建议使用OTS作为结果表，可以解决死锁的问题。一般不建议使用TDDL或者RDS作为Flink Job的结果表。

如果必须要使用Mysql等关系数据库作为sink节点，有以下建议：

确保没有其他读写业务方的干扰
如果Job的数据量不大可以尝试单并发写入。但是在高QPS/TPS、高并发情况下，写入性能会降低。
尽可能不使用UniqueKey, 带UniqueKey(唯一主键)表的写入可能会导致死锁。如果业务要求表必须包含UniqueKey，请按照字段区分能力从大到小排列来定义UniqueKey，可大幅降低死锁出现概率。如一个md5值的区分能力大于day_time(20171010)。
根据业务特点做分库分表，尽可能避免单表写入，实施细节请联系对应的DBA。


场景六：作业延迟过大
更新时间：2018-07-23 17:20:10


本页目录
场景描述
场景描述
线上作业业务延迟不正常，表现为曲线图中平均延迟呈水平趋势但延迟过大、或逐步成上升趋势、或在追数据的过程中下降非常缓慢。

1. 脏数据导致延迟
排查指引：
1.查看脏数据曲线图，有脏数据会显示相应时间节点上显示数据量，没有则显示为0.

2.查看failover，脏数据会在错误中标明。

解决方案：脏数据未进行过滤，导致报错，作业重启造成业务延迟。需要改SQL，处理/过滤脏数据，重新上线。
2.源表没有数据进入流计算的
排查指引：

这种情况下没有Failover，数据延时会很大，请查看数据曲线，检查各source输入是否有数据。

解决方案：

检查源表，保证上游有数据进入流计算。

3.RDS写入瓶颈
排查指引： RDS写入过慢，调大并发、增加资源，输出为0或RPS极小。
解决方案： 新建结果表，重新引入后上线。
4.数据有输入
排查指引： 查看数据源数据是否存在以下情况：

历史数据
周期性数据输出为0
数据不稳定，波动大
解决方案

数据源的流入数据问题，历史数据处理完成后（如追数据完成），延迟会下降。
周期性数据输入为0，查看是否是数据生产机制产生。
数据输入波动大，检查source源。
5.作业部分节点出现反压情况
解决方案：

先自动调优
找到反压的节点，通过手动调优，增加节点的资源、并发。
作业中有group by：设置作业参数blink.miniBatch.allowLatencyMs=5000 #表示整个job允许的延迟 blink.miniBatch.size=1000 #单个batch的size
针对JOIN、GROUP BY等节点 ，单独调大资源。


场景七：作业启动一段时间后报错停止，有failover
更新时间：2018-07-23 17:20:10


本页目录
场景描述
场景描述
作业正常运行一段时间后，作业停止运行，报错。failover里出现报错信息。

1.sts token过期
1STS token过期导致的,不会影响线上作业

2.脏数据处理失败报错
排查指引

在failover中查看脏数据具体内容。

解决方案

修改SQL，过滤脏数据，重新上线。

3.写入MYSQL类型数据库死锁
排查指引

手动调优后，sink节点拆除的部分节点，与同时写入的其他节点中间出现rebalance。
sink节点多并发写入数据库。
出现死锁的表中pk与数据库表定义的UK是否一致，包括顺序。
定义的pk是否按照区分度高低进行排列。
解决方案
参考死锁解决方案：写MySQL(TDDL/RDS)出现死锁（DeadLock）


场景八：作业无运行信息和曲线指标
更新时间：2018-07-18 11:42:52


场景描述
用户在上线作业后，作业的运维页面看不到拓补图、看不到一些瞬时值的指标、曲线指标看不到该怎么排查？

排查流程
1.查看是否有faliover错误信息。

解决方案：

如果有failover错误信息可以参阅SQL常见问题！

2.查看运维页面的作业信息中如果没有有拓扑图和瞬时值的数据该怎么解决？

解决方案：

直接提工单询问值班同学，工单格式如下：

项目名
作业名称
什么时间提交的作业
公司名称
报错信息截图
3.如果运维页面的曲线指标，全部指标或者是部分指标都没有信息该怎么排查？

解决方案：

首先确认是否使用了自定义的source，如果是自定义的source，source的输入曲线为空是正常的，因为是自定义的source流计算无法监控到。

如果没有使用自定义的插件也发生了曲线指标不存在的现象该怎么排查？

直接提工单询问值班同学，工单格式如下：

项目名
作业名称
什么时间提交的作业
公司名称
报错信息截图


===================================

Apache Flink状态管理和容错机制介绍
施晓罡  Hadoop技术博文  今天
本文分享嘉宾施晓罡，目前在阿里大数据团队部从事Blink方面的研发，现在主要负责Blink状态管理和容错相关技术的研发。


有状态的流数据处理

Flink中的状态接口

状态管理和容错机制实现

阿里相关工作介绍

一、有状态的流数据处理
1.1、什么是有状态的计算
计算任务的结果不仅仅依赖于输入，还依赖于它的当前状态，其实大多数的计算都是有状态的计算。



比如wordcount,给一些word,其计算它的count,这是一个很常见的业务场景。count做为输出，在计算的过程中要不断的把输入累加到count上去，那么count就是一个state。

1.2、传统的流计算系统缺少对于程序状态的有效支持
状态数据的存储和访问

状态数据的备份和恢复

状态数据的划分和动态扩容



       在传统的批处理中，数据是划分为块分片去完成的，然后每一个Task去处理一个分片。当分片执行完成后，把输出聚合起来就是最终的结果。在这个过程当中，对于state的需求还是比较小的。



        对于流计算而言，对State有非常高的要求，因为在流系统中输入是一个无限制的流，会运行很长一段时间，甚至运行几天或者几个月都不会停机。在这个过程当中，就需要将状态数据很好的管理起来。很不幸的是，在传统的流计算系统中，对状态管理支持并不是很完善。比如storm,没有任何程序状态的支持，一种可选的方案是storm+hbase这样的方式去实现，把这状态数据存放在Hbase中，计算的时候再次从Hbase读取状态数据，做更新在写入进去。这样就会有如下几个问题：



流计算系统的任务和Hbase的数据存储有可能不在同一台机器上，导致性能会很差。这样经常会做远端的访问，走网络和存储

备份和恢复是比较困难，因为Hbase是没有回滚的，要做到Exactly onces 很困难。在分布式环境下，如果程序出现故障，只能重启Storm，那么Hbase的数据也就无法回滚到之前的状态。比如广告计费的这种场景，Storm+Hbase是是行不通的，出现的问题是钱可能就会多算，解决以上的办法是Storm+mysql，通过mysql的回滚解决一致性的问题。但是架构会变得非常复杂。性能也会很差，要commit确保数据的一致

对于storm而言状态数据的划分和动态扩容也是非常难做，一个很严重的问题是所有用户都会在strom上重复的做这些工作，比如搜索，广告都要在做一遍，由此限制了部门的业务发展

1.3、Flink丰富的状态访问和高效的容错机制


Flink在最早设计的时候就意识到了这个问题，并提供了丰富的状态访问和容错机制。如下图所示：







Flink并且提供了丰富的状态访问和高效的容错机制







二、Flink中的状态管理
2.1、按照数据的划分和扩张方式，Flink中大致分为2类：
Keyed States

Operator States



2.1.1、 Keyed States
 Keyed States的使用







 Flink也提供了Keyed States多种数据结构类型







 Keyed States的动态扩容





2.1.2、Operator State
Operator States的使用







Operator States的数据结构不像Keyed States丰富，现在只支持List



Operator States多种扩展方式







Operator States的动态扩展是非常灵活的，现提供了3种扩展，下面分别介绍：



ListState:并发度在改变的时候，会将并发上的每个List都取出，然后把这些List合并到一个新的List,然后根据元素的个数在均匀分配给新的Task

UnionListState:相比于ListState更加灵活，把划分的方式交给用户去做，当改变并发的时候，会将原来的List拼接起来。然后不做划分，直接交给用户

BroadcastState:如大表和小表做Join时，小表可以直接广播给大表的分区，在每个并发上的数据都是完全一致的。做的更新也相同，当改变并发的时候，把这些数据COPY到新的Task即可

  以上是Flink Operator States提供的3种扩展方式，用户可以根据自己的需求做选择。



 使用Checkpoint提高程序的可靠性



 用户可以根据的程序里面的配置将checkpoint打开，给定一个时间间隔后，框架会按照时间间隔给程序的状态进行备份。当发生故障时，Flink会将所有Task的状态一起恢复到Checkpoint的状态。从哪个位置开始重新执行。



Flink也提供了多种正确性的保障，包括：



AT LEAST ONCE

Exactly once







备份为保存在State中的程序状态数据



  Flink也提供了一套机制，允许把这些状态放到内存当中。做Checkpoint的时候，由Flink去完成恢复。







从已停止作业的运行状态中恢复



   当组件升级的时候，需要停止当前作业。这个时候需要从之前停止的作业当中恢复，Flink提供了2种机制恢复作业:



Savepoint:是一种特殊的checkpoint，只不过不像checkpoint定期的从系统中去触发的，它是用户通过命令触发，存储格式和checkpoint

External Checkpoint：对已有checkpoint的一种扩展，就是说做完一次内部的一次Checkpoint后，还会在用户给定的一个目录中，多存储一份checkpoint的数据



三、状态管理和容错机制实现
下面介绍一下状态管理和容错机制实现方式，Flink提供了3种不同的StateBackend



MemoryStateBackend

FsStateBackend

RockDBStateBackend






用户可以根据自己的需求选择，如果数据量较小，可以存放到MemoryStateBackend和FsStateBackend中，如果数据量较大，可以放到RockDB中。



下面介绍HeapKeyedStateBackend和RockDBKeyedStateBackend



HeapKeyedStateBackend







RockDBKeyedStateBackend







Checkpoint的执行流程



Checkpoint的执行流程是按照Chandy-Lamport算法实现的。







Checkpoint Barrier的对齐





全量Checkpoint



全量Checkpoint会在每个节点做备份数据时，只需要将数据都便利一遍，然后写到外部存储中，这种情况会影响备份性能。在此基础上做了优化。







RockDB的增量Checkpoint



RockDB的数据会更新到内存，当内存满时，会写入到磁盘中。增量的机制会将新产生的文件COPY持久化中，而之前产生的文件就不需要COPY到持久化中去了。通过这种方式减少COPY的数据量，并提高性能。





四、阿里相关工作介绍
  Flink在阿里的成长路线



     阿里是从2015年开始调研Flink,2015年10月启动Blink项目，并完善Flink在大规模生产下的一些优化和改进。2016年双11采用了Blink系统，为搜索，推荐，广告业务提供服务。2017年5月Blink已成为阿里的实时计算引擎。







阿里在状态管理和容错相关的工作







正在做的工作，基于State重构Window方面的一些优化，阿里也正在将功能做完善。后续将包括asynchronous Checkpoint的功能完善，并和社区进一步沟通和合作。帮助Flink社区完善相关方面的工作。



重要|Flink SQL与kafka整合的那些事儿
原创： 浪院长  Spark学习技巧  今天
flink与kafka整合是很常见的一种实时处理场景，尤其是kafka 0.11版本以后生产者支持了事务，使得flink与kafka整合能实现完整的端到端的仅一次处理，虽然这样会有checkpoint周期的数据延迟，但是这个仅一次处理也是很诱人的。可见的端到端的使用案例估计就是前段时间oppo的案例分享吧。关注浪尖微信公众号(bigdatatip)输入 oppo 即可获得。

1.flink sql与kafka整合方式介绍

flink SQL与kafka整合有多种方式，浪尖就在这里总结一下：

1.datastream转table

通过addsource和addsink API，整合，生成Datastream后注册为表，然后sql分析。

主要接口有两种形式

1.直接注册为表
// register the DataStream as Table "myTable" with fields "f0", "f1"
tableEnv.registerDataStream("myTable", stream);

// register the DataStream as table "myTable2" with fields "myLong", "myString"
tableEnv.registerDataStream("myTable2", stream, "myLong, myString");

2.转换为table
DataStream<Tuple2<Long, String>> stream = ...

// Convert the DataStream into a Table with default fields "f0", "f1"
Table table1 = tableEnv.fromDataStream(stream);

// Convert the DataStream into a Table with fields "myLong", "myString"
Table table2 = tableEnv.fromDataStream(stream, "myLong, myString");

2.tablesource和tablesink

通过tablesource和tablesink接口，也可以直接注册为输入和输出表。

Kafka010JsonTableSource和Kafka010JsonTableSink

3.自定义catalog

通过自定义catalog的形式，这种类型暂时不讲后面会有视频教程放到知识星球里。

ExternalCatalog catalog = new InMemoryExternalCatalog();

// register the ExternalCatalog catalog
tableEnv.registerExternalCatalog("InMemCatalog", catalog);

4.connector方式

这种方式是本文要讲明白的一种方式，其余的会陆续分享到知识星球内部。

这种方式目前仅仅支持kafka，es，和file。

2.案例讲解

直接上案例吧，然后再去讲一下细节问题。

import org.apache.flink.api.common.typeinfo.Types;import org.apache.flink.streaming.api.TimeCharacteristic;import org.apache.flink.streaming.api.environment.StreamExecutionEnvironment;import org.apache.flink.table.api.TableEnvironment;import org.apache.flink.table.api.java.StreamTableEnvironment;import org.apache.flink.table.descriptors.Json;import org.apache.flink.table.descriptors.Kafka;import org.apache.flink.table.descriptors.Rowtime;import org.apache.flink.table.descriptors.Schema;public class kafka2kafka {    public static void main(String[] args) throws Exception {        StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();        env.setStreamTimeCharacteristic(TimeCharacteristic.EventTime);        env.setParallelism(1);        StreamTableEnvironment tEnv = TableEnvironment.getTableEnvironment(env);        tEnv.connect(                new Kafka()                        .version("0.10")                        //   "0.8", "0.9", "0.10", "0.11", and "universal"                        .topic("jsontest")                        .property("bootstrap.servers", "mt-mdh.local:9093")                        .property("group.id","test")                        .startFromLatest()        )                .withFormat(                        new Json()                                .failOnMissingField(false)                                .deriveSchema()                )                .withSchema(                        new Schema()                                .field("rowtime",Types.SQL_TIMESTAMP)                                .rowtime(new Rowtime()                                        .timestampsFromField("eventtime")                                        .watermarksPeriodicBounded(2000)                                )                                .field("fruit", Types.STRING)                                .field("number", Types.INT)                )                .inAppendMode()                .registerTableSource("source");        tEnv.connect(                new Kafka()                        .version("0.10")                        //   "0.8", "0.9", "0.10", "0.11", and "universal"                        .topic("test")                        .property("acks", "all")                        .property("retries", "0")                        .property("batch.size", "16384")                        .property("linger.ms", "10")                        .property("bootstrap.servers", "mt-mdh.local:9093")                        .sinkPartitionerFixed()        ).inAppendMode()                .withFormat(                        new Json().deriveSchema()                )                .withSchema(                        new Schema()                                .field("fruit", Types.STRING)                                .field("total", Types.INT)                                .field("time", Types.SQL_TIMESTAMP)                )                .registerTableSink("sink");        tEnv.sqlUpdate("insert into sink select fruit,sum(number),TUMBLE_END(rowtime, INTERVAL '5' SECOND) from source group by fruit,TUMBLE(rowtime, INTERVAL '5' SECOND)");        env.execute();    }}
这个例子是按照事件时间开窗，统计对fruit求和。从这个例子里可以看到要使用connector还是比较麻烦的，配置项目比较多，下面我们就拆分介绍一下。细节内容可以阅读官网(https://ci.apache.org/projects/flink/flink-docs-release-1.7/dev/table/connect.html#type-strings)

1.配置数据源

.connect(
  new Kafka()
    .version("0.11")    // required: valid connector versions are
                        //   "0.8", "0.9", "0.10", "0.11", and "universal"
    .topic("...")       // required: topic name from which the table is read

    // optional: connector specific properties
    .property("zookeeper.connect", "localhost:2181")
    .property("bootstrap.servers", "localhost:9092")
    .property("group.id", "testGroup")

    // optional: select a startup mode for Kafka offsets
    .startFromEarliest()
    .startFromLatest()
    .startFromSpecificOffsets(...)

    // optional: output partitioning from Flink's partitions into Kafka's partitions
    .sinkPartitionerFixed()         // each Flink partition ends up in at-most one Kafka partition (default)
    .sinkPartitionerRoundRobin()    // a Flink partition is distributed to Kafka partitions round-robin
    .sinkPartitionerCustom(MyCustom.class)    // use a custom FlinkKafkaPartitioner subclass
)

2.数据的格式

目前支持CSV，JSON，AVRO三种格式。从json数据源里解析所需要的table字段，这个过程需要我们指定。总共有三种方式，如下：

.withFormat(
  new Json()
    .failOnMissingField(true)   // optional: flag whether to fail if a field is missing or not, false by default

    // required: define the schema either by using type information which parses numbers to corresponding types
    .schema(Type.ROW(...))

    // or by using a JSON schema which parses to DECIMAL and TIMESTAMP
    .jsonSchema(
      "{" +
      "  type: 'object'," +
      "  properties: {" +
      "    lon: {" +
      "      type: 'number'" +
      "    }," +
      "    rideTime: {" +
      "      type: 'string'," +
      "      format: 'date-time'" +
      "    }" +
      "  }" +
      "}"
    )

    // or use the table's schema
    .deriveSchema()
)

其实，最常用的是第三种，直接从我们指定的schema里逆推。

3.schema信息

除了配置schema信息之外，还可以配置时间相关的概念。

.withSchema(
  new Schema()
    .field("MyField1", Types.SQL_TIMESTAMP)
      .proctime()      // optional: declares this field as a processing-time attribute
    .field("MyField2", Types.SQL_TIMESTAMP)
      .rowtime(...)    // optional: declares this field as a event-time attribute
    .field("MyField3", Types.BOOLEAN)
      .from("mf3")     // optional: original field in the input that is referenced/aliased by this field
)

4.输出的更新模式

更新模式有append模式，retract模式，update模式。

.connect(...)
  .inAppendMode()    // otherwise: inUpsertMode() or inRetractMode()

5.时间相关配置

在配置schema信息的时候可以配置时间相关的概念，比如事件时间，处理时间，还可以配置watermark相关的，甚至是自定义watermark。

对于事件时间，时间戳抽取支持：

// Converts an existing LONG or SQL_TIMESTAMP field in the input into the rowtime attribute.
.rowtime(
  new Rowtime()
    .timestampsFromField("ts_field")    // required: original field name in the input
)

// Converts the assigned timestamps from a DataStream API record into the rowtime attribute
// and thus preserves the assigned timestamps from the source.
// This requires a source that assigns timestamps (e.g., Kafka 0.10+).
.rowtime(
  new Rowtime()
    .timestampsFromSource()
)

// Sets a custom timestamp extractor to be used for the rowtime attribute.
// The extractor must extend `org.apache.flink.table.sources.tsextractors.TimestampExtractor`.
.rowtime(
  new Rowtime()
    .timestampsFromExtractor(...)
)

watermark生成策略支持

// Sets a watermark strategy for ascending rowtime attributes. Emits a watermark of the maximum
// observed timestamp so far minus 1. Rows that have a timestamp equal to the max timestamp
// are not late.
.rowtime(
  new Rowtime()
    .watermarksPeriodicAscending()
)

// Sets a built-in watermark strategy for rowtime attributes which are out-of-order by a bounded time interval.
// Emits watermarks which are the maximum observed timestamp minus the specified delay.
.rowtime(
  new Rowtime()
    .watermarksPeriodicBounded(2000)    // delay in milliseconds
)

// Sets a built-in watermark strategy which indicates the watermarks should be preserved from the
// underlying DataStream API and thus preserves the assigned watermarks from the source.
.rowtime(
  new Rowtime()
    .watermarksFromSource()
)
3.总结

本文主要讲了flink sql与kafka结合的多种方式，对于datastream相关操作可以一般采用addsource和addsink的方式，对于想使用flink的朋友们，kafkajsontablesource和kafkajsontablesink在逐步废弃掉，可以采用connector和catalog的形式，尤其是后者在实现平台的过程中也是非常之靠谱好用的。


----------------------------------------------------
返回主页 Code Complete
博客园首页新随笔联系订阅管理
随笔 - 21  文章 - 22  评论 - 79
追源索骥：透过源码看懂Flink核心框架的执行流程


写在最前：因为这篇博客太长，所以我把它转成了带书签的pdf格式，看起来更方便一点。想要的童鞋可以到我的公众号“老白讲互联网”后台留言flink即可获取。
另，很多同学反映说百度经常死链，又发现github的markdown现在做的还不错，所以也发布了一份到https://github.com/bethunebtj/flink_tutorial.git
希望对大家有所帮助，谢谢！
追源索骥：透过源码看懂Flink核心框架的执行流程
flink

追源索骥：透过源码看懂Flink核心框架的执行流程
前言
1.从 Hello,World WordCount开始
1.1 flink执行环境
1.2 算子（Operator）的注册（声明）
1.3 程序的执行
1.3.1 本地模式下的execute方法
1.3.2 远程模式（RemoteEnvironment）的execute方法
1.3.3 程序启动过程
2.理解flink的图结构
2.1 flink的三层图结构
2.2 StreamGraph的生成
2.2.1 StreamTransformation类代表了流的转换
2.2.2 StreamGraph生成函数分析
2.2.3 WordCount函数的StreamGraph
2.3 JobGraph的生成
2.3.1 JobGraph生成源码
2.3.2 operator chain的逻辑
2.3.3 JobGraph的提交
2.4 ExecutionGraph的生成
3. 任务的调度与执行
3.1 计算资源的调度
3.2 JobManager执行job
3.2.1 JobManager的组件
3.2.2 JobManager的启动过程
3.2.3 JobManager启动Task
3.3 TaskManager执行task
3.3.1 TaskManager的基本组件
3.3.2 TaskManager执行Task
3.3.2.1 生成Task对象
3.3.2.2 运行Task对象
3.3.2.3 StreamTask的执行逻辑
3.4 StreamTask与StreamOperator
4. StreamOperator的抽象与实现
4.1 数据源的逻辑——StreamSource与时间模型
4.2 从数据输入到数据处理——OneInputStreamOperator & AbstractUdfStreamOperator
4.3 StreamSink
5. 为执行保驾护航——Fault Tolerant与保证Exactly-Once语义
5.1 Fault Tolerant演进之路
5.1.1 Storm的Record acknowledgement模式
5.1.2 Spark streaming的micro batch模式
5.1.3 Google Cloud Dataflow的事务式模型
5.1.4 Flink的分布式快照机制
5.2 checkpoint的生命周期
5.2.1 触发checkpoint
5.2.2 Task层面checkpoint的准备工作
5.2.3 操作符的状态保存及barrier传递
5.3 承载checkpoint数据的抽象：State & StateBackend
6.数据流转——Flink的数据抽象及数据交换过程
6.1 flink的数据抽象
6.1.1 MemorySegment
6.1.2 ByteBuffer与NetworkBufferPool
6.1.3 RecordWriter与Record
6.2 数据流转过程
6.2.1 整体过程
6.2.2 数据跨task传递
6.3 Credit漫谈
6.3.1 背压问题
6.3.2 使用Credit实现ATM网络流控
7.其他核心概念
7.1 EventTime时间模型
7.2 FLIP-6 部署及处理模型演进
7.2.1 现有模型不足
7.2.2 核心变更
7.2.3 Cluster Manager的架构
7.2.4 组件设计及细节
8.后记

前言
Flink是大数据处理领域最近很火的一个开源的分布式、高性能的流式处理框架，其对数据的处理可以达到毫秒级别。本文以一个来自官网的WordCount例子为引，全面阐述flink的核心架构及执行流程，希望读者可以借此更加深入的理解Flink逻辑。

本文跳过了一些基本概念，如果对相关概念感到迷惑，请参考官网文档。另外在本文写作过程中，Flink正式发布了其1.5 RELEASE版本，在其发布之后完成的内容将按照1.5的实现来组织。


1.从 Hello,World WordCount开始
首先，我们把WordCount的例子再放一遍：

复制代码
    public class SocketTextStreamWordCount {

    public static void main(String[] args) throws Exception {
        if (args.length != 2){
            System.err.println("USAGE:\nSocketTextStreamWordCount <hostname> <port>");
            return;
        }
        String hostName = args[0];
        Integer port = Integer.parseInt(args[1]);
        // set up the execution environment
        final StreamExecutionEnvironment env = StreamExecutionEnvironment
                .getExecutionEnvironment();

        // get input data
        DataStream<String> text = env.socketTextStream(hostName, port);

        text.flatMap(new LineSplitter()).setParallelism(1)
        // group by the tuple field "0" and sum up tuple field "1"
                .keyBy(0)
                .sum(1).setParallelism(1)
                .print();

        // execute program
        env.execute("Java WordCount from SocketTextStream Example");
    }

        /**
         * Implements the string tokenizer that splits sentences into words as a user-defined
         * FlatMapFunction. The function takes a line (String) and splits it into
         * multiple pairs in the form of "(word,1)" (Tuple2&lt;String, Integer&gt;).
         */
        public static final class LineSplitter implements FlatMapFunction<String, Tuple2<String, Integer>> {
            @Override
            public void flatMap(String value, Collector<Tuple2<String, Integer>> out) {
                // normalize and split the line
                String[] tokens = value.toLowerCase().split("\\W+");
                // emit the pairs
                for (String token : tokens) {
                    if (token.length() > 0) {
                        out.collect(new Tuple2<String, Integer>(token, 1));
                    }
                }
            }
        }
    }
复制代码
首先从命令行中获取socket对端的ip和端口，然后启动一个执行环境，从socket中读取数据，split成单个单词的流，并按单词进行总和的计数，最后打印出来。这个例子相信接触过大数据计算或者函数式编程的人都能看懂，就不过多解释了。


1.1 flink执行环境
程序的启动，从这句开始：final StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment()。
这行代码会返回一个可用的执行环境。执行环境是整个flink程序执行的上下文，记录了相关配置（如并行度等），并提供了一系列方法，如读取输入流的方法，以及真正开始运行整个代码的execute方法等。对于分布式流处理程序来说，我们在代码中定义的flatMap,keyBy等等操作，事实上可以理解为一种声明，告诉整个程序我们采用了什么样的算子，而真正开启计算的代码不在此处。由于我们是在本地运行flink程序，因此这行代码会返回一个LocalStreamEnvironment，最后我们要调用它的execute方法来开启真正的任务。我们先接着往下看。


1.2 算子（Operator）的注册（声明）
我们以flatMap为例,text.flatMap(new LineSplitter())这一句话跟踪进去是这样的：

复制代码
public <R> SingleOutputStreamOperator<R> flatMap(FlatMapFunction<T, R> flatMapper) {

        TypeInformation<R> outType = TypeExtractor.getFlatMapReturnTypes(clean(flatMapper),
                getType(), Utils.getCallLocationName(), true);

        return transform("Flat Map", outType, new StreamFlatMap<>(clean(flatMapper)));

    }
复制代码


里面完成了两件事，一是用反射拿到了flatMap算子的输出类型，二是生成了一个Operator。flink流式计算的核心概念，就是将数据从输入流一个个传递给Operator进行链式处理，最后交给输出流的过程。对数据的每一次处理在逻辑上成为一个operator，并且为了本地化处理的效率起见，operator之间也可以串成一个chain一起处理（可以参考责任链模式帮助理解）。下面这张图表明了flink是如何看待用户的处理流程的：抽象化为一系列operator，以source开始，以sink结尾，中间的operator做的操作叫做transform，并且可以把几个操作串在一起执行。
image_1cae39t06eoo3ml1be8o0412c69.png-43.5kB
我们也可以更改flink的设置，要求它不要对某个操作进行chain处理，或者从某个操作开启一个新chain等。
上面代码中的最后一行transform方法的作用是返回一个SingleOutputStreamOperator，它继承了Datastream类并且定义了一些辅助方法，方便对流的操作。在返回之前，transform方法还把它注册到了执行环境中（后面生成执行图的时候还会用到它）。其他的操作，包括keyBy，sum和print，都只是不同的算子，在这里出现都是一样的效果，即生成一个operator并注册给执行环境用于生成DAG。


1.3 程序的执行
程序执行即env.execute("Java WordCount from SocketTextStream Example")这行代码。


1.3.1 本地模式下的execute方法
这行代码主要做了以下事情：

生成StreamGraph。代表程序的拓扑结构，是从用户代码直接生成的图。
生成JobGraph。这个图是要交给flink去生成task的图。
生成一系列配置
将JobGraph和配置交给flink集群去运行。如果不是本地运行的话，还会把jar文件通过网络发给其他节点。
以本地模式运行的话，可以看到启动过程，如启动性能度量、web模块、JobManager、ResourceManager、taskManager等等
启动任务。值得一提的是在启动任务之前，先启动了一个用户类加载器，这个类加载器可以用来做一些在运行时动态加载类的工作。

1.3.2 远程模式（RemoteEnvironment）的execute方法
远程模式的程序执行更加有趣一点。第一步仍然是获取StreamGraph，然后调用executeRemotely方法进行远程执行。
该方法首先创建一个用户代码加载器

ClassLoader usercodeClassLoader = JobWithJars.buildUserCodeClassLoader(jarFiles, globalClasspaths,   getClass().getClassLoader());


然后创建一系列配置，交给Client对象。Client这个词有意思，看见它就知道这里绝对是跟远程集群打交道的客户端。

复制代码
        ClusterClient client;

        try {
            client = new StandaloneClusterClient(configuration);
            client.setPrintStatusDuringExecution(getConfig().isSysoutLoggingEnabled());
        }
        }
        try {
            return client.run(streamGraph, jarFiles, globalClasspaths, usercodeClassLoader).getJobExecutionResult();
        }
复制代码


client的run方法首先生成一个JobGraph，然后将其传递给JobClient。关于Client、JobClient、JobManager到底谁管谁，可以看这张图：
image_1cae7g15p6k94no1ves121c5pd9.png-19.7kB
确切的说，JobClient负责以异步的方式和JobManager通信（Actor是scala的异步模块），具体的通信任务由JobClientActor完成。相对应的，JobManager的通信任务也由一个Actor完成。

复制代码
        JobListeningContext jobListeningContext = submitJob(
                actorSystem,config,highAvailabilityServices,jobGraph,timeout,sysoutLogUpdates,    classLoader);

        return awaitJobResult(jobListeningContext);
复制代码


可以看到，该方法阻塞在awaitJobResult方法上，并最终返回了一个JobListeningContext，透过这个Context可以得到程序运行的状态和结果。


1.3.3 程序启动过程
上面提到，整个程序真正意义上开始执行，是这里：


env.execute("Java WordCount from SocketTextStream Example");
远程模式和本地模式有一点不同，我们先按本地模式来调试。
我们跟进源码，（在本地调试模式下）会启动一个miniCluster，然后开始执行代码：

复制代码
// LocalStreamEnvironment.java

    @Override
    public JobExecutionResult execute(String jobName) throws Exception {

        //生成各种图结构
        ......

        try {
            //启动集群，包括启动JobMaster，进行leader选举等等
            miniCluster.start();
            configuration.setInteger(RestOptions.PORT, miniCluster.getRestAddress().getPort());

            //提交任务到JobMaster
            return miniCluster.executeJobBlocking(jobGraph);
        }
        finally {
            transformations.clear();
            miniCluster.close();
        }
    }
复制代码


这个方法里有一部分逻辑是与生成图结构相关的，我们放在第二章里讲；现在我们先接着往里跟：

复制代码
//MiniCluster.java
public JobExecutionResult executeJobBlocking(JobGraph job) throws JobExecutionException, InterruptedException {
        checkNotNull(job, "job is null");

        //在这里，最终把job提交给了jobMaster
        final CompletableFuture<JobSubmissionResult> submissionFuture = submitJob(job);

        final CompletableFuture<JobResult> jobResultFuture = submissionFuture.thenCompose(
            (JobSubmissionResult ignored) -> requestJobResult(job.getJobID()));

    ......

    }
复制代码


正如我在注释里写的，这一段代码核心逻辑就是调用那个submitJob方法。那么我们再接着看这个方法：

复制代码
    public CompletableFuture<JobSubmissionResult> submitJob(JobGraph jobGraph) {
        final DispatcherGateway dispatcherGateway;
        try {
            dispatcherGateway = getDispatcherGateway();
        } catch (LeaderRetrievalException | InterruptedException e) {
            ExceptionUtils.checkInterrupted(e);
            return FutureUtils.completedExceptionally(e);
        }

        // we have to allow queued scheduling in Flip-6 mode because we need to request slots
        // from the ResourceManager
        jobGraph.setAllowQueuedScheduling(true);

        final CompletableFuture<Void> jarUploadFuture = uploadAndSetJarFiles(dispatcherGateway, jobGraph);

        final CompletableFuture<Acknowledge> acknowledgeCompletableFuture = jarUploadFuture.thenCompose(

        //在这里执行了真正的submit操作
            (Void ack) -> dispatcherGateway.submitJob(jobGraph, rpcTimeout));

        return acknowledgeCompletableFuture.thenApply(
            (Acknowledge ignored) -> new JobSubmissionResult(jobGraph.getJobID()));
    }
复制代码


这里的Dispatcher是一个接收job，然后指派JobMaster去启动任务的类,我们可以看看它的类结构，有两个实现。在本地环境下启动的是MiniDispatcher，在集群上提交任务时，集群上启动的是StandaloneDispatcher。
image_1cenfj3p9fp110p0a8unn1mrh9.png-27.4kB

那么这个Dispatcher又做了什么呢？它启动了一个JobManagerRunner（这里我要吐槽Flink的命名，这个东西应该叫做JobMasterRunner才对，flink里的JobMaster和JobManager不是一个东西），委托JobManagerRunner去启动该Job的JobMaster。我们看一下对应的代码：

复制代码
//jobManagerRunner.java
    private void verifyJobSchedulingStatusAndStartJobManager(UUID leaderSessionId) throws Exception {

        ......

        final CompletableFuture<Acknowledge> startFuture = jobMaster.start(new JobMasterId(leaderSessionId), rpcTimeout);

        ......
    }
复制代码


然后，JobMaster经过了一堆方法嵌套之后，执行到了这里：

复制代码
    private void scheduleExecutionGraph() {
        checkState(jobStatusListener == null);
        // register self as job status change listener
        jobStatusListener = new JobManagerJobStatusListener();
        executionGraph.registerJobStatusListener(jobStatusListener);

        try {
            //这里调用了ExecutionGraph的启动方法
            executionGraph.scheduleForExecution();
        }
        catch (Throwable t) {
            executionGraph.failGlobal(t);
        }
    }
复制代码


我们知道，flink的框架里有三层图结构，其中ExecutionGraph就是真正被执行的那一层，所以到这里为止，一个任务从提交到真正执行的流程就走完了，我们再回顾一下（顺便提一下远程提交时的流程区别）：

客户端代码的execute方法执行；
本地环境下，MiniCluster完成了大部分任务，直接把任务委派给了MiniDispatcher；
远程环境下，启动了一个RestClusterClient，这个类会以HTTP Rest的方式把用户代码提交到集群上；
远程环境下，请求发到集群上之后，必然有个handler去处理，在这里是JobSubmitHandler。这个类接手了请求后，委派StandaloneDispatcher启动job，到这里之后，本地提交和远程提交的逻辑往后又统一了；
Dispatcher接手job之后，会实例化一个JobManagerRunner，然后用这个runner启动job；
JobManagerRunner接下来把job交给了JobMaster去处理；
JobMaster使用ExecutionGraph的方法启动了整个执行图；整个任务就启动起来了。
至此，第一部分就讲完了。


2.理解flink的图结构
第一部分讲到，我们的主函数最后一项任务就是生成StreamGraph，然后生成JobGraph，然后以此开始调度任务运行，所以接下来我们从这里入手，继续探索flink。


2.1 flink的三层图结构
事实上，flink总共提供了三种图的抽象，我们前面已经提到了StreamGraph和JobGraph，还有一种是ExecutionGraph，是用于调度的基本数据结构。
image_1caf1oll019fp1odv1bh9idosr79.png-486.3kB
上面这张图清晰的给出了flink各个图的工作原理和转换过程。其中最后一个物理执行图并非flink的数据结构，而是程序开始执行后，各个task分布在不同的节点上，所形成的物理上的关系表示。

从JobGraph的图里可以看到，数据从上一个operator流到下一个operator的过程中，上游作为生产者提供了IntermediateDataSet，而下游作为消费者需要JobEdge。事实上，JobEdge是一个通信管道，连接了上游生产的dataset和下游的JobVertex节点。
在JobGraph转换到ExecutionGraph的过程中，主要发生了以下转变：
加入了并行度的概念，成为真正可调度的图结构
生成了与JobVertex对应的ExecutionJobVertex，ExecutionVertex，与IntermediateDataSet对应的IntermediateResult和IntermediateResultPartition等，并行将通过这些类实现
ExecutionGraph已经可以用于调度任务。我们可以看到，flink根据该图生成了一一对应的Task，每个task对应一个ExecutionGraph的一个Execution。Task用InputGate、InputChannel和ResultPartition对应了上面图中的IntermediateResult和ExecutionEdge。
那么，flink抽象出这三层图结构，四层执行逻辑的意义是什么呢？
StreamGraph是对用户逻辑的映射。JobGraph在此基础上进行了一些优化，比如把一部分操作串成chain以提高效率。ExecutionGraph是为了调度存在的，加入了并行处理的概念。而在此基础上真正执行的是Task及其相关结构。


2.2 StreamGraph的生成
在第一节的算子注册部分，我们可以看到，flink把每一个算子transform成一个对流的转换（比如上文中返回的SingleOutputStreamOperator是一个DataStream的子类），并且注册到执行环境中，用于生成StreamGraph。实际生成StreamGraph的入口是StreamGraphGenerator.generate(env, transformations) 其中的transformations是一个list，里面记录的就是我们在transform方法中放进来的算子。


2.2.1 StreamTransformation类代表了流的转换
StreamTransformation代表了从一个或多个DataStream生成新DataStream的操作。顺便，DataStream类在内部组合了一个StreamTransformation类，实际的转换操作均通过该类完成。
image_1caf64b7c1gjnv2eebi1v9e1cvum.png-129.4kB
我们可以看到，从source到各种map,union再到sink操作全部被映射成了StreamTransformation。
其映射过程如下所示：
image_1caf6ak4rkqsc1u1hci93fe0d13.png-36.6kB

以MapFunction为例：

首先，用户代码里定义的UDF会被当作其基类对待，然后交给StreamMap这个operator做进一步包装。事实上，每一个Transformation都对应了一个StreamOperator。
由于map这个操作只接受一个输入，所以再被进一步包装为OneInputTransformation。
最后，将该transformation注册到执行环境中，当执行上文提到的generate方法时，生成StreamGraph图结构。

另外，并不是每一个 StreamTransformation 都会转换成runtime层中的物理操作。有一些只是逻辑概念，比如union、split/select、partition等。如下图所示的转换树，在运行时会优化成下方的操作图。
image_1caf71h79s0s3fodem1aeb1j3m1g.png-83.8kB


2.2.2 StreamGraph生成函数分析
我们从StreamGraphGenerator.generate()方法往下看：

复制代码
    public static StreamGraph generate(StreamExecutionEnvironment env, List<StreamTransformation<?>> transformations) {
        return new StreamGraphGenerator(env).generateInternal(transformations);
    }

    //注意，StreamGraph的生成是从sink开始的
    private StreamGraph generateInternal(List<StreamTransformation<?>> transformations) {
        for (StreamTransformation<?> transformation: transformations) {
            transform(transformation);
        }
        return streamGraph;
    }

    //这个方法的核心逻辑就是判断传入的steamOperator是哪种类型，并执行相应的操作，详情见下面那一大堆if-else
    private Collection<Integer> transform(StreamTransformation<?> transform) {

        if (alreadyTransformed.containsKey(transform)) {
            return alreadyTransformed.get(transform);
        }

        LOG.debug("Transforming " + transform);

        if (transform.getMaxParallelism() <= 0) {

            // if the max parallelism hasn't been set, then first use the job wide max parallelism
            // from theExecutionConfig.
            int globalMaxParallelismFromConfig = env.getConfig().getMaxParallelism();
            if (globalMaxParallelismFromConfig > 0) {
                transform.setMaxParallelism(globalMaxParallelismFromConfig);
            }
        }

        // call at least once to trigger exceptions about MissingTypeInfo
        transform.getOutputType();

        Collection<Integer> transformedIds;
        //这里对操作符的类型进行判断，并以此调用相应的处理逻辑.简而言之，处理的核心无非是递归的将该节点和节点的上游节点加入图
        if (transform instanceof OneInputTransformation<?, ?>) {
            transformedIds = transformOneInputTransform((OneInputTransformation<?, ?>) transform);
        } else if (transform instanceof TwoInputTransformation<?, ?, ?>) {
            transformedIds = transformTwoInputTransform((TwoInputTransformation<?, ?, ?>) transform);
        } else if (transform instanceof SourceTransformation<?>) {
            transformedIds = transformSource((SourceTransformation<?>) transform);
        } else if (transform instanceof SinkTransformation<?>) {
            transformedIds = transformSink((SinkTransformation<?>) transform);
        } else if (transform instanceof UnionTransformation<?>) {
            transformedIds = transformUnion((UnionTransformation<?>) transform);
        } else if (transform instanceof SplitTransformation<?>) {
            transformedIds = transformSplit((SplitTransformation<?>) transform);
        } else if (transform instanceof SelectTransformation<?>) {
            transformedIds = transformSelect((SelectTransformation<?>) transform);
        } else if (transform instanceof FeedbackTransformation<?>) {
            transformedIds = transformFeedback((FeedbackTransformation<?>) transform);
        } else if (transform instanceof CoFeedbackTransformation<?>) {
            transformedIds = transformCoFeedback((CoFeedbackTransformation<?>) transform);
        } else if (transform instanceof PartitionTransformation<?>) {
            transformedIds = transformPartition((PartitionTransformation<?>) transform);
        } else if (transform instanceof SideOutputTransformation<?>) {
            transformedIds = transformSideOutput((SideOutputTransformation<?>) transform);
        } else {
            throw new IllegalStateException("Unknown transformation: " + transform);
        }

        //注意这里和函数开始时的方法相对应，在有向图中要注意避免循环的产生
        // need this check because the iterate transformation adds itself before
        // transforming the feedback edges
        if (!alreadyTransformed.containsKey(transform)) {
            alreadyTransformed.put(transform, transformedIds);
        }

        if (transform.getBufferTimeout() > 0) {
            streamGraph.setBufferTimeout(transform.getId(), transform.getBufferTimeout());
        }
        if (transform.getUid() != null) {
            streamGraph.setTransformationUID(transform.getId(), transform.getUid());
        }
        if (transform.getUserProvidedNodeHash() != null) {
            streamGraph.setTransformationUserHash(transform.getId(), transform.getUserProvidedNodeHash());
        }

        if (transform.getMinResources() != null && transform.getPreferredResources() != null) {
            streamGraph.setResources(transform.getId(), transform.getMinResources(), transform.getPreferredResources());
        }

        return transformedIds;
    }
复制代码


因为map，filter等常用操作都是OneInputStreamOperator,我们就来看看transformOneInputTransform((OneInputTransformation<?, ?>) transform)方法。

复制代码
private <IN, OUT> Collection<Integer> transformOneInputTransform(OneInputTransformation<IN, OUT> transform) {

        Collection<Integer> inputIds = transform(transform.getInput());

        // 在递归处理节点过程中，某个节点可能已经被其他子节点先处理过了，需要跳过
        if (alreadyTransformed.containsKey(transform)) {
            return alreadyTransformed.get(transform);
        }

        //这里是获取slotSharingGroup。这个group用来定义当前我们在处理的这个操作符可以跟什么操作符chain到一个slot里进行操作
        //因为有时候我们可能不满意flink替我们做的chain聚合
        //一个slot就是一个执行task的基本容器
        String slotSharingGroup = determineSlotSharingGroup(transform.getSlotSharingGroup(), inputIds);

        //把该operator加入图
        streamGraph.addOperator(transform.getId(),
                slotSharingGroup,
                transform.getOperator(),
                transform.getInputType(),
                transform.getOutputType(),
                transform.getName());

        //对于keyedStream，我们还要记录它的keySelector方法
        //flink并不真正为每个keyedStream保存一个key，而是每次需要用到key的时候都使用keySelector方法进行计算
        //因此，我们自定义的keySelector方法需要保证幂等性
        //到后面介绍keyGroup的时候我们还会再次提到这一点
        if (transform.getStateKeySelector() != null) {
            TypeSerializer<?> keySerializer = transform.getStateKeyType().createSerializer(env.getConfig());
            streamGraph.setOneInputStateKey(transform.getId(), transform.getStateKeySelector(), keySerializer);
        }

        streamGraph.setParallelism(transform.getId(), transform.getParallelism());
        streamGraph.setMaxParallelism(transform.getId(), transform.getMaxParallelism());

        //为当前节点和它的依赖节点建立边
        //这里可以看到之前提到的select union partition等逻辑节点被合并入edge的过程
        for (Integer inputId: inputIds) {
            streamGraph.addEdge(inputId, transform.getId(), 0);
        }

        return Collections.singleton(transform.getId());
    }

    public void addEdge(Integer upStreamVertexID, Integer downStreamVertexID, int typeNumber) {
        addEdgeInternal(upStreamVertexID,
                downStreamVertexID,
                typeNumber,
                null,
                new ArrayList<String>(),
                null);

    }
    //addEdge的实现，会合并一些逻辑节点
    private void addEdgeInternal(Integer upStreamVertexID,
            Integer downStreamVertexID,
            int typeNumber,
            StreamPartitioner<?> partitioner,
            List<String> outputNames,
            OutputTag outputTag) {
        //如果输入边是侧输出节点，则把side的输入边作为本节点的输入边，并递归调用
        if (virtualSideOutputNodes.containsKey(upStreamVertexID)) {
            int virtualId = upStreamVertexID;
            upStreamVertexID = virtualSideOutputNodes.get(virtualId).f0;
            if (outputTag == null) {
                outputTag = virtualSideOutputNodes.get(virtualId).f1;
            }
            addEdgeInternal(upStreamVertexID, downStreamVertexID, typeNumber, partitioner, null, outputTag);
            //如果输入边是select，则把select的输入边作为本节点的输入边
        } else if (virtualSelectNodes.containsKey(upStreamVertexID)) {
            int virtualId = upStreamVertexID;
            upStreamVertexID = virtualSelectNodes.get(virtualId).f0;
            if (outputNames.isEmpty()) {
                // selections that happen downstream override earlier selections
                outputNames = virtualSelectNodes.get(virtualId).f1;
            }
            addEdgeInternal(upStreamVertexID, downStreamVertexID, typeNumber, partitioner, outputNames, outputTag);
            //如果是partition节点
        } else if (virtualPartitionNodes.containsKey(upStreamVertexID)) {
            int virtualId = upStreamVertexID;
            upStreamVertexID = virtualPartitionNodes.get(virtualId).f0;
            if (partitioner == null) {
                partitioner = virtualPartitionNodes.get(virtualId).f1;
            }
            addEdgeInternal(upStreamVertexID, downStreamVertexID, typeNumber, partitioner, outputNames, outputTag);
        } else {
        //正常的edge处理逻辑
            StreamNode upstreamNode = getStreamNode(upStreamVertexID);
            StreamNode downstreamNode = getStreamNode(downStreamVertexID);

            // If no partitioner was specified and the parallelism of upstream and downstream
            // operator matches use forward partitioning, use rebalance otherwise.
            if (partitioner == null && upstreamNode.getParallelism() == downstreamNode.getParallelism()) {
                partitioner = new ForwardPartitioner<Object>();
            } else if (partitioner == null) {
                partitioner = new RebalancePartitioner<Object>();
            }

            if (partitioner instanceof ForwardPartitioner) {
                if (upstreamNode.getParallelism() != downstreamNode.getParallelism()) {
                    throw new UnsupportedOperationException("Forward partitioning does not allow " +
                            "change of parallelism. Upstream operation: " + upstreamNode + " parallelism: " + upstreamNode.getParallelism() +
                            ", downstream operation: " + downstreamNode + " parallelism: " + downstreamNode.getParallelism() +
                            " You must use another partitioning strategy, such as broadcast, rebalance, shuffle or global.");
                }
            }

            StreamEdge edge = new StreamEdge(upstreamNode, downstreamNode, typeNumber, outputNames, partitioner, outputTag);

            getStreamNode(edge.getSourceId()).addOutEdge(edge);
            getStreamNode(edge.getTargetId()).addInEdge(edge);
        }
    }
复制代码



2.2.3 WordCount函数的StreamGraph
flink提供了一个StreamGraph可视化显示工具，在这里
我们可以把我们的程序的执行计划打印出来System.out.println(env.getExecutionPlan()); 复制到这个网站上，点击生成，如图所示：
image_1cafgsliu1n2n1uj21p971b0h6m71t.png-25.7kB
可以看到，我们源程序被转化成了4个operator。
另外，在operator之间的连线上也显示出了flink添加的一些逻辑流程。由于我设定了每个操作符的并行度都是1，所以在每个操作符之间都是直接FORWARD，不存在shuffle的过程。


2.3 JobGraph的生成
flink会根据上一步生成的StreamGraph生成JobGraph，然后将JobGraph发送到server端进行ExecutionGraph的解析。


2.3.1 JobGraph生成源码
与StreamGraph类似，JobGraph的入口方法是StreamingJobGraphGenerator.createJobGraph()。我们直接来看源码

复制代码
private JobGraph createJobGraph() {

        // 设置启动模式为所有节点均在一开始就启动
        jobGraph.setScheduleMode(ScheduleMode.EAGER);

        // 为每个节点生成hash id
        Map<Integer, byte[]> hashes = defaultStreamGraphHasher.traverseStreamGraphAndGenerateHashes(streamGraph);

        // 为了保持兼容性创建的hash
        List<Map<Integer, byte[]>> legacyHashes = new ArrayList<>(legacyStreamGraphHashers.size());
        for (StreamGraphHasher hasher : legacyStreamGraphHashers) {
            legacyHashes.add(hasher.traverseStreamGraphAndGenerateHashes(streamGraph));
        }

        Map<Integer, List<Tuple2<byte[], byte[]>>> chainedOperatorHashes = new HashMap<>();
        //生成jobvertex，串成chain等
        //这里的逻辑大致可以理解为，挨个遍历节点，如果该节点是一个chain的头节点，就生成一个JobVertex，如果不是头节点，就要把自身配置并入头节点，然后把头节点和自己的出边相连；对于不能chain的节点，当作只有头节点处理即可
        setChaining(hashes, legacyHashes, chainedOperatorHashes);
        //设置输入边edge
        setPhysicalEdges();
        //设置slot共享group
        setSlotSharing();
        //配置检查点
        configureCheckpointing();

        // 如果有之前的缓存文件的配置的话，重新读入
        for (Tuple2<String, DistributedCache.DistributedCacheEntry> e : streamGraph.getEnvironment().getCachedFiles()) {
            DistributedCache.writeFileInfoToConfig(e.f0, e.f1, jobGraph.getJobConfiguration());
        }

        // 传递执行环境配置
        try {
            jobGraph.setExecutionConfig(streamGraph.getExecutionConfig());
        }
        catch (IOException e) {
            throw new IllegalConfigurationException("Could not serialize the ExecutionConfig." +
                    "This indicates that non-serializable types (like custom serializers) were registered");
        }

        return jobGraph;
    }
复制代码


2.3.2 operator chain的逻辑
为了更高效地分布式执行，Flink会尽可能地将operator的subtask链接（chain）在一起形成task。每个task在一个线程中执行。将operators链接成task是非常有效的优化：它能减少线程之间的切换，减少消息的序列化/反序列化，减少数据在缓冲区的交换，减少了延迟的同时提高整体的吞吐量。

image_1cafj7s6bittk5tt0bequlig2a.png-158.7kB
上图中将KeyAggregation和Sink两个operator进行了合并，因为这两个合并后并不会改变整体的拓扑结构。但是，并不是任意两个 operator 就能 chain 一起的,其条件还是很苛刻的：

上下游的并行度一致
下游节点的入度为1 （也就是说下游节点没有来自其他节点的输入）
上下游节点都在同一个 slot group 中（下面会解释 slot group）
下游节点的 chain 策略为 ALWAYS（可以与上下游链接，map、flatmap、filter等默认是ALWAYS）
上游节点的 chain 策略为 ALWAYS 或 HEAD（只能与下游链接，不能与上游链接，Source默认是HEAD）
两个节点间数据分区方式是 forward（参考理解数据流的分区）
用户没有禁用 chain
flink的chain逻辑是一种很常见的设计，比如spring的interceptor也是类似的实现方式。通过把操作符串成一个大操作符，flink避免了把数据序列化后通过网络发送给其他节点的开销，能够大大增强效率。


2.3.3 JobGraph的提交
前面已经提到，JobGraph的提交依赖于JobClient和JobManager之间的异步通信，如图所示：
image_1cafn516r1p68kt31g7r196rcsv2n.png-40.1kB
在submitJobAndWait方法中，其首先会创建一个JobClientActor的ActorRef,然后向其发起一个SubmitJobAndWait消息，该消息将JobGraph的实例提交给JobClientActor。发起模式是ask，它表示需要一个应答消息。

Future<Object> future = Patterns.ask(jobClientActor, new JobClientMessages.SubmitJobAndWait(jobGraph), new Timeout(AkkaUtils.INF_TIMEOUT()));
answer = Await.result(future, AkkaUtils.INF_TIMEOUT());


该SubmitJobAndWait消息被JobClientActor接收后，最终通过调用tryToSubmitJob方法触发真正的提交动作。当JobManager的actor接收到来自client端的请求后，会执行一个submitJob方法，主要做以下事情：

向BlobLibraryCacheManager注册该Job；
构建ExecutionGraph对象；
对JobGraph中的每个顶点进行初始化；
将DAG拓扑中从source开始排序，排序后的顶点集合附加到Exec> - utionGraph对象；
获取检查点相关的配置，并将其设置到ExecutionGraph对象；
向ExecutionGraph注册相关的listener；
执行恢复操作或者将JobGraph信息写入SubmittedJobGraphStore以在后续用于恢复目的；
响应给客户端JobSubmitSuccess消息；
对ExecutionGraph对象进行调度执行；
最后，JobManger会返回消息给JobClient，通知该任务是否提交成功。


2.4 ExecutionGraph的生成
与StreamGraph和JobGraph不同，ExecutionGraph并不是在我们的客户端程序生成，而是在服务端（JobManager处）生成的，顺便flink只维护一个JobManager。其入口代码是ExecutionGraphBuilder.buildGraph（...）
该方法长200多行，其中一大半是checkpoiont的相关逻辑，我们暂且略过，直接看核心方法executionGraph.attachJobGraph(sortedTopology)
因为ExecutionGraph事实上只是改动了JobGraph的每个节点，而没有对整个拓扑结构进行变动，所以代码里只是挨个遍历jobVertex并进行处理：

复制代码
for (JobVertex jobVertex : topologiallySorted) {

            if (jobVertex.isInputVertex() && !jobVertex.isStoppable()) {
                this.isStoppable = false;
            }

            //在这里生成ExecutionGraph的每个节点
            //首先是进行了一堆赋值，将任务信息交给要生成的图节点，以及设定并行度等等
            //然后是创建本节点的IntermediateResult，根据本节点的下游节点的个数确定创建几份
            //最后是根据设定好的并行度创建用于执行task的ExecutionVertex
            //如果job有设定inputsplit的话，这里还要指定inputsplits
            ExecutionJobVertex ejv = new ExecutionJobVertex(
                this,
                jobVertex,
                1,
                rpcCallTimeout,
                globalModVersion,
                createTimestamp);

            //这里要处理所有的JobEdge
            //对每个edge，获取对应的intermediateResult，并记录到本节点的输入上
            //最后，把每个ExecutorVertex和对应的IntermediateResult关联起来
            ejv.connectToPredecessors(this.intermediateResults);

            ExecutionJobVertex previousTask = this.tasks.putIfAbsent(jobVertex.getID(), ejv);
            if (previousTask != null) {
                throw new JobException(String.format("Encountered two job vertices with ID %s : previous=[%s] / new=[%s]",
                        jobVertex.getID(), ejv, previousTask));
            }

            for (IntermediateResult res : ejv.getProducedDataSets()) {
                IntermediateResult previousDataSet = this.intermediateResults.putIfAbsent(res.getId(), res);
                if (previousDataSet != null) {
                    throw new JobException(String.format("Encountered two intermediate data set with ID %s : previous=[%s] / new=[%s]",
                            res.getId(), res, previousDataSet));
                }
            }

            this.verticesInCreationOrder.add(ejv);
            this.numVerticesTotal += ejv.getParallelism();
            newExecJobVertices.add(ejv);
        }
复制代码


至此，ExecutorGraph就创建完成了。


3. 任务的调度与执行
关于flink的任务执行架构，官网的这两张图就是最好的说明：
image_1cafnu1pl1d8c15m219b8vkb2334.png-112.9kB
Flink 集群启动后，首先会启动一个 JobManger 和多个的 TaskManager。用户的代码会由JobClient 提交给 JobManager，JobManager 再把来自不同用户的任务发给 不同的TaskManager 去执行，每个TaskManager管理着多个task，task是执行计算的最小结构， TaskManager 将心跳和统计信息汇报给 JobManager。TaskManager 之间以流的形式进行数据的传输。上述除了task外的三者均为独立的 JVM 进程。
要注意的是，TaskManager和job并非一一对应的关系。flink调度的最小单元是task而非TaskManager，也就是说，来自不同job的不同task可能运行于同一个TaskManager的不同线程上。
image_1cclle7ui2j41nf611gs1is18m19.png-127.5kB
一个flink任务所有可能的状态如上图所示。图上画的很明白，就不再赘述了。


3.1 计算资源的调度
Task slot是一个TaskManager内资源分配的最小载体，代表了一个固定大小的资源子集，每个TaskManager会将其所占有的资源平分给它的slot。
通过调整 task slot 的数量，用户可以定义task之间是如何相互隔离的。每个 TaskManager 有一个slot，也就意味着每个task运行在独立的 JVM 中。每个 TaskManager 有多个slot的话，也就是说多个task运行在同一个JVM中。
而在同一个JVM进程中的task，可以共享TCP连接（基于多路复用）和心跳消息，可以减少数据的网络传输，也能共享一些数据结构，一定程度上减少了每个task的消耗。
每个slot可以接受单个task，也可以接受多个连续task组成的pipeline，如下图所示，FlatMap函数占用一个taskslot，而key Agg函数和sink函数共用一个taskslot：
image_1cafpf21c1jh3s5ap1fisu4v23h.png-44.7kB
为了达到共用slot的目的，除了可以以chain的方式pipeline算子，我们还可以允许SlotSharingGroup，如下图所示：
image_1cafpko68b3r1lk0dpsnmbj3c3u.png-61.2kB
我们可以把不能被chain成一条的两个操作如flatmap和key&sink放在一个TaskSlot里执行，这样做可以获得以下好处：

共用slot使得我们不再需要计算每个任务需要的总task数目，直接取最高算子的并行度即可
对计算资源的利用率更高。例如，通常的轻量级操作map和重量级操作Aggregate不再分别需要一个线程，而是可以在同一个线程内执行，而且对于slot有限的场景，我们可以增大每个task的并行度了。
接下来我们还是用官网的图来说明flink是如何重用slot的：
image_1cafqroarkjkuje1hfi18gor654b.png-137kB
TaskManager1分配一个SharedSlot0
把source task放入一个SimpleSlot0，再把该slot放入SharedSlot0
把flatmap task放入一个SimpleSlot1，再把该slot放入SharedSlot0
因为我们的flatmap task并行度是2，因此不能再放入SharedSlot0，所以向TaskMange21申请了一个新的SharedSlot0
把第二个flatmap task放进一个新的SimpleSlot，并放进TaskManager2的SharedSlot0
开始处理key&sink task，因为其并行度也是2，所以先把第一个task放进TaskManager1的SharedSlot
把第二个key&sink放进TaskManager2的SharedSlot

3.2 JobManager执行job
JobManager负责接收 flink 的作业，调度 task，收集 job 的状态、管理 TaskManagers。被实现为一个 akka actor。


3.2.1 JobManager的组件
BlobServer 是一个用来管理二进制大文件的服务，比如保存用户上传的jar文件，该服务会将其写到磁盘上。还有一些相关的类，如BlobCache，用于TaskManager向JobManager下载用户的jar文件
InstanceManager 用来管理当前存活的TaskManager的组件，记录了TaskManager的心跳信息等
CompletedCheckpointStore 用于保存已完成的checkpoint相关信息，持久化到内存中或者zookeeper上
MemoryArchivist 保存了已经提交到flink的作业的相关信息，如JobGraph等

3.2.2 JobManager的启动过程
先列出JobManager启动的核心代码

复制代码
def runJobManager(
      configuration: Configuration,
      executionMode: JobManagerMode,
      listeningAddress: String,
      listeningPort: Int)
    : Unit = {

    val numberProcessors = Hardware.getNumberCPUCores()

    val futureExecutor = Executors.newScheduledThreadPool(
      numberProcessors,
      new ExecutorThreadFactory("jobmanager-future"))

    val ioExecutor = Executors.newFixedThreadPool(
      numberProcessors,
      new ExecutorThreadFactory("jobmanager-io"))

    val timeout = AkkaUtils.getTimeout(configuration)

    // we have to first start the JobManager ActorSystem because this determines the port if 0
    // was chosen before. The method startActorSystem will update the configuration correspondingly.
    val jobManagerSystem = startActorSystem(
      configuration,
      listeningAddress,
      listeningPort)

    val highAvailabilityServices = HighAvailabilityServicesUtils.createHighAvailabilityServices(
      configuration,
      ioExecutor,
      AddressResolution.NO_ADDRESS_RESOLUTION)

    val metricRegistry = new MetricRegistryImpl(
      MetricRegistryConfiguration.fromConfiguration(configuration))

    metricRegistry.startQueryService(jobManagerSystem, null)

    val (_, _, webMonitorOption, _) = try {
      startJobManagerActors(
        jobManagerSystem,
        configuration,
        executionMode,
        listeningAddress,
        futureExecutor,
        ioExecutor,
        highAvailabilityServices,
        metricRegistry,
        classOf[JobManager],
        classOf[MemoryArchivist],
        Option(classOf[StandaloneResourceManager])
      )
    } catch {
      case t: Throwable =>
        futureExecutor.shutdownNow()
        ioExecutor.shutdownNow()

        throw t
    }

    // block until everything is shut down
    jobManagerSystem.awaitTermination()

    .......
}
复制代码


配置Akka并生成ActorSystem，启动JobManager
启动HA和metric相关服务
在startJobManagerActors()方法中启动JobManagerActors，以及webserver，TaskManagerActor，ResourceManager等等
阻塞等待终止
集群通过LeaderService等选出JobManager的leader

3.2.3 JobManager启动Task
JobManager 是一个Actor，通过各种消息来完成核心逻辑：

复制代码
override def handleMessage: Receive = {
  case GrantLeadership(newLeaderSessionID) =>
    log.info(s"JobManager $getAddress was granted leadership with leader session ID " +
      s"$newLeaderSessionID.")
    leaderSessionID = newLeaderSessionID

    .......
复制代码


有几个比较重要的消息：

GrantLeadership 获得leader授权，将自身被分发到的 session id 写到 zookeeper，并恢复所有的 jobs
RevokeLeadership 剥夺leader授权，打断清空所有的 job 信息，但是保留作业缓存，注销所有的 TaskManagers
RegisterTaskManagers 注册 TaskManager，如果之前已经注册过，则只给对应的 Instance 发送消息，否则启动注册逻辑：在 InstanceManager 中注册该 Instance 的信息，并停止 Instance BlobLibraryCacheManager 的端口【供下载 lib 包用】，同时使用 watch 监听 task manager 的存活
SubmitJob 提交 jobGraph
最后一项SubmintJob就是我们要关注的，从客户端收到JobGraph，转换为ExecutionGraph并执行的过程。
复制代码
private def submitJob(jobGraph: JobGraph, jobInfo: JobInfo, isRecovery: Boolean = false): Unit = {

    ......

    executionGraph = ExecutionGraphBuilder.buildGraph(
          executionGraph,
          jobGraph,
          flinkConfiguration,
          futureExecutor,
          ioExecutor,
          scheduler,
          userCodeLoader,
          checkpointRecoveryFactory,
          Time.of(timeout.length, timeout.unit),
          restartStrategy,
          jobMetrics,
          numSlots,
          blobServer,
          log.logger)

    ......

    if (leaderElectionService.hasLeadership) {
            log.info(s"Scheduling job $jobId ($jobName).")

            executionGraph.scheduleForExecution()

          } else {
            self ! decorateMessage(RemoveJob(jobId, removeJobFromStateBackend = false))

            log.warn(s"Submitted job $jobId, but not leader. The other leader needs to recover " +
              "this. I am not scheduling the job for execution.")

    ......
}
复制代码


首先做一些准备工作，然后获取一个ExecutionGraph，判断是否是恢复的job，然后将job保存下来，并且通知客户端本地已经提交成功了，最后如果确认本JobManager是leader，则执行executionGraph.scheduleForExecution()方法，这个方法经过一系列调用，把每个ExecutionVertex传递给了Excution类的deploy方法：

复制代码
public void deploy() throws JobException {

        ......

        try {
            // good, we are allowed to deploy
            if (!slot.setExecutedVertex(this)) {
                throw new JobException("Could not assign the ExecutionVertex to the slot " + slot);
            }

            // race double check, did we fail/cancel and do we need to release the slot?
            if (this.state != DEPLOYING) {
                slot.releaseSlot();
                return;
            }

            if (LOG.isInfoEnabled()) {
                LOG.info(String.format("Deploying %s (attempt #%d) to %s", vertex.getTaskNameWithSubtaskIndex(),
                        attemptNumber, getAssignedResourceLocation().getHostname()));
            }

            final TaskDeploymentDescriptor deployment = vertex.createDeploymentDescriptor(
                attemptId,
                slot,
                taskState,
                attemptNumber);

            final TaskManagerGateway taskManagerGateway = slot.getTaskManagerGateway();

            final CompletableFuture<Acknowledge> submitResultFuture = taskManagerGateway.submitTask(deployment, timeout);

            ......
        }
        catch (Throwable t) {
            markFailed(t);
            ExceptionUtils.rethrow(t);
        }
    }
复制代码


我们首先生成了一个TaskDeploymentDescriptor，然后交给了taskManagerGateway.submitTask()方法执行。接下来的部分，就属于TaskManager的范畴了。


3.3 TaskManager执行task

3.3.1 TaskManager的基本组件
TaskManager是flink中资源管理的基本组件，是所有执行任务的基本容器，提供了内存管理、IO管理、通信管理等一系列功能，本节对各个模块进行简要介绍。
1. MemoryManager flink并没有把所有内存的管理都委托给JVM，因为JVM普遍存在着存储对象密度低、大内存时GC对系统影响大等问题。所以flink自己抽象了一套内存管理机制，将所有对象序列化后放在自己的MemorySegment上进行管理。MemoryManger涉及内容较多，将在后续章节进行继续剖析。
2. IOManager flink通过IOManager管理磁盘IO的过程，提供了同步和异步两种写模式，又进一步区分了block、buffer和bulk三种读写方式。
IOManager提供了两种方式枚举磁盘文件，一种是直接遍历文件夹下所有文件，另一种是计数器方式，对每个文件名以递增顺序访问。
在底层，flink将文件IO抽象为FileIOChannle，封装了底层实现。
image_1cag7idg4vfj1l871n0l1k0e1f7u4o.png-194.1kB
可以看到，flink在底层实际上都是以异步的方式进行读写。
3. NetworkEnvironment 是TaskManager的网络 IO 组件，包含了追踪中间结果和数据交换的数据结构。它的构造器会统一将配置的内存先分配出来，抽象成 NetworkBufferPool 统一管理内存的申请和释放。意思是说，在输入和输出数据时，不管是保留在本地内存，等待chain在一起的下个操作符进行处理，还是通过网络把本操作符的计算结果发送出去，都被抽象成了NetworkBufferPool。后续我们还将对这个组件进行详细分析。


3.3.2 TaskManager执行Task
对于TM来说，执行task就是把收到的TaskDeploymentDescriptor对象转换成一个task并执行的过程。TaskDeploymentDescriptor这个类保存了task执行所必须的所有内容，例如序列化的算子，输入的InputGate和输出的ResultPartition的定义，该task要作为几个subtask执行等等。
按照正常逻辑思维，很容易想到TM的submitTask方法的行为：首先是确认资源，如寻找JobManager和Blob，而后建立连接，解序列化算子，收集task相关信息，接下来就是创建一个新的Task对象，这个task对象就是真正执行任务的关键所在。

复制代码
val task = new Task(
        jobInformation,
        taskInformation,
        tdd.getExecutionAttemptId,
        tdd.getAllocationId,
        tdd.getSubtaskIndex,
        tdd.getAttemptNumber,
        tdd.getProducedPartitions,
        tdd.getInputGates,
        tdd.getTargetSlotNumber,
        tdd.getTaskStateHandles,
        memoryManager,
        ioManager,
        network,
        bcVarManager,
        taskManagerConnection,
        inputSplitProvider,
        checkpointResponder,
        blobCache,
        libCache,
        fileCache,
        config,
        taskMetricGroup,
        resultPartitionConsumableNotifier,
        partitionStateChecker,
        context.dispatcher)
复制代码


如果读者是从头开始看这篇blog，里面有很多对象应该已经比较明确其作用了（除了那个brVarManager，这个是管理广播变量的，广播变量是一类会被分发到每个任务中的共享变量）。接下来的主要任务，就是把这个task启动起来,然后报告说已经启动task了：

// all good, we kick off the task, which performs its own initialization
task.startTaskThread()

sender ! decorateMessage(Acknowledge.get())


3.3.2.1 生成Task对象
在执行new Task()方法时，第一步是把构造函数里的这些变量赋值给当前task的fields。
接下来是初始化ResultPartition和InputGate。这两个类描述了task的输出数据和输入数据。

复制代码
for (ResultPartitionDeploymentDescriptor desc: resultPartitionDeploymentDescriptors) {
    ResultPartitionID partitionId = new ResultPartitionID(desc.getPartitionId(), executionId);

    this.producedPartitions[counter] = new ResultPartition(
        taskNameWithSubtaskAndId,
        this,
        jobId,
        partitionId,
        desc.getPartitionType(),
        desc.getNumberOfSubpartitions(),
        desc.getMaxParallelism(),
        networkEnvironment.getResultPartitionManager(),
        resultPartitionConsumableNotifier,
        ioManager,
        desc.sendScheduleOrUpdateConsumersMessage());
    //为每个partition初始化对应的writer
    writers[counter] = new ResultPartitionWriter(producedPartitions[counter]);

    ++counter;
}

// Consumed intermediate result partitions
this.inputGates = new SingleInputGate[inputGateDeploymentDescriptors.size()];
this.inputGatesById = new HashMap<>();

counter = 0;

for (InputGateDeploymentDescriptor inputGateDeploymentDescriptor: inputGateDeploymentDescriptors) {
    SingleInputGate gate = SingleInputGate.create(
        taskNameWithSubtaskAndId,
        jobId,
        executionId,
        inputGateDeploymentDescriptor,
        networkEnvironment,
        this,
        metricGroup.getIOMetricGroup());

    inputGates[counter] = gate;
    inputGatesById.put(gate.getConsumedResultId(), gate);

    ++counter;
}
复制代码


最后，创建一个Thread对象，并把自己放进该对象，这样在执行时，自己就有了自身的线程的引用。


3.3.2.2 运行Task对象
Task对象本身就是一个Runable，因此在其run方法里定义了运行逻辑。
第一步是切换Task的状态：

复制代码
        while (true) {
            ExecutionState current = this.executionState;
            ////如果当前的执行状态为CREATED，则将其设置为DEPLOYING状态
            if (current == ExecutionState.CREATED) {
                if (transitionState(ExecutionState.CREATED, ExecutionState.DEPLOYING)) {
                    // success, we can start our work
                    break;
                }
            }
            //如果当前执行状态为FAILED，则发出通知并退出run方法
            else if (current == ExecutionState.FAILED) {
                // we were immediately failed. tell the TaskManager that we reached our final state
                notifyFinalState();
                if (metrics != null) {
                    metrics.close();
                }
                return;
            }
            //如果当前执行状态为CANCELING，则将其修改为CANCELED状态，并退出run
            else if (current == ExecutionState.CANCELING) {
                if (transitionState(ExecutionState.CANCELING, ExecutionState.CANCELED)) {
                    // we were immediately canceled. tell the TaskManager that we reached our final state
                    notifyFinalState();
                    if (metrics != null) {
                        metrics.close();
                    }
                    return;
                }
            }
            //否则说明发生了异常
            else {
                if (metrics != null) {
                    metrics.close();
                }
                throw new IllegalStateException("Invalid state for beginning of operation of task " + this + '.');
            }
        }
复制代码


接下来，就是导入用户类加载器并加载用户代码。
然后，是向网络管理器注册当前任务（flink的各个算子在运行时进行数据交换需要依赖网络管理器），分配一些缓存以保存数据
然后，读入指定的缓存文件。
然后，再把task创建时传入的那一大堆变量用于创建一个执行环境Envrionment。
再然后，对于那些并不是第一次执行的task（比如失败后重启的）要恢复其状态。
接下来最重要的是

invokable.invoke();
方法。为什么这么说呢，因为这个方法就是用户代码所真正被执行的入口。比如我们写的什么new MapFunction()的逻辑，最终就是在这里被执行的。这里说一下这个invokable，这是一个抽象类，提供了可以被TaskManager执行的对象的基本抽象。
这个invokable是在解析JobGraph的时候生成相关信息的，并在此处形成真正可执行的对象

// now load the task's invokable code
//通过反射生成对象
invokable = loadAndInstantiateInvokable(userCodeClassLoader, nameOfInvokableClass);


image_1cbkaa8r9182i18ct1kfu8g829m9.png-29.9kB
上图显示了flink提供的可被执行的Task类型。从名字上就可以看出各个task的作用，在此不再赘述。
接下来就是invoke方法了，因为我们的wordcount例子用了流式api，在此我们以StreamTask的invoke方法为例进行说明。


3.3.2.3 StreamTask的执行逻辑
先上部分核心代码：

复制代码
public final void invoke() throws Exception {

    boolean disposed = false;
    try {
            // -------- Initialize ---------
            //先做一些赋值操作
            ......

    // if the clock is not already set, then assign a default TimeServiceProvider
    //处理timer
    if (timerService == null) {
        ThreadFactory timerThreadFactory =
            new DispatcherThreadFactory(TRIGGER_THREAD_GROUP, "Time Trigger for " + getName());

        timerService = new SystemProcessingTimeService(this, getCheckpointLock(), timerThreadFactory);
    }

    //把之前JobGraph串起来的chain的信息形成实现
    operatorChain = new OperatorChain<>(this);
    headOperator = operatorChain.getHeadOperator();

    // task specific initialization
    //这个init操作的起名非常诡异，因为这里主要是处理算子采用了自定义的checkpoint检查机制的情况，但是起了一个非常大众脸的名字
    init();

    // save the work of reloading state, etc, if the task is already canceled
    if (canceled) {
        throw new CancelTaskException();
    }

    // -------- Invoke --------
    LOG.debug("Invoking {}", getName());

    // we need to make sure that any triggers scheduled in open() cannot be
    // executed before all operators are opened
    synchronized (lock) {

        // both the following operations are protected by the lock
        // so that we avoid race conditions in the case that initializeState()
        // registers a timer, that fires before the open() is called.

        //初始化操作符状态，主要是一些state啥的
        initializeState();
        //对于富操作符，执行其open操作
        openAllOperators();
    }

    // final check to exit early before starting to run
    f (canceled) {
        throw new CancelTaskException();
    }

    // let the task do its work
    //真正开始执行的代码
    isRunning = true;
    run();
复制代码


StreamTask.invoke()方法里，第一个值得一说的是TimerService。Flink在2015年决定向StreamTask类加入timer service的时候解释到：

This integrates the timer as a service in StreamTask that StreamOperators can use by calling a method on the StreamingRuntimeContext. This also ensures that the timer callbacks can not be called concurrently with other methods on the StreamOperator. This behaviour is ensured by an ITCase.

第二个要注意的是chain操作。前面提到了，flink会出于优化的角度，把一些算子chain成一个整体的算子作为一个task来执行。比如wordcount例子中，Source和FlatMap算子就被chain在了一起。在进行chain操作的时候，会设定头节点，并且指定输出的RecordWriter。

接下来不出所料仍然是初始化，只不过初始化的对象变成了各个operator。如果是有checkpoint的，那就从state信息里恢复，不然就作为全新的算子处理。从源码中可以看到，flink针对keyed算子和普通算子做了不同的处理。keyed算子在初始化时需要计算出一个group区间，这个区间的值在整个生命周期里都不会再变化，后面key就会根据hash的不同结果，分配到特定的group中去计算。顺便提一句，flink的keyed算子保存的是对每个数据的key的计算方法，而非真实的key，用户需要自己保证对每一行数据提供的keySelector的幂等性。至于为什么要用KeyGroup的设计，这就牵扯到扩容的范畴了，将在后面的章节进行讲述。
对于openAllOperators()方法，就是对各种RichOperator执行其open方法，通常可用于在执行计算之前加载资源。
最后，run方法千呼万唤始出来，该方法经过一系列跳转，最终调用chain上的第一个算子的run方法。在wordcount的例子中，它最终调用了SocketTextStreamFunction的run，建立socket连接并读入文本。


3.4 StreamTask与StreamOperator
前面提到，Task对象在执行过程中，把执行的任务交给了StreamTask这个类去执行。在我们的wordcount例子中，实际初始化的是OneInputStreamTask的对象（参考上面的类图）。那么这个对象是如何执行用户的代码的呢？

复制代码
    protected void run() throws Exception {
        // cache processor reference on the stack, to make the code more JIT friendly
        final StreamInputProcessor<IN> inputProcessor = this.inputProcessor;

        while (running && inputProcessor.processInput()) {
            // all the work happens in the "processInput" method
        }
    }
复制代码


它做的，就是把任务直接交给了InputProcessor去执行processInput方法。这是一个StreamInputProcessor的实例，该processor的任务就是处理输入的数据，包括用户数据、watermark和checkpoint数据等。我们先来看看这个processor是如何产生的：

复制代码
    public void init() throws Exception {
        StreamConfig configuration = getConfiguration();

        TypeSerializer<IN> inSerializer = configuration.getTypeSerializerIn1(getUserCodeClassLoader());
        int numberOfInputs = configuration.getNumberOfInputs();

        if (numberOfInputs > 0) {
            InputGate[] inputGates = getEnvironment().getAllInputGates();

            inputProcessor = new StreamInputProcessor<>(
                    inputGates,
                    inSerializer,
                    this,
                    configuration.getCheckpointMode(),
                    getCheckpointLock(),
                    getEnvironment().getIOManager(),
                    getEnvironment().getTaskManagerInfo().getConfiguration(),
                    getStreamStatusMaintainer(),
                    this.headOperator);

            // make sure that stream tasks report their I/O statistics
            inputProcessor.setMetricGroup(getEnvironment().getMetricGroup().getIOMetricGroup());
        }
    }
复制代码


这是OneInputStreamTask的init方法，从configs里面获取StreamOperator信息，生成自己的inputProcessor。那么inputProcessor是如何处理数据的呢？我们接着跟进源码：

复制代码
public boolean processInput() throws Exception {
        if (isFinished) {
            return false;
        }
        if (numRecordsIn == null) {
            numRecordsIn = ((OperatorMetricGroup) streamOperator.getMetricGroup()).getIOMetricGroup().getNumRecordsInCounter();
        }

        //这个while是用来处理单个元素的（不要想当然以为是循环处理元素的）
        while (true) {
            //注意 1在下面
            //2.接下来，会利用这个反序列化器得到下一个数据记录，并进行解析（是用户数据还是watermark等等），然后进行对应的操作
            if (currentRecordDeserializer != null) {
                DeserializationResult result = currentRecordDeserializer.getNextRecord(deserializationDelegate);

                if (result.isBufferConsumed()) {
                    currentRecordDeserializer.getCurrentBuffer().recycle();
                    currentRecordDeserializer = null;
                }

                if (result.isFullRecord()) {
                    StreamElement recordOrMark = deserializationDelegate.getInstance();

                    //如果元素是watermark，就准备更新当前channel的watermark值（并不是简单赋值，因为有乱序存在），
                    if (recordOrMark.isWatermark()) {
                        // handle watermark
                        statusWatermarkValve.inputWatermark(recordOrMark.asWatermark(), currentChannel);
                        continue;
                    } else if (recordOrMark.isStreamStatus()) {
                    //如果元素是status，就进行相应处理。可以看作是一个flag，标志着当前stream接下来即将没有元素输入（idle），或者当前即将由空闲状态转为有元素状态（active）。同时，StreamStatus还对如何处理watermark有影响。通过发送status，上游的operator可以很方便的通知下游当前的数据流的状态。
                        // handle stream status
                        statusWatermarkValve.inputStreamStatus(recordOrMark.asStreamStatus(), currentChannel);
                        continue;
                    } else if (recordOrMark.isLatencyMarker()) {
                    //LatencyMarker是用来衡量代码执行时间的。在Source处创建，携带创建时的时间戳，流到Sink时就可以知道经过了多长时间
                        // handle latency marker
                        synchronized (lock) {
                            streamOperator.processLatencyMarker(recordOrMark.asLatencyMarker());
                        }
                        continue;
                    } else {
                    //这里就是真正的，用户的代码即将被执行的地方。从章节1到这里足足用了三万字，有点万里长征的感觉
                        // now we can do the actual processing
                        StreamRecord<IN> record = recordOrMark.asRecord();
                        synchronized (lock) {
                            numRecordsIn.inc();
                            streamOperator.setKeyContextElement1(record);
                            streamOperator.processElement(record);
                        }
                        return true;
                    }
                }
            }

            //1.程序首先获取下一个buffer
            //这一段代码是服务于flink的FaultTorrent机制的，后面我会讲到，这里只需理解到它会尝试获取buffer，然后赋值给当前的反序列化器
            final BufferOrEvent bufferOrEvent = barrierHandler.getNextNonBlocked();
            if (bufferOrEvent != null) {
                if (bufferOrEvent.isBuffer()) {
                    currentChannel = bufferOrEvent.getChannelIndex();
                    currentRecordDeserializer = recordDeserializers[currentChannel];
                    currentRecordDeserializer.setNextBuffer(bufferOrEvent.getBuffer());
                }
                else {
                    // Event received
                    final AbstractEvent event = bufferOrEvent.getEvent();
                    if (event.getClass() != EndOfPartitionEvent.class) {
                        throw new IOException("Unexpected event: " + event);
                    }
                }
            }
            else {
                isFinished = true;
                if (!barrierHandler.isEmpty()) {
                    throw new IllegalStateException("Trailing data in checkpoint barrier handler.");
                }
                return false;
            }
        }
    }
复制代码


到此为止，以上部分就是一个flink程序启动后，到执行用户代码之前，flink框架所做的准备工作。回顾一下：

启动一个环境
生成StreamGraph
注册和选举JobManager
在各节点生成TaskManager，并根据JobGraph生成对应的Task
启动各个task，准备执行代码
接下来，我们挑几个Operator看看flink是如何抽象这些算子的。


4. StreamOperator的抽象与实现

4.1 数据源的逻辑——StreamSource与时间模型
StreamSource抽象了一个数据源，并且指定了一些如何处理数据的模式。

复制代码
public class StreamSource<OUT, SRC extends SourceFunction<OUT>>
        extends AbstractUdfStreamOperator<OUT, SRC> implements StreamOperator<OUT> {

    ......

    public void run(final Object lockingObject, final StreamStatusMaintainer streamStatusMaintainer) throws Exception {
        run(lockingObject, streamStatusMaintainer, output);
    }

    public void run(final Object lockingObject,
            final StreamStatusMaintainer streamStatusMaintainer,
            final Output<StreamRecord<OUT>> collector) throws Exception {

        final TimeCharacteristic timeCharacteristic = getOperatorConfig().getTimeCharacteristic();

        LatencyMarksEmitter latencyEmitter = null;
        if (getExecutionConfig().isLatencyTrackingEnabled()) {
            latencyEmitter = new LatencyMarksEmitter<>(
                getProcessingTimeService(),
                collector,
                getExecutionConfig().getLatencyTrackingInterval(),
                getOperatorConfig().getVertexID(),
                getRuntimeContext().getIndexOfThisSubtask());
        }

        final long watermarkInterval = getRuntimeContext().getExecutionConfig().getAutoWatermarkInterval();

        this.ctx = StreamSourceContexts.getSourceContext(
            timeCharacteristic,
            getProcessingTimeService(),
            lockingObject,
            streamStatusMaintainer,
            collector,
            watermarkInterval,
            -1);

        try {
            userFunction.run(ctx);

            // if we get here, then the user function either exited after being done (finite source)
            // or the function was canceled or stopped. For the finite source case, we should emit
            // a final watermark that indicates that we reached the end of event-time
            if (!isCanceledOrStopped()) {
                ctx.emitWatermark(Watermark.MAX_WATERMARK);
            }
        } finally {
            // make sure that the context is closed in any case
            ctx.close();
            if (latencyEmitter != null) {
                latencyEmitter.close();
            }
        }
    }

    ......

    private static class LatencyMarksEmitter<OUT> {
        private final ScheduledFuture<?> latencyMarkTimer;

        public LatencyMarksEmitter(
                final ProcessingTimeService processingTimeService,
                final Output<StreamRecord<OUT>> output,
                long latencyTrackingInterval,
                final int vertexID,
                final int subtaskIndex) {

            latencyMarkTimer = processingTimeService.scheduleAtFixedRate(
                new ProcessingTimeCallback() {
                    @Override
                    public void onProcessingTime(long timestamp) throws Exception {
                        try {
                            // ProcessingTimeService callbacks are executed under the checkpointing lock
                            output.emitLatencyMarker(new LatencyMarker(timestamp, vertexID, subtaskIndex));
                        } catch (Throwable t) {
                            // we catch the Throwables here so that we don't trigger the processing
                            // timer services async exception handler
                            LOG.warn("Error while emitting latency marker.", t);
                        }
                    }
                },
                0L,
                latencyTrackingInterval);
        }

        public void close() {
            latencyMarkTimer.cancel(true);
        }
    }
}
复制代码


在StreamSource生成上下文之后，接下来就是把上下文交给SourceFunction去执行:

userFunction.run(ctx);
SourceFunction是对Function的一个抽象，就好像MapFunction，KeyByFunction一样，用户选择实现这些函数，然后flink框架就能利用这些函数进行计算，完成用户逻辑。
我们的wordcount程序使用了flink提供的一个SocketTextStreamFunction。我们可以看一下它的实现逻辑，对source如何运行有一个基本的认识：

复制代码
public void run(SourceContext<String> ctx) throws Exception {
        final StringBuilder buffer = new StringBuilder();
        long attempt = 0;

        while (isRunning) {

            try (Socket socket = new Socket()) {
                currentSocket = socket;

                LOG.info("Connecting to server socket " + hostname + ':' + port);
                socket.connect(new InetSocketAddress(hostname, port), CONNECTION_TIMEOUT_TIME);
                BufferedReader reader = new BufferedReader(new InputStreamReader(socket.getInputStream()));

                char[] cbuf = new char[8192];
                int bytesRead;
                //核心逻辑就是一直读inputSocket,然后交给collect方法
                while (isRunning && (bytesRead = reader.read(cbuf)) != -1) {
                    buffer.append(cbuf, 0, bytesRead);
                    int delimPos;
                    while (buffer.length() >= delimiter.length() && (delimPos = buffer.indexOf(delimiter)) != -1) {
                        String record = buffer.substring(0, delimPos);
                        // truncate trailing carriage return
                        if (delimiter.equals("\n") && record.endsWith("\r")) {
                            record = record.substring(0, record.length() - 1);
                        }
                        //读到数据后，把数据交给collect方法，collect方法负责把数据交到合适的位置（如发布为br变量，或者交给下个operator，或者通过网络发出去）
                        ctx.collect(record);
                        buffer.delete(0, delimPos + delimiter.length());
                    }
                }
            }

            // if we dropped out of this loop due to an EOF, sleep and retry
            if (isRunning) {
                attempt++;
                if (maxNumRetries == -1 || attempt < maxNumRetries) {
                    LOG.warn("Lost connection to server socket. Retrying in " + delayBetweenRetries + " msecs...");
                    Thread.sleep(delayBetweenRetries);
                }
                else {
                    // this should probably be here, but some examples expect simple exists of the stream source
                    // throw new EOFException("Reached end of stream and reconnects are not enabled.");
                    break;
                }
            }
        }

        // collect trailing data
        if (buffer.length() > 0) {
            ctx.collect(buffer.toString());
        }
    }
复制代码


整段代码里，只有collect方法有些复杂度，后面我们在讲到flink的对象机制时会结合来讲，此处知道collect方法会收集结果，然后发送给接收者即可。在我们的wordcount里，这个算子的接收者就是被chain在一起的flatmap算子，不记得这个示例程序的话，可以返回第一章去看一下。


4.2 从数据输入到数据处理——OneInputStreamOperator & AbstractUdfStreamOperator
StreamSource是用来开启整个流的算子，而承接输入数据并进行处理的算子就是OneInputStreamOperator、TwoInputStreamOperator等。
image_1cdc1tbgs136k1ppf17at14fumjf2d.png-126.7kB
整个StreamOperator的继承关系如上图所示（图很大，建议点开放大看）。
OneInputStreamOperator这个接口的逻辑很简单：

复制代码
public interface OneInputStreamOperator<IN, OUT> extends StreamOperator<OUT> {

    /**
     * Processes one element that arrived at this operator.
     * This method is guaranteed to not be called concurrently with other methods of the operator.
     */
    void processElement(StreamRecord<IN> element) throws Exception;

    /**
     * Processes a {@link Watermark}.
     * This method is guaranteed to not be called concurrently with other methods of the operator.
     *
     * @see org.apache.flink.streaming.api.watermark.Watermark
     */
    void processWatermark(Watermark mark) throws Exception;

    void processLatencyMarker(LatencyMarker latencyMarker) throws Exception;
}
复制代码


而实现了这个接口的StreamFlatMap算子也很简单，没什么可说的：

复制代码
public class StreamFlatMap<IN, OUT>
        extends AbstractUdfStreamOperator<OUT, FlatMapFunction<IN, OUT>>
        implements OneInputStreamOperator<IN, OUT> {

    private static final long serialVersionUID = 1L;

    private transient TimestampedCollector<OUT> collector;

    public StreamFlatMap(FlatMapFunction<IN, OUT> flatMapper) {
        super(flatMapper);
        chainingStrategy = ChainingStrategy.ALWAYS;
    }

    @Override
    public void open() throws Exception {
        super.open();
        collector = new TimestampedCollector<>(output);
    }

    @Override
    public void processElement(StreamRecord<IN> element) throws Exception {
        collector.setTimestamp(element);
        userFunction.flatMap(element.getValue(), collector);
    }
}
复制代码


从类图里可以看到，flink为我们封装了一个算子的基类AbstractUdfStreamOperator，提供了一些通用功能，比如把context赋给算子，保存快照等等，其中最为大家了解的应该是这两个：

复制代码
    @Override
    public void open() throws Exception {
        super.open();
        FunctionUtils.openFunction(userFunction, new Configuration());
    }

    @Override
    public void close() throws Exception {
        super.close();
        functionsClosed = true;
        FunctionUtils.closeFunction(userFunction);
    }
复制代码


这两个就是flink提供的Rich***Function系列算子的open和close方法被执行的地方。


4.3 StreamSink
StreamSink着实没什么可说的，逻辑很简单，值得一提的只有两个方法：

复制代码
    @Override
    public void processElement(StreamRecord<IN> element) throws Exception {
        sinkContext.element = element;
        userFunction.invoke(element.getValue(), sinkContext);
    }

    @Override
    protected void reportOrForwardLatencyMarker(LatencyMarker maker) {
        // all operators are tracking latencies
        this.latencyGauge.reportLatency(maker, true);

        // sinks don't forward latency markers
    }
复制代码


其中，processElement 是继承自StreamOperator的方法。reportOrForwardLatencyMarker是用来计算延迟的，前面提到StreamSource会产生LateMarker，用于记录数据计算时间，就是在这里完成了计算。

算子这部分逻辑相对简单清晰，就讲这么多吧。


5. 为执行保驾护航——Fault Tolerant与保证Exactly-Once语义

5.1 Fault Tolerant演进之路
对于7×24小时不间断运行的流程序来说，要保证fault tolerant是很难的，这不像是离线任务，如果失败了只需要清空已有结果，重新跑一次就可以了。对于流任务，如果要保证能够重新处理已处理过的数据，就要把数据保存下来；而这就面临着几个问题：比如一是保存多久的数据？二是重复计算的数据应该怎么处理，怎么保证幂等性？
对于一个流系统，我们有以下希望：

最好能做到exactly-once
处理延迟越低越好
吞吐量越高越好
计算模型应当足够简单易用，又具有足够的表达力
从错误恢复的开销越低越好
足够的流控制能力（背压能力）

5.1.1 Storm的Record acknowledgement模式
storm的fault tolerant是这样工作的：每一个被storm的operator处理的数据都会向其上一个operator发送一份应答消息，通知其已被下游处理。storm的源operator保存了所有已发送的消息的每一个下游算子的应答消息，当它收到来自sink的应答时，它就知道该消息已经被完整处理，可以移除了。
如果没有收到应答，storm就会重发该消息。显而易见，这是一种at least once的逻辑。另外，这种方式面临着严重的幂等性问题，例如对一个count算子，如果count的下游算子出错，source重发该消息，那么防止该消息被count两遍的逻辑需要程序员自己去实现。最后，这样一种处理方式非常低效，吞吐量很低。


5.1.2 Spark streaming的micro batch模式
前面提到，storm的实现方式就注定了与高吞吐量无缘。那么，为了提高吞吐量，把一批数据聚集在一起处理就是很自然的选择。Spark Streaming的实现就是基于这样的思路：
我们可以在完全的连续计算与完全的分批计算中间取折中，通过控制每批计算数据的大小来控制延迟与吞吐量的制约，如果想要低延迟，就用小一点的batch，如果想要大吞吐量，就不得不忍受更高的延迟（更久的等待数据到来的时间和更多的计算），如下图所示。
image_1ceop58ha180p1h3ren58jk15gb9.png-105.7kB
以这样的方式，可以在每个batch中做到exactly-once，但是这种方式也有其弊端：
首先，batch的方式使得一些需要跨batch的操作变得非常困难，例如session window；用户不得不自己想办法去实现相关逻辑。
其次，batch模式很难做好背压。当一个batch因为种种原因处理慢了，那么下一个batch要么不得不容纳更多的新来数据，要么不得不堆积更多的batch，整个任务可能会被拖垮，这是一个非常致命的问题。
最后，batch的方式基本意味着其延迟是有比较高的下限的，实时性上不好。


5.1.3 Google Cloud Dataflow的事务式模型
我们在传统数据库，如mysql中使用binlog来完成事务，这样的思路也可以被用在实现exactly-once模型中。例如，我们可以log下每个数据元素每一次被处理时的结果和当时所处的操作符的状态。这样，当我们需要fault tolerant时，我们只需要读一下log就可以了。这种模式规避了storm和spark所面临的问题，并且能够很好的实现exactly-once，唯一的弊端是：如何尽可能的减少log的成本？Flink给了我们答案。


5.1.4 Flink的分布式快照机制
实现exactly-once的关键是什么？是能够准确的知道和快速记录下来当前的operator的状态、当前正在处理的元素（以及正处在不同算子之间传递的元素）。如果上面这些可以做到，那么fault tolerant无非就是从持久化存储中读取上次记录的这些元信息，并且恢复到程序中。那么Flink是如何实现的呢？

Flink的分布式快照的核心是其轻量级异步分布式快照机制。为了实现这一机制，flink引入了一个概念，叫做Barrier。Barrier是一种标记，它被source产生并且插入到流数据中，被发送到下游节点。当下游节点处理到该barrier标志时，这就意味着在该barrier插入到流数据时，已经进入系统的数据在当前节点已经被处理完毕。
image_1ceos05badva20hb5glen1voqm.png-15.3kB

如图所示，每当一个barrier流过一个算子节点时，就说明了在该算子上，可以触发一次检查点，用以保存当前节点的状态和已经处理过的数据，这就是一份快照。（在这里可以联想一下micro-batch，把barrier想象成分割每个batch的逻辑，会好理解一点）这样的方式下，记录快照就像和前面提到的micro-batch一样容易。

与此同时，该算子会向下游发送该barrier。因为数据在算子之间是按顺序发送的，所以当下游节点收到该barrier时，也就意味着同样的一批数据在下游节点上也处理完毕，可以进行一次checkpoint，保存基于该节点的一份快照，快照完成后，会通知JobMananger自己完成了这个快照。这就是分布式快照的基本含义。

再看这张图：
image_1ceot7q13apu1a04170af7j1jao34.png-66.6kB
有时，有的算子的上游节点和下游节点都不止一个，应该怎么处理呢？如果有不止一个下游节点，就向每个下游发送barrier。同理，如果有不止一个上游节点，那么就要等到所有上游节点的同一批次的barrier到达之后，才能触发checkpoint。因为每个节点运算速度不同，所以有的上游节点可能已经在发下个barrier周期的数据了，有的上游节点还没发送本次的barrier，这时候，当前算子就要缓存一下提前到来的数据，等比较慢的上游节点发送barrier之后，才能处理下一批数据。

当整个程序的最后一个算子sink都收到了这个barrier，也就意味着这个barrier和上个barrier之间所夹杂的这批元素已经全部落袋为安。这时，最后一个算子通知JobManager整个流程已经完成，而JobManager随后发出通知，要求所有算子删除本次快照内容，以完成清理。这整个部分，就是Flink的两阶段提交的checkpoint过程，如下面四幅图所示：
image_1ceot517e14g31u2u1mnt12o91dkb1g.png-175.5kB

image_1ceot5kqbnik1f2i1dss1q5c1a1t.png-221.3kB

image_1ceot64dppjtojkq3n1jl5j0h2a.png-297.8kB

image_1ceot6kes56sidn1f2u1voo19kf2n.png-255.5kB

总之，通过这种方式，flink实现了我们前面提到的六项对流处理框架的要求：exactly-once、低延迟、高吞吐、易用的模型、方便的恢复机制。

最后，贴一个美团做的flink与storm的性能对比：flink与storm的性能对比


5.2 checkpoint的生命周期
接下来，我们结合源码来看看flink的checkpoint到底是如何实现其生命周期的：

由于flink提供的SocketSource并不支持checkpoint，所以这里我以FlinkKafkaConsumer010作为sourceFunction。


5.2.1 触发checkpoint
要完成一次checkpoint，第一步必然是发起checkpoint请求。那么，这个请求是哪里发出的，怎么发出的，又由谁控制呢？
还记得如果我们要设置checkpoint的话，需要指定checkpoint间隔吧？既然是一个指定间隔触发的功能，那应该会有类似于Scheduler的东西存在，flink里，这个负责触发checkpoint的类是CheckpointCoordinator。

flink在提交job时，会启动这个类的startCheckpointScheduler方法，如下所示

复制代码
    public void startCheckpointScheduler() {
        synchronized (lock) {
            if (shutdown) {
                throw new IllegalArgumentException("Checkpoint coordinator is shut down");
            }

            // make sure all prior timers are cancelled
            stopCheckpointScheduler();

            periodicScheduling = true;
            currentPeriodicTrigger = timer.scheduleAtFixedRate(
                    new ScheduledTrigger(),
                    baseInterval, baseInterval, TimeUnit.MILLISECONDS);
        }
    }

    private final class ScheduledTrigger implements Runnable {

        @Override
        public void run() {
            try {
                triggerCheckpoint(System.currentTimeMillis(), true);
            }
            catch (Exception e) {
                LOG.error("Exception while triggering checkpoint.", e);
            }
        }
    }
复制代码


启动之后，就会以设定好的频率调用triggerCheckPoint()方法。这个方法太长，我大概说一下都做了什么：

检查符合触发checkpoint的条件，例如如果禁止了周期性的checkpoint，尚未达到触发checkpoint的最小间隔等等，就直接return
检查是否所有需要checkpoint和需要响应checkpoint的ACK（ack涉及到checkpoint的两阶段提交，后面会讲）的task都处于running状态，否则return
如果都符合，那么执行checkpointID = checkpointIdCounter.getAndIncrement();以生成一个新的id，然后生成一个PendingCheckpoint。PendingCheckpoint是一个启动了的checkpoint，但是还没有被确认。等到所有的task都确认了本次checkpoint，那么这个checkpoint对象将转化为一个CompletedCheckpoint。
定义一个超时callback，如果checkpoint执行了很久还没完成，就把它取消
触发MasterHooks，用户可以定义一些额外的操作，用以增强checkpoint的功能（如准备和清理外部资源）
接下来是核心逻辑：
   // send the messages to the tasks that trigger their checkpoint
    for (Execution execution: executions) {
        execution.triggerCheckpoint(checkpointID, timestamp, checkpointOptions);
    }


这里是调用了Execution的triggerCheckpoint方法，一个execution就是一个executionVertex的实际执行者。我们看一下这个方法：

复制代码
    public void triggerCheckpoint(long checkpointId, long timestamp, CheckpointOptions checkpointOptions) {
        final LogicalSlot slot = assignedResource;

        if (slot != null) {
        //TaskManagerGateway是用来跟taskManager进行通信的组件
            final TaskManagerGateway taskManagerGateway = slot.getTaskManagerGateway();

            taskManagerGateway.triggerCheckpoint(attemptId, getVertex().getJobId(), checkpointId, timestamp, checkpointOptions);
        } else {
            LOG.debug("The execution has no slot assigned. This indicates that the execution is " +
                "no longer running.");
        }
    }
复制代码


再往下跟就进入了Task类的范畴，我们将在下一小节进行解读。本小节主要讲了CheckpointCoordinator类是如何触发一次checkpoint，从其名字也可以看出来其功能：检查点协调器。


5.2.2 Task层面checkpoint的准备工作
先说Task类中的部分，该类创建了一个CheckpointMetaData的对象，并且生成了一个Runable匿名类用于执行checkpoint，然后以异步的方式触发了该Runable：

复制代码
    public void triggerCheckpointBarrier(
            final long checkpointID,
            long checkpointTimestamp,
            final CheckpointOptions checkpointOptions) {

            ......

            Runnable runnable = new Runnable() {
                @Override
                public void run() {
                    // set safety net from the task's context for checkpointing thread
                    LOG.debug("Creating FileSystem stream leak safety net for {}", Thread.currentThread().getName());
                    FileSystemSafetyNet.setSafetyNetCloseableRegistryForThread(safetyNetCloseableRegistry);

                    try {
                        boolean success = invokable.triggerCheckpoint(checkpointMetaData, checkpointOptions);
                        if (!success) {
                            checkpointResponder.declineCheckpoint(
                                    getJobID(), getExecutionId(), checkpointID,
                                    new CheckpointDeclineTaskNotReadyException(taskName));
                        }
                    }

                    ......
                }
            };
            executeAsyncCallRunnable(runnable, String.format("Checkpoint Trigger for %s (%s).", taskNameWithSubtask, executionId));
        }
    }
复制代码


上面代码里的invokable事实上就是我们的StreamTask了。Task类实际上是将checkpoint委托给了更具体的类去执行，而StreamTask也将委托给更具体的类，直到业务代码。
StreamTask是这样实现的：

如果task还在运行，那就可以进行checkpoint。方法是先向下游所有出口广播一个Barrier，然后触发本task的State保存。
如果task结束了，那我们就要通知下游取消本次checkpoint，方法是发送一个CancelCheckpointMarker，这是类似于Barrier的另一种消息。
注意，从这里开始，整个执行链路上开始出现Barrier，可以和前面讲Fault Tolerant原理的地方结合看一下。
复制代码
    private boolean performCheckpoint(
            CheckpointMetaData checkpointMetaData,
            CheckpointOptions checkpointOptions,
            CheckpointMetrics checkpointMetrics) throws Exception {

        synchronized (lock) {
            if (isRunning) {

                operatorChain.broadcastCheckpointBarrier(
                        checkpointMetaData.getCheckpointId(),
                        checkpointMetaData.getTimestamp(),
                        checkpointOptions);

                checkpointState(checkpointMetaData, checkpointOptions, checkpointMetrics);
                return true;
            }
            else {

                ......

            }
        }
    }
复制代码


完成broadcastCheckpointBarrier方法后，在checkpointState()方法中，StreamTask还做了很多别的工作：

复制代码
        public void executeCheckpointing() throws Exception {

            ......

            try {
                //这里，就是调用StreamOperator进行snapshotState的入口方法
                for (StreamOperator<?> op : allOperators) {
                    checkpointStreamOperator(op);
                }

                // we are transferring ownership over snapshotInProgressList for cleanup to the thread, active on submit
                AsyncCheckpointRunnable asyncCheckpointRunnable = new AsyncCheckpointRunnable(
                    owner,
                    operatorSnapshotsInProgress,
                    checkpointMetaData,
                    checkpointMetrics,
                    startAsyncPartNano);

                owner.cancelables.registerCloseable(asyncCheckpointRunnable);
                //这里注册了一个Runnable，在执行完checkpoint之后向JobManager发出CompletedCheckPoint消息，这也是fault tolerant两阶段提交的一部分
                owner.asyncOperationsThreadPool.submit(asyncCheckpointRunnable);

                ......

            }
        }
复制代码


说到checkpoint，我们印象里最直观的感受肯定是我们的一些做聚合的操作符的状态保存，比如sum的和以及count的值等等。这些内容就是StreamOperator部分将要触发保存的内容。可以看到，除了我们直观的这些操作符的状态保存外，flink的checkpoint做了大量的其他工作。

接下来，我们就把目光转向操作符的checkpoint机制。


5.2.3 操作符的状态保存及barrier传递
第四章时，我们已经了解了StreamOperator的类关系，这里，我们就直接接着上一节的checkpointStreamOperator(op)方法往下讲。
顺便，前面也提到了，在进行checkpoint之前，operator初始化时，会执行一个initializeState方法，在该方法中，如果task是从失败中恢复的话，其保存的state也会被restore进来。

传递barrier是在进行本operator的statesnapshot之前完成的，我们先来看看其逻辑，其实和传递一条数据是类似的，就是生成一个CheckpointBarrier对象，然后向每个streamOutput写进去：

复制代码
    public void broadcastCheckpointBarrier(long id, long timestamp, CheckpointOptions checkpointOptions) throws IOException {
        try {
            CheckpointBarrier barrier = new CheckpointBarrier(id, timestamp, checkpointOptions);
            for (RecordWriterOutput<?> streamOutput : streamOutputs) {
                streamOutput.broadcastEvent(barrier);
            }
        }
        catch (InterruptedException e) {
            throw new IOException("Interrupted while broadcasting checkpoint barrier");
        }
    }
复制代码


下游的operator接收到本barrier，就会触发其自身的checkpoint。

StreamTask在执行完broadcastCheckpointBarrier之后，
我们当前的wordcount程序里有两个operator chain，分别是：

kafka source -> flatmap
keyed aggregation -> sink
我们就按这个顺序来捋一下checkpoint的过程。

1.kafka source的checkpoint过程

复制代码
    public final void snapshotState(FunctionSnapshotContext context) throws Exception {
        if (!running) {
            LOG.debug("snapshotState() called on closed source");
        } else {
            unionOffsetStates.clear();

            final AbstractFetcher<?, ?> fetcher = this.kafkaFetcher;
            if (fetcher == null) {
                // the fetcher has not yet been initialized, which means we need to return the
                // originally restored offsets or the assigned partitions
                for (Map.Entry<KafkaTopicPartition, Long> subscribedPartition : subscribedPartitionsToStartOffsets.entrySet()) {
                    unionOffsetStates.add(Tuple2.of(subscribedPartition.getKey(), subscribedPartition.getValue()));
                }

                if (offsetCommitMode == OffsetCommitMode.ON_CHECKPOINTS) {
                    // the map cannot be asynchronously updated, because only one checkpoint call can happen
                    // on this function at a time: either snapshotState() or notifyCheckpointComplete()
                    pendingOffsetsToCommit.put(context.getCheckpointId(), restoredState);
                }
            } else {
                HashMap<KafkaTopicPartition, Long> currentOffsets = fetcher.snapshotCurrentState();

                if (offsetCommitMode == OffsetCommitMode.ON_CHECKPOINTS) {
                    // the map cannot be asynchronously updated, because only one checkpoint call can happen
                    // on this function at a time: either snapshotState() or notifyCheckpointComplete()
                    pendingOffsetsToCommit.put(context.getCheckpointId(), currentOffsets);
                }

                for (Map.Entry<KafkaTopicPartition, Long> kafkaTopicPartitionLongEntry : currentOffsets.entrySet()) {
                    unionOffsetStates.add(
                            Tuple2.of(kafkaTopicPartitionLongEntry.getKey(), kafkaTopicPartitionLongEntry.getValue()));
                }
            }

            if (offsetCommitMode == OffsetCommitMode.ON_CHECKPOINTS) {
                // truncate the map of pending offsets to commit, to prevent infinite growth
                while (pendingOffsetsToCommit.size() > MAX_NUM_PENDING_CHECKPOINTS) {
                    pendingOffsetsToCommit.remove(0);
                }
            }
        }
    }
复制代码


kafka的snapshot逻辑就是记录一下当前消费的offsets，然后做成tuple（partitiion，offset）放进一个StateBackend里。StateBackend是flink抽象出来的一个用于保存状态的接口。

2.FlatMap算子的checkpoint过程
没什么可说的，就是调用了snapshotState()方法而已。

3.本operator chain的state保存过程
细心的同学应该注意到了，各个算子的snapshot方法只把自己的状态保存到了StateBackend里，没有写入的持久化操作。这部分操作被放到了AbstractStreamOperator中，由flink统一负责持久化。其实不需要看源码我们也能想出来，持久化无非就是把这些数据用一个流写到磁盘或者别的地方，接下来我们来看看是不是这样：

复制代码
            //还是AbstractStreamOperator.java的snapshotState方法
            if (null != operatorStateBackend) {
                snapshotInProgress.setOperatorStateManagedFuture(
                    operatorStateBackend.snapshot(checkpointId, timestamp, factory, checkpointOptions));
            }
复制代码


那么这个operatorStateBackend是怎么保存状态的呢？
首先把各个算子的state做了一份深拷贝；
然后以异步的方式执行了一个内部类的runnable，该内部类的run方法实现了一个模版方法，首先打开stream，然后写入数据，然后再关闭stream。
我们来看看这个写入数据的方法：

复制代码
                public SnapshotResult<OperatorStateHandle> performOperation() throws Exception {
                    long asyncStartTime = System.currentTimeMillis();

                    CheckpointStreamFactory.CheckpointStateOutputStream localOut = this.out;

                    // get the registered operator state infos ...
                    List<RegisteredOperatorBackendStateMetaInfo.Snapshot<?>> operatorMetaInfoSnapshots =
                        new ArrayList<>(registeredOperatorStatesDeepCopies.size());

                    for (Map.Entry<String, PartitionableListState<?>> entry : registeredOperatorStatesDeepCopies.entrySet()) {
                        operatorMetaInfoSnapshots.add(entry.getValue().getStateMetaInfo().snapshot());
                    }

                    // ... write them all in the checkpoint stream ...
                    DataOutputView dov = new DataOutputViewStreamWrapper(localOut);

                    OperatorBackendSerializationProxy backendSerializationProxy =
                        new OperatorBackendSerializationProxy(operatorMetaInfoSnapshots, broadcastMetaInfoSnapshots);

                    backendSerializationProxy.write(dov);

                    ......

                }
复制代码


注释写的很清楚，我就不多说了。

4.后继operatorChain的checkpoint过程
前面说到，在flink的流中，barrier流过时会触发checkpoint。在上面第1步中，上游节点已经发出了Barrier，所以在我们的keyed aggregation -> sink 这个operatorchain中，我们将首先捕获这个barrier。

捕获barrier的过程其实就是处理input数据的过程，对应着StreamInputProcessor.processInput()方法，该方法我们在第四章已经讲过，这里我们简单回顾一下：

复制代码
            //每个元素都会触发这一段逻辑，如果下一个数据是buffer，则从外围的while循环里进入处理用户数据的逻辑；这个方法里默默的处理了barrier的逻辑
            final BufferOrEvent bufferOrEvent = barrierHandler.getNextNonBlocked();
            if (bufferOrEvent != null) {
                if (bufferOrEvent.isBuffer()) {
                    currentChannel = bufferOrEvent.getChannelIndex();
                    currentRecordDeserializer = recordDeserializers[currentChannel];
                    currentRecordDeserializer.setNextBuffer(bufferOrEvent.getBuffer());
                }
                else {
                    // Event received
                    final AbstractEvent event = bufferOrEvent.getEvent();
                    if (event.getClass() != EndOfPartitionEvent.class) {
                        throw new IOException("Unexpected event: " + event);
                    }
                }
            }
复制代码


处理barrier的过程在这段代码里没有体现，因为被包含在了getNextNonBlocked()方法中，我们看下这个方法的核心逻辑：

复制代码
            //BarrierBuffer.getNextNonBlocked方法
            else if (bufferOrEvent.getEvent().getClass() == CheckpointBarrier.class) {
                if (!endOfStream) {
                    // process barriers only if there is a chance of the checkpoint completing
                    processBarrier((CheckpointBarrier) bufferOrEvent.getEvent(), bufferOrEvent.getChannelIndex());
                }
            }
            else if (bufferOrEvent.getEvent().getClass() == CancelCheckpointMarker.class) {
                processCancellationBarrier((CancelCheckpointMarker) bufferOrEvent.getEvent());
            }
复制代码


先提一嘴，大家还记得之前的部分也提到过CheckpointMarker吧，这里正好也对上了。

处理barrier也是个麻烦事，大家回想一下5.1节提到的屏障的原理图，一个opertor必须收到从每个inputchannel发过来的同一序号的barrier之后才能发起本节点的checkpoint，如果有的channel的数据处理的快了，那该barrier后的数据还需要缓存起来，如果有的inputchannel被关闭了，那它就不会再发送barrier过来了：

复制代码
private void processBarrier(CheckpointBarrier receivedBarrier, int channelIndex) throws Exception {
        final long barrierId = receivedBarrier.getId();

        // fast path for single channel cases
        if (totalNumberOfInputChannels == 1) {
            if (barrierId > currentCheckpointId) {
                // new checkpoint
                currentCheckpointId = barrierId;
                notifyCheckpoint(receivedBarrier);
            }
            return;
        }

        // -- general code path for multiple input channels --

        if (numBarriersReceived > 0) {
            // this is only true if some alignment is already progress and was not canceled

            if (barrierId == currentCheckpointId) {
                // regular case
                onBarrier(channelIndex);
            }
            else if (barrierId > currentCheckpointId) {
                // we did not complete the current checkpoint, another started before
                LOG.warn("Received checkpoint barrier for checkpoint {} before completing current checkpoint {}. " +
                        "Skipping current checkpoint.", barrierId, currentCheckpointId);

                // let the task know we are not completing this
                notifyAbort(currentCheckpointId, new CheckpointDeclineSubsumedException(barrierId));

                // abort the current checkpoint
                releaseBlocksAndResetBarriers();

                // begin a the new checkpoint
                beginNewAlignment(barrierId, channelIndex);
            }
            else {
                // ignore trailing barrier from an earlier checkpoint (obsolete now)
                return;
            }
        }
        else if (barrierId > currentCheckpointId) {
            // first barrier of a new checkpoint
            beginNewAlignment(barrierId, channelIndex);
        }
        else {
            // either the current checkpoint was canceled (numBarriers == 0) or
            // this barrier is from an old subsumed checkpoint
            return;
        }

        // check if we have all barriers - since canceled checkpoints always have zero barriers
        // this can only happen on a non canceled checkpoint
        if (numBarriersReceived + numClosedChannels == totalNumberOfInputChannels) {
            // actually trigger checkpoint
            if (LOG.isDebugEnabled()) {
                LOG.debug("Received all barriers, triggering checkpoint {} at {}",
                        receivedBarrier.getId(), receivedBarrier.getTimestamp());
            }

            releaseBlocksAndResetBarriers();
            notifyCheckpoint(receivedBarrier);
        }
    }
复制代码


总之，当收到全部的barrier之后，就会触发notifyCheckpoint()，该方法又会调用StreamTask的triggerCheckpoint，和之前的operator是一样的。

如果还有后续的operator的话，就是完全相同的循环，不再赘述。

5.报告完成checkpoint事件
当一个operator保存完checkpoint数据后，就会启动一个异步对象AsyncCheckpointRunnable，用以报告该检查点已完成，其具体逻辑在reportCompletedSnapshotStates中。这个方法把任务又最终委托给了RpcCheckpointResponder这个类：

复制代码
checkpointResponder.acknowledgeCheckpoint(
            jobId,
            executionAttemptID,
            checkpointId,
            checkpointMetrics,
            acknowledgedState);
复制代码


从这个类也可以看出来，它的逻辑是通过rpc的方式远程调JobManager的相关方法完成报告事件，底层也是通过akka实现的。
那么，谁响应了这个rpc调用呢？是该任务的JobMaster。

复制代码
    //JobMaster.java
    public void acknowledgeCheckpoint(
            final JobID jobID,
            final ExecutionAttemptID executionAttemptID,
            final long checkpointId,
            final CheckpointMetrics checkpointMetrics,
            final TaskStateSnapshot checkpointState) {

        final CheckpointCoordinator checkpointCoordinator = executionGraph.getCheckpointCoordinator();
        final AcknowledgeCheckpoint ackMessage = new AcknowledgeCheckpoint(
            jobID,
            executionAttemptID,
            checkpointId,
            checkpointMetrics,
            checkpointState);

        if (checkpointCoordinator != null) {
            getRpcService().execute(() -> {
                try {
                    checkpointCoordinator.receiveAcknowledgeMessage(ackMessage);
                } catch (Throwable t) {
                    log.warn("Error while processing checkpoint acknowledgement message");
                }
            });
        } else {
            log.error("Received AcknowledgeCheckpoint message for job {} with no CheckpointCoordinator",
                    jobGraph.getJobID());
        }
    }
复制代码


JobMaster反手就是一巴掌就把任务又rpc给了CheckpointCoordinator.receiveAcknowledgeMessage()方法。

之前提到，coordinator在触发checkpoint时，生成了一个PendingCheckpoint，保存了所有operator的id。

当PendingCheckpoint收到一个operator的完成checkpoint的消息时，它就把这个operator从未完成checkpoint的节点集合移动到已完成的集合。当所有的operator都报告完成了checkpoint时，CheckpointCoordinator会触发completePendingCheckpoint()方法，该方法做了以下事情：

把pendinCgCheckpoint转换为CompletedCheckpoint
把CompletedCheckpoint加入已完成的检查点集合，并从未完成检查点集合删除该检查点
再度向各个operator发出rpc，通知该检查点已完成
本文里，收到这个远程调用的就是那两个operator chain，我们来看看其逻辑:

复制代码
    public void notifyCheckpointComplete(long checkpointId) throws Exception {
        synchronized (lock) {
            if (isRunning) {
                LOG.debug("Notification of complete checkpoint for task {}", getName());

                for (StreamOperator<?> operator : operatorChain.getAllOperators()) {
                    if (operator != null) {
                        operator.notifyCheckpointComplete(checkpointId);
                    }
                }
            }
            else {
                LOG.debug("Ignoring notification of complete checkpoint for not-running task {}", getName());
            }
        }
    }
复制代码


再接下来无非就是层层通知对应的算子做出响应罢了。
至此，flink的两阶段提交的checkpoint逻辑全部完成。


5.3 承载checkpoint数据的抽象：State & StateBackend
State是快照数据的载体，StateBackend是快照如何被保存的抽象。

State分为 KeyedState和OperatorState，从名字就可以看出来分别对应着keyedStream和其他的oeprator。从State由谁管理上，也可以区分为raw state和Managed state。Flink管理的就是Managed state，用户自己管理的就是raw state。Managed State又分为ValueState、ListState、ReducingState、AggregatingState、FoldingState、MapState这么几种，看名字知用途。

StateBackend目前提供了三个backend，MemoryStateBackend，FsStateBackend，RocksDBStateBackend，都是看名字知用途系列。

State接口、StateBackend接口及其实现都比较简单，代码就不贴了， 尤其State本质上就是一层容器封装。

贴个别人写的状态管理的文章吧：详解Flink中的状态管理


6.数据流转——Flink的数据抽象及数据交换过程
本章打算讲一下flink底层是如何定义和在操作符之间传递数据的。


6.1 flink的数据抽象

6.1.1 MemorySegment
Flink作为一个高效的流框架，为了避免JVM的固有缺陷（java对象存储密度低，FGC影响吞吐和响应等），必然走上自主管理内存的道路。

这个MemorySegment就是Flink的内存抽象。默认情况下，一个MemorySegment可以被看做是一个32kb大的内存块的抽象。这块内存既可以是JVM里的一个byte[]，也可以是堆外内存（DirectByteBuffer）。

如果说byte[]数组和direct memory是最底层的存储，那么memorysegment就是在其上覆盖的一层统一抽象。它定义了一系列抽象方法，用于控制和底层内存的交互，如：

复制代码
public abstract class MemorySegment {

    public abstract byte get(int index);

    public abstract void put(int index, byte b);

    public int size() ;

    public abstract ByteBuffer wrap(int offset, int length);

    ......
}
复制代码


我们可以看到，它在提供了诸多直接操作内存的方法外，还提供了一个wrap()方法，将自己包装成一个ByteBuffer，我们待会儿讲这个ByteBuffer。

Flink为MemorySegment提供了两个实现类：HeapMemorySegment和HybridMemorySegment。他们的区别在于前者只能分配堆内存，而后者能用来分配堆内和堆外内存。事实上，Flink框架里，只使用了后者。这是为什么呢？

如果HybridMemorySegment只能用于分配堆外内存的话，似乎更合常理。但是在JVM的世界中，如果一个方法是一个虚方法，那么每次调用时，JVM都要花时间去确定调用的到底是哪个子类实现的该虚方法（方法重写机制，不明白的去看JVM的invokeVirtual指令），也就意味着每次都要去翻方法表；而如果该方法虽然是个虚方法，但实际上整个JVM里只有一个实现（就是说只加载了一个子类进来），那么JVM会很聪明的把它去虚化处理，这样就不用每次调用方法时去找方法表了，能够大大提升性能。但是只分配堆内或者堆外内存不能满足我们的需要，所以就出现了HybridMemorySegment同时可以分配两种内存的设计。

我们可以看看HybridMemorySegment的构造代码：

复制代码
    HybridMemorySegment(ByteBuffer buffer, Object owner) {
        super(checkBufferAndGetAddress(buffer), buffer.capacity(), owner);
        this.offHeapBuffer = buffer;
    }

        HybridMemorySegment(byte[] buffer, Object owner) {
        super(buffer, owner);
        this.offHeapBuffer = null;
    }
复制代码


其中，第一个构造函数的checkBufferAndGetAddress()方法能够得到direct buffer的内存地址，因此可以操作堆外内存。


6.1.2 ByteBuffer与NetworkBufferPool
在MemorySegment这个抽象之上，Flink在数据从operator内的数据对象在向TaskManager上转移，预备被发给下个节点的过程中，使用的抽象或者说内存对象是Buffer。

注意，这个Buffer是个flink接口，不是java.nio提供的那个Buffer抽象类。Flink在这一层面同时使用了这两个同名概念，用来存储对象，直接看代码时到处都是各种xxxBuffer很容易混淆：

java提供的那个Buffer抽象类在这一层主要用于构建HeapByteBuffer，这个主要是当数据从jvm里的一个对象被序列化成字节数组时用的；
Flink的这个Buffer接口主要是一种flink层面用于传输数据和事件的统一抽象，其实现类是NetworkBuffer，是对MemorySegment的包装。Flink在各个TaskManager之间传递数据时，使用的是这一层的抽象。
因为Buffer的底层是MemorySegment，这可能不是JVM所管理的，所以为了知道什么时候一个Buffer用完了可以回收，Flink引入了引用计数的概念，当确认这个buffer没有人引用，就可以回收这一片MemorySegment用于别的地方了（JVM的垃圾回收为啥不用引用计数？读者思考一下）：

复制代码
public abstract class AbstractReferenceCountedByteBuf extends AbstractByteBuf {

    private volatile int refCnt = 1;

    ......
}
复制代码


为了方便管理NetworkBuffer，Flink提供了BufferPoolFactory，并且提供了唯一实现NetworkBufferPool，这是个工厂模式的应用。

NetworkBufferPool在每个TaskManager上只有一个，负责所有子task的内存管理。其实例化时就会尝试获取所有可由它管理的内存（对于堆内存来说，直接获取所有内存并放入老年代，并令用户对象只在新生代存活，可以极大程度的减少Full GC），我们看看其构造方法：

复制代码
public NetworkBufferPool(int numberOfSegmentsToAllocate, int segmentSize) {

        ......

        try {
            this.availableMemorySegments = new ArrayBlockingQueue<>(numberOfSegmentsToAllocate);
        }
        catch (OutOfMemoryError err) {
            throw new OutOfMemoryError("Could not allocate buffer queue of length "
                    + numberOfSegmentsToAllocate + " - " + err.getMessage());
        }

        try {
            for (int i = 0; i < numberOfSegmentsToAllocate; i++) {
                ByteBuffer memory = ByteBuffer.allocateDirect(segmentSize);
                availableMemorySegments.add(MemorySegmentFactory.wrapPooledOffHeapMemory(memory, null));
            }
        }

        ......

        long allocatedMb = (sizeInLong * availableMemorySegments.size()) >> 20;

        LOG.info("Allocated {} MB for network buffer pool (number of memory segments: {}, bytes per segment: {}).",
                allocatedMb, availableMemorySegments.size(), segmentSize);
    }
复制代码


由于NetworkBufferPool只是个工厂，实际的内存池是LocalBufferPool。每个TaskManager都只有一个NetworkBufferPool工厂，但是上面运行的每个task都要有一个和其他task隔离的LocalBufferPool池，这从逻辑上很好理解。另外，NetworkBufferPool会计算自己所拥有的所有内存分片数，在分配新的内存池时对每个内存池应该占有的内存分片数重分配，步骤是：

首先，从整个工厂管理的内存片中拿出所有的内存池所需要的最少Buffer数目总和
如果正好分配完，就结束
其次，把所有的剩下的没分配的内存片，按照每个LocalBufferPool内存池的剩余想要容量大小进行按比例分配
剩余想要容量大小是这么个东西：如果该内存池至少需要3个buffer，最大需要10个buffer，那么它的剩余想要容量就是7
实现代码如下：

复制代码
    private void redistributeBuffers() throws IOException {
        assert Thread.holdsLock(factoryLock);

        // All buffers, which are not among the required ones
        final int numAvailableMemorySegment = totalNumberOfMemorySegments - numTotalRequiredBuffers;

        if (numAvailableMemorySegment == 0) {
            // in this case, we need to redistribute buffers so that every pool gets its minimum
            for (LocalBufferPool bufferPool : allBufferPools) {
                bufferPool.setNumBuffers(bufferPool.getNumberOfRequiredMemorySegments());
            }
            return;
        }

        long totalCapacity = 0; // long to avoid int overflow

        for (LocalBufferPool bufferPool : allBufferPools) {
            int excessMax = bufferPool.getMaxNumberOfMemorySegments() -
                bufferPool.getNumberOfRequiredMemorySegments();
            totalCapacity += Math.min(numAvailableMemorySegment, excessMax);
        }

        // no capacity to receive additional buffers?
        if (totalCapacity == 0) {
            return; // necessary to avoid div by zero when nothing to re-distribute
        }

        final int memorySegmentsToDistribute = MathUtils.checkedDownCast(
                Math.min(numAvailableMemorySegment, totalCapacity));

        long totalPartsUsed = 0; // of totalCapacity
        int numDistributedMemorySegment = 0;
        for (LocalBufferPool bufferPool : allBufferPools) {
            int excessMax = bufferPool.getMaxNumberOfMemorySegments() -
                bufferPool.getNumberOfRequiredMemorySegments();

            // shortcut
            if (excessMax == 0) {
                continue;
            }

            totalPartsUsed += Math.min(numAvailableMemorySegment, excessMax);


            final int mySize = MathUtils.checkedDownCast(
                    memorySegmentsToDistribute * totalPartsUsed / totalCapacity - numDistributedMemorySegment);

            numDistributedMemorySegment += mySize;
            bufferPool.setNumBuffers(bufferPool.getNumberOfRequiredMemorySegments() + mySize);
        }

        assert (totalPartsUsed == totalCapacity);
        assert (numDistributedMemorySegment == memorySegmentsToDistribute);
    }
复制代码


接下来说说这个LocalBufferPool内存池。
LocalBufferPool的逻辑想想无非是增删改查，值得说的是其fields：

复制代码
    /** 该内存池需要的最少内存片数目*/
    private final int numberOfRequiredMemorySegments;

    /**
     * 当前已经获得的内存片中，还没有写入数据的空白内存片
     */
    private final ArrayDeque<MemorySegment> availableMemorySegments = new ArrayDeque<MemorySegment>();

    /**
     * 注册的所有监控buffer可用性的监听器
     */
    private final ArrayDeque<BufferListener> registeredListeners = new ArrayDeque<>();

    /** 能给内存池分配的最大分片数*/
    private final int maxNumberOfMemorySegments;

    /** 当前内存池大小 */
    private int currentPoolSize;

    /**
     * 所有经由NetworkBufferPool分配的，被本内存池引用到的（非直接获得的）分片数
     */
    private int numberOfRequestedMemorySegments;
复制代码


承接NetworkBufferPool的重分配方法，我们来看看LocalBufferPool的setNumBuffers()方法，代码很短，逻辑也相当简单，就不展开说了：

复制代码
    public void setNumBuffers(int numBuffers) throws IOException {
        synchronized (availableMemorySegments) {
            checkArgument(numBuffers >= numberOfRequiredMemorySegments,
                    "Buffer pool needs at least %s buffers, but tried to set to %s",
                    numberOfRequiredMemorySegments, numBuffers);

            if (numBuffers > maxNumberOfMemorySegments) {
                currentPoolSize = maxNumberOfMemorySegments;
            } else {
                currentPoolSize = numBuffers;
            }

            returnExcessMemorySegments();

            // If there is a registered owner and we have still requested more buffers than our
            // size, trigger a recycle via the owner.
            if (owner != null && numberOfRequestedMemorySegments > currentPoolSize) {
                owner.releaseMemory(numberOfRequestedMemorySegments - numBuffers);
            }
        }
    }
复制代码



6.1.3 RecordWriter与Record
我们接着往高层抽象走，刚刚提到了最底层内存抽象是MemorySegment，用于数据传输的是Buffer，那么，承上启下对接从Java对象转为Buffer的中间对象是什么呢？是StreamRecord。

从StreamRecord<T>这个类名字就可以看出来，这个类就是个wrap，里面保存了原始的Java对象。另外，StreamRecord还保存了一个timestamp。

那么这个对象是怎么变成LocalBufferPool内存池里的一个大号字节数组的呢？借助了StreamWriter这个类。

我们直接来看把数据序列化交出去的方法：

复制代码
    private void sendToTarget(T record, int targetChannel) throws IOException, InterruptedException {
        RecordSerializer<T> serializer = serializers[targetChannel];

        SerializationResult result = serializer.addRecord(record);

        while (result.isFullBuffer()) {
            if (tryFinishCurrentBufferBuilder(targetChannel, serializer)) {
                // If this was a full record, we are done. Not breaking
                // out of the loop at this point will lead to another
                // buffer request before breaking out (that would not be
                // a problem per se, but it can lead to stalls in the
                // pipeline).
                if (result.isFullRecord()) {
                    break;
                }
            }
            BufferBuilder bufferBuilder = requestNewBufferBuilder(targetChannel);

            result = serializer.continueWritingWithNextBufferBuilder(bufferBuilder);
        }
        checkState(!serializer.hasSerializedData(), "All data should be written at once");



        if (flushAlways) {
            targetPartition.flush(targetChannel);
        }
    }
复制代码


先说最后一行，如果配置为flushAlways，那么会立刻把元素发送出去，但是这样吞吐量会下降；Flink的默认设置其实也不是一个元素一个元素的发送，是单独起了一个线程，每隔固定时间flush一次所有channel，较真起来也算是mini batch了。

再说序列化那一句:SerializationResult result = serializer.addRecord(record);。在这行代码中，Flink把对象调用该对象所属的序列化器序列化为字节数组。


6.2 数据流转过程
上一节讲了各层数据的抽象，这一节讲讲数据在各个task之间exchange的过程。


6.2.1 整体过程
看这张图：
image_1cetavukjja42ce1261v5k57i9.png-821.8kB

第一步必然是准备一个ResultPartition；
通知JobMaster；
JobMaster通知下游节点；如果下游节点尚未部署，则部署之；
下游节点向上游请求数据
开始传输数据

6.2.2 数据跨task传递
本节讲一下算子之间具体的数据传输过程。也先上一张图：
image_1cfmpba9v15anggtvsba2o1277m.png-357.5kB
数据在task之间传递有如下几步：

数据在本operator处理完后，交给RecordWriter。每条记录都要选择一个下游节点，所以要经过ChannelSelector。
每个channel都有一个serializer（我认为这应该是为了避免多线程写的麻烦），把这条Record序列化为ByteBuffer
接下来数据被写入ResultPartition下的各个subPartition里，此时该数据已经存入DirectBuffer（MemorySegment）
单独的线程控制数据的flush速度，一旦触发flush，则通过Netty的nio通道向对端写入
对端的netty client接收到数据，decode出来，把数据拷贝到buffer里，然后通知InputChannel
有可用的数据时，下游算子从阻塞醒来，从InputChannel取出buffer，再解序列化成record，交给算子执行用户代码
数据在不同机器的算子之间传递的步骤就是以上这些。

了解了步骤之后，再来看一下部分关键代码：
首先是把数据交给recordwriter。

复制代码
    //RecordWriterOutput.java
    @Override
    public void collect(StreamRecord<OUT> record) {
        if (this.outputTag != null) {
            // we are only responsible for emitting to the main input
            return;
        }
        //这里可以看到把记录交给了recordwriter
        pushToRecordWriter(record);
    }
复制代码


然后recordwriter把数据发送到对应的通道。

复制代码
    //RecordWriter.java
    public void emit(T record) throws IOException, InterruptedException {
        //channelselector登场了
        for (int targetChannel : channelSelector.selectChannels(record, numChannels)) {
            sendToTarget(record, targetChannel);
        }
    }

        private void sendToTarget(T record, int targetChannel) throws IOException, InterruptedException {

        //选择序列化器并序列化数据
        RecordSerializer<T> serializer = serializers[targetChannel];

        SerializationResult result = serializer.addRecord(record);

        while (result.isFullBuffer()) {
            if (tryFinishCurrentBufferBuilder(targetChannel, serializer)) {
                // If this was a full record, we are done. Not breaking
                // out of the loop at this point will lead to another
                // buffer request before breaking out (that would not be
                // a problem per se, but it can lead to stalls in the
                // pipeline).
                if (result.isFullRecord()) {
                    break;
                }
            }
            BufferBuilder bufferBuilder = requestNewBufferBuilder(targetChannel);

            //写入channel
            result = serializer.continueWritingWithNextBufferBuilder(bufferBuilder);
        }
        checkState(!serializer.hasSerializedData(), "All data should be written at once");

        if (flushAlways) {
            targetPartition.flush(targetChannel);
        }
    }
复制代码


接下来是把数据推给底层设施（netty）的过程：

复制代码
    //ResultPartition.java
    @Override
    public void flushAll() {
        for (ResultSubpartition subpartition : subpartitions) {
            subpartition.flush();
        }
    }

        //PartitionRequestQueue.java
        void notifyReaderNonEmpty(final NetworkSequenceViewReader reader) {
        //这里交给了netty server线程去推
        ctx.executor().execute(new Runnable() {
            @Override
            public void run() {
                ctx.pipeline().fireUserEventTriggered(reader);
            }
        });
    }
复制代码


netty相关的部分：

复制代码
    //AbstractChannelHandlerContext.java
    public ChannelHandlerContext fireUserEventTriggered(final Object event) {
        if (event == null) {
            throw new NullPointerException("event");
        } else {
            final AbstractChannelHandlerContext next = this.findContextInbound();
            EventExecutor executor = next.executor();
            if (executor.inEventLoop()) {
                next.invokeUserEventTriggered(event);
            } else {
                executor.execute(new OneTimeTask() {
                    public void run() {
                        next.invokeUserEventTriggered(event);
                    }
                });
            }

            return this;
        }
    }
复制代码


最后真实的写入：

复制代码
    //PartittionRequesetQueue.java
    private void enqueueAvailableReader(final NetworkSequenceViewReader reader) throws Exception {
        if (reader.isRegisteredAsAvailable() || !reader.isAvailable()) {
            return;
        }
        // Queue an available reader for consumption. If the queue is empty,
        // we try trigger the actual write. Otherwise this will be handled by
        // the writeAndFlushNextMessageIfPossible calls.
        boolean triggerWrite = availableReaders.isEmpty();
        registerAvailableReader(reader);

        if (triggerWrite) {
            writeAndFlushNextMessageIfPossible(ctx.channel());
        }
    }

    private void writeAndFlushNextMessageIfPossible(final Channel channel) throws IOException {

        ......

                next = reader.getNextBuffer();
                if (next == null) {
                    if (!reader.isReleased()) {
                        continue;
                    }
                    markAsReleased(reader.getReceiverId());

                    Throwable cause = reader.getFailureCause();
                    if (cause != null) {
                        ErrorResponse msg = new ErrorResponse(
                            new ProducerFailedException(cause),
                            reader.getReceiverId());

                        ctx.writeAndFlush(msg);
                    }
                } else {
                    // This channel was now removed from the available reader queue.
                    // We re-add it into the queue if it is still available
                    if (next.moreAvailable()) {
                        registerAvailableReader(reader);
                    }

                    BufferResponse msg = new BufferResponse(
                        next.buffer(),
                        reader.getSequenceNumber(),
                        reader.getReceiverId(),
                        next.buffersInBacklog());

                    if (isEndOfPartitionEvent(next.buffer())) {
                        reader.notifySubpartitionConsumed();
                        reader.releaseAllResources();

                        markAsReleased(reader.getReceiverId());
                    }

                    // Write and flush and wait until this is done before
                    // trying to continue with the next buffer.
                    channel.writeAndFlush(msg).addListener(writeListener);

                    return;
                }

        ......

    }
复制代码


上面这段代码里第二个方法中调用的writeAndFlush(msg)就是真正往netty的nio通道里写入的地方了。在这里，写入的是一个RemoteInputChannel，对应的就是下游节点的InputGate的channels。

有写就有读，nio通道的另一端需要读入buffer，代码如下：

复制代码
    //CreditBasedPartitionRequestClientHandler.java
    private void decodeMsg(Object msg) throws Throwable {
        final Class<?> msgClazz = msg.getClass();

        // ---- Buffer --------------------------------------------------------
        if (msgClazz == NettyMessage.BufferResponse.class) {
            NettyMessage.BufferResponse bufferOrEvent = (NettyMessage.BufferResponse) msg;

            RemoteInputChannel inputChannel = inputChannels.get(bufferOrEvent.receiverId);
            if (inputChannel == null) {
                bufferOrEvent.releaseBuffer();

                cancelRequestFor(bufferOrEvent.receiverId);

                return;
            }

            decodeBufferOrEvent(inputChannel, bufferOrEvent);

        }

        ......

    }
复制代码


插一句，Flink其实做阻塞和获取数据的方式非常自然，利用了生产者和消费者模型，当获取不到数据时，消费者自然阻塞；当数据被加入队列，消费者被notify。Flink的背压机制也是借此实现。

然后在这里又反序列化成StreamRecord：

复制代码
    //StreamElementSerializer.java
    public StreamElement deserialize(DataInputView source) throws IOException {
        int tag = source.readByte();
        if (tag == TAG_REC_WITH_TIMESTAMP) {
            long timestamp = source.readLong();
            return new StreamRecord<T>(typeSerializer.deserialize(source), timestamp);
        }
        else if (tag == TAG_REC_WITHOUT_TIMESTAMP) {
            return new StreamRecord<T>(typeSerializer.deserialize(source));
        }
        else if (tag == TAG_WATERMARK) {
            return new Watermark(source.readLong());
        }
        else if (tag == TAG_STREAM_STATUS) {
            return new StreamStatus(source.readInt());
        }
        else if (tag == TAG_LATENCY_MARKER) {
            return new LatencyMarker(source.readLong(), new OperatorID(source.readLong(), source.readLong()), source.readInt());
        }
        else {
            throw new IOException("Corrupt stream, found tag: " + tag);
        }
    }
复制代码


然后再次在StreamInputProcessor.processInput()循环中得到处理。

至此，数据在跨jvm的节点之间的流转过程就讲完了。


6.3 Credit漫谈
在看上一部分的代码时，有一个小细节不知道读者有没有注意到，我们的数据发送端的代码叫做PartittionRequesetQueue.java，而我们的接收端却起了一个完全不相干的名字：CreditBasedPartitionRequestClientHandler.java。为什么前面加了CreditBased的前缀呢？


6.3.1 背压问题
在流模型中，我们期待数据是像水流一样平滑的流过我们的引擎，但现实生活不会这么美好。数据的上游可能因为各种原因数据量暴增，远远超出了下游的瞬时处理能力（回忆一下98年大洪水），导致系统崩溃。
那么框架应该怎么应对呢？和人类处理自然灾害的方式类似，我们修建了三峡大坝，当洪水来临时把大量的水囤积在大坝里；对于Flink来说，就是在数据的接收端和发送端放置了缓存池，用以缓冲数据，并且设置闸门阻止数据向下流。

那么Flink又是如何处理背压的呢？答案也是靠这些缓冲池。
image_1cfksrl5cd4m1lbqqqgvc811349.png-43.1kB
这张图说明了Flink在生产和消费数据时的大致情况。ResultPartition和InputGate在输出和输入数据时，都要向NetworkBufferPool申请一块MemorySegment作为缓存池。
接下来的情况和生产者消费者很类似。当数据发送太多，下游处理不过来了，那么首先InputChannel会被填满，然后是InputChannel能申请到的内存达到最大，于是下游停止读取数据，上游负责发送数据的nettyServer会得到响应，停止从ResultSubPartition读取缓存，那么ResultPartition很快也将存满数据不能被消费，从而生产数据的逻辑被阻塞在获取新buffer上，非常自然地形成背压的效果。

Flink自己做了个试验用以说明这个机制的效果：
image_1cfkta54rkdd1od4aau1e3n7nhm.png-240.6kB
我们首先设置生产者的发送速度为60%，然后下游的算子以同样的速度处理数据。然后我们将下游算子的处理速度降低到30%，可以看到上游的生产者的数据产生曲线几乎与消费者同步下滑。而后当我们解除限速，整个流的速度立刻提高到了100%。


6.3.2 使用Credit实现ATM网络流控
上文已经提到，对于流量控制，一个朴素的思路就是在长江上建三峡链路上建立一个拦截的dam，如下图所示：
image_1cfku114lf7hpqf3lmcl0116c13.png-22.7kB
基于Credit的流控就是这样一种建立在信用（消费数据的能力)上的，面向每个虚链路（而非端到端的）流模型，如下图所示：
image_1cfku4g4g174d7gb5ecbfcib71g.png-22.5kB
首先，下游会向上游发送一条credit message，用以通知其目前的信用（可联想信用卡的可用额度），然后上游会根据这个信用消息来决定向下游发送多少数据。当上游把数据发送给下游时，它就从下游的信用卡上划走相应的额度（credit balance）：
image_1cfkug5sm1v4l15pbgj4jntc7q1t.png-12.9kB
下游总共获得的credit数目是Buf_Alloc，已经消费的数据是Fwd_Cnt，上游发送出来的数据是Tx_Cnt，那么剩下的那部分就是Crd_Bal:
Crd_Bal = Buf_Alloc - ( Tx_Cnt - Fwd_Cnt )
上面这个式子应该很好理解。

可以看到，Credit Based Flow Control的关键是buffer分配。这种分配可以在数据的发送端完成，也可以在接收端完成。对于下游可能有多个上游节点的情况（比如Flink），使用接收端的credit分配更加合理：
image_1cfkvpmlh1gl31ef41cvh1c903a19.png-13.1kB
上图中，接收者可以观察到每个上游连接的带宽情况，而上游的节点Snd1却不可能轻易知道发往同一个下游节点的其他Snd2的带宽情况，从而如果在上游控制流量将会很困难，而在下游控制流量将会很方便。

因此，这就是为何Flink在接收端有一个基于Credit的Client，而不是在发送端有一个CreditServer的原因。

最后，再讲一下Credit的面向虚链路的流设计和端到端的流设计的区别：
image_1cfl05d2f1ub879c1lc5qsq14n9m.png-13.4kB
如上图所示，a是面向连接的流设计，b是端到端的流设计。其中，a的设计使得当下游节点3因某些情况必须缓存数据暂缓处理时，每个上游节点（1和2）都可以利用其缓存保存数据；而端到端的设计b里，只有节点3的缓存才可以用于保存数据（读者可以从如何实现上想想为什么）。

对流控制感兴趣的读者，可以看这篇文章：Traffic Management For High-Speed Networks。


7.其他核心概念
截至第六章，和执行过程相关的部分就全部讲完，告一段落了。第七章主要讲一点杂七杂八的内容，有时间就不定期更新。


7.1 EventTime时间模型
flink有三种时间模型：ProcessingTime，EventTime和IngestionTime。
关于时间模型看这张图：
image_1cdbotdcmoe11q961st5lbn1j4n9.png-38.4kB
从这张图里可以很清楚的看到三种Time模型的区别。

EventTime是数据被生产出来的时间，可以是比如传感器发出信号的时间等（此时数据还没有被传输给flink）。
IngestionTime是数据进入flink的时间，也就是从Source进入flink流的时间（此时数据刚刚被传给flink）
ProcessingTime是针对当前算子的系统时间，是指该数据已经进入某个operator时，operator所在系统的当前时间
例如，我在写这段话的时间是2018年5月13日03点47分，但是我引用的这张EventTime的图片，是2015年画出来的，那么这张图的EventTime是2015年，而ProcessingTime是现在。
Flink官网对于时间戳的解释非常详细：点我
Flink对于EventTime模型的实现，依赖的是一种叫做watermark的对象。watermark是携带有时间戳的一个对象，会按照程序的要求被插入到数据流中，用以标志某个事件在该时间发生了。
我再做一点简短的说明，还是以官网的图为例：
image_1cdbt8v5jl2ujn91uu1joh1p4gm.png-11.3kB
对于有序到来的数据，假设我们在timestamp为11的元素后加入一个watermark，时间记录为11，则下个元素收到该watermark时，认为所有早于11的元素均已到达。这是非常理想的情况。
image_1cdbtcc5c1a6i1tuaadb1rd5136913.png-11.6kB
而在现实生活中，经常会遇到乱序的数据。这时，我们虽然在timestamp为7的元素后就收到了11，但是我们一直等到了收到元素12之后，才插入了watermark为11的元素。与上面的图相比，如果我们仍然在11后就插入11的watermark，那么元素9就会被丢弃，造成数据丢失。而我们在12之后插入watermark11，就保证了9仍然会被下一个operator处理。当然，我们不可能无限制的永远等待迟到元素，所以要在哪个元素后插入11需要根据实际场景权衡。

对于来自多个数据源的watermark，可以看这张图：
image_1cdbufp4a1opmsit5n61mial4520.png-72kB
可以看到，当一个operator收到多个watermark时，它遵循最小原则（或者说最早），即算子的当前watermark是流经该算子的最小watermark，以容许来自不同的source的乱序数据到来。
关于事件时间模型，更多内容可以参考Stream 101 和谷歌的这篇论文：Dataflow Model paper


7.2 FLIP-6 部署及处理模型演进
就在老白写这篇blog的时候，Flink发布了其1.5 RELEASE版本，号称实现了其部署及处理模型（也就是FLIP-6)，所以打算简略地说一下FLIP-6的主要内容。


7.2.1 现有模型不足
1.5之前的Flink模型有很多不足，包括：

只能静态分配计算资源
在YARN上所有的资源分配都是一碗水端平的
与Docker/k8s的集成非常之蠢，颇有脱裤子放屁的神韵
JobManager没有任务调度逻辑
任务在YARN上执行结束后web dashboard就不可用
集群的session模式和per job模式混淆难以理解
就我个人而言，我觉得Flink有一个这里完全没提到的不足才是最应该修改的：针对任务的完全的资源隔离。尤其是如果用Standalone集群，一个用户的task跑挂了TaskManager，然后拖垮了整个集群的情况简直不要太多。


7.2.2 核心变更
Single Job JobManager
最重要的变更是一个JobManager只处理一个job。当我们生成JobGraph时就顺便起一个JobManager，这显然更加自然。

ResourceManager
其职责包括获取新的TM和slot，通知失败，释放资源以及缓存TM以用于重用等。重要的是，这个组件要能做到挂掉时不要搞垮正在运行的好好的任务。其职责和与JobManager、TaskManager的交互图如下：
image_1cfl9453k1gld4acr1m13j3195sg.png-23.9kB

TaskManager
TM要与上面的两个组件交互。与JobManager交互时，要能提供slot，要能与所有给出slot的JM交互。丢失与JM的连接时要能试图把本TM上的slot的情况通告给新JM，如果这一步失败，就要能重新分配slot。
与ResourceManager交互时，要通知RM自己的资源和当前的Job分配情况，能按照RM的要求分配资源或者关闭自身。

JobManager Slot Pool
这个pool要持有所有分配给当前job的slot资源，并且能在RM挂掉的情况下管理当前已经持有的slot。

Dispatcher
需要一个Job的分发器的主要原因是在有的集群环境下我们可能需要一个统一的提交和监控点，以及替代之前的Standalone模式下的JobManager。将来对分发器的期望可能包括权限控制等。
image_1cfl9ju2617bh1s191mar1jsp12vot.png-31.4kB


7.2.3 Cluster Manager的架构
YARN
新的基于YARN的架构主要包括不再需要先在容器里启动集群，然后提交任务；用户代码不再使用动态ClassLoader加载；不用的资源可以释放；可以按需分配不同大小的容器等。其执行过程如下：
无Dispatcher时
image_1cfla0n7u1lg21n3o36uu0c1o5h1a.png-46.2kB
有Dispatcher时
image_1cfla15os15i3qcsu6c4p4clk1n.png-50.7kB

Mesos
与基于YARN的模式很像，但是只有带Dispatcher模式，因为只有这样才能在Mesos集群里跑其RM。
image_1cfla4tka101n18bf1mno4npu9s24.png-49.2kB
Mesos的Fault Tolerance是类似这样的：
image_1cfla6eka1ph71mu1pll1q0mgqq2h.png-12.1kB
必须用类似Marathon之类的技术保证Dispatcher的HA。

Standalone
其实没啥可说的，把以前的JobManager的职责换成现在的Dispatcher就行了。
image_1cflaaim2ih2v54umsmq01lqc2u.png-36.8kB
将来可能会实现一个类似于轻量级Yarn的模式。

Docker/k8s
用户定义好容器，至少有一个是job specific的（不然怎么启动任务）；还有用于启动TM的，可以不是job specific的。启动过程如下
image_1cflafs2o1trgicjmdbndn1bdq3b.png-24.2kB


7.2.4 组件设计及细节
分配slot相关细节
从新的TM取slot过程：
image_1cflakoadvjm8pf6nt1k331qj33o.png-77.2kB

从Cached TM取slot过程：
image_1cflambu91ufi5fl1cg9gimdff45.png-63.4kB

失败处理

TM失败
TM失败时，RM要能检测到失败，更新自己的状态，发送消息给JM，重启一份TM；JM要能检测到失败，从状态移除失效slot，标记该TM的task为失败，并在没有足够slot继续任务时调整规模；TM自身则要能从Checkpoint恢复

RM失败
此时TM要能检测到失败，并准备向新的RM注册自身，并且向新的RM传递自身的资源情况；JM要能检测到失败并且等待新的RM可用，重新请求需要的资源；丢失的数据要能从Container、TM等处恢复。

JM失败
TM释放所有task，向新JM注册资源，并且如果不成功，就向RM报告这些资源可用于重分配；RM坐等；JM丢失的数据从持久化存储中获得，已完成的checkpoints从HA恢复，从最近的checkpoint重启task，并申请资源。

JM & RM 失败
TM将在一段时间内试图把资源交给新上任的JM，如果失败，则把资源交给新的RM

TM & RM失败
JM如果正在申请资源，则要等到新的RM启动后才能获得；JM可能需要调整其规模，因为损失了TM的slot。

=================

面试|Flink实现PageRank算法
原创： 浪院长  Spark学习技巧  4天前
PageRank估计是很多面试场合上镜率比较高的吧，面试Spark的时候会被问到，最近flink热，估计也会被问到吧，浪尖就在这里帮大家解决这个疑难杂症。

算法常见的原题是：

pagerank的算法会维护两个数据集：一个由（pageID，linkList）的元素组成，包含每个页面的相邻页面的列表；另一个由（pageID，rank）元素组成，包含每个页面的当前排序值。它按如下步骤进行计算。

将每个页面的排序值初始化为1.0。

在每次迭代中，对页面p，向其每个相邻页面（有直接链接的页面）发送一个值为rank(p)/numNeighbors(p)的贡献值。

将每个页面的排序值设为0.15 + 0.85 * contributionsReceived。

最后两个步骤会重复几个循环，在此过程中，算法会逐渐收敛于每个页面的实际PageRank值。在实际操作中，收敛通常需要大约10轮迭代。



对于SPark的实现前面浪尖也发过了案例了，可以参考：

百度面试题：Spark 实现PageRank

flink实现pagerank会更简单，这个得益于flink支持迭代计算。关于flink的迭代计算可以参考：

Flink特异的迭代操作-bulkIteration

不得不会的Flink Dataset的DeltaI 迭代操作

Flink迭代操作末文-迭代流



下面废话少说直接上案例吧。

import org.apache.flink.api.common.functions.FilterFunction;
import org.apache.flink.api.common.functions.FlatMapFunction;
import org.apache.flink.api.common.functions.GroupReduceFunction;
import org.apache.flink.api.common.functions.MapFunction;
import org.apache.flink.api.java.DataSet;
import org.apache.flink.api.java.ExecutionEnvironment;
import org.apache.flink.api.java.functions.FunctionAnnotation.ForwardedFields;
import org.apache.flink.api.java.operators.IterativeDataSet;
import org.apache.flink.api.java.tuple.Tuple1;
import org.apache.flink.api.java.tuple.Tuple2;
import org.apache.flink.api.java.utils.ParameterTool;
import org.apache.flink.util.Collector;

import java.util.ArrayList;

import static org.apache.flink.api.java.aggregation.Aggregations.SUM;

/**
 算法会维护两个数据集：一个由（pageID，linkList）的元素组成，包含每个页面的相邻页面的列表；
 另一个由（pageID，rank）元素组成，包含每个页面的当前排序值。它按如下步骤进行计算：
 将每个页面的排序值初始化为1.0。
 在每次迭代中，对页面p，向其每个相邻页面（有直接链接的页面）发送一个值为rank(p)/numNeighbors(p)的贡献值。
 将每个页面的排序值设为0.15 + 0.85 * contributionsReceived。
 最后两个步骤会重复几个循环，在此过程中，算法会逐渐收敛于每个页面的实际PageRank值。在实际操作中，收敛通常需要大约10轮迭代。
 */
@SuppressWarnings("serial")
public class PageRank {

  private static final double DAMPENING_FACTOR = 0.85;
  private static final double EPSILON = 0.0001;

  // *************************************************************************
  //     PROGRAM
  // *************************************************************************

  public static void main(String[] args) throws Exception {

    ParameterTool params = ParameterTool.fromArgs(args);

    final int numPages = params.getInt("numPages", PageRankData.getNumberOfPages());
    final int maxIterations = params.getInt("iterations", 10);

    // set up execution environment
    final ExecutionEnvironment env = ExecutionEnvironment.getExecutionEnvironment();

    // make the parameters available to the web ui
    env.getConfig().setGlobalJobParameters(params);

    // get input data
    DataSet<Long> pagesInput = getPagesDataSet(env, params);
    DataSet<Tuple2<Long, Long>> linksInput = getLinksDataSet(env, params);

    // 初始化rank <pageID,rank>
    DataSet<Tuple2<Long, Double>> pagesWithRanks = pagesInput.
        map(new RankAssigner((1.0d / numPages)));

    // 获取<pageID,NeighborsLinkList>
    DataSet<Tuple2<Long, Long[]>> adjacencyListInput =
        linksInput.groupBy(0).reduceGroup(new BuildOutgoingEdgeList());

    // set iterative data set
    IterativeDataSet<Tuple2<Long, Double>> iteration = pagesWithRanks.iterate(maxIterations);

    DataSet<Tuple2<Long, Double>> newRanks = iteration
        // join pages with outgoing edges and distribute rank
        .join(adjacencyListInput).where(0).equalTo(0).flatMap(new JoinVertexWithEdgesMatch())
        // collect and sum ranks
        .groupBy(0).aggregate(SUM, 1)
        // apply dampening factor
        .map(new Dampener(DAMPENING_FACTOR, numPages));

    DataSet<Tuple2<Long, Double>> finalPageRanks = iteration.closeWith(
        newRanks,
        newRanks.join(iteration).where(0).equalTo(0)
        // termination condition
        .filter(new EpsilonFilter())); //自定义了一个终止条件

    // emit result
    if (params.has("output")) {
      finalPageRanks.writeAsCsv(params.get("output"), "\n", " ");
      // execute program
      env.execute("Basic Page Rank Example");
    } else {
      System.out.println("Printing result to stdout. Use --output to specify output path.");
      finalPageRanks.print();
    }
  }

  // *************************************************************************
  //     USER FUNCTIONS
  // *************************************************************************

  /**
   * A map function that assigns an initial rank to all pages.
   */
  public static final class RankAssigner implements MapFunction<Long, Tuple2<Long, Double>> {
    Tuple2<Long, Double> outPageWithRank;

    public RankAssigner(double rank) {
      this.outPageWithRank = new Tuple2<Long, Double>(-1L, rank);
    }

    @Override
    public Tuple2<Long, Double> map(Long page) {
      outPageWithRank.f0 = page;
      return outPageWithRank;
    }
  }

  /**
   * A reduce function that takes a sequence of edges and builds the adjacency list for the vertex where the edges
   * originate. Run as a pre-processing step.
   */
  @ForwardedFields("0")
  public static final class BuildOutgoingEdgeList implements GroupReduceFunction<Tuple2<Long, Long>, Tuple2<Long, Long[]>> {

    private final ArrayList<Long> neighbors = new ArrayList<Long>();

    @Override
    public void reduce(Iterable<Tuple2<Long, Long>> values, Collector<Tuple2<Long, Long[]>> out) {
      neighbors.clear();
      Long id = 0L;

      for (Tuple2<Long, Long> n : values) {
        id = n.f0;
        neighbors.add(n.f1);
      }
      out.collect(new Tuple2<Long, Long[]>(id, neighbors.toArray(new Long[neighbors.size()])));
    }
  }

  /**
   * Join function that distributes a fraction of a vertex's rank to all neighbors.
   */
  public static final class JoinVertexWithEdgesMatch implements FlatMapFunction<Tuple2<Tuple2<Long, Double>, Tuple2<Long, Long[]>>, Tuple2<Long, Double>> {

    @Override
    public void flatMap(Tuple2<Tuple2<Long, Double>, Tuple2<Long, Long[]>> value, Collector<Tuple2<Long, Double>> out){
      Long[] neighbors = value.f1.f1;
      double rank = value.f0.f1;
      double rankToDistribute = rank / ((double) neighbors.length);

      for (Long neighbor: neighbors) {
        out.collect(new Tuple2<Long, Double>(neighbor, rankToDistribute));
      }
    }
  }

  /**
   * The function that applies the page rank dampening formula.
   */
  @ForwardedFields("0")
  public static final class Dampener implements MapFunction<Tuple2<Long, Double>, Tuple2<Long, Double>> {

    private final double dampening;
    private final double randomJump;

    public Dampener(double dampening, double numVertices) {
      this.dampening = dampening;
      this.randomJump = (1 - dampening) / numVertices;
    }

    @Override
    public Tuple2<Long, Double> map(Tuple2<Long, Double> value) {
      value.f1 = (value.f1 * dampening) + randomJump;
      return value;
    }
  }

  /**
   * Filter that filters vertices where the rank difference is below a threshold.
   */
  public static final class EpsilonFilter implements FilterFunction<Tuple2<Tuple2<Long, Double>, Tuple2<Long, Double>>> {

    @Override
    public boolean filter(Tuple2<Tuple2<Long, Double>, Tuple2<Long, Double>> value) {
      return Math.abs(value.f0.f1 - value.f1.f1) > EPSILON;
    }
  }

  // *************************************************************************
  //     UTIL METHODS
  // *************************************************************************

  private static DataSet<Long> getPagesDataSet(ExecutionEnvironment env, ParameterTool params) {
    if (params.has("pages")) {
      return env.readCsvFile(params.get("pages"))
        .fieldDelimiter(" ")
        .lineDelimiter("\n")
        .types(Long.class)
        .map(new MapFunction<Tuple1<Long>, Long>() {
          @Override
          public Long map(Tuple1<Long> v) {
            return v.f0;
          }
        });
    } else {
      System.out.println("Executing PageRank example with default pages data set.");
      System.out.println("Use --pages to specify file input.");
      return PageRankData.getDefaultPagesDataSet(env);
    }
  }

  private static DataSet<Tuple2<Long, Long>> getLinksDataSet(ExecutionEnvironment env, ParameterTool params) {
    if (params.has("links")) {
      return env.readCsvFile(params.get("links"))
        .fieldDelimiter(" ")
        .lineDelimiter("\n")
        .types(Long.class, Long.class);
    } else {
      System.out.println("Executing PageRank example with default links data set.");
      System.out.println("Use --links to specify file input.");
      return PageRankData.getDefaultEdgeDataSet(env);
    }
  }
}
准备数据集

public class PageRankData {

  public static final Object[][] EDGES = {
    {1L, 2L},
    {1L, 15L},
    {2L, 3L},
    {2L, 4L},
    {2L, 5L},
    {2L, 6L},
    {2L, 7L},
    {3L, 13L},
    {4L, 2L},
    {5L, 11L},
    {5L, 12L},
    {6L, 1L},
    {6L, 7L},
    {6L, 8L},
    {7L, 1L},
    {7L, 8L},
    {8L, 1L},
    {8L, 9L},
    {8L, 10L},
    {9L, 14L},
    {9L, 1L},
    {10L, 1L},
    {10L, 13L},
    {11L, 12L},
    {11L, 1L},
    {12L, 1L},
    {13L, 14L},
    {14L, 12L},
    {15L, 1L},
  };

  private static int numPages = 15;

  public static DataSet<Tuple2<Long, Long>> getDefaultEdgeDataSet(ExecutionEnvironment env) {

    List<Tuple2<Long, Long>> edges = new ArrayList<Tuple2<Long, Long>>();
    for (Object[] e : EDGES) {
      edges.add(new Tuple2<Long, Long>((Long) e[0], (Long) e[1]));
    }
    return env.fromCollection(edges);
  }

  public static DataSet<Long> getDefaultPagesDataSet(ExecutionEnvironment env) {
    return env.generateSequence(1, 15);
  }

  public static int getNumberOfPages() {
    return numPages;
  }

}

是不是很简单，大家可以自己搞个案例测试一下哦～



更多flink学习视频和教程，欢迎加入浪尖知识星球～




微信扫一扫
关注该公众号