页面历史

...

4.2 源库与目标库“大小写规则不一致”的迁移

背景：

某银行计划将原有 Impala 数据库替换为 StarRocks 数据库，需迁移表和数据。但 StarRocks 要求表名、字段名必须为全小写，不支持大小写混合（例如 Impala 中表名 “OrderInfo” 在 StarRocks 中需改为 “orderinfo”）。

问题影响：
Smartbi 中表和字段的 “身份 ID”（即系统识别的唯一标识）是根据数据库实际名称生成的。若迁移后表名 / 字段名变更（如从 “OrderInfo” 变为 “orderinfo”），Smartbi 中基于旧库创建的报表、数据集、数据模型等上层资源，会因找不到对应的 “旧 ID” 而报错（例如提示 “表不存在”“字段匹配失败”）。

解决方案：

...

1. 统一命名规范：

...

1. 在数据迁移前，将 Impala 数据库中的表名、字段名统一修改为全小写（如 “OrderInfo”→“orderinfo”，“CreateTime”→“createtime”），确保与 StarRocks 的命名规则一致。

...

2. ID 规则自动映射（兼容旧资源）：使用 ID 规则强制转换（如 LOWER_CATALOG规则将表ID转为小写）,详细可查看：业务库迁移之后ID替换操作。

4.3 源库与目标库"Catalog 、Schema 不一致"的迁移

背景：

在企业数字化转型中，数据库迁移常面临跨类型数据库架构差异与版本升级适配两大核心挑战：

1. 跨数据库类型的天然差异：当从无 Catalog/Schema 的数据库（如旧版 MySQL）迁移至有层级结构的数据库（如 PostgreSQL）时，表的定位路径（如 “Schema. 表名”）会发生根本变化。

2. 版本升级与多 Catalog 支持：

   • 若需保留旧库表名格式（如大小写混合），可通过 Smartbi 的 “ID 替换规则” 功能，强制将旧库的表名 / 字段名转换为 StarRocks 支持的格式。
   • 操作示例：配置 “UPPER_NO_CATALOG” 规则，将旧库中大写表名（如 “OrderInfo”）自动映射为 StarRocks 的全小写表名（“orderinfo”），无需手动修改报表、数据集等上层资源。

...

1. • 旧版 Smartbi（如 V10.5.8 前）不支持多 Catalog，字段 ID 格式为 “数据源名.表名.字段名”；
   • 新版本（V11）引入多 Catalog 支持后，字段 ID 变为 “数据源名.Catalog.Schema. 表名.字段名”。若旧库升级时未适配新规则，原有的报表、数据集会因 ID 格式不匹配而无法识别新库表结构。

导致问题：元数据解析失效

Smartbi 通过 “数据源→Catalog→Schema→表→字段” 的层级关系生成唯一标识（ID），若 Catalog/Schema 名称或层级变更，上层资源（报表、数据集、数据模型）会因 “找不到旧 ID 对应的新路径” 报错，具体表现为：

• 报表 / 数据集提示 “表不存在” 或 “字段匹配失败”；
• 数据模型关联关系失效，拖放表时无法自动识别字段映射。

如何处理：

这时候需要先把Schema/Catalog的ID替换成新的规则，详细操作可查看：业务库迁移之后ID替换操作。

4.4 源库与目标库“SQL语法有差异”的迁移

如果源库与目标库的SQL语法有差异，需要手工调整SQL语句。

比如源库 mySQL——》目标库PostgreSQL，在数据模型中使用SQL查询使用子查询，如果替换成了oracle 业务库，需要手动在SQL语句中调整成Oracle 语法：

其他数据库之间不同语法，可通过AI搜索进行调整。

4.

...

5 源库与目标库”函数不一致“的迁移

比如源库 mySQL——》目标库PostgreSQL，在数据模型中使用SQL查询获取当前日期，如果替换成了PostgreSQL业务库，需要在手动在SQL语句中调整成PostgreSQL函数：

4.5 源库与目标库"Catalog 、Schema 不一致"的迁移

比如跨数据库类型迁移（如 MySQL→PostgreSQL）；2个库的Schema/Catalog 名称不一样（如源库 schema 为 “old_schema”，目标库为 “new_schema”），并且还是旧版本升级至新版本（涉及多 Catalog 支持）。

...