企业官网建设流程全解析

简介：《阿里云 专有云企业版 V3.12.0 DataWorks 用户指南 20200706》面向企业数据平台管理员、开发与运维人员，围绕专有云环境下 DataWorks 的登录、工作空间创建与日常使用展开，可作为团队搭建和治理大数据平台的离线参考手册。全包仅含 1 个 PDF 文件，大小约 32.03MB，目录层级清晰，便于按章节检索与集中查阅。内容覆盖快速入门、数据集成、数据开发、数据治理、数据服务与数据安全等模块，并具体涉及建表上传数据、创建业务流程、配置同步任务、设置周期和依赖、运行及排错、权限管理、数据脱敏与操作审计等实操要点，同时保留法律声明和通用约定，方便读者理解文档使用边界与警示级别。已有 187 人学习，适合需要对照目录完成工作空间配置、任务编排与数据治理的初、中级用户。

1. 拿到 V3.12.0 的用户指南却装不起来：这版环境到底卡在哪

某开发者拿着 V3.12.0 的用户指南来问：顺着目录点到「创建工作空间」，控制台上根本没有这一项。这跟操作快慢无关，是版本没有对上——手册的文档版本是 20200706，对应产品版本 V3.12.0；控制台一旦升过级，菜单层级、数据源类型条目、脚本模式里的 JSON 字段都会出现小幅变化。专有云企业版这套东西装不好，往往不会立刻报错：工作空间模式选错、数据集成资源组挂在不同网络域、数据源白名单少一条，表现都是「任务提交成功、目标表一条数据没有」，排查起来很困难。这篇写给两种人：第一次在专有云里把 DataWorks 从登录一路做到「一个同步任务真正跑出数」的开发者，以及接手别人环境、需要快速核对版本和配置的老手。下面按装前、装中、装坏三段走。

2. 装前清单：V3.12.0 的版本矩阵、账号和网络三件事

DataWorks 在专有云里属于由底座统一交付的服务，很难按「下载安装包、然后双击”下一步」的方式理解。控制台、调度服务、数据集成资源组、底层计算引擎分别独立发版，用户指南只负责把「怎么用」写清楚。真正动手之前，有三件事要先固定下来：版本对得上、账号有权限、网络通得到。这三件事里任意一件没确认，后面所有操作都会白做一遍。

我见过最常见的情况是，人一上来就登录控制台建工作空间，建完发现引擎项目没绑定，数据源测试连通性一直转圈，折腾两天回头才发现是资源组的网络域选错了。所以这一章不写操作步骤，只做核对；核对完再往下走，效率反而高得多。

2.1 三个版本号必须对齐：文档、产品、引擎

用户指南的页脚写着「文档版本：20200706」，封面写着「产品版本：V3.12.0」。这两个号是一组，缺一不可。很多人只看文件名里的 V3.12.0，忽略了文档日期，结果拿一份 V3.10 的旧手册对着 V3.12 的控制台点，菜单名称差一截，自然到处找不到入口。

表里最容易被忽略的是「工作空间模式」这一行。标准模式会给每个任务两套环境：开发环境里跑通了不算数，还得提交、发布到生产环境，调度才会真正按周期跑。简单模式只有一套环境，开发即生产，图省事的人喜欢选它，然后在一个误操作里把线上表覆盖掉。我一般建议：只要团队超过两个人，一律选标准模式，多出来的那一步发布动作，等于给你的数据留一条可回退的路径。

引擎版本这栏，用户指南里不会写死。它由专有云底座统一交付，你拿到的是什么版本就是什么版本。需要确认的点只有两个：引擎项目名是否已经创建、当前登录账号是不是该项目的 owner 或有授权。这两点没确认，工作空间建出来也是个空壳。

2.2 账号分层：主账号、子账号、工作空间角色是三回事

权限这块，翻车率比网络还高。原因很简单：DataWorks 的权限有三层，很多人只配了一层就以为完事。

第一层是云账号层。主账号负责开通服务、创建资源组、给子账号授权，日常开发不要用它登录。第二层是 RAM 子账号层，每个开发者一个，谁操作谁留痕，出问题能定位到人。第三层是工作空间内的角色，常见的是项目管理员、开发、运维、访客这几种，决定这个人能在工作空间里干什么。

