Apache Flink 实时计算在美的多业务场景下的应用与实践

摘要：本文整理自美的集团实时数据负责人、资深数据架构师董奇，在 Flink Forward Asia 2022 主会场的分享。本篇内容主要分为四个部分：本篇内容主要分为四个部分：

实时生态系统在美的的发展和建设现状

核心传统业务场景 Flink 实时数字化转型实践

新兴业务场景 Flink 实时数字化应用实践

未来展望

点击查看直播回放 & 演讲PPT

一、实时生态系统在美的的发展和建设现状

纵观过去几年美的的实时大数据建设之路，在实时数据技术架构演进过程中实时的应用阶段共分为五个阶段。

第一阶段，初阶应用（2017-2018）。我们当时主要是有一些简单的业务数据清洗，以及准实时前序的实时数据接入需求。因此当时就选择了 StreamSets 技术栈，它有比较简单的可视化配置以及简单的代码逻辑加工，可以完成相应的需求工作。因此在 2017-2018 阶段，我们的阶段性总结就是初阶应用这一部分，为准实时的计算加工链路去做相应的前序实时接入的准备。

第二阶段，深入探索（2018-2020）。随着整体业务需求场景越来越复杂，我们就不得不去探索更加适用的实时技术栈，来支撑我们更加复杂的实时数据需求。我们当时的选型是 Spark Streaming，但由于 Spark Streaming 的分布式比较复杂，以及 Scala 晦涩难懂的语法糖。因此在 2019 年我们去做了 Spark Streaming+Spark SQL 平台化的结合，在此基础上去满足更加复杂的业务数据需求。但由于 Spark 分布式对应的 connector 还比较匮乏，它对更加复杂的业务化场景支持力度不够，以及它本质上还是微批的实时处理概念，并不是真正的流处理。所以在 2020 年，我们踏入了重新选型，寻求更好的、更能满足业务场景的技术栈。

第三阶段，重新选型（2020-2021 年初）。我们在 2020 年重新选型，最终选择了 Flink DataStram+Redis/HBase 整个一套结合的外部存储体系去管理状态，去做技术栈的融合，以及实现相对比较复杂的实时业务场景。当时基于这套架构，我们也支持了设备数据的实时接入，包括智能设备的实时自动调控以及实时的消息推送等等。但我们为什么在这个阶段最终选择 Redis/HBase 的外部存储，还是因为沿用 Spark Streaming 原来的这套架构体系，因为 Spark Streaming 的状态管理还是用外部存储去实现的，且当时的研发同学对于 Flink 相关的了解并不够深入，因此还是沿用了之前相应的外部存储的状态管理机制。

第四阶段，稳定应用（2021 年初-2021 年底）。我们需要去寻求更加稳定的应用和更低的开发成本，也基于对 Flink 的进一步深入了解，在此基础上，选型用了 Flink DataStream+RocksDB 状态存储管理策略，真正实现了 Exactly Once 语义去做更简便的容灾恢复机制的实现，同时也做到了真正 Flink 相关的稳定应用阶段的实现。

第五阶段，体系建设（2021 年底-2022 年底）。我们由于 Flink DataStream 对于业务的支撑以及需求的快速迭代交付还是比较慢，所以在 2021 年底我们去做了体系化建设。用 Flink SQL+相应基础平台实时数仓建设，去支撑我们所有的业务体系需求。在此基础上，我们做了逻辑元数据的管理；统一自定义的 connector+统一自定义的 UDF；预编译+调试功能；大状态任务相应 State 的自动优化；长周期场景的支持；以及相应的运维管理体系保障的可视化建设等。

目前数据源主要来源于四个部分，分别是云端设备日志，是针对 IoT 场景相关的；埋点上报日志；业务数据库日志；算法加工数据以及其他第三方日志。

中间的实时研发平台主要分为三个模块，分别是资源管理、任务管理、运维监控。

资源管理：主要做元数据管理以及 UDF 和自定义数据源管理。
任务管理：主要是 DataStream 和 SQL 任务的支持，以及模板任务和物化视图的沉淀。简便了开发流程，提供了固定逻辑的沉淀，以及未来新同学做开发的时候，它能够快速引用迭代起来。
运维监控：主要做了告警自定义的规则配置，以及通知信息的打通。再到下面可视化运维监控体系的打通，也就是 Flink Metrics+Prometheus+ Grafana 这整一套内容。应用层主要分为两大部分，分别是实时数据服务和实时数据分析。
实时数据服务：主要是内部实现了统一的接口服务平台。在平台之上，我们可以做逻辑数据源的配置；统一数据服务单元的维护；实时逻辑结果表统一定义；实时逻辑接口定义。而其中，实时服务单元的维护其实就是统一来源表的维护。
实时数据分析可以分为汇总数据指标对接和明细指标对接两部分。汇总数据指标对接主要依赖多表关联查询，中间和 QBI 打通做数据集加工，最终进行汇总表数据指标对接的实时数据分析服务。明细数据表对接是单表查询的连接，数据源主要是 StarRocks 和 ClickHouse，在这基础上对接 QBI 实现明细报表的分析应用。

