互联网的高速发展使得对数据实效性的要求越来越高，基于数据流的流计算越来越重要。以Flink为代表的新一代流计算引擎以其高吞吐、低延迟、checkpoint、state、time、window等特性方便了我们对数据流的高效处理。

Flink是一个框架和分布式处理引擎，用于对无界和有界数据流进行状态计算。Flink起源于德国柏林工业大学的一个研究项目Stratosphere，Flink从Stratosphere的分布式执行引擎开始，并于2014年3月成为Apache Incubator项目。2014年12月，Flink成为Apache顶级项目。

Why flink

high throughput & low latency。流计算任务对吞吐和延迟有着很高要求，Spark Streaming通过微批去实现流处理，而Flink是纯流式计算的思路，可以满足高吞吐和低延迟。

图1 latency对比

图2 throughput对比

state & checkpoint。流计算任务中state管理是非常重要的一部分，在Storm等框架中需要开发人员自己去管理state，同时Storm不支持批计算，而Flink 能够支持批流统一。Flink通过内置的state使得我们可以像使用集合类一样方便进行状态操作，同时得益于checkpoint机制，通过Chandy-Lamport算法产生一个分布式快照，保证了exactly-once并可以进行快速的故障恢复。

time & window。现在流处理中，对time的支持必不可少，Flink中,processing time表示处理消息的时间、event time表示流数据中包含的业务时间时间、ingestion time表示进入到系统的时间。watermark也是一个很关键的概念。基于event time必须指定如何生成事件watermark，这是表示事件时间进度的机制。通过watermark声明不会再有任何小于该watermark的时间戳的数据元素到来，即使一些事件延迟到达，也不至于过于影响窗口计算的正确性。watermark很好的解决了event time乱序的问题。此外，Flink还提供了一套便捷的窗口操作包括滚动窗口、滑动窗口、会话窗口。

流计算开发平台

大搜车旗下包括车易拍、车行168、运车管家、布雷克索等公司，以及深度战略合作的长城汽车、长安汽车、英菲尼迪等主机厂商，以及与中石油昆仑好客等产业链上下游的合作伙伴。

Flink在大搜车各个业务域有着广泛的应用，如日志分析、物联网、实时数仓等。大搜车基于Flink的流计算的开发平台，经历了从小到大的历程。

整体架构

图3 大搜车流计算平台架构

统一脚手架

最初各个任务是自己创建maven工程，过程中发现开发人员需要花大量时间去结果依赖冲突的问题，同时线上会出现由于版本带来的各种问题。为了解决这个问题，我们提供maven 提供的脚手架创建一个任务模板。生成的作业模板 pom.xml 已经将Flink相关的依赖进行了处理。

mvn org.apache.maven.plugins:maven-archetype-plugin:2.4:generate \
-DarchetypeGroupId=com.souche \
-DarchetypeArtifactId=jingwei-quickstart \
-DarchetypeVersion=1.1.0-SNAPSHOT

开发人员无需再花时间处理依赖冲突，也方便后续Flink版本的升级。同时我们对Flink中的常见source及sink，如kafka、mysql，进行了封装，开发人员通过简单配置即可接入数据源，对于kakfa还可以通过统一参数管理进行offset重置进行任务重跑，此外在任务Dispatcher中配置任务重启策略等。

统一工作台

最初我们依赖Flink Web工作台进行，随着业务量的增加，我们发现诸多不便，对于权限管理、任务版本、执行savepoint等功能不能很好支持，因此我们开发了一个统一的流计算工作台（精卫）。包含如下功能：

任务运行/恢复
版本管理
任务暂停（savepoint）
权限管理
日志查询
运行监控

图4 任务开发

图5 版本管理

SQL开发

Java API的问题

开发效率及成本

通过Java API基于DataStream开发流计算任务，通过脚手架解决了依赖冲突的问题，但是开发人员还是要通过flatmap、filter、keyby、window等Operator去开发流计算任务，同时要经过打包，上传及发布等流程，调试过程中出现问题需要重新执行上述流程，这便造成了流计算任务开发缓慢、效率低下的问题。开发周期长，一个开发人员很难同时维护多个任务。

