贝壳基于 Flink 的实时计算演进之路

摘要：贝壳找房大数据平台实时计算负责人刘力云带来的分享内容是贝壳找房的实时计算演进之路，内容以下：

1. 发展历程
2. 平台建设
3. 实时数仓及其应用场景
4. 事件驱动场景
5. 将来规划

GitHub 地址
https://github.com/apache/flink
欢迎你们给 Flink 点赞送 star~

1、发展历程

首先是平台的发展历程。最先是由于业务方在实时计算方面有比较多的业务场景，包括业务方自研的实时任务，须要自行开发、部署及维护，咱们的大数据部门也会承接客户大数据的实时开发需求。

这些看起来都是一些烟囱式的开发架构（即每一个业务线之间由不一样的开发团队独立建设，技术栈不一样，互不联系），缺少统一的任务管控，也很难保留开发过程当中积累的技术沉淀。所以，咱们在 18 年时上线了基于 Spark Streaming 的实时计算平台，统一部署管理实时计算任务。以后咱们又在此基础上提供了任务开发功能 - 标准化的 SQL 语言（SQL 1.0），以提升数据开发效率。

随着咱们承接的任务愈来愈多，咱们也发现了 Spark Streaming 的一些使用问题，主要是其 Checkpoint 是同步的，有时会形成比较大的延迟。此外，Kafka 消费的 Offset 数据存在 Checkpoint，很难作到任务细粒度的监控，好比消费状态的获取，因而咱们开始转向 Flink。

19 年，咱们的平台开始支持 Flink 任务，而且很快提供了基于 Flink 1.8 的 SQL 2.0 功能，包括 DDL 定义和维表关联。接下来，在 SQL 2.0 的基础上，咱们开始了实时数仓的建设。

今年初，在收集了业务方的需求场景后，咱们认为在实时事件处理方面需求明确，并且目前的实现也存在较多的弊端，所以咱们开始着手事件处理平台的开发。今年发布的 Flink 1.11 在 SQL 方面有很大的提高，咱们在其基础上正在开发一套统一的 SQL（3.0）。

目前平台支持的部门涵盖了贝壳绝大部分的业务方，支持各类场景，包括人店相关的房源、客源、经纪人、风控以及运营等。

目前平台支持的项目有 30 多个。在 SQL2.0 后，平台上的任务数有明显增加，达到 800 多个。因为贝壳全部的流量数据、用户行为分析、以及数仓的建设都是经过平台来构建的，因此数据量很大，天天处理的消息达 2500 亿条，单任务的消息吞吐量峰值达 3 百万。

这是咱们平台任务的增加状况，能够明显看到 19 年 10 月 SQL 2.0 上线且支持实时数仓开发后，任务增加势头显著。

2、平台建设

平台的功能概览包括四个方面：

• 支持任务托管的基本能力，包括任务的编辑发布、版本管理、监控报警等；
• 支持多种语言的实时任务，包括对贝壳算法相关的 Python 实时任务的良好支持；
• 根据业务场景不一样，支持多种业务类型，如自定义任务、模板任务及场景任务（SQL 任务），内部通用配置化任务，如分流合并操做。目前 SQL 任务在平台占比较高，咱们的目标是 80%；
• 支持公共队列（针对较数据量小的需求），对于数据量大的需求，要有稳定的资源保证，咱们能够提供专有队列，运行更为可靠。

平台的总体架构与其它公司的差很少。底层是计算和存储层，计算支持 Flink 和 Spark，主要包括消息队列和各类 OLAP 存储，同时也支持 MySQL，Hive 也能够作到实时落地，维表支持 Redis，HBase 存储。ClickHouse 是目前主要的实时 OLAP 存储，因为 Doris 支持 update，同时对关联查询的支持也比较好，咱们也在尝试 Doris 存储。

引擎层主要封装的是 SQL 引擎、DataStream 的通用性操做。在事件处理方面，对 Flink 的 CEP，包括对其它普通规则也作了较好的封装。

开发管理层提供了各类任务的开发、监控和资源管理。

平台之上，也是提供了对 ETL、BI、推荐、监控、风控等各类业务场景的支持。

这是平台任务生命周期的管理。能够看到，在启动后会新建实例，从集群拿到运行状态后会判断是否正常运行。“是”则转成运行中状态。在运行过程当中会对任务作延迟和心跳的监控；若是说任务发生了异常，而且在配置中设置了延迟或心跳时长的阈值，则会尝试进行重启。用户能够在启动任务时设置重启次数，当超过该值时，则认为重启失败，将发送告警给任务负责人。

