简介《人大金仓-KingbaseES GIS数据迁移方案》面向需要将ArcGIS、GeoScene、SuperMap等平台空间数据迁移至国产KingbaseES数据库的DBA、GIS开发与数据管理人员围绕矢量/栅格数据入库、迁移验证及常见问题给出可操作的路径。压缩包仅含1个PDF文件约2.76MB文档版本V8.6目录从适用读者、术语约定讲起依次覆盖KingbaseES GIS能力、基于ArcGIS的KDTS工具迁移、ArcGIS/GeoScene软件迁移、SuperMap迁移以及第三方通用格式GIS数据入库并配有迁移结果验证与FAQ。已有136人学习适合作为迁移项目的前期评估与实施参考读者可据此了解KDTS的抽取、转换、加载流程掌握源库与目标库连接配置、GIS表和字段选择、迁移后完整性核对及排错思路也能对照各平台章节规划迁移步骤与验证清单。1. 迁移前先想清楚GIS 数据进国产库到底难在哪上周有位同行把一套 ArcGIS 的要素集往 KingbaseES 里搬表建好了、数据也进去了结果客户端一打开图层就是空白日志里只有一句空间参考不匹配。这种翻车在 GIS 数据迁移里太常见了——问题往往不在“能不能导进去”而在空间字段、空间参考、元数据注册这三件事有没有对齐。这份 KingbaseES V8.6 的 GIS 数据迁移方案讲的正是把 ArcGIS、GeoScene、SuperMap 以及 shp、GeoJSON 这类通用格式的空间数据落到 KGIS 插件上的完整路径涵盖 KDTS 工具迁移、平台原生异构迁移、迁移后验证和 FAQ 四块。适合正在做信创替换的 DBA、GIS 应用开发以及手上只有一份 Oracle Spatial 备份、连 GIS 平台都没有的运维同学。2. 先搞懂 KGIS 存的是什么矢量、栅格、三维的落库形态2.1 数据库在 GIS 架构里站的位置国内外主流 GIS 平台的数据组织方式大同小异业务属性表放在关系库里空间几何单独抽成一列栅格影像和切片缓存则走文件系统或对象存储数据库只保留路径、范围框、中心点这些元信息。这个结构直接决定了迁移时你要搬的不是“一个文件”而是三类形态完全不同的东西。矢量数据最终变成带geom字段的普通表。行政区划、POI 点、道路这些.shp、.kml、.geojson进去之后一行一个要素几何存在专门的空间列里配合空间索引才能查得动。栅格数据tif、img、航片、卫片、高程、无人机影像KGIS 的处理方式是存元数据加实际存储路径把中心点、范围框、星历参数这些属性落到表里查询时先走属性过滤再去读文件省掉大量 IO。三维数据支持 Z 维度和 M 维度TIN、POLYHEDRALSURFACE 这类体积对象可以建模也能算三维对象之间的关系。这里有个容易误判的点倾斜摄影和三维模型不走三维几何存储方案里明确说按栅格那套方式存。我见过有人把一大坨倾斜摄影硬塞进几何字段结果单表膨胀到几百 GB查询直接拖垮实例。选型上记住一条——几何列只放真正需要空间运算的要素影像和模型走元数据引用。2.2 为什么强调 KGIS 插件而不是裸库KingbaseES 本身是通用关系库空间能力来自 KGIS 插件。装了插件才有几何类型、空间索引、空间函数这一整套。迁移前的第一件事就是确认目标库的 KGIS 已经就位、版本和源端几何类型能对上否则 KDTS 把数据推过去了建表阶段就会因为找不到几何类型而失败。常见做法是先在一个空库上跑一遍CREATE EXTENSION之类的初始化再拿一张小表试水。提示源端如果是 Oracle Spatial几何类型是 SDO_GEOMETRY目标端是 KGIS 的几何类型两者不是一对一映射。字段类型转换规则要在 KDTS 的“数据类型配置”里逐条确认别指望默认映射全覆盖。3. KDTS 迁移实操从建连接到大表拆分的完整参数3.1 什么场景该选 KDTS而不是平台自带迁移方案里给了两条路选择标准很实在。ArcGIS/GeoScene 平台自带的异构数据库迁移适合少量图层、小数据量点点鼠标就完事但只要满足下面任一条件就该上 KDTS数据存在 Oracle Spatial 里且要素类、要素集、整库体量巨大平台迁移慢到无法接受手上只有数据库备份文件压根没有 GIS 平台可以做中转。KDTS 的定位是通用数据迁移工具用插件方式动态加载各数据库访问接口支持结构迁移、全量数据迁移、列名映射和表数据过滤。GIS 场景下它多干一件事把空间字段原样搬过去再由目标端注册成地理数据库要素类。3.2 源库与目标库的连接配置先在 ArcMap 的 ArcToolbox 里走“数据管理工具 → 地理数据库管理 → 创建企业级地理数据库”把源 Oracle 和目标 KingbaseES 都配上。ArcCatalog 里添加数据库连接时有个细节KingbaseES 的 instance 如果端口不是默认 5432必须写成IP,端口的形式比如192.168.4.30,5444。写成IP:端口是连不上的。两个库都要右键执行“启动地理数据库”授权文件只能用*.ecp用别的格式会直接报错。这一步做完ArcGIS 侧才算认了这两个库是地理数据库后面的注册流程才有基础。3.3 KDTS 连接参数逐项拆解新建源/目标数据源时需要填的字段包括连接名称、数据库类型、数据库版本、服务器地址、端口、用户名、密码、数据库、驱动、URL、连接参数。几个容易填错的参数说明常见错误数据库类型源端支持 Oracle、MySQL、SQLServer、Db2、Gbase、PostgreSQL、DM、KingbaseES选错类型导致驱动不匹配URL 生成方式Oracle 需选 SID 或 ServiceNameKingbaseES 需选 JDBC 或 UnixDomainSocket集群环境用 SID 连不上连接参数按数据库类型适配可增删超时参数没调大表迁移中途断连SID 和 ServiceName 的区别值得单说SID 是实例名用于和操作系统交互的标识ServiceName 是服务名。集群环境下各节点 SID 可能不一致但 ServiceName 统一所以集群库一律用 ServiceName。至于 UnixDomainSocket是给迁移工具和目标库装在同一台 Linux 服务器时用的走进程间通信比 TCP 快一截能明显压缩大数据量的传输时间。3.4 建任务的四步流程与关键取舍新建迁移任务分四步选择数据源、选择模式、选择迁移对象、配置参数。选择模式这一步至少得选一种模式否则直接报错卡住。如果只选了模式没勾“表”系统会认为你不需要迁移对象自动跳过第三步直接进参数配置——这个行为容易让人以为漏了步骤其实是设计如此。选择迁移对象时可以全选、包含指定表、排除指定表。指定表有三种录入方式输入框直接敲表名多个用逗号分隔回车确认、从列表勾选支持按模式、表名关键字、数据条数限制检索、从文件导入先下载模板按规则填好再导。列表为空就点下一步会报错。配置参数是真正决定迁移成败的一屏逐项说# KDTS 参数配置的关键取值界面项此处以键值形式记录便于复现 table_default_action 建表/重建表 导入数据 # 默认全选只要结构就取消“导入数据” table_sort_by 按行数和大字段大小交替 # 默认大表多时改成按大小排序更稳 source_cursor_fetch 100 # 源库游标读取记录数 batch_write_rows 1000 # 批量写入目标库记录数 batch_commit_size 100MB # 每次批量提交大小 lob_prefetch_size 4000Byte # LOB 字段预读取大小 split_threshold_rows 按行数拆分 # 大表拆分阈值依据 split_max_blocks 块数上限 # 拆分最大块数 max_connections 100 # 源/目标库最大连接数逻辑上分三层。第一层是对象处理建表/重建表决定是否在目标端重建结构导入数据决定只迁结构还是连数据一起走非对象设置里的主键、检查约束、唯一约束、外键、索引、触发器、自动转换对象名、注释默认全选GIS 表尤其要保留主键和空间索引否则迁完查不动。第二层是吞吐调优游标读取 100、批量写入 1000、每次提交 100MB 是默认组合数据量大时把批量写入调高通常更快但内存吃紧就要往回压LOB 预读取 4000 字节对带大字段的要素表影响明显。第三层是大表拆分按行数或按大小拆配合拆分最大块数和含大对象表的游标读取上限把一张几千万行的要素表切成多块并行搬。表名和列名大小写默认“不变”需要统一成大写或小写再改这个选项在跨库大小写敏感差异大的时候能救场。数据库连接数默认 100源库扛不住就往下调不然迁移一开始就把生产库连接池占满。配置完点“保存”是预迁移任务点“保存并迁移”直接开跑。状态栏显示“完成”即成功显示“失败”可以点详情看日志定位。3.5 迁完必须注册否则应用打不开这是整份方案里最容易被跳过、后果最严重的一步。ArcGIS/GeoScene 平台的数据迁到 KingbaseES 之后必须做注册后续应用才能正常识别要素类。操作方式是把迁移输出目录下result/时间戳/SDE/AcrpyRegisterScript/里的acrpyRegisterWithGeodatabase.py拷到 ArcGIS 所在机器放到类似c:\Python27\ArcGIS10.8的目录下用对应 Python 环境执行。没注册的表现很统一数据明明在表里SELECT count(*)也有数但客户端加载图层是空的或者提示不是有效的地理数据库要素类。血泪经验是——注册脚本要在迁移成功后立刻跑不要等业务方来报障才回头补。4. 平台原生迁移与通用格式入库小数据量和无平台的两条路4.1 ArcGIS/GeoScene 原生异构迁移的适用边界少量图层、小数据量的场景没必要上 KDTS。直接在 ArcGIS/GeoScene 里走数据导出、配置 KingbaseES 连接、导入这条链就行。优点是图形化、不用额外装工具缺点也很明显数据量一大就慢中途失败的回滚和断点续传能力弱。我一般把这条路径当作验证通道——先拿它把几张核心表迁过去确认 KGIS 的空间函数和索引表现符合预期再决定是否用 KDTS 批量推全量。迁完同样要验证对比源端和目标端的要素数量、几何类型、空间参考、范围框是否一致。这一套检查在方案里对应“迁移结果验证”小节核心就是逐项比对别只看行数。4.2 SuperMap 平台迁移的差异点SuperMap 走的是自家工具或 API 把数据导出再导入 KingbaseES流程同样是导出、配连接、导入、验证四段。和 ArcGIS 最大的差别在于空间数据模型的抽象层次不同同一份矢量数据在两边对字段命名、几何类型细分、坐标系描述的表示不完全一致。迁移前建议先做一张对照表把源端的几何类型、坐标参考系、字段类型和目标端 KGIS 支持的类型一一对上尤其是自定义坐标系和带 M 值的数据转换过程中丢失维度是很隐蔽的坑。4.3 通用格式shp / GeoJSON / KML入库的做法没有 GIS 平台、手上只有一堆.shp、.kml、.geojson、.dwg、.dxf的时候走通用格式入库。思路是先确认文件本身的坐标系定义完整.shp依赖同名.prj文件缺了就是无坐标系数据进去之后没法做空间分析再把几何和属性解析成带空间列的记录批量写入最后建空间索引并验证。# 通用矢量文件入库的骨架逻辑伪代码按实际驱动替换 import shapefile # 读 shp import psycopg2 # KingbaseES 兼容 PG 协议 conn psycopg2.connect(host192.168.4.30, port5444, dbnamegisdb, useruser, password***) cur conn.cursor() sf shapefile.Reader(roads.shp, encodingutf-8) # encoding 必须与属性表实际编码一致 fields [f[0] for f in sf.fields[1:]] # 跳过 DeletionFlag # 建表属性列 一个几何列几何类型要和 shp 的 shapeType 对上 cur.execute( CREATE TABLE roads ( gid serial PRIMARY KEY, name varchar(128), geom geometry(LineString, 4490) -- 4490 为 CGCS2000 地理坐标 ) ) rows [] for sr in sf.iterShapeRecords(): wkt sr.shape.__geo_interface__ # 转 GeoJSON 结构再拼 WKT rows.append((sr.record[name], wkt)) cur.executemany( INSERT INTO roads(name, geom) VALUES (%s, ST_GeomFromGeoJSON(%s)), rows) cur.execute(CREATE INDEX idx_roads_geom ON roads USING gist(geom)) conn.commit()逐段说明。连接部分KingbaseES 走 PG 协议端口按实际填别默认 5432。建表部分几何类型必须和 shp 的shapeType严格对应——点就是 Point线就是 LineString写成 Geometry 泛型虽然能进但索引效率会打折SRID 要填对4490 是 CGCS20004326 是 WGS84填错等于数据带了个假的坐标系标签后面所有空间运算都是错的。插入部分ST_GeomFromGeoJSON是通用转换入口比手工拼 WKT 少踩转义坑。最后建 GiST 空间索引不建索引的要素表在千万级数据下基本不可用。注意encoding参数要跟 shp 属性表的实际编码一致。中文属性乱码十有八九是这里没对上不是数据库字符集的问题。5. 避坑清单迁移现场最常见的五类翻车5.1 迁完图层空白日志只有坐标系报错现象表里有数据客户端加载图层是空的或者提示空间参考不匹配。原因源端和目标端的 SRID 没对齐或者 shp 缺.prj导致几何进去时是无坐标系状态。解决迁移前逐层核对空间参考通用格式入库时显式指定 SRID已经迁错的用ST_SetSRID修正再重建空间索引。5.2 KDTS 任务卡在“选择模式”过不去现象模式选了点下一步没反应或者报错。原因只选了模式没勾“表”系统认为没有迁移对象行为上会跳步另一种是模式列表为空压根没选。解决先确认至少勾选一张表或者明确要走“只迁结构”就接受跳步逻辑模式搜索框可以按关键字快速筛别在长列表里手翻。5.3 大表迁移中途断连重跑又从零开始现象几千万行的要素表跑到一半连接断开任务失败重跑耗时翻倍。原因批量提交大小和连接数没调单次提交过大或者源库连接池被打满也可能是网络抖动叠加没有断点机制。解决把每次批量提交压到 100MB 以内、批量写入行数降到 1000 左右连接数从 100 往下调超大表一律开大表拆分按行数或大小切块单块失败只补那一块。血泪经验是大表拆分阈值不要拍脑袋先拿一张表试跑测出单块耗时再定块数。5.4 迁完没注册业务方打不开要素类现象数据全在count正常但 GIS 客户端认不出这是要素类。原因跳过了acrpyRegisterWithGeodatabase.py注册这一步。解决迁移成功后立刻执行注册脚本Python 环境要和 ArcGIS 自带的版本对上。这类问题没有后悔药只能回补注册补之前别让业务方接入。5.5 中文属性乱码、字段名大小写错乱现象属性表里中文变成问号或方块或者迁完发现所有字段名都被转成大写应用代码全挂。原因shp 编码没指定或者 KDTS 的表名/列名大小写选项被改成了强制大写/小写。解决通用格式入库时显式传encodingKDTS 里大小写选项默认“不变”除非应用侧明确要求统一否则别动。已经错了的重建表再迁比事后改字段名省事。6. 验证怎么做才算过关三条检查线和一个习惯迁移结果验证最忌讳只看行数。行数相等但几何错位、坐标系错标、索引缺失的情况太多了。我一般按三条线走。第一条是数量与结构线源端和目标端逐表比对记录数比对字段名、字段类型、字段长度几何列的类型和 SRID 单独核。KDTS 的任务详情里能看到结构迁移的明细拿它和源端USER_TAB_COLUMNS之类的元数据对一遍。第二条是空间正确性线抽若干要素比对几何的 WKT 或 GeoJSON 是否一致再算一遍范围框extent源端和目标端的 min/max 坐标要能对上空间参考的 SRID 必须一致。这一步可以用一条 SQL 快速扫-- 抽检要素数、范围框、SRID 一致性 SELECT count(*) AS feature_cnt, ST_Extent(geom) AS bbox, ST_SRID(geom) AS srid FROM roads;ST_Extent返回的包围盒和源端对比偏差超过容差就说明几何在转换中被改动过ST_SRID全员一致才算过。第三条是可用性线在目标库上跑几条真实业务会用的空间查询比如范围查询、相交判断、缓冲区分析看执行计划有没有走空间索引。没走索引的话数据再对上线也是灾难。EXPLAIN里出现 Seq Scan 而不是 Index Scan回头查索引建没建、几何类型是不是泛型。最后说个习惯。从那以后我每次做 GIS 迁移都强制先拿一张中等规模的表跑完整链路——建连接、迁结构、迁数据、注册、验证、跑查询——全过一遍再动全量。这套流程里任何一个环节的坑在小表上暴露的成本是小时级在全量上是天级。方案里的 FAQ 部分值得在动手前通读一遍很多报错它已经写了原因只是现场没人翻。希望帮到你。本文还有配套的精品资源点击获取