简介：《阿里云专有云企业版 V3.12.0 DataWorks 用户指南（20200706）》面向企业数据平台管理员、开发人员与运维人员，系统讲解专有云环境下 DataWorks 的登录控制台、工作空间创建、快速入门、数据集成、数据开发、数据治理、数据服务与数据安全等核心模块，可作为搭建和使用大数据开发管理平台的参考手册。资源共 1 个 PDF 文件，约 32.03MB，保留官方文档的目录层级、法律声明与通用约定，并包含操作警示、格式说明及命令行示例等细节，便于按章节检索。已有 187 人学习下载。读者可从中了解工作空间权限与资源配额设置、SQL/Python 任务编写、图形化 ETL 编排、元数据与数据质量检查、API 发布、角色权限与数据脱敏等实操要点，适合需要系统查阅专有云 DataWorks 功能与规范的中高级用户。

1. 先弄明白它是什么：一个把数据“搬进来、算出来、管起来”的工作台

第一次看到“DataWorks 用户指南”这几个字，很多人会以为是某个软件的安装说明。其实换个说法就好懂了：它是一间数据工厂的总控台。在这块网页界面上，你能把业务库里的订单数据搬进来，写完一段 SQL 让它每天早上八点自动跑一遍，跑完再回头检查昨天的数据有没有缺行。做大数据开发、零基础入门，最怕的是一上来就被几十个菜单吓住，而这份 V3.12.0 的用户指南，本质上就是这间工厂的操作手册。

它服务的人群比想象中宽：做数仓的、写报表的、做数据治理的，甚至只是想把几张 Excel 背后的库表对上的业务分析同学，都能在里面找到能用的模块。所以别急着背菜单，先建立“数据是流水线上流动的东西”这个感觉，后面每一步都会顺很多。

2. 为什么零基础也值得学：从“取数”到“出报表”的完整链路

新手最容易犯的错，是把 DataWorks 当成一个“写 SQL 的地方”。它确实能写 SQL，但写 SQL 只是中间一环。真正让它有价值的是把零散动作串成一条不靠人盯的链路：数据进来、按规则加工、加工完做质量检查、检查通过再对外提供接口。这条链路一旦搭起来，昨天还靠人手工导表的工作，今天就能自己按时跑。

所以学它的正确顺序不是“先背函数”，而是先看清每条流水线各自负责什么，再挑一条最短的路线走通一遍。

2.1 把 DataWorks 想成一家数据工厂：四条流水线

我用一个开厂的类比来讲，比看架构图好懂得多。

第一条是搬运车间，也就是数据集成。它的活是把数据从 A 挪到 B。A 和 B 可以是 MySQL、SQL Server、PostgreSQL、Oracle、DM、DRDS、POLARDB、HBase、Hive、OSS、MongoDB、Redis、LogHub、Elasticsearch 这些常见存储中的任意两种。搬运工分两个角色：Reader 负责从源头读，Writer 负责往目标写，一读一写配成一对，叫一个同步任务。你不需要写代码去连数据库，配好连接信息、选好表、映射好字段，它自己搬。

第二条是加工车间，也就是数据开发。搬进来的原始数据通常不能直接用，要清洗、关联、汇总。这里提供几种干活的工具：写 SQL 的节点、把常用 SQL 封装成组件的节点、跑 Spark 程序的节点、写 Python 的节点、以及把一段脚本整体提交的节点。你可以把它们像积木一样串成一个业务流程，前一步的输出就是后一步的输入。

第三条是质检车间，也就是数据治理。数据搬完算完，得有人回答“这份数据可信吗”。这里管三件事：数据资产（有哪些表、谁在用）、元数据（表结构、字段含义、血缘关系，也就是这张表是从哪几张表算出来的）、数据质量（配规则，比如主键不能重复、金额不能为负，跑完出报告）。

第四条是发货窗口，也就是数据服务。加工好的结果不能只躺在库里，业务系统要调用。这里能把一张表或一段查询发布成数据 API，别人按接口文档传参数就能拿到结果，不用直连你的库。

