从Flink 1.16.0开始集成了SQL Gateway功能，提供了多种客户端远程并发执行SQL的能力。不用再使用提交jar包的方式来创建任务了。
我是使用filnk 1.17.1版本。
官网关于SQL Gateway的讲解：https://nightlies.apache.org/flink/flink-docs-release-1.17/zh/docs/dev/table/sql-gateway/overview/
SQL Gateway提交作业的执行后端可以是Flink的standalone集群或者是Yarn集群。
我这里的环境是standalone，然后我只用了一台机器，主要是为了测试SQL Gateway提交SQL Job
flink下载解压到服务上之后就可以启动了。在主节点执行$FLINK_HOME/bin/start-cluster.sh，启动集群。
关闭standalone集群可以执行$FLINK_HOME/bin/stop-cluster.sh。
集群成功启动之后可以接着启动sql-gateway。执行：
$FLINK_HOME/bin/sql-gateway.sh start -Dsql-gateway.endpoint.rest.address=xxx.xxx.xxx.xxx
其中-Dsql-gateway.endpoint.rest.address用来指定SQL Gateway服务绑定的地址。注意如果指定为localhost则SQL Gateway只能通过本机访问，无法对外提供服务。可以设置成0.0.0.0。SQL Gateway服务日志文件在$FLINK_HOME/log目录中。
可以执行$FLINK_HOME/bin/sql-gateway.sh -h获取sql-gateway.sh命令更多的使用方式
Usage: sql-gateway.sh [start|start-foreground|stop|stop-all] [args]
commands:
start - Run a SQL Gateway as a daemon
start-foreground - Run a SQL Gateway as a console application
stop - Stop the SQL Gateway daemon
stop-all - Stop all the SQL Gateway daemons
-h | --help - Show this help message
SQL Gateway 配置
可以通过如下方式动态指定SQL Gateway的配置项
$ ./sql-gateway -Dkey=value
官网给出的配置项列表如下：
KeyDefaultTypeDescription
sql-gateway.session.check-interval
1 minDuration定时检查空闲 session 是否超时的间隔时间，设置为 0 时关闭检查。
sql-gateway.session.idle-timeout
10 minDurationsession 超时时间，在这个时间区间内没有被访问过的 session 会被关闭。如果设置为 0，session 将不会被关闭。
sql-gateway.session.max-num
1000000IntegerSQL Gateway 服务中存活 session 的最大数量。
sql-gateway.session.plan-cache.enabled
falseBoolean设置为 true 的时候，SQL Gateway 会在一个 session 内部缓存并复用 plan。
sql-gateway.session.plan-cache.size
100IntegerPlan cache 的大小, 当且仅当 table.optimizer.plan-cache.enabled 为 true 的时候生效。
sql-gateway.session.plan-cache.ttl
1 hourDurationPlan cache 的 TTL, 控制 cache 在写入之后多久过期, 当且仅当 table.optimizer.plan-cache.enabled 为 true 的时候生效。
sql-gateway.worker.keepalive-time
5 minDuration空闲工作线程的存活时间。当工作线程数量超过了配置的最小值，超过存活时间的多余空闲工作线程会被杀掉。
sql-gateway.worker.threads.max
500IntegerSQL Gateway 服务中工作线程的最大数量。
sql-gateway.worker.threads.min
5IntegerSQL Gateway 服务中工作线程的最小数量。
Rest API
前面部署过程中SQL Gateway默认是以Rest API的形式提供服务，这里直接讲解使用方式。假设在我们的测试环境SQL Gateway运行的IP和端口为sql-gateway-ip:8083。
首先执行：
curl --request POST http://sql-gateway-ip:8083/v1/sessions
创建并获取到一个sessionHandle。示例返回如下：
{"sessionHandle":"2f35eb7e-97f0-40a4-b22d-f49c3a8fe7ef"}
然后以执行SQL SELECT 1语句为例。格式为：
curl --request POST http://sql-gateway-ip:8083/v1/sessions/${sessionHandle}/statements/ --data '{"statement": "SELECT 1"}'
我们替换sessionHandle为上面返回的sessionHandle，实际命令如下：
curl --request POST http://sql-gateway-ip:8083/v1/sessions/2f35eb7e-97f0-40a4-b22d-f49c3a8fe7ef/statements/ --data '{"statement": "SELECT 1"}'
得到的返回值包含一个operationHandle，如下所示：
{"operationHandle":"7dcb0266-ed64-423d-a984-310dc6398e5e"}
最后我们使用sessionHandle和operationHandle来获取运行结果。格式为：
curl --request GET http://sql-gateway-ip:8083/v1/sessions/${sessionHandle}/operations/${operationHandle}/result/0
其中最后一个0为token。可以理解为查询结果是分页（分批）返回，token为页码。
替换sessionHandle和operationHandle为前面获取的真实值，实际命令如下：
curl --request GET http://localhost:8083/v1/sessions/2f35eb7e-97f0-40a4-b22d-f49c3a8fe7ef/operations/7dcb0266-ed64-423d-a984-310dc6398e5e/result/0
得到结果如下：
{"results":{"columns":[{"name":"EXPR$0","logicalType":{"type":"INTEGER","nullable":false},"comment":null}],"data":[{"kind":"INSERT","fields":[1]}]},"resultType":"PAYLOAD","nextResultUri":"/v1/sessions/2f35eb7e-97f0-40a4-b22d-f49c3a8fe7ef/operations/7dcb0266-ed64-423d-a984-310dc6398e5e/result/1"}
我们从result -> data -> fields 可以得到SELECT 1的运行结果为1。
前面提到token的作用类似于分页。上面JSON的nextResultUri告诉我们获取下一批结果的URL。发现token从0变成了1。我们访问这个nextResultUri：
curl --request GET http://localhost:8083/v1/sessions/2f35eb7e-97f0-40a4-b22d-f49c3a8fe7ef/operations/7dcb0266-ed64-423d-a984-310dc6398e5e/result/1
返回如下内容：
{"results":{"columns":[{"name":"EXPR$0","logicalType":{"type":"INTEGER","nullable":false},"comment":null}],"data":[]},"resultType":"EOS","nextResultUri":null}
可以看到resultType为EOS，表示所有结果都已经获取到了。此时nextResultUri为null，没有下一页结果。
版权归原作者 Denny辉 所有， 如有侵权，请联系我们删除。