Flink在美团的实践与应用

  • 时间:
  • 浏览:1
  • 来源:大发彩神下载—大发彩神APP

第二类应用就说 机器学习的一有一个 场景,机器学习的场景肯能会依赖离线的形状数据以及实时的形状数据。一有一个 是基于现有的离线场景下的形状提取,经过了批防止,流转到了离线的集群。另外一有一个 就说 近线模式,近线模式出的数据就说 现有的从日志分发系统流转过来的统一的日志,经过Flink的防止,就说 包括流的关联以及形状的提取,再做模型的训练,流转到最终的训练的集群,训练的集群会产出P的形状,还有都是Delta的形状,最终将哪几种形状影响到线上的线上的形状的一有一个 训练的一有一个 服务上。这是一有一个 比较常见的,比如说比较就说 通用的也是比较通用的一有一个 场景,目前话语主要应用的方肯能所含了搜索还有推荐,以及其他其他的业务。

下面会给亲们讲有一个 Flink在美团的真实使用的案例。第一有一个 是Petra,Petra觉得是一有一个 实时指标的一有一个 聚合的系统,它觉得是面向公司的一有一个 统一化的防止方案。它主要面向的业务场景就说 基于业务的时间去统计,还有计算其他实时的指标,要求话语是低速度单位,他还有一有一个 却话语,肯能它是面向的是通用的业务,肯能业务肯能是人及会有人及不同的维度,每一有一个 业务肯能所含了包括应用通道机房,还有其他的人及应用各个业务特有的其他维度,然后 哪几种维度肯能涉及到比较多,另外一有一个 却话语它肯能是就说 业务时需去做其他复合的指标的计算,比如说最常见的交易成功率,他肯能时需去计算支付的成功数,还有和下单数的比例。另外一有一个 却话语统一化的指标聚合肯能面向的还是一有一个 系统,比如说是其他B端肯能是R段的其他监控类的系统,没有 系统对于指标系统的诉求,却话语然后 指标聚合不能最真最实时最精确的不能产生其他结果,数据保证说它的下游系统不能真实的监控到当前的信息。右边图是我当一有一个 Metrics展示的一有一个 事例。能不能看后其他觉得跟完后 讲也是比较例如的,却话语所含了业务的不同维度的其他指标汇聚的结果。

美团在调研使用Flink完后 遇到了其他痛点和哪几种的问题报告 :

在监控上亲们也做了其他事情,对于实时作业来讲,对监控的要求会更高,比如说在作业延迟的完后 对业务的影响也比较大,统统做了其他延迟的报警,包括作业情況的报警,比如说作业存活的情況,以及作业运行的情況,还有未来会做其他自定义Metrics的报警。自定义Metrics是未来会考虑基于作业防止一种生活 的内容性,做其他可配置化的其他报警。

在用Flink去做实时指标复核的系统的完后 ,着重从这几方面去考虑了。第一有一个 方面是说精确的计算,包括使用了FLink和CheckPoint的机制去保证说我能不能 做到不丢不重的计算,第一有一个 首先是由统一化的Metrics流入到一有一个 预聚合的模块,预聚合的模块主要去做其他初始化的其他聚合,其中的为哪几种会分预聚合和全量聚合主要的防止一类哪几种的问题报告 ,包括就完后 那位同学问的一有一个 哪几种的问题报告 ,就说 数据倾斜的哪几种的问题报告 ,比如说在热点K居于的完后 ,当前的防止方案也是通过预聚合的最好的法律土办法去做其他缓冲,让尽量把K去打散,再聚合全量聚合模块去做汇聚。那觉得也是没有 防止一次责哪几种的问题报告 ,所完后 面也考虑说在性能的优化上包括去探索情況存储的性能。下面话语还是所含晚到数据的容忍能力,肯能指标汇聚肯能完后 也提到说要所含其他复合的指标,没有 符合的指标所依赖的数据肯能来自于不同的流,即便来自于同一有一个 流,肯能每一有一个 数据上报的完后 ,肯能也会有晚到的情況居于,那完后 时需去对数据关联做晚到的容忍,容忍的一方面是说能不能设置晚到的Lateness的延迟,买车人面是能不能设置窗口的长度,然后 其觉得现实的应用场景上,觉得还有一方面考虑却话语除了去尽量的去拉长时间,时需考虑真正的计算成本,统统在这方面也做了其他权衡,没有 指标基本就说 经过全量聚合完后 ,聚合结果会回写Kafka,经过数据同步的模块写到OpenTSDB去做,最后去grafana那做指标的展示,买车人面肯能去应用到通过Facebook包同步的模块去同步到报警的系统上面去做其他指标,基于指标的报警。

1.业务场景:

