写点什么

58 同城基于 Flink 的千亿级实时计算平台架构实践

2020 年 1 月 08 日

58同城基于Flink的千亿级实时计算平台架构实践

本文由 dbaplus 社群授权转载。


58 同城作为覆盖生活全领域的服务平台,业务覆盖招聘、房产、汽车、金融、二手及本地服务等各个方面。丰富的业务线和庞大的用户数每天产生海量用户数据需要实时化的计算分析,实时计算平台定位于为集团海量数据提供高效、稳定、分布式实时计算的基础服务。本文主要介绍 58 同城基于 Flink 打造的一站式实时计算平台 Wstream。


实时计算场景

和很多互联网公司一样,实时计算在 58 拥有丰富的场景需求,主要包括以下几类:


  • 实时数据 ETL:实时消费 Kafka 数据进行清洗、转换、结构化处理用于下游计算处理。

  • 实时数仓:实时化数据计算,仓库模型加工和存储。实时分析业务及用户各类指标,让运营更加实时化。

  • 实时监控:对系统和用户行为进行实时检测和分析,如业务指标实时监控,运维线上稳定性监控,金融风控等。

  • 实时分析:特征平台,用户画像,实时个性化推荐等。


平台演进


在实时计算平台建设过程中,主要是跟进开源社区发展以及实际业务需求,计算框架经历了 Storm 到 Spark Streaming 到 Flink 的发展,同时建设一站式实时计算平台,旨在提升用户实时计算需求开发上线管理监控效率,优化平台管理。


实时计算引擎前期基于 Storm 和 Spark Streaming 构建,很多情况下并不能很好的满足业务需求,如商业部门基于 Spark Streaming 构建的特征平台希望将计算延迟由分钟级降低到秒级,提升用户体验,运维监控平台基于 Storm 分析公司全量 nginx 日志对线上业务进行监控,需要秒级甚至毫秒级别的延迟,Storm 的吞吐能力成为瓶颈。


同时随着实时需求不断增加,场景更加丰富,在追求任务高吞吐低延迟的基础上,对计算过程中间状态管理,灵活窗口支持,以及 exactly once 语义保障的诉求越来越多。Apache Flink 开源之后,支持高吞吐低延迟的架构设计以及高可用的稳定性,同时拥有实时计算场景一系列特性以及支持实时 Sql 模型,使我们决定采用 Flink 作为新一代实时计算平台的计算引擎。


平台规模


实时计算平台当前主要基于 Storm/Spark Streaming/Flink,集群共计 500 多台机器,每天处理数据量 6000 亿+,其中 Flink 经过近一年的建设,任务占比已经达到 50%。


Flink 稳定性

Flink 作为实时计算集群,可用性要求远高于离线计算集群。为保障集群可用性,平台主要采用任务隔离以及高可用集群架构保障稳定性。


任务隔离

在应用层面主要基于业务线以及场景进行机器隔离,队列资源分配管理,避免集群抖动造成全局影响。



集群架构

Flink 集群采用了 ON YARN 模式独立部署,为减少集群维护工作量,底层 HDFS 利用公司统一 HDFS Federation 架构下建立独立的 namespace,减少 Flink 任务在 checkpoint 采用 hdfs/rocksdb 作为状态存储后端场景下由于 hdfs 抖动出现频繁异常失败。


在资源隔离层面,引入 Node Label 机制实现重要任务运行在独立机器,不同计算性质任务运行在合适的机器下,最大化机器资源的利用率。同时在 YARN 资源隔离基础上增加 Cgroup 进行物理 cpu 隔离,减少任务间抢占影响,保障任务运行稳定性。



平台化管理

Wstream 是一套基于 Apache Flink 构建的一站式、高性能实时大数据处理平台。提供 SQL 化流式数据分析能力,大幅降低数据实时分析门槛,支持通过 DDL 实现 source/sink 以及维表,支持 UDF/UDAF/UDTF,为用户提供更强大的数据实时处理能力。支持多样式应用构建方式 FlinkJar/Stream SQL/Flink-Storm,以满足不同用户的开发需求,同时通过调试,监控,诊断,探查结果等辅助手段完善任务生命周期管理。



流式 sql 能力建设

