不写代码 玩转大数据实时计算

Flink SQL 是当今大数据实时计算领域最主流的开源引擎 Flink 的高级用户接口，通过熟悉 Flink SQL 的特性和场景，不用了解太多大数据与实时计算复杂概念，即可使用大数据实时计算技术为业务赋能。

Flink 是第三代大数据流计算，相比第一代流计算引擎 Storm 以及第二代流计算引擎 Spark Streaming ， Flink 在各个方面都有巨大的优势，在保证了“仅有一次”处理语义的同时还能保证高吞吐和低延迟，如下表。

流计算引擎

准确性

容错机制

延时

吞吐量

易用性

扩展性

业界使用

Flink

Exactly-once

轻

ms

高

高

好

高

Spark  Streaming

Exactly-once

重

s

高

中

好

中

Storm

At-least-once

重

ms

低

低

一般

低

由于 SQL 是数据处理中最广泛使用的语言，为简化 Flink 的用户接口， Flink 推出了 Flink SQL 来增强在数据处理中的便利性。利用 Flink SQL 来进行大数据实时计算，至少具有以下四个明显优势：

语言无关 ，无需了解 Java 、 Scala 或者 Python 等语言，会使用 SQL 语言即可。

依赖无关 ，无需了解背后的依赖关系和集群版本，方便集群升级和运维。

使用简单 ，无需了解引擎内部的各种概念，可专注 SQL 表达业务。

最佳实践 ， SQL 到作业的真正提交过程中，会经过优化处理，自动适配业界最优方案。

Flink 是流计算引擎， Flink SQL 自然是流计算之上的 SQL 表达，既有一般 SQL 语言的基础特性，也包含流计算中的专门特性。

• DDL 支持，支持 catalog ， database ， table ， view 和 function 这些对象的 create 、 drop 和 alter 能力，支持 SQL hints 给执行计划传递额外信息，支持 explain 查看相应的 SQL 的物理执行计划。

• Function 支持，提供了很多的内置函数，日常能用到的业务无关的函数基本都提供了，比较函数、逻辑函数、数学函数、字符串函数、类型转换函数、分组函数、聚合函数等。

•   UDF 支持，支持四种用户自定义函数，标量函数、表函数、聚合函数、表聚合函数。

  

• 时间语义支持，支持处理时间、摄入时间和事件时间，扩充的时间语义是对传统 SQL 的丰富，特别是事件时间的支持，能够更好的支持业务逻辑贴近业务实际。

• 时间窗口支持，支持翻滚窗口、滑动窗口和会话窗口，对窗口的表达也是对传统 SQL 的扩充，消息只会在一个翻滚窗口中出现，可能在多个滑动窗口中出现，只在一个会话窗口中出现。

• 模式匹配支持，因为 Flink 本身提供复杂事件处理的 CEP 库，所以也扩充了 SQL 中模式匹配的语义，通过 SQL 语言就可以在流计算中实现复杂事件处理。

• 内嵌 connector ， FlinkSQL 内嵌很多 connector 来和外部数据源连接，常用的包括 Kafka ， HBase ， ES ， JDBC 以及 FileSystem ，并且 FileSystem 支持多个文件格式，特别是对 parque 和 orc 的支持，并提供 datagen ， print ， blackhole 进行调试。

作为 Flink SQL 的底座， Flink 本身有着丰富的使用场景， Flink SQL 基本继承了 Flink 的使用场景，这里着重介绍三种 Flink SQL 的使用场景。

数据同步

SQL 的原意即为结构化查询语言，适合在不同的 schema 之上的关系代数运算，经过不同的投影、映射、筛选、变换、聚合等操作来从一个 schema 变换为另一个 schema ，这种表达落实在 flink SQL 上，即为将一个表经过一系列变换转变为另外一个表，而每个表可以代表一个外部的存储系统。

在司内业务中，存在很多从业务数据库 MySQL 到大数据生态的数据同步， Flink SQL 特别对这个场景进行了重点支持，并且 Flink SQL 支持两种模式的 MySQL 的数据同步。

如上图，第一种即是传统的经过一个 CDC 捕获中间件 Debezimu 或者 Canal 来实现从 MySQL 服务器到 Kafka 的 binlog 传递， Flink SQL 从 Kafka 接入数据，经过处理落入各种存储。

如上图，第二种省去了 CDC 捕获中间件以及 Kafka ， Flink SQL 可以直接将 Binlog 日志作为数据源来读取，大大的减少了链路的复杂和延迟。

批流融合

