互聯(lián)汽車是指使用后端系統(tǒng)與其他車輛進(jìn)行通信的車輛,以增強(qiáng)可用性,實(shí)現(xiàn)便捷的服務(wù),并保持分布式軟件的維護(hù)和更新。
在大眾汽車公司,我們正在使用 NVIDIA 開(kāi)發(fā)互聯(lián)汽車,以解決在原生 python 和 pandas 中實(shí)現(xiàn)時(shí)存在計(jì)算效率低下的問(wèn)題,如地理空間索引和 K 近鄰。
處理駕駛和傳感器數(shù)據(jù)對(duì)于聯(lián)網(wǎng)汽車了解其環(huán)境至關(guān)重要。它使連接的車輛能夠執(zhí)行諸如停車點(diǎn)檢測(cè)、基于位置的服務(wù)、防盜、通過(guò)實(shí)時(shí)交通推薦路線、車隊(duì)管理等任務(wù)。位置信息是大多數(shù)這些用例的關(guān)鍵,需要一個(gè)快速的處理管道來(lái)支持實(shí)時(shí)服務(wù)。
全球聯(lián)網(wǎng)汽車的銷量正在迅速增長(zhǎng),而這反過(guò)來(lái)又增加了可用的數(shù)據(jù)量。根據(jù) Gartner ,平均連接車輛每年將產(chǎn)生 280 PB 的數(shù)據(jù),其中至少一天會(huì)產(chǎn)生 4 TB 的數(shù)據(jù)。研究還指出,到 2025 年,將部署約 4 。 7 億輛聯(lián)網(wǎng)車輛。
這篇博文將集中討論處理基于位置的地理空間信息和為聯(lián)網(wǎng)汽車提供必要服務(wù)所需的數(shù)據(jù)管道。
互聯(lián)汽車數(shù)據(jù)的挑戰(zhàn)
使用互聯(lián)汽車數(shù)據(jù)帶來(lái)了技術(shù)和業(yè)務(wù)挑戰(zhàn):
需要快速處理大量的流數(shù)據(jù),因?yàn)橛脩粝M@得近乎實(shí)時(shí)的體驗(yàn),以便及時(shí)做出決策。例如,如果一個(gè)用戶請(qǐng)求一個(gè)停車位,而系統(tǒng)需要 5 分鐘的響應(yīng)時(shí)間,那么這個(gè)停車位很可能在回答時(shí)就已經(jīng)被占用了。更快地處理和分析數(shù)據(jù)是克服這一挑戰(zhàn)的關(guān)鍵因素。
還有數(shù)據(jù)隱私問(wèn)題需要考慮。連接的車輛必須滿足 通用數(shù)據(jù)保護(hù)條例( GDPR ) 。簡(jiǎn)而言之, GDPR 要求在數(shù)據(jù)分析之后,不應(yīng)該有機(jī)會(huì)從分析的數(shù)據(jù)中識(shí)別單個(gè)用戶。此外,禁止存儲(chǔ)與個(gè)人用戶有關(guān)的數(shù)據(jù)(除非用戶書(shū)面同意)。匿名化可以通過(guò)屏蔽識(shí)別單個(gè)用戶的數(shù)據(jù)或者通過(guò)分組和聚合數(shù)據(jù)來(lái)滿足這些要求,這樣就不可能跟蹤用戶。為此,我們需要確保處理聯(lián)網(wǎng)車輛數(shù)據(jù)的軟件符合 GDPR 關(guān)于數(shù)據(jù)匿名化的規(guī)定,這在數(shù)據(jù)處理過(guò)程中增加了額外的計(jì)算要求。
采用數(shù)據(jù)科學(xué)方法
RAPIDS 可以解決互聯(lián)汽車的技術(shù)和業(yè)務(wù)難題。開(kāi)放源碼軟件( OSS )庫(kù)和 API 的 RAPIDS 套件使您能夠完全在 GPU 上執(zhí)行端到端的數(shù)據(jù)科學(xué)和分析管道。根據(jù) Apache 2 。 0 , RAPIDS 由 NVIDIA 孵育 許可,并基于廣泛的硬件和數(shù)據(jù)科學(xué)經(jīng)驗(yàn)。 RAPIDS 利用 NVIDIA CUDA 開(kāi)關(guān) 原語(yǔ)進(jìn)行低級(jí)計(jì)算優(yōu)化,并通過(guò)用戶友好的 Python 接口公開(kāi) GPU 并行性和高帶寬內(nèi)存速度。
在下面的部分中,我們將討論 RAPIDS (軟件)和 NVIDIA GPU s (硬件)如何使用測(cè)試數(shù)據(jù)幫助解決原型應(yīng)用程序的技術(shù)和業(yè)務(wù)挑戰(zhàn)。將評(píng)估兩種不同的方法:地理空間索引和 k- 近鄰。
通過(guò)使用 RAPIDS ,我們可以將這個(gè)管道的速度提高 100 倍。
地理空間索引簡(jiǎn)介
地理空間索引是互聯(lián)汽車領(lǐng)域許多算法的基礎(chǔ)。它是將地球的各個(gè)區(qū)域劃分成可識(shí)別的網(wǎng)格單元的過(guò)程。在查詢互聯(lián)汽車產(chǎn)生的海量數(shù)據(jù)時(shí),對(duì)搜索空間進(jìn)行修剪是一種有效的方法。
流行的方法包括 軍用網(wǎng)格參考系統(tǒng) ( MGRS )和 Uber 六邊形層次空間索引 ( Uber H3 )。
在這個(gè)數(shù)據(jù)管道示例中,我們使用 Uber H3 在空間上將記錄拆分為一組較小的子集。
以下是將記錄拆分為子集后需要滿足的條件 :
每個(gè)子集最多由 N 個(gè)記錄組成。這個(gè)“ N ”是根據(jù)計(jì)算能力限制來(lái)選擇的。對(duì)于這個(gè)實(shí)驗(yàn),我們考慮“ n ”等于 2500 個(gè)記錄。
子集由 subset _ id 表示,它是從 0 開(kāi)始的自動(dòng)遞增數(shù)字。
以下是示例輸入數(shù)據(jù),它有兩列–緯度和經(jīng)度:
表 1 :輸入數(shù)據(jù)示例。
下面是將 Uber H3 應(yīng)用于用例需要實(shí)現(xiàn)的算法
迭代 latitude 和 longitude ,并從分辨率 0 分配 hex_id 。
如果發(fā)現(xiàn)任何包含少于 2500 條記錄的 hex_id ,則從 0 開(kāi)始遞增地分配 subset_id 。
識(shí)別包含超過(guò) 2500 條記錄的 hex \ u id 。
以增量分辨率拆分前面的記錄,現(xiàn)在分辨率為 1 。
重復(fù)第 3 步和第 4 步,直到所有記錄都分配給 subset \ u id 和 hex \ u id ,或者直到分辨率達(dá)到 15 。
應(yīng)用上述算法后,將產(chǎn)生以下輸出數(shù)據(jù):
表 2 :應(yīng)用地理空間索引后的輸出數(shù)據(jù)示例。
Uber H3 實(shí)現(xiàn)的代碼片段
下面是使用 pandas 實(shí)現(xiàn) Uber H3 的代碼片段:
下面是使用pandas實(shí)現(xiàn) Uber H3 的代碼片段:
#while loop until all the records are assigned to subset_id while resolution < 16 and df["subset_id"].isnull().any(): #assignment of hex_id df['hex_id']= df.apply(lambda row: h3.geo_to_h3(row["latitude"], row["longitude"], resolution), axis = 1) df_aggreg = df.groupby(by = "hex_id").size().reset_index() df_aggreg.columns = ["hex_id", "value"] #filtering the records that are less than 2500 count hex_id = df_aggreg[df_aggreg['value']<2500]['hex_id'] #assignment of subset_id for index, value in hex_id.items(): df.loc[df['hex_id'] == value, 'subset_id'] = subset_id subset_id += 1 df_return = df_return.append(df[~df['subset_id'].isna()], ignore_index=True) df = df[df['subset_id'].isna()] resolution += 1
下面是使用PySpark實(shí)現(xiàn) Uber H3 的代碼片段:
#while loop until all the records are assigned to subset_id while resolution < 16 and (len(df.head(1)) != 0): #assignment of hex_id df = df.rdd.map(lambda x: (x["latitude"], x["longitude"], x["subset_id"],h3.geo_to_h3(x["latitude"], x["longitude"], resolution))) df = sqlContext.createDataFrame(df, schema) df_aggreg = df.groupby("hex_id").count() df_aggreg = df_aggreg.withColumnRenamed("hex_id", "hex_id") .withColumnRenamed("count", "value") #filtering the records that are less than 2500 count hex_id = df_aggreg.filter(df_aggreg.value < 2500) var_hex_id = list(hex_id.select('hex_id').toPandas()['hex_id']) for i in var_hex_id: #assignment of subset_id df = df.withColumn('subset_id',F.when(df.hex_id==i,subset_id) .otherwise(df.subset_id)).select(df.latitude, df.longitude, 'subset_id', df.hex_id) subset_id += 1 df_return = df_return.union(df.filter(df.subset_id != 0)) df = df.filter(df.subset_id == 0) resolution += 1
通過(guò)對(duì) Uber H3 模型的 pandas 實(shí)現(xiàn),我們發(fā)現(xiàn)了一個(gè)非常緩慢的執(zhí)行過(guò)程。代碼的執(zhí)行速度太慢導(dǎo)致生產(chǎn)力大大降低,因?yàn)橹荒茏龊苌俚膶?shí)驗(yàn)。具體目標(biāo)是將執(zhí)行時(shí)間縮短 10 倍。
為了加快管道的速度,我們采取了如下一步一步的方法。
第一步:簡(jiǎn)單 CPU 并行版本
這個(gè)版本的思想是為 H3 庫(kù)處理實(shí)現(xiàn)一個(gè)簡(jiǎn)單的基于多處理的內(nèi)核。處理的第二部分,即根據(jù)數(shù)據(jù)分配子集,是 pandas 庫(kù)函數(shù),它不容易并行化。
#Function to assign hex_id def minikernel(df, resolution): df['hex_id'] = np.vectorize(lambda latitude, longitude: h3.geo_to_h3(latitude, longitude, resolution))( np.array(df['latitude']), np.array(df['longitude'])) return df
#while loop until all the records are assigned to subset_id while resolution < 16 and df["subset_id"].isnull().any(): #CPU Parallelization df_chunk = np.array_split(df, n_cores) pool = Pool(n_cores) #assigning hex_id by calling the function minikernel() df_chunk_res=pool.map(partial(minikernel, resolution=resolution), df_chunk) df = pd.concat(df_chunk_res) pool.close() pool.join() df_aggreg = df.groupby(by = "hex_id").size().reset_index() df_aggreg.columns = ["hex_id", "value"] #filtering the records that are less than 2500 count hex_id = df_aggreg[df_aggreg['value']<2500]['hex_id'] for index, value in hex_id.items(): #assignment of subset_id is pandas library function #which cannot be parallelized df.loc[df['hex_id'] == value, 'subset_id'] = subset_id subset_id += 1 df_return = df_return.append(df[~df['subset_id'].isna()], ignore_index=True) df = df[df['subset_id'].isna()] resolution += 1
通過(guò)對(duì)線程池應(yīng)用簡(jiǎn)單的并行化,我們可以顯著減少代碼的第一部分( H3 庫(kù)),但第二部分( pandas 庫(kù))是完全單線程的,速度非常慢。
第二步:應(yīng)用 RAPIDS [ZBK9
這里的想法是盡可能多地使用 cuDF 中的標(biāo)準(zhǔn)特性(因此,最輕微的代碼更改)來(lái)實(shí)現(xiàn)最佳性能。由于 cuDF 現(xiàn)在在 CUDA 統(tǒng)一內(nèi)存上運(yùn)行,因此不可能簡(jiǎn)單地并行化第一部分( H3 庫(kù)),因?yàn)?cuDF 不處理 CPU 分區(qū)。代碼如下所示。注意,以下代碼在 cuDF 數(shù)據(jù)幀上運(yùn)行。
#while loop until all the records are assigned to subset_id while resolution < 16 and df["subset_id"].isnull().any(): #assignment of hex_id #df is a cuDF df['hex_id'] = np.vectorize(lambda latitude, longitude: h3.geo_to_h3(latitude, longitude, resolution)) (df['latitude'].to_array(), df['longitude'] .to_array()) df_aggreg = df.groupby('hex_id').size().reset_index() df_aggreg.columns = ["hex_id", "value"] #filtering the records that are less than 2500 count hex_id = df_aggreg[df_aggreg['value']<2500]['hex_id'] for index, value in hex_id.to_pandas().items(): #assignment of subset_id df.loc[df['hex_id'] == value, 'subset_id'] = subset_id subset_id += 1 df_return = df_return.append(df[~df['subset_id'].isna()], ignore_index=True) df = df[df['subset_id'].isna()] resolution += 1
步驟 3 :使用較大的數(shù)據(jù)執(zhí)行簡(jiǎn)單的 CPU 并行版本和 cuDF GPU 版本
在這一步中,我們將數(shù)據(jù)量增加了三倍,從 50 萬(wàn)條記錄增加到 150 萬(wàn)條記錄,并執(zhí)行一個(gè)簡(jiǎn)單的 CPU 并行版本及其等價(jià)的 cuDF GPU 版本。
第四步:再做一次實(shí)驗(yàn),復(fù)制到 pandas 和 cuDF
如步驟 2 所述, cuDF 在 CUDA 統(tǒng)一內(nèi)存上運(yùn)行,由于 cuDF 缺少 CPU 分區(qū),因此無(wú)法并行化第一部分( H3 庫(kù))。因此,我們沒(méi)有使用函數(shù)數(shù)組\ u split 。為了克服這個(gè)挑戰(zhàn),我們首先將 cuDF 轉(zhuǎn)換為 pandas 數(shù)據(jù)幀,然后應(yīng)用函數(shù)數(shù)組\ u split ,然后將分割的塊轉(zhuǎn)換回 cuDF ,并進(jìn)一步進(jìn)行 H3 庫(kù)處理。
#while loop until all the records are assigned to subset_id while resolution < 16 and df["subset_id"].isnull().any(): #copy to pandas df_temp = df.to_pandas() #CPU Parallelization df_chunk = np.array_split(df_temp, n_cores) pool = Pool(n_cores) df_chunk_res=pool.map(partial(minikernel, resolution=resolution), df_chunk) pool.close() pool.join() df_temp = pd.concat(df_chunk_res) #Back to cuDF df = cudf.DataFrame(df_temp) #assignment of hex_id df['hex_id'] = np.vectorize(lambda latitude, longitude: h3.geo_to_h3(latitude, longitude, resolution)) (df['latitude'].to_array(), df['longitude'] .to_array()) df_aggreg = df.groupby('hex_id').size().reset_index() df_aggreg.columns = ["hex_id", "value"] #filtering the records that are less than 2500 count hex_id = df_aggreg[df_aggreg['value']<2500]['hex_id'] for index, value in hex_id.to_pandas().items(): #assignment of subset_id df.loc[df['hex_id'] == value, 'subset_id'] = subset_id subset_id += 1 df_return = df_return.append(df[~df['subset_id'].isna()], ignore_index=True) df = df[df['subset_id'].isna()] resolution += 1
瀏覽所有上述方法的執(zhí)行時(shí)間圖:
圖 2 :數(shù)據(jù)大小為 50 萬(wàn)的各種方法的執(zhí)行時(shí)間。
圖 3 :數(shù)據(jù)大小為 150 萬(wàn)的各種方法的執(zhí)行時(shí)間。
加快地理空間指數(shù)計(jì)算的經(jīng)驗(yàn)教訓(xùn)
高性能: 前面的略圖得出的結(jié)論很清楚, cuDF GPU 版本提供了最佳性能。而且數(shù)據(jù)集越大,速度就越快。
代碼適應(yīng)性和易轉(zhuǎn)換性: 請(qǐng)注意,所移植的代碼并不是 GPU 加速的最佳方案。我們正在 CPU 上運(yùn)行的第三方庫(kù)( Uber H3 )上運(yùn)行比較。為了利用這個(gè)庫(kù),我們需要在每個(gè)循環(huán)上將數(shù)據(jù)從 GPU 內(nèi)存復(fù)制到 CPU 內(nèi)存,這不是最佳方法。
除此之外,還有一個(gè)子集合 id 計(jì)算,它也是以行方式進(jìn)行的,通過(guò)更改原始代碼可能會(huì)加快計(jì)算速度。但代碼仍然沒(méi)有改變,因?yàn)槲覀兊闹饕繕?biāo)之一是檢查代碼的適應(yīng)性以及庫(kù) pandas 和 cuDF 之間的輕松轉(zhuǎn)換。
可重用代碼: 正如您在前面已經(jīng)觀察到的,管道是一組標(biāo)準(zhǔn)化的函數(shù),也可以用作解決其他用例的函數(shù)。
一種 CUDA 加速 K 近鄰分類方法的研究
使用上述方案,而不是通過(guò)索引和分組的方式來(lái)測(cè)量相連車輛的密度——另一種方法是根據(jù)兩個(gè)地點(diǎn)之間的地球距離進(jìn)行地理分類。
我們選擇的分類算法是 K- 近鄰 。最近鄰方法的原理是找到距離數(shù)據(jù)點(diǎn)最近的預(yù)定義數(shù)量的數(shù)據(jù)點(diǎn)( K )。我們將比較基于 CPU 的 KNN 實(shí)現(xiàn)與相同算法的 RAPIDS GPU 加速版本。
在我們當(dāng)前的用例中,我們使用匿名流式連接的汽車數(shù)據(jù)(如前面的業(yè)務(wù)挑戰(zhàn)中所述)。在這里,使用 KNN 對(duì)數(shù)據(jù)進(jìn)行分組和聚合是匿名化的一部分。
然而,對(duì)于我們的用例,當(dāng)我們?cè)诘乩碜鴺?biāo)上分組和聚合時(shí),我們將使用 Haversine 度量,它是唯一可以對(duì)地理坐標(biāo)進(jìn)行聚類的度量。
在我們的管道中,使用 haversine 作為距離度量的 KNN 的輸入將是地理坐標(biāo)(緯度、經(jīng)度)和所需的最近數(shù)據(jù)點(diǎn)的數(shù)量。在下面的示例中,將創(chuàng)建 K = 7 。
在下面的例子中,我們展示了以元組(經(jīng)度和緯度)表示的相同數(shù)據(jù)。
輸入數(shù)據(jù)與上一個(gè)示例中顯示的元組(經(jīng)度和緯度)相同。
應(yīng)用 KNN 后,通過(guò) KNN 算法計(jì)算群集 id : 對(duì)于前兩行輸入數(shù)據(jù),集群輸出數(shù)據(jù)如下所示。為了避免混淆,我們用相應(yīng)的顏色標(biāo)記集群 id 。
表 3 :應(yīng)用 k 近鄰分類后的樣本輸出數(shù)據(jù)。
以下是使用 pandas 實(shí)現(xiàn) KNN 的代碼片段:
nbrs = NearestNeighbors(n_neighbors=7, algorithm='ball_tree', metric = "haversine").fit(coord_array_rad) distances, indices = nbrs.kneighbors(coord_array_rad) # Distance is computed in radians from haversine distances_m = earth_radius * distances # Drop KNN, which are not compliant with minimum distance compliant_distances_mask = (distances_m<KNN_MAX_DISTANCE) .all(axis = 1) compliant_indices = indices[compliant_distances_mask]
采用 KNN 作為分類算法。 KNN 的缺點(diǎn)是它的計(jì)算性能,特別是當(dāng)數(shù)據(jù)量較大時(shí)。我們的目的是最終利用 cuML 的 KNN 實(shí)現(xiàn)。
之前的實(shí)現(xiàn)在相當(dāng)小的數(shù)據(jù)集中工作,但沒(méi)有在 1 。 5 天內(nèi)完成 300 萬(wàn)條記錄的處理。所以我們阻止了它。
為了轉(zhuǎn)向 CUDA 加速的 KNN 實(shí)現(xiàn),我們必須用如下所示的等效度量來(lái)模擬 haversine 距離。
第 1 步:圍繞哈弗斯線進(jìn)行坐標(biāo)變換
在運(yùn)行此練習(xí)時(shí),在 cuML 的 KNN 實(shí)現(xiàn)中, haversine 距離度量本機(jī)不可用。因此,使用歐幾里德距離代替。盡管如此,公平地說(shuō),當(dāng)前版本的 RAPIDS KNN 已經(jīng)支持 haversine 度量。
首先,我們將坐標(biāo)轉(zhuǎn)換為以米為單位的距離,以便執(zhí)行距離度量計(jì)算。[10]這是通過(guò)名為 df _ geo ()的函數(shù)實(shí)現(xiàn)的,該函數(shù)將在下一步中使用。
歐幾里德距離的一個(gè)警告是,它不適用于地球上距離更遠(yuǎn)的坐標(biāo)。相反,它基本上會(huì)在地球表面“挖洞”,而不是在地球表面。但是,對(duì)于小于等于 100 公里的較小距離,哈弗斯距離和歐幾里德距離之間的差異最小。
步驟 2 :執(zhí)行 KNN 算法
到目前為止,我們已經(jīng)將所有坐標(biāo)轉(zhuǎn)換為東北坐標(biāo)格式,在這一步中,可以應(yīng)用實(shí)際的 KNN 算法。
我們?cè)谙旅娴脑O(shè)置中使用了 CUDA 加速 KNN 。我們注意到這個(gè)實(shí)現(xiàn)執(zhí)行得非???,絕對(duì)值得實(shí)現(xiàn)。
#defining the hyperparameters n_neighbors = 7 algorithm = "brute" metric = "euclidean" #Implementation of kNN by calling df_geo() which converts the coordinates #into Northing and Easting coordinate format nbrs = NearestNeighbors(n_neighbors=n_neighbors, algorithm=algorithm, metric=metric).fit(df_geo[['northing', 'easting']]) distances, indices = nbrs.kneighbors(df_geo[['northing', 'easting']])
步驟 3 :執(zhí)行距離掩蔽和過(guò)濾
這一部分是在 CPU 上完成的,因?yàn)樵?GPU 上沒(méi)有明顯的加速。
distances = cp.asnumpy(distances.values) indices = cp.asnumpy(indices.values)
#running on CPU KNN_MAX_DISTANCE = 10000 # meters # Drop KNN, which are not compliant with minimum distance compliant_distances_mask = (distances < KNN_MAX_DISTANCE).all(axis = 1) compliant_indices = indices[compliant_distances_mask]
我們的結(jié)果是在 naive pandas 實(shí)現(xiàn)的基礎(chǔ)上應(yīng)用到一個(gè)有 300 萬(wàn)個(gè)樣本的數(shù)據(jù)集時(shí),加速了 800 倍。
圖 4 :數(shù)據(jù)量為 300 萬(wàn)的各種方法的執(zhí)行時(shí)間。
K 近鄰聚類的經(jīng)驗(yàn)教訓(xùn)
高性能: 前面的略圖得出的結(jié)論很清楚, cuDF GPU 版本提供了最佳性能。即使數(shù)據(jù)集更大,執(zhí)行也不會(huì)像 CPU 執(zhí)行那樣花費(fèi)很長(zhǎng)時(shí)間。
比較 cuML 和 scikit 的 KNN : 基于 cuML 的實(shí)現(xiàn)速度極快。但是我們不得不多走一英里來(lái)模擬缺失的距離指標(biāo)??紤]到所取得的性能提升,做比要求更多的事情絕對(duì)值得。同時(shí), haversine 距離在 RAPIDS AI 中受支持,并且與 scikit 實(shí)現(xiàn)一樣方便。
我們利用歐幾里德距離和北向東距的方法來(lái)克服缺失的哈弗斯距離。根據(jù)我們代碼中的研究“ 在相當(dāng)長(zhǎng)的距離上——可能長(zhǎng)達(dá)幾千公里或更多,歐幾里德開(kāi)始錯(cuò)誤的計(jì)算 ”,我們將距離限制為 10 公里。通過(guò)使用北距 – 東距,我們首先需要轉(zhuǎn)換坐標(biāo)。由于整體性能更好,我們可以接受轉(zhuǎn)換坐標(biāo)所需的時(shí)間。
代碼適應(yīng)性和易轉(zhuǎn)換性: 除北距 – 東距功能外。
剩下的代碼類似于 CPU 代碼,仍然獲得了更好的性能。我們沒(méi)有更改代碼,因?yàn)槲覀兊闹饕繕?biāo)之一也是檢查代碼的適應(yīng)性以及庫(kù) pandas 和 cuDF 之間的輕松轉(zhuǎn)換。
可重用代碼: 正如您在前面已經(jīng)觀察到的, pipeline 是一組標(biāo)準(zhǔn)化的函數(shù),也可以用作解決其他用例的函數(shù)。
概括
本文總結(jié)了 RAPIDS 如何通過(guò)在兩個(gè)模型(即地理空間索引( Uber H3 )和 K 近鄰分類( KNN ))上對(duì)數(shù)據(jù)管道進(jìn)行評(píng)估,從而將數(shù)據(jù)管道的速度提高 100 倍。此外,我們分析了 NVIDIA RAPIDS AI 相對(duì)于前兩種模型在性能、代碼適應(yīng)性和可重用性等方面的優(yōu)缺點(diǎn)。我們的結(jié)論是 RAPIDS 肯定是一種流數(shù)據(jù)處理技術(shù)(連接的汽車數(shù)據(jù))。它提供了更快的數(shù)據(jù)處理的好處,這是流數(shù)據(jù)分析的關(guān)鍵因素。而且, RAPIDS 支持大量的機(jī)器學(xué)習(xí)算法。加速的 RAPIDS cuDF 和 cuML 庫(kù)的 API 與 pandas 保持相似,以實(shí)現(xiàn)簡(jiǎn)單的轉(zhuǎn)換。改造現(xiàn)有的 ML 管道并使其受益于 cuDF 和 cuML 非常容易。
何時(shí)選擇 RAPIDS 而不是標(biāo)準(zhǔn) Python 和 pandas :
當(dāng)應(yīng)用程序需要更快的數(shù)據(jù)處理時(shí)。
如果您確信該代碼在 GPU 中運(yùn)行比在 CPU 中運(yùn)行有好處。
如果推薦的算法作為 cuML 的一部分可用。
本文針對(duì)汽車工程師、數(shù)據(jù)工程師、大數(shù)據(jù)架構(gòu)師、項(xiàng)目經(jīng)理和行業(yè)顧問(wèn),他們對(duì)探索或處理數(shù)據(jù)科學(xué)的可能性以及使用 Python 分析數(shù)據(jù)感興趣。
關(guān)于作者
Chaitanya Kumar Dondapati 目前在德國(guó)慕尼黑大眾汽車數(shù)據(jù)實(shí)驗(yàn)室擔(dān)任數(shù)據(jù)科學(xué)家。他的興趣包括數(shù)據(jù)分析、大數(shù)據(jù)、可視化分析和物聯(lián)網(wǎng)。在加入大眾之前,他為思科、貝爾直升機(jī)和曼恩等多家國(guó)際客戶提供咨詢服務(wù)。
Miguel Martinez 是 NVIDIA 的高級(jí)深度學(xué)習(xí)數(shù)據(jù)科學(xué)家,他專注于 RAPIDS 和 Merlin 。此前,他曾指導(dǎo)過(guò) Udacity 人工智能納米學(xué)位的學(xué)生。他有很強(qiáng)的金融服務(wù)背景,主要專注于支付和渠道。作為一個(gè)持續(xù)而堅(jiān)定的學(xué)習(xí)者, Miguel 總是在迎接新的挑戰(zhàn)。
Dai Yang 是 NVIDIA 的高級(jí)解決方案架構(gòu)師。他負(fù)責(zé)使用 GPU 和網(wǎng)絡(luò)產(chǎn)品定制客戶優(yōu)化的解決方案,重點(diǎn)關(guān)注工業(yè)、汽車和 HPC 客戶。 Dai 積極參與 EMEA 地區(qū) DGX 解決方案的規(guī)劃、部署和培訓(xùn)。在加入 NVIDIA 之前,戴是慕尼黑工業(yè)大學(xué)的研究助理,在那里他研究了高性能計(jì)算的各個(gè)方面,并為 MPI 標(biāo)準(zhǔn)擴(kuò)展了 MPI 論壇的草案。戴是在 ISC2020 漢斯梅爾獎(jiǎng)獲獎(jiǎng)團(tuán)隊(duì)的一部分。
Adolf Hohl 是 NVIDIA EMEA automotive SA 企業(yè)團(tuán)隊(duì)的高級(jí)經(jīng)理,專注于 GPU —用于自主車輛( AV )開(kāi)發(fā)和測(cè)試的加速人工智能基礎(chǔ)設(shè)施以及企業(yè)人工智能。他的興趣在于為了 AV 的進(jìn)步和安全而利用大規(guī)模計(jì)算。阿道夫持有佛雷堡大學(xué) IT 安全博士學(xué)位。
審核編輯:郭婷
-
傳感器
+關(guān)注
關(guān)注
2564文章
52813瀏覽量
765609 -
汽車電子
+關(guān)注
關(guān)注
3037文章
8297瀏覽量
169898 -
NVIDIA
+關(guān)注
關(guān)注
14文章
5283瀏覽量
106092
發(fā)布評(píng)論請(qǐng)先 登錄
量子計(jì)算在海綿壓縮測(cè)試數(shù)據(jù)優(yōu)化中的創(chuàng)新探索