# 排查权限问题时，先把「能不能进」和「进去能干什么」拆开验证 # 1) 主账号侧：确认子账号存在且未被禁用（在账号管理页面核对，不要凭记忆） # 2) 子账号侧：确认已加入目标工作空间，且角色不是「访客」 # 3) 数据源侧：确认单独授过权，工作空间角色不自动等于数据源权限 echo "三层权限逐层确认：账号 -> 工作空间角色 -> 数据源授权"

上面这段是思路，并非需要执行的命令，但排查顺序照着走最省时间。第三层最容易被跳过：把一个人加进工作空间、给了开发角色，他照样看不到某个 MySQL 数据源，因为数据源权限是单独管的，要单独授权。这个设计不是多余，是为了让「能进工作空间」和「能碰生产库」彻底分开。

我的习惯是给新同学先配开发角色，需要动生产的时候再单独提运维角色，并且数据源权限按库授权、不按实例授权。后悔药这东西，配权限的时候多花五分钟，出事的时候能省五天。

2.3 网络与客户端：连通性要在动手前证明

专有云环境基本都是内网闭环，控制台域名、引擎 Endpoint、数据源地址全在内网。开工前我在跳板机上跑一遍下面这段，把「解析」「端口」「证书」三件事一次确认完。

# 1) 控制台入口：区分是 DNS 问题还是网络问题 curl -sS -o /dev/null \ -w 'http_code=%{http_code} dns=%{time_namelookup}s connect=%{time_connect}s total=%{time_total}s\n' \ https://<控制台域名>/ # 2) 数据源端口探活：MaxCompute/控制台走 443，MySQL 3306，Oracle 1521 for hp in "<MySQL主机>:3306" "<Oracle主机>:1521" "<引擎Endpoint>:443"; do h=${hp%:*}; p=${hp#*:} nc -z -w 5 "$h" "$p" && echo "OK $hp" || echo "FAIL $hp" done

第一段里-o /dev/null是丢掉响应体，只看指标；time_namelookup是 DNS 解析耗时，time_connect是 TCP 握手耗时。如果dns快、connect卡住，问题在网络层，不在应用层；如果两个都很小但http_code是 502，那就是后端服务的事，跟你的客户端没关系。第二段的nc -z只探端口不通数据，-w 5是 5 秒超时，避免逐个卡死。

还有一件小事经常被忽略：客户端系统时间。控制台登录态是靠签名和时间戳校验的，机器时间偏差超过十几分钟，表现就是「密码明明对，登录一直失败」。装之前顺手校一次时，能省掉一轮毫无意义的密码重置。

3. 从登录到工作空间：控制台第一段可复现路径

前置核对做完，正式进入操作。这一段的目标很明确：登录进去、建出一个标准模式的工作空间、把成员和角色初始化好。三步都不复杂，但每一步都有一个「默认值陷阱」，默认选项不等于适合你的选项。

我习惯把这一段当成一次小型的交付验收：每做完一步，都留一个可以回看的证据——工作空间 ID、成员列表截图、数据源权限清单。后面出问题时，这些证据能帮你快速排除「是不是根本没配上」这种低级可能。

3.1 登录入口：域名、区域和浏览器侧的两个坑

登录地址来自专有云底座的控制台域名，并非公网那个通用入口。第一次拿到环境时，最稳妥的做法是找交付方要一份「入口清单」，包含控制台地址、引擎 Endpoint、对象存储地址，一次性收进自己的笔记里，别每次现问。

登录后第一件事是确认区域和集群。专有云里可能有多套集群，选错了集群，你会看到一片空白的工作空间列表，然后开始怀疑是不是权限没给。实际上只是站错了地方。

浏览器侧有两个反复出现的坑。一是缓存，控制台升级后旧 JS 还在本地，页面会出现「按钮点了没反应」的奇怪现象，无痕窗口一试就知道。二是自签证书，内网控制台常用自签证书，浏览器拦截后有些请求静默失败，页面显示不全。遇到「别人能看到我看不到」的情况，先换无痕窗口，再换浏览器，最后才怀疑权限。

# 登录前顺手确认本机时间和时区，避免签名类登录失败 timedatectl set-timezone Asia/Shanghai timedatectl status | grep -E 'Time zone|synchronized'

set-timezone把本机时区固定到 UTC+8，和后面工作空间的调度时区保持一致，省得看日志时来回心算八小时。synchronized那一行如果显示 no，说明时间同步没开，让运维把时间同步服务打开再登录。

