一、实时计算平台演进

1. 历史进程

• 2013年，以Storm 0.8为基础构建实时计算平台。
• 2018年，以Flink 1.4为基础构建实时计算平台。
• 2020年，以Flink 1.11为基础构建实时计算平台，并全面拥抱SQL。

奇虎360在实时计算方面有很强的积累。在2013年开始使用Storm 0.8版本来构建公司内部的流计算平台，包括早期跟Storm社区也有很多的交流和贡献。虽然Storm作为第一代流行的流计算引擎而得到了广泛的使用，但其自身在资源亲和性、消息处理语义、框架吞吐能力等方面存在固有的不足。Flink作为最新一代的流计算引擎，在2018年发布1.4版本后，运行时和API都基本达到了线上应用的标准。所以在2018年，开始基于Flink 1.4版本构建新的实时计算平台，并在公司内部得到了大量的使用。得益于Flink社区的快速发展，特别是Flink SQL在Flink 1.11的成熟，在建设Qilin大数据平台的时候，对实时计算平台的各项功能进行重构，并将Flink的版本切换到了1.11。

2. 当前现状

目前在奇虎360内部Flink支撑了绝大多数实时计算任务的运行，从团队来看，超过50个业务线使用实时计算平台，包括360搜索、花椒、360金融、360导航等等，各业务线每天通过实时计算平台处理的数据量超过了10000亿条。

二、基于Flink的实时计算平台

1. 一代平台Hermes

Hermes是第一版的基于Flink的实时计算平台，对于早期Flink作业的支撑起了非常大的作用。Hermes基本包括了一个平台应该有的大部分功能，客户端接口hermes，中控服务control center，作业提交网关的gateway，作业依赖管理，服务发现与高可用，另外也同时提供了作业诊断与分析、监控和报警等服务。

2. 二代平台Qilin

由于Hermes只能支持Flink任务的相关支撑工作，无法与其他大数据组件相协同，因此在2020年我们基于Flink 1.11开始构建新一版的实时计算平台Qilin。

在第一版hermes的基础上做了很多改进：首先，在客户端以web为主的前提下，提供了api和cli两种更多的接入方式；其次，在中控服务中，基本都采用了无状态服务，满足了master和worker节点的任意水平扩展，保障服务的高可用；再者，平台操作全面异步化，极大的改善了用户体验。其他诸如文件中心，UDF市场，实现了任务依赖和任务定义的解耦。 

中台部门的一个永恒命题就是降本增效，所以这一版，我们完全重构了作业诊断分析模块，重新实现了一版任务分析系统，能够在最快的时间内在尽量多的维度上定位作业问题、提升作业运行效率、保障作业的稳定性。

三、Flink在奇虎360的典型场景

奇虎360实时计算团队以促进业务发展为导向，以引擎的稳定和高效为基础，在Flink内核和生态上做了大量的研发工作，这里以两个例子作为说明。

1. 结合Hyperscan加速正则效能提升

1）问题域

日常帮用户诊断作业运行问题的时候，经常会发现作业的瓶颈在于字符串的java原生的正则匹配效能低下，导致作业运行缓慢，频繁反压。当这样的case总是出现以后，我们调研是否可以在框架层面帮用户解决这个问题。在一些典型安全场景下，正则匹配不是业务逻辑前奏，而成了业务逻辑本身，做好正则匹配本身，就是对业务计算的强力支撑 。此外，正则匹配的效能提升，也希望是可以水平扩展的，这样才能在超大数据量下，保证计算的吞吐足够大。

2）解决方案域

正则匹配效能提升是基于Hyperscan所构建一套解决方案。Hyperscan是基于PCRE所构建的支持块模式和流模式的正则匹配库，由于其支持的规则具有特定的标准，所以在运行之前，需要将规则进行转换和编译，形成特定的规则数据库。

同时对Hyperscan进行了整合封装，使其尽量做到环境无关，然后根据需要对其输入输出进行了改造，使得他满足平台灵活快捷的需求。

在与Flink的适配层面，专门支持了Hyperscan datastream和Hyperscan operator。这样既有利于在平台上的产品化，同时也很方面直接在Flink中进行算子级别的使用。

3）场景域 流量监测 

正则匹配效能提升的应用场景有很多。首先是流量检测，流量检测本身也有很多细分场景，最常见的就是在网关数据中进行安全检测，每一条网关数据都要与大量的安全规则进行匹配，比如来了一条数据，但是安全规则有几千几万条，希望在毫秒级得到响应。第二个是内容摘取，例如用于在上报的打点日志中寻找特定字符串；信息流跟踪一般用于信息流业务中的关键字替换的场景，当遇到特定的字符，直接脱敏处理。

