自拍偷在线精品自拍偷,亚洲欧美中文日韩v在线观看不卡

GPU+生成式人工智能助力提升時空數(shù)據(jù)分析

譯文 精選
人工智能
通過實戰(zhàn)案例介紹,本文指出隨著基于GPU加速的數(shù)據(jù)庫技術(shù)為時間序列和空間數(shù)據(jù)帶來更好的性能和精度水平,生成式人工智能技術(shù)將使得非領(lǐng)域?qū)<乙材軌蜻M行復(fù)雜的時空數(shù)據(jù)處理。

譯者 | 朱先忠

審校 | 重樓

引言

時空數(shù)據(jù)來自手機、氣候傳感器、金融市場交易以及車輛和集裝箱中的傳感器等多種來源,是規(guī)模最大、擴展最快的數(shù)據(jù)類別。IDC估計,到2025年,聯(lián)網(wǎng)物聯(lián)網(wǎng)設(shè)備產(chǎn)生的數(shù)據(jù)總量將達到73.1 ZB,復(fù)合年增長率從2019年的18.3 ZB增長到26%。

根據(jù)《麻省理工科技評論》最近的一份報告顯示,物聯(lián)網(wǎng)數(shù)據(jù)(通常標有位置)的增長速度快于其他結(jié)構(gòu)化和半結(jié)構(gòu)化數(shù)據(jù)(見下文中的圖示)。然而,由于物聯(lián)網(wǎng)數(shù)據(jù)的復(fù)雜集成和有意義的利用帶來的挑戰(zhàn),大多數(shù)組織至今在很大程度上仍未開發(fā)物聯(lián)網(wǎng)數(shù)據(jù)。

當(dāng)前,兩項突破性技術(shù)進步的融合將為地理空間和時間序列數(shù)據(jù)分析領(lǐng)域帶來前所未有的效率和可訪問性。第一種是GPU加速的數(shù)據(jù)庫,它為時間序列和空間工作負載帶來了以前無法達到的性能和精度水平。第二種是生成人工智能,這一技術(shù)有助于消除對同時擁有GIS專業(yè)知識和高級編程敏銳性的高端人才的需求。

上述這些發(fā)展成就都是開創(chuàng)性的,它們相互交織,使復(fù)雜的空間和時間序列分析越來越普及,使越來越廣泛的數(shù)據(jù)專業(yè)人員比以往任何時候都能夠使用這些技術(shù)。在這篇文章中,們來探討這些進步將如何重塑時空數(shù)據(jù)庫的格局,并開創(chuàng)一個數(shù)據(jù)驅(qū)動的見解和創(chuàng)新的新時代。

GPU如何加速時空分析

GPU最初設(shè)計用于加速計算機圖形和渲染,最近在其他需要大規(guī)模并行計算的領(lǐng)域推動了有關(guān)創(chuàng)新,包括為當(dāng)今最強大的生成人工智能模型提供動力的神經(jīng)網(wǎng)絡(luò)。同樣,時空分析的復(fù)雜性和范圍經(jīng)常受到計算規(guī)模的限制。但是,能夠利用GPU加速技術(shù)的現(xiàn)代數(shù)據(jù)庫已經(jīng)突破了新的性能瓶頸,從而推動新的技術(shù)見解。在這里,我將重點介紹基于GPU加速的時空分析方面的兩個特定領(lǐng)域。

具有不同時間戳的時間序列流的不精確聯(lián)接

在分析不同的時間序列數(shù)據(jù)流時,時間戳很少完全對齊。即使設(shè)備依賴精確的時鐘或GPS(全球衛(wèi)星定位系統(tǒng)),傳感器也可能以不同的間隔生成讀數(shù),或提供具有不同延遲的指標?;蛘撸诠善苯灰缀凸善眻髢r的情況下,您可能會有交錯的時間戳,這些時間戳并不完全一致。

為了在任何給定時間獲得機器數(shù)據(jù)狀態(tài)的通用操作畫面,您需要加入這些不同的數(shù)據(jù)集(例如,了解路線上任何點處的車輛的實際傳感器值,或?qū)⒔鹑诮灰着c最新報價進行對賬)。與客戶數(shù)據(jù)不同,在客戶數(shù)據(jù)中,您可以使用固定的客戶ID進行連接;在這里,您需要執(zhí)行不精確的連接,以根據(jù)時間關(guān)聯(lián)不同的數(shù)據(jù)流。

我們可以利用GPU的處理能力來完成繁重的任務(wù),而不是試圖構(gòu)建復(fù)雜的數(shù)據(jù)工程管道來關(guān)聯(lián)時間序列。例如,借助于Kinetica(一個分布式的、GPU加速的數(shù)據(jù)庫),您可以利用GPU加速的ASOF聯(lián)接,該聯(lián)接允許您使用指定的間隔將一個時間序列數(shù)據(jù)集聯(lián)接到另一個數(shù)據(jù)集,以及確定應(yīng)返回該間隔內(nèi)的最小值還是最大值。

