企业官网建设流程全解析

简介：SAP Data Services 连接 MySQL 的配置指南，面向数据集成、ETL 开发与运维人员，解决 SAP Data Services 与 MySQL 数据源对接时的驱动配置、连接测试和元数据导入等实际问题。资源为 1 份 docx 文档，压缩包约 1.43 MB，已有 1622 人学习下载。文档以图文形式按步骤演示：先在 Data Services 主界面 data store 标签中新建存储，选择 MySQL 数据库类型，再通过 ODBC 管理工具添加驱动、填写服务器、用户名、密码并执行连通性测试；连接成功后，继续展示如何双击 tables 查看已有表、批量选中表并导入元数据，以及如何查看表的设计信息和通过 View data 预览数据内容。除了完整操作流，还特别提示了 MySQL 服务需提前启动、版本兼容性判断、账号安全防护和备份恢复策略等常见注意事项，帮助使用者规避连库失败、数据丢失等风险。整体内容结构清晰，既适合实施 SAP DS 数据接入项目的团队对照操作，也适合刚接触 SAP Data Services 的开发人员作为快速上手手册。

1. 为什么 DS 连 MySQL 总在 ODBC 这层翻车

SAP Data Services 连 MySQL，步骤看着就那几步：右下角切到 datastore 标签页，右键新建，数据库类型选 MySQL，填上服务器、用户名、密码，点 OK。可实际环境里一次点通的不到三分之一。最常见的是连接报 driver not found 或 cannot connect to the database server，排查半天发现不是密码错，而是 ODBC 驱动根本没对上号。

根源在于 Data Services 连接 MySQL 不像连 SQL Server 那样走原生协议，而是要经过本机 ODBC 驱动中转。ODBC 这一层一乱，后面全是坑：32 位驱动和 64 位驱动互相看不见、DSN 建错层级导致 Job Server 找不到数据源、导入表结构时中文变成乱码、表清单空得让人怀疑连错了库。

下面按「驱动选型 → ODBC 数据源配置 → Data Services 建 datastore → 导入元数据 → 验证排错」的完整链路走一遍，中间每一处参数都给到能直接抄的值。正在做 MySQL 数据接入、数仓迁移的开发者，照着这个顺序搭，基本能一次跑通，不用在同一个坑里蹲两次。

2. 装前准备：版本边界、驱动选型与环境检查

2.1 先确认 DS 版本对 MySQL 的支持边界

SAP Data Services 从常见的 4.2 版本到后面的 4.3，对 MySQL 的连接方式其实一直没变过：支持，但必须走 ODBC。这和连 SQL Server、Oracle 不一样，那两类数据库有原生的数据库接口，而 MySQL 在官方支持矩阵里写得很明确，是「通过 MySQL 官方 ODBC 驱动接入」。所以动手前第一件事不是打开 Designer 点新建，而是把两边版本弄清楚。

我一般先看 DS 的版本号，Designer 里 Help → About 能找到，安装目录下的版本文件里也有。然后对照支持矩阵确认这个 DS 版本能接受的 MySQL 大版本范围。实际部署经验里，DS 4.2 搭配 MySQL 5.6、5.7 是很常见的组合，DS 4.3 之后对 MySQL 8.0 的支持才趋于完整。如果手里是 DS 4.2 硬要连 MySQL 8.0，不是完全不能连，但握手阶段容易出问题，后面避坑章节会专门讲。

提示：支持矩阵告诉你的只是「这个版本能连」，真正决定连不连得通的，是驱动位数和驱动版本。这两个变量比 DS 版本本身更关键，别把排查时间都花在版本对照上。

2.2 选驱动：ANSI 还是 Unicode，32 位还是 64 位

MySQL 官方 ODBC 驱动叫 MySQL Connector/ODBC，常见两个大版本：老的 5.3 系列和新一些的 8.0 系列。每个版本又分 ANSI Driver 和 Unicode Driver 两个变体。我的建议很直接：新环境一律用 8.0 的 Unicode Driver。

理由有两条。第一，MySQL 8.0 默认认证插件是 caching_sha2_password，老驱动握手时会报 unsupported authentication plugin，换成 8.0 驱动通常就过了。第二，Unicode 驱动对 utf8mb4 字符集的支持更稳，导入表结构时表名、字段名、注释里的中文不容易乱。ANSI 驱动不是不能用，但每次遇到中文乱码问题，八成最后都查到 ANSI 变体头上，没必要给自己留这个隐患。