谓所批流融合，指的在一个流计算过程中同时集成了批计算的过程。典型场景如实时数仓中的维度扩充过程，事实表的数据作为流数据会持续不断进来，但作为用户信息或者商品品类表等维度信息可能存在于 MySQL ，需要在计算的过程中将事实表的数据与 MySQL 中的信息关联，实现维度扩充。

在 Flink 的 DataStream 编程模型中，用户需要自己考虑如何实现两个流的关联与对齐等操作，但在 Flink SQL 中，事实表和维度表投统一在表的概念下，只需要在两个表之上进行 join 的操作，即可实现流与批的融合，用户无需了解后台的数据存取和更新逻辑。

HIVE整合

在大数据离线数仓以及数据处理的实践中， HIVE 无疑占有特殊的地位，所以 Flink SQL 1.11 版本的一大特性即为与 HIVE 的整合，包含以下两大特性：

技术栈支持 ， Flink SQL 支持使用 HIVE Metastore 作为元数据管理中心，支持在 Flink SQL 中使用 HIVE SQL 的 DDL 方言，支持在 Flink SQL 中使用 HIVE 的内嵌函数以及 UDF 。

客户端支持 ，支持 HIVE 的多个主流版本，支持流式或者批式的读取 HIVE 数据，包括读取分区，写分区、提交分区等操作。

利用 Flink SQL 提供的与 HIVE 交互的能力，叠加 Flink 的仅有一次语义和作业容错处理，以往的 HIVE 批量调度作业就有了转向实时处理的可能。通过离线转实时，至少带来如下好处：

数据延迟大大减少 ，离线操作一般是 T+ 1 操作，并且如果上游数据迟到，或者某步骤运行出错导致的重跑，都会对下游的处理带来很大的影响，改为实时后，上游数据迟到能够被及时发现，运行出错得益于 Flink 的 Checkpoint 机制，影响可控，整个链路上的数据产出延迟大大降低。

资源使用大大减少 ，在离线处理中单个步骤因为要在短时间内处理全量的数据，所以需要的计算资源会比较大，如果集群中同时运行多个离线报表任务，对整个集群资源要求很高，改为实时后，短时间内处理的数据平均到一天 24 个小时中去处理，对作业计算资源要求将大大降低，并且整个集群的资源要求也会降低并在时间维度上充分利用。

Flink SQL 在场景化上提供了很强的能力，但是在实际的使用之中，还存在一些问题，比如客户端不支持并发操作，不支持 SQL 作业的细粒度并发设置，作业提交速度比较慢以及与司内 Hadoop 环境适配等问题，针对于此，系统部做了很多的功能增强以及产品化的工作。

功能增强

在 Flink SQL 的功能增强上，主要是着眼于提供易用性和与司内环境的适配。举例说明如下：

1. 静态资源加速，通过静态资源加速功能，作业提交的速度可以从分钟级提高到秒级。

2. 细粒度并发设置，改变 Flink SQL 本身只支持全局设置并发，可以针对算子设置并发。

3. 数据源格式适配，维护开发社区缺失的数据源 Format ，简化司内业务处理。

4. Kafka 版本支持， Flink 1.11 版本放弃对 Kafka 08&09 的支持，继续维护开发司内 09 版本。

5. 函数状态提升，维护开发司内 Flink SQL 的 UDF 版本，支持对 Flink 状态的访问能力。

连续语言处理，围绕 Flink SQL Client 连续语言处理、 Savepoint 机制以及运行时参数化能力

产品化

Flink SQL 产品化，依托于系统部推出的大数据服务一体化平台——奇麟。奇麟对 Flink SQL 提供了作业前、开发作业、作业后三个阶段的管理支持。

作业前 ，在开发 Flink SQL 作业之前，需要做两件事，即建表和创建 UDF ，表的定义在元数据管理中， UDF 的定义在 UDF 管理中，通过表的定义和 UDF 的定义，有利于实现表资源和 UDF 资源的复用以及 SQL 作业开发的可视化。

开发作业 ，开发作业即依托于表的关系代数运算以及 UDF 的业务表达来实现，不建议写非常复杂的 SQL 语句，可通过 SQL 语句的拆分，比如通过多个 view 的创建，来减少 SQL 语句的复杂度。

作业后 ，主要指作业运行和作业管理的高级配置，比如作业运行时的资源配置，以及作业监控报警拉起的策略等，保证作业运行的 SLA 。

通过 奇麟 提交 Flink SQL 作业，对用户屏蔽了客户端搭建、依赖管理等等繁琐流程，用户只需点点点就可以完成作业的开发，奇麟的地址为 http://qilin.qihoo.net/ ，欢迎使用。

往期精彩回顾

kubernetes之flannel 网络分析