目前网易流计算规模已经达到了一千多个任务，2 万多个 vcores 以及 80 多 T 的内存，网易流计算覆盖了绝大多数场景，包括广告、电商大屏、ETL、数据分析、推荐、风控、搜索、直播等。
摘要：本文由网易 Java 技术专家吴良波分享，主要内容为 Apache Flink 在网易的实践，文章提纲如下：
- 业务与规模演进
- Flink 平台化
- 案例分析
- 未来发展与思考
一、业务与规模演进
网易流计算演进
在很久以前，网易内部基本上都是使用 Storm 来处理实时的计算任务，比较主要的使用场景是实时邮件反垃圾，广告，新闻推荐等业务。如今内部仍有一部分任务是运行在 Storm 上，目前正往 Flink 上迁移。
- 16 年左右 Flink 社区在网络上逐渐开始火起来，网易这边开始调研 Flink，发现 Flink 具有很多优秀的特性，比如高吞吐、低延迟、支持 Checkpoint、支持 Exactly once 语义，支持 Event time 等，能够很好的满足业务实时计算的场景，因此很多项目开始使用 Flink 来作为流计算的引擎来搭建流计算平台。
- 在 2017 年 2 月份，网易杭州研究院成立了一个代号为 Sloth 的项目，基于 SQL 的实时计算平台，底层计算引擎采用 Apache Flink。
但是这套系统做的并不是很成功，一方面是因为平台化，产品化做的不是很到位，用户使用起来不是很方便，SLA 也没有得到很好的保障。另一方面对 Flink 底层的代码改动较大，导致后面跟不上社区的节奏。于是在今年年初对系统进行重新改造，重新拥抱社区，在 SQL 方面采用了阿里巴巴年初新开源的 Blink，使用 Blink 来提交 SQL 任务，同时支持用户直接写 JAVA 代码来提交流计算任务，方便那些有开发能力的同学开发 Flink 任务。
网易杭研在做流计算平台的同时，公司一些大的业务方也在开发自己的流计算平台，这样一来就造成了公司很大的资源和人力上的浪费。为了整合公司资源，以及应对各个业务不断增长的实时计算任务的需求，决定和各个业务方一起共建分布式的实时计算平台，将业务方的任务全部迁移到新的分布式实时计算平台上，杭研负责底层平台和接口的研发与维护，业务方则更加关注业务本身。
基于流计算的业务规模
目前网易流计算规模已经达到了一千多个任务，2 万多个 vcores 以及 80 多 T 的内存。
业务场景
目前网易流计算覆盖了绝大多数场景，包括广告、电商大屏、ETL、数据分析、推荐、风控、搜索、直播等。
二、Flink 平台化
平台架构演进-Sloth 0.x
在 2017 年初的时候,因为当时社区版本的 Flink 对于 SQL 的支持不是很完善，所以 Sloth 平台自定义了 SQL 规范，自己实现了 DDL 等。但当时这个平台的架构存在很多问题，特别是版本升级的时候，代码迁移等的工作量非常大，运维起来也非常困难。另外当时实时计算只是作为离线计算平台的一个功能模块，因此 Sloth 的前端是和离线平台绑定在一起的，实时计算模块前端每次升级发布都需要和离线计算平台一起，非常不方便。
平台架构演进-Sloth 1.0
在 Sloth 的 1.0 版本中，Flink 版本实现了插件化管理，每次 Flink 升级的时候就不需要进行复杂的代码合并工作了，这一点主要通过父子进程架构来实现的。此外，Sloth 1.0 版本的运维方便了许多，并且也支持 jar 包任务开发，用户可以直接通过 Stream API 来写流计算任务。Sloth 的 1.0 版本还支持了阿里巴巴开源的 Blink SQL，并且在监控方面还接入了 Grafana，任务 metrics 存储则使用了网易自研的时序数据库 Ntsdb。
平台架构演进-Sloth 2.0
在 Sloth 的 2.0 版本中，实现了平台的 PaaS 化以及平台的高可用。Sloth 平台提供对外的平台 API，Sloth 开发了一套独立部署的前端界面，同时业务方也可以开发跟自己业务更为紧密的前端界面，通过平台的 API 来提交任务以及后续的任务运维等等。
以前的计算平台都是单点的，都是部署在同一台服务器，一旦服务器出了故障，整个平台就挂了，所以 Sloth 2.0 设计成分布式的，可以部署多个 Server，使用 Nginx 作为负载均衡器，来达到系统的高可用。同时支持了更多的 Flink 版本，因为各个业务以前用的版本都可能不一样，为了将任务直接迁移过来，需要支持这些历史的版本，所以平台支持了 Flink 1.5、Flink 1.7、Flink 1.9 和 Blink 等多个版本。
平台模块图
下图所示是 Sloth 的模块图。在 Web 端，业务方可以搭建自己的任务管控平台 Web，业务方所需要的前端平台可能和公用 Sloth 的前端平台不同，业务方内部还包括各种不同的部门，他们需要对于各个部门的用户权限进行控制等。Sloth-Server 模块，包括用户的权限管理，会话管理，任务开发，元数据管理，任务运维，标签管理，内核调度，文件管理。Sloth-Bill 模块主要是对资源以及用量的统计，Sloth-admin 模块包括监控，报警，任务恢复，以及任务诊断。Sloth-Kernel 模块负责任务执行、语法检测以及 SQL 调试。
事件管理
对于分布式平台的任务操作而言，当前任务只允许一个人操作，而不允许两个人同时操作，这就需要以下几个模块来共同配合：
- Server：事件执行的发起者，接受事件的请求，进行数据校验，拼装，将事件发送给 Kernel 执行。
- Kernel：事件具体逻辑的执行者，根据请求向集群发送指令(Shell 脚本方式)。
- Admin：事件执行结果的确认者，根据事件类型，获取事件的最终结果，保证结果的正确性。
以启动场景为例：
- 首先，Server 会接收到来自用户的启动请求，之后会创建一个分布式锁，Admin 会监控这个锁。
- 然后， Server 向 Kernel 提交任务，提交之后会立即返回，返回之后就会立即更新数据库中的状态，将状态更新为启动中，这样在页面上用户就能够看到任务是启动中的状态了。
- 接下来，Server 就会等待内核的 Shell 脚本的执行结果，如果 Shell 脚本执行成功了，就会去写 Zookeeper，写完 Zookeeper 之后 Admin 模块就会马上检测到 Zookeeper 节点有状态发生了修改，Admin 会立即去获取 YARN 上的任务状态，如果获取到任务状态是运行中，就将数据库的任务状态更新为运行中，这会在前端看到任务就已经是运行状态了。
- 最后一步是 Admin 更为完数据库之后，会释放掉 Zookeeper 上的锁，其他人这时候就可以操作这个任务了。
Server、Kernel 和 Admin 这三个模块都是不可靠的，那么如何保证其稳定和高可用呢？Server 可以通过部署多个，水平扩展来实现，Kernel 则会由 Server 来进行监听，当发现 Kernel 挂了，可以由 Server 重新拉起或者重新创建。而 Admin 的高可用则是通过热备来实现的，如果主 Admin 挂掉了，可以马上迁移到备 Admin，备 Admin 可以迅速将元数据以及任务信息全部加载进来接替工作，进而实现高可用。
内核调度
对于内核调度而言，是基于父子进程的架构实现的。Server 会通过 Sloth RPC 启动不同的 kernel 子进程，分为常驻子进程模式和临时子进程模式。常驻子进程负责处理启动，停止，语法检查，表结构解析，获取提交结果的请求，临时子进程是用于 SQL 的 Debug 的，当调试完成需要将这个子进程关闭掉，将资源进行回收。内核通过子进程来实现的好处在于当 Kernel 挂掉的时候，Server 可以通过监听自动拉起来。
平台任务状态图
平台的任务状态主要由 Server 和 Admin 来控制。Server 主要控制初始状态的执行，Admin 则主要负责控制所有与 YARN 相关的状态交互。
任务开发
任务开发的界面支持的功能主要有：任务调试、任务 Tab 页、语法检查、任务标签、元数据管理、用户资源文件管理以及任务复制等。
Blink SQL
扩展完善了 Blink 对维表 Join 的支持，以及如 HDFS、Kafka、HBase，ES，Ntsdb，Kudu 等 Sink 端的支持。
任务调试
SQL 类型的任务支持调试功能，用户可以根据不同的 source 表和 dim 表，上传不同的 csv 文件作为输入数据，进行调试。调试执行由指定的 kernel 来完成，sloth-server 负责组装请求，调用 kernel，返回结果，搜集日志。
日志检索
在 YARN 集群的每个节点上面部署 Filebeat，通过 Filebeat 将节点上面的任务日志写入到 Kafka 消息队列中，然后通过 Logstash 进行解析处理，之后写入 ES 集群中。主要用于两个用途，一个是通过界面 Kibana 来提供给开发和运维人员使用，另外一个就是将运行时状态的任务日志直接在界面上展示供用户进行搜索和查看。
监控
在监控方面，使用的是 influxdb metric report 组件对于指标进行监控。时序数据库使用的是网易自研的 ntsdb 时序数据库，其能够支持动态扩展和高可用等功能。监控指标的使用方式有两种：
- 一种是通过 Grafana 的界面来查看指标；
- 另外一种是报警模块会从Ntsdb中获取相关指标数据并进行监控报警。
报警
Sloth 流计算平台支持常见的任务失败，数据滞留延迟，failover 报警，也支持用户自定义规则报警，包括对于输入 QPS、输出 QPS，户自定义延迟的监控等。以输入 QPS 为例，可以设置当连续几个周期内 QPS 低于某一值时就触发报警。此外，报警方式也支持多样化的工具，比如各种网易内部的聊天工具、邮件、电话以及短信等，对于任务调试阶段，为了避免被骚扰，可以设置任务报警抑制时间间隔。
三、案例分析
数据实时同步
AI 智能对话服务场景中，客户在前端配置知识库数据，通过 Sloth 实时处理后，写入到 ES 中供查询场景使用。
实时数仓
目前网易很多产品已经开始实时数仓的建设了，但仍旧处于持续完善过程中。实时数仓的建设和离线数仓大致相同，只不过实时数仓是经过实时计算平台进行处理的。大致的过程就是首先收集日志、埋点数据等，将其写入到 Kafka 里面，经过实时计算平台进行处理，将 ODS 层中的明细数据抽取出来，在进行汇总以及维度关联等操作，将结果写入到 Redis，Kudu 等，再通过数据服务提供给前端的业务使用。
电商应用-数据分析
电商的数据分析场景主要包括实时活动分析、首页资源分析、流量漏斗以及实时毛利计算等。简要的逻辑就是从 Hubble 收集用户的访问日志推动到 Kafka，使用 Sloth 清洗出明细层，写入 Kafka，再用 Sloth 任务，关联维度，实时写入 Kudu，落入 Kudu 表的数据，一方面可以提供给业务方使用，分析师可以开发实时查询；另外一方面，可以在这个实例的 Kudu 表上面，提供给数据应用。
电商应用-搜索推荐
电商的搜索推荐场景则主要包括用户实时足迹、用户实时特征、商品实时特征、实时 CTR CVR 样本组建、首页 A 区轮播、B 区活动精选等 UV、PV 实时统计等。简要的逻辑就是使用 Sloth 读取应用日志，进行数据清洗和维度拆分，写入 Kafka，再使用 Sloth 读取 Kafka 的数据，实时统计多维特征，实时统计多维特征 5min、30min、1 小时的 PV 和 UV，写入 Redis，供线上工程计算 CTR、CVR 以及优化搜索和推荐结果。
四、未来发展与思考
网易在流计算方面对于未来发展的思考主要包括以下五点：
- 实时计算平台支持 Flink On K8S 的任务
- 任务的自动配置功能，平台能根据业务类型，流量自动配置内存，并发度等，既保证业务 SLA，也能提升计算集群的资源利用率。
- 智能诊断，对 UDF 以及代码构建的流计算任务，调试成本高，运行出错让业务和平台方疲于奔命，智能诊断是流计算平台根据任务的各种 Metric 信息，直指问题所在，减少业务和平台定位问题的时间，对于存在风险的任务，可以提前给出预警，并对调优给出建议。
- 关注 Flink 1.9 后续对于 SQL 的支持，以及 Flink 批流统一。
- 更多地参与到社区中去。
作者介绍：
吴良波，网易 JAVA 技术专家，2011 年加入网易后从事 JAVA 后台系统的研发，如网易邮件反垃圾系统，网易分布式云爬虫系统等，目前负责网易实时计算平台的研发。