京東城市時空資料引擎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項軟著。

我們的目標是，做世界上最好用的時空資料管理和分析平臺。大家可以關注一下我們的公眾號，也可以透過二維碼訪問我的個人主頁。本次彙報的PPT，可以透過公眾號進行下載。我的彙報完了，再次感謝大家！

歡迎點選【 京東智聯雲】 ，瞭解開發者社群

更多精彩技術實踐與獨家乾貨解析

歡迎關注【京東智聯雲開發者】公眾號