例如,在下面的場景中,交易和報價以不同的時間間隔到達。

如果我想分析蘋果公司的交易及其相應(yīng)的報價,我可以使用Kinetica的ASOF聯(lián)接來立即找到在每次蘋果交易的特定間隔內(nèi)發(fā)生的相應(yīng)報價。相應(yīng)的SQL腳本如下所示:

SELECT *
FROM trades t
LEFT JOIN quotes q
ON t.symbol = q.symbol
AND ASOF(t.time, q.timestamp, INTERVAL '0' SECOND, INTERVAL '5' SECOND, MIN)
WHERE t.symbol = 'AAPL'

這里僅使用一行SQL腳本并結(jié)合GPU的強大功能從而取代了時空數(shù)據(jù)的復(fù)雜數(shù)據(jù)工程管道的實現(xiàn)成本和處理延遲。此查詢將在交易后五秒內(nèi)為每個交易找到最接近該交易的報價。時間序列或空間數(shù)據(jù)集上的這些類型的不精確連接是幫助治理時空數(shù)據(jù)泛濫的關(guān)鍵工具。

數(shù)十億點的交互式地理可視化

通常,探索或分析時空物聯(lián)網(wǎng)數(shù)據(jù)的第一步是可視化。特別是對于地理空間數(shù)據(jù),根據(jù)參考地圖渲染數(shù)據(jù)將是對數(shù)據(jù)進行視覺檢查、覆蓋率問題檢查、數(shù)據(jù)質(zhì)量問題或其他異常情況檢查的最簡單方法。例如,與開發(fā)其他算法或流程來驗證GPS信號質(zhì)量相比,視覺掃描地圖并確認車輛的GPS軌跡實際上遵循道路網(wǎng)絡(luò)的速度要快得多。或者,如果你在幾內(nèi)亞灣的島周圍看到虛假數(shù)據(jù),你可以快速識別和隔離發(fā)送0度緯度和0度經(jīng)度的無效GPS數(shù)據(jù)源。

然而,使用傳統(tǒng)技術(shù)大規(guī)模分析大型地理空間數(shù)據(jù)集往往需要妥協(xié)。傳統(tǒng)的客戶端渲染技術(shù)通??梢蕴幚頂?shù)萬個點或地理空間特征,然后渲染會出現(xiàn)問題,良好的交互式探索體驗根本不可能存在。探索數(shù)據(jù)的子集,例如在有限的時間窗口或非常有限的地理區(qū)域,有可能會將數(shù)據(jù)量減少到更易于管理的數(shù)量。然而,一旦開始對數(shù)據(jù)進行采樣,就有可能丟棄那些顯示特定數(shù)據(jù)質(zhì)量問題、趨勢或異常的數(shù)據(jù),而這些數(shù)據(jù)本可以通過可視化分析輕松發(fā)現(xiàn)。

對航運交通中近3億個數(shù)據(jù)點的目視檢查可以快速發(fā)現(xiàn)數(shù)據(jù)質(zhì)量問題,例如非洲的異常數(shù)據(jù)或本初子午線的波段。

幸運的是,GPU恰好擅長可視化加速。例如,具有服務(wù)器端GPU渲染功能的現(xiàn)代數(shù)據(jù)庫平臺,如Kinetica,可以實現(xiàn)數(shù)百萬甚至數(shù)十億個地理空間點和特征的實時探索和可視化。這種巨大的加速使您能夠即時可視化所有地理空間數(shù)據(jù),而不會進行下采樣、聚合或降低數(shù)據(jù)保真度。即時渲染在平移和縮放操作時提供非常流暢的可視化體驗,從而非常有利于這些數(shù)據(jù)領(lǐng)域的探索和發(fā)現(xiàn)??梢赃x擇性地啟用諸如熱圖或裝箱之類的附加聚合,以便對完整的數(shù)據(jù)語料庫執(zhí)行進一步分析。

上圖中使用放大方法來分析中國東海區(qū)域的航運交通模式和船只速度。

用LLM實現(xiàn)時空分析的普及化

時空問題涉及數(shù)據(jù)中空間和時間之間的關(guān)系,通常會引起外行的直覺共鳴,因為它們反映了現(xiàn)實世界的經(jīng)驗。人們可能會想知道一件商品從下單到成功交付的過程。然而,即使對于經(jīng)驗豐富的程序員來說,將這些看似簡單的查詢轉(zhuǎn)換為函數(shù)代碼也是一項艱巨的挑戰(zhàn)。

