AdMaster技术专栏(二):拆解Flink,制胜大数据江湖的秘密



上一期,我们拆解了AdMaster的底层数据处理平台——数据魔方,破解了这个多阶魔方如何快速复原,还原品牌数字形象,如何变化组合,捕捉市场机会。

数据魔方持久运转,离不开数据源源不断的供养,因此,本期技术专栏,我们将目光聚焦于新一代大数据处理技术——Flink,看AdMaster如何利用Flink实时、全量、完整的采集、整理海量社交数据。


AdMaster高级研发总监:史腾飞(Stanford Shi)


说起大数据,我们第一时间想到的,就是它的3V特性,即Volume(规模)、Velocity(速度)、Variety(多样性),作为新一代技术和架构,大数据技术的目的,就是在成本可控的情况下,通过快速的采集、整理和分析,从大体量、多类别的数据中找到有价值的洞察。


这多少类似中国传统的江湖,大过八荒,门派林立,武功虽繁多,但唯快不破。在大数据的江湖里,能应对海量数据门派、快速出击,同时还可以处理多种非机构化(图文、语音、视频等)数据,既稳定可靠有成本可控的,就是Flink。



Flink出现前,大数据处理的难题

在Flink推出之前,为了应对大数据处理在规模、速度和类别上的挑战,Google提出了MapReduce方案,随后开源社区在该思想的影响下开发了Hadoop,随着不断的发展和完善,开源社区围绕Hadoop形成了一整套完善的大数据技术生态体系。大数据处理一般有两个典型的场景:

· 流处理(Stream Processing):用于即时处理实时数据,处理对象一般是单条数据记录,有时也被称为实时处理。例如:用户持续产生的订单、爬虫不断返回的抓取结果等。

· 批处理(Batch Processing):用于处理定期产生的数据集,处理对象一般是多条数据记录构成的批次。例如:系统定期产生的日志文件等。



MapRaduce主要适用于大规模批处理,通过把数据分为规模适当的子集(批次),利用分布式集群的并行计算能力,完成对大数据的高效处理。


在流处理应用场景下,则要求对于每一条实时产生的数据快速、可靠的完成处理。为了满足这种需求,Nathan Marz另辟蹊径开发了Storm,通过一种巧妙设计的算法保证了数据处理流程的效率和可靠性。


Storm做到了低延时,但是吞吐量偏低,容错也不太好;另外一种计算引擎Spark Streaming则是以批处理为核心,通过微批次模拟流处理,吞吐量和容错都不错,但是做不到低延时。



Flink,大数据江湖的全能门派

MapRaduce、Storm、Spark存在的问题,在Flink推出后,得到了解决,因为它不仅兼具高吞吐、低延迟,容错处理的额外开销也不高。


Flink的核心数据模型是流式的(Data Stream)。数据流可以是无边界的无限流,即一般意义上的流处理,也可以是有边界的有限流,这样就等效于批处理。所以,Flink同时支持流处理和批处理两种数据处理模式。


灵活易用的API

除了最底层的有状态流处理抽象接口外,Flink应用开发主要基于以下几种API:

· Core API:包含面向流处理的DataStream API和面向批处理的DataSet API,基于这两组API,可以完成对数据的转换、连接、聚合等操作;

· Table API这是通过一种围绕数据表构建的DSL(domain-specific language,领域特定语言),将关系型数据库操作原语应用于数据流的API,支持如select、join、group by等操作。

· SQL(Structured Query Language,机构化查询语言):结合Table API,Flink支持以SQL语言描述数据处理逻辑,这大大简化了数据处理逻辑的编写。



让我们看一个简单的例子:



这是一个经典的单词计数问题,通过以下步骤完成计数:

· 读取文件

· 将输入全部转为小写并分词

· 将每个单词构建成计数为1的tuple

· 以单词进行分组

· 对计数进行求和

· 保存结果


水平扩展和容错


在开发期间,一般采用Local模式以便进行调试。生产环境中,除了Flink内建的独立集群之外,我们还可以把Flink应用部署在YARN、Mesos、K8S等集群上,Flink能够自动的基于应用的并发设置申请计算资源,当资源获取失败时,Flink还能自动申请新的计算资源进行替换。


通过在集群中并行运行数以千计的计算任务,Flink拥有近乎无限的水平扩展能力,在如此规模之下,Flink的异步增量快照算法以尽可能小的延迟代价保障了数据处理的可靠性。


Flink中的每个任务都可以是有状态的。有状态函数在单个元素/事件的处理过程中存储数据,使状态成为任何类型的更精细操作的关键构建块。Flink针对应用的本地状态管理做了优化。优化的关键是将状态信息保持在内存中(当内存不足时会采用一种支持高速访问的磁盘存储结构),这使得状态处理造成的延迟非常低。


为了提升系统容错能力,Flink会对状态信息保留快照,这使它能快速恢复数据流的状态和位置。对于拥有少量状态的流式应用,这些快照是非常轻量级的。


程序出现故障时,Flink将会停止整个数据流的处理过程,然后重启各个子任务并重置它们到最近成功的快照,输入流将会被重置到状态快照的时间点。Flink保证重启的并行数据流中,所有已处理的记录都不会出现在系统恢复后的处理流程中。



Flink在AdMaster数据处理中的应用

在AdMaster的业务实践中,Flink主要应用于爬虫数据解析、多数据源实时接入等场景,以保证社交数据采集的实时、准确和完整。这里以爬虫数据解析为例,具体介绍一下Flink的应用方法:


整个Flink应用是运行在YARN集群上,处理流程上分为以下几个环节:

· Kafka Consumer,从Kafka集群获得爬虫集群抓回的数据;

· Pre Check,数据预处理,对每条数据做预先检查,如果发现错误则转发重试节点;

· Parse,数据解析;

· Post Check,对解析结果进行检查,如果发现错误则转发值重试节点;

· Save,对解析结果进行保存;

· Retry,对失败的抓取进行重试;



Flink在YARN集群上运行时:Flink YARN Client负责与YARN RM通信协商资源请求,Flink JobManager和Flink TaskManager分别申请到Container去运行各自的进程。目前,该系统日均处理数据量1亿+,高峰期可处理6000条/秒。


通过使用Flink流式数据执行引擎,AdMaster用尽可能小的延迟代价,保障了数据处理的可靠性,每天更新并新增数亿条数据,为数据魔方实现分钟级稳定输出提供了可能,也进而保证了客户能够快速地从海量社交数据中找到真实的洞察。