乐趣区

关于数据库:如何利用现代化数据栈高效处理地理信息数据

jiezi

背景常识

什么是地理信息数据

地理信息数据的定义次要来自于咱们熟知的星球——地球。咱们晓得地球表面是一个凸凹不平的外表，是一个近似的椭球体。以海平面为参照已知最高点和最低点之间有靠近 2 万米的差距。

  • 珠穆朗玛峰，8848.86 米含冰层（人民日报：2020 年 12 月 8 日）
  • 马里亚纳海沟，绝对海平面深 10909 米（人民日报：2020 年 11 月 30 日）

即使是海平面也会在月球潮汐引力的作用下变动着，更不要提气候变化导致的海平面升高。因而要想找到一个确切的数学模型来示意地球还是挺艰难的一件事。

于是人们以北极南极为两个定点，将地球依照这个轴线进行旋转。地球在这个旋转状态的下就会出现一个椭球体的状态，这个就是现实的地球椭球体。这个椭球体就能够利用数学模型来进行示意。

正是基于这样一个共识，在 1975 年国内大地测量与地球物理联合会举荐下地球椭球体的模型数据被举荐为：半长径 6378140 米，半短径 6356755 米，扁率 1∶298.257，后续该数值有一些修改。

基于这些精准的测量数据，咱们能够通过数学示意来定义地球上所有的点，从而利用现代化的定位技术咱们能够精确定位地球上所有的地位。

定位技术

在地球上要想晓得咱们准确地位能够应用导航软件，导航软件的失常工作须要依赖全球定位系统。目前世界上共有四大导航系统，别离是

  • 中国的 北斗
  • 美国的 GPS
  • 欧盟的 伽利略
  • 俄罗斯的 格洛纳斯

这些定位系统最次要的局部是人造卫星，它们依照固定的法则围绕地球运行，其中有一些是运行在圆形的地球同步轨道上。

因为每个卫星和咱们的间隔不同，因而它们同一时刻发送的信标会以渺小的工夫距离先后到达咱们的设施上。这样咱们就有了带有提早的信标信号，每一个提早是能够被看作是一个间隔。

咱们当时晓得每一个卫星的确切地位，再加上这些间隔信息。当咱们失去起码 3 个信号之后就能够利用驰名的三角定位法失去咱们的精确地位，这也是所有卫星定位技术应用的外围原理。

空间数据

现有空间数据库规范次要有如下两套，两套规范之间大体是互相兼容的。

  • Simple Feature Access SQL，简称 SFA SQL：SFA SQL 是 凋谢天文空间信息联盟（Open Geospatial Consortium，简称 OGC）制订的规范。
  • SQL Multimedia Part3: Spatial，简称 SQL/MM：SQL/MM 是 国际标准化组织（International Standard Organization，简称 ISO）制订的规范。

通过空间数据的形容咱们能够定义一个具体的几何体。在这两种规范中公共的局部中都定义了上面 3 组共 6 个根底类型，这些是常常用到的类型。

  • 点、多个点
  • 线、多个线
  • 多边形、多个多边形

为了不便存储和应用这些数据 OGC 组织通过 OpenGIS 标准定了两种具体格局

  • Well-Known Text (WKT) format
  • Well-Known Binary (WKB) format

WKB/WKT 都只是通过标记语言形容点、线、面 的几何体数据，当用于几何计算时个别不须要坐标系。然而当数据须要展现在地图上时则须要将其原始的空间数据投射到大地坐标系上（这个过程称为投影）才能够失去这个几何图形具体的地理坐标。

空间援用辨认号 (SRID)

要将几何图形投影到坐标系，必须须要应用 SRID。SRID 能够了解为惟一标识了将某个几何体空间数据映射成某个具体坐标系中的形式。

当 SRID 为 0 或者不应用 SRID 时，示意一个几何图形实例没有被放到任何一个坐标系中，咱们无奈定位其地位。例如通过长宽高的具体值咱们能够晓得一个正方体的形态，然而咱们没法晓得他的具体坐标。

