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

阅读数:3465 2019 年 4 月 1 日

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

在这样的背景下,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(微信同号)。