摘要：本文整顿自美的团体实时数据负责人、资深数据架构师董奇，在 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 复用，来加重更多存储和计算资源的节约。
点击查看直播回放 & 演讲 PPT
更多内容
流动举荐
阿里云基于 Apache Flink 构建的企业级产品 - 实时计算 Flink 版现开启流动：
99 元试用 实时计算 Flink 版（包年包月、10CU）即有机会取得 Flink 独家定制卫衣；另包 3 个月及以上还有 85 折优惠！
理解流动详情：https://www.aliyun.com/produc…