GaussDB(DWS)性能调优，解决DM区大内存占用问题

华为云开发者联盟 华为云开发者联盟 博客等级 墨衍会员 · AI 创作全网分发 墨衍智能分发 本文由作者通过墨衍一键同步至各平台 1分发平台 1.2k累计阅读 1.2k平均单平台 已同步平台 优快云 微信公众号 微博 知乎 掘金 百家号 博客园 抖音 小红书 你的文章也可以这样分发 墨衍会员 ¥399起/年，写一次发全网 我也要 码龄10年
关注
原创 2024-07-04 08:59:20 1.2k 阅读 AI 写同款· GEO 优化 ›

本文分享自华为云社区《GaussDB(DWS)性能调优：DM区优化案例——维度表关联条件存在会计期》，作者： O泡果奶~。

当前DM（P1、P3、CBGDM）存在维度表与主表关联时使用会计期作为关联条件，会导致出现大内存占用或未识别数据倾斜的问题

【场景一】f.period_id = 维度表.period_id

1.1、【问题描述】

主表和维度表关联过程中将会计期作为关联条件，导致维度表未进行分区剪枝，可能会产生大内存占用的情况

1.2、【原始SQL】

仅呈现SQL中的问题，详细SQL见附件

FROM
		DMACC.dm_adp_ar_trx_dtl_tmp F
		INNER JOIN DMDIM.DM_DIM_REGION_RC_D REG ON F.COA_GEO_PC_KEY = REG.GEO_PC_KEY
		INNER JOIN DMDIM.DM_DIM_PRODUCT_T_D T9 ON F.PROD_KEY = T9.PROD_KEY 
		AND T9.PROD_POV_ID = 1
		INNER JOIN DMDIM.DM_DIM_PROJECT_D J ON F.PROJ_KEY = J.PROJ_KEY
		INNER JOIN DMDIM.DM_DIM_CONTRACT_D HT ON HT.CONTRACT_KEY = F.CONTRACT_KEY
		LEFT JOIN DMCOMMON.DWR_CONFIG_DOMESTIC_FINANCE_V FIN ON F.COA_COMPANY_KEY = FIN.COMPANY_KEY 
		AND F.COA_GEO_PC_KEY = FIN.GEO_PC_KEY
		LEFT JOIN DMAR.DWB_FMD_DIM_INVOICE_PAY_PLAN_D PP ON F.AR_INVOICE_PAY_PLAN_ID = PP.AR_INVOICE_PAY_PLAN_ID 
		AND F.PERIOD_ID = PP.PERIOD_ID
		LEFT JOIN DMARDI.DWR_DIM_AR_INVOICE_V INV ON F.AR_INVOICE_ID = INV.AR_INVOICE_ID
		INNER JOIN DMARDI.DWR_DIM_AR_APPLICATION_V APP ON F.AR_APPLICATION_RECORD_ID = APP.AR_APPLICATION_RECORD_ID
		INNER JOIN DMARDI.DWR_DIM_AR_RECEIPT_V RCP ON F.AR_RECEIPT_RECORD_ID = RCP.AR_RECEIPT_RECORD_ID
		INNER JOIN DMARDI.DWR_DIM_AR_RECEIPT_TYPE_V RT ON RCP.RECEIPT_RECORD_TYPE_ID = RT.AR_RECEIPT_TYPE_ID
		LEFT JOIN (
		SELECT C
			.CONTRACT_KEY,
			D.COMPANY_KEY,
			R.FIRST_SHIP_DATE 
		FROM
			DMDIM.dm_dim_contract_d C,
			DMDIM.DM_DIM_COMPANY_D D,
			DMARDI.DWR_CTRCT_FIRST_SHIP_DATE_R R 
		WHERE
			C.CONTRACT_ID = R.CONTRACT_ID 
			AND D.COMPANY_ID = R.COMPANY_ID 
		) FR ON F.CONTRACT_KEY = FR.CONTRACT_KEY 
		AND F.COA_COMPANY_KEY = FR.COMPANY_KEY
		INNER JOIN DMDIM.DM_DIM_SALES_MODE_D MO ON F.SALES_MODE_KEY = MO.SALES_MODE_KEY
		JOIN DMDIM.DM_DIM_JOURNAL_SOURCE_D T29 ON F.JE_SOURCE_ID = T29.JE_SOURCE_ID
		JOIN DMDIM.DM_DIM_JOURNAL_CATEGORY_D T30 ON F.JE_CATEGORY_ID = T30.JE_CATEGORY_ID

