受疫情影响，第十一届中国数据库技术大会（DTCC 2020）从原定的 5 月份，推延到了 8 月份，再推延到了 12 月份。尽管如此，仍然没有减退国人对数据库技术的激情。2020 年 12 月 21 日 -12 月 23 日，北京国际会议中心人头攒动，各大厂商争奇斗艳。在 NoSQL 技术专场，京东智能城市研究院的李瑞远博士给大家带来了《京东城市时空数据引擎 JUST 的架构设计与利用实际》的主题报告，受到了大家的宽泛关注。
李瑞远博士的个人简介：李瑞远，博士，京东城市时空数据组负责人，京东智能城市研究院研究员，京东智能城市事业部数据科学家，负责时空数据平台架构设计、时空索引与分布式相结合钻研、时空数据产品的研发、以及时空数据挖掘在城市场景的落地等工作。退出京东之前，在微软亚洲研究院城市计算组实习 / 工作 4 年。钻研趣味包含：时空数据管理与开掘、分布式计算和城市计算。在国内外高水平期刊和国内会议上发表论文 20 余篇，包含：KDD、Artificial Intelligence、ICDE、AAAI、TKDE、WWW、UbiComp、软件学报等。申请专利 20 余项。现为中国计算机学会（CCF）会员、CCF 数据库专委会通信委员、IEEE 会员。先后负责多个国内外顶级会议或期刊的论文审稿人。
JUST 简介：时空数据蕴含着丰盛的信息，可能利用于各种城市利用。但时空数据更新频率高、数据体量大、结构复杂，难以被高效存储、治理和剖析。单台机器显然无奈应答海量数据的场景，而分布式查询处理框架例如 Spark、Hadoop 等，因为不足无效的时空索引和时空剖析算法，因而难以高效地解决时空数据。京东城市时空数据引擎 JUST 采纳先进的数据建模办法、数据存储技术、分布式索引技术和剖析技术，预置了多种无效的时空开掘算法，可能帮忙人们便捷高效地治理海量时空数据。基于 JUST 间断两次取得了 ACM SIGSPATIAL 十年影响力大奖，发表了国内顶级论文 20 余篇，申请了专利 30 余项。JUST 已为多个智能城市我的项目提供反对，在新冠防疫中也施展了重要作用；在京东外部，JUST 在双十一亿万级订单和海量物流轨迹场景下失去了验证。
上面对本次演讲内容做出整顿，内容曾经取得了演讲者的确认。
各位朋友们大家好！非常感谢大家加入本次的汇报，也非常感谢大会的举办方对我的邀请。我叫李瑞远，来自于京东智能城市研究院，大家能够通过百度间接搜寻我的名字，第一个链接应该就是我。明天给大家带来一个小众但又十分广泛的数据库——京东城市时空数据引擎 JUST。说它小众，是因为大家可能没有听过时空数据库，在此我做一个调研，大家晓得有哪些厂商都在做时空数据库吗？（现场只有一两人举手）其实，一些 GIS 厂商在做时空数据库，一些互联网厂商也在做时空数据库。说它广泛，是因为它的的确确可能解决咱们身边的很多问题，与每个人的生存非亲非故。严格意义上讲，JUST 目前还不能叫时空数据库，因而咱们称之为时空数据引擎。
我的汇报将从以下四个方面进行开展。
随着 5G、IoT 技术的倒退，产生了海量的时空数据。时空数据简而言之，就是具备工夫属性和空间属性的数据。这些时空数据大体可分成三类。第一类是咱们关上手机地图看失去的地图矢量数据；第二类是卫星遥感影像的数据；第三类就是城市的感知数据，包含车上的 GPS 数据、手机跟基站进行交互的信令数据、以及咱们在社交媒体上的签到数据。大家进入咱们的会议核心时，应用北京衰弱宝扫描了二维码，其实也是一种签到数据。这些时空数据可能利用到很多城市利用中。因为工夫关系，我只举一个例子。在疫情防控中，如果某地发现了新冠确诊病例，咱们就能够通过北京衰弱宝的签到数据，找到所有在这段时间范畴内到过该地的那些人，并重点对这些人进行排查，履行保护措施，避免疫情的扩散。
时空数据具备以下四个特点：
首先，时空数据的体量十分大。大家都说，当初是大数据时代，而事实世界中，80% 的数据都与地理位置相干。这就要求咱们的时空数据引擎具备很强的扩展性。
第二，时空数据的数据结构非常复杂。这体现在两方面。1）时空数据的类型是多种多样的，像北京国际会议中心，在地图上就是以点的模式存在；路线是以线的模式存在；而一个小区，在地图上是以面的模式存在；还有以时序的模式存在，比方空气质量站点，每隔一小时就会有一个读数；甚至还有以网状的模式存在，比方一个车联网，两辆车之间很近就能造成一条边。2）时空数据是一个高维的数据，它至多有 3 维：工夫，经度和纬度。这就要求咱们的时空数据引擎可能反对各种类型的时空数据。
第三，时空数据的查问模式十分独特。不同于关系型数据库很多查问是以值作为过滤条件那样，时空数据的查问模式通常是空间范畴查问，例如，找到过来一个小时通过北京国际会议中心四周 1 公里范畴内的那些车；或者是最近邻查问，例如，找到离我最近的出租车。这就要求咱们的时空数据引擎领有非凡的索引构造。
第四，时空数据的更新频率很高。例如，GPS 点每隔 2 秒就可能产生一个新的读数，手机信令也是连续不断地产生数据。这就要求咱们的时空数据引擎可能实时接入数据，并且可能反对数据更新。
当初其实涌现了很多时空数据平台。
第一类是现有关系型数据库的扩大，例如 PostGIS、Oracle Spatial、MySQL Spatial 等，可能反对时空数据的治理和查问。但这类时空数据平台最后是面向单机版进行设计的，当数据量很大例如超过 1T 时，零碎往往就难以工作了，因而它们面临着扩展性的问题。
为解决海量数据的问题，涌现了很多分布式的平台，例如 Hadoop、Spark 以及 HBase。然而这些平台自身并没有时空索引，在没有时空索引的状况下，如果执行一个 KNN 查问，例如找到与我最近的出租车，零碎将会扫描所有的记录，计算每条记录与我的间隔，而后依照间隔排序，返回与我最近的 k 条记录，这样效率将会十分低下，面临着重大的效率问题。
于是，咱们就想，是否在这些分布式平台中构建时空索引呢？次要有三类代表。Spatial Hadoop 在 Hadoop 之上构建了时空索引，可能治理海量的时空数据。然而，大家都晓得，即便对一个 Job 来说，Hadoop 都会触发屡次的磁盘读写，导致效率比拟低下。为解决 Hadoop 的问题，Spark 尝试着将数据尽量缓存到内存中，GeoSpark 正是在 Spark 上构建了时空索引。然而理论状况中，内存资源是十分贵重的，通常状况下，我的项目可能就只有 3 台机器，要求你治理海量的时空数据，因而，GeoSpark 也会面临着扩展性的问题。另一类代表是基于 Key-Value 的分布式时空数据平台，将数据还是存储到了磁盘，并通过一些索引组件，例如 GeoMesa，对时空数据进行索引。咱们的零碎 JUST 也是属于这类的。然而，原生的 GeoMesa + NoSQL 比拟难应用，开发人员须要深刻理解它的开发手册，能力对时空数据进行治理；另一方面，GeoMesa + NoSQL 也不足一些时空剖析函数，须要开发人员本人来从头开始编写很多时空剖析函数，因而这类时空数据管理系统面临着易用性的问题。
最初一类零碎是对时空数据进行可视化。当初有很多前端组件，例如 Leaflet 和 Mapbox，可能将时空数据在地图上进行展现；还有很多后端组件，例如 GeoServer，可能公布一些 GIS 服务。然而对时空数据的可视化，不仅仅是说要展现数据自身，还要展现数据的深层含意，这就要求与底层的时空剖析联动起来。例如，当咱们有 2000 多辆车，咱们首先须要实时接入每辆车的轨迹数据，而后通过地图匹配技术确定每辆车在哪条路线上，当某条路线上有很多数据时，可能还须要主动地进行聚合，否则前端非常容易造成卡顿。现有的 GIS 可视化平台不足与底层算法进行联动的性能，因而会面临着剖析渲染的问题。
为了解决上述问题，咱们提出了京东城市时空数据引擎 JUST，JUST 正是英文名字 JD Urban Spatio-Temporal Data Engine 各单词的首字母缩写。JUST 提供了一个集时空数据存储、治理、开掘、可是剖析、服务提供等一体化解决方案。图中展现了 JUST 的根本框架，最上面是 JUST-DB，能够了解为数据库，它对时空数据进行建模、存储、索引，以高效反对查问；JUST-DM 中封装了很多时空数据挖掘的算法；JUST-TS 对时序数据进行剖析可视化；JUST-GIS 对 GIS 数据进行剖析可视化；左边的工作治理模块，对立治理 JUST 的工作，包含实时工作和定时工作；为了更好地对外提供服务，咱们还有 JUST-Service 模块；最左边是部署运维监控模块，保障咱们零碎的稳固运行。与后面所说的现有的时空数据平台的四点有余对应，JUST 平台具备扩展性强、效率高、易用性好、剖析渲染快等特点。接下来，我将具体介绍咱们是如何实现的。
后面提到，时空数据结构非常复杂，品种十分繁多，如果咱们对每种时空数据独自构建一张表，采纳独立的存储分析方法，这将造成咱们的设计老本十分大，保护也十分艰难。为此，咱们将按时空数据之间是否有关系将时空数据分成点数据和网数据；进一步，对于点数据和网数据，依照工夫、空间的动静、动态个性划分成三类数据，因而共划分成了 2×3= 6 种数据类型，所有的时空数据都能够用其中的一种进行建模。咱们对每种时空数据，设计了最佳的索引构造，封装了齐备的剖析开掘算法，这大大地升高了咱们对时空数据的治理老本。这体现了 JUST 对时空数据品种的扩展性强方面。
另一方面，JUST 原生应用了多种分布式框架，这里列出了几个重要的框架，例如：咱们采纳 HBase 作为底层的存储引擎，Spark 作为执行引擎，GeoMesa 作为索引工具。
这是咱们 JUST-DB 的技术框架图，由图可知，咱们还用到了很多其余的分布式组件，并且把它们有机地整合在了一起（注：标记有问号的模块是布局中的模块）。采纳了分布式组件，可能让 JUST 反对海量的时空数据，扩展性很强。
咱们还为时空数据设计了新的存储模式。以轨迹数据为例，后面提到，咱们应用 HBase 作为底层存储，HBase 是一种 Key-Value 的数据库。传统应用 Key-Value 数据库存储轨迹的办法是，每个 GPS 点存储为一条记录，一条轨迹由很多 GPS 点组成，从状态上看，轨迹是竖着存储的，咱们称这种存储形式为垂直存储。垂直存储形式有几个不好的中央：首先，每个 GPS 点存储为一条记录，记录的数目与 GPS 点的个数雷同，会造成数据的条目数十分多；其次，轨迹的 GPS 点分散了存储，难以对轨迹进行压缩，最终造成空间的占用会很大，从而导致查问的效率变慢；第三，对于每条记录而言，一条记录并没有示意轨迹的残缺信息，这不利于起初的轨迹查问和剖析，例如咱们想要查问类似轨迹，须要思考整条轨迹的信息，而非只是一个 GPS 点。为了解决这三个问题，咱们提出了一种新的轨迹存储计划，咱们称为程度存储计划。如左边表所示，咱们首先对轨迹进行分段，失去很多子轨迹，而后将每条子轨迹的所有 GPS 点存储在 Key-Value 数据库中的一个网格中。这样做的益处包含：首先，记录的条目数不再与 GPS 点的数目间接相干，而是与子轨迹的数据雷同，大大的缩小了数据条目数；其次，一条子轨迹的 GPS 点寄存在了一起，便于咱们对数据进行压缩，缩小数据的存储空间；第三，每条记录蕴含了残缺的轨迹信息，这就方面咱们对轨迹的剖析和查问。这里，咱们须要留神的是，在 Key-Value 数据库中，索引是指对键的设计，而非关系型数据库中相似于 B + 树等构造。咱们采纳了空间换工夫的策略，每张逻辑表在底层存储了多张物理表，每张物理表的值雷同，但键不一样，以高效反对不同类型的查问。此外，键至于以后的记录无关，而与其余的记录无关，也就是说，当轨迹进行插入时，咱们无需批改现有的记录，可能高效反对轨迹的插入更新。
留神有一列叫 Signature，咱们称之为轨迹签名。通常状况下，咱们是用轨迹的最小突围盒子（也就是 MBR）来示意轨迹的地位信息的。但这会造成一些问题。如图所示，轨迹其实穿过了它的最小突围盒子的很小的一部分，也就是说，最小突围盒子其实不能残缺的示意其地位信息。为了解决这个问题，咱们对最小突围盒子进一步均匀划分成 n×n 的网格，同时对应于一个 n×n 的二进制序列。当轨迹中至多有一个 GPS 点落在了其中的网格中，那么对应的二进制位设为 1，否则设为 0。这样，咱们就可能更加准确地示意轨迹的地位信息。更准确的地位信息也为咱们提供了更多的查问优化空间。
总而言之，咱们为轨迹设计的新的存储模式，空间占用更少，可能更好地反对各种时空查问，而且效率更高。
此外，咱们还为时空数据设计了新的时空索引构造。后面提到，咱们采纳的是 NoSQL 的 Key-Value 数据库。Key-Value 数据库只能存储一维的索引，然而咱们的时空数据至多有三维的属性：经度，纬度，工夫。这就须要将三维的信息转化到一维。在 GeoMesa 中，采纳的是空间填充曲线，其实也就是 GeoHash。假如咱们有一个纬度 40.78 和经度 -73.97。对于纬度而言，其取值范畴为 -90 到 90，咱们采纳一个相似于二分查找的策略，当在搜寻空间的右边时，咱们失去一个 0，在搜寻空间左边时，咱们失去一个 1，直到达到一个特定的层级，咱们就进行，这样，40.78 就转化成了一个二进制序列：101。同样，咱们对经度 -73.97 执行相似的操作，失去另一个二进制序列：010。咱们再将这两个二进制序列穿插编码，这样就将一个二维的信息转化到了一位。如果有工夫维度怎么办呢？因为工夫是有限缩短的，咱们首先将工夫划分成了多个工夫区间，咱们能够称之为工夫桶，例如 1 天。对于若在每个桶内的工夫，咱们采纳一个同样的编码策略，例如 10 点钟，咱们再 0 到 24 小时中，一直进行二分查找，失去一个序列 011。最初，将工夫、纬度、经度三个二进制编码进行穿插，失去一个一维的二进制编码。如果咱们想要找到 1 点到 2 点间通过一个 1 公里乘以 1 公里区间范畴内的 GPS 点轨迹，咱们很有可能会失去一个这样的键的范畴，而后将这个键的范畴去 Key-Value 数据库中扫描。咱们留神到，这个键的范畴是十分大的，笼罩了大多数的数据。究其原因，咱们发现，时间尺度与空间尺度是不一样的。在这个例子中，1 小时的跨度，绝对于 1 年（这里假如工夫桶长度为 1 年）来说的比例，远远大于 1 公里乘以 1 公里范畴绝对于地球表面积的比例，这会造成空间过滤成果生效！
为了解决这个问题，咱们提出了一些新的索引形式，咱们不再对工夫、空间对立编码，而是先对工夫进行分桶，在每个桶外面，独自对空间进行编码。查问时，咱们首先找到那些对应的工夫区域，而后在每个工夫区域中，生成一个空间编码范畴。通过这样的改变，咱们能够将 30 秒以上的时空范畴查问放慢到 5 秒以内。
后面提到，咱们应用 Spark 作为咱们的执行引擎，传统应用 Spark 的形式为，客户端向服务器发动申请，而后服务端向 Yarn 集群发动资源申请，Yarn 集群接管到资源申请后，会经验申请 Resource Manager、启动 APP Master、申请 Container、启动 Executor、散发工作等一系列过程，才会创立一个 SparkContext，解决用户的查问。这里咱们留神到，申请资源是十分耗时的。为了解决这个问题，咱们 JUST 当时在 Yarn 集群上创立了两个 SparkContext，并用 SparkJobServer 进行治理。当用户发动申请时，咱们间接抉择其中一个 SparkContext 来解决。应用两个 SparkContext 是为了保证系统的高可用，当其中一个 SparkContext 解体时，另一个 SparkContext 可能及时地响应用户的申请。总之，咱们在线多活的 SparkContext 形式，可能缩小资源的申请工夫，进一步放慢查问效率，同时还可能进步零碎的稳定性。
咱们采纳实在的轨迹数据集做了大量试验。下面两张图是对于存储性能的比照，比照办法就是纵向的轨迹存储办法，由图可知，对于 136GB 的原始轨迹数据，咱们仅花了 30GB 的存储空间，绝对于纵向存储办法，咱们的空间利用率晋升了 85%，存储索引的效率晋升了超过 7 倍。上面两张图是对于轨迹空间范畴查问和 KNN 查问的比照试验，比照办法也是业界十分先进的两款基于 Spark 的轨迹管理系统，因为 Spark 尽量会把数据存储在内存中，在咱们的试验环境下（5 台机器），他们的效率远远低于咱们的办法，留神到，当轨迹数据大于 100GB 时，比照办法间接解体了，然而咱们的办法依然可能很好地反对。这充沛表明了，咱们的零碎效率高，扩展性强！咱们的论文也被国内数据库顶级会议 ICDE 2020 胜利接管，大家感兴趣能够搜寻浏览。
后面次要介绍咱们 JUST 为扩展性强、效率高作的致力。为了让 JUST 更加易用，咱们封装了很多开箱即用的时空数据挖掘算法。包含：轨迹数据挖掘算法，路网数据挖掘算法，以及其余数据挖掘算法。目前咱们依然在一直地欠缺更多的算法。所有这些算法，咱们裸露了很多参数接口，开发人员能够依据不同的业务需要指定不同的参数。
另一个为易用性做的致力是，咱们提供了一个便捷的交互界面和交互方式。当初不同的开发人员应用的开发语言可能不一样，例如，做后端服务开发的共事可能应用 Java 进行开发，做数据分析的共事可能应用 Python 进行开发，但所有这些共事的普通话，就是 SQL。JUST 提供了 SQL 的交互方式，可能缩小大家的学习老本。此外，SQL 为咱们定义好了对立的输入输出格局，这样也不便开发人员自由组合咱们的性能，例如是先对轨迹进行过滤，再对轨迹进行分段，还是先对轨迹进行分段，再对轨迹进行过滤，都能够由开发人员自在指定，这进步了咱们零碎的灵活性。咱们的指标就是，咱们所有的操作，包含数据查问、数据定义、数据处理、数据分析，都能够用一句简略的 SQL 语句进行实现。咱们本人实现了一套残缺的 SQL 优化器，可能实现过滤、投影等谓词下推、常量的计算，还能对查问进行重写。为了让开发人员可能像应用 MySQL 数据那样应用咱们的 JUST，咱们还实现了一个合乎 JDBC 规范的 DB Driver。这极大地提高了咱们零碎的易用性。咱们零碎的论文，也被往年数据库顶级会议 ICDE 2020 胜利接管。
咱们发现，目前为内部提供 JUST 服务时，后端开发人员大多数只是转发前端的申请到 JUST-DB 中，然而须要他们独自部署一个后端服务，同时还要思考鉴权、限流、缓存、日志等性能，造成后端开发工程师工作量极大，而且容易出错，保护老本很高。为了缩小后端的开发工作量，咱们 JUST-Service 模块，提供了配置化的 API 服务，用户只须要在零碎中配置一些参数，即可对外提供 API 服务接口，真正实现了零代码量。同时，JUST-Service 模块还提供了对立鉴权、流量限度、主动缓存、日志监控等性能，无需后端开发工程师再独自开发。这些进一步提高了 JUST 零碎的易用性。
对时空数据的治理，绕不开对时空数据的可视化剖析。传统的 GIS 引擎提供了地图可视化能力。但传统的 GIS 引擎次要面向的是动态为主、动静为辅的空间数据，例如，路网和 POI 数据，个别都是依照季度或者半年度进行更新，数据量也不是十分大，个别就是几百 G。当初曾经进入了 5G 和 IoT 时代，分分钟就会产生上 TB 的数据，传统的 GIS 引擎首先难以高效地接入这些数据，其次可视化成果也有余。如图所示，当咱们的数据点超过 5000 时，应用 Leaflet 技术进行前端渲染，就会造成显著的卡顿，甚至有可能造成浏览器的解体。此外，现有的 GIS 引擎难以跟底层的剖析算法进行联动，而咱们对数据的可视化，并不是简略的有什么数据就展现什么数据，而是心愿可能通过展现出数据背地的含意。
为此，咱们提供了一个 JUST-GIS 模块，次要面向的是动静为主、动态为辅的时空数据，借助于底层的 JUST-DB 模块，可能实时疾速地接入海量的时空数据；借助于 JUST-DM 模块，咱们可能与一些剖析算法进行联动。咱们也实现了一些分布式时空数据的编码、压缩策略，可能放慢渲染成果。两头的图展现的是应用咱们 JUST-GIS 引擎，对 16 万个城市部件的展现成果，能够看到，咱们的引擎可能丝滑地放大、放大、拖动地图。左边的图是一个理论案例，咱们实时接入了城市中的车辆 GPS 轨迹数据，对轨迹数据进行地图匹配操作，剖析出每条路线的速度和车流量信息。同时，咱们也对 GPS 点实时聚类，缩小前端的渲染压力。
这是咱们的 JUST-GIS 的基本功能框架，两头根底服务和应用服务是 JUST-GIS-Server，封装了各种 GIS 剖析性能，可能公布 GIS 服务；JUST-Studio 和 JUST-GIS GL JS 是前端展现模块和 SDK 包。
这是咱们的 JUST-Studio 用户界面。它可能对地图上的所有因素进行可视化编辑，比方一条路显示的色彩、粗细。通过 JUST-Studio，用户能够自定义本人的地图款式。将来，JUST-Studio 将会成为所有 JUST 能力的可视化输入窗口，用户甚至不要写 SQL 语句了，通过它可能间接调用咱们底层的能力，所见即所得地生成下层的解决方案。
接下来，咱们介绍几个基于 JUST 的理论落地利用案例。
受疫情影响，咱们中国数据库技术大会，从往年的 5 月份推延到了 8 月份，起初又推延到了 12 月份。通过咱们政府部门的不懈努力，咱们国内的疫情终于根本失去了管制，咱们当初才可能在这里欢聚一堂。然而当初国外的疫情依然不容乐观。在疫苗进去之前，早发现依然是防控疫情最无效的伎俩。传统伎俩来发现密接人群，次要是依附人的回顾和线下人工排查，这种办法十分慢，容易出错，也会漏掉很多密接接触人群。而一旦潜在感染者晚一天被发现，他将会感化更多的人。咱们必须采纳新的办法来疾速找到那些与确诊病例密切接触的人。人的轨迹信息可能反映人与人之间的接触信息，因而，咱们能够通过对轨迹数据进行剖析，来疾速找到那些潜在的易感人群。左边是咱们的零碎框架，咱们的零碎部署在了多个部门，实时接入了多种时空数据，应用咱们预置的多种时空解决算法，构建了无效的时空索引，以高效反对关联人查问剖析。在疫情最重大的前 20 天，咱们的零碎帮忙北京市找到了 500 多名高危密切接触者，帮忙宿迁市找到了全市范畴内四分之一的新冠肺炎确诊人员，在全国范畴内帮忙广州、南京、成都等 18 个省市做了高危人群态势剖析，可能从海量的轨迹数据中秒级挖掘出易感人群。相干的论文曾经发表在了 ArXiv 上，大家感兴趣的话能够下载浏览。
第二个例子是 JUST 助力危化品监管。大家可能还记得，在往年的 6 月 13 日，浙江温岭产生了一场重大的危化品爆炸事变，造成了 20 多人的死亡，170 多人的受伤。因而，危化品的监管事关人民的生命财产平安，受到了政府部门的极大关注。咱们 JUST 目前在危化品监管上次要做了两件事件：1）危化品车辆是否依照了报备的路线行驶？因为如果危化品车辆驶入了居民区，会造成重大的平安威逼；2）是否存在非法的化工厂？比方，有些居民可能会将本人的民房腾出来，用来存储一些化工用品，咱们称之为“黑化工”，另外，一些不符合要求的化工厂，被政府勒令关停后，还可能偷偷进行生产。对危化品的监管是十分艰难的，以南通为例，危化品监管波及到 6 个环节，7 个因素，须要 9 个不同的政府部门协同，12 个软件系统的联动，而南通共有 2000 多家危化品企业，3000 多辆危化品车辆，1000 多艘船舶，一线的危化品监管人员只有 20 多人，如果只是通过人工进行排查，是十分艰难的。咱们 JUST 部署到了南通，很好地解决了上述两个问题。咱们的零碎实时接入了危化品车辆的轨迹数据。针对第一个问题，当某辆危化品车辆偏离了原来报备的路线，咱们的零碎会实时拉响警报；同时，疾速剖析出这辆危化品车辆在以后交通状况下将来 15 分钟内可能达到的区域范畴，联合路网信息，举荐交警部门设置路障的地位，对该车辆进行拦挡，避免其驶入居民区，对社会造成平安威逼。针对第二个问题，咱们对危化品车辆的 GPS 点轨迹信息进行剖析，找到它们常常停留的地点，再联合 POI 散布信息，如果发现某些停留的地点四周没有危化品工厂，或者是曾经关停的危化品工厂，那么这些停留的中央很有可能存在非法化工厂。咱们把这些地位举荐给监管部门，他们再在实地进行核查。此外，咱们还能够通过危化品的行驶门路和停留地点，剖析出一些危险较高的区域，通知居民不要去那些危险较高的区域，也揭示政府部门要特地关注那些危险较高的区域。
这是咱们在南通部署的危化品全流程治理平台，左边的视频展现的是，通过咱们的零碎找到了一个“黑化工”企业实在案例。咱们的零碎极大地缩小了委办局工作人员的地勤排查工作量，进步了他们的人效。上线几个月的试运行期间，咱们的零碎疾速地检测到了危化品车辆异样行驶行为 410 项，精准地匹配守法小化工 64 家。
最初一个案例是利用 JUST 的能力复原小区路网。当初所有的地图厂商，他们主路上的路网数据都比拟全，因为主路上的信息采集能够通过汽车较容易地采集，然而他们对于小区外部的路线数据往往是不全的，因为有些小区不容许内部的车辆进入，光靠人工采集十分耗时耗力。然而，小区外部的路网数据对于快递、外卖场景来说是十分重要的，它可能更好地帮忙系统对快递员和外卖小哥进行调度。咱们京东有好几万的快递小哥，他们的脚印遍布了中国的大街小巷，而每个快递员手上都有一个 PDA 手持设施，每 2 秒产生一个 GPS 点。鲁迅真的说过，世界上本没有路，走的人多了，也便成了路。于是乎，咱们利用快递小哥的 GPS 轨迹点信息，复原出小区外部的细粒度路网，以及每条路上是否可能开车，还是走路，进而推断每条路线上的通行工夫。
这是咱们零碎的根本框架。JUST 平台接入海量快递员的轨迹信息以及粗粒度的路网信息，而后对轨迹信息进行去噪、分段和地图匹配，提供高效的时空查问给下层模型。咱们训练了一些深度学习模型，可能很好地修复小区内的路网。相干工作也被国内顶级人工智能会议 AAAI 胜利接管，大家感兴趣的话能够去看一下。
咱们的零碎还在更多的智能城市我的项目中胜利落地，包含：雄安新区块数据平台、江苏园博园智慧园博我的项目、南通雪亮工程项目、广汉国家农业产业园我的项目、战疫金盾我的项目、南通市域治理现代化我的项目等，大家能够看到，咱们的战疫金盾受到了央视 1 台的新闻报道。将来，JUST 将会在更多的我的项目中落地，帮忙国家解决难题，帮忙社会发明价值。
最初介绍的是基于咱们 JUST，所发明的学术成绩。
咱们始终要求本人做“顶天立地”的事件，除了真真切切地解决理论问题，还踊跃积淀理论知识。过来不到 3 年的工夫，咱们 JUST 有十余项技术通过了国内顶级会议或者期刊的评审，咱们 JUST 也创始了历史，是世界上首次间断两年取得国内时空数据畛域十年影响力大奖的团队。到目前为止，咱们为 25 个省市公安局提供了技术服务，并收到了他们的感谢信。基于 JUST，咱们提交了 30 余项发明专利，并取得了公安部的权威认证。截止到目前，咱们通过了 6 项软著。
咱们的指标是，做世界上最好用的时空数据管理和剖析平台。大家能够关注一下咱们的公众号，也能够通过二维码拜访我的个人主页。本次汇报的 PPT，能够通过公众号进行下载。我的汇报完了，再次感激大家！
欢送点击 【京东智联云】，理解开发者社区
更多精彩技术实际与独家干货解析
欢送关注【京东智联云开发者】公众号