Stream SQL 是平台为了打造 sql 化实时计算能力,减小实时计算开发门槛,基于开源的 Flink,对底层 sql 模块进行扩展实现以下功能:


  • 支持自定义 DDL 语法(包括源表,输出表,维表)

  • 支持自定义 UDF/UDTF/UDAF 语法

  • 实现了流与维表的 join,双流 join


在支持大数据开源组件的同时,也打通了公司主流的实时存储平台。同时为用户提供基于 Sql client 的 cli 方式以及在 Wstream 集成了对实时 sql 能力的支持,为用户提供在线开发调试 sql 任务的编辑器,同时支持代码高亮,智能提示,语法校验及运行时校验,尽可能避免用户提交到集群的任务出现异常。


另外也为用户提供了向导化配置方式,解决用户定义 table 需要了解复杂的参数设置,用户只需关心业务逻辑处理,像开发离线 Hive 一样使用 sql 开发实时任务。



Storm 任务迁移 Flink

在完善 Flink 平台建设的同时,我们也启动 Storm 任务迁移 Flink 计划,旨在提升实时计算平台整体效率,减少机器成本和运维成本。Flink-Storm 作为官方提供 Flink 兼容 Storm 程序为我们实现无缝迁移提供了可行性,但是作为 beta 版本,在实际使用过程中存在很多无法满足现实场景的情况,因此我们进行了大量改进,主要包括实现 Storm 任务 on yarn ,迁移之后任务 at least once 语义保障,兼容 Storm 的 tick tuple 机制等等。



通过对 Fink-Storm 的优化,在无需用户修改代码的基础上,我们已经顺利完成多个 Storm 版本集群任务迁移和集群下线,在保障实时性及吞吐量的基础上可以节约计算资源 40%以上,同时借助 yarn 统一管理实时计算平台无需维护多套 Storm 集群,整体提升了平台资源利用率,减轻平台运维工作量。


任务诊断

指标监控

Flink webUI 提供了大量的运行时信息供用户了解任务当前运行状况,但是存在无法获取历史 metrics 的问题导致用户无法了解任务历史运行状态,因此我们采用了 Flink 原生支持的 Prometheus 进行实时指标采集和存储。


Prometheus 是一个开源的监控和报警系统,通过 pushgateway 的方式实时上报 metrics,Prometheus 集群采用 Fedration 部署模式,meta 节点定时抓取所有子节点指标进行汇总,方便统一数据源提供给 Grafana 进行可视化以及告警配置。



任务延迟

吞吐能力和延迟作为衡量实时任务性能最重要的指标,我们经常需要通过这两个指标来调整任务并发度和资源配置。Flink Metrics 提供 latencyTrackingInterval 参数启用任务延迟跟踪,打开会显著影响集群和任务性能,官方高度建议只在 debug 下使用。


在实践场景下,Flink 任务数据源基本都是 Kafka,因此我们采用 topic 消费堆积作为衡量任务延迟的指标,监控模块实时通过 Flink rest 获取任务正在消费 topic 的 offset,同时通过 Kafka JMX 获取对应 topic 的 logsize,采用 logsize– offset 作为 topic 的堆积。



日志检索

Flink 作为分布式计算引擎,所有任务会由 YARN 统一调度到任意的计算节点,因此任务的运行日志会分布在不同的机器,用户定位日志困难。我们通过调整 log4j 日志框架默认机制,按天切分任务日志,定期清理过期日志,避免异常任务频繁写满磁盘导致计算节点不可用的情况,同时在所有计算节点部署 agent 实时采集日志,汇聚写入 Kafka,通过日志分发平台实时将数据分发到 ES,方便用户进行日志检索和定位问题。


Flink 优化

在实际使用过程中,我们也针对业务场景进行了一些优化和扩展,主要包括:


1)Storm 任务需要 Storm 引擎提供 ack 机制保障消息传递 at least once 语义,迁移到 Flink 无法使用 ack 机制,我们通过定制 KafakSpout 实现 checkpoint 相关接口,通过 Flink checkpoint 机制实现消息传递不丢失。另外 Flink-Storm 默认只能支持 standalone 的提交方式,我们通过实现 yarn client 相关接口增加了 storm on yarn 的支持。


2)Flink 1.6 推荐的是一个 TaskManager 对应一个 slot 的使用方式,在申请资源的时候根据最大并发度申请对应数量的 TaskManger,这样导致的问题就是在任务设置 task slots 之后需要申请的资源大于实际资源。


