京东城市时空数据引擎JUST亮相中国数据库技术大会

受疫情影响，第十一届中国数据库技术大会（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项软著。