这四条线合起来才叫一个平台。新手常有的困惑是“我该从哪条学起”，我的建议很明确：从第一条开始，因为搬运是唯一一个不需要你懂业务逻辑、只看配置就能出结果的模块，成就感来得最快。

2.2 专有云版本和公有云版本，新手要知道的那一点差别

这份指南的标题里有个词很关键：专有云企业版。它不是那种打开浏览器注册个账号就能用的形态，而是部署在你自己单位的机房里的整套系统。

这个差别会直接影响你第一步怎么迈。公有云上你关心的是“怎么注册、怎么实名”，专有云上你要关心的是另外三件事：控制台地址是管理员给你的内网地址，不是随便搜得到的域名；账号是管理员开的，你自己注册不了；你要连的数据源大概率也在内网，IP 和端口得找对应系统的负责人要。

我第一次接触这类环境时踩过的坑，就是拿着公有云的教程一步步照做，卡在第一步登录上整整半天，最后才发现地址根本不对。所以记住一句话：专有云环境下，第一件事永远是找管理员，而不是找教程。

2.3 学完能做什么：三个最常见的使用场景

说点具体的，让你知道学它到底能换成什么。

场景一：日常取数。业务同事要一份“上个月各地区销售额”，以前的做法是登进业务库跑 SQL、导 Excel、发邮件。学会之后，你在数据开发里建一个 SQL 节点，设成每天跑，结果写进一张结果表，谁要看自己去查，你不用每天重复劳动。

场景二：跨库同步。业务数据在 MySQL，分析在另一套系统里，两边不通。用数据集成配一个同步任务，设成每小时一次，增量字段选更新时间，两边就自动对齐了。指南里专门有一节讲整库迁移，就是把一整个库的表批量搬过去，不用一张张配。

场景三：数据质量兜底。报表数字对不上，是数据源出错还是加工逻辑错了？配好质量规则和血缘关系之后，你能顺着链路往回查，看到底是哪一环出的问题，而不是靠猜。

这三个场景覆盖了绝大多数新手的真实需求。你不需要把指南里那几十种数据源全学会，先会一种源、一种目标，就够跑通整个流程了。

3. 第一步怎么迈：登录控制台、创建工作空间

概念清楚了，接下来是动手。这一章的目标很朴素：让你成功登进去，并且拥有一个属于自己的、可以随便折腾的空间。别小看这一步，很多人的入门就断在这里。

3.1 登录前先确认三件事

在浏览器里敲地址之前，先把这三样东西凑齐，能省掉大量来回。

第一是控制台地址。专有云环境里这个地址由管理员提供，通常是一个内网 IP 加端口的形式。拿到之后先确认你的电脑能访问这个网段，最简单的验证方式是直接在浏览器打开，看能不能出登录页。打不开就别往下折腾了，先找网络或管理员。

第二是账号和密码。同样由管理员分配。这里要注意一个容易忽略的点：不同账号进来看见的菜单可能不一样，因为权限是按角色配的。如果你登录后发现某个模块是灰的或者根本看不到，大概率不是你操作错了，而是这个账号没被授权。这种情况直接问管理员要权限，别自己找捷径。

第三是你要连的数据源信息。包括数据库类型、主机地址、端口、库名、用户名、密码。这些信息不在 DataWorks 里，得找对应系统的负责人要。建议一开始就记在一个地方，后面配置数据源时会反复用到。

提示：第一次登录后先别急着建东西，花两分钟把界面左上角的区域、右上角的账号信息看一遍，确认自己所在的区域和身份是对的。专有云环境有时会有多套环境并存，进错环境是很常见的翻车原因。

3.2 创建工作空间：把“项目组”开出来

工作空间是整个平台上最基础的单位，你可以把它理解成一个项目组：有自己的成员、自己的权限、自己的资源配额，组内的任务、表、数据源都在这个范围里，和其他组互不干扰。

创建的时候会填几项关键信息，我按重要性排一下。