1.3、【性能分析】

image.png

image.png

image.png

从上图的执行计划可以看出，由于用会计期作为关联条件，导致维度表未进行分区剪枝，数据量大，不但产生了数据倾斜，同时还由于数据量大出现了关联下盘，大大降低了sql执行性能。主表只有一个会计期，可以识别出对应的会计期，然后对SQL进行如下改写：

FROM
		DMACC.dm_adp_ar_trx_dtl_tmp F
		INNER JOIN DMDIM.DM_DIM_REGION_RC_D REG ON F.COA_GEO_PC_KEY = REG.GEO_PC_KEY
		INNER JOIN DMDIM.DM_DIM_PRODUCT_T_D T9 ON F.PROD_KEY = T9.PROD_KEY 
		AND T9.PROD_POV_ID = 1
		INNER JOIN DMDIM.DM_DIM_PROJECT_D J ON F.PROJ_KEY = J.PROJ_KEY
		INNER JOIN DMDIM.DM_DIM_CONTRACT_D HT ON HT.CONTRACT_KEY = F.CONTRACT_KEY
		LEFT JOIN DMCOMMON.DWR_CONFIG_DOMESTIC_FINANCE_V FIN ON F.COA_COMPANY_KEY = FIN.COMPANY_KEY 
		AND F.COA_GEO_PC_KEY = FIN.GEO_PC_KEY
		LEFT JOIN DMAR.DWB_FMD_DIM_INVOICE_PAY_PLAN_D PP ON F.AR_INVOICE_PAY_PLAN_ID = PP.AR_INVOICE_PAY_PLAN_ID 
		AND PP.PERIOD_ID = '202406'
		LEFT JOIN DMARDI.DWR_DIM_AR_INVOICE_V INV ON F.AR_INVOICE_ID = INV.AR_INVOICE_ID
		INNER JOIN DMARDI.DWR_DIM_AR_APPLICATION_V APP ON F.AR_APPLICATION_RECORD_ID = APP.AR_APPLICATION_RECORD_ID
		INNER JOIN DMARDI.DWR_DIM_AR_RECEIPT_V RCP ON F.AR_RECEIPT_RECORD_ID = RCP.AR_RECEIPT_RECORD_ID
		INNER JOIN DMARDI.DWR_DIM_AR_RECEIPT_TYPE_V RT ON RCP.RECEIPT_RECORD_TYPE_ID = RT.AR_RECEIPT_TYPE_ID
		LEFT JOIN (
		SELECT C
			.CONTRACT_KEY,
			D.COMPANY_KEY,
			R.FIRST_SHIP_DATE 
		FROM
			DMDIM.dm_dim_contract_d C,
			DMDIM.DM_DIM_COMPANY_D D,
			DMARDI.DWR_CTRCT_FIRST_SHIP_DATE_R R 
		WHERE
			C.CONTRACT_ID = R.CONTRACT_ID 
			AND D.COMPANY_ID = R.COMPANY_ID 
		) FR ON F.CONTRACT_KEY = FR.CONTRACT_KEY 
		AND F.COA_COMPANY_KEY = FR.COMPANY_KEY
		INNER JOIN DMDIM.DM_DIM_SALES_MODE_D MO ON F.SALES_MODE_KEY = MO.SALES_MODE_KEY
		JOIN DMDIM.DM_DIM_JOURNAL_SOURCE_D T29 ON F.JE_SOURCE_ID = T29.JE_SOURCE_ID
		JOIN DMDIM.DM_DIM_JOURNAL_CATEGORY_D T30 ON F.JE_CATEGORY_ID = T30.JE_CATEGORY_ID

经优化后，执行计划如下图所示，维度表进行了分区剪枝，数据量减少，缓解了数据倾斜，也避免了关联下盘的问题。

image.png

image.png

【场景二】f left join 维度表 on f.period_id = 维度表.period_id and 维度表.period_id = ‘会计期’

2.1、【问题描述】

主表和维度表关联过程中将会计期作为关联条件，同时还为维度表会计期进行赋值，可能会产生数据倾斜未识别的情况

2.2、【原始SQL】

