多语言多风格网站方案中国招采网招标公告

张

张建站

2026/4/19 13:06:17

10分钟阅读

多语言多风格网站方案,中国招采网招标公告,怎么做网站里的资讯,西安网站建设那家好导读淘宝闪购从25年春天的横空出世#xff0c;到秋天“第一杯奶茶”的火爆#xff0c;再到今天成为广大消费者即时生活服务的日常#xff0c;业务团队取得了巨大的突破#xff0c;背后自然少不了技术团队的支撑。经过一年多的探索实践#xff0c;闪购大数据团队沉淀了以…导读淘宝闪购从25年春天的横空出世到秋天“第一杯奶茶”的火爆再到今天成为广大消费者即时生活服务的日常业务团队取得了巨大的突破背后自然少不了技术团队的支撑。经过一年多的探索实践闪购大数据团队沉淀了以Paimon为底座流、批、分析多引擎协作的Lakehouse架构。本文介绍阿里云 Serverless Spark Paimon在淘宝闪购大数据湖仓场景的应用。一、业务介绍淘宝闪购是阿里巴巴旗下的即时零售业务也是目前电商领域非常热门的“风口”之一。淘宝闪购零售业务是淘宝闪购重要的生态体系之一业务覆盖了餐饮外商品的外卖业务包括超市便利、看病买药、水果买菜、鲜花潮玩、酒水饮料、食品百货、手机数码等众多品类和消费场景。淘宝闪购零售数据团队是淘宝闪购DIC数据智能中心下负责零售业务的数据团队。在2025年5月闪购业务快速发展的背景下零售数据团队也面临着业务快速增长带来的数据体量和业务诉求对实时数据更强烈的压力零售业务特殊场景基础商品量级大观测维度多在大盘观测、多端流量调配及权益补充等场景下业务对多维分析和实验效果回收有更高时效的要求。在淘宝闪购数据团队长时间探索ALake积累的湖仓一体背景下闪购初期零售数据的整体实时架构便融合了湖仓一体架构快速支撑了业务在闪购上线初期快速看数和策略调整的诉求经过多轮的技术探索逐步形成了FlinkPaimonSparkStarRocks的技术架构Spark在其中扮演了非常关键的角色在应用端使用Spark在营销特征生产、零售流量多维分析、AB实验效果回收等场景上均得到了效率和稳定性的提升。本文将主要分享零售数据团队在实时湖仓探索中在Spark应用落地的一些实践总结。二、淘宝闪购零售数据实时架构演进之路2.1 烟囱式开发的实时链路主要应用场景零售商家数据看板、实时分析。在此阶段遇到的问题主要是烟囱式开发开发和维护成本较高。我们在实时中间层的沉淀上基本满足诉求但是在应对业务多维分析需求时原先架构的开发成本和数据核对的成本比较高无法支撑快速迭代的业务诉求。2.2 引入湖仓Paimon StarRocks实时分析提效初见成效在引入了湖仓之后实时主要技术架构升级到TTFlinkPaimonStarRocks主要应用场景商家端应用、实时分析。在湖仓一体的背景下闪购初期我们选择了StarRocks查询引擎搭建FBI看板快速响应了业务快速迭代的看数需求。在此场景下遇到的问题如下维表引入效率低由于湖仓在零售数据团队的引入处于初期比较多的底层依赖公共层表都在ODPS中在FBI引入StarRocks直查分析的情况下没有办法直接关联所以StarRocks的物化没有办法实现比较多的维度聚合场景。需求迭代快时效容忍度高闪购上线初期市场竞争激烈业务需求的变化也快对数据产出的时间要求也高但是对于实时性的要求不是很高所以对开发效率提了比较大的挑战。流量数据量级大分析维度多Cube计算数据膨胀大数据产出延迟大与餐饮外卖场景不同零售场景下业务需要关注到商家行业、城市、品牌、业态等多维度的流量和交易转化分析应用场景主要是在快速增长的流量下做大盘观测、分行业运营、流量策略调整、权益补充等场景上初期的技术方案是FlinkPaimonStarRocks但是在基础流量量级上Cube膨胀倍数达到万倍在对比之下StarRocks更适合在中等规模的数据聚合在大Cube的规模下StarRocks的多维表物化视图无法稳定产出导致数据时效性受到极大的影响零售流量分析在淘宝闪购上线初期StarRocks物化视图的成功率约40%~60%在高峰期的数据延迟能达到3h以上。2.3 引入批处理引擎Spark实现流批一体提升稳定性和效率应用场景更丰富为了解决以上的一些难题我们联合了阿里云EMR Serverless Spark团队和爱橙ALake Spark团队合作引入Spark引擎通过批处理实现准实时物理物化补充当前在湖仓的技术栈上的缺口经过近半年的应用实践达成了在数据稳定产出上的目标同时在产出时效性得到了大大提升。闪购的批处理场景选择了ALake Spark主要考虑因素是ALake Spark跟Paimon的集成非常成熟。与其他具有私有格式的引擎不同DLF Paimon表是ALake Spark的“内表”支持Paimon的全部特性包括读写全类型表(Append表PK表Object表Format表)支持ACID、Schema Evolution、Time Travel、Call Procedure等湖表特性支持列裁剪、谓词下推、基于统计信息的Plan调整、z-order等查询优化以及支持DV和Variant类型等高级特性。此外ALake通过跟阿里云EMR团队合作引入Fusion和Celeborn等重要组件大幅提升Spark的性能、稳定性和弹性成为湖上批处理的首选引擎。主要概况以下几点1数据湖的无缝集成。ALake Spark跟Paimon的集成非常成熟尤其是对DV表的支持更佳开启 Paimon 表的 Deletion-Vectors 属性后Spark的读写性能能提升约3-5倍同时支持ACID、Schema Evolution、Time Travel、Call Procedure等湖表特性。2Variant高效JSON数据存储和读写支持让复杂文本的读取和计算效率得到大大的提升。在测试场景中读取性能在关闭和开启Shredding配置下分别提升1.7倍和12倍。3稳定性强解释性高。ALake通过跟阿里云EMR团队合作引入Fusion和Celeborn等重要组件大幅提升Spark的性能、稳定性这也是在闪购初期我们对实时/批处理引擎比较大的考量。并且可解释性强数据核验的效率非常高有助于提升效率。4调优空间大效率高。支持列裁剪、谓词下推、基于统计信息的Plan调整、z-order等查询优化方案我们在Spark测试过程中发现对任务的调优可以获得指数级的效率提升收益对数据的产出时效有极大的提升最大能提升90%以上的任务运行效率。5开发和运维的成本低。技术栈比较成熟无需手动管理和复杂的基础设施搭建即可快速启动任务开发大大减少在闪购势如破竹的背景下快速迭代的学习成本真正实现了流批一体提升了整个团队的开发效率。最终Spark在淘宝闪购零售数据多个场景中应用AB实验回收分析、实时流量分析、营销批信号和特征生产等。整个开发成本平均提升30%~40%的效率数据产出稳定性提升90%以上同时通过Spark调优带来的效率提升最高达到了92%。三、Spark Paimon重要特性详解3.1 Delete Vector在Delete Vector(DV)之前Paimon支持两种数据合并方式Copy on Write(COW)和Merge on Read(MOR)。COW模式在更新时需重写整个数据文件导致写放大和高延迟难以支持高频流式写入而MOR虽写入高效但读取时需做文件合并带来显著的读开销且对计算引擎集成不友好。DV引入了新的机制写入时记录被删除的数据读取时过滤。DV既保留了MOR写入高效性又减少了COW的合并开销从而更好地支持流批一体场景。下面以PK介绍DV的整体设计。在delete和update时生成delete file并记录被删除recordDV file具体编码如下逻辑上记录每个文件被删除的record的rowid物理上以bitmap存储在index file meta和index file中读表时过滤掉delete file记录的record。对比5亿条数据(20%重复率)的主键表入湖后查询开启DV比关闭DV性能提升3-5倍。3.2 VariantJson数据在闪购业务中使用非常广泛但Json解析的性能经常成为瓶颈。针对这个问题ALake Spark结合Paimon推出了Variant类型通过牺牲一次写性能大大加速高频的读性能。Variant的整体思路是写时解析Json的Schema并以自描述可索引的方式存储Schema和数据只需在写入时做一次完整解析和编码换取读取时媲美结构化数据的性能。Variant的编码格式如下:Variant的Metadata字段存储的是去重之后的keyValue的filed id部分存储的是按照key字典排序之后的id每个id指向其对应的key从而支持快速二分查找所需要的key。Value的field offset和field value部分存储value的偏移和具体的值。针对嵌套结构field value递归存储上述结构(Metadata Value字段)。针对结构相对固定的Variant数据ALake Spark Paimon还支持了Shredding即采样出固定的字段并以struct的方式存储从而进一步加速解析过程。在测试场景中读取性能在关闭和开启Shredding配置下分别提升1.7倍和12倍3.3 Fusion CelebornFusion是ALake Spark跟阿里云EMR Serverless Spark团队合作引入的向量化SQL执行引擎使用C 向量化技术重写了Spark SQL Engine。除了语言层面Fusion的主要特点是把原有的行式计算转变成列式计算从而更易于SIMD加速更加CPU Cache友好结合异步合并IO等优化在CPU密集型作业上相比Java Engine有数倍性能提升。Apache Celeborn是阿里云EMR Serverless Spark团队捐赠给ASF的顶级项目目前已经是Spark Remote Shuffle Service的事实标准。Celeborn主要解决的问题是大Shuffle作业的稳定性、弹性和性能问题主要技术手段是远程存储和Shuffle数据重组彻底解决重Shuffle作业经常出现的FetchFailure异常生产作业极端情况有数量级的性能提升。Fusion Celeborn 的架构如下:4、Spark Paimon在闪购的应用4.1 流批一体营销实时特征生产提效随着闪购市场的竞争日益激烈对用户的精细化运营变得越来越关键同时也对营销算法提出了新的挑战以前的离线特征已经无法满足业务策略快速迭代的诉求算法团队也对特征的时效性提出了更高的要求。之前的实时特征生产流程如下所示在算法侧离线特征重要性评估之后向数据团队提特征生产需求在数据和算法开始梳理和对齐口径开始针对某一批实时特征的开发和上线结合数据验证理论上需要2个星期以上的时间而且还不包含全链路的质量保障工作如果遇到比较极端的序列型特征Flink SQL还没有办法支持需采用DataStreaming的方案实现开发时长甚至会达到1个月以上主要的时间是花在了特征开发阶段。在接入湖仓之后我们采用了新的实时特征生产模式新的生产模式核心思想是逐步提升特征的时效性优先生产分钟级时效的特征根据分钟级特征的重要性表现决定是否转向实时生产的模式。新的实时特征生产流程如下所示此生产模式下的数据链路如下零售数据团队营销特征生产的提效成果Spark生产单个特征的效率至少是原先的 3倍以上实时特征有效比例20%在整个特征生产到算法实验链路上至少能提升40%的效率同时在资源成本上也有约20%的节省。4.2 流量营销多维分析如前文所述在零售EAT夏战的大范围作战中对于时效性的要求越来越高高时效的数据应用在大盘观测、流量调配、策略调整、权益补充等多个场景中。因此业务侧与管理层对于数据的实时性有更高的期待和更多的要求原有的技术架构与人力无法匹配快速迭代的需求。从维度上看零售场景下业务需要关注到商家行业、城市、品牌、业态、类目等多维度的流量和交易转化分析如果再配合营销超算同学做算法AB实验的回收数据需要再加入实验信息、端、用户分层、笔单分层、券维度等等实验所需维度在实验效果回收时需要cube做数据多维分析数据量膨胀近万倍传统生产逻辑已无法满足算法侧及时回收数据的强诉求。在实时准实时分析上形成3套分析范式序号分析框架场景/示例1Paimon[detail]StarRocks中小数据规模实时分析例如零售实时营销2PaimonStarRocks MV[sum]StarRocks中等数据规模实时分析例如零售多维实时AB实验分析3PaimonSpark[sum]StarRocks大批量数据准实时分析例如零售多维实时流量分析数据湖技术的落地带来了新的可能。我们通过SparkPaimon的结合的方式并进行合理的执行计划优化使回收数据的时效性达到半小时/10分钟级大大提高算法实验回收效率为营销和搜推赋能。4.3 Spark治理和调优最佳实践应用Spark在应用上调优和治理的空间是比较大的尤其是针对大量级数据的聚合查询。以下是我们在实践过程中总结的调优案例对我们运算效率和资源利用均有特别大的提升。总的来说Spark的核心调优原则总结为2条1问题导向先通过SparkUI定位瓶颈Stage 执行时间、Task 分布、数据输入量再针对性优化。关键指标Stage 执行时长、Task 耗时方差、Shuffle 数据量、内存溢出OOM日志。2分级优化优先级参数调优 → 执行计划优化 → 存储层优化湖表结构调整。4.3.1 数据倾斜治理最高频问题1诊断方法SparkUI 观察某 Stage 执行时间远超其他 Stage如占总耗时 80%。同 Stage 下 Task 耗时方差极大如 90% Task 耗时 1min个别 Task 30min。Shuffle Read/Write 数据量异常如某 Task 读取数据量是平均值的 100 倍。定位倾斜算子通过SQL / DataFrame查看 Stage 对应的 SQL 逻辑如 JOIN、GROUP BY。检查输入数据量差异如大表 7.5 亿 vs 小表 400 万。2治理方案场景解决方案关键参数/操作效果通用倾斜开启自适应倾斜处理spark.sql.adaptive.skewJoin.enabledtruespark.sql.adaptive.skewJoin.skewedPartitionThresholdInBytes256MB拆分倾斜分区避免单 Task 过载大表 JOIN 小表强制 MapJoin避免 ShuffleSQL 中添加/* MAPJOIN(small_table) */Hint消除 Shuffle提速 85%倾斜 Key 预处理对倾斜 Key 单独处理如加随机前缀CONCAT(key, _, FLOOR(RAND() * 10))分桶不合理调整Paimon表分桶数分桶设置黄金公式推荐分桶数分区数据量 (GB) / 2示例单分区数据 864GB → 分桶数设为432解决底层数据分布不均4.3.2 执行计划优化CUBE/维度展开场景1问题特征维度组合爆炸如 4 维度展开 200 倍。单 Stage 内完成数据读取维度计算Task 并发度不足。2优化方案步骤操作原理1. 增加并发度在维度展开前插入hintrepartition(N)将计算拆分到更多 Task避免单 Task 负载过重2. 确定 N 值按数据量级尝试N 数据量 × (20/50/100)示例900 万数据 → 试400通过 SparkUI 观察 Task 均衡性调整 N3. 验证效果检查新 Stage 是否存在倾斜总耗时下降目标Task 耗时标准差 20%优化效果CUBE 作业从 90min优化至8min性能提升 92.7%。4.3.3 湖表存储层优化终极手段1适用场景参数调优后性能仍不达标。分区数据量与分桶数严重不匹配如 1TB 数据仅 10 个桶。2优化步骤分桶数量调整计算公式分桶数分区数据量 (GB) / 2参考文档Paimon Rescale Bucket分桶键选择主键表默认使用主键无需显式设置。非主键表选择高频 JOIN 或 GROUP BY 字段如user_id。关键配置示例TBLPROPERTIES(bucketxxx,-- 按数据量计算primary-keyds,user_id,order_id,-- 主键表必设deletion-vectors.enabledtrue-- 启用删除向量加速查询)4.3.4 总结调优流程图实战指南Stage 耗时不均维度计算慢是否Task 数过少分桶不合理达标未达标任务执行慢SparkUI诊断检查数据倾斜检查并发度启用 skewJoin MapJoin检查分桶设置增加 repartition重建Paimon表验证效果完成5、总结与未来展望在淘宝闪购上线以来的这一段时间内业务不断在创造一个又一个峰值用户活跃度和订单量级都屡创新高在这背后数据团队始终以“稳定、高效、智能”为准则在湖仓一体架构的基础上深度融合流计算与批处理能力构建起一套高弹性、低延迟、强一致的数据处理体系作为核心计算引擎阿里云 EMR Serverless Spark 在湖仓一体架构中扮演了关键角色在湖仓流计算和批计算的共同加持下抗住了业务的压力同时越来越多的业务场景应用快速落地。未来我们也会继续与阿里云EMR Serverless Spark团队和爱橙ALake Spark团队密切合作在闪购业务上探索更多的使用场景发挥Spark更大的价值。我们坚信在AI与即时零售深度融合的时代浪潮下Spark不仅是计算引擎更是连接数据、智能与商业价值的关键桥梁。而淘宝闪购正成为这一桥梁上最活跃、最具创新力的先行者之一欢迎大家到淘宝闪购下单。鸣谢感谢我们淘宝闪购-DIC零售数据团队慧航、圣俞、空竹、晚识、约理、鸢鸿、舫舟、量衡、清临等各位同学在湖仓应用的支持感谢淘宝闪购-DIC霄明、哲昆在零售数据团队在湖仓探索和Spark应用上的支持和帮助感谢爱橙湖仓团队无谓、其修、夷羿的大力支持感谢阿里云EMR Serverless Spark团队一锤、寻径、履霜、羊川、昕羽、羲羽、郑涛等同学的支持。