基于上面的内容，我们总结实时数仓体系建设的思路主要分为三大部分，第一是时效性，第二是稳定性，第三是灵活性。

时效性指时效性保障架构设计，从上图可以看到，实时数据源主要来源于左边四个部分，云端设备日志、Oracle 的数据库、MySQL 数据库、埋点上报日志。

离线数据源，是最终作为中间长周期的源表，以及实时任务中依赖的维表开发的数据源。业务系统通过 SQOOP 同步到 Hive 去和 Kafka 做 Union All 的源表长周期的引入，然后同步到 HBase 或者 Redis 做维表和实时计算打通的引入。

再到应用层的结果表，为保障时效性，对于小的单表我们在 MySQL 上提供数据服务应用，对于大的单表查询，在 StarRocks 之前我们是运用 ClickHouse 去做支撑的，所以在单表应用上，前序最终数据服务的赋能是用 ClickHouse 去做实现的。但由于今年我们的业务场景更加复杂，所以存在单表的查询场景，也会存在多表聚合关联查询的场景。在此需求背景下，我们整体引入了 StarRocks，用 StarRocks 支撑在线数据分析场景和多表联合查询数据应用场景来更好更灵活的去满足业务场景诉求。

稳定性的建设体系主要分为两个部分，开发阶段和运行阶段。

开发阶段主要做了数据源连通性校验、逻辑元数据表 WITH 参数格式校验、实时任务预编译校验、抽样数据 Debug 逻辑校验、大状态任务 RocksDB 磁盘路径动态查询分配。

运行阶段主要做了集群资源监控和告警、任务状态监控和告警、任务数据流量异常监控和告警、任务 Flink Metrics 监控运维告警。同时也跟我们内部的监控报警平台和体系打通，做到及时报警通知的功能。

灵活开发加工主要分为两个部分，资源管理和任务管理。

在资源管理方面，我们支持以下功能：

统一的元数据管理去做逻辑表全生命周期的维护，任务只需要做简单的 Import 引入，就可以支持元表的自动引用接入。在表侧我们也支持统一的快速克隆复制去满足特定场景的新增和修改。
统一的自定义 UDF 管理和自定义 Connector 管理。
统一的数据源管理和资源 JAR 包管理。
外部数据源的关联打通。在我们的平台上就可以直接查看 HBase、Kafka 等数据源表里的数据内容，做快速的校验和探查。

在任务管理方面，我们支持以下功能：

支持场景化的逻辑沉淀和公共逻辑沉淀。比如去重、前序统一的归一化处理，我们都可以把它统一的沉淀起来。多个任务只要统一引用一个模块的视图或者模板化的任务模板，就可以去做开发工作。
支持一键新增和修改，也是跟元表一样，在任务模块我们支持一键克隆和修改的功能。
支持预编译，Fail Fast 支撑语法和词法问题开发态的一键暴露。
支持任务调试功能，让我们在开发过程中，就可以发现计算逻辑或者开发逻辑的错误。
支持暂停、恢复功能，对于有状态的任务，可以做到 JobGragh 不变的情况下，快速进行停止、重启的工作，不需要回滚或重跑太久远的数据。

二、核心传统业务场景 Flink 实时数字化转型实践

第一个是 B 端长周期相关的场景，其主要分为两个核心场景，分别是美云销 APP 数据看板和全链路订单可视。

在传统行业，它的供应链以及订单的全链路是比较长的。以内销为例，从下单到下单审批，制造生产，中间的物料齐套，品质检验，物流发车，物流状态跟踪，整个流程节点多达 20 多个。如果在此基础之上，我们要回溯过去 1-2 年长周期订单状态的跟踪，对于实时的挑战还是比较大的。

到美云销 APP 数据看板这一部分，我们也需要回溯过去很久的数据，来供应整个代理商或者零售商，查看他们门店经营策略的数据情况，包括采购分析情况、销售分析情况、库存分析情况等等。所以基于这样的需求背景，我们设计了如上图左侧所示的实时开发架构链路。

