网站平台建设心得,学设计师需要学历吗,有什么软件可以制作图片,搜索词和关键词摘要#xff1a;本文整理自美的集团实时数据负责人、资深数据架构师董奇#xff0c;在 Flink Forward Asia 2022 主会场的分享。本篇内容主要分为四个部分#xff1a; 实时生态系统在美的的发展和建设现状 核心传统业务场景 Flink 实时数字化转型实践 新兴业务场景 Flink … 摘要本文整理自美的集团实时数据负责人、资深数据架构师董奇在 Flink Forward Asia 2022 主会场的分享。本篇内容主要分为四个部分 实时生态系统在美的的发展和建设现状 核心传统业务场景 Flink 实时数字化转型实践 新兴业务场景 Flink 实时数字化应用实践 未来展望 Tips点击「阅读原文」查看原文视频演讲 ppt 01 实时生态系统在美的的发展和建设现状 纵观过去几年美的的实时大数据建设之路在实时数据技术架构演进过程中实时的应用阶段共分为五个阶段。 第一阶段初阶应用2017-2018。我们当时主要是有一些简单的业务数据清洗以及准实时前序的实时数据接入需求。因此当时就选择了 StreamSets 技术栈它有比较简单的可视化配置以及简单的代码逻辑加工可以完成相应的需求工作。因此在 2017-2018 阶段我们的阶段性总结就是初阶应用这一部分为准实时的计算加工链路去做相应的前序实时接入的准备。 第二阶段深入探索2018-2020。随着整体业务需求场景越来越复杂我们就不得不去探索更加适用的实时技术栈来支撑我们更加复杂的实时数据需求。我们当时的选型是 Spark Streaming但由于 Spark Streaming 的分布式比较复杂以及 Scala 晦涩难懂的语法糖。因此在 2019 年我们去做了 Spark StreamingSpark SQL 平台化的结合在此基础上去满足更加复杂的业务数据需求。但由于 Spark 分布式对应的 connector 还比较匮乏它对更加复杂的业务化场景支持力度不够以及它本质上还是微批的实时处理概念并不是真正的流处理。所以在 2020 年我们踏入了重新选型寻求更好的、更能满足业务场景的技术栈。 第三阶段重新选型2020-2021 年初。我们在 2020 年重新选型最终选择了 Flink DataStramRedis/HBase 整个一套结合的外部存储体系去管理状态去做技术栈的融合以及实现相对比较复杂的实时业务场景。当时基于这套架构我们也支持了设备数据的实时接入包括智能设备的实时自动调控以及实时的消息推送等等。但我们为什么在这个阶段最终选择 Redis/HBase 的外部存储还是因为沿用 Spark Streaming 原来的这套架构体系因为 Spark Streaming 的状态管理还是用外部存储去实现的且当时的研发同学对于 Flink 相关的了解并不够深入因此还是沿用了之前相应的外部存储的状态管理机制。 第四阶段稳定应用2021 年初-2021 年底。我们需要去寻求更加稳定的应用和更低的开发成本也基于对 Flink 的进一步深入了解在此基础上选型用了 Flink DataStreamRocksDB 状态存储管理策略真正实现了 Exactly Once 语义去做更简便的容灾恢复机制的实现同时也做到了真正 Flink 相关的稳定应用阶段的实现。 第五阶段体系建设2021 年底-2022 年底。我们由于 Flink DataStream 对于业务的支撑以及需求的快速迭代交付还是比较慢所以在 2021 年底我们去做了体系化建设。用 Flink SQL相应基础平台实时数仓建设去支撑我们所有的业务体系需求。在此基础上我们做了逻辑元数据的管理统一自定义的 connector统一自定义的 UDF预编译调试功能大状态任务相应 State 的自动优化长周期场景的支持以及相应的运维管理体系保障的可视化建设等。 目前数据源主要来源于四个部分分别是云端设备日志是针对 IoT 场景相关的埋点上报日志业务数据库日志算法加工数据以及其他第三方日志。 中间的实时研发平台主要分为三个模块分别是资源管理、任务管理、运维监控。 资源管理主要做元数据管理以及 UDF 和自定义数据源管理。 任务管理主要是 DataStream 和 SQL 任务的支持以及模板任务和物化视图的沉淀。简便了开发流程提供了固定逻辑的沉淀以及未来新同学做开发的时候它能够快速引用迭代起来。 运维监控主要做了告警自定义的规则配置以及通知信息的打通。再到下面可视化运维监控体系的打通也就是 Flink MetricsPrometheus 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 不变的情况下快速进行停止、重启的工作不需要回滚或重跑太久远的数据。 02 核心传统业务场景 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 之后需要和接口平台、服务平台进行打通做防下滑功能的设计和自定义出入参的设计最终放到大屏端做比较稳定、灵活、及时性的数据展示。 03 新兴业务场景 Flink 实时数字化应用实践 首先是家居设备实时智能调控场景这里我们举了三个例子分别是冰箱云管家、洗地机云管家、电热云管家。 冰箱云管家主要是根据用户的行为习惯包括冰箱开关门的次数、开关门的时间点、传感器的温度等等匹配相应的算法规则和算法模型做整个速冷模式的控制以达到节能的目的。 洗地机云管家主要根据自身的上报数据和用户的配置数据包括出水量、地理位置、第三方气候温湿度等数据信息分析用户使用的时间段控制出水量信息。当我们需要提前使用可以开启自动唤醒功能以达到节能的目的。 电热云管家主要根据自身的上报数据和用户的配置数据包括温度、地理位置、第三方气候温湿度等数据信息做用户行为分析。匹配算法模型的结果和规则做电热温度的自动调控、不同阶段使用温度的调整、峰谷夜电预加热的功能以达到节能和自动化调控的目的。 这一部分实时链路通过云端设备数据接入进来打通内部防火墙写到 Redis再通过 LogStash 读取 Redis 的数据写到 Kafka 供 Flink 消费。这里的 Flink 是用上面的第三方数据和规则数据写到 Redis 之后整体关联打通再把数据结果写回到 Kafka。通过 IoT 云做指令下发到达设备数据中完成智能设备自动调控的全流程体系的打通。 这一部分实现之后为了防止下发指令出现问题我们也做了同步的实时监控包括下发指令的错发、漏发、迟发等等。 说到自动调控功能就不得不提到为什么我们会搭配 Hi 服务实时消息推送的功能。因为很多功能虽然都可以实现自动调控但也有很多需要人机交互完成甚至有还需要人为操控完成的操作去满足更优的用户体验。所以我们才有了 Hi 服务实时消息推送功能去衔接智能场景化的服务。 Hi 服务实时消息推送功能主要覆盖了美的 40的品类最终实现了 169 个在线服务以及 1000在线规则。其中它有三个核心功能智能工程师、贴心小管家、懂你销售员。 智能工程师的功能包括故障提醒、安全提醒、异常提醒贴心小管家的功能包括完成提醒、清洁提醒以及忘关机提醒懂你销售员的功能包括耗材到期提醒、用户场景提醒、美食推荐提醒。产生这个功能的主要原因是有的用户对智能设备的了解程度并不多所以当我们发现你的多样性智能设备或者单一智能设备下有智能场景没有被应用我们就会做相应的推荐。比如在用了厨房相关的电器设备后我们会根据冰箱里的食材和烹饪工具给你一些美食相关的推荐。 这部分链路也跟上面很相似只是最终数据不会推送到 IoT 云而是推送到第三方推消息送平台再打通各个服务中心包括美居、美的服务以及其他小程序、手机短信、手机顶部消息弹送等等来进行消息推送。 这一部分我们也会做实时分析监控包括效果回收、体验分析、异常监控等等。效果回收是指我们推送给你消息后你的反馈是怎样的日活/月活表现是怎样的。 体验分析是指我们推送完后有多少用户觉得干扰然后取消了这些推送功能后续不再推送了然后根据统计的比例和量做进一步分析。 异常监控是指我们会防止太多消息推送对用户造成干扰所以我们会监控消息推送的量是否符合常态化标准。 在电商活动大屏监控的基础上我们原来是由各个运营在第三方电商平台包括淘宝、天猫、京东、拼抖快等等自己收集数据手工上报然后自己在 Excel 做聚合打通、联动分析把结果分析进来。比如我作为品类运营今年的 KPI 在大促活动几件全平台完成了多少哪里我还要去尽快调整等等这是全平台的运营分析需求。 所以在此背景下我们先做了业务数据化即把手工录入上报的数据通过我们的系统平台自动落到数据库里。然后根据数据库实时接入的数据感知大促的数据变化。通过 Flink 加工写到 StarRocks并把去年同期数据的引入维表用作对比分析放到 QBI 上。最后用 QBI 做各种分析内容的大屏搭建的展示从而给用户、运营更快、更直观的运营决策。 04 未来展望 基于我们现在实时生态体系建设包括应用场景还是有很多的痛点所以我们的短期的未来目标还是降本提效和工具赋能。 上图左侧是基础运维。 第一云原生架构部署。然后这一部分主要是做弹性扩缩容的探索。 第二集群热点机器自动均衡。对于新加的热点机器可以自动打通热点机器自动均衡包括磁盘的打散分类。 第三任务报错根因和修复策略提示。把运维更加智能化去提供基础运维更多的能力给上层。 我觉得好的平台不仅仅能帮助用户更快的提效还应该对使用的开发人员有指导作用。让他们根据平台能更好的发现自己任务的问题以及在过程中能学习到引擎底层、平台运维底层的知识。 上图右侧是平台和业务的展望。 第一希望基于 Flink 去做可视化配置集成工具的建设。 第二希望做细粒度资源配置的平台化打通来形成开发过程中任务稳定性的保障细粒度的控制资源放在哪些节点或者 operater 上会更好、更合适。 第三流批一体的实践。基于今天的背景离线数据的相应冗余计算浪费了我们太多的资源希望在引擎统一的基础上做流批一体的实践以及进一步做 state 层面的打通让离线算好的数据实时基于 state 复用来减轻更多存储和计算资源的浪费。 往期精选 ▼ 关注「Apache Flink」获取更多技术干货 ▼