上图呈现的是当前美团实时计算平台的简要架构。最底层是数据缓存层,能不能看后美团测的所有日志类的数据,都是通过统一的日志分发系统分发到Kafka。Kafka作为最大的数据中转层,支撑了美团线上的少量业务,包括离线拉取,以及次责实时防止业务等。在数据缓存层之上,是一有一个 引擎层,你你这一层的左侧是亲们目前提供的实时计算引擎,包括Storm和Flink。Storm在此完后 是 standalone 模式的部署最好的法律土办法,Flink肯能其现在运行的环境,美团选泽的是On YARN模式,除了计算引擎之外,亲们还提供其他实时存储功能,用于存储计算的上面情況、计算的结果、以及维度数据等,目前你你这一类存储所含Hbase、Redis以及ES。在计算引擎之上,是趋于五花八门的一层,你你这一层主要面向数据开发的同学。实时数据开发面临诸多哪几种的问题报告 ,例如在多多应用程序 的调试调优方面就要比普通的多多应用程序 开发困难统统。在数据平台你你这一层,美团面向用户提供的实时计算平台,不仅能不能托管作业,还能不能实现调优诊断以及监控报警,此外还有实时数据的检索以及权限管理等功能。除了提供面向数据开发同学的实时计算平台,美团现在正在做的事情还包括构建元数据中心。这也是未来亲们想做SQL的一有一个 前提,元数据中心是承载实时流系统的一有一个 重要环节,亲们能不能把它理解为实时系统中的大脑,它能不能存储数据的Schema,Meta。架构的最顶层就说 亲们现在实时计算平台支撑的业务,不仅所含线上业务日志的实时查询和检索,还所含当下十分热门的实时机器学习。机器学习一个劲会涉及到搜索和推荐场景,这有一个 场景最显著特点:一、会产生海量实时数据;二、流量的QPS相当高。此时就时需实时计算平台承载次责实时形状的提取工作,实现应用的搜索推荐服务。还有一类是比较常见的场景,包括实时的形状聚合,斑马Watcher(能不能认为是一有一个 监控类的服务),实时数仓等。

美团实时计算平台的现状是作业量现在肯能达到了近万,集群的节点的规模是千级别的,天级消息量肯能达到了万亿级,高峰期的消息量不能达到千万条每秒。

本文转自Apache Flink China博客,作者:刘迪珊,原文链接:Flink在美团的实践与应用

下图是当前的日志的其他查询,它记录了,肯能作业在挂掉完后 ,每一有一个 ApplicationID肯能会变化,没有 基于作业唯一的唯一的主键作业名去搜集了所有的作业,从创建之初到当前运行的日志,没有 能不能允许用户的跨Application的日志查询。

智能调度目的也是为了防止资源不均的哪几种的问题报告 ,现在普通的调度策略就说 基于CPU,基于内存去调度的。除此之外,在生产过程中也发现了其他其他的哪几种的问题报告 ,比如说Flink是会依赖本地磁盘,进行依赖本地磁盘做本地的情況的存储,统统磁盘IO,还有磁盘的容量,也是一类考虑的哪几种的问题报告 点,除此之外还包括网卡流量,肯能每个业务的流量的情況是不一样的,分配进来会原困流量的高峰,把某一有一个 网卡打满,从而影响其他业务,统统期望话语是说做其他智能调度化的事情。目前暂时能做到的是从cpu和内存两方面,未来会从其他方面做其他更优的调度策略。

以上就说 美团目前实时计算平台的简要架构。

与Storm不同的是,知道Storm在遇到异常的完后 是非常简单粗暴的,比如说有居于了异常,肯能用户没有 在代码中进行比较规范的异常防止,然后 没有 关系,肯能worker会重启作业总要继续执行,然后 他保证的是At-Least-Once另一有一个 的语义,比如说一有一个 网络超时的异常对他而言影响肯能并没有 没有 大,然后 Flink不同的是他对异常的容忍度是非常的苛刻的,那完后 就考虑的是比如说会居于节点肯能是网络的故障,那JobManager单点哪几种的问题报告 肯能就说 一有一个 瓶颈,JobManager那个肯能挂掉话语,没有 肯能对整个作业的影响就说 不可回复的,统统考虑了做HA,另外一有一个 就说 会去考虑其他肯能运维的因素而原困的那作业,还有除此之外,肯能有其他用户作业是没有 开启CheckPoint,但肯能是肯能节点肯能是网络故障原困挂掉,希望会在平台内层做其他自动拉起的策略,去保证作业运行的稳定性。

1.节点/网络故障

下面带亲们来看一下,美团从去年投入生产过程中都遇到了哪几种哪几种的问题报告 ,以及其他防止方案,分为下面有一个 次责:

在实践过程中,为了防止作业管理的其他哪几种的问题报告 ,减少用户开发的其他成本,亲们做了其他平台化的工作,下图是一有一个 作业提交的界面展示,包括作业的配置,作业生命周期的管理,报警的其他配置,延迟的展示,都是集成在实时计算平台的。

3.容灾

可靠性、延迟需求不同;

1.资源隔离的考虑:分场景、按业务

高峰期不同,运维时间不同;