工作空间名称和标识：名称给人看，标识给系统用，一般要求英文加数字。建议起名时带上团队和用途，比如把“营销”和“日常分析”体现在标识里，后面空间多了不至于分不清。

所属项目或资源组：决定这个空间能用多少计算资源。新手常见的问题是资源给得太小，跑一个稍大的同步任务就排队等很久，还以为是配置写错了。如果条件允许，开始时就和管理员确认一下配额。

成员与角色：把要一起干活的人加进来，并且分配角色。这里有个血泪经验——角色不是越多越好。开发、运维、访客的权限差别很大，给一个只需要看报表的同学开开发权限，后面出问题很难追溯。按最小必要原则给就行。

创建工作空间这个动作本身几分钟就完事，但它决定了后面所有操作的地基。我当时图省事，用了默认名字，结果一个月后开了五六个空间，自己都分不清哪个是哪个，只能一个个点进去看内容。这个坑完全可以在起名那一步避免。

3.3 进去之后先点这四处，别乱逛

进了工作空间，左侧菜单一大排，新手很容易从第一项开始逐个点开，点完一圈什么也没记住。我的建议是先只认四个入口。

数据源管理：所有同步任务的前提。你要用的那个库，得先在这里登记成一个“数据源”，填好连接信息并点测试连通性，显示成功才算数。这一步不通，后面全白搭。

数据开发：你花时间最多的地方。建表、写 SQL、编排任务、配同步，都在这里。

运维中心：任务跑完之后去哪看结果、看日志、看失败原因。新手往往只在数据开发里点“运行”，跑失败了不知道去哪查，其实答案都在运维中心的任务实例里。

数据服务：等你把数据加工好了，想让别的系统调用，再来看这里。入门阶段可以先放着。

把这四个入口记住，剩下的菜单等你真的需要时再看，一点都不迟。平台的功能多是给不同角色准备的，你不需要全都会。

4. 跑通第一个例子：从建表到同步任务跑出结果

这一章是整篇里最该动手的部分。我们做一个最小但完整的例子：把一张业务表的数据同步过来，落到一张新表里，然后让它按周期自动跑。整个过程分四步，每一步我都给出可直接参考的配置和一个白话解释。

4.1 第一步：建一张表，把数据传上去

先在数据开发里建一张目标表。下面这段是建表语句，字段按你自己的业务改，重点是看懂每一行在干什么。

-- 建一张订单明细的目标表，命名建议带层级前缀，比如 ods_ 表示原始层 CREATE TABLE IF NOT EXISTS ods_order_detail ( order_id STRING COMMENT '订单号，唯一标识', user_id STRING COMMENT '用户标识', city STRING COMMENT '下单城市', amount DECIMAL(18,2) COMMENT '订单金额，保留两位小数', pay_time STRING COMMENT '支付时间，原始数据按字符串接入', dt STRING COMMENT '分区字段，按天分区，格式 yyyyMMdd' ) COMMENT '订单明细原始表' PARTITIONED BY (dt STRING); -- 按天分区，后面同步时用来区分批次

逐行说一下。IF NOT EXISTS是为了防止重复执行时报错，建表脚本经常会跑第二遍。字段类型里金额用DECIMAL(18,2)而不是浮点数，是因为浮点数算钱会出现精度误差，这类问题排查起来非常费劲。时间字段先用STRING接，是因为很多源库的时间格式不统一，先原样接进来，后面在加工层再转成标准时间类型，比在同步环节硬转要稳。最后按天分区，是为了后面同步任务能按批次写入，出问题时也能只重跑某一天。

表建好之后，如果你想先手动传一点测试数据验证流程，可以用平台提供的上传功能传一个 CSV，注意列的顺序要和建表语句一致，分区字段一般不在文件里，而是在上传时单独指定。

4.2 第二步：建业务流程，把同步任务配出来

在数据开发里新建一个业务流程，然后在这个流程下新建一个数据集成节点。配置方式有两种：界面引导的向导模式和直接写配置的脚本模式。新手先用向导模式，跑通之后再看脚本模式，会更清楚每一项对应什么。

脚本模式的核心配置长这样：

