简介《人大金仓-KingbaseES GIS数据迁移方案》面向数据库管理员、GIS开发与运维人员以及正在推进国产数据库替代的政企技术团队聚焦地理空间数据从ArcGIS、GeoScene、SuperMap等主流平台向KingbaseES V8.6迁移的实施路径。文档依次介绍KingbaseES的GIS能力与空间数据类型、基于KDTS工具的ETL迁移与结果验证、借助ArcGIS/GeoScene软件直接导库的流程以及SuperMap和第三方通用格式数据的入库方法各章均附常见问题汇总便于对照排查。包内仅含1份PDF文档压缩包约2.76MB内容集中于操作步骤与配置要点适合按章节检索查阅。目前已有136人学习下载。读者可从中获得矢量与栅格数据的迁移思路、源库与目标库连接配置参考、迁移后完整性校验方法及典型故障应对经验对规划迁移方案、编写实施文档有直接借鉴价值。1. GIS 数据迁移最容易出问题的地方从来不是搬不搬得动很多人第一次接 GIS 数据迁移会本能地当成一次普通的库表搬迁导出、导入、核对行数结束。做完才发现几何字段从 geometry 退化成 varchar平台那几张 SDE 元数据表根本没进目标库客户端连上去图层列表一片空白。KingbaseES 的 GIS 数据迁移方案要解决的正是这件事——它不是一次 dump而是把矢量、栅格、三维数据连同 GIS 平台依赖的元数据、空间索引、坐标系定义一起迁过去并在目标端重新注册成可用的地理数据库。这套内容适合正在做国产数据库替换的 DBA、GIS 应用开发也适合要交一份完整迁移设计的毕设或课设读者尤其适合源端连着 Oracle Spatial、数据体量又很大的场景。2. 迁移前的摸底与选型四条路径怎么分流迁移方案是否合理八成取决于开工前那两天的摸底。上来就装工具、建任务往往做到一半才发现源库里有一半是切片缓存文件压根不进数据库或者字段里混着三种坐标系迁完连范围框都对不上。先把数据形态和路径定下来后面每一步才有依据。2.1 先看清源库里到底存了什么空间数据不是一张表的事。同一个 GIS 库里通常同时存在四类东西它们的迁移方式完全不同混在一起谈一次迁完必然出问题。数据类型典型内容存储形态迁移方式矢量数据行政区划、道路、POI、建筑物转为数据库表用专门的 geom 字段存空间位置表迁移几何字段需按空间类型重建栅格数据航片、卫片、高程、无人机影像tif/img影像本身 元数据属性表实际存储路径、中心点、范围框、星历参数属性表与影像文件分开处理三维数据带 Z 维度的高程对象、TIN、POLYHEDRALSURFACE数据库表支持 Z/M 维度与体积对象建模表迁移注意维度信息不能丢切片缓存各类瓦片、缓存目录文件系统不进库直接按目录同步矢量数据的源文件格式五花八门dwg、dxf 是 CAD 系shp 是事实上的国际标准kml、geojson 多见于交换场景。迁移要做的不是把这些文件搬进目录而是把文件里的几何与属性解析成表记录。但凡源端是库 文件混合形态摸底时就得分清楚哪些进库、哪些走文件同步别让两类东西挤在同一个迁移任务里。还有一类容易被忽略平台自身的系统表。GIS 平台在关系库里除了业务图层还会建一批描述图层结构、版本、权限的元数据表它们名字看起来像业务表实际是平台运行的基础。这些东西漏迁业务表迁得再完整客户端也认不出图层。2.2 四条路径的分流判据方案里给了四条迁移路径选择依据不是偏好而是三个客观条件源库类型、数据体量、源端有没有 GIS 平台在跑。路径适用条件主要工具典型场景KDTS 工具迁移源端为 Oracle Spatial数据量巨大或源端已无 GIS 平台只剩备份库文件KDTS要素类、要素集、整库级别的大体量搬迁平台异构库迁移有 ArcGIS / GeoScene 平台在运行图层数量少、数据量小平台自带的异构数据库迁移能力几十个图层的中小项目切换SuperMap 侧迁移源端为 SuperMap 体系平台导出 目标库导入单一平台的整体切换通用格式入库数据以 shp、geojson、kml、tif 等文件形式散落平台导入或工具入库数据来源杂、无统一平台分流的核心判断只有一句话有平台且数据量小用平台自己的能力没平台或数据量大走 KDTS。平台自带的迁移在图层多、单表上千万行时速度会明显下降这是工具架构决定的不是参数没调好。反过来几十个图层的小库硬上 KDTS配置成本反而更高容易出现为了迁 200MB 数据写了一下午任务的尴尬。提示判断数据量大不要只看总容量。一张 3000 万行的路网表和一堆 200 行的行政区划表迁移难度完全不在一个量级。按单表最大行数和大字段LOB占比来判断更准。2.3 目标端准备别等报错才想起这几项目标库不是建个库就完事。空间能力靠插件提供字符集、表空间、连接数这些基础项没配对迁移中途报的错往往指向别处排查起来很折磨人。-- 目标库建好后先确认空间扩展可用没有它geometry 类型根本建不出来 CREATE EXTENSION IF NOT EXISTS kgis; -- 版本与字符集必须核对源目两端编码不一致中文属性会最先出问题 SELECT version(); SHOW server_encoding; SHOW lc_collate; -- 迁移单独开一个 schema便于迁移失败后按 schema 整体清理重来 CREATE SCHEMA IF NOT EXISTS gis_mig; -- 大表迁移期间临时放宽迁完再调回这两项直接影响建索引和几何运算的速度 ALTER SYSTEM SET maintenance_work_mem 2GB; ALTER SYSTEM SET work_mem 256MB;这段里最容易被跳过的是server_encoding。源端如果是 GBK 系编码、目标端是 UTF8几何数据本身没问题但图层名、字段注释、属性表里的中文地名会出现乱码而且这种乱码在迁移日志里看不出来要等业务方打开图层才发现。另一项是连接数。KDTS 默认会向源库和目标库各开最多 100 个连接如果目标库的max_connections只有 200 而线上业务已经占掉大半迁移任务会在跑到一半时连接被拒。开工前把目标库连接数调高或者把工具的连接数上限压到 30 以内二选一。2.4 迁移窗口与回滚预案空间库迁移的耗时很难估准一张带大字段的表可能跑几小时。正式切换前通常的做法是先拿一个中等规模的库试跑一遍记录实际耗时再按 1.5 倍留窗口。源库在整个迁移期间保持只读或者至少不做结构变更迁完不立刻下线留出比对和回退的时间。这一步没做好一旦目标端几何批量出错连重来的原始数据都没有后悔药是买不到的。3. 大库搬迁KDTS 工具迁移的关键配置KDTS 是这套方案里承担主力工作的工具。它用插件方式动态加载待迁移数据库的访问接口支持结构迁移、全量数据迁移、列名映射和表数据过滤源端覆盖 Oracle、MySQL、SQLServer、Db2、Gbase、PostgreSQL、达梦和 KingbaseES 本身。这一章按实际动手顺序把配置讲透。3.1 源端与目标端连接怎么建连接配置是整个任务的地基参数填错后面全白干。需要填的项包括连接名称、数据库类型、数据库版本、服务器地址、端口、用户名、密码、数据库、驱动、URL 和连接参数其中 URL 由前面的地址端口库名自动生成但生成规则因库而异。源端是 Oracle 时要额外选 SID 还是 ServiceName。SID 是实例名用于和操作系统交互的标识ServiceName 是服务名在集群环境下各节点 SID 可能不一致但 ServiceName 统一所以集群源库一律选 ServiceName否则连到哪个节点全看运气。目标端是 KingbaseES 时URL 类型可以在 JDBC 和 UnixDomainSocket 之间选。UnixDomainSocket 是同一主机上的进程间通信方式当迁移工具和目标库装在同一台 Linux 服务器上时用它能省掉网络栈开销大批量写入时收益明显。工具和目标库不在一台机器上就老老实实选 JDBC。# 端口不是默认值时必须显式带出否则客户端会连到默认端口上另一个实例 # ArcGIS 侧添加数据库连接时的实例写法示例 # 192.168.4.30,5444 # 逗号前是地址逗号后是实际端口只有端口为 5432 时才可以省略这条规则在 ArcGIS 侧建连接时同样适用方案里专门强调过instance 端口号不使用 5432 时必须注明。踩过这个坑的人都知道报错信息只会说连接失败不会告诉你是端口问题。3.2 任务四步走源、模式、对象、参数新建迁移任务固定是四步选择数据源、选择模式、选择迁移对象、配置参数。第一步填任务名不能重名选定源库和目标库连接。第二步选模式需要迁系统模式的要勾上包含系统模式模式多的时候用左上角查询框检索。这一步有个硬性约束至少选一种模式否则直接报错任务建不下去。第三步选迁移对象三种策略——全部表、包含指定表、排除指定表。选包含指定表时有三种录入方式输入框直接敲表名多个用逗号分隔后回车确认、从列表中勾选、从文件导入。文件导入要先下载导入模板按模板规则填写再上传适合几百张表需要精确控制的场合。选了包含指定表却一张没加系统会拦住不让进下一步这个设计其实是在救你——空列表跑出来的任务要么全量迁要么什么都不迁两种都不是你想要的。第四步是参数配置也是整个任务里最需要经验的部分单独展开。3.3 性能参数别用默认值参数面板分迁移配置和数据类型配置两块。数据类型配置里可以做源类型到目标类型的映射、长度限制调整遇到源端某些自定义类型需要改写时在这里处理。迁移配置这块的默认值偏保守大库场景必须调。参数默认值作用大库建议源库游标读取记录数100单次从源库游标取出的行数提到 10005000减少网络往返批量写入目标库记录数1000单批写入的行数提到 5000配合提交大小调整每次批量提交大小100MB单次事务提交的数据量视目标库 WAL 与磁盘写入能力可到 200500MBLOB 字段预读取大小4000 Byte大字段的预读缓冲影像、长文本多时提到 32KB 以上数据库最大连接数100对源库和目标库的连接上限压到 30 以内除非目标库连接数充裕游标读取记录数和批量写入记录数是一对。前者决定从源库拉数据的速度后者决定往目标库灌的速度只调一个会形成瓶颈读得再快写不进去也是白搭。提交大小则和事务日志直接相关单次提交太大目标库的日志文件会涨得很快回滚段压力也大。大表拆分阈值是另一个关键项。它按行数或表大小设定拆分界限还带一个拆分最大块数的上限。一张几千万行的要素表如果整表作为一个迁移单元中途失败就得从头再来拆成若干块之后失败只影响当前块。含大对象的表还可以单独设游标读取记录数上限避免一次性把大量影像数据拉进内存。表排序依据默认是按行数和大字段大小交替意思是大小表穿插着迁。这个策略的好处是前期就能看到进展、及早暴露配置问题坏处是总耗时略长。如果窗口很紧可以改成按大小排序先啃硬骨头但要接受跑了三小时还没看到一张表完成的心理压力。非对象设置那一栏控制主键、检查约束、唯一约束、外键、索引、触发器、注释是否随迁默认全选表名列名大小写默认保持不变要统一成大写或小写在这里改。3.4 迁移完成不等于可用注册地理数据库任务状态栏显示完成只是数据到位了。ArcGIS / GeoScene 平台的数据迁移后必须执行注册后续应用才能正常识别图层。迁移完成后结果目录下会生成一个形如result/2021-12-02_15-15-15/SDE/AcrpyRegisterScript/acrpyRegisterWithGeodatabase.py的注册脚本把它拷贝到 ArcGIS 所在机器上放到对应版本的 Python 目录例如C:\Python27\ArcGIS10.8下执行。# 注册脚本执行前的两项检查少一项都会失败 # 1. 确认脚本版本与 ArcGIS 的 Python 版本匹配10.x 系列走 Python 2.7 # 2. 确认执行账号对目标库有创建/修改地理数据库对象的权限 python acrpyRegisterWithGeodatabase.py这一步是整个流程里最容易被漏掉的环节因为它不在迁移任务的界面里只有翻到结果目录才会发现。跳过注册的后果是库里数据一条不少SQL 查得出几何客户端连上去图层列表却认不出来。血泪经验——先注册再验收。4. 小数据量快搬平台直连与通用格式入库不是所有迁移都值得开 KDTS。图层不多、数据体量在百万行以下的场景用 GIS 平台自己的能力反而更快配置也更直观。这一章讲清另外三条路径的落点。4.1 ArcGIS / GeoScene 侧走异构库迁移这条路径的操作链是在 ArcMap 里通过 ArcToolbox 进入数据管理工具下的地理数据库管理创建企业级地理数据库源库比如 Oracle和目标库KingbaseES分别建立数据库连接在 ArcCatalog 的目录树中对两个连接都执行启动地理数据库然后用平台自带的复制、导出入库能力把要素类搬过去。创建企业级地理数据库时有个细节选择授权文件只能用*.ecp格式其他格式在界面上根本选不中。启动地理数据库这一步源端和目标端都要做只做目标端会导致源端要素类读不出空间参考。连接参数里instance 那一栏按 3.1 节的规则写地址加端口。这条路径的边界很清楚图层数量少、单表数据量小。它的好处是平台全程托管空间参考、字段类型、几何校验几乎不用手工干预坏处是图层一多、表一大速度就肉眼可见地掉下来。判断标准通常是单表不超过几百万行、图层总数几十个以内。4.2 SuperMap 侧的迁移落点SuperMap 体系的迁移思路和 ArcGIS 侧接近也是走源端导出、目标端配连接、导入入库的链路。差别在于 SuperMap 对数据源的组织方式不同它的数据源、数据集概念和 ArcGIS 的要素集、要素类不是一一对应的迁移前要先把对应关系理清楚否则容易出现数据集迁过去了但挂在错误的数据源下。配置目标库连接时同样是地址、端口、库名、用户名密码这几项端口非默认值必须带出。迁移后的验证和 ArcGIS 侧一致也是查结构、查行数、查范围框方案里同样配了 FAQ 部分覆盖常见异常。三个平台的 FAQ 内容其实高度重合翻来覆去就是坐标系、几何为空、字段截断、权限这几类第 5 章统一收拢。4.3 通用格式文件入库shp、geojson、kml 与栅格没有平台、数据以文件形式存在时走通用格式入库。矢量文件按格式分两类处理shp、geojson、kml 这类标准矢量格式通过平台或工具的导入功能直接生成带 geom 字段的表dwg、dxf 这类 CAD 格式需要先做图层剥离和坐标转换CAD 的坐标系定义经常缺失或写错直接入库会得到一堆位置飘到海里的要素。栅格数据走另一条路。KGIS 支持栅格存储能直接存元数据和属性信息减少读取的时间与空间成本——影像的实际存储路径、中心点、范围框、星历参数这些都可以进表查询时先查元数据定位再按路径取影像比整幅读进内存高效得多。要注意三维模型和倾斜摄影测量数据不走这套存储方式它们按栅格那套处理。-- 通用格式入库后的自检几何类型、坐标系、范围框三项一起看 SELECT f_table_name, type, -- 几何类型点线面是否与源文件一致 srid, -- 空间参考标识0 表示未定义坐标系 ST_Extent(geom)::text -- 整体范围框与源文件对比能立刻发现坐标偏移 FROM geometry_columns WHERE f_table_schema gis_mig;srid为 0 是最常见的隐性故障。数据能查、能显示但做空间分析时距离算出天文数字或者图层叠加完全对不上。这类问题不会报错只会让业务方觉得迁完之后算得不对。4.4 四条路径怎么选一张对照表判断项KDTS平台直连SuperMap 侧通用格式源库类型Oracle Spatial 等异构库有平台在运行SuperMap 体系文件形式单表规模千万行级百万行以内中小规模随意是否需 GIS 平台不需要必需必需可选元数据完整性需迁移后注册平台自动处理平台自动处理需手工建主要风险参数配置、注册遗漏大表速度慢数据源对应关系坐标系缺失实际项目里经常是组合使用主体走 KDTS零散的历史文件走通用格式入库最后统一做一次验收。别指望一条路径通吃。5. 避坑与排查五处最容易出问题的地方5.1 迁移显示完成但几何字段是空的现象任务状态完成表行数和源端一致打开表一看 geom 字段全为 NULL或者几何类型变成了文本。原因通常是两处。一是源端的几何字段类型在目标端没有对应映射工具按默认规则降级处理成了 varchar二是非对象设置里没勾选对应项空间索引和几何约束没建出来字段建成了普通列。解决先在数据类型配置里显式建立源类型到目标类型的映射几何字段必须落到 KGIS 的 geometry 类型上。迁完立刻用SELECT count(geom)和总行数对比两个数字不等就是这个问题不用等业务方反馈。5.2 坐标系对不上图层叠加全飘现象数据完整几何也在但和底图叠加时整体偏移或者距离计算明显不对。原因源端要素类里存的空间参考在迁移中丢失目标端 srid 变成 0 或者被套上了错误的值。集群环境下源端不同节点的坐标系定义不一致时更容易出这种事。解决迁移前把源端每个图层的 SRID 导出一份清单迁完逐个比对。SRID 为 0 的图层必须回填正确的空间参考不能靠看起来能显示蒙混过关。5.3 中文图层名和字段注释变乱码现象表结构和数据都对但图层名、字段注释、属性里的中文地名显示成问号或乱码。原因源目两端server_encoding不一致或者迁移过程中字符集转换没开。解决建库阶段就把目标库编码对齐到 UTF8迁移任务里确认字符集转换选项开启。已经乱码的只能按 schema 清空重迁改不回来。5.4 迁完客户端打不开图层现象SQL 查得到数据几何、坐标系都正常ArcGIS / GeoScene 连上去图层列表是空的或者报错。原因忘了做地理数据库注册。KDTS 迁完不会自动注册注册脚本躺在结果目录里没人管。解决到result/时间戳/SDE/AcrpyRegisterScript/下取acrpyRegisterWithGeodatabase.py复制到对应 Python 目录执行。把这一步写进迁移检查清单别靠记忆。5.5 大表跑到一半断了重来代价太高现象几千万行的表迁到 70% 失败重跑又是几小时。原因大表拆分阈值没设整表当一个单元或者目标库连接数、日志空间不够跑到中途资源耗尽。解决按行数或表大小设拆分阈值并设置拆分最大块数让失败只影响当前块。批量提交大小从默认 100MB 往下调一档减轻目标库日志压力。失败后先看日志定位到具体块不要直接整任务重跑。6. 验收与答辩用一组 SQL 自证迁移结果迁移做完怎么证明它是好的靠口头说我核对过了没有说服力尤其答辩场合。我一般按四层往下走结构层、数量层、空间层、业务层每层都有可以拿出来的证据。结构层比对表、字段、类型、约束、索引是否齐全用系统表导出的方式逐项比对数量层比对每张表的行数和大字段非空数量空间层比对 SRID、几何类型、整体范围框业务层挑三到五个典型图层在客户端里叠加、查询、做一次空间分析看结果是否符合预期。验证层检查项判定标准结构表数量、字段名、字段类型、主键与索引与源端清单完全一致数量各表行数、geom 非空数、LOB 非空数行数一致几何与 LOB 无缺失空间SRID、几何类型、范围框SRID 无 0 值范围框偏差在容差内业务叠加显示、属性查询、空间分析结果与源端一致数量层和空间层可以写成一个脚本一次跑完比人眼核对靠谱得多。# check_gis_migration.py # 逐表比对行数、几何非空数、SRID 种类与整体范围框 # KingbaseES 走 PG 协议PG 驱动可以直接连空间函数以《KingbaseGIS 参考手册》为准 import psycopg2 TABLES [gis_mig.roads, gis_mig.poi, gis_mig.parcel] def stat(cur, table): cur.execute(f SELECT count(*), -- 总行数 count(geom), -- 几何非空数差值就是丢几何的行 count(DISTINCT ST_SRID(geom)), -- SRID 种类1 说明坐标系混了 ST_Extent(geom)::text -- 整体范围框 FROM {table} ) return cur.fetchone() conn psycopg2.connect(host10.0.0.21, port54321, dbnamegisdb, usermig, password***) cur conn.cursor() for t in TABLES: rows, geoms, srids, extent stat(cur, t) flag OK if rows geoms and srids 1 else CHECK print(f{t:24s} rows{rows:10d} geom{geoms:10d} srid_kinds{srids} extent{extent} [{flag}]) cur.close() conn.close()这段的关键在三个比值。rows和geoms不等说明有行丢了几何回到 5.1 排查srid_kinds大于 1说明同一张表里混了多个坐标系这种表在业务侧做任何空间运算都不可信extent拿源端跑一遍对比偏差超过一个小量级基本就是坐标偏移。脚本里表名和连接信息按自己环境改空间函数的具体名称对着《KingbaseGIS 参考手册》核一遍不同版本可能有细微差异。答辩时我建议把顺序倒过来讲先展示验收脚本的输出再回头讲迁移路径和参数为什么这么选。评委的问题八成集中在你怎么保证迁全了坐标系怎么处理大表失败了怎么办这三个问题前面几章都有现成答案把证据摆出来比讲原理有效得多。从那以后我每次做空间库迁移不管数据量多小都强制先跑一遍摸底清单、再跑一遍验收脚本两步都留痕。吃过一次迁完了但图层打不开的亏之后就知道省下的那半小时后面要拿一整天去补。这套方案里的路径选择、参数配置和验收方法拿去做课程设计或者直接改改用到项目上都够用希望帮到你。本文还有配套的精品资源点击获取