位数问题更隐蔽。Data Services 的 Designer 客户端在很多部署里是 32 位进程，哪怕操作系统是 64 位 Windows。ODBC 驱动和调用它的进程位数必须一致：DS 是 32 位，就得装 32 位驱动，并且用 32 位的 ODBC 管理器建 DSN。这一点是 DS 连 MySQL 翻车率最高的位置，没有之一。装驱动时看清安装包是 x86 还是 x64，别装完才拍大腿。

2.3 动手前的环境检查清单

以下清单是每次建连接前我都会过一遍的，任何一项不过都不往下走，省得后面排查时在几层原因之间来回猜：

这块看起来琐碎，但能省掉后面大部分拆弹时间。尤其是「驱动位数」和「ODBC 管理器位数」这两项，很多人以为驱动装完就完事，结果在管理器里找不到驱动，又怀疑安装过程坏了，折腾一圈才发现是位数没配对。这两项的验证命令和路径，下一章写具体操作。

还有一个安全习惯顺便说：给 DS 建一个专用账号，不要拿 root 去连。账号按最小权限授，后面 ODBC 和 datastore 里的密码都集中在这一处维护，改密时只动一个地方，风险可控。备份和恢复策略属于部署侧的事，这里不展开，但账号权限收敛是连接配置里就该做好的部分。

版本边界再补一句：支持矩阵查到的「支持」，往往指某个 DS 版本配合特定驱动能建立会话，不代表元数据导入、批量抽取这些功能一定顺畅。我在 DS 4.2 上连 MySQL 5.7 遇到过元数据能导、但跑 data flow 时类型映射异常的情况，最后是升级驱动小版本解决的。所以版本判断口诀是：DS 版本管「能不能」，驱动版本管「稳不稳」，位数统一管「找不找得到」。三者分开记，排查时才有思路。

3. 配置 MySQL ODBC 数据源：odbcad32 里先跑通

这一章只做一件事：在操作系统层面把 MySQL 连接封装成一个命名的 DSN，也就是数据源名称。Data Services 里的 datastore 连 MySQL 时，本质是拿着你给的名字去 ODBC 管理器里找对应的数据源。顺序上必须先做这步再开 Designer，顺序反了会一直处于「DS 里觉得什么都配好了、一测就报错」的状态。

3.1 打开正确的 ODBC 管理器

Windows 上有两个 ODBC 管理器，同名都叫「ODBC 数据源管理器」，但一个管 32 位驱动，一个管 64 位驱动。64 位系统上从开始菜单搜「ODBC」出来的那个通常是 64 位版本，如果你装的是 32 位驱动，在里面什么都看不到。正确的打开方式是直接运行：

C:\Windows\SysWOW64\odbcad32.exe

用 32 位管理器打开后，切到「驱动程序」页签，应该能在列表里看到 MySQL ODBC 8.0 Unicode Driver 之类的条目。如果看不到，说明驱动没装或者装成了 64 位，回去把驱动卸了重装 32 位版本，不要继续往下走。

注意：System32 目录下的 odbcad32.exe 反而是 64 位管理器，SysWOW64 目录下的才是 32 位管理器。这个方向非常容易记反，我第一次配的时候就是在 System32 里找了半天驱动，怎么看怎么不对劲。

3.2 新建系统 DSN 并填写连接参数

在 32 位 ODBC 管理器的「系统 DSN」页签下，点「添加」，选择刚才确认过的 MySQL 驱动，进入参数填写界面。注意这里要选的是系统 DSN，不是用户 DSN，原因值得说清楚：Data Services 的 Job Server 是作为 Windows 服务运行的，服务运行账户下通常看不到登录用户自己的 DSN，把数据源建在系统级，所有账户包括服务账户才能共用。

只建用户 DSN 的话，Designer 里手动测试可能一切正常，一部署 job 开跑就报数据源找不到。这是经典的「开发环境正常、生产环境炸」的坑，我在第五章的避坑记录里还会再提一次。

参数填写参考这张表：

DSN 名称我习惯用全大写加下划线，比如 DS_MYSQL。这个名字在 Data Services 里要一字不差地引用，如果后面改了 DSN 名称，之前建好的 datastore 会全部失效，需要逐个重指，所以起名时一次定好，别用带空格或中文的名字给自己找麻烦。