{ "type": "job", "version": "2.0", "steps": [ { "stepType": "mysql", // 源头类型，这里以 MySQL 为例 "name": "reader", "parameter": { "username": "read_user", // 建议用只读账号，别用业务主账号 "password": "******", "connection": [ { "querySql": "select order_id, user_id, city, amount, pay_time from orders where dt = '${bizdate}'" } ] } }, { "stepType": "odps", // 目标端类型，具体按你的环境选 "name": "writer", "parameter": { "partition": "dt=${bizdate}", // 分区值用调度参数动态替换 "column": ["order_id", "user_id", "city", "amount", "pay_time", "dt"] } } ], "setting": { "errorLimit": { "record": 0 }, // 容忍的脏数据条数，0 表示一条都不放过 "speed": { "concurrent": 2 } // 并发数，调大能提速，但要先看源库压力 } }

几个参数值得单独解释。stepType决定用哪个插件，源头是 MySQL 就写对应的 reader 类型，目标是哪里就写对应的 writer 类型，指南里对每种数据源都有专门的配置章节，配置时对照着看最稳。querySql里出现的${bizdate}是调度参数，运行时会被替换成具体日期，这就是“同一份配置每天跑不同数据”的关键，千万别把日期写死。

errorLimit里record: 0表示遇到一条脏数据就整任务失败。新手会觉得这样太严格，但恰恰是好事——它逼着你第一时间发现问题，而不是让脏数据悄悄流进去，等你一个月后发现报表数字不对再回头查。

speed.concurrent是并发数，调大确实快，但如果你的源库本身负载就高，并发抢连接可能把线上业务拖慢。第一次配置时先用 1 或 2，观察一段时间再调。

配置完别急着跑，先点一下测试连通性，确认源和目标都能连上。这一步能提前拦掉一大半“任务跑失败”的问题。

4.3 第三步：设置周期和依赖，让任务自己按点跑

手动跑一次成功，只说明配置对；能按周期自动跑，才算真正用起来。

在节点的调度配置里，需要设几个东西。调度周期选天，表示每天跑一次。调度时间决定几点开始，建议放在源库业务低峰期，比如凌晨。依赖关系最关键：这个同步任务依赖谁？如果它依赖上游的另一张表，就要把上游节点配成它的父节点，这样上游没跑完，它不会先跑，避免读到半截数据。

这里还有一个容易混淆的概念：调度时间和数据时间不是一回事。你设凌晨两点跑，但同步的可能是“昨天”的数据。所以脚本里用${bizdate}而不是用系统当前时间，这个参数会自动取到业务日期，具体取值规则在调度配置页面有说明，第一次配置时对着看一眼，能少走很多弯路。

配完之后把节点提交并发布到运维中心。注意“保存”和“提交发布”是两个动作，只在数据开发里保存，运维中心是看不到这个任务的，很多人卡在这里，以为任务丢了。

4.4 第四步：运行、看日志、排错

发布之后，在运维中心找到这个任务，可以先手动触发一次补数据运行，验证整条链路。

跑完之后要看的不是只有一个“成功”二字。点进实例详情，看三件事：读取条数、写入条数、耗时。如果读取一万条写入零条，那大概率是字段映射错了或者写入条件不满足。如果两者差很多，看看是不是有脏数据被过滤了。

失败的情况下，日志里通常会给出行号或者具体字段。最常见的三类报错是连接超时、字段类型不匹配、分区不存在。前两个去查数据源配置，第三个去查目标表的分区是不是已经建好——有些环境需要你手动把分区创建出来，写入时才能落进去。

跑通这一次之后，你就完成了从“看懂菜单”到“真的让数据动起来”的跨越。后面所有的复杂任务，本质上都是这个流程的叠加。

5. 新手最容易踩的五个坑：现象、原因和补救办法

这一章是我认为最该先读的部分。下面五条几乎每个新手都会遇到至少两条，提前知道能省下大量时间。

5.1 配置类的三个坑

坑一：测试连通性一直失败，但用客户端工具明明能连上。

现象是你在数据库客户端里连得好好的，到平台上就是不通。原因是平台执行任务的机器和你的电脑不是同一台，它能访问的网段和你不一样，你电脑上的网络策略不代表它也通。解决办法是先找管理员确认执行任务的那批机器到目标库的网络是否放通，端口是否开放。这个问题靠改配置解决不了，必须走网络确认。

坑二：任务跑成功了，但目标表里没数据。

现象是日志里显示成功，查询结果却是空的。最常见的原因是分区没对上——你写了dt=20240101，但实际查询的时候没指定分区，或者写入的分区和查询的分区不是同一个。还有一种可能是字段映射时顺序错了，数据其实写进去了，只是写到了别的列里。解决办法是先按分区查一遍，再核对字段映射的顺序，别只看任务状态。

坑三：改完配置重新跑，跑的还是旧逻辑。

现象是明明改了 SQL，结果没变。原因是节点修改之后没有重新提交发布，运维中心执行的还是上一个版本。这个坑特别隐蔽，因为数据开发界面上显示的是新代码。解决办法是养成习惯：改完必提交，提交后去运维中心确认一下版本时间是不是刚才。我现在的做法是每次改完都看一眼发布时间，宁可多花十秒。

5.2 运行与权限类的两个坑

坑四：自己的任务能跑，同事打开就报没权限。

现象是同一个节点，你能运行，别人报权限错误。原因是数据权限和空间成员权限是两套东西，把人在工作空间里加进来，不代表他能读那张表。解决办法是明确区分：工作空间成员负责“能不能进这个空间”，表权限负责“能不能读这张表”，两个都要配。新人入职时直接按角色模板配一遍，比事后一个个补要省事。

坑五：任务偶尔失败，重跑就好，找不到规律。

现象是十次里失败一两次，重跑就成功。这类问题最难查，通常和资源排队、源库瞬时压力、或者任务之间抢同一份资源有关。解决办法是先看失败时间点有没有规律，再看当时的并发数和资源使用情况。如果确实是资源紧张，把并发调低、把调度时间错开，往往比优化 SQL 更有效。这类问题别急着改代码，先看环境。

注意：以上五条里，有三条是“配置没错但环境不对”。新手容易默认所有问题都是自己配错了，然后反复改配置，越改越乱。遇到报错先问一句：这是配置问题，还是环境问题？

6. 下一步学什么：三阶段路径和一个具体技巧

跑通第一个例子之后，很多人会陷入“接下来学什么”的迷茫，因为指南目录实在太长了。我给一条我自己走过的路径，分三个阶段，每个阶段只盯一件事。

第一阶段，把数据集成吃透。目标不是学会所有数据源，而是彻底搞懂一种源到一种目标的完整配置：连接怎么测、字段怎么映射、增量怎么取、脏数据怎么处理、失败了怎么重跑。这五件事弄明白，换一种数据源只是换个插件名而已。指南里数据源配置那一大章看着吓人，其实结构完全一样，看懂一个就等于看懂了模板。

第二阶段，进数据开发。这时候你开始需要写加工逻辑了。顺序建议是：先会写单表 SQL 节点，再学多节点串联和依赖，最后学调度参数和血缘。血缘这个功能特别值得早用，它能让你在结果不对时顺着链路往回追，比盲猜快得多。

第三阶段，碰治理和服务。等你有几张表在稳定产出，再考虑配质量规则、把结果发布成 API。顺序反了会很痛苦——表还没有就先配治理，规则无从下手。

最后分享一个具体技巧，也是我踩坑之后养成的习惯：每建一个新任务，先在测试空间跑三天，确认每天都成功、条数合理，再挪到正式空间。听起来慢，但比在正式环境里出问题再回滚快得多。从那以后我每次上线新任务都强制走一遍“测试空间跑三天”的流程，再没出现过半夜被叫起来看报表的情况。

学这类平台，最怕的不是难，是想一口吃成胖子。你只要把第一个同步任务跑通，剩下的都是在这个骨架上加东西。希望帮到你。

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