FROM
		dmdp.dm_dpc_inv_m_dtl_f_TEM_A LT1
		LEFT JOIN dmcommon.dm_dim_prod_key_r LT2 ON LT1.prod_key = LT2.old_key 
		AND LT1.period_id = LT2.period_id 
		AND LT2.PERIOD_ID = 202406
		LEFT JOIN dmcommon.dm_dim_reg_key_r LT3 ON LT1.period_id = LT3.period_id 
		AND LT1.geo_pc_key = LT3.old_key 
		AND LT3.PERIOD_ID = 202406
		LEFT JOIN dmcommon.dm_dim_cus_key_r LT4 ON LT1.period_id = LT4.period_id 
		AND LT1.account_dept_cust_key = LT4.old_key 
		AND LT4.PERIOD_ID = 202406
		LEFT JOIN dmcommon.dm_dim_proj_key_r LT5 ON LT1.period_id = LT5.period_id 
		AND LT1.proj_key = LT5.old_key 
		AND LT5.PERIOD_ID = 202406
		LEFT JOIN dmcommon.dm_dim_cus_key_r LT6 ON LT1.period_id = LT6.period_id 
		AND LT1.enterprise_cust_key = LT6.old_key 
		AND LT6.PERIOD_ID = 202406
		LEFT JOIN dmcommon.dm_dim_rep_key_r LT7 ON LT1.period_id = LT7.period_id 
		AND LT1.report_item_id = LT7.old_key 
		AND LT7.PERIOD_ID = 202406
		LEFT JOIN dmcommon.dm_dim_supply_center_key_r LT8 ON LT1.period_id = LT8.period_id 
		AND LT1.supply_center_key = LT8.old_key 
		AND LT8.PERIOD_ID = 202406
		LEFT JOIN dmcommon.dm_dim_inv_key_r LT9 ON LT1.period_id = LT9.period_id 
		AND LT1.inventory_class_key = LT9.old_key 
		AND LT9.PERIOD_ID = 202406
		LEFT JOIN dmcommon.dm_dim_bus_key_r LT10 ON LT1.period_id = LT10.period_id 
		AND LT1.business_status_key = LT10.old_key 
		AND LT10.PERIOD_ID = 202406
		LEFT JOIN dmcommon.dm_dim_hisi_key_r LT11 ON LT1.period_id = LT11.period_id 
		AND LT1.hisi_prod_key = LT11.old_key 
		AND LT11.PERIOD_ID = 202406
		LEFT JOIN dmcommon.dm_dim_inv_org_key_r LT12 ON LT1.period_id = LT12.period_id 
		AND LT1.inventory_org_key = LT12.old_key 
		AND LT12.PERIOD_ID = 202406
		LEFT JOIN dmcommon.dm_dim_cus_key_r LT13 ON LT1.period_id = LT13.period_id 
		AND LT1.end_cust_key = LT13.old_key 
		AND LT13.PERIOD_ID = 202406
		LEFT JOIN dmcommon.dm_dim_cus_key_r LT14 ON LT1.period_id = LT14.period_id 
		AND LT1.sign_cust_key = LT14.old_key 
		AND LT14.PERIOD_ID = 202406
		LEFT JOIN dmcommon.dm_dim_cus_key_r LT15 ON LT1.period_id = LT15.period_id 
		AND LT1.agent_distribution_cust_key = LT15.old_key 
		AND LT15.PERIOD_ID = 202406
		LEFT JOIN dmcommon.dm_dim_com_key_r LT16 ON LT1.period_id = LT16.period_id 
		AND LT1.company_key = LT16.old_key 
		AND LT16.PERIOD_ID = 202406
		LEFT JOIN dmcommon.dm_dim_con_key_r LT17 ON LT1.period_id = LT17.period_id 
		AND LT1.contract_key = LT17.old_key 
		AND LT17.PERIOD_ID = 202406
		LEFT JOIN dmcommon.dm_dim_con_key_r LT18 ON LT1.period_id = LT18.period_id 
		AND LT1.loan_contract_key = LT18.old_key 
		AND LT18.PERIOD_ID = 202406
		LEFT JOIN dmcommon.dm_dim_supply_center_key_r LT19 ON LT1.period_id = LT19.period_id 
		AND LT1.target_supply_center_key = LT19.old_key 
		AND LT19.PERIOD_ID = 202406
		LEFT JOIN dmcommon.dm_dim_subinventory_key_r LT20 ON LT1.period_id = LT20.period_id 
		AND LT1.subinventory_key = LT20.old_key 
		AND LT20.PERIOD_ID = 202406 
	WHERE
		1 = 1 
	AND partition_value IN ( 0, 1 )

2.3、【性能分析】

image.png

image.png

上图的执行计划可以看出，在主表一开始关联过程中就存在数据倾斜，导致SQL执行性能差。

image.png

image.png

详细执行计划中，虽然维度表进行了分区剪枝，但由于使用了 left join，导致关联条件中维度表的常量period_id不能直接赋值给主表period_id，主表关联后的结果重分布时将period_id作为了分布键之一，这会影响优化器的倾斜优化。可以将f.period_id = 维度表.period_id这一关联条件删掉，对sql进行如下改写

FROM
		dmdp.dm_dpc_inv_m_dtl_f_TEM_A LT1
		LEFT JOIN dmcommon.dm_dim_prod_key_r LT2 ON LT1.prod_key = LT2.old_key 
		AND LT2.PERIOD_ID = 202406
		LEFT JOIN dmcommon.dm_dim_reg_key_r LT3 ON LT1.geo_pc_key = LT3.old_key 
		AND LT3.PERIOD_ID = 202406
		LEFT JOIN dmcommon.dm_dim_cus_key_r LT4 ON LT1.account_dept_cust_key = LT4.old_key 
		AND LT4.PERIOD_ID = 202406
		LEFT JOIN dmcommon.dm_dim_proj_key_r LT5 ON LT1.proj_key = LT5.old_key 
		AND LT5.PERIOD_ID = 202406
		LEFT JOIN dmcommon.dm_dim_cus_key_r LT6 ON LT1.enterprise_cust_key = LT6.old_key 
		AND LT6.PERIOD_ID = 202406
		LEFT JOIN dmcommon.dm_dim_rep_key_r LT7 ON LT1.report_item_id = LT7.old_key 
		AND LT7.PERIOD_ID = 202406
		LEFT JOIN dmcommon.dm_dim_supply_center_key_r LT8 ON LT1.supply_center_key = LT8.old_key 
		AND LT8.PERIOD_ID = 202406
		LEFT JOIN dmcommon.dm_dim_inv_key_r LT9 ON LT1.inventory_class_key = LT9.old_key 
		AND LT9.PERIOD_ID = 202406
		LEFT JOIN dmcommon.dm_dim_bus_key_r LT10 ON LT1.business_status_key = LT10.old_key 
		AND LT10.PERIOD_ID = 202406
		LEFT JOIN dmcommon.dm_dim_hisi_key_r LT11 ON LT1.hisi_prod_key = LT11.old_key 
		AND LT11.PERIOD_ID = 202406
		LEFT JOIN dmcommon.dm_dim_inv_org_key_r LT12 ON LT1.inventory_org_key = LT12.old_key 
		AND LT12.PERIOD_ID = 202406
		LEFT JOIN dmcommon.dm_dim_cus_key_r LT13 ON LT1.end_cust_key = LT13.old_key 
		AND LT13.PERIOD_ID = 202406
		LEFT JOIN dmcommon.dm_dim_cus_key_r LT14 ON LT1.sign_cust_key = LT14.old_key 
		AND LT14.PERIOD_ID = 202406
		LEFT JOIN dmcommon.dm_dim_cus_key_r LT15 ON LT1.agent_distribution_cust_key = LT15.old_key 
		AND LT15.PERIOD_ID = 202406
		LEFT JOIN dmcommon.dm_dim_com_key_r LT16 ON LT1.company_key = LT16.old_key 
		AND LT16.PERIOD_ID = 202406
		LEFT JOIN dmcommon.dm_dim_con_key_r LT17 ON LT1.contract_key = LT17.old_key 
		AND LT17.PERIOD_ID = 202406
		LEFT JOIN dmcommon.dm_dim_con_key_r LT18 ON LT1.loan_contract_key = LT18.old_key 
		AND LT18.PERIOD_ID = 202406
		LEFT JOIN dmcommon.dm_dim_supply_center_key_r LT19 ON LT1.target_supply_center_key = LT19.old_key 
		AND LT19.PERIOD_ID = 202406
		LEFT JOIN dmcommon.dm_dim_subinventory_key_r LT20 ON LT1.subinventory_key = LT20.old_key 
		AND LT20.PERIOD_ID = 202406 
	WHERE
		1 = 1 
	AND partition_value IN ( 0, 1 )

改写后，执行计划如下所示

image.png

可以看出，执行计划不但进行了分区剪枝，同时优化器还进行了倾斜优化，提高了SQL执行性能

点击关注，第一时间了解华为云新鲜技术~

收录于
大数据

当前文章被收录于：

大数据
40 篇文章 3 人学习

大数据领域技术分享

订阅专栏 查看详情
标签
#gaussdb #大数据 #性能调优 #DM #华为云开发者联盟
#华为云
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。

相关推荐

鸿蒙案例上新啦 | 出门打车、到家上课：25个模板带你一屏打通日常生活

如何合理拆分页面组件、如何建立单一可信的状态源、如何让用户在每一步操作中都获得明确反馈。鸿蒙开发实践中心以标准化的应用与元服务模板为入口，将清晰的业务架构与可复用的代码结构直观呈现。不妨立即挑选一个感兴趣的方向进入云端环境，从页面布局、组件封装、状态管理到路由组织，亲手跑通你的鸿蒙实战项目。

华为云官方博客 21

LakeAgent：DWS数据仓库的第二大脑，告别 “翻译式运维”，迈入智能自治时代

和普通 SQL 改写工具不同，LakeAgent 自动做多方案代价对比，主动规避负优化陷阱：补充分区键过滤实现剪枝，扫描分区由 37 收敛至 1，执行代价从 758.28 降至 113.74；未来的数据仓库，将不止能算、能存，更能看懂自己、诊断自己、理解自己。长久以来，数仓的智能都依附于人：信号需要人解读，瓶颈需要人研判，经验困在个体里，无法随底座永续生长。CPU 高、CPU 告警、CPU 诊断、CPU 使用率过高、CPU 满。语法、错误码、计费、性能调优、最佳实践、故障处置等全场景内容。

华为云官方博客 499

如何使用RDS Supabase后端BaaS能力：文件存储（File Storage）

• product-images（公开桶，允许公共读取）：策略名称"Public read for product-images"，允许SELECT，目标角色anon，策略定义bucket_id = 'product-images'。上传/删除需另配INSERT/DELETE策略，详见SQL。• product-specs（私有桶，仅认证用户访问自己的文件夹）：建议拆为上传、读取、删除三条策略，策略定义均为 bucket_id = 'product-specs' 且仅限本人文件夹（详见下文 SQL）。

华为云官方博客 429

如何使用RDS Supabase后端BaaS能力：实时订阅与推送（Realtime）

Realtime 把数据库的每次变更同步到客户端：表里增、删、改一行，订阅者无需刷新页面或主动请求即可秒级收到。三大能力各司其职：• Postgres Changes — 监听表的 INSERT/UPDATE/DELETE，变化即通知• Broadcast — 客户端之间直接互发，适合瞬时通知、协同编辑• Presence — 跟踪频道里“谁在线”典型场景有实时数据展示（订单、库存、监控指标即时刷新）、即时通讯（消息收发、在线名单、“对方正在输入”）、协同编辑与实时通知。

华为云官方博客 419

AI Agent如何通过MCP连接到华为云RDS Supabase应用平台

Schema元数据列出所有可访问的表（按schema分组）。Schema元数据列出表的列及元数据（类型/默认值/约束）。Schema元数据列出所有约束（PK/FK/UNIQUE/CHECK/EXCLUDE）。可按schema/表/类型过滤。Schema元数据列出所有外键关系。可按schema/表过滤。Schema元数据列出所有索引及定义和大小。可按schema/表过滤。Schema元数据列出已应用的数据库迁移记录。Schema元数据列出已安装的PostgreSQL扩展。

华为云官方博客 433

华为大数据Flink让每一 CU 算力，跑出开源 5.74 倍的性能

1. 开源Apache Flink 已成为业界流计算事实标准，但在极端重负载场景下存在性能瓶颈。2. 华为大数据Flink通过多项自研深度优化，在执行计划、算子执行、状态存储三个层面构建协同的优化体系。3. Nexmark Benchmark 测试结果：整体性能提升 5.74 倍，极端重负载场景性能领先最高 18.3 倍。4. 100% 兼容 Apache Flink 1.20，业务代码零改造，无缝迁移。

华为云官方博客 351

LakeAgent实战 | 业务分析篇从一句提问到业务分析

本文以“订单金额变化”分析为例，展示LakeAgent如何通过自然语言提问，结合DataArtsStudio的数据资产与专业技能，帮助业务人员快速定位数据、生成SQL、追踪血缘、生成报告。从问题出发，逐步实现数据发现、变化洞察、原因追溯与团队协作，最终形成可复用的分析流程与企业规则，显著提升数据分析效率与一致性。

华为云官方博客 358

华为云RDS Supabase AI应用已开放公测 ：30分钟搭建AI应用后端