我们通过在 ResoureManager 请求资源管理器 SlotManager 的时候增加 TaskManagerSlot 相关信息,用于维护申请到的待分配 TaskManager 和 slot,之后对于 SlotRequests 请求不是直接申请 TaskManager,而是先从 SlotManager 申请是否有足够 slot,没有才会启动新的 TaskManger,这样就实现了申请资源等于实际消耗资源,避免任务在资源足够的情况下无法启动。



3)Kafak Connector 改造,增加自动换行支持,另外针对 08source 无法设置 client.id,通过将 client.id 生成机制优化成更有标识意义的 id,便于 Kafka 层面管控。


4)Flink 提交任务无法支持第三方依赖 jar 包和配置文件供 TaskManager 使用,我们通过修改 flink 启动脚本,增加相关参数支持外部传输文件,之后在任务启动过程中通过将对应的 jar 包和文件加入 classpath,借助 yarn 的文件管理机制实现类似 spark 对应的使用方式,方便用户使用。


5)业务场景存在大量实时写入 hdfs 需求,Flink 自带 BucketingSink 默认只支持 string 和 avro 格式,我们在此基础上同时支持了 LZO 及 Parquet 格式写入,极大提升数据写入性能。


后续规划

实时计算平台当前正在进行 Storm 任务迁移 Flink 集群,目前已经基本完成,大幅提升了平台资源利用率和计算效率。后续将继续调研完善 Flink 相关能力,推动 Flink 在更多的实时场景下的应用,包括实时规则引擎,实时机器学习等。


作者介绍


冯海涛/万石康,负责 58 同城实时计算平台建设。


原文链接


https://mp.weixin.qq.com/s?__biz=MzI4NTA1MDEwNg==&mid=2650784251&idx=1&sn=3f90f0eadad3b781200ec8b31d281dfd&chksm=f3f9746ec48efd78b0e10fa9a3e9fe646ef385c9450762ed634194760b03a528b561dbcab321&scene=27#wechat_redirect


2020 年 1 月 08 日 14:003105

评论 1 条评论