这是平台监控报警的架构。咱们在 Spark 引入了 sdk 依赖，在用户开发任务时用代码显示添加就能够监听系统关心的指标。Flink 任务支持自定义 Reporter 的 metrics 的获取。咱们还支持 java agent 的依赖注入，经过依赖注入咱们能够获取实时任务的制定信息。在 Hermes 平台，咱们能够拿到这些监控信息，来支持延时报警、心跳报警、及数据血缘基础上的流量分析，后续的有状态任务恢复也依赖这些监控指标。监控日志落入存储（InfluxDB）以后能够进行可视化处理，方便的查看历史运行状态。

这是平台监控查看页面，分别显示了数据读入、写出、及延时的状况。

3、实时数仓

咱们的实时数仓目前具有如下几方面能力：首先是完善的元数据管理，包括链接管理和表管理；数仓开发人员共同构建了数据分层架构，包括 4 个分层：

• 在实时侧，分层越少越好，不然中间环节越多，出问题的几率越大；
• 在 SQL 层面，支持标准的SQL语法，维表关联，提供图形化的SQL开发环境。另外还支持丰富的内置函数，并逐步完善支持用户自定义函数（UDF）的开发；
• 数据血缘方面，平台支持图形化展现和完善的链路分析，并且能实时看到数据流的运行状况并对异常进行标示；
• 最后是多源支持，对公司内部用到的各类存储作到了较好的支持。

这是简易的实时数仓架构图，整体来讲是属于 Lambda 架构，包括实时流和离线流，以及离线流对实时流数据覆盖的修复。从用户行为日志、后端服务器日志及业务数据库采集来的消息流，汇入并经过 ODS（Opertional Data Source）层再到 DW（Data Warehouse）层，咱们支持 ODS 和 DW 层对维度进行扩充，关联维表。

目前 DWD（Data Warehouse Detail）层的数据直接送入 ClickHouse，ClickHouse 如今是咱们 OLAP 引擎的一个主力存储。从 DWD 到 ClickHouse 的存储只知足了部分业务场景，还存在一些问题。好比咱们须要作数据汇总，那么咱们如今 DWS（Data Warehouse Service）层在这方面还稍微欠缺。目前明细数据进入了 ClickHouse，咱们首先对那些应该汇总的数据存了明细，这样会致使存储量比较大，查询效率较低。后续咱们会考虑引入 Doris，由于它能够在实时计算侧作实时聚合，依托 Doris 对 Update 的支持，就能够完善 DWS 功能。

这里展现的是咱们的 SQL 编辑器。能够看到左边是正在编辑的 SQL，咱们支持 Flink 执行计划的查看、任务调试。右侧一列能够定义源表、维表、输出表。能够在自定义的数据源基础上定义流表，并自动生产 DDL。同时，对于某些自动生成 DDL 难以支持的场景，用户能够在左边的编辑区域自行编写 DDL。

任务调式分为手动和自动两种方式。手动方式需准备样例数据，拷贝到开发界面；自动方式则会从 SQL 任务的上游获取样例数据。元数据信息（kafka、HBase、ClickHouse 等）是动态得到的，元信息和样例共同生成的 DebugSQL 去调用 SQL 引擎的公共服务。SQL 引擎获得样例数据后，好比，若是有关联维表的操做，则会关联线上维表，在 SQL 引擎中执行调试，将结果送给 UI 端进行展现。

这是一个完整的调试界面，能够看到左侧是自动获取的样例数据，右侧是下游的输出。

根据元数据的定义及上报的指标等监控数据，咱们能够生成一个实时数据血缘链路。图中的箭头展现了数据流转的健康情况，将来会对血缘链路上的数据监控作得更细致。数据血缘知足了 4 个方面的需求：溯源分析、问题排查、数据差别分析、提高用户体验。在血缘链路上还能够进行比较复杂的异常预警，例如，数据源字段的变动对下游的影响。

这是咱们 SQL2.0 引擎的大体架构，经过 Antlr4 扩展标准 SQL 的语法，从而支持 Flink 的各类源，维表和下游存储表的定义。经过 SqljobParser 内置的 SqlStmtParser 生成 SqlContext，在逻辑计划（Logical Plan）中作解析。若是遇到维表，则通过一系列维表关联的流程。上图中下半部分是底层 API 架构。

这是平台 DDL 样例。对于源表（Source），支持 Kafka，将来在新版本的 Flink 之上将能够支持更多种源。对于维表（Dim），支持 HBase、Redis、MySQL。数据存储表（Sink）支持图中所列五种。表格下面的是 DDL 定义的语法规则，右边是一些表定义的样例，分别是 Kafka 源表、维表和输出表（输出到控制台）。

再看咱们的维表关联，从 SQL 引擎结构能够看出，输入的 SQL 进行解析，当有维表关联时（包含 join 字段），咱们会从语法层面作转换。咱们在表的层面定义了流和维关联以后的表的形态，左下角是其生成过程。关联维表、流维转换、用异步 IO 获取数据等过程不在这里细说。

