58同城实时计算平台架构实践

本文主要介绍了58个城市实时计算平台和基于Flink的一站式实时计算平台Wstream的技术演变，涵盖了大量的实践经验、干货和方法论，希望能对您有所帮助。

背景

58城市是一个服务平台，覆盖生活的所有领域，包括招聘、房地产、汽车、金融、二手和当地服务等。丰富的业务线和大量的用户每天都会产生大量的用户数据，这需要实时计算和分析。实时计算平台的定位是为集团海量数据提供高效、稳定、分布式实时计算的基本服务。本文主要介绍Flink在58个城市建立的一站式实时计算平台Wstream。

实时计算场景

像许多互联网公司一样，58岁的实时计算有着丰富的场景需求，主要包括以下类:

1.实时数据ETL

实时消费卡夫卡数据，用于下游计算处理的清洗、转换和结构处理。

2.实时数仓

实时数据计算、仓库模型处理和存储。实时分析各种业务和用户指标，使操作更加实时。

3.实时监控

系统和用户行为的实时检测和分析，如业务指标的实时监控、运维的在线稳定性监控、财务风险控制等。

4.实时分析

功能平台、用户肖像、实时个性化推荐等。

平台演进

在实时计算平台的建设过程中，主要是跟踪开源社区的发展和实际的业务需求。计算框架经历了从风暴到火花流再到Flink的发展。同时，构建一站式实时计算平台，以提高用户实时计算需求开发的在线管理监控效率，优化平台管理。

实时计算引擎是在早期基于风暴和火花流构建的。在许多情况下，它不能很好地满足业务需求。例如，商业部门基于火花流(Spark Streaming)构建的功能平台希望将计算延迟从分钟级降低到第二级，从而改善用户体验。运维监控平台基于暴风分析公司的完整引擎日志监控在线业务，需要二级甚至毫秒级的延迟，暴风的吞吐量成为瓶颈。同时，随着对实时和丰富场景需求的增加，在追求高吞吐量和低任务延迟的基础上，对计算过程中的中间状态管理、灵活的窗口支持和一次语义保证的需求也越来越多。Apache Flink是开源的，它支持高吞吐量和低延迟架构设计以及高可用性稳定性。同时，它具有实时计算场景的一系列特征，并支持实时Sql模型，这使得我们决定采用Flink作为下一代实时计算平台的计算引擎。

平台规模

实时计算平台目前主要基于暴风/火花流/Flink，集群中共有500多台机器，日数据处理量为6000亿，其中Flink在近一年的建设后已经达到了50%的任务。

Flink稳定性

Flink作为一个实时计算集群，需要比离线计算集群高得多的可用性。为了保证集群的可用性，平台主要采用任务隔离和高可用性集群架构来保证稳定性。

任务隔离  

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

集群架构

Flink集群在开纱模式下独立部署。为了减少集群的维护工作量，底层hdfs使用公司统一的HDFS联邦架构建立独立的命名空间，以减少检查点使用hdfs/rocksdb作为状态存储后端时，由于HDFS抖动导致的Flink任务频繁异常故障。在资源隔离层面，引入节点标签机制(Node Label mechanism)，实现重要任务在独立的机器上运行，具有不同计算属性的任务在合适的机器上运行，从而最大化机器资源的利用率。同时，Cgroup是在CHANK资源隔离的基础上增加的，用于物理cpu隔离，减少了任务间抢占的影响，保证了ta的稳定性

平台化管理

流式sql能力建设

2支持自定义DDL语法(包括源表、输出表和维度表)。支持自定义UDF/UDTF/UDAF语法

3。实现流程表和维度表的连接。双流join

支持大数据的开源组件，也开启了公司的主流实时存储平台。同时，它为用户提供了基于Sql客户端的cli模式，并支持Wstream中集成的实时sql功能。它还为用户提供了一个在线开发和调试sql任务的编辑器。同时，它支持代码高亮、智能提示、语法验证和运行时验证，以尽可能避免用户提交给集群的任务出现异常。此外，它还为用户提供了一种引导配置模式，解决了用户在定义表时需要知道复杂参数设置的问题。用户只需要关心业务逻辑处理，并使用sql来开发像离线Hive这样的实时任务。

Storm任务迁移Flink