发布
用户头像
具体案例呢?
2020 年 01 月 14 日 17:39
回复
没有更多了
  • 唯品会实时计算平台的演进之路

    本文介绍唯品会实时计算平台的现状和发展历程。

  • 实时计算框架 Flink 在教育行业的应用实践(下)

    Spark发送数据到Kafka,及最后的执行分析计划,与Flink无区别,不再展开。下面简述差异点。文件到集群上运行。

  • 80|Flink 内存管理

    2020 年 12 月 17 日

  • Apache Kylin 在携程的实践

    在近期的 Apache Kylin Meetup 上,携程大数据资深研发工程师张巍分享了 Kylin 在携程的应用。本文为大家介绍携程当前的架构以及使用 Kylin 过程中的挑战与心得。

  • 起底 eBay Flink 的上云之路

    本文介绍eBay Rheos Team如何将Flink算力服务化、便捷化。

  • 性能突破:MRS2.0 即将上线,组件全线升级

    紧跟大数据前沿,尝鲜MapReduce 2.0版本—增加了诸多新特性

  • 实时计算引擎在贝壳的应用与实践

    本文介绍实时计算引擎在贝壳的应用与实践。

  • 腾讯 Flink 实践:实时计算平台 Oceanus 建设历程

    目前腾讯的实时计算的规模已经十分庞大。数据平台部实时计算团队每天需要处理超过了17万亿条数据,其中每秒接入的数据峰值达到了2.1亿条。本文介绍了腾讯大数据在实时计算平台建设上的工作。

  • 把嵌套列表作为 Apache Spark SQL 的首选

    演讲嘉宾DB Tsai is an Apache Spark PMC / Committer and an open source and staff software engineer at Apple Siri. He implemented several algorithms including linear models with Elastici-Net (L1/L2) regularization using LBFGS/OWL-QN optimizers in Apache Spark. Prior to joining Apple, DB worked on Personalized Recommendation ML Algorithms at Netflix. DB was a Ph.D. candidate in Applied Physics at Stanford University. He holds a Master’s degree in Electrical Engineering from Stanford.译文参考:蔡東邦老师是 Apache Spark PMC / Committer,同时也是 Apple Siri 的主任工程师。他将多个算法应用到了 Apache Spark 当中,包括使用了 LBFGS / OWL-QN 优化器 的 Elastici-Net(L1 / L2)正则化的线性模型。在加入 Apple Siri 之前,蔡老师在Netflix从事个性化推荐机器学习算法的研究工作。目前是斯坦福大学应用物理专业的博士候选人,也获得了斯坦福大学电气工程硕士学位。内容介绍Making Nested Columns as First Citizen in Apache Spark SQLApple Siri is the world’s largest virtual assistant service powering every iPhone, iPad, Mac, Apple TV, Apple Watch, and HomePod. We use large amounts of data to provide our users the best possible personalized experience. Our raw event data is cleaned and pre-joined into an unified data for our data consumers to use. To keep the rich hierarchical structure of the data, our data schemas are very deep nested structures. In this talk, we will discuss how Spark handles nested structures in Spark 2.4, and we’ll show the fundamental design issues in reading nested fields which is not being well considered when Spark SQL was designed. This results in Spark SQL reading unnecessary data in many operations. Given that Siri’s data is super nested and humongous, this soon becomes a bottleneck in our pipelines.Then we will talk about the various approaches we have taken to tackle this problem. By making nested columns as first citizen in Spark SQL, we can achieve dramatic performance gain. In some of our production queries, the speed-up can be 20x in wall clock time and 8x less data being read. All of our work will be open source, and some has already been merged into upstream.参考译文:Apple Siri是世界上最大的虚拟助理服务,为每部 iPhone,iPad,Mac,Apple TV,Apple Watch 和 HomePod 提供服务支持。我们使用大量数据来为用户提供最佳的个性化体验。所有的原始事件数据被清理并预先加入到统一数据中,供我们的数据使用者使用。为了保持数据的丰富层次结构,我们的数据模式采用了非常深的嵌套结构。在本次演讲中,我将讨论 Spark 如何处理 Spark 2.4 中的嵌套结构,还会展示读取嵌套字段时的基本设计问题,这些问题在设计 Spark SQL 时并未得到充分考虑。这就导致了 Spark SQL 在许多操作中读取不必要的数据。鉴于 Siri 超级嵌套的数据非常庞大,它很快就成了瓶颈所在。之后,我会介绍为解决这个问题所采取的各种方法。将嵌套列作为 Spark SQL 中的第一个公民,在性能上获得显着的提升。在我们的一些生产查询中,加速20倍,读取的数据减少8倍。我们所有的工作都将开源,有些已经合并到了核心区域。

    2019 年 7 月 26 日

  • 62|Apache Hive 集成

    2020 年 11 月 12 日

  • Flink 如何取代 JStorm,成为字节跳动流处理唯一标准?

    本文将为大家展示字节跳动公司将 Jstorm 任务迁移到Apache Flink 上的整个过程以及后续计划。你可以借此了解到字节跳动公司引入Apache Flink 的背景,Apache Flink 集群的构建过程,如何兼容以前的 Jstorm 作业以及基于Apache Flink 构建一个流式任务管理平台,本文将一一为你揭开这些神秘的面纱。

  • 实时计算在有赞的实践——效率提升之路

    有赞是一个商家服务公司,提供全行业全场景的电商解决方案。在有赞,大量的业务场景依赖对实时数据的处理,作为一类基础技术组件,服务着有赞内部几十个业务产品,几百个实时计算任务,其中包括交易数据大屏,商品实时统计分析,日志平台,调用链,风控等多个业务场景,本文将介绍有赞实时计算当前的发展历程和当前的实时计算技术架构。

  • 基于 Hadoop 的 58 同城离线计算平台设计与实践

    本文介绍大数据平台离线计算和探讨58在离线计算平台建设实践的思路、方案和问题解决之道。

  • 大数据分析引擎 Apache Flink 升级成为 Apache 顶级项目

    Apache Flink是一个高效、分布式、基于Java实现的通用大数据分析引擎,它具有分布式 MapReduce一类平台的高效性、灵活性和扩展性以及并行数据库查询优化方案。从Apache官方博客中得知,Flink已于近日升级成为Apache基金会的顶级项目。

  • 京东 Flink 优化与技术实践

    京东于2018年开始基于Flink+K8s深入打造高性能、稳定、可靠、易用的实时计算平台,支撑了京东内部多条业务线平稳度过618、双11多次大促。

  • 比拼生态和未来,Spark 和 Flink 哪家强?

    在前一篇文章《Spark 比拼 Flink:下一代大数据计算引擎之争,谁主沉浮?》中,作者对 Spark 和 Flink 的引擎做了对比。但对于用户来说,引擎并不是考虑数据产品的唯一方面。开发和运维相关的工具和环境、技术支持、社区等等,对能不能在引擎上面做出东西来都很重要,这些构成了一个产品的生态。可以说,引擎决定了功能和性能的极限,而生态能让这些能力真正发挥出作用。

  • 持续交付中流水线构建完成后就大功告成了吗?别忘了质量保障

    如果我们将注意力集中到具体的动作和问题上,会更有利于我们理解,而不是从一开始就被概念性的术语和框架束缚住。

    2018 年 2 月 9 日

  • 数据处理框架:批处理还是流处理?

    在这一讲中,我介绍了物联网系统的两类数据处理框架,批处理和流处理,顺便讲了很多大数据处理技术的起源和设计思想。

    2020 年 11 月 30 日

  • 流计算与消息(二):在流计算中使用 Kafka 链接计算任务

    Kafka和Flink都提供了保证Exactly Once的特性,配合使用可以实现端到端的Exactly Once语义。

    2019 年 10 月 3 日

  • 实时计算在有赞的实践 - 效率提升之路

    本文来自《2019年有赞技术大礼包》系列。