认证、存储、实时推送、数据库API——4个后端模块，传统开发需要数周。今天，你只需要30分钟。AI创业公司的全栈开发工程师。上周老板说"下周要上线的AI对话应用，后端你来搞"——认证鉴权、数据库接口、文件存储、实时推送，每一个模块都需要数周搭建，而市场不会等你。小张打开华为云RDS Supabase，30分钟搭好认证、数据库API、对象存储，剩下的时间全用来打磨AI交互体验。基于开源Supabase+华为云RDS PostgreSQL全托管能力，为开发者提供。

华为云官方博客 354

如何使用RDS Supabase后端BaaS能力：数据库函数（Database Function）

上一篇介绍了 Database Data API——建表即自动生成增删改查接口，解决单表读写，但聚合统计、跨表事务、字段自动维护等逻辑已超出其能力边界。本篇推进到数据库函数（Database Function）：把业务逻辑封装进数据库，前端通过 .rpc() 调用，由触发器自动响应数据变更。上一篇中，小张基于 Data API 完成了产品目录的建表与基础读写。但新需求随之而来：按分类统计产品数与价格区间、上架新品同时写产品表与定价表、产品修改后自动刷新更新时间。

华为云官方博客 437

如何使用RDS Supabase后端BaaS能力：创表即生成API（Database Data API）

认证、存储、实时推送、数据库API——4个后端模块，传统开发要数周。本系列逐个拆解，首篇聚焦数据库API（Database Data API）：建表即得 API，无需手写后端。小张，AI创业公司的全栈工程师。老板让他做个产品目录页，展示产品与价格、支持上下架。传统做法要搭后端、写接口、配权限，工期少说1-2周；而在华为云RDS Supabase，建两张表、应用 SDK 直连，几分钟增删改查全跑通。

华为云官方博客 454

从一句话到一个能出去的链接，AI开发者空间做了什么

自行搭建的 Agent、正在使用的开源项目、团队既有的工具，都可以接入，可以通过AI创建或者手动搭建环境；华为云 AI开发者空间——面向开发者的云端一站式开发平台，做的就是把这段路接上：环境免安装，浏览器打开即为完整的 Linux 运行环境，预置的 AI 智能体开箱即用。第一个任务建议选能出结果的：做一个游戏、生成一个页面、创建一台实例，从需求走到可访问的链接，一次就能看清这个环境在做什么。沙箱是一个完整的 Linux 环境，依赖、服务、端口都是真实的，不是模拟。环境释放后，权限随之失效。

华为云官方博客 411

华为云码道配置自定义大模型，四种方式完整实操

案例介绍。

华为云官方博客 604

图数据库：实现穿透式监管的数据基座

穿透式监管标志着国企监管从“管企业”向“管资本”转型过程中的关键一跃。而图数据库正是这一跃的技术支点。从股权穿透到资金链穿透，从供应链穿透到数据穿透，华为GES图数据库正在将“穿透式监管”从理念变为可落地、可操作的实践。无论是天眼查式的全量链路查询，还是某集团财经的税务规则判断，抑或是芯片供应链式的部件风险分析，乃至通过Palantir构建决策知识图谱，其底层逻辑都是一致的——用图的力量，穿透一切形式的“隔离层”，直抵风险本质与责任核心。

华为云官方博客 652

《公共云三十问》正式收官，奔赴企业AI百场景新征程

今年6月底，公共云产业联盟重点推出《公共云三十问》专栏，以每周三问的节奏，连载十周，解读《先进公共云》白皮书，分享国计民生系列案例，旨在凝聚共识、推动落地实践。同时，专栏分析公共云在产业升级、民生福祉、科技创新、全球发展等方面的作用，梳理中国特色公共云发展路径：以普惠云拓展用云广度，以智算云提升用云深度，以自主云夯实用云厚度，以全球云打开用云跨度。这十问从专属云、行业云切入，深入政务、金融、交通、电力、钢铁、化工、油气、制造等国计民生场景，回答公共云“怎么用”。

华为云官方博客 465

开发者小技巧|IAM配置，让码道代码智能体连续30天免登录

案例介绍。

华为云官方博客 640

码道深度对接CodeArts，让需求自动落地为代码

案例介绍。

华为云官方博客 712

【公共云三十问 之三十】拥抱AI，企业如何建设面向智能体的专属云？

