Apache Flink 在AI时代的探索与发展

实时AI智能体 实时AI数据分析 实时AI数据分析 实时AI数据分析 智能推荐及时个性化推荐 情感分析实时内容分类打标、温度感知 RAG实时知识更新 引擎能力（阿里云实时计算Flink版） 场景介绍 实际案例某头部车企客户之声实时市场舆情分析 项目简介 VOC（VoiceofCustomer）应用场景，涵盖高层战略、产品介绍、试乘试驾、售后维修、召回、APP使用、论坛、车友会、会员体系、线上线下活动、权益使用等各种场景下，使用大模型进行语音和文字数据的结构化打标和处理工作，提供情感分析、信息提取、VOC标注、标签挖掘能力，用于舆情监控、活动介绍、售后维修等场景。 项目需求与痛点 •效率：传统的方式依靠靠人工抽检或者针对每个场景训练NLP小模型来应对，并发和吞吐较低，客户要求达到百万条推理/小时•效果：常见NLP小模型应对多数据源、多目标场景的泛化能力不足，无法满足所有需求•成本：要求在控制成本、不依靠堆积资源的前提下，满足生成效率的需求 方案价值与成果 •高吞吐:依托Flink+百炼+Kafka的流式推理架构，在Kafka分区数1200个、Flink并发度100时，可实现240万条数据/小时的处理效率，远超客户百万条每小时的预期。 •低成本：整条链路未大幅增加Kafka分区或Flink并发度，仅优化超时参数与异步吞吐•高精确度：借助FlinkAIFunction调用大模型能力，调用百炼做到高质量标签生成，提升后续标签挖掘、舆情分析等场景的准确度 •多种源端数据（评价文本）清洗后以Json格式推送至消息通道Kafka•Flink流式消费Kafka中数据，使用AIFunction异步httpcall形式调用百炼大模型服务，结果返回异步队列，将生成的三级标签数据回写至Kafka•Kafka中数据推送给下游业务消费，做进一步分析 实时AI智能体 事件驱动型AI智能体 特点与需求 WhyFlink? ApacheFlinkAgents https://github.com/apache/flink-agents FlinkAgents FlinkAgents 开源社区 FlinkAgents由阿里云主导发起，Ververica、Confluent、LinkedIn基于ApacheFlink开源社区合作共建。 Github仓库：https://github.com/apache/flink-agents 首个MVP版本计划与9月底发布，设计文档与开发计划，详见GithubDiscussion：https://github.com/apache/flink-agents/discussions 期待更多社区开发者的加入~！ THANK YOU 谢 谢 观 看 WeAreHiring!北京/上海/杭州xintong.sxt@alibaba-inc.com Hive数仓到Lakehouse的升级 从Hive离线数仓到Lakehouse架构 对象存储OSS(无限存储、高密度、冷热分层) Lakehouse：结构化与非结构化的融合 Lakehouse架构:Unify your Data, Analytics and AI 消除复杂化孤岛，简化数据资产 •Unified：管理结构化与非结构化数据，统一权限、存储、治理、共享。 •Open：开放元数据协议、开放表格式与文件格式、多引擎生态、不受专有格式和封闭生态系统的限制。 •Scalable：计算性能和存储成本的极致优化确保最低TCO，更好的Native计算，更优的冷热分层。 LakehouseCatalog：Data &AI的统一与开放的治理 PaimonRESTAPI的设计 HiveMetastore+Ranger是时候从深坑中出来了 PaimonRESTCatalog不仅仅是Paimon表 PaimonRESTCatalogUUID路径 •在开放数据湖仓架构中，多个计算引擎需共享元数据。UUID作为全局唯一标识符，可消除因自增ID导致的跨系统冲突风险，确保不同服务生成的目录对象（如表、分区）唯一可识别。 •比如简单的例子是删表再重建，如果这个时候用的文件名，可能会导致老的流作业写入错误的文件到新的表里面。 •UUID目录的设计，也可以用于异步延迟删除，比如删除表可以逻辑删除即可，文件可以在一天以后再删，加速且给个后悔药。 基于PaimonREST的多层API设计 PaimonVirtualFileSystem:访问Catalog内所有文件 •文件视图访问所有文件，使用真实对象名称。•统一权限管控，管理结构化与非结构化文件。•统一访问接口，使用VFS屏蔽底层存储介质。•丰富生态，Hadoop、Python、Rust、Fuse。 PaimonRESTAPI目标与愿景 REST体系的核心目标是结合全托管计算引擎提供Lakehouse架构，打破数据孤岛，提供一个统一的数据平台，既能像数据湖一样低成本存储多模态数据（如文本、视频、时序数据），又能像数据仓库一样支持高性能查询、ACID事务和严格的数据治理。通过开放生态和分层架构，实现“One Data, All Analytics”。 RESTServer：以DLF为例 PaimonRESTServer的架构：以DLF为例 •开源开放，基于标准REST+标准OSSSDK，适配湖表和文件管理场景•新一代REST网关，接口访问时延比起DLF1提升10倍以上 RESTServer企业级安全权限 用户管理 •原生支持阿里云RAM用户•基于用户和角色 权限控制 •支持对湖表设置ACL细粒度权限控制•计算产品对接DLF通过STSRam体系•列级权限，行级权限&列Masking 审计和治理 •全面记录操作日志，满足生产合规•支持漏洞发现和安全治理 RESTServer湖表数据治理 冷热分层 元数据 存储概览 存储信息与趋势文件访问时间 开源SDK元数据变更日志元数据访问日志 智能分层分区级访问冷热分层 THANK YOU 谢 谢 观 看 实时数仓演进之路 饿了么大数据架构简介 实时数仓架构演进 实时数仓1.0 实时数仓2.0 烟囱式重复开发数据孤岛->一致性差成本压力:计存&运维 新兴业务难以提效“伪”流批一体：DWD两份存储成本&性能:TT带宽/性能,Holo内表研发效率:TT无法检索分析,调试成本 成熟CDM资产复用数据一致性提升计存运维成本下降 Lakehouse探索选型 Lakehouse架构-ALake 阿里从Data Warehouse转变到LakeHouse再演变到Data+AI大数据平台架构关键载体 淘天、阿里数据、饿了么（淘宝闪购）、高德、优酷、大麦、CBU及云智能 •湖仓协同•统一存储•标准格式•集中管控•Data+AI•单一入口•资源统一 饿了么湖仓Pipeline 传统实时数仓VSLakehouse架构 实时湖仓应用实践 湖仓应用-淘宝闪购 强数据驱动&业务快速变化=> T+1时效无法满足需求=>近实时需求💥 监控预警&补偿 在线应用用户投放搜索推荐营销定价商物流实时联动…… 业务决策 实时决策大屏运营效率诊断商家生意参谋流量效率分析AB实验体系…… 库存监控商户营业预警业务风险监控实时数据订正…. 解决方案-交付策略 Func(重要程度,查询频率,时效性,复杂度)=>数据方案 典型案例-UV统计 典型案例-近实时AB 应用实践-小结 规划与展望 规划与展望 未来畅想 •实现真正的流批一体：让数据流动像血液一样自然，不再有批处理和流处理的界限•构建智能化的数据服务：让数据工程师不再是“数据搬运工”而是“智囊团"•推动湖仓与AI的深度融合：让数据不仅被分析，更能主动"思考"和"预测"•拥抱更加开放的生态体系：让不同的技术能够和谐共存，发挥各自优势 THANK YOU 谢 谢 观 看 FlinkCDC实现企业级实时数据同步 传统的数据集成通常由全量和增量同步两套系统构成，在全量同步完成后，还需要进一步将增量表和全量表进行合并操作，这种架构的组件构成较为复杂，系统维护困难。本方案提供FlinkCDC技术实现了统一的增量和全量数据的实时集成。 流批一体LakeHouse架构实践 企业面临数据孤岛、流批分离致运维复杂与口径不一。阿里云数据湖构建（DLF）提供统一元数据与存储管理，Paimon实现湖上流批一体，通过DLF+Paimon+计算引擎集成，构建统一存储、口径一致、生态开放的云原生Lakehouse，加速数据价值释放。 钉钉扫码进群，获取专业技术服务群号：66255057436 完成体验及填写调研问卷，即可领取精美定制好礼！ 国内最大的运动零售运营商 关于滔搏 企业荣誉 •2020年荣获称号，代表行业质量最高水平。 •入选胡润研究院•入选。•2022年获得，表彰在零售创新领域的卓越成就。•拥有，涵盖智能货架、库存管理系统等创新领域。•多次被评为，吸引和留住优秀人才。•2024年获得《财富》杂志。•连续4年，被《机构投资者》评为。 •滔搏是中国颇具规模的，与二十余个领先的运动品牌建立了长期合作关系，是在国内最大的零售运营合作伙伴。•滔搏目前在全国拥有约，并前瞻性地建立了的全域经营生态。•滔搏创立于1999年，并于2019年以滔搏国际控股有限公司为主体在香港主板上市。•2024/2025财年，滔搏实现营业收入，净利润。(滔搏国际年报)•MSCI ESG评级为，为中国运动鞋服行业上市企业的领先水平。 挑战和收益并存 零售的技术痛点 实时湖仓架构实践 零售场景下的实时湖仓构建与实践 从传统困境到战略抉择 从技术价值到社区共建 零售的技术痛点 传统线下零售都会面临的战略抉择 大数据上云不是一个可选题 业务连续性保障压力 设备与软件版本老旧 数据处理能力达到瓶颈 痛点①：设备老旧，软件版本滞后 02开源软件版本滞后带来的问题 01老旧硬件带来的挑战 ➢性能瓶颈：CPU、内存和存储IO性能低下，难以支持现代高并发业务。 ➢功能落后：缺少新特性和技术支持，限制了业务创新和效率提升。 ➢高故障率：设备运行时间长，元件老化，故障频发，导致业务中断。 ➢安全隐患：社区活跃度低，安全漏洞无法及时修复，存在高风险。 ➢维护成本高：维护旧设备需要投入大量人力物力，成本高昂且不经济。 ➢升级困难：版本跨度大导致升级复杂、耗时且风险高，可能影响现有业务。 痛点②：业务稳定性保障要求高 ➢资源浪费：资源配置按业务峰值需求，但实际利用率低，尤其是在零售业务等有明显波谷的场景，平均利用率甚至不足30%。 ➢人力投入大：日常运维需要专人值守，故障排查过程复杂，消耗大量人力资源。 ➢应急响应慢：告警系统通道单一，夜间等非工作时间应急响应效率低，可能导致故障处理不及时。 ➢扩展困难：当业务快速增长时，传统架构的扩容周期长，无法及时响应，容易成为业务发展的瓶颈。 痛点③：数据处理能力达到瓶颈 数据质量与一致性 业务数据整合困难 实时性缺失 传统批处理模式无法满足日益增长的实时业务需求。传统ETL工具（如Informatica）每日凌晨跑批，导致库存、价格等关键数据无法实时同步。 不同系统间数据难以高效整合与共享。由于系统分散，经常存在数据合并刷新的需求，造成大量的增删改查操作，对数仓带来很大的压力。 缺乏统一管理和ACID特性支持。数据冗余与冲突同一商品在不同系统（ERP、POS、电商平台）中编码、价格、库存不一致，导致超卖或订单纠纷。 大数据升级迭代诉求强烈 满足技术稳定性要求 满足技术先进性要求 满足业务时效性要求 实时湖仓架构实践 零售场景下的实时湖仓构建与实践 湖仓1.0的主要问题 技术陈旧 慢且不稳 运维复杂 Kudu、Impala等大数据组件