3.2 创建工作空间：六个参数逐项过

工作空间是整个平台的组织单元，团队协作、任务开发、调度运行、权限管理全挂在它下面。创建时填的参数不多，但有几个建完就改不了，必须一次填对。

名称那一栏别图省事。工作空间名称会进入表的一级路径，比如引擎里的库名、同步任务的目标表前缀，一旦定下来再改，等于把所有下游依赖重写一遍。我一般用「业务线_环境_序号」的格式，短、可读、不会撞名。

模式这一栏前面说过，选标准模式。这里补一句原理：标准模式下，开发环境里的任务改动只影响开发库，提交并发布之后才进生产。这意味着你可以放心在开发环境反复试错，代价只是多一次发布动作。简单模式省掉这一步，也省掉了唯一的保护伞。

资源组这栏是真正的玄学所在，下一条细说。

3.3 成员与权限初始化：三种角色的最小授权

工作空间建好之后，第一件事不是建表，是加人。加人顺序建议是：先加项目管理员（一到两个，负责后续授权），再加开发者（按项目组批量加），运维角色只给真正需要发布上线的人。

# 成员初始化核对清单（逐项打勾，别凭记忆） # [ ] 每个成员都有独立的子账号，不存在共用账号 # [ ] 项目管理员不超过 2 人 # [ ] 开发角色不默认带发布权限（标准模式下发布单独受控） # [ ] 数据源权限单独授权，且按库授权而非按实例 # [ ] 离职/转岗人员的角色已回收，回收动作有记录 echo "成员初始化完成后再开始建表"

这份清单看着啰嗦，但每一条都对应过一次真实事故。共用账号是最典型的：出了误删，日志里全是同一个名字，根本定位不到人。开发角色默认带发布权限也很危险，标准模式的意义就在于把开发和发布切开，切不干净等于白选。

数据源权限那条我在下一章展开。这里只强调一句：工作空间角色和数据源权限是两套体系，别指望加进工作空间就能读所有库。

4. 数据源接入：连通性测试和三类典型数据源的参数取舍

数据集成是 DataWorks 里跑得最多、也最容易出问题的模块。用户指南里列了三十多种数据源，从 MySQL、SQL Server、PostgreSQL、Oracle 到 DM、DRDS、POLARDB，再到 MaxCompute、DataHub、OSS、HDFS、HBase、MongoDB、Redis、Elasticsearch、LogHub。类型多是好事，但配置界面上每个数据源要填的字段结构都不一样，照抄别人的配置基本都会失败。

这一章不去逐个过完那三十多种，只抓三类最有代表性的：关系型库（MySQL）、企业里常见的 Oracle、以及引擎侧的 MaxCompute。把这三类的参数逻辑搞明白，剩下的都是换汤不换药。

4.1 连通性测试先于一切：界面按钮只证明了一半

配置界面上有个「测试连通性」按钮，很多人把它当成最终验收。它证明的其实是：数据集成资源组所在的那台机器或那个网络域，能够用你填的账号密码连上目标库。它不证明你本地机器能连，也不证明调度跑起来之后还连得上。

真正的验证顺序应该是三层。第一层，跳板机上用nc探端口，证明网络可达。第二层，用原生命令行客户端登录，证明账号密码和库名没问题。第三层，才到界面上点那个测试连通性按钮。

# 第二层验证：用原生客户端确认账号与库名，比界面报错信息详细得多 mysql -h <MySQL主机> -P 3306 -u <用户名> -p -e "select 1" <库名> # Oracle 场景，thin 模式，注意 SID 和 ServiceName 的写法差异 # sqlplus <用户名>/<密码>@//<Oracle主机>:1521/<ServiceName>

mysql那行如果报Access denied，问题在账号或来源 IP 白名单；如果报Unknown database，库名写错了；如果一直挂着不动，网络层有防火墙。这三种报错在 DataWorks 界面上会统一显示成一句「连接失败」，信息量差得远，所以我习惯先在命令行里把错误逼出来。

Oracle 那行是注释掉的，因为不同环境装不装 sqlplus 不一定。要点在于连接串格式：@//host:port/ServiceName和@host:port:SID是两种写法，用错一个，界面上的报错永远不会告诉你原因。

4.2 三类典型数据源：参数怎么填、哪里会错

