简介《阿里云专有云企业版 V3.12.0 DataWorks 用户指南20200706》是一份面向大数据开发、数据治理、平台运维及架构设计人员的官方产品文档可用于了解专有云环境下 DataWorks 的功能边界、操作流程与实施要点。资源包共 1 个 PDF 文件大小约 32.03MB内容按登录控制台、创建工作空间、快速入门、数据集成、数据开发、数据治理、数据服务与数据安全等模块组织并附法律声明和通用约定说明。已有 187 人学习或下载。读者可将其作为平台部署、日常运维和团队培训的案头参考借助目录快速定位建表上传、业务流程、同步任务、周期依赖、运行排错等主题也可据此梳理权限、资源配额、数据质量与脱敏审计等治理环节形成较完整的学习与实施路径。1. 一份 2020 年封版的 PDF现在还有人翻它查什么接手一套别人部署好的专有云大数据环境最难受的往往不是不会写 SQL而是界面上那个输入框到底该填什么。报错弹窗丢给你一串码内网搜不到工单排期三天最后翻遍资料才发现答案躺在一份 2020 年封版的 PDF 里——《DataWorks 用户指南》V3.12.0文档版本 20200706。它本质上是一份控制台操作手册登录 DataWorks 控制台、创建工作空间、快速入门六步、数据集成、二十多个数据源的配置项、二十二个 Reader 插件和二十六个 Writer 插件的参数清单。这份资料不负责教你大数据它负责回答“这个框怎么填、这个插件支持哪些参数、这条报错该去第几节查”。它适合两类人正在交付和运维专有云大数据平台的实施人员以及从公有云版本切过来、发现界面对不上的开发者。2. 从登录到工作空间专有云 DataWorks 的六个平面怎么切2.1 控制台入口与账号体系先确认你卡在哪一层专有云和公有云最大的差别在入口。公有云是统一域名加账号体系专有云是部署在机房里的独立一套集群控制台地址由部署方给通常是一个内网 VIP 或自定义域名账号则来自对接的统一身份系统或者平台自建。这意味着“打不开控制台”和“登录后看不到东西”是两件完全不同的事很多人把两者混在一起排查白耗半天。我一般按三层往下压网络层能不能通到控制台端口认证层账号是否有效、是否已被同步进来授权层账号在目标工作空间里有没有角色。第三层最容易被忽略——账号是好的密码是对的登录也成功了但工作空间列表是空的原因是没人把你加进任何一个空间的成员列表。反过来加进去了但角色是访客左侧的开发面板会一直是灰的看起来像功能缺失实际是权限没给到。层检查点典型表现网络控制台地址、端口、内网可达页面打不开、连接超时认证账号状态、密码策略、是否已同步登录失败、提示账号不存在授权是否为某工作空间成员、角色级别登录成功但空间列表为空、面板置灰提示登录成功但看不到开发面板优先查角色而不是查浏览器缓存。专有云里这类“看起来像 bug”的现象八成是权限。控制台登录之后先别急着建东西。把右上角的环境标识、当前集群、当前工作空间确认一遍再动手。我见过不止一次人在测试集群以为自己在生产改了一通配置才发现改错了地方。2.2 工作空间不是文件夹是资源配额和权限的边界工作空间在 DataWorks 里的定位是项目管理和协作的基础单元这句话听起来很虚落到专有云上其实非常具体一个工作空间绑定一个计算引擎项目、一组调度资源、一套成员和角色。创建的时候真正要填的只有几项但每一项都会在后面咬你一口。创建项含义填错后的后果空间名称与标识全局唯一标识后期改名困难脚本里的引用全部失效绑定计算引擎项目空间与底层计算资源的映射建表失败、SQL 节点无法执行调度资源组周期任务实际跑在哪个资源池任务一直处于等待状态成员与角色谁能开发、谁能运维、谁只读开发面板置灰或权限过大环境划分开发环境与生产环境测试任务直接写到生产表有一个坑值得单独说工作空间和底层计算项目是两层对象删除工作空间不等于删除底层项目底层项目里的表和数据还在配额也还占着。反过来底层项目被回收了工作空间还在但所有 SQL 节点都会报找不到项目。清理环境的时候两边都要看不能只看控制台列表。资源配额这块专有云比公有云更容易踩坑因为资源是物理上被划分好的。一个空间分到的计算配额和调度资源是固定的任务并发上不去很多时候不是参数没调好是资源组本身就这么大。遇到周期任务大面积延迟先看资源组使用率再去调任务优先级顺序反了就是白忙。2.3 快速入门的六步其实是一条最小可用闭环手册里的快速入门是六步入门概述、建表并上传数据、创建业务流程、创建同步任务、设置周期和依赖、运行及排错。新手照着点一遍能跑通但真正有价值的是这六步暴露出来的依赖关系——每一步失败都指向一个具体的基础设施问题而不是操作问题。第一步建表并上传数据卡住通常是计算引擎不可用或者当前角色没有建表权限。第二步创建业务流程卡住往往是调度资源组没绑或者绑错了。第三步创建同步任务卡住基本都在数据源连通性上这个放到下一章细说。第四步设置周期和依赖卡住多半是 cron 表达式写错或者上游节点没产出。第五步运行及排错卡住一般是不会看运维中心的实例状态把“等待”当成“失败”。步骤隐含依赖失败时先看什么建表并上传数据计算引擎可用、建表权限项目是否绑定、角色是否有 DDL 权限创建业务流程调度资源组已绑定资源组状态与剩余配额创建同步任务数据源连通、网络可达连通性测试结果与白名单设置周期和依赖调度周期语义、上游产出cron 表达式、上游实例状态运行及排错运维中心可访问实例日志而不是任务代码按这个顺序走一遍相当于给自己画了一张环境体检表。后面再遇到问题直接对照这张表定位比漫无目的翻文档快得多。3. 数据集成这条主线二十多个数据源与连通性测试的排查顺序3.1 数据源配置的五要素和一条固定排查链手册里从 MySQL 一路列到 LogHub二十多个数据源配置项看起来各不相同抽出来其实是同一组要素。把这五要素记住任何新数据源都能套。要素具体内容常见错误类型选对插件同名库可能有多个插件MySQL 与 RDBMS 混用连接串JDBC URL、主机、端口、库名端口写成 3306 之外的默认值凭证用户名、密码、权限范围用只读账号做写入同步网络所在网络、白名单、路由只放了机器 IP没放资源组网段附加参数编码、时区、SSL、连接池时区不一致导致时间字段偏移连通性测试失败是最常见的求助场景。我不建议一上来就改配置而是按固定顺序往下压先确认网络能不能通到目标端口再确认账号密码能登录然后确认账号对目标库有读或写权限最后才怀疑驱动版本和参数。这个顺序的好处是每一步都能证伪不会在中间来回打转。实际排查中网络层占的比例最高。专有云的数据源大多在内网DataWorks 侧的任务实际是从调度资源组发起的所以白名单要放的是资源组的出口地址不是你在浏览器里那台机器的地址。这个区别坑过不少人手动用客户端连得上测试连通性却一直失败原因就是两边出口不同。注意测试连通性通过不代表同步任务一定能跑通。测试只验证了连接真正跑起来还会受并发、权限范围、表结构影响。3.2 数据源隔离专有云多租户下最容易漏的一步数据源隔离解决的是“谁能看到哪个数据源”。在公有云单人项目里这个问题不明显到了专有云同一套集群上挂着多个业务方的项目一个没做隔离的数据源意味着 A 项目的人能在自己的界面上看到 B 项目的连接串和账号。手册里这一节篇幅不长但它属于那种“平时无所谓出事就是大事”的配置。配置逻辑一般是这样先定义数据源归属的项目再决定是否允许跨项目引用。如果业务上确实需要跨项目共享走授权而不是放开隔离。我一般会建议在环境初始化阶段就把这条规则定死后期再补成本要高得多因为已经有一批任务依赖了错误的引用方式改一个就可能带出一串。判断是否做对了有个简单办法用一个只有本项目角色的账号登录看数据源列表里是不是只有预期的那些。如果出现了别的项目的连接隔离就没生效。3.3 向导模式和脚本模式判断标准其实只有三条手册里作业配置分了向导模式和脚本模式两条路径很多人纠结选哪个。我的判断标准就三条源表有没有可用的切分键、要不要做限速、要不要自定义字段转换。三条里有任意一条为“是”直接上脚本模式别在向导里绕。维度向导模式脚本模式字段映射可视化勾选JSON 里手写 column切分键界面可选但受限自由指定 splitPk限速与并发界面提供基础项可精细控制 speed 各字段参数化支持有限支持调度参数、变量替换排错配置不可见出错难定位配置即文本可对比可版本化向导模式的优势是快适合字段少、结构简单、一次性的同步。脚本模式的优势是可复现配置本身就是一份可以进版本库的文本出问题能 diff。我在生产环境基本只用脚本模式原因不是它更强而是它留得下证据——半年后有人问这条链路当时怎么配的答案还在文件里。3.4 二十二个 Reader 和二十六个 Writer选错插件比配错参数更常见插件数量多最容易出的不是参数填错而是插件选错。手册目录里几个典型的分叉点值得记一下。场景可选插件选择依据关系型库通用读写MySQL/Oracle/SQL Server 专用插件 与 RDBMS 插件专用插件参数更全RDBMS 用于快速接一批同构库HBase 读写HBase 插件 与 HBase11xsql 插件走原生 API 还是走 SQL 层Table StoreOTS 插件、OTSReader-Internal、OTSStream全量读、内部读、增量流读三种语义日志类LogHub Reader、LogHub Writer注意消费组与起始位点语义文件类OSS、HDFS、FTP注意分隔符、编码、压缩格式插件选错的典型症状是“配置全对但结果不对”字段数对得上数据能进去就是某些列的值串了位。这种情况八成是分隔符或者转义规则没对上而不是映射写错。遇到先怀疑插件和格式再怀疑字段顺序。4. 同步作业参数怎么设并发、限流、脏数据的四组取值4.1 一份脚本模式作业的骨架长什么样脚本模式的配置本质是一段 JSON结构固定最外层是 job里面是 configuration再往下分 setting、reader、writer 三块。看一个从关系型库同步到计算引擎的典型例子。{ type: job, version: 1.0, configuration: { setting: { speed: { concurrent: 4 }, errorLimit: { record: 0 } }, reader: { plugin: mysql, parameter: { username: sync_ro, password: ${mysqlPassword}, column: [id, order_no, amount, created_at], splitPk: id, connection: [ { table: [t_order], jdbcUrl: [jdbc:mysql://10.0.0.11:3306/sales] } ] } }, writer: { plugin: odps, parameter: { table: ods_t_order, project: dw_prod, partition: dt${bizdate}, truncate: true, column: [id, order_no, amount, created_at], accessId: ${accessId}, accessKey: ${accessKey} } } } }这段配置里几个地方值得单独说。setting.speed.concurrent控制并发数它决定了任务会被切成几份同时跑。setting.errorLimit.record是脏数据容忍条数写 0 表示一条脏数据都不允许遇到就失败。reader.parameter.splitPk是切分键没有它并发就切不开配了并发也只能单线程跑——这是最容易被忽略的一处很多人把 concurrent 调到 16实际吞吐没变就是因为 splitPk 没填或者填了一个分布极不均匀的字段。writer.parameter.partition里的${bizdate}是调度参数运行时会替换成具体日期。truncate决定写入前是否清空目标分区全量覆盖场景要开增量追加场景必须关否则每次调度都把历史数据洗掉。凭证类的字段不要写明文用变量替换配置进版本库时才不会把密码一起带出去。4.2 并发和限流两个旋钮不要同时拧到底speed下面通常有两个可调项concurrent并发数和bytes每秒字节数上限。这两个是两种不同的控制手段前者提高吞吐后者压制吞吐同时用会互相打架。经验做法是二选一源库压力可控时用并发源库是共享的核心库时用限流。并发数不是越大越好。每提高一档并发源库上就多一条连接、多一份查询压力目标端也多一份写入批次。我一般的取值逻辑是小表百万行以内给 2 到 4中等表给 4 到 8大表给 8 到 16并且必须确认 splitPk 是高基数列。超过 16 的情况很少见收益递减明显反而容易把源库拖慢引发业务侧投诉。场景concurrentspeed.bytes说明小表、低频2不设稳定优先常规业务表4 到 8不设需 splitPk 支持核心共享库2按带宽设上限保护源库大表初始化8 到 16不设配合高基数列切分目标端写入受限不限按目标端能力设防止压垮写入侧有一个反直觉的点并发调高之后任务反而更慢通常是切分不均导致的。比如 splitPk 选了一个只有三四种取值的状态字段16 个并发里 13 个分到空数据实际干活的最多三四份还多了一堆调度开销。切分键要选分布均匀的数值型或时间型主键不要选枚举字段。4.3 脏数据什么时候该让任务失败什么时候该放过去errorLimit有两个维度按条数record和按比例percentage。手册里对这个参数的描述比较克制实际用起来需要自己定策略。我的分法是按数据性质走。ODS 层的原始数据同步我倾向于从严record设 0 或者很小的值因为脏数据意味着上游有问题放过去就是把污染带到下游后面清洗成本更高。DWD 层的加工任务可以适度放宽允许少量记录被过滤并记录下来避免个别异常行卡住整条链路。脏数据被过滤之后去哪儿了这个也要提前确认。一般会落到专门的脏数据表或者日志里需要有人定期看。如果没人看放宽 errorLimit 就等于把问题藏起来几周之后下游指标对不上回头查才发现源头早就开始丢数据了。注意把 errorLimit 调大从来不是解决方案只是把失败的时机往后推。真正的处理是有人盯脏数据。4.4 整库迁移适合一次性搬迁不适合长期同步手册里整库迁移覆盖了 MySQL 和 Oracle 两条路径逻辑是扫描源库的表结构批量生成同步任务一次性把一批表搬过去。这个功能在项目初始化阶段非常好用几十上百张表不用一张张配。但它的适用边界很清楚。表数量多、结构简单、没有复杂对象存储过程、触发器、外键约束的场景整库迁移能省下大量重复劳动。反过来源库有大量自定义类型、有跨库依赖、有需要人工映射的特殊字段整库迁移生成的配置就得逐个返工省下的时间又还回去了。判断项适合整库迁移建议手工配置表数量几十张以上个位数表结构常规字段类型自定义类型、大对象库内对象只有表含存储过程、触发器、外键同步频率一次性搬迁持续增量同步命名规范源目标一致需要大量重命名一次性搬迁完成之后增量部分建议还是手写脚本模式任务。整库迁移生成的任务在参数层面比较通用针对单表做性能优化时改动空间小长期跑起来不如手工配的顺手。5. 避坑记录五个能把同步任务卡死的现场5.1 连通性测试过了任务跑起来超时现象数据源页面点测试连通性绿的提示成功。提交同步任务运行几分钟后失败日志里是连接超时。原因测试连通性用的是控制台侧发起的探测实际任务是从调度资源组发起的两者出口不同。控制台能通不代表资源组能通到目标库。解决把资源组所在网段加到目标库白名单再用一个最小任务验证不要只信测试按钮。这个顺序调过来之后这类问题基本绝迹。5.2 周期实例一直显示等待以为资源不够其实是依赖没满足现象任务到点了不跑实例状态一直是等待运维中心里看不出明显报错。原因等待状态有两种含义一种是等资源一种是等上游。多数人第一反应是资源不足去扩资源组扩完还是不跑。解决先看实例的依赖树确认上游实例是否已经成功产出。上游没跑完下游永远等。确认依赖没问题之后再看资源组使用率。顺序反了就是白折腾。5.3 整库迁移跑完了对表发现少了几张现象迁移任务显示成功核对源库和目标库的表数量少了若干张。原因整库迁移默认按规则筛选表不符合命名规范或者没有主键的表可能被跳过界面上不一定有明显提示。解决迁移前先导出源库表清单迁移后用清单做一次差集比对把漏掉的表挑出来手工补。不要用“任务成功”当迁移完成的判据。5.4 改了字段名任务不报错但数据错位现象源表加了一个字段同步任务没改跑完发现目标表某几列的值整体右移了一位。原因脚本模式的 column 是按位置映射的不是按名字匹配。源端字段顺序变了配置里没同步调整就会错位而且不会报错因为类型可能恰好兼容。解决同步配置里的 column 显式写全字段名并且和源表结构纳入同一个变更流程。源端改表结构同步配置必须同步改。这类错误最难查因为数据是“有”的只是错的。5.5 成员加进工作空间了开发面板还是灰的现象账号已在成员列表里登录后左侧开发相关入口不可点。原因角色给的是运维或者访客级别这类角色本身不带开发权限。成员列表里有名字不等于有开发角色。解决确认角色定义需要开发的给开发角色需要发布的确认是否有发布权限。专有云里角色体系往往和统一身份系统做了映射改动可能要两边同步别只改一边就以为生效了。6. 把这份 PDF 用成查询手册三条检索路径和一次版本比对这份文档七百多页从头读是不现实的。我自己的用法是三条路径按命中率排序。第一条是按插件名直查目录。Reader 和 Writer 插件在目录里是平铺的编号连续找到插件名就等于找到了参数清单。比如要确认某个 Writer 支持哪些写入模式直接跳到对应小节比在搜索框里搜中文描述准确得多因为正文里的中文表述和你想的关键词经常对不上。第二条是搜英文参数名不搜中文。像 splitPk、errorLimit、concurrent 这些词在文档里是原样出现的搜中文“切分键”“脏数据”反而可能漏。遇到报错信息先把报错里的英文标识提出来再搜。第三条是看警示级别。文档开头定义了四级标记禁止、警告、注意、说明。禁止和警告对应的段落是真正会出事的地方注意和说明是补充。时间紧的时候只扫禁止和警告能避开大部分致命操作。这个习惯我从看第一份手册就养成了后来发现它比通读有效得多。最后说版本比对。手里这份是 V3.12.0、文档版本 20200706如果实际环境不是这个版本别 assumption 一致。我一般只比三处插件清单有没有增减、关键参数有没有改名、控制台入口位置有没有变。这三处对上了其余细节差异通常不影响操作对不上就以实际界面为准文档当参考。比对项怎么比不一致时的处理插件清单对照数据集成里的可选插件列表以界面为准缺的插件找部署方确认关键参数抽查 splitPk、errorLimit、speed参数改名时以界面提示为准控制台入口对照工作空间与数据开发菜单层级按实际路径记录别照抄文档路径警示级别段落扫禁止与警告两类这类操作一律先在测试环境验证血泪经验是这么来的早些年我照着文档路径去找一个配置项找了半小时没找到最后发现那个版本把它挪到了另一个菜单下文档没错只是版本不同。从那以后我每次拿到新环境的文档都先做一次这三项比对再开始干活宁可前期多花二十分钟也不想在后面反复怀疑自己点错了地方。希望帮到你。本文还有配套的精品资源点击获取