不同 SRID 值代表了将几何体映射到坐标系中的不同形式。几何体自身的空间数据联合 SRID 就能够具体定位这个几何体在坐标系中的地位。

下图简略演示了有无 SRID 得差别。像欧洲石油测绘组 (EPSG) 定义的 SRID 是依据地球地理信息构建的坐标系，几何图形依据几何体空间数据以及 EPSG 规范的 SRID 值能够转成实在的地理坐标。

目前有多种公认的规范 SRID，例如欧洲石油测绘组 (EPSG) 定义的 SRID。不同数据库对于不同 SRID 规范的适配性也不同。

某些数据库和空间类型（如 PostgreSQL 中的 PostGIS 几何和天文或 Microsoft SQL Server 中的天文类型）应用预约义的 EPSG 代码子集，只可应用具备这些 SRID 的空间参考。

现在编制 SIRD 的工作曾经转交给了国际石油和天然气生产商协会 (OGP) 的手中，要想理解更多的 EPSG 信息，能够拜访 https://epsg.io/

常见 SRID 规范与天文坐标系

在中国罕用的坐标系有上面四个

  • WGS84：美国 GPS 零碎上应用的坐标系。
  • GCJ02：由中国国家测绘局制订的地理坐标零碎。
  • BD09：百度地图所应用的坐标系，它是建设在 GCJ02 坐标系之上。
  • CGCS2000：中国北斗零碎所应用的坐标系。

大地坐标系与地图绘制

地图绘制的根本步骤

绘制地图构建大地坐标系次要会采纳以下步骤：

  1. 首先会抉择一个基准点，所有的地形数据都是基于这个基准点的进行绘制。而这个点也正是位于地球椭球体上的一个点。
  2. 地球椭球体能够充当画布，测绘员则能够在画布上勾画出具体的街道和地形信息。从而造成最终的地图数据供咱们应用。
  3. 基于定位的点和地图的基准点的之间的偏差就能够实现整个定位到地图的转换这个过程就是坐标系转换。当然理论的过程要更为简单一些，甚至会有屡次偏差修改。

存储地理信息

目前支流关系型数据库对地理信息根本都都有反对，其中最罕用的类型便是 geometry 类型。在 Oracle 数据库中对应为 sdo_geometry 类型。

还有其它的几何类型，例如：Point、Polygon、MultiPoint、MultiPolygon 等等，介于篇幅的起因本文内容只针对 geometry 类型。

有趣味深刻理解的敌人能够依据下方表格自行深入研究，本文不做过多开展。

数据库 几何类型
MySQL POINT、LINESTRING、POLYGON、MULTIPOINT、MULTILINESTRING、MULTIPOLYGON、
GEOMETRY、GEOMETRYCOLLECTION
PostgreSQL POINT、LINE、LSEG、BOX、PATH、POLYGON、CIRCLE、GEOMETRY
Oracle SDO_GEOMETRY、SDO_TOPO_GEOMETRY、SDO_GEORASTER
SqlServer GEOMETRY、GEOGRAPHY

不同的数据库因为存储和查问引擎的不同，针对地理信息的存储会有一些差别。这些差别次要是因为单纯的 WKB 并不能满足理论需要，最间接的问题就是 WKB 只思考的几何图形的空间数据存储，然而并未波及大地坐标系相干的信息。

比方在 MySQL 中地理信息数据将会在 WKB 数据前额定减少 4 个字节用于寄存其对应的 SRID。而 PostgreSQL 用了更加高级的 EWKB 格局作为地理信息数据的存储格局。

因而如果想要以二进制形式间接从数据库中获取地理信息数据，理解正确的获取形式十分必要。

地理信息数据利用的问题

咱们会从一个具体案例来和大家探讨地理信息数据利用中会遇到的理论问题。咱们这个天文数据利用案例如下：

如何晓得地球上一块土地在一段时间内的应用状况？

为了达成这个目标，咱们将会不得不面临如下的一些挑战：

数据量大

首先土地的应用是随着工夫变动而变动的，比方：

  • 在一些工夫内这些用地可能是耕地，另外一些工夫可能是用作林地。
  • 随着时间推移一块土地可能会被切割成个地块，或者合并成一个更大的地块。