填完先不要点 OK，做一步验证：点界面下方的 Test 按钮。测试通过会弹出 Connection successful 的提示，到这一步 ODBC 层就算跑通了，再点 OK 保存。如果 Test 直接失败，先别急着改参数，往下看。

3.3 Test 连接：命令行先测，ODBC 再测

ODBC 界面的 Test 是最直观的验证方式，但我习惯在点它之前先用命令行把 MySQL 侧的可能性排除掉，否则 Test 报错时分不清是账号问题还是网络问题：

mysql -h 192.168.1.10 -P 3306 -u ds_user -p

这个命令能成功登录，说明三件事：MySQL 服务在监听、账号密码正确、远程访问权限放开了。如果命令行都连不上，ODBC 那边必然报错，先回去处理 MySQL 侧的授权。给 DS 用的账号授最小权限，常见语句是这样：

CREATE USER 'ds_user'@'%' IDENTIFIED BY 'SmartPwd2024'; GRANT SELECT, SHOW VIEW ON ds_db.* TO 'ds_user'@'%'; FLUSH PRIVILEGES;

这里授的是 SELECT 和 SHOW VIEW，正好覆盖元数据导入和读数的需求。如果后续要让 DS 往 MySQL 里写目标表，再按需补 INSERT、UPDATE、DELETE，不要图省事直接给 ALL。host 段按应用服务器所在网段收紧会更好，% 是最省事的写法，适合内网环境。

命令行测通过后，回到 ODBC 界面点 Test。如果这时还报错，优先看错误文本里的关键信息：Access denied for user 多半是授权 host 段不对，Unknown database 是 Database 字段填错，authentication plugin 相关的报错是驱动版本太老。这几个高频报错第五章统一放排查记录，这里先把 DSN 建好，继续往 Data Services 里走。

4. 在 Data Services 里创建 MySQL Data Store

ODBC 数据源就绪后，回到 SAP Business Objects Data Services 这一侧。前面所有功夫都是铺垫，这里开始才是输入素材里那套操作的主场：新建 datastore、选 MySQL 类型、填连接信息、导入表元数据。

4.1 进入 datastore 标签页并新建连接

打开 Data Services Designer，输入 repository 的用户名密码完成登录。主界面是多个标签页布局，右下角能找到 datastore 标签页，这就是管理数据源的地方。在标签页的空白处右键，选择新建，或者走菜单栏 File → New → Datastore，入口是同一个。

提示：如果右键菜单里新建 datastore 是灰色的，先检查是否连上了 repository。Designer 必须处于已登录状态才能建 datastore，未连接 repository 的本地离线模式下建不了。

新建窗口弹出后，会看到一堆字段。很多新手栽在这里：看着字段多就随便填，结果点 OK 报错，或者建完连不上。其实真正关键的字段就那么几个，下面逐个说。

4.2 MySQL Data Store 的参数说明

新建 datastore 的参数窗口里，有几项必须填对，缺一个都可能在点 OK 后报错：

「Database type 选 MySQL 而不是 Generic ODBC」这个细节值得多说。选 MySQL 时，Data Services 会按 MySQL 的元数据规则去读 information_schema，数据类型映射走内置的 MySQL 映射表；选 Generic ODBC 虽然也能建立连接，但元数据读取走通用规则，导入表结构时容易把字段类型识别错，后面在 data flow 里做类型转换会莫名多出一堆问题。宁可多花十秒找到 MySQL 选项，也不要图省事选通用项。

连接信息这一栏，我倾向于直接填之前建好的 DSN 名，而不是把服务器、库名、账号密码在 datastore 里再填一遍。填 DSN 名的好处是连接参数只维护一份：改密码时只要改 ODBC 数据源，不用回 Designer 里逐个 datastore 改。坏处是多一层依赖，跑 job 的机器上必须有同名 DSN。对 DS 这种经常配多台服务器的架构来说，DSN 集中维护是更省事的选择。

4.3 创建 datastore 并导入表元数据

参数填完点 OK，datastore 创建完成。这时它在 datastore 标签页下显示为一个节点，双击展开能看到一个 tables 子节点。双击 tables，右侧会列出 MySQL 数据库里已有的表。注意这里列出来的是 MySQL 侧实时读到的表清单，不是 Data Services 本地的。