MySQL 那串参数里，useSSL=false是内网环境的常规做法，避免为了走 SSL 去配证书；serverTimezone=Asia/Shanghai是必填项，不填的话驱动会按 UTC 解释时间，写进去的数据整体差八小时，而且任务不报错，你只能靠对账发现；tinyInt1isBit=false解决的是另一个常见问题：MySQL 里tinyint(1)常被拿来当布尔用，驱动默认会把它读成 true/false，同步到目标端就变成了 1/0 或者直接类型不匹配。

Oracle 的坑集中在连接串。SID 是实例名，ServiceName 是服务名，两者在配置上完全不是一个写法，但界面上只有一个输入框。拿不准的时候，问一句 DBA 要 ServiceName，比自己在两种写法里试半天快。

MaxCompute 的参数看着简单，实际上最依赖前置确认：endpoint 必须是内网地址，project 必须是已经存在的引擎项目，AK 必须是该项目下有权限的账号。这三样缺一样，界面上表现都是「测试连通性失败」，但原因完全不同。

4.3 脚本模式：一份能直接改的同步作业 JSON

向导模式适合字段少的表，字段一多、要做列裁剪或过滤条件，就得切到脚本模式。脚本模式本质是一段 JSON，描述读端和写端各自的参数。下面这份是 MySQL 到 MaxCompute 的最小可用版本，把尖括号里的内容替换掉就能跑。

{ "type": "job", "version": "2.0", "steps": [ { "stepType": "mysql", "name": "reader", "category": "reader", "parameter": { "username": "<db_user>", "password": "<db_password>", "connection": [ { "jdbcUrl": ["jdbc:mysql://<mysql_host>:3306/<db>?useSSL=false&serverTimezone=Asia/Shanghai&tinyInt1isBit=false"], "querySql": ["select id, order_no, amount, updated_at from t_order where dt = '${bizdate}'"] } ] } }, { "stepType": "odps", "name": "writer", "category": "writer", "parameter": { "accessId": "<ak>", "accessKey": "<sk>", "project": "<odps_project>", "table": "ods_t_order", "partition": "dt=${bizdate}", "truncate": true, "odpsServer": "http://<odps_endpoint>/api" } } ], "setting": { "speed": { "channel": 3, "mbps": 5 }, "errorLimit": { "record": 0, "percentage": 0.0 } } }

steps数组里第一个是读端，stepType写mysql，category写reader；第二个是写端，stepType写odps，category写writer。这对组合决定了插件加载哪个实现，写错了会报「找不到插件」。

读端用querySql而不是table + column，好处是能做列裁剪和条件过滤，缺点是并发切分要靠splitPk自己指定，不带splitPk时整张表走单通道，大表会非常慢。上面这份为了可读性省掉了splitPk，实际跑大表要补上主键字段。

${bizdate}是调度参数，由系统在运行时按周期替换，常见格式是yyyymmdd。这里有个反复出现的坑：源表里的dt字段如果是yyyy-MM-dd格式，而${bizdate}出来是yyyymmdd，条件永远匹配不上，任务显示成功、数据一条没有。

写端的partition必须写，而且要写成dt=${bizdate}这种形式，否则往分区表写数据会直接报错。truncate: true表示写入前先清理对应分区，这个参数在重跑补数时很省事，但如果你把分区写成了常量（比如dt=20200706），每次重跑都往同一个分区灌，历史数据就没了。这就是我前面说的「默认值陷阱」——参数本身没错，错在填了个不会变的值。

setting.speed.channel是并发数，mbps是限速，errorLimit是脏数据容忍度。生产环境我一般把errorLimit.record设成 0，一条脏数据都不放过；临时导数据可以放宽到几十条，别设成百分比，小表上百分比几乎没有约束力。

5. 避坑与排查：装 DataWorks 最常见的五个翻车现场

下面五条是按出现频率排的，每一条都按「现象、原因、解决」写。这些坑有个共同点：报错信息都很含糊，有的甚至不报错，只能靠对账发现。

5.1 登录与权限：能进控制台不代表能干活

现象一：控制台能正常登录，点「创建工作空间」按钮是灰的，或者点了直接弹一个没有详细信息的错误。

原因：当前登录的是子账号，没有被授予工作空间管理相关权限；或者当前选中的区域/集群下没有任何可用资源组。

解决：先用主账号登录一次，确认同一位置按钮可用，把问题定位到权限而不是系统。然后给子账号补授权，注意授权范围要覆盖到目标区域。补完之后不要立刻重试，退出重新登录一次，让会话里的权限刷新，否则你会以为授权没生效又改一遍。