企业可分阶段建设覆盖开发、运行、运营及安全的一体化智能体平台——从构建一站式、高低码协同的智能体开发平台，到打造高性能、极致弹性的运行时环境，再到搭建AgentOps驱动的持续运营与运维体系，同时构建端到端、多层次的全链路安全防护体系。在数据湖建设方面，遵循“存量复用、平滑演进、AI导向、分步迭代”原则，分三阶段推进——打造AI多模数据湖核心能力、完成存算分离与统一元数据管理、实现闭环赋能全面支撑智能体规模化落地，在保护既有投资的前提下将传统数据平台转型为AI数据专属供给平台。

华为云官方博客 818

【公共云三十问 之二十九】国计民生之制造：制造云如何重塑数智时代的新质生产力？

平台打通软件交付的完整路径，覆盖需求管理、代码托管、代码检查、编译构建、制品仓库、部署、测试等关键环节，支持大模型能力融入研发全流程，实现从需求到交付的端到端管理。通过构建“研发一朵云”，方案打破地域与组织壁垒，实现跨团队协同开发，有效缩短软件交付周期，助力工业制造企业从“传统研发”走向“敏捷研发”，加速数智化转型进程。当制造云真正成为数据流通的平台、AI创新的底座，公共云的社会价值将从基础设施层向生产场景层持续延伸，为新型工业化建设和制造强国战略注入源源不断的动力，重塑数智时代的中国制造新质生产力。

华为云官方博客 786

告别重复手工迁仓，码道MCP+Skill实现仓库批量迁移

案例介绍。

华为云官方博客 781

【公共云三十问 之二十八】国计民生之油气：智算云如何叩响数智时代的“地心蓝金”？

西南油气田以“向地球深部要资源”为战略方向，联合以华为云Stack为代表的公共云服务商共同打造统一算力底座，建设西南区域数据湖与通用技术平台，构建“勘探开发工程技术、天然气生产过程管控、天然气产运储销”等三个一体化协同应用场景，支撑油气勘探、开发生产、管输储运等全业务链的数智化转型。当智算云真正成为数据流通的平台、AI创新的底座，油气田得以将算力效能、数据价值与智能技术深度融入勘探开发全链条，将“看不见的算力”转化为“摸得着的储量”，以智能化手段持续降低勘探风险、缩短发现周期、提高采收效率，确保生产安全。

华为云官方博客 612

【公共云三十问 之二十七】国计民生之化工：数智云如何重塑传统化工新范式？

在架构方面，方案构建云边协同的统一体系，涵盖AI协同、数据协同与运营协同三大维度——总部集中训练大模型，边缘节点负责推理执行，云边持续迭代，实现“边用边学”的智能闭环，模型平均精度提升20%以上。此外，方案提供一站式企业级工业物联网平台、数据湖与数据治理平台，覆盖工业数据分析“采、存、算、管、用”全流程，打通生产现场与管理系统间的数据壁垒，有效消除数据孤岛。层面，方案充分发挥软硬协同优势，实现计算、存储、网络与云平台的深度协同，训练线性度超95%，为大模型训练推理提供强劲算力支撑。▲化工“数智”新模式。

华为云官方博客 663

【公共云三十问 之二十六】国计民生之钢铁：数智云如何淬炼中国钢铁新力量？

同时，构建云边端协同的统一架构，支撑集团总部与各生产基地两级协同发展——总部集中训练大模型，边缘节点负责推理执行，云边持续迭代，实现训推一体化的资源调度与高效协同，为钢铁行业的数智化转型构建了坚实的算力底座。层面，方案构建覆盖“工业数采→边缘IT/OT融合→统一数据湖→数据治理平台→数据应用”全链路的一站式数据治理与流通平台，打通生产现场与管理系统间的数据壁垒，让数据“采得到、流得动、用得好”，加速数据价值从生产现场向经营决策层流动释放。湘潭钢铁集团的钢铁数智云，是钢铁工业智能云建设的标杆案例。

华为云官方博客 524

LakeWatch——MRS 智能运维Agent

从资源池、队列、作业等多个维度，对集群CPU与内存资源进行精细化分析与对比，直观呈现不同时间段的空闲、满载等使用状态，识别资源浪费，指导治理优化，为扩缩容决策提供数据支撑。对HDFS存储进行多维度深度分析（目录、用户、用户组等），涵盖使用量、增量、文件大小分布及数据热度等指标，帮助快速识别增长较快的目录、长期未访问的文件，统计目录文件数量与小文件占比，评估HDFS总存储量与扩缩容需求，为存储治理与资源规划提供全面数据支撑。Agent主动巡检，识别异常趋势并提前预警，让运维从"事后处理"转向"事前预防"。