在改进Flink平台建设的同时，我们还启动了暴风任务迁移Flink计划，旨在提高实时计算平台的整体效率，降低机器成本和运行维护成本。弗林克风暴(Flink-Storm)，作为一个官方的弗林克兼容风暴计划，为我们提供了实现无缝迁移的可行性。然而，作为测试版，在实际使用过程中有许多情况不能满足实际情况。因此，我们做了很多改进，主要包括在纱线上实现风暴任务、迁移后至少一次任务的语义保证以及风暴兼容的记号元组机制等。

通过芬克风暴的优化，我们在不需要用户修改代码的基础上，成功完成了集群多个风暴版本的任务迁移和离线。在确保实时性能和吞吐量的基础上，我们可以节省40%以上的计算资源。同时，我们不需要维护多个风暴集群来用纱线管理实时计算平台，从而提高平台资源的整体利用率，减少平台运行维护的工作量。

任务诊断

指标监控

Flink webUI为用户提供了大量运行时信息，以了解任务的当前运行状态。但是，用户无法获得历史指标的问题导致用户无法知道任务的历史运行状态。因此，我们采用Flink支持的普罗米修斯(Prometheus)来收集和存储实时指标。普罗米修斯是一个开源的监控和警报系统，通过pushgateway实时向度量报告。普罗米修斯集群采用分布式部署模式。元节点定期抓取所有的子节点指示器进行汇总，便于向格拉瓦纳提供统一的数据源进行可化和报警配置。

任务延迟

吞吐量容量和延迟是衡量实时任务性能的最重要指标。我们经常需要通过这两个指标来调整任务并发性和资源分配。Flink Metrics提供了延迟跟踪时间参数来启用任务延迟跟踪。打开它将显著影响集群和任务性能。强烈建议仅在调试下使用。在实践场景中，Flink任务的数据源基本上是卡夫卡，所以我们使用话题消费积累作为衡量任务延迟的指标。监控模块通过Flink rest实时获取任务正在消耗的主题偏移量，同时通过卡夫卡JMX获取相应主题的日志大小，并使用日志大小偏移量作为主题的累积。

日志检索

Flink被用作分布式计算引擎。所有任务都将由CHANK统一分派到任何计算节点。因此，任务的运行日志将分布在不同的机器上。用户很难找到日志。我们调整log4j日志框架的默认机制，每天拆分任务日志，并定期清理过期日志。避免计算节点因异常任务频繁填满磁盘而不可用的情况。同时，在所有计算节点部署代理实时收集日志，聚合并写入卡夫卡，通过日志分发平台实时向专家系统分发数据，方便用户搜索和定位日志。

Flink优化

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

1。风暴任务要求风暴引擎提供确认机制，以保证消息传递至少一次的语义。迁移到Flink时，不能使用ack机制。我们实现了与检查点相关的集成

2.Flink 1.6建议使用与插槽相对应的任务管理器。当申请资源时，根据最大并发性应用相应数量的任务管理器。这导致了设置任务槽后要应用的资源大于实际资源的问题。当资源管理器请求资源管理器插槽管理器时，我们会添加任务管理器批次相关信息来维护要分配的应用任务管理器和插槽。之后，我们不会直接为插槽请求申请任务管理器。相反，在启动新的任务管理器之前，我们首先从插槽管理器申请是否有足够的插槽，从而实现申请资源等于资源的实际消耗，避免资源充足时任务无法启动。

3。Kafak连接器经过改造，增加了自动换行功能。此外，对于08source无法设置client.id，client.id生成机制被优化为更有意义的id。卡夫卡控制

4很方便，flink提交任务不支持第三方依赖jar包和配置文件供TaskManager使用。我们通过修改Flink启动脚本和添加相关参数来支持外部传输文件，然后在任务启动期间将相应的jar包和文件添加到类路径中。借助纱线的文件管理机制，实现了类似spark的相应使用模式，方便用户使用

5。在业务场景中有大量的实时hdf编写需求。Flink自己的BucketingSink默认情况下只支持字符串和avro格式。在此基础上，我们同时支持LZO和拼花格式写作，大大提高了数据写作性能。

后续规划

实时计算平台目前正在迁移Flink集群进行风暴任务，已经基本完成，大大提高了平台资源的利用率和计算效率。以下将继续调查和改进Flink的相关能力，并促进Flink在更实时场景中的应用，包括实时规则引擎、实时机器学习等。