因而每年获取的地图数据都只是当年最新的状况，地块数据也是不停地变动的。

基于这样一个状况，若想要晓得一个时间跨度下的地块变动。通常会涵盖不同工夫的地图数据。若地图数据是 1G 大小，如果要计算 10 年的变动就须要解决 10G 的历史地图数据。

计算量大

对于地图数据中还会含有很多其它结构化数据，比方：小区、门牌号、餐馆名称，地块天堑以及交通路线等等信息。因而在基于业务查问须要会先进行业务维度上的数据查问和筛选。

写过业务逻辑的敌人都晓得，简单的业务查问很可能会波及到几张表的联查操作。在加上咱们还须要通过 GIS 函数进行几何图形的交并计算。这就会引发上面两个问题

  • 大量的天文的几何信息、标注信息引发出大表的 Join 性能问题。
  • 因为 GIS 的函数计算引发的大量计算。

没有万能的数据库

当初支流的对地理信息存储比拟敌对的数据库次要是 PostgreSQL、Oracle 和 SQLServer。像 PostgreSQL 对地理信息数据处理的生态工具也比拟敌对，例如：

  • PostgreSQL 对 GeoServer、MapServer、ArcGISServer 几个地图服务中间件的支持性比拟好。
  • PostgreSQL 对 PostGIS 的反对兼容性要比 Greenplum 好

这些传统数据库并不能解决所有问题，尤其是面临千万级别的 GIS 表时，表的 Join 查问又会面临重大的问题。

侥幸的是，近几年新型和强力的 OLAP 剖析型数据库一直呈现，地理信息数据的解决和剖析能够联合这些新型剖析引擎大大晋升地理信息数据处理的效率。

高效解决地理信息数据的现代化数据栈

以下现代化数据栈的计划来自于 CloudCanal 用户的一个实在案例。该用户原有计划是基于 PostgreSQL 进行地理信息数据的查问和解决。

通过 CloudCanal 数据互通，采纳如下现代化的数据栈，轻松整合了 ClickHouse 弱小的剖析能力和 ElasticSearch 的弱小全文索引能力来解决地理信息数据，大大晋升了地理信息数据处理的效率。

数据栈架构图

以上架构图展现了整个地理信息数据的流向以及处理过程：

  1. PostgreSQL 对地理信息存储和解决比拟敌对，业务利用先将产生的地理信息数据全副写入到 PostgreSQL 中
  2. 利用 CloudCanal 在异构数据源之间迁徙和同步地理信息数据，自动化地转化地理信息数据写入新型的数据源中

  3. 利用 ClickHouse 弱小的剖析能力来高效解决地理信息数据

    1. 海量地理信息数据的聚合、join 剖析操作
    2. 利用利用 ClickHouse 弱小的剖析能力先进行数据初筛，生成数据量较小的无效数据，间接对数据规模较小的地理信息数据应用 JTS 工具进行二次几何函数计算而后生成最终处理结果
  4. 利用 ElasticSearch 弱小的全文索引能力，利用能够间接对 ElasticSearch 中存储的地理信息数据进行全文检索

能够看到采纳 CloudCanal 当前得现代化数据栈解决地理信息数据具备如下益处：

  • 能够应答简单的业务查问须要，针对业务选用不同的新型数据库晋升效率。
  • 利用能够间接应用剖析引擎过滤出来的较小数据规模的地理信息数据进行几何函数计算，大大晋升效率。

CloudCanal 中对于地理信息数据敌对兼容

表构造迁徙

在应用 PostgreSQL 作为主库，ClickHouse 作为剖析库的时候。第一个问题就是 ClickHouse 的建表，在没有 CloudCanal 工具，建表比拟苦楚，应用 CloudCanal，这个过程就会相当便当。

  • PostgreSQL 没有相似 MySQL show create table 的语句能够不便的获取到原始建表语句让咱们参照，因而须要一张表一张表的去创立。
  • ClickHouse 的表字端类型和 PostgreSQL 的字端类型并不统一，还须要理解它们做针对的映射和转换。

即使是在 PostgreSQL 和 PostgreSQL 之间进行数据同步，还须要思考一些问题

  • 带有 SRID 的 PostgreSQL 表构造迁徙

这些问题通过应用 CloudCanal 解决，它会自动识别表的字段类型并且映射到适宜的列上，这样就省了不少学习理解新数据库的工夫。

同样 CloudCanal 就像 PostgreSQL 一样对 GIS 个性反对比拟残缺，它可能精确解决带有 SRID 的 PostgreSQL 表构造。如下表。

CREATE TABLE "city"
(
    "ogc_fid"    int4 NOT NULL,
    "mssm"       varchar(16),
    "bz"         varchar(16),
    "provincen"  varchar(50),
    "provincec"  varchar(50),
    "cityn"      varchar(50),
    "cityc"      varchar(50),
    "shape_leng" float4,
    "shape_area" float4,
    "geom"       geometry(geometry,4490) -- 带有 SRID 的列
);

数据迁徙

CloudCanal 反对将用户源端数据库中的地理信息相干数据残缺迁徙到对端异构数据源，并且反对断点续传。

在地理信息数据的迁徙上，CloudCanal 做了不少工作。当源端数据库是 PostgreSQL 时。全量数据同步过程会辨认到表上的 SRID 信息，并将 PostgreSQL 应用 EWKB 格局转换为规范的 WKT 连同 SRID 一起作为最终数据。

  • 当对端是 ClickHouse 的时候咱们能够失去残缺的 GIS 地理信息数据以及对应的坐标系 SRID，在程序中能够进一步解决。
  • 当对端是 PostgreSQL 时也能够残缺的将地理信息和坐标系同步到对端。

自定义解决

在地理信息数据从源端数据库迁徙 / 同步到对端数据库过程中，通过 CloudCanal 自定义代码性能能够做一些非常灵活的加工操作。

用户能够本人实现自定义代码，在数据同步过程中针对每一条数据做一些额定的解决。比方：

  • 在解决 GIS 的利用中常常会用到求外切，失去几何图形的最大矩形区域。而后将这个矩形区域存储在一个新的字段中
  • 求 GIS 数据几何图形的中心点
  • 提前裁剪数据，将荡涤好、裁剪好的规整数据写入对端新型数据库。

长周期的实时地理信息数据同步

CloudCanal 不仅反对历史数据的迁徙同时还反对异构数据源之间的实时数据同步。实时的地理信息数据同步可能增强企业在某些业务畛域的竞争力。

在实时同步时，用户最关怀的天然是长周期实时同步的稳定性。

在理论状况中为了保障业务运行中对于实时数据同步的稳定性 CloudCanal 采纳了多种形式来实现。

  • 齐全分布式：外围组件均反对分布式部署，防止单点故障
  • 容灾主动复原：如果运行实时同步工作的机器 Crash，CloudCanal 会主动迁徙这台机器上的实时同步工作到别的可用的机器持续实时化的同步
  • 实时同步断点续传：CloudCanal 针对各种数据库源端类型都有设计专门的位点治理。当因故障产生工作重启，工作会在上一次中断的中央持续开始同步，防止数据失落。

总结

在本文最后咱们比拟简略的介绍了地理信息数据相干的背景常识，文章后半段咱们探讨了如何利用现代化的数据栈高效解决地理信息数据。

如果您感觉文章对您有帮忙，请帮忙转发分享，也期待大家多多关注和应用 CloudCanal，到 ClouGence 官网 https://www.clougence.com 即可下载体验。

参考资料

  • 北斗卫星导航系统公开服务性能标准 1.0 版
  • 习近平同尼泊尔总统班达里互致信函 独特发表珠穆朗玛峰高程
  • “奋斗者”号全海深载人潜水器顺利完成万米深潜试验
  • 北斗卫星导航系统 公开服务性能标准
  • 高精度地图（一）——天文坐标系
  • The Home of Location Technology Innovation and Collaboration
  • MYSQL 8.0 中存储 GIS 数据的正确姿态
退出移动版