发现更多内容

我是合适的人选么?

escray

学习 面试 面试现场

终于可以职业规划了么?

escray

学习 面试 面试现场

一看就懂的三次握手

书旅

TCP 三次握手 操作系统 协议族

Flink的2种部署模式-2

小知识点

scala flink 大数据技术

我喜欢的工作,喜欢我么?

escray

学习 面试 面试现场

小白程序员成长之路-准备篇

桃夭十一里

盲打练习 在线打字

区块链在新冠病毒爆发中将加速发展

CECBC区块链专委会

区块链技术 供应链 食品追溯

免费开源看板软件Wekan安装与使用记录

emuqi

Docker 效率工具 wekan 看板 任务管理

Week 11命题作业

Jeremy

如何通过技术面试?

escray

学习 面试 面试现场

Apache Pulsar 社区周报:08-08 ~ 08-14

Apache Pulsar

Apache Apache Pulsar 消息系统

firewalld 常用指令

wong

Firewalld

我以后去做什么,技术还是业务?

escray

学习 面试 职业规划 面试现场

Week 11 学习总结

Jeremy

四十不惑,准备面试

escray

学习 面试现场

为什么考研,考研能给你带来什么?说说我的感受!

我是程序员小贱

企业品尝新基建的美酒前,需要名为NetEngine 8000的酒杯

脑极体

简单交互式页面的思考(C)

Alex

指针 C语言 交互设计

迟到的"松鼠"

许学文

个人感悟

对于结果不同程度的追求,决定了这个人的身价

非著名程序员

程序员 个人成长 思维模型 结果思维

公司想要大龄程序员么?

escray

学习 面试现场

架构设计篇之云计算服务设计与决策

小诚信驿站

云计算 刘晓成 企业架构和云服务 SaaS/IaaS/PaaS

Python中的bytes、str以及unicode区别

王坤祥

Python Python PEP

学习笔记丨Makefile的基本编写与优化

Liuchengz.

c Linux makefile

搞一搞Elasticsearch

北漂码农有话说

区块链政策区域特征分明 产业园区渐成聚集效应

CECBC区块链专委会

区块链 新基建

数据库快速迁移10亿级数据

架构师修行之路

高并发系统设计 数据库优化

辗转相除法求最大公约数(C语言实现)

InfoQ_3f366696ed0c

C语言

究竟要找什么样的工作?

escray

学习 面试 面试现场

大数据技术发展(三):Spark 代替 Hadoop ? Spark Or Flink ?

抖码算法

Java 大数据 flink hadoop spark

Docker 的前世今生

哈喽沃德先生

Docker 容器 微服务 虚拟化 容器化

打造 VUCA 时代的 10 倍速 IT 团队

打造 VUCA 时代的 10 倍速 IT 团队

58同城基于Flink的千亿级实时计算平台架构实践-InfoQ