下一步是导入元数据：在右侧列表里选中所有要用的表，右键选择 import。这个动作会把每张表的表结构、字段名、数据类型、主外键信息读进 Data Services 的 repository，存成一份元数据。import 完成之后，datastore 节点下的 tables 里能看到已导入的表，并带有已导入标识。

导入元数据这步经常被跳过，但它的必要性在于：后续创建 data flow、做字段映射时，Data Services 依赖的是这份本地元数据，而不是每次实时连数据库。只建 datastore 不 import，表在 job 里就是不可选状态。所以确认连接能通之后的第一件事，就是把目标表全部 import 进来，省得后面建 job 时发现某张表没导，又回头补。

导入完成后，挑一张表做完整性检查。双击 datastore 下面的 dimcustomer 表，右侧打开表设计视图，能看到字段清单、类型、长度这些结构信息。然后在这一行右键选择 View data，就能看到这张表里的真实数据内容。

到这一步，Data Services 到 MySQL 的整条链路算是真正打通了：连接能建、表能列、结构能导、数据能看。接下来就是把踩过的坑记下来，给后面遇到同类问题的同学留个路标。

5. 避坑记录：四个现场与对应修复

这一章放实际处理过的几个现场，每条按「现象 → 原因 → 解决」来写，遇到同类问题可以直接按方抓药。DS 连 MySQL 的坑大多集中在 ODBC 层，这四类加起来覆盖了绝大多数报错场景。

5.1 驱动装了却在 ODBC 管理器里看不到

现象：装了 MySQL Connector/ODBC，安装过程没有任何报错，但打开 ODBC 数据源管理器，「驱动程序」列表里找不到 MySQL 相关条目，自然也没法新建 DSN。

原因：装的是 64 位驱动，而 Data Services 的 Designer 是 32 位进程，用的 ODBC 管理器也是 32 位版本的，两边的驱动程序列表互不相通。这个组合在 64 位 Windows 上非常容易发生，因为默认下载的安装包往往就是 64 位。

解决：卸载已装的驱动，重新下载 32 位版本安装，安装时留意安装包名称里的 x86 标识。装完用C:\Windows\SysWOW64\odbcad32.exe打开 32 位管理器验证。判断 DS 客户端位数的方法：看 Designer 安装目录下主程序路径带 x86 还是 x64，或者直接看任务管理器里进程是否带 32 位标记。

5.2 Test 报 Access denied 或 authentication plugin 错误

现象：ODBC 参数填完点 Test，报 Access denied for user，或者提示 Authentication plugin 'caching_sha2_password' cannot be loaded。

原因：账号密码本身没错，但 MySQL 8.0 默认建的用户用的是 caching_sha2_password 认证插件，老版本的 ODBC 驱动不支持这种握手方式；Access denied 那条通常是账号的 host 段限定太严，比如只允许 localhost 登录，远程连接时直接被拒了。

解决：驱动升级到 8.0 系列是对付插件报错最直接的办法。同时把账号 host 放宽到应用服务器所在网段，或直接用 %。如果不方便换驱动，可以在 MySQL 侧把账号改回兼容插件：

ALTER USER 'ds_user'@'%' IDENTIFIED WITH mysql_native_password BY 'SmartPwd2024'; FLUSH PRIVILEGES;

这条语句的作用是把指定账号的认证方式改为 MySQL 老版本的 native password 模式，让旧驱动也能完成握手。注意它会覆盖账号原来的密码为语句里写的值，执行前先确认这个密码就是打算给 DS 用的那个。

5.3 tables 下看不到表，import 报 Table not found

现象：datastore 能建，连接测试也成功，但双击 tables 右侧列表是空的；强行 import 会报 Table not found 或 Unknown database。

原因：大概率是 DSN 里 Database 字段没填，或者账号权限只覆盖了部分库，而 DS 默认去读的库和实际数据不在同一个库。DS 读表清单走的是 information_schema，如果账号没有对应库的权限，information_schema 里查不到记录，列表自然为空。

解决：回到 ODBC DSN 配置里把 Database 字段填成目标库名。同时确认账号授权范围：

SHOW GRANTS FOR 'ds_user'@'%'; GRANT SELECT, SHOW VIEW ON ds_db.* TO 'ds_user'@'%';

改完 DSN 后，记住在 Designer 里把 datastore 删掉重建，或者重新连接一次。ODBC DSN 的修改不会热更新到已创建的 datastore 上，你在 DSN 里填了新库名，旧 datastore 还抱着之前读到的那份信息不放，删掉重建是最省事的办法。

5.4 Designer 能连，Job Server 跑 job 却报找不到 DSN

现象：Designer 里测试连接、建 datastore、导入元数据都正常，但把 job 部署到 Job Server 执行时报数据源找不到，或者提示 ODBC 驱动不存在。

原因：Designer 手动测试走的是你当前登录账户的会话，能读到用户级 DSN；Job Server 作为 Windows 服务运行，运行账户通常不是你的登录账户，它看不到用户 DSN，只能看到系统 DSN。这个问题隐蔽在：开发阶段一切正常，一到调度执行就翻车，而且报错信息不直接说 DSN 权限，只说数据源找不到，很容易让人误判成网络问题。

解决：把 ODBC 数据源建在「系统 DSN」层级，不要建在「用户 DSN」层级，这是根治办法。同时确认 Job Server 服务账户对驱动有读取权限，以及装驱动的机器就是跑 job 的机器。DS 架构里 Designer 和 Job Server 往往不在同一台机器上，DSN 要建在 Job Server 那台机器上，不是建在你自己电脑上就行。

5.5 导入后表结构中文全部乱码

现象：import 之后，表注释、字段注释里的中文显示成问号或方框，View data 里中文字段值也是乱码。

原因：ODBC 驱动用了 ANSI 变体，连接字符集没有显式指定，MySQL 侧连接默认字符集和 DS 侧解析字符集不一致。常见于 MySQL 5.6/5.7 配 ANSI 驱动的老环境。

解决：DSN 建立时选择 Unicode Driver，并在连接参数里显式指定字符集。ODBC 的连接参数可以通过连接串精确控制，在 DSN 配置界面的附加参数或连接串里加上CHARSET=utf8mb4，前提是 MySQL 侧库表本身也是 utf8mb4。改完重新测试连接，再回到 Designer 里把之前导入的错误元数据删掉，重新 import 一次。

注意：已经导入的错误元数据不会因为 DSN 改了字符集就自动变好，务必要删掉重导。只改 DSN 不重导，你会以为没生效，其实元数据是旧的那份。

6. 验证跑通：datastore 与 View data 的一分钟检查法

6.1 快速检查清单

装完环境后，我每次都会把下面这条链路完整走一遍，任何一步不通就回去查对应环节。这套动作一分钟内能跑完，但每一步都在验证一个不同的层面，哪一步断了，问题就锁定在哪一层：

1. 双击 datastore 节点，能展开、不报错，验证连接会话正常。
2. 双击 tables，左侧列出目标库里的表，验证 DSN 的库选择正确。
3. 右键 import，确认所有表都变成已导入状态，验证元数据读取权限正常。
4. 双击 dimcustomer 表，设计视图里字段名、类型和 MySQL 侧一致，验证类型映射正确。
5. 右键 View data，弹出的数据预览和 MySQL 查询结果一致，验证数据链路和字符集。

前两步查连接，第三步查权限和元数据读取，第四步查类型映射，第五步查数据和字符集。这一套走下来，ODBC 驱动、DSN、DS 三层配置基本没有漏网之鱼。如果哪一步卡住，按第五章的对应条目处理，不要从头胡乱试。

6.2 用 View data 做最后的字符集确认

View data 是最容易被忽略、但最有价值的一步验证。它直接走 ODBC 把数据拉到 Designer 的数据预览窗口，中文字段如果在这里显示正常，基本可以认定驱动、DSN、DS 三层的字符集都对齐了；如果这里乱码，跑出来的 job 结果大概率也是乱的，早发现在这一步，能省掉后面整条数据流的返工。

还可以顺手做一个交叉验证：在 MySQL 命令行里查同一张表：

SELECT * FROM ds_db.dimcustomer LIMIT 10;

拿命令行结果和 Designer 的 View data 窗口对比，两张画面数据一致、中文一致，这条链路就算真正打通过了。数据一致性的验证没有捷径，眼睛扫一遍虽然原始，但比任何日志都可靠。

从那以后，我每次给 Data Services 接新的 MySQL 环境，都会强制走一遍「驱动位数 → Test → import → View data」的闭环，任何一环跳过，后面建 job 时都会以更难看的方式还回来。DS 连 MySQL 的坑九成集中在 ODBC 那一层，把这层跑透，后面的数据流就顺了。希望帮到你。

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