下图是当前某一有一个 作业的一有一个 可支持跨天维度的Metrics的一有一个 查询的页面。能不能看后说肯能是不能通过纵向的对比,能不能发现除了作业在某一有一个 时间点是肯能哪几种情況原困的?比如说延迟啊另一有一个 容易帮用户判断其他他的做作业的其他哪几种的问题报告 。除了作业的运行情況之外,也会先就说 分发其他节点的基本信息作为横向的对比

亲们的数据源主就说 Kafka,读写Kafka是一类非常常见的实时流防止避不开的一有一个 内容,而Kafka一种生活 的集群规模是非常比较大的,然后 节点的故障出显是一有一个 常态哪几种的问题报告 ,在此基础上亲们对节点故障进行了其他容错,比如说节点挂掉肯能是数据均衡的完后 ,Leader会切换,那一种生活 Flink的读写对Leader的切换容忍度没有 没有 高,在此基础上亲们对其他特定场景的,以及其他特有的异常做的其他优化,进行了其他重试。

4.对晚到数据的容忍能力

2.Exactlyonce的精确性保障

另外一方面话语就说 会进行新的场景的也在做新的场景的其他探索,期望是比如说包括完后 也提到说除了流式的防止,也期望说把离线的场景下的数据进行其他合并,通过统一的Sql的API去提供给业务做更多的服务,包括流防止,还有批防止的结合。

2.上下游容错

下图是现在提供的产品化的Petra的一有一个 展示的机示意图,能不能看后目前话语就说 定义了某其他常用的算子,以及维度的配置,允许用户进行配置话的防止,直接去不能获取到他期望要的指标的一有一个 展示和汇聚的结果。目前还在探索说为Petra基于Sql做其他事情,肯能统统用户也比较就说 在就说 习惯上也能不能倾向于说我能不能 去写Sql去完成另一有一个 的统计,统统也会基于此说依赖Flink的一种生活 的对SQl还有TableAPI的支持,也会在Sql的场景上进行其他探索。

另外就说 完后 提到说在开发实时作业的完后 ,调优和诊断是一有一个 比较难的痛点,就说 用户都是没有去查看分布式的日志,统统也提供了一套统一的防止方案。这套防止方案主就说 针对日志和Metrics,会在针对引擎那一层做其他日志和Metrics的上报,没有 它会通过统一的日志分发系统,将哪几种原始的日志,还有Metrics汇集到Kafka那一层。今后Kafka你你这一层亲们能不能发现它有一个 下游,一方面是做日志到ES的数据同步,目的话语是说不能进入日志中心去做其他日志的检索,另外一方面是通过其他聚合防止流转到写入到OpenTSDB把数据做依赖,这份聚合后的数据会做其他查询,一方面是Metrics的查询展示,另外一方面就说 包括实做的其他相关的报警。

3.维度计算中数据倾斜

YARN打标签,节点物理隔离;

未来话语肯能也是通过也是期望在这三方面进行做其他更多的事情,完后 也提到了包括情況的管理,第一有一个 是情況的统一的,比如说Sql化的统一的管理,希望有统一的配置,帮用户去选泽其他期望的回滚点。另外一有一个 就说 大情況的性能优化,肯能比如说像做其他流量数据的双流的关联的完后 ,现在也遇到了其他性能瓶颈的哪几种的问题报告 ,对于说啊基于内存型的情況,基于内存型的数据的防止,以及基于RocksDB的情況的防止,做过性能的比较,发现觉得性能的差异还是有其他大的,统统希望说在基于RocksDBBackend的上面不能去尽量去更多的做其他优化,从而提升作业防止的性能。第二方面就说 Sql,Sql话语应该是每一有一个 位就说 当前肯能各个公司都是做的一有一个 方向,肯能完后 都是对Sql做其他探索,包括提供了基于Storm的其他Sql的表示,然后 肯能对于完后 话语对于与语义的表达肯能会有其他不够,统统希望说在基于Flink可去防止哪几种方面的事情,以及包括Sql的并发度的其他配置的优化,包括Sql的查询的其他优化,都希望说在Flink未来不能去优化更多的东西,去真正能使Sql应用到生产的环境。

应用场景,重要性不同;

为了适配这两类MQ做了不同的事情,对于线上的MQ,期望去做一次同步多次消费,目的是防止对线上的业务造成影响,对于的生产类的Kafka就说 线下的Kafka,做了其他地址的地址的屏蔽,还有基础基础的其他配置,包括其他权限的管理,还有指标的分发。

2.资源隔离的策略:

容灾肯能亲们对考虑的太满多,比如说有没有 肯能一有一个 机房的所有的节点都挂掉了,肯能是无法访问了,觉得它是一有一个 小概率的事件,但它也是会居于的。统统现在也会考虑做多机房的其他部署,包括还有Kafka的其他热备。

离线DataNode与实时计算节点的隔离;

在上面哪几种痛点和哪几种的问题报告 的背景下,美团从去年刚开始进行Flink的探索,关注点主要有以下有一个 方面: