【IT168 专稿】本文根据罗江宇老师在2018年5月12日【第九届中国数据库技术大会】现场演讲内容整理而成。
讲师简介:
罗江宇,滴滴出行资深研发工程师。浙江大学硕士,曾就职新浪微博,2016年加入滴滴出行,目前从事Flink业务支持,集群稳定性保障和研发工作。
摘要:
为了应对滴滴数据量爆炸性增长和对实时计算低延迟的高要求,滴滴引入Flink 实时计算框架,目前Flink Streaming已在滴滴的实时监控,实时BI,实时CEP ,和在线业务等领域有了广泛的应用。本次演讲主要介绍Flink Streaming在滴滴大规模生产的应用场景,以及分享生产中遇到的问题以及解决方法,从中获取的经验。
分享大纲:
1、Flink Streaming平台化
2、Flink Streaming在滴滴的实践
3、Flink Streaming展望与规划
正文:
1、Flink Streaming平台化
首先,我介绍一下滴滴引入Flink Streaming的背景,主要分为三部分:一是滴滴存在丰富的数据及应用场景,比如乘客、司机、交易以及轨迹数据等,在用户下单过程中也会产生很多日志数据;二是业务实时性要求越来越高;三是公司很多Storm或JStorm小集群需要及时升级整合。由于Flink Streaming原生兼容Storm和JStorm,因此转向Flink Streaming的成本相对来说比较低。
作为滴滴大数据架构部,我们改造的主要目的,一是希望降低使用Flink Streaming服务的门槛,二是整合公司内的小集群,降低运维成本,提升机器利用率;三是提升服务的稳定性与问题定位的效率。
上图为滴滴实时计算平台整体架构,底层存储使用HDFS、ES以及Druid,再上一层是Yarn调度层,再向上是目前滴滴正在使用的计算引擎——Flink Streaming和Spark Straeming, 最上层主要包括应用管控、WeblDE,SQL(建设中)以及诊断系统。
在Yarn计算资源管理部分,我们主要分为两大类,一类是稳定性要求较高的业务独占机器(基于Label机制);二是普通业务混布机器(基于CGroup机制)。如上图下方所示,Label一般基于业务,每个业务分成一个Label,稳定性要求较高的业务使用队列绑定Label,普通业务基本就是No-Label, 运行在混布环境。
为了支持平台化Flink Streaming改造,我们做得第一件事是支持HDFS应用资源,主要因为flink提交应用不支持HDFS;二是限制JobManager至多运行一个应用;三是基于应用DAG情况进行计算资源申请;四是支持计算资源的动态缩扩。下面重点介绍下基于计算资源的动态缩扩。
上图是计算资源扩容示例图,比如我现在需要进行应用升级,原来的50个并行度变为100个并行度,我并不是先把申请的50个资源全部回收,再重新申请100个,而是直接在50个的基础上追加。首先由应用管控部分提交应用到JobManager,JobManager计算应用所需资源后进行缩扩check,如果需要扩容,JobManager会先向Yarn RM申请,Yarn RM再向Hadoop Yarn申请扩容资源。会新增相应的TaskManager,这个过程还会涉及到调整networkbuffer。
缩容示意图如上所示,同样是由应用管控提交应用,计算所需资源之后进行缩扩check,JobManager主动check进行realease一些TM。在缩扩容的过程中,最重要的两件事情就是计算所需资源和保持该资源。
接下来讲讲Flink流式任务开发与管控,Flink流式任务开发主要有三种方式,一是通过Web IDE,二是通过Streaming SOL(建设中),三是线下开发。流式任务管控就是管控web化,不需要客户机,并且简化提交应用的参数配置。
流式任务开发及管控整体流程如上所示,Web IDE、SQL以及线下开发接入应用管控平台,整体再接入诊断系统,诊断系统主要用于分析调优。
上述为Web IDE界面,我们会在Web IDE上提供一些基本模板,可以多位用户协同开发。在Web管控提交页面,我们会列出集群、所属项目、公共用户、任务名称、任务类别、主程序等信息,用户基本不需要配置太多信息。
Flink流式任务诊断体系如下图所示,主要分为两部分:Flink日志和流式指标。
日志部分实时接入ES,我们可以通过Kibana和ES SQL查询。由于ES层的数据只能保留有限的时间,如果用户需要保持较长时间的数据进行分析,我们会考虑将日志接入HDFS,然后通过Hive和UI查看。流式指标直接接入Druid,然后通过监控大盘查看流量和延迟,以及其他指标。
2、Flink Streaming在滴滴的实践
Flink Streaming在滴滴的主要应用场景有四个:实时ETL、实时报表、实时监控和实时业务。接下来,我先分享一下实时网关日志监控,一是主要支持select、groupby、filter和一定时间范围内的window计算规则;二是支持计算规则的动态更新;三是基本覆盖整个公司的网关日志;四是数据量高峰期可达到每秒300万以上;五是通过网关日志监控提升线上业务排查问题效率。
以上是实时网关日志监控整体图,日志Agent采集数据到Kafka,Flink Streaming会定时从计算规则元数据管理中心拉取元数据,Metric上报可进行自监控,最终结果输入ES,业务方通过查询ES进行DashBoard展示和告警; Flink Streaming计算应用的metric 上报到监控平台,提供对监控计算应用的监控。
以上是实时网关日志监控规则,基本涵盖groupby、select等指标。在这个过程中,我们遇到的问题大概可分为以下五类:一是数据量暴涨,计算资源不够,这种情况常见于节假日前夕,提供兜底的方案是基于计算规则的降级方案。
二是机房网络可能存在故障,在我们实际生产中有两个机房,为了防止因机房故障导致服务不可用,我们做了异地多活。
三是聚合结果明显不正确,造成这种现象的原因可能是数据跨度较大,延迟数据较多,进而造成数据聚合结果不正确,我们的解决方案是构建延迟数据监控。
四是其他异常处理,主要包括Checkpoint异常和Kafka 异常,针对监控对时间延迟要求高,对延迟一定时间的数据没有意义的情况,对checkpoint异常的处理策略进行优化和监控;而Kafka 的异常,主要发生在kafka的发送的时候,由于kafka集群升级或者网络抖动,导致kafka 发送失败的情况,针对kafka 发送失败的情况,提供合理的retries 和在最大retries 失败后的skip策略。
在实时规则引擎部分,其支持DSL和CEP代码规则,支持CEP规则动态更新,目前已上线的应用场景是实时运营,实时发放券和实时风控,并且由原来天级别的处理时间提升为实时处理。
实时规则引擎整体架构如上图所示,从MQ和Kafka接入数据清洗,我们做了CEP规则元数据管理中心,提供动态CEP算子,通过Groovy方式解析规则并生成NFA,然后进行数据处理,这匹配过程中可能需要依赖外部特征数据查询,最后匹配结果输出到Kafka,下游根据发送到Kafka的匹配结果进行进一步处理。
实时规则描述部分从上至下依次为规则、序列算子、condition描述和输出算子。在序列算子层加入了wait和abortwith算子,condition描述就是代码级别,此处主要是SQL。假如,beginwith是yes,followba是yes,wait是yes,abortwith是no,则最后输出算子。
实时规则引擎遇到的问题主要有以下四类:
1. pattern无法动态加载,每次更新需要重启应用。解决方案是采用groovy动态语言,改造cep operator动态加载update NFA生效。
2. sharedBuffer的性能问题,每次元素到来会需要将之前匹配到的中间元素都rocksdb中获取出来导致性能很差,基于社区的优化patch,在中间加了一些缓存优化很好的满足了业务需求。
3. cep的原本实现条件表达复杂,需要写很多内部类利用aviator的表达式解析引擎,和json表达很好的简化了数据匹配条件的描述。
4. cep本身无法表达notFollowedBy结尾类型的条件,而业务中确有很多类似的需求,通过开发类似wait语义的算子将满足了类似 begin().notFollowedBy().wait()这种业务需求的表达 。
3、Flink Streaming展望与规划
根据滴滴的应用情况,我们总共提出了五点规划:一是完善动态CEP,接下来会将考虑动态CEP与风控相结合,提升风控的实时性;二是构建Streaming SQL平台,进一步降低使用门槛与开发成本;三是支持Flink Streaming任务平滑升级,主要满足稳定性要求极高的应用的升级;四是支持流与维表Join和双流Join(不借助外部存储) ;五是拓宽Flink Streaming应用场景,未来可能会考虑向机器学习和IOT等方向拓展。
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/31077337/viewspace-2213334/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/31077337/viewspace-2213334/