华为云官方博客 513

华为云专题文档发布：丰富的AI案例、选型指导和概念解读

发布 “云服务选型”、“云计算概念”专题，提供云服务选型指导，助您选择匹配业务的云服务，解读云计算相关概念，开启云上学习之路。开发者工具和文档专区上线，提供从学习、实践到反馈的全链路支持。帮助中心新增100余篇AI案例。

华为云官方博客 286

一个人，也能用AI做点“星东西”

华为云星耀创想者大赛-2026华为云OPC创意大赛等你来~

华为云官方博客 289

从需求到可执行工作项：MCP+Skill 让智能体规划真正落地

回顾整个体验，以前让智能体帮我拆需求，它是洋洋洒洒给我列了一大篇 Markdown，看着挺像那么回事，但最后还是得我一条条往 CodeArts Req 里搬，搬完再手动挂父子关系、排日期，拆需求五分钟，搬运两小时。现在好了，MCP 给智能体接上了"手"，Skill 给它装上了"项目经理的脑子"，一句话下去，34 个工作项连带排期、层级关系全给我建好了，甘特图一拉，齐刷刷都在两周内，节省了多少工作量啊，美滋滋。本次实操在码道代码智能体基础上，构建了一套"需求→可执行工作项"的自动化规划方案。

华为云官方博客 561

华为云码道「码力续航计划」更新！

✅上新GLM‑5.3‑Flash，高速响应，代码生成、工程解析、Agent调试高效输出。新增GLM‑5.3‑Flash福利模型，每日解锁1000万免费Tokens。● 本次活动共发放总量价值100万元Tokens，发完即止！把耗算力的编码重活，交给华为云码道代码智能体🚀🚀。● 每日额度准时刷新，当日清零、次日满血重置。✅复杂算法、大项目解析、批量代码生成随便跑。✅不用抠额度、不用算消耗，放开调试大胆迭代。✅无需额外操作，登录即送，直接切换模型使用。● 把算力交给码道，让撸码不再内耗👏🏻。

华为云官方博客 677

【公共云三十问 之二十四】国计民生之交通：交通云如何铺就数智通衢新坦途？

交通行业作为支撑实体经济的关键基础设施，涵盖公路、铁路、机场、港口、地铁等众多子领域，其中，公路网络作为综合交通运输体系的基础骨架，承担着全国超过70%的客货运量，其数字化、智能化转型的需求尤为迫切。方面，提供Agent开发框架、知识库管理、RAG工程、意图识别、静态应用编排及模型评测等能力，支持客户将行业知识、业务流程与AI能力深度融合，快速构建面向收费稽核、路网调度、应急处置等场景的智能应用。开发并实现落地应用，全面覆盖建设、管理、养护、运营、服务、安全、办公七大业务领域。

华为云官方博客 460

【公共云三十问 之二十五】国计民生之电力：电力云如何点亮数智电力新引擎？

方案构建了覆盖数据获取、质量评估到标准化处理的全链路能力。基于公共云服务商智算底座及气象大模型，通过时空图神经网络重新建模产流机制，中国华电建成超50TB多源融合数据集，突破时空建模与机理融合等五大关键技术，短期径流预测精度较传统机理模型提升5个百分点以上，实现15天中期径流预测精度超85%，推理效率达秒级。基于气象大模型的基础架构与预训练能力，客户可直接在大模型之上开展增量训练与微调，充分利用场站所在区域的高精度历史数据（如3公里、1公里分辨率），针对不同场站和区域的地形地貌与气候特征进行模型调优。

华为云官方博客 380

邀请函｜第三届“兴智杯”全国人工智能创新应用大赛开幕式，期待您现场莅临

AI 算法工程师、大模型应用开发、智能编码、国产软硬件栈开发者、开源开发者。大赛官方参赛对象就包含企事业单位开发者团队、个人开发者中华人民共...诉求：了解本届赛题方向、对接算力 / 技术资源、认识同行、获取参赛信息。意向参赛团队、往届参赛选手、技术团队负责人、个人独立开发者。

华为云官方博客 478
上一篇： 一文了解Spring Boot启动类SpringApplication
下一篇： 硬核解读，WeTune是如何提升数据库查询重写性能？
点赞 21
评论 0
书签 书签 8
华为云开发者联盟
华为云开发者联盟 企业官方账号 企业官方账号
博客等级 码龄10年 72万+粉丝 5984原创
+ 关注 专栏目录 订阅专栏
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值