動(dòng)力電池測(cè)試中的直流負(fù)載挑戰(zhàn)與應(yīng)對(duì)策略
5G網(wǎng)絡(luò)優(yōu)化中,信令測(cè)試儀如何幫助故障排查?
如何部署OpenVINO?工具套件應(yīng)用程序?
ANACONDA——關(guān)于發(fā)布數(shù)據(jù)應(yīng)用程序的新簡(jiǎn)單方法

OTDR測(cè)試數(shù)據(jù)分析技巧
電力驅(qū)動(dòng)測(cè)試系統(tǒng)的技術(shù)原理和應(yīng)用
android手機(jī)上emulate應(yīng)用程序的方法
AWTK-WEB 快速入門(2) - JS 應(yīng)用程序

一文聊聊自動(dòng)駕駛測(cè)試技術(shù)的挑戰(zhàn)與創(chuàng)新

AWTK-WEB 快速入門(1) - C 語(yǔ)言應(yīng)用程序

中國(guó)電信完成6G天地一體化原型樣機(jī)測(cè)試
使用TPA3128d2,增益上選擇了26DB,測(cè)試數(shù)據(jù)時(shí)發(fā)現(xiàn)只有22DB是為什么?
電源模塊測(cè)試系統(tǒng)ATE的數(shù)據(jù)報(bào)告與數(shù)據(jù)分析功能

評(píng)論