在互联网越来越快的今天，用户的“耐性”正在变差，企业对数据服务实时化的需求也日益增多，打车、外卖、网购、在线视频等场景下，用户已经不能忍受较长时间的等待，企业对于大数据实时决策的要求也越来越严苛。

在这样的背景下，OPPO基于 Flink 打造了实时计算平台 OStream，对Flink进行了系列的改进和优化，探索了实时流计算的行业实践以及变化趋势。为此，OPPO 大数据平台研发负责人张俊接受了InfoQ的专访，深度解析了实时流计算的行业实践以及变化趋势。同时，张俊也将在QCon广州上带来相关专题演讲。

InfoQ：目前OPPO有在什么样的场景中使用Flink？（如果方便透露规模的话也可以具体介绍下）你们是什么时候开始使用Flink的？当时为什么要选择Flink？

OPPO的互联网服务拥有2.5亿的全球活跃用户，涵盖了应用商店、信息流、搜索等各类业务。2017 年开始，陆续有业务开始尝试实时计算，主要是基于 Storm 和 Spark Streaming。2018年开始逐步尝试转向 Flink，核心有两点考虑：第一，相对 Spark Streaming 来说，Flink 是原生的流处理引擎，能带来更低的处理延迟；第二，相对 Storm 来说，Flink 具备内置的状态管理与更低成本的容错机制。

目前，Flink 已经应用在实时 ETL、实时报表、实时标签等场景，目前广泛服务于浏览器、信息流、应用商店等业务，集群规模达到200台机器。到下半年，预计集群规模会超过500台，推荐、搜索、广告等业务也都在规划接入。

InfoQ：能否整体介绍下你们大数据平台的架构？基于 Flink 构建的实时计算平台主要做了哪些工作？

OPPO 大部分的数据来源是手机终端，因此我们基于NiFi构建了数据接入系统，将数据同时落地HDFS 与 Kafka，分别应用于离线与实时场景：

离线方面，基于Hive构建了一整套数仓体系，跑批任务通过 Airflow 来统一调度，报表、多维分析主要利用 Kylin 来加速，即席查询由 Presto 来承载；
实时方面，构建了以”Kafka->Flink->Kafka->Druid/Elasticsearch”为核心的实时数据流，Druid主要用于实时报表，Elasticsearch用于实时标签。

目前，自建的实时计算平台 OStream 主要基于Flink SQL来构建，提供一站式的 WEB 控制台来创建库表、编辑并提交SQL、查看作业日志、展示作业指标、设置告警规则。未来，平台还将支持画布拖拽与 JAR 包提交两种使用模式，进一步满足不同用户人群的诉求。

InfoQ：在使用 Flink 构建实时计算平台的过程中遇到过哪些难点？是怎么解决的？你们做了哪些定制化的改造与增强？（出于什么原因改造、如何优化、优化后的效果）

主要遇到有三个难点，社区都有相关的讨论，但官方目前还没有成熟的解决方案：

第一，如何与外部元数据打通。我们的离线数仓元数据（包括库表与UDF）由自研的元数据中心管理，信息统一存储在 MySQL 上，实时元数据也希望能统一起来维护。Flink SQL API 虽然可以从 ExternalCatalog 来搜索外部表定义，但内置只有基于 memory 的实现。我们通过扩展 ExternalCatalog，从MySQL查询外部表，实现了与元数据中心的打通。

第二，如何提交与管理SQL作业。目前，Flink SQL 只支持嵌入代码中来提交，REST-based SQL gateway 一直是社区的热门需求。Uber开源的 AthenaX 填补了这个空白，实现了以 SQL REST 的方式来提交与作业管理。但是，由于原生的 AthenaX 以及关键模块的缺失，根本无法运行起来，所以我们扩展了它的 TableCatalog 和 JobStore，实现了完整的元数据与作业管理，同时进行大量功能上的优化与修复，使其达到生产可用的状态。

第三，如何实现数据流与维表join。实际流处理场景中，实时数据经常需要关联 MySQL/Hive 维表，比如根据用户ID获取特征标签。我们利用 Flink 对 stream-table 二元性的支持，在SQL编译阶段进行改写，将维表 join 转换为中间 stream，从而自动加载维表数据到内存来与中间stream关联。这样的实现方式很轻量，无需改动Flink内核代码。

InfoQ：OPPO 流计算技术的演进过程是怎样的？反过头来看，Flink 是否能够完美支撑平台迈向智能化的需求？未来你们会有什么样的迭代计划？

OPPO 流计算发展较晚，因此反而没有太多的历史包袱，使得我们可以更顺利地转向 Flink 这样的先进框架。当前，OPPO 流计算的应用主要偏向实时数仓方向，推荐实时化以及监控实时化正在萌芽中，未来会有更多的发展。

所谓平台智能化，我的理解是不断加深自动化程度，最小化人工的使用与维护成本。这个仅依靠 Flink 单体系统是无法实现的，需要生态的协作与合力。Flink 目前的生态发展势头不错，已经与越来越多的系统打通，自身框架的架构也愈加完善，能够支撑智能化场景的探索与演进。未来，我们计划从两个层面去尝试：在使用层面，自动报表、标签以及 ETL 的生成；维护层面，智能配置优化、自动系统告警等。

InfoQ：取之于开源，用之于开源，您个人或您所在的团队为 Flink 社区做过哪些贡献？开发者如何参与到 Flink 社区贡献中来？

目前所做的贡献可以参考 FLINK-9384、FLINK-9444、FLINK-10061、FLINK-10079、FLINK-10170 这几个issue。

学习 Flink 的初期一直有关注社区动向，但真正提交贡献是源于研发过程中偶然遇到的问题。因为属于基本的功能点，当时不太敢相信是 Flink 内核bug，更多地以为是使用方式不当。后来，反复确认了API文档，还写了额外的示例都重现了问题，才深入源码去探究，最终找到和修复了bug。现在总结下来，关于参与开源社区有几点感悟：

平时多关注 mailing list 与 github pull request，那里有很多问题和话题的探讨，可以提供方向性地指引。当然，真正的切入点还是源于深入应用中遇到的问题。
平时使用过程中，不要仅仅停留在API层面，可以通过某个API方法为切入点深入Runtime，刚开始不用陷入细节，跟踪主体流程就好，必要时把 code path 记录一下，真正遇上问题时可以快速地定位。
发现问题，要大胆提出，社区多数人都很nice，会耐心地给出建议与想法，即便最终没有 merge，探讨的过程也是一种学习与积累。当然，提交PR时有一些规范还是要注意，比如PR问题描述要尽量详细与清晰，问题修复要有单元测试佐证，确保修改后全局单元测试都能通过。

InfoQ：之前DA（Flink创始公司）的CTO发表演讲称，当前存在的一个趋势是，Flink将朝着批流融合计算方面发展。您怎样看这样的发展趋势？这将对Flink的应用带来哪些影响？

Flink 或 Spark 这样的平台型框架所带来的核心优势，就是在 API 层面统一各个分布式计算场景。当前，虽然 Flink 在流计算领域所向披靡，但离线批处理领域仍然是 Hive 和 Spark 的天下。我认为最主要的原因是 Runtime 能力和生态没有跟上，前不久我们有尝试用 Flink 做批计算，但与 Hive 元数据打通这样最基本的特性都有缺失，前方死路一条。当然，我很期待 Flink 在 Runtime 层面的批流融合方向。数据开发者能够共同维护同一套代码，平台开发维护统一的计算引擎，相信是大家喜闻乐见的。

嘉宾介绍

张俊，OPPO 大数据平台研发负责人，主导了 OPPO 涵盖“数据接入-数据治理-数据开发-数据应用”全链路的数据中台建设。2011年硕士毕业于上海交通大学，曾先后工作于摩根士丹利、腾讯，具有丰富的数据系统研发经验，目前重点关注数仓建设、实时计算、OLAP 查询方向，同时也是Flink 开源社区贡献者。

5 月 25-28 日 QCon 全球软件开发大会广州站，张俊老师将会现场进行【Flink 在 OPPO 的平台研发与应用实践】相关内容的分享，详细剖析OStream 平台的研发之道——设计原则、总体架构、Flink 改进优化。

访问QCon广州官网可了解相关详情。现在是大会 8 折最后阶段，当前购票立减 1360 元，咨询可致电鱼丸：13269078023（微信同号）。

创作场景

OPPO 基于 Flink 构建实时计算平台的思路、演进与优化