现象二：登录页输完密码，转两圈回到登录页，什么提示都没有。

原因：多半是客户端时间偏差太大，签名校验失败；少数情况是浏览器缓存了旧版前端资源。

解决：先timedatectl status看时间同步状态，再开一个无痕窗口试。两步都排除之后，才去查账号是否被锁定。这个顺序很重要，反过来的话你会花半小时重置一个根本没问题的密码。

5.2 数据源与网络：连通性失败有一半不是网络问题

现象三：数据源配置页面点测试连通性，转很久然后失败，报错只有一句连接超时。

原因：三种可能，网络不通、端口没放行、来源 IP 没进白名单。专有云里数据源通常有白名单机制，资源组的出口 IP 不在名单里，包会被丢掉，表现出来就是超时。

解决：跳板机nc -z -w 5 <host> <port>先确认端口，通了再用mysql命令行确认账号，最后去数据源侧加白名单。加白名单这步要拿到资源组的确切出口地址，别随手填个网段，填宽了是安全问题，填窄了下次换资源组又得重来。

现象四：测试连通性通过了，跑同步任务报认证失败或者表不存在。

原因：账号在该库上没有读权限，或者 JDBC URL 里的库名大小写和实际不一致（Linux 上库名区分大小写）。

解决：让 DBA 单独给这个账号授select，不要图省事给全库权限。库名不一致的情况，把 URL 里的库名复制过去，别手打。

5.3 调度与数据：任务成功但数据没到，最费时间

现象五：周期任务到点没跑，或者跑了但目标表空着。

原因：两种情况要分开看。没跑，多半是标准模式下开发环境提交了但没发布到生产，或者调度依赖没配导致上游没完成。跑了但没数据，多半是分区字段没写、写成了常量，或者${bizdate}的格式和源表字段格式对不上。

解决：先看运维中心的实例状态，是「未运行」还是「运行成功」，这一眼能省掉大量猜测。未运行就查发布记录和依赖关系；运行成功但没数据，就去查 SQL 里的分区条件和时间格式，用同一份 SQL 在源库手动跑一遍，看能不能出数。手动能出、调度不出，问题一定在参数替换上。

6. 装完怎么验证：三条自检加一个跑通的同步任务

装完不等于跑通。我判断一套 DataWorks 环境「可用」的标准只有一条：一个带调度的同步任务，能按周期把源库当天的数据搬到目标表，并且两边的行数对得上。围绕这条标准，验证分三步走。

第三步是最容易糊弄过去的。开发环境里点「运行」跑一次，看到成功就收工，这是不够的；标准模式下真正要验证的是「提交并发布之后，生产环境的周期实例能不能按时触发」。所以我把验证动作拆成两半：开发环境验证逻辑，生产环境验证调度。

对账这步用一段 SQL 就够，两边各跑一次，把结果贴在一起看：

-- 源端：MySQL，按调度参数对应的日期统计 select count(*) as src_cnt, max(updated_at) as src_max_updated from t_order where dt = '${bizdate}'; -- 目标端：MaxCompute，分区条件必须和写端 partition 配置一致 select count(*) as odps_cnt, max(updated_at) as odps_max_updated from odps_project.ods_t_order where dt = '${bizdate}';

两个count对不上，先别怀疑同步逻辑，去看dt条件是不是两边格式不一致——这是最常见的原因。行数对上了但max(updated_at)差八小时，回去检查 MySQL 的 JDBC URL 里有没有serverTimezone=Asia/Shanghai。这两个字段一起看，能覆盖掉八成「数据看起来不对」的情况。

还有一个习惯值得养成：验证时故意制造一次失败。把数据源密码改错一位，跑一次任务，看报错信息能不能定位到具体数据源；再改回来，跑通。这样做的好处是你提前知道了失败长什么样，真出事的时候不会把「密码错」误判成「网络不通」。这套动作我一般叫它「反向验收」，听着麻烦，实际五分钟。

从那以后，我每次交付一套新环境，都会强制走一遍这条链路：命令行探端口、原生客户端验账号、开发环境跑通、发布到生产、对账行数与时间字段、最后反向制造一次失败。六步走完才算验收结束，中间任何一步跳过，后面都会以另一种形式找回来。希望帮到你。

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