企业官网建设流程全解析

简介：华为云数据中台解决方案介绍是一份面向企业数据架构师、大数据平台工程师及售前顾问的技术文档，旨在帮助企业构建统一的数据管理平台，解决多源数据汇聚、存储、加工、服务与治理等核心问题。资源包内为1个PDF文件，大小2.44MB，内容聚焦华为云数据中台的完整方案。文档重点解析了贴源层、共享层、分析层、应用层四层架构及选型原因：贴源层负责数据采集、存储与高并发写入；共享层提供高效数据访问与更新删除能力；分析层支撑高并发查询与强资源隔离；应用层提供多种API接口。同时对DRS、MRS、DWS、DLI、DAYU五大组件进行功能拆解：DWS支持流式数据实时入库与万亿级数据毫秒级查询，DAYU提供数据资产管理和血缘分析，DLI支持跨源分析以打破数据孤岛，MRS则提供大数据分析引擎。读者可从中获取数据集成、数据仓库建设、数据治理与跨源分析的设计参考，应用场景覆盖大数据分析与挖掘、数据资产管理、数据安全审计、数据集成与交换等，并包含电力、电网等行业的落地案例。目前已有977人学习，适合作为数据平台规划、技术选型和售前方案撰写的参考资料。

1. 数据中台不是买来的，华为云这份 PDF 能给你的和给不了你的

拿到《华为云数据中台解决方案介绍.pdf》这类文档，很少会有工程师逐字读完。大家真正想要的是：看完能不能给客户或老板讲清楚数据中台怎么搭，以及动手时第一步做什么。这类 PDF 通常会把数据接入、数据处理、数据治理、数据服务画成一张光鲜的架构图，但它不会告诉你租户权限怎么分、调度参数怎么设、冷数据何时归档。这里把 PDF 里的高频组件映射到具体工程动作，用 OBS、DLI、DGC 组合出一条可运行的数据链路，再把成本、一致性、验收这些容易被方案介绍带过的话题讲透。适合正在做中台选型的数据架构师，也适合要交付 POC 的数据开发和云服务运维人员。

2. 华为云数据中台的架构分层与核心组件选型

常见方案 PDF 会画一个“数据源 → 数据接入 → 数据开发 → 数据资产 → 数据服务”的架构，对应到华为云，通常由一组服务组合而成，而不是一个单独的“中台产品”。如果只能用一句话记住，那就是：OBS 放原始数据，DGC 做治理和编排，DLI/DWS 做计算，ROMA 做服务共享。下面按层拆开看。

2.1 数据接入层：CDM、DIS、ROMA Connect 的选型边界

接入层最常见的是数据库同步、日志流、API 调用三种场景。CDM 用于快速迁移和周期批量同步，适合 MySQL、Oracle 到 OBS 或 DWS 的数据搬迁；DIS 用于实时流接入，适合 IoT 设备日志、Web 埋点这类持续产生的数据；ROMA Connect 用于企业系统间 API、消息和事件集成，适合异构系统打通。这三者并不是互斥关系，很多中台会同时使用。

选型时可以优先看“数据是批量到、还是持续到”。批量到用 CDM，持续到用 DIS；如果两个系统之间还要做接口编排，再叠加 ROMA Connect。POC 阶段从 CDM 开始成本最低，一条链路跑通后再加流式接入也不迟。

2.2 数据开发与治理中枢：DGC 把中台动作变成作业

DGC（DataArts Studio）承担数据开发、作业编排、调度、血缘和质量管理。在方案图里，DGC 作业由节点和连线构成，一个最简单的周期作业可以只包含一个 SQL 节点，先清理昨天的临时表再重建。下面这份 JSON 是 DGC 作业定义的简化示例，对应控制台“数据开发 → 作业开发”页面里的配置结构：

{ "name": "ods_user_log_daily", "nodes": [ { "name": "clean_and_build_ods", "type": "DLI_SQL", "properties": { "sql": "CREATE TABLE IF NOT EXISTS ods.user_log ...", "database": "ods", "queue": "default" } } ], "schedule": { "type": "CRON", "cron": "0 0 2 * * ?" } }

这里的type对应 DGC 支持的节点类型，此处使用 DLI_SQL 表示在 DLI 队列上执行 SQL。schedule.cron是 Quartz 风格表达式，0 0 2 * * ?表示每天凌晨 2 点触发，?用于“不指定星期几”。SQL 节点里的database和queue决定作业在哪个库、哪个计算队列上跑，这两个参数在多人共用一个 DGC 环境时必须显式设置，否则作业会落到别人的默认资源上。

调度参数是 DGC 使用里最容易踩坑的地方：

DGC 的作业之间可以设置依赖关系，例如“数据质量作业”必须在上游作业成功后运行。血缘关系会自动生成，在数据资产模块中可以看到表级链路。多团队共享 DGC 时，建议给作业加后缀区分环境，比如prd_ods_daily、dev_ods_daily，避免互相覆盖。

2.3 数据湖与数据仓库：OBS、DLI、DWS、MRS 的分工

