摘要：贝壳找房大数据平台实时计算负责人刘力云带来的分享内容是贝壳找房的实时计算演进之路，内容如下：
- 倒退历程
- 平台建设
- 实时数仓及其利用场景
- 事件驱动场景
- 将来布局
GitHub 地址
https://github.com/apache/flink
欢送大家给 Flink 点赞送 star~
一、倒退历程
首先是平台的倒退历程。最早是因为业务方在实时计算方面有比拟多的业务场景，包含业务方自研的实时工作，须要自行开发、部署及保护，咱们的大数据部门也会承接客户大数据的实时开发需要。
这些看起来都是一些烟囱式的开发架构（即每个业务线之间由不同的开发团队独立建设，技术栈不同，互不分割），不足对立的工作管控，也很难保留开发过程中积攒的技术积淀。因而，咱们在 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 上线且反对实时数仓开发后，工作增长势头显著。
二、平台建设
平台的性能概览包含四个方面：
- 反对工作托管的根本能力，包含工作的编辑公布、版本治理、监控报警等；
- 反对多种语言的实时工作，包含对贝壳算法相干的 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）之后能够进行可视化解决，不便的查看历史运行状态。
这是平台监控查看页面，别离显示了数据读入、写出、及延时的状况。
三、实时数仓
咱们的实时数仓目前具备以下几方面能力：首先是欠缺的元数据管理，包含连贯治理和表治理；数仓开发人员独特构建了数据分层架构，包含 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 失去交易数据的各种图表展现。
客户实时热力求是咱们正在跟业务方沟通的一个需要场景，能实时获取用户线上的行为，使经纪人对客户行为有一个比拟全面的实时掌控，促成客户保护的转化率。另一方面，也使客户更不便地理解房源热度状态，促使用户做出购买决策。
四、事件驱动
先理解一下事件驱动型和数据分析型的区别：
- 事件驱动是依据事件流中的事件实时触发内部计算和内部状态的更新，次要关注实时事件触发的内部变动，重在独自事件以及内部动作的触发。
- 数据分析型次要是从原始数据中提取有价值的信息，重在剖析。
在咱们跟业务方的沟通过程中，咱们发现很多场景中他们心愿实时获取用户的行为。比拟典型的是风控场景，依据用户线上的行为模式判断其是否触发风控规定。此外，咱们的实时经营，依据用户线上行为给用户进行积分的减少及信息推送。搜寻举荐也是咱们十分关怀的，即用户在搜寻之前的实时行为。综合这些，咱们提取出三方面问题：
- 一是用户行为事件不足对立的形象和治理，开发效率低，周期长，各部门存在反复建设；
- 二是规定逻辑与业务零碎是耦合的，难以实现灵便的变动，对于简单的规定或场景，业务方不足相干的技能和常识储备，如对 CEP 的反对；
- 第三是不足对立的上游动作触发的配置。
基于以上三个痛点，咱们构建了事件处理平台，形象成三个模块，事件治理，规定引擎和动作触发。
这是事件处理平台所反对的业务场景。
这是事件处理平台的架构，总体来说就是治理模块，引擎和动作触发。在两头这里咱们提供了一个适配层，能够跟第三方零碎进行集成。
这是咱们事件处理的操作流程，首先是创立数据源，与实时计算平台相似，次要反对 Kafka，在 Kafka 音讯流上定义咱们的数据格式。
在数据源根底上创立事件流，事件流蕴含了同类事件，咱们实现了一些算子，能够在数据源的根底上做一些操作。从右侧能够看到，在多个数据源上进行了一些过滤、加解密的操作，最终通过 union 算子汇总成一个对立格局的同类事件的事件流，不便后续应用。
在事件流的根底上能够定义单个的事件，之后能够创立事件组，以对接咱们的业务含意，即明确具体的业务是做什么的，如用户的点击、浏览、分享、关注等事件。创立事件组有两种形式：
- 一是本地形式，即能够依据事件的各个字段和维度设定条件；
- 二是近程形式，这与咱们的埋点零碎（用户行为日志）间接连通，能够间接失去用户事件的定义。
工作配置过程分几个局部，这是 log 监控的工作样例。上图展现的是事件处理的规定设置局部。这是一个 CEP 事件，能够定义事件窗口，获取具体事件，在此之上定义 CEP 的模式，还能够定义事件的输入，例如须要输入哪些字段。
这是触发动作调用，反对音讯发送，服务调用及落地 Kafka。截图展现的是音讯发送的样例。
五、将来布局
这是咱们实时计算的整体架构，下部是 Hermes 实时计算平台，次要包含工作管控、SQL 引擎、CEP 引擎等各种能力。Data Pipeline、实时数仓及事件处理平台的工作都是通过此平台进行管控。将来咱们打算做的是用户数据平台，如各业务方对用户的线上行为的历史查问，以及在全平台用户数据的综合剖析。
对将来的布局次要有以上几个方向，包含状态的治理及复原、动静的资源分配（动静的配置、动静的资源调整）。为了放弃工作的稳定性，咱们在也打算在高可用性方面做一些调研。在流批一体方面，会借用数据湖的能力，提供对历史和实时数据的混合查问的反对。