例如,在考慮交通狀況、道路封閉和送貨窗口的同時,為送貨卡車確定最大限度地縮短行程時間的最佳路線需要復(fù)雜的算法和實時數(shù)據(jù)集成。同樣,考慮到各種影響因素,通過時間和地理信息來追蹤疾病的傳播,需要復(fù)雜的建模和分析,這甚至?xí)尳?jīng)驗豐富的數(shù)據(jù)科學(xué)家感到困惑。

這些例子強調(diào)了時空問題雖然在概念上是可訪問的,但往往隱藏著使其編碼成為一項艱巨任務(wù)的復(fù)雜性。即使是經(jīng)驗最豐富的SQL專家,也可能會對理解最佳數(shù)學(xué)運算以及相應(yīng)的SQL函數(shù)語法提出挑戰(zhàn)。

值得慶幸的是,最新一代的大型語言模型(LLM)能夠熟練地生成正確高效的代碼,包括SQL。經(jīng)過時空分析細微差別訓(xùn)練的這些模型的微調(diào)版本,例如Kinetica的SQL-GPT原生LLM,現(xiàn)在可以為一類全新的用戶來解釋這些分析領(lǐng)域。

例如,假設(shè)我想分析典型的紐約市出租車數(shù)據(jù)集,并提出與空間和時間有關(guān)的問題。首先,我將為LLM提供一些關(guān)于我要分析的表的基本上下文。在Kinetica Cloud中,我可以使用UI或基本的SQL命令來定義我的分析上下文,包括對特定表的引用。這些表的列名和定義與LLM共享,但不共享這些表中的任何數(shù)據(jù)。或者,我可以在上下文中包含其他注釋、規(guī)則或示例查詢結(jié)果,以進一步提高SQL的準確性。

一旦我設(shè)置了初始上下文,我就可以在Kinetica Cloud中使用SQL-GPT來詢問“Which were the top 5 origin neighborhoods for trips to JFK airport?前往JFK機場的前5個始發(fā)社區(qū)是哪些。經(jīng)過微調(diào)的LLM立即生成以下SQL:

--前往JFK機場的前5個始發(fā)社區(qū)是哪些?

SELECT
nta."NTAName" AS origin_neighborhood,
COUNT(*) AS trip_count
FROM
"taxi_data_historical" AS taxi
JOIN "nyct2020" AS nta
ON ST_CONTAINS(nta."geom", ST_MAKEPOINT(taxi."pickup_longitude", taxi."pickup_latitude"))
WHERE ST_CONTAINS((
 SELECT "geom"
 FROM "nyct2020"
 WHERE "NTAName" = 'John F. Kennedy International Airport'
 ),
 ST_MAKEPOINT(taxi."dropoff_longitude", taxi."dropoff_latitude"))
GROUP BY
origin_neighborhood
ORDER BY
trip_count DESC
LIMIT 5;

幾秒鐘內(nèi),經(jīng)過微調(diào)的LLM幫助我實現(xiàn)了

  • 設(shè)置SELECT語句,引用正確的目標表和列,設(shè)置JOIN并使用COUNT(*)、GROUP BY、ORDER BY和LIMIT。對于那些不太精通SQL的人來說,即使是基本的查詢構(gòu)造也是一個巨大的加速器。
  • 使用正確的空間函數(shù),如使用ST_MAKEPOINT()從緯度和經(jīng)度創(chuàng)建點,使用ST_CONTAINS()查找包含指定點的地理區(qū)域。通過幫助我選擇正確的函數(shù)和語法,LLM可以幫助那些新進入該領(lǐng)域的人開始進行空間分析。
  • 將真實世界中的參考信息集成到位置和時間。我問過“JFK airport肯尼迪機場”,但LLM能夠?qū)⑦@個參考翻譯成名為“John F. Kennedy International Airport約翰·F·肯尼迪國際機場”的規(guī)劃單元。一次節(jié)省了時間——謝謝你了,LLM!

現(xiàn)在,我運行查詢來回答我的初始問題:

同樣,如果我請求Kinetica SQL-GPT幫助我“Find the total number of people who were picked up at JFK airport by hour of the day查找一天中在肯尼迪機場接載的總?cè)藬?shù)”,它會生成以下SQL:

-- Find the total number of people who were picked up at JFK airport by hour of the day
SELECT HOUR(pickup_datetime) AS hour_of_day, SUM(passenger_count) AS total_passengers
FROM taxi_data_historical
WHERE STXY_CONTAINS((SELECT geom FROM nyct2020 WHERE NTAName = 'John F. Kennedy International Airport'), pickup_longitude, pickup_latitude)
GROUP BY hour_of_day
ORDER BY hour_of_day;

這個查詢包含了額外的復(fù)雜性,即對每輛出租車的乘客人數(shù)進行求和,并按一天中的小時對數(shù)據(jù)進行統(tǒng)計。但是LLM處理了這種復(fù)雜性,并立即生成了正確的SQL。