数据存哪里，决定中台是“湖”还是“仓”。OBS 是对象存储，所有原始文件都放这里；DLI 是无服务器 SQL 引擎，直接在 OBS 上做探索，适合临时分析；DWS 是数据仓库，适合高并发报表和固定模型；MRS 是托管大数据集群，适合 Spark、Flink、Hive 这类需要自定义运行时的计算。方案里写“湖仓一体”时，通常就是 OBS + DLI/DWS 并存。

下面是一段在 DLI 上创建外表映射 OBS 文件的 SQL：

CREATE TABLE IF NOT EXISTS dws_demo.user_log ( user_id STRING COMMENT '用户ID', action STRING COMMENT '动作', event_time TIMESTAMP COMMENT '事件时间' ) USING CSV OPTIONS ( path = 'obs://your-data-lake-bucket/raw/logs/', header = 'true' );

path指向 OBS 桶中的原始目录，header = 'true'表示 CSV 文件第一行是表头。使用CREATE TABLE ... USING CSV时，DLI 并不会立即读取数据，而是建立表与文件的映射关系；第一次查询时才启动计算引擎扫描文件。因此建表阶段即使源文件字段顺序有问题，也不会立刻暴露，只有查询时才会报错。对固定报表场景，建议把高频查询的数据从 OBS 落到 DWS，用 DWS 的列存和索引换查询性能。

3. 最小闭环落地：用 DGC + DLI + OBS 从零构建一条数据链路

方案 PDF 看完，下一步是在云账号里跑通“文件进来、数据能查、任务每天跑”的最小闭环。不需要一开始就上完整的数据治理和指标平台，只需要一个 OBS 桶、一个 DLI 队列、一个 DGC 作业。

3.1 创建 OBS 桶与目录规划

OBS 桶是数据中台的家，建议按业务建桶，而不是把所有数据塞进一个桶。目录按分层命名：raw放原始数据，processed放清洗后数据，archive放冷数据，temp放临时文件。在服务器上安装 obsutil 后，用下面的脚本初始化：

#!/bin/bash # 创建 OBS 桶并初始化分层目录 BUCKET=your-data-lake-bucket REGION=cn-north-4 obsutil mb obs://$BUCKET -location=$REGION for dir in raw processed archive temp; do echo "" > .keep obsutil cp .keep obs://$BUCKET/$dir/.keep done

obsutil mb用于创建桶，-location必须和后续计算资源所在区域一致，否则跨区域读写在性能和流量费上都不划算。obsutil cp在这里是上传一个空占位文件，避免控制台上看不到“空目录”。实际运行中，archive目录往往放在单独的低频或归档存储桶中，由生命周期规则管理，而不是和热数据混在一起。

3.2 创建 DLI 队列与数据连接

DLI 队列有按需和包周期两种计费模式。POC 阶段选按需，测试完及时删除，避免闲置扣费。在 DGC 中创建数据连接时，需要填 DLI 队列名、OBS 桶路径和 AK/SK 或委托。连接类型选 DLI，访问方式建议用委托而不是长期密钥，这样 DGC 作业运行时能临时获取权限，密钥不落盘。这里最常犯的错误是只建队列不配置队列资源规格，导致 SQL 调度时因为内存不足直接失败。

3.3 配置调度、重试与失败告警

把刚才的 SQL 节点包装成周期作业，调度周期支持分钟、小时、天和自定义 cron。生产环境通常配置每天凌晨执行，因为上游数据源一般按天产出。调度参数需要重点关注：

DGC 支持配置“依赖作业”，在周期调度中选择上游作业，只有上游成功后当前作业才会启动。例如先执行原始数据接入作业，再执行指标计算作业，最后执行数据质量检查。建议把每个作业名加上环境前缀，比如prd_dws_daily、prd_dqc_daily，这样调度监控页面上扫一眼就能分辨任务归属。

4. 冷热数据分层与归档表：降低中台存储成本

数据中台运行半年后，存储成本通常超过计算成本。几十 TB 的日志被反复查询的机会远低于新鲜数据。热数据在 DWS/DLI 中被高频访问，不需要立即归档；中低频明细数据放在 OBS 标准存储；超过 90 天、只做审计或追偿的数据，应该进入低频访问或归档存储。这就是冷热分离。

4.1 用访问频次而不是“年龄”定义冷热

判断冷热不能只看数据生产时间。一个分区最近 30 天没有被查询，且下游任务只有月度批量读取，可以视为温数据；超过 180 天没有查询，且不需要单条随机读取，就是冷数据。反过来，一张生产日期很早的系统维表如果每天被 join，仍然是热数据。常见做法是在数据资产平台记录表或分区最后访问时间，再结合下游调度依赖，确定分级策略。

4.2 按时间分区：在写数据时就为归档做好准备

归档的前提是表有清晰分区，否则无法按时间批量搬移。在 DLI 或 DWS 中，时间字段设置为分区列，比建一张大表再删历史高效得多。下面是一个以天为分区的归档表创建示例：

CREATE TABLE IF NOT EXISTS dws_demo.user_log_archive ( user_id STRING, action STRING, event_time TIMESTAMP ) PARTITIONED BY (dt STRING);