随着 Flink 社区新版本的发布，在 SQL 方面的支持愈来愈强，咱们目前正在作基于 Flink1.11 的新版 SQL 引擎，也会将以前的 SQL 引擎统一。由于 Flink1.11 支持DDL，因此这部分咱们不会再作，而是直接使用其新特性：

• 解析模块（Parse Model）将用户原始的 SQL 解析成内部的执行计划，彻底依赖于 Flink SQL。Connector Model 完成目前 Flink 还没有支持的 Connector 开发。
• Format Model 实现数据源字段的序列化和反序列化。
• 执行模块（Execute Model）基于 Flink1.11 SQL API 执行解析后的执行计划。
• UDF 模块是专门处理 UDF 的解析，如参数调用的合法验证、权限验证、细致的数据权限限制。
• SDK Model 是对外提供的标准化服务，如 SQL 文本开发的验证，debug 功能等。

这是实时数仓的一个落地场景：交易的实时大屏，也是咱们第一个落地的典型业务场景。咱们支持各类交易实时指标，用户能够经过实时查询 ClickHouse 获得交易数据的各类图表展现。

客户实时热力图是咱们正在跟业务方沟通的一个需求场景，能实时获取用户线上的行为，使经纪人对客户行为有一个比较全面的实时掌控，促进客户维护的转化率。另外一方面，也使客户更方便地了解房源热度状态，促使用户作出购买决策。

4、事件驱动

先了解一下事件驱动型和数据分析型的区别：

• 事件驱动是根据事件流中的事件实时触发外部计算和外部状态的更新，主要关注实时事件触发的外部变化，重在单独事件以及外部动做的触发。
• 数据分析型主要是从原始数据中提取有价值的信息，重在分析。

在咱们跟业务方的沟经过程中，咱们发现不少场景中他们但愿实时获取用户的行为。比较典型的是风控场景，根据用户线上的行为模式判断其是否触发风控规则。此外，咱们的实时运营，根据用户线上行为给用户进行积分的增长及信息推送。搜索推荐也是咱们很是关心的，即用户在搜索以前的实时行为。综合这些，咱们提取出三方面问题：

• 一是用户行为事件缺少统一的抽象和管理，开发效率低，周期长，各部门存在重复建设；
• 二是规则逻辑与业务系统是耦合的，难以实现灵活的变化，对于复杂的规则或场景，业务方缺少相关的技能和知识储备，如对 CEP 的支持；
• 第三是缺少统一的下游动做触发的配置。

基于以上三个痛点，咱们构建了事件处理平台，抽象成三个模块，事件管理，规则引擎和动做触发。

这是事件处理平台所支持的业务场景。

这是事件处理平台的架构，整体来讲就是管理模块，引擎和动做触发。在中间这里咱们提供了一个适配层，能够跟第三方系统进行集成。

这是咱们事件处理的操做流程，首先是建立数据源，与实时计算平台相似，主要支持 Kafka，在 Kafka 消息流上定义咱们的数据格式。

在数据源基础上建立事件流，事件流包含了同类事件，咱们实现了一些算子，能够在数据源的基础上作一些操做。从右侧能够看到，在多个数据源上进行了一些过滤、加解密的操做，最终经过 union 算子汇总成一个统一格式的同类事件的事件流，方便后续使用。

在事件流的基础上能够定义单个的事件，以后能够建立事件组，以对接咱们的业务含义，即明确具体的业务是作什么的，如用户的点击、浏览、分享、关注等事件。建立事件组有两种方式：

• 一是本地方式，便可以根据事件的各个字段和维度设定条件；
• 二是远程方式，这与咱们的埋点系统（用户行为日志）直接连通，能够直接获得用户事件的定义。

任务配置过程分几个部分，这是 log 监控的任务样例。上图展现的是事件处理的规则设置部分。这是一个 CEP 事件，能够定义事件窗口，获取具体事件，在此之上定义 CEP 的模式，还能够定义事件的输出，例如须要输出哪些字段。

这是触发动做调用，支持消息发送，服务调用及落地 Kafka。截图展现的是消息发送的样例。

5、将来规划

这是咱们实时计算的总体架构，下部是 Hermes 实时计算平台，主要包括任务管控、SQL 引擎、CEP 引擎等各类能力。Data Pipeline、实时数仓及事件处理平台的任务都是经过此平台进行管控。将来咱们计划作的是用户数据平台，如各业务方对用户的线上行为的历史查询，以及在全平台用户数据的综合分析。

对将来的规划主要有以上几个方向，包括状态的管理及恢复、动态的资源分配（动态的配置、动态的资源调整）。为了保持任务的稳定性，咱们在也计划在高可用性方面作一些调研。在流批一体方面，会借用数据湖的能力，提供对历史和实时数据的混合查询的支持。