對于更復(fù)雜的用戶,LLM還可以進行更高級的時空處理。例如,在下一個例子中,我想分析華盛頓特區(qū)的一隊卡車,我想了解哪些卡車目前靠近一組地理圍欄(在這種情況下,是華盛頓特區(qū)著名地標周圍的緩沖區(qū))。

我可以從一個關(guān)于特定地理圍欄附近的基本問題開始,比如“How many unique trucks are currently within 1000 meters of the white house landmark?白宮地標1000米范圍內(nèi)目前有多少輛獨特的卡車?”并使用Kinetica SQL-GPT生成以下SQL:

-- How many unique trucks are currently within 1000 meters of the white house landmark?
SELECT COUNT(DISTINCT r.TRACKID)
FROM recent_locations r
JOIN dc_landmarks d ON STXY_DWITHIN(r.x, r.y, d.wkt, 1000, 1)
WHERE d.fence_label = 'white house'

但是,如果我想不斷刷新哪些卡車在我的地理圍欄附近的視圖,我可以讓LLM幫助我創(chuàng)建一個物化視圖。

Kinetica SQL-GPT和LLM能夠生成SQL來創(chuàng)建和刷新物化視圖,并從“在過去5分鐘內(nèi),哪些卡車到達華盛頓特區(qū)地標200米以內(nèi)?保留所有列并創(chuàng)建一個名為landmark_trucks的物化視圖(每10秒刷新一次以存儲結(jié)果)”這一提示開始:

-- Which trucks came within 200 meters of a landmark in Washington DC in the last 5 mins? Keep all the columns and create a materialized view called landmark_trucks that refreshes every 10 seconds to store the results.
CREATE OR REPLACE MATERIALIZED VIEW landmark_trucks REFRESH EVERY 10 SECONDS AS
SELECT *
FROM truck_locations t
JOIN dc_landmarks d ON STXY_DWITHIN(t.x, t.y, d.wkt, 200, 1)
WHERE t."TIMESTAMP" >= NOW() - INTERVAL '5' MINUTE;

為了利用不斷增長的時空數(shù)據(jù)量,企業(yè)需要對其數(shù)據(jù)平臺進行現(xiàn)代化改造,以處理分析的規(guī)模,并提供其業(yè)務(wù)所依賴的見解和優(yōu)化。幸運的是,GPU和生成人工智能的最新進展已準備好改變時空分析的世界。

總結(jié)

GPU加速的數(shù)據(jù)庫極大地簡化了時空數(shù)據(jù)的大規(guī)模處理和探索。隨著針對自然語言到SQL進行微調(diào)的大型語言模型的最新進展,時空分析技術(shù)可以在廣大組織中進一步推廣應(yīng)用,這將有助于超越GIS分析師和SQL專家的傳統(tǒng)領(lǐng)域。GPU和生成人工智能的快速創(chuàng)新必將使這類應(yīng)用成為一個令人興奮的領(lǐng)域。

本文作者Philip Darringer是Kinetica公司(http://www.kinetica.com/)的產(chǎn)品管理副總裁,負責(zé)指導(dǎo)公司時間序列和時空工作負載實時分析數(shù)據(jù)庫的開發(fā)。他在企業(yè)產(chǎn)品管理方面擁有超過15年的經(jīng)驗,專注于數(shù)據(jù)分析、機器學(xué)習(xí)和位置情報領(lǐng)域

譯者介紹

朱先忠,51CTO社區(qū)編輯,51CTO專家博客、講師,濰坊一所高校計算機教師,自由編程界老兵一枚。

原文標題:Transforming spatiotemporal data analysis with GPUs and generative AI,作者:Philip Darringer


責(zé)任編輯:華軒 來源: 51CTO
相關(guān)推薦

2024-04-02 15:37:04

2024-04-29 08:46:33

2023-08-02 18:26:31

2023-08-07 15:44:42

生成式人工智能AI

2023-05-05 14:02:59

人工智能聊天機器人

2024-01-25 14:30:08

人工智能

2024-07-30 13:34:21

2025-01-17 14:03:02

2023-06-15 15:24:28

人工智能數(shù)據(jù)中心綜合布線

2023-08-14 10:38:39

2023-11-07 10:20:22

人工智能AI

2023-08-29 11:36:49

2022-02-26 19:05:01

AI人工智能機器學(xué)習(xí)

2023-11-03 14:23:28

人工智能云技術(shù)

2023-07-26 15:52:05

2021-05-27 15:22:19

人工智能AI深度學(xué)習(xí)

2024-03-07 16:36:30

2024-04-18 16:12:10

2024-02-20 11:44:41

人工智能AI數(shù)據(jù)質(zhì)量

2023-06-07 07:02:17

點贊
收藏

51CTO技術(shù)棧公眾號