因为 B 端长周期对于过去历史数据的引入，是通过业务库数据同步数据到 Hive 表里，然后 Hive 表里我们用 Flink 去对接之后去应用它的 Hive 表中分区表的概念。自动加载每一天分区新的全量数据，以及结合当天的 Kafka 实时增量数据做 Union All 的结合。最后输出给 Flink 计算逻辑做进一步逻辑加工，以及后续加工链路中维表打宽的内容扩展。所以在此链路上，我们需要用这样一套技术链路来支撑 B 端长周期场景的实现。

但由于实时和离线分布在两个不同的调度集群中，离线调度集群经常出现延迟的问题。为了解决这个问题，并且保证第二天业务能够在早上 8 点或 9 点之前看到实时数据内容。所以我们用存储去换计算时间的及时性，多加了一天 Kafka 的存储，把实时增量数据直接 Union All 到前一天的数据内容上，做续跑的加工，保障数据的实时性。

这样就可以做到，12 点的通讯表的自动逻辑切换工作，重点监控保障今天全增量准确的数据在 12 点之前产出，而不用去考虑原来的早上 7 点或者 8 点需要起夜去重跑处理离线表未能及时产出的问题，较大减轻团队同学凌晨值班的压力，保障对应任务的稳定性和及时性。

工厂生产进度的逻辑相对比较简单，因为它其实是从上面拆分而来的，是上面大的节点中的小节点。基于需求背景下，每天工厂的管理人员、小组长，或者是下面的开工员工，都可以实时看到自己每个小时当班的生产进度，去完成今天白班或者晚班的生产进度要求，它是实时大屏，所以在业务过程中就发挥了很大的价值。

所以在此基础上，我们会从 MES 系统数据接入实时数据进来，然后通过 OGG 同步到 Kafka。但是在 OGG 同步过来的数据会有一个问题，因为它是部分字段更新，所以它就需要今天的数据和原来的全量全行数据做补齐，再去写到 Kafka 里才能真正实现，今天拿到的实时计算数据是全面的，才能进行进一步的 Flink 逻辑加工。

在这一部分处理完之后，我们把数据写到 MySQL 里，通过接口服务平台供应到产品端使用。因为这一部分汇总完的数据量还比较小，所以总结来说就是常规的实时增量数据的计算跟踪场景，最终在接口侧进行复合指标加工来满足产品应用。

这个场景的背景是，中国区域/运营中心/事业部每年都会不定期举行酒会或者其他活动，组织美的的代理商、运营商零售商参与其中，并进行美的的抢单活动。这里面会有涉及到哪些策略的优惠内容呢？一般是参与酒会的代理商、运营商、零售商，可以拿到价格保障、供货保障，以及新品首发保障等。所以抢单活动还是比较关键的，同时对运营商完成年度或者月度的 KPI 也非常关键。

因此在现场我们就需要有大屏可以指导大家及时调整自己的运营策略，更好的展示活动热烈的氛围，让 B 端的代理商、零售商更好的开展零售活动或者抢单活动，最后进行套餐或者组装活动抢购的舒适体验。

这个场景和美云销全链路 APP 可视的场景非常相似，唯一的不同点在于，针对这个场景我们最终接入 StarRocks 之后，需要和接口平台、服务平台进行打通，做防下滑功能的设计和自定义出入参的设计，最终放到大屏端做比较稳定、灵活、及时性的数据展示。

三、新兴业务场景 Flink 实时数字化应用实践

首先是家居设备实时智能调控场景，这里我们举了三个例子，分别是冰箱云管家、洗地机云管家、电热云管家。

冰箱云管家主要是根据用户的行为习惯，包括冰箱开关门的次数、开关门的时间点、传感器的温度等等，匹配相应的算法规则和算法模型，做整个速冷模式的控制，以达到节能的目的。

洗地机云管家主要根据自身的上报数据和用户的配置数据，包括出水量、地理位置、第三方气候温湿度等数据信息，分析用户使用的时间段，控制出水量信息。当我们需要提前使用，可以开启自动唤醒功能，以达到节能的目的。

电热云管家主要根据自身的上报数据和用户的配置数据，包括温度、地理位置、第三方气候温湿度等数据信息，做用户行为分析。匹配算法模型的结果和规则，做电热温度的自动调控、不同阶段使用温度的调整、峰谷夜电预加热的功能，以达到节能和自动化调控的目的。

这一部分实时链路通过云端设备数据接入进来，打通内部防火墙，写到 Redis，再通过 LogStash 读取 Redis 的数据写到 Kafka 供 Flink 消费。这里的 Flink 是用上面的第三方数据和规则数据，写到 Redis 之后，整体关联打通，再把数据结果写回到 Kafka。通过 IoT 云做指令下发，到达设备数据中，完成智能设备自动调控的全流程体系的打通。

这一部分实现之后，为了防止下发指令出现问题，我们也做了同步的实时监控，包括下发指令的错发、漏发、迟发等等。

说到自动调控功能就不得不提到，为什么我们会搭配 Hi 服务实时消息推送的功能。因为很多功能虽然都可以实现自动调控，但也有很多需要人机交互完成，甚至有还需要人为操控完成的操作，去满足更优的用户体验。所以我们才有了 Hi 服务实时消息推送功能去衔接智能场景化的服务。

Hi 服务实时消息推送功能主要覆盖了美的 40+的品类，最终实现了 169 个在线服务以及 1000+在线规则。其中它有三个核心功能，智能工程师、贴心小管家、懂你销售员。

智能工程师的功能包括故障提醒、安全提醒、异常提醒；贴心小管家的功能包括完成提醒、清洁提醒以及忘关机提醒；懂你销售员的功能包括耗材到期提醒、用户场景提醒、美食推荐提醒。产生这个功能的主要原因是，有的用户对智能设备的了解程度并不多，所以当我们发现，你的多样性智能设备或者单一智能设备下，有智能场景没有被应用，我们就会做相应的推荐。比如在用了厨房相关的电器设备后，我们会根据冰箱里的食材和烹饪工具，给你一些美食相关的推荐。

这部分链路也跟上面很相似，只是最终数据不会推送到 IoT 云，而是推送到第三方推消息送平台，再打通各个服务中心，包括美居、美的服务以及其他小程序、手机短信、手机顶部消息弹送等等，来进行消息推送。

这一部分我们也会做实时分析监控，包括效果回收、体验分析、异常监控等等。效果回收是指，我们推送给你消息后，你的反馈是怎样的，日活/月活表现是怎样的。

体验分析是指，我们推送完后有多少用户感觉干扰，然后取消了这些推送功能，后续不再推送了，然后根据统计的比例和量做进一步分析。

异常监控是指，我们会防止太多消息推送对用户造成干扰，所以我们会监控消息推送的量是否符合常态化标准。

在电商活动大屏监控的基础上，我们原来是由各个运营在第三方电商平台，包括淘宝、天猫、京东、拼抖快等等，自己收集数据手工上报，然后自己在 Excel 做聚合打通、联动分析把结果分析进来。比如我作为品类运营今年的 KPI 在大促活动几件全平台完成了多少，哪里我还要去尽快调整等等，这是全平台的运营分析需求。

所以在此背景下，我们先做了业务数据化，即把手工录入上报的数据，通过我们的系统平台自动落到数据库里。然后根据数据库实时接入的数据，感知大促的数据变化。通过 Flink 加工，写到 StarRocks，并把去年同期数据的引入维表用作对比分析，放到 QBI 上。最后用 QBI 做各种分析内容的大屏搭建的展示，从而给用户、运营更快、更直观的运营决策。

四、未来展望

基于我们现在实时生态体系建设，包括应用场景还是有很多的痛点，所以我们的短期的未来目标还是降本提效和工具赋能。

上图左侧是基础运维。

第一，云原生架构部署。然后这一部分主要是做弹性扩缩容的探索。
第二，集群热点机器自动均衡。对于新加的热点机器，可以自动打通热点机器自动均衡，包括磁盘的打散分类。
第三，任务报错根因和修复策略提示。把运维更加智能化，去提供基础运维更多的能力给上层。我认为好的平台不仅仅能帮助用户更快的提效，还应该对使用的开发人员有指导作用。让他们根据平台能更好的发现自己任务的问题，以及在过程中能学习到引擎底层、平台运维底层的知识。

上图右侧是平台和业务的展望。

第一，希望基于 Flink 去做可视化配置集成工具的建设。
第二，希望做细粒度资源配置的平台化打通，来形成开发过程中任务稳定性的保障，细粒度的控制资源放在哪些节点或者 operater 上会更好、更合适。
第三，流批一体的实践。基于今天的背景，离线数据的相应冗余计算浪费了我们太多的资源，希望在引擎统一的基础上，做流批一体的实践，以及进一步做 state 层面的打通，让离线算好的数据，实时基于 state 复用，来减轻更多存储和计算资源的浪费。