2. 加速Flink SQL 优化用户使用

1）SQL表达的优势

为什么不管是社区还是各大公司，大家都在力推sql来进行编程，至少有以下三个原因：

• SQL更易为数据开发人员使用，更易于进行业务逻辑表达。
• SQL的提交过程包含逻辑优化和物理优化，映射到社区的编程规范和最佳实践，对Flink零了解，也可以写出最好的Flink代码。
• SQL作为上层接口，与计算引擎内核耦合度低，有利于引擎升级。

基于以上三个原因，我们也在公司内部做了很多Flink SQL的推广工作。

2）多语言UDF

A. 问题域

在推广的过程中，发现作为一家安全公司有一些特点，比如安全相关的同事，不使用java系的开发语言，而UDF作为SQL关系表达的补充，又必不可少，所以提供可供多语言使用的UDF就成为必须。

B. 解决方案域

首先，平台会根据Flink的规范，实现了udf和udtf的基础设施，其中规定了与用户逻辑的输入输出接口。其次，用户实现自己的业务逻辑，并按照输入输出接口进行交互，用户的业务逻辑会被作为process整体运行，而这个process本身也受管控。再者，拓展了Flink sql的calcite语法，使得用户可以向注册普通udf一样去注册多语言udf。这样，整个流程就运转起来。

3）细粒度资源设置

A. 问题域

上文说明了SQL作为编程入口的优势，但同时SQL表达也有一定的劣势，其中最为明显的就是隔离了Flink在进行api编程时的并行度设置的灵活度。当我们使用Flink API编程时，对于每一个operator，我们都可以按照需求进行并行度进行设置，最大化的充分利用计算资源。但当编程接口转换到SQL之后，SQL表达和最终的DAG图之间会经过若干的优化和转变，导致仅仅通过SQL表达无法预知将要运行的DAG图形，另外SQL表达本身也没有提供并行度设置的入口。但与此同时，细粒度的设置，在生产实践中往往又是必不可少的，因为一个运行中的作业，各级算子之间的资源使用的差异总是天然存在的。作为一个以降本增效为基本目标的基础部门，我们责无旁贷的必须为资源的最大化利用提供每一种可能。

B. 解决方案域

整个解决方案分为两个大的步骤，首先根据用户的SQL语句转化成DAG图，将DAG图经过一系列的转换后进行序列化，展示给用户进行相关属性的设置，最后再将用户的设置，连同之前的DAG图进行融合，并提交运行。

这其中存在很多需要考虑的点，其中最需要注意的是三个。一，如何确保用户的SQL语句在经过变化的时候，生成的DAG图还能基本保持一致，不然如果SQL语句有简单的变化，DAG图却完全不一样，那么就失去了意义；二，如何保证在作业已经运行之后，还允许作业重新提交进行恢复，如果细粒度设置只能在初次提交进行，那么将大大减少其生产使用的价值；三，需要明确方案应对的场景，对于细粒度并行度设置，但无论是基于table hints还是基于source和sink的with属性，其场景域都是狭窄却明确的，我们的方案也不是万能的，也需要明确在哪些场景下可用，哪些场景下不可用。

经过精心的设计和反复的实验，最终得到了稳定的、可复用的细粒度设置解决方案。

在Flink SQL的优化上，我们还有其他十几项优化点，限于篇幅，这里不一一赘述。

四、Flink在奇虎360的未来应用

建设以Flink为基础的实时计算平台，道阻且长，我们还需要不断的对齐、优化，但目前总体而言，计算平台的建设已经到了一个稳定期，下一阶段，我们的重点方向会转向计算上云和湖仓一体的建设。

计算上云是大势所趋。首先，云上的计算资源隔离，相比目前的Yarn，要更彻底更可控，相对于目前实时作业总是受到离线作业的影响，上云之后，这部分影响会大大减少；其次，云上的资源管理更灵活，对于应对业务计算资源需求的波峰波谷提供了更好的基础；再者，云上基于pod的依赖管理更加清晰，不会再有yarn上的各种依赖冲突和缺失；最后，对于平台建设而言，发布的不再是一堆jar包，而是各种image，管理性大大提升。

湖仓一体是宏大的体系工程。鉴于目前HIVE的各种计算特性缺失，计算速度低下，数据存储死板，并发读写太差，无法支持变更，业界已经探索出若干条道路，基于iceberg的数据湖建设就是其中之一。在后续的平台建设中，我们会探索利用iceberg来替代hive的可能性，减少数据计算的资源需求，降低数据可见性的延迟，减少数据存储的资源消耗，增加数据查询的速度，进一步更好的支撑数据业务的发展。