PARTITIONED BY (dt STRING)表示按天分区，分区值作为独立字段出现在查询条件中。查询时用WHERE dt >= '2026-01-01' AND dt < '2026-02-01'能触发分区裁剪，只扫描对应目录。归档时也只需要复制或移动对应分区目录，不需要重写全表。需要注意分区字段不能出现在字段表里，否则建表会报重复定义。

4.3 用 OBS 生命周期策略自动将冷分区沉降到归档存储

手动搬数据不现实，OBS 支持桶级生命周期规则，按对象前缀自动转换存储类别。例如把processed/下超过 90 天的对象转低频，超过 180 天转归档。下面是一份生命周期规则配置：

{ "rules": [ { "id": "move_processed_to_archive", "prefix": "processed/", "status": "Enabled", "filter": { "prefix": "processed/" }, "transitions": [ { "days": 90, "storageClass": "STANDARD_IA" }, { "days": 180, "storageClass": "GLACIER" } ] } ] }

prefix限定规则只作用于processed/目录下的对象；第一个transition表示 90 天后转低频访问，第二个表示 180 天后转归档。规则设置前要确认下游任务是否还会读取这些文件，否则产品同学临时要求查历史明细时，需要等待解冻流程。归档表不是一个物理上的大表，而是一组前缀一致、分区清晰的数据文件目录，生命周期规则就相当于归档执行器。

5. 分布式事务与数据一致性：中台调度必须避开的坑

数据中台的调度器天然是分布式定时任务。当任务被拆到多个节点并行运行时，数据一致性不再是单库事务能解决的。你需要处理的是任务级别的幂等、重试、补偿和对账。DGC 只管触发和执行，不会替业务数据做去重和校验。

5.1 数据管道也有事务边界

数据库事务强调 ACID，但数据管道面对的是多个系统、多张表，很难用全局锁。常见做法是把一个作业拆成“读取 → 写入 → 确认 → 通知”四个阶段，事务边界设在“写入成功”这个节点。如果写入中途失败，重试时可能已经写了一半，所以必须让目标写入是幂等的，或者有清理步骤。很多方案里用“先删分区再写”来实现这一点，但删和写之间如果间隔过长，查询会看到空分区。

5.2 幂等写入：目标表要有唯一键和去重逻辑

最简单的幂等设计是在目标表上建唯一键，导入时用INSERT OVERWRITE或MERGE。DWS 支持 upsert，DLI 可以先在临时表里去重再写回目标表。下面这句 DLI SQL 示意如何按用户和时间去重，避免重复入库：

INSERT OVERWRITE TABLE dws_demo.user_log SELECT user_id, action, event_time FROM ( SELECT user_id, action, event_time, ROW_NUMBER() OVER (PARTITION BY user_id, event_time ORDER BY action) AS rn FROM ods.user_log ) t WHERE rn = 1;

ROW_NUMBER()按user_id和event_time分组，重复数据只保留字典序最小的action行。结合INSERT OVERWRITE覆盖目标表分区，即使上游重复推送，最终结果也不会出现双份。使用MERGE时要注意更新键选择，键选择不好会引发目标表锁竞争，尤其是在多作业同时写一张表时。

5.3 分布式定时任务的重试、补偿和告警

DGC 的节点重试只针对任务执行失败，不解决业务数据缺失。比如源端数据已经被清理，目标端没有补到数据，任务重试也一样成功。因此需要数据对账层：每个作业结束前自动对比源表和目标表的记录数，超过阈值就告警。这属于补偿机制，比重试更可靠。

建议把统一前缀作为告警关键字，在云监控中按作业名过滤，避免每个节点失败都通知所有人。调度编排时，把“数据对账”作为每个链路的最后一个节点，它失败才算整条链路失败。

6. 从 PDF 解析到交付验收：把方案文档变成可执行清单

6.1 用 PDF 解析把方案文档变成验收清单

方案 PDF 里的表格和架构图，只靠人眼翻很难保证验收时每个组件都被覆盖。可以写一个 PDF 解析脚本，把表格内容抽出来转成 CSV，再在 CSV 旁边增加“已配置”列，作为交付清单。

import csv import pdfplumber with pdfplumber.open("solution.pdf") as pdf: rows = [] for page in pdf.pages: for table in page.extract_tables(): for row in table: rows.append(row) with open("solution_checks.csv", "w", newline="", encoding="utf-8") as f: writer = csv.writer(f) writer.writerow(["组件", "规格", "用途", "已配置"]) writer.writerows(rows)

pdfplumber适合处理文字型 PDF；扫描版 PDF 需要先做 OCR，否则抽取出来的是空列表。抽取结果不一定完全规整，每张表转成一行后可能出现空单元格，需要人工确认一遍。脚本输出的 CSV 可以作为交付核对表，逐行对应到云环境里的实际资源：OBS 桶有没有建，生命周期规则有没有生效，DLI 作业有没有配置调度，DGC 作业的失败告警有没有绑定到责任人。每一行都变成可勾选的交付项，验收就从“读过方案”变成“服务已配置并可运行”。

本文还有配套的精品资源，点击获取