维护成本

同时任务一旦出现问题，平台开发运维人员不了解具体业务，不能快速处理问题，往往需要查看业务源代码来进行问题定位和处理。

SQL的重要性

如何解决这些问题，能提升开发人员的效率，并减少平台方的运维成本？SQL是一个很好的解决方案。SQL语言是一个高级的非过程化语言，1974诞生至今，经久不衰，语言简洁，在开发人员、DBA、数据分析师中都有着良好的基础。同时我们看到在大数据离线处理领域，也经历了MapReduce到Hive的发展过程，当下Hive以其快速、高效、易于维护的特性已经成为数据仓库的重要组成部分。因此支持Flink SQL开发流计算任务变得尤为重要。

我们知道SQL是作用于关系表的，流计算是对流数据的处理，为什么可以用SQL开发流计算任务？回答这个问题，就要提到流与表的等价性。以Mysql和Binlog为例，Mysql的对表的操作会通过Binlog形成携带时间的数据流，主从同步中会通过对Binlog数据流的处理形成一张表。因此，流与表是等价的，流跟表可以进行互转，因此作用于关系表的SQL可以适用于流计算中。

SQL实践

Flink当前版本（1.8）对DDL、维表join等功能尚不完善，同时内置UDF少、connector少，开发SQL任务繁琐，没法做到百分百SQL开发流计算任务。阿里巴巴开源的BLink对DDL、维表join、UDF等功能有了很大的增强，对于connector和SQL任务提交等功能开源版本尚不完善。为了解决能够实现完全SQL开发流计算任务，我们对SQL任务提交接口和connector进行了扩展。通过实现 sql-client 中的 Executor 实现了SQL任务的Rest接口，并提供参数配置、Savepoint等功能。通过实现 StreamTableSink 、 StreamTableSourceFactory
、 LookupableTableSource 等接口实现了自定义connector及维表join功能。

图6 维表时序图

以此，实现了以Flink SQL方式提供平台化服务。通过SQL语言优势降低了业务开发成本，提升了开发效率，减少运维成本。原来需要两周的任务，三天既可以上线，上百行的Java代码，可以缩减到几十行SQL脚本。出现问题后，平台开发人员可以快速定位和解决问题。

图7 SQL任务开发与运行

运维监控

监控报警

流计算任务不同于离线任务，对数据的实时性要求很高，一旦任务出现异常，出现数据堆积将直接影响下游应用，因此流计算任务的监控报警极为重要。大搜车基于Flink Metrics并在关键节点（source、sink）开发了自定义监控指标，通过Prometheus+Grafana实现了对Flink集群的监控及Flink Job的监控Dashboard。同时对任务状态、集群资源等关键指标进行了报警规则的配置，确保平台开发人员可以第一时间获取集群异常信息。

图8 Flink job监控

Flink on yarn

Flink支持standalone和yarn/k8s等模式，大搜车包括多个工作域，出于业务的需求要进行资源隔离，yarn模式可以实现对资源的隔离，同时资源按需使用提升资源率。

日志采集

通过Flink Web工作台可以方便的查看日志，但是如果日志过多则会出现加载缓慢甚至页面Crash。可以通过修改conf下日志配置进行按日滚动和日志拆分，大搜车在实践过程中，会将Flink应用日志通过Flume进行采集对接日志平台，方便开发人员定位问题。

远程调试

Flink是运行在JVM上的，因此可以通过配置相关参数进行remote debug。

export JVM_ARGS="-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=5005"

再通过IDE新建remote

图9 远程调试

Checkpoint
checkpoint的时间间隔不要太小，分钟级别即可。

//interval 5min
env.enableCheckpointing(1000 * 60 * 5);

后期规划

SQL任务可视化调试
任务血缘关系分析

作者简介：
张迪，大搜车基础架构部资深数据研发工程师，现负责大搜车流计算平台的建设与研发。

本文转载自公众号大搜车TED技术沙龙（ID: souchedata）。

原文链接：https://mp.weixin.qq.com/s/KVmS0ZToSxlrpdTtclOj4A

创作场景

Flink 在大搜车流计算的探索与实践