[[201558]]

從應(yīng)用上來(lái)講，GPU 數(shù)據(jù)庫(kù)帶來(lái)了三大方面的進(jìn)步：加載速度、實(shí)時(shí)處理和寬表多條件查詢。它最大的革新點(diǎn)之一在于，提供了一種不依靠索引，并大幅提升速度的手段。 所以，要搞清楚 GPU 數(shù)據(jù)庫(kù)，先讓我們聊聊數(shù)據(jù)庫(kù)，尤其是數(shù)據(jù)存儲(chǔ)。

索引、分區(qū)和組合主鍵

傳統(tǒng)數(shù)據(jù)庫(kù)的存儲(chǔ)是在磁盤(pán)旋轉(zhuǎn)的碟片上。讀數(shù)據(jù)時(shí)碟片先旋轉(zhuǎn)到一定位置，磁頭再伸到相應(yīng)的扇區(qū)，稱(chēng)之為尋道，并讀取一個(gè)或多個(gè)數(shù)據(jù)塊(Block)。旋轉(zhuǎn)到位的時(shí)間和轉(zhuǎn)速有關(guān)，以 7200 轉(zhuǎn) / 秒的磁盤(pán)為例，旋轉(zhuǎn)延遲為 4.16ms。普通臺(tái)式 PC 磁盤(pán)的尋道時(shí)間為 10ms, 數(shù)據(jù)傳輸時(shí)間可忽略不計(jì)，因此，光是從扇區(qū)上讀取數(shù)據(jù)，就需要 14 毫秒左右。這是什么概念呢? 大家后面可以看到，GPU 數(shù)據(jù)庫(kù)的響應(yīng)時(shí)間常常也就幾十毫秒。

數(shù)據(jù)庫(kù)如何找到想要的記錄?最糟的辦法是掃描整個(gè)表，這就意味著要一個(gè)個(gè)的扇區(qū)地讀，直到讀到目標(biāo)記錄。每讀一個(gè)扇區(qū)用 14 毫秒的話，就洗洗睡了吧。 每個(gè)記錄都有一個(gè)所屬的扇區(qū)和該記錄在該數(shù)據(jù)塊里的位置。不同的操作系統(tǒng)和數(shù)據(jù)庫(kù)對(duì)這兩個(gè)概念有不同的名稱(chēng)，讓我們姑且稱(chēng)為 PageID 和 SlotID。如果知道每條記錄的 PageID 和 SlotID，無(wú)論運(yùn)氣好不好，讀取時(shí)間都是一個(gè)常數(shù)——直接到磁盤(pán)上的目標(biāo)塊，整塊讀出，并按 SlotID 找到該記錄在本塊里的所在位置，讀出即可。這也稱(chēng)為時(shí)間復(fù)雜度為 O(1)。

索引可以看作一張表，最重要的功能就是記錄每條記錄的 PageID 和 SlotID, 并通過(guò)一系列指針，讓人們盡可能快地找到或更新它們。

以數(shù)據(jù)庫(kù)最基本的查詢之一： SELECT...WHERE ID=123456 為例， 最有效的是哈希索引。它本質(zhì)上是一個(gè) Key-Value 表，Key 是 ID 的哈希值，對(duì)應(yīng)該 Key-Value 表里的第幾行，Value 包括一個(gè)指針，指向存儲(chǔ)該條記錄的 PageID 和 SlotID。對(duì)于 ID=123456，先用哈希函數(shù)算出哈希值，比如是 9231，那么直接去索引表的第 9231 行即可找到 PageID 和 SlotID，讀出對(duì)應(yīng)扇區(qū)的數(shù)據(jù)塊里的數(shù)據(jù)。因?yàn)樗饕ǔ７旁趦?nèi)存里，因此訪問(wèn)速度比一塊塊地從磁盤(pán)讀快得多。

真實(shí)的索引遠(yuǎn)比這個(gè)復(fù)雜，并分為哈希、B 樹(shù)，B+ 樹(shù)等不同技術(shù)，來(lái)處理等值、范圍掃描、非等值查詢等?；驹矶碱?lèi)似，將掃描磁盤(pán)的多個(gè)扇區(qū)變?yōu)閽呙枰粋€(gè)多層次的地圖， 以便逐層找到目標(biāo)記錄所在的 PageID 和 SlotID。

索引的最大壞處是多了一張或多張索引表。每增加一條記錄，不僅要將該記錄寫(xiě)到磁盤(pán)里，而且要計(jì)算哈希值、編入索引表、并調(diào)整索引里受影響的指針位置等等。將一個(gè)寫(xiě)操作變成了多個(gè)操作，更容易出錯(cuò)甚至損壞，而且延長(zhǎng)了寫(xiě)入時(shí)間，大大降低了數(shù)據(jù)加載入庫(kù)的速度。因此，大家可以看到，基于磁盤(pán)的數(shù)據(jù)庫(kù)，無(wú)論是傳統(tǒng)關(guān)系型還是現(xiàn)代的分布式 Hadoop 數(shù)據(jù)庫(kù)，都會(huì)提供多種加載方式，其中一種一定是直接寫(xiě)文件，而不寫(xiě)索引，不考慮事務(wù)，以便加快加載。 在這點(diǎn)上，GPU 數(shù)據(jù)庫(kù)很不一樣，也是其最重要的優(yōu)勢(shì)之一，后面再講。

用戶們不會(huì)那么乖，只按 ID 查，如果還需要按時(shí)間、店鋪 ID、產(chǎn)品 ID 之類(lèi)查怎么辦?最簡(jiǎn)單的辦法是建多個(gè)索引。用哪個(gè)字段查，就為哪個(gè)字段建索引。如果字段數(shù)少還行，但是如果有 10 個(gè)常用字段怎么辦? 這 10 個(gè)字段的組合就可能產(chǎn)生 1024 種索引，如果所有記錄都需要編入索引，數(shù)據(jù)量將膨脹到何種程度?

用戶行為分析的巨頭 Heap Analytics 就用這個(gè)辦法：將 Web 訪問(wèn)事件的所有屬性記錄進(jìn)一張大表，對(duì)常用字段分別建索引。其使用的 PostgreSQL 支持部分索引(partial Index)，允許按 Where 條件篩選，僅將符合 Where 條件的記錄建入索引，以便大大地減小建索引的開(kāi)銷(xiāo)和索引表的大小。據(jù)稱(chēng)，他們需要維護(hù)幾百甚至上千個(gè)這樣的索引。 好在這張大 Fact 表是張稀疏表，每種屬性的數(shù)據(jù)都不多，大量空白值，因此通過(guò) Where 條件篩選后的部分索引會(huì)大大縮小。

Hive、SQL-On-Hadoop 之類(lèi)的產(chǎn)品還會(huì)增加其他手段，比如分區(qū)。在建表時(shí)增加一個(gè)“分區(qū)”字段，通常用基數(shù)低，而用戶經(jīng)常查詢的字段，比如年月、店鋪 ID 或產(chǎn)品 ID。往數(shù)據(jù)庫(kù)里增加記錄時(shí)，同一分區(qū)的記錄盡量連續(xù)存放在磁盤(pán)的同一個(gè)或相鄰的數(shù)據(jù)塊、或分布式集群的同一個(gè) Region/Partition/Bucket/Division 里 (不同的技術(shù)對(duì)這個(gè)概念的稱(chēng)謂不同)。如果用戶經(jīng)常用這些字段查詢，或者 Group By，那么只要先找到分區(qū)，一個(gè)讀操作就可以讀出同一個(gè)年月、店鋪 ID 或產(chǎn)品 ID 的大量記錄，大大節(jié)省旋轉(zhuǎn)、尋道或分布式存儲(chǔ)系統(tǒng)尋址的開(kāi)銷(xiāo)。

對(duì)于索引問(wèn)題，惠普等老牌數(shù)據(jù)庫(kù)公司還推出了 MDAM 等技術(shù)，將分區(qū)字段放在主鍵之前，拼成多個(gè)字段的組合主鍵，建入同一個(gè) B 樹(shù)索引中，從而用一個(gè)索引達(dá)到兩個(gè)甚至更多索引的效果。 查詢時(shí)，先組合主鍵里的分區(qū)字段，對(duì)每個(gè)分區(qū)進(jìn)行并行的范圍掃描(Range Scan)?？梢韵胂螅绻葱詣e分區(qū)，一下子可以縮小一半的搜索范圍。 有興趣的同學(xué)可以讀讀 HP Labs 大牛 Goetz Graefe 的有關(guān)論文，此人對(duì)惠普大型數(shù)據(jù)庫(kù)和 Microsoft SQL Server 都有神一般的影響。 這一機(jī)制在惠普的 Nonstop SQL/MX 和 Apache Trafodion 里仍能找到。

不過(guò)組合分區(qū)也有其他問(wèn)題。如果存儲(chǔ)系統(tǒng)是鍵 - 值(Key-Value)的分布式系統(tǒng)，如 HBase，那么對(duì)于每對(duì)鍵 - 值都需要存 Key。如果 Key 是組合主鍵，包括多個(gè)字段，那么 Key 就會(huì)很長(zhǎng)，大大增加存儲(chǔ)開(kāi)銷(xiāo)。所以還需要進(jìn)行編碼和壓縮，來(lái)減小空間開(kāi)銷(xiāo)。代價(jià)是，在數(shù)據(jù)加載時(shí)，仍會(huì)有增加額外的編碼開(kāi)銷(xiāo)。

GPU 和 SIMD

表和圖像很類(lèi)似，對(duì)象都是很有規(guī)律的一個(gè)個(gè)格子。 處理起來(lái)也很類(lèi)似：可以并行地對(duì)每個(gè)格子里的數(shù)值執(zhí)行一組單向步驟的指令——即通過(guò) SIMD(Single Instruction Multiple Data)用同一組指令處理多個(gè)數(shù)據(jù)單元。加上 GPU 有多核，因此可以并行大量線程。每個(gè)線程都有對(duì)應(yīng)的核支撐，無(wú)需操作系統(tǒng)來(lái)回切換，將大大加快速度。對(duì) NVidiaK80 這樣的 GPU 設(shè)備來(lái)講，硬件并行意味著可以用 4992 顆核來(lái)支持上萬(wàn)個(gè)線程并行處理，這比操作系統(tǒng) +CPU 的超線程快多了。GPU 上的內(nèi)存也增加了不少，K80 有 24G 顯存，在 RDMA 等技術(shù)的支持下，可以通過(guò) PCI-E 總線和網(wǎng)口實(shí)現(xiàn) GPU 顯存之間的高速數(shù)據(jù)交換。 K80 顯存的 IO 總吞吐量也達(dá)到 480G/S。因此，將 GPU 用于并行計(jì)算和數(shù)據(jù)庫(kù)是水到渠成的事。用 GPU 進(jìn)行幾千萬(wàn)行的掃描通常僅需幾十毫秒。如果網(wǎng)絡(luò)速度夠快，幾十億行的掃描，返回幾億行結(jié)果，也僅需幾百毫秒。

GPU 數(shù)據(jù)庫(kù)

物聯(lián)網(wǎng)的迅猛發(fā)展，讓人們不得不調(diào)整數(shù)據(jù)平臺(tái)的設(shè)計(jì)思路和處理方式。2017 年 Gartner 發(fā)布的 Top strategic predictions for 2017 一文指出，到 2020 年，210 億只 IoT 設(shè)備對(duì)數(shù)據(jù)中心存儲(chǔ)需求增長(zhǎng)將不超過(guò) 3%。 先入庫(kù)再處理的方式不適合高速、巨量的物聯(lián)網(wǎng)數(shù)據(jù)。

和銀行或商業(yè)交易記錄相比，這些物聯(lián)網(wǎng)數(shù)據(jù)的存儲(chǔ)價(jià)值不高，因?yàn)橥瑯拥膫鞲衅髦g的個(gè)體差異很小，更接近于隨機(jī)過(guò)程，我們更關(guān)心在某個(gè)時(shí)間段內(nèi)，發(fā)生某個(gè)事件的概率，因此需要確保相應(yīng)統(tǒng)計(jì)模型的可靠，和等，而不那么關(guān)心 A 區(qū)的傳感器在二季度比去年同期多發(fā)了多少個(gè)警報(bào)，更無(wú)需考慮 A 區(qū)傳感器半年以來(lái)的購(gòu)物和存貸記錄，是否適合我行 180 天期的金茉莉理財(cái)產(chǎn)品。

在數(shù)據(jù)加載的同時(shí)進(jìn)行分析，顯得前所未有地重要。第一個(gè)坎就是要擺脫對(duì)索引的依賴(lài)。在多個(gè)數(shù)據(jù)流高速加載的情況下，無(wú)需寫(xiě)索引表所換來(lái)的性能非?？捎^。據(jù) Kinetica 的創(chuàng)立者稱(chēng)，2010 年美國(guó)陸軍情報(bào)和安全指揮中心(US Army Intelligence and Security Command) 希望處理 200 多個(gè)實(shí)時(shí)數(shù)據(jù)流，包括手機(jī)、無(wú)人機(jī)、社交網(wǎng)絡(luò)和 Web 訪問(wèn)，每小時(shí) 2 千億條記錄，為分析師和開(kāi)發(fā)者們提供接口，來(lái)結(jié)合時(shí)間和地理位置監(jiān)控危險(xiǎn)信號(hào)。 他們嘗試了 HBase、Cassandra 和 MongoDB， 但一直未能解決同樣的問(wèn)題：能支持的查詢極為有限，索引越來(lái)越多，越來(lái)越復(fù)雜，并一直需要增加硬件。得到結(jié)果的速度越來(lái)越慢，開(kāi)始是 1 個(gè)小時(shí)，隨著索引越來(lái)越復(fù)雜，逐漸需要 1 天，后來(lái)發(fā)展到一個(gè)星期。 用兩年時(shí)間，他們開(kāi)發(fā)了基于 GPU 的系統(tǒng)——用 HBase 作為永久存儲(chǔ)，用 GPU 數(shù)據(jù)庫(kù)提供實(shí)時(shí)加載、實(shí)時(shí)查詢。多個(gè)實(shí)時(shí)流可以從多個(gè) Head 節(jié)點(diǎn)，多線程加載，可處理每分鐘 14 億條。

該 GPU 數(shù)據(jù)庫(kù)以列式存儲(chǔ)，結(jié)合內(nèi)存 + 顯存，無(wú)需優(yōu)化，無(wú)需建索引。內(nèi)置可視化層、地理空間層、流處理層，并有 Hadoop 和 Spark 等接口。常見(jiàn)的使用方法是從 Kafka、Storm、Nifi 上獲取數(shù)據(jù)，高速處理，并輸出到 BI 工具如 Tableau、Qlikview 里。

他們?cè)?2017 年紐約舉行的 O'Reilly AI 大會(huì)里有個(gè)演示： 8 個(gè) GPU 設(shè)備組成的集群，每臺(tái)服務(wù)器 256G 內(nèi)存，整個(gè)集群有 244 億條記錄，共 1.7TB，其中包含 41 億條推特。

推特表的情況如下：

用戶可以在地圖上任意圈定區(qū)域，結(jié)合郵編、名稱(chēng)等篩選、關(guān)聯(lián)，一秒以內(nèi)可以從 41 億條里，返回 5.13 億條結(jié)果。 

這種城市級(jí)的區(qū)域選擇，得到 4300 多萬(wàn)條結(jié)果，需幾十毫秒。

同時(shí)，也可以復(fù)制區(qū)域形狀，拉到其他地區(qū)放大縮小范圍，用關(guān)鍵詞搜索文本內(nèi)容，也可以在幾十毫秒得到幾百條結(jié)果。

用 SQL 對(duì)這張 40 多億條記錄的大表，跑下面這條聚合查詢，72 毫秒就出結(jié)果。

SELECT count(*), sum(sentiment_vader_p),avg(sentiment_vader_p), min(sentiment_vader_p),stddev(sentiment_vader_p),var(sentiment_vader_p),sum(txtblob_p),avg(txtblob_p),stddev(txtblob_p) 
 
FROM MASTER.Twitter  

對(duì)兩張 2000 萬(wàn)條記錄的電影統(tǒng)計(jì)表關(guān)聯(lián)、排序和模糊匹配，響應(yīng)時(shí)間是 53 毫秒。既然是排序，那么 limit 100 對(duì)響應(yīng)時(shí)間的幫助應(yīng)該不大。

SELECT m.title, m.genres, avg(r.rating),count(r.rating)  
from movie m, rating r 
where r.movieID=m.movieID 
and (genres like'Action%' or genres like 'Thriller%') 
group by m.title, m.genres 
order by 4 desc 
limit 100  

總的來(lái)說(shuō)，分析型應(yīng)用涉及到的大多數(shù)數(shù)據(jù)庫(kù)操作是讀。在生產(chǎn)時(shí)間，將數(shù)據(jù)加載到顯存和內(nèi)存里，無(wú)需訪問(wèn)磁盤(pán)，因此無(wú)需依靠索引來(lái)降低訪問(wèn)扇區(qū)的開(kāi)銷(xiāo)。通過(guò)每個(gè) GPU 的幾千個(gè)核，并發(fā)上萬(wàn)個(gè)線程并行掃描全表，尤其適合幾千萬(wàn)到幾十億行的 JOIN、模糊匹配、Group By、全表掃描或聚合等等，比如七八千萬(wàn)條的大表在非主鍵字段上 JOIN，性能提升很明顯。單機(jī)處理幾千萬(wàn)行的數(shù)據(jù)也能在幾十毫秒內(nèi)返回。這樣的低成本查詢，使用起來(lái)就比 Hadoop 和傳統(tǒng)關(guān)系型數(shù)據(jù)庫(kù)靈活、高效得多。人們不僅可以更自由地選擇任意字段分析，按任意組合，一次查詢的條件更多，而且能夠?qū)Ω咚偌虞d的數(shù)據(jù)流實(shí)時(shí)處理——先處理、再落地。

同時(shí)，GPU 顯存和內(nèi)存之間的交換帶寬很高，所以即使是 TB 級(jí)數(shù)據(jù)，或者有更新、數(shù)據(jù)注入時(shí)，可以用內(nèi)存作為橋梁，實(shí)現(xiàn)磁盤(pán)—內(nèi)存—顯存緩存的三級(jí)緩存來(lái)解決。

多維交叉可視化查詢

傳統(tǒng)的 BI 只能每次看一個(gè)視圖，比如先從銷(xiāo)售，再碰碰運(yùn)氣加入庫(kù)存，但實(shí)際上有價(jià)值的結(jié)論需要多個(gè)視圖一起看，因此產(chǎn)生了多維度交互式可視化查詢，讓大家的嘗試更高效。

Tableau 無(wú)疑是這方面最成功的企業(yè)之一。這種做法的顛覆性意義在于，同一個(gè)儀表盤(pán)上同時(shí)展現(xiàn)多個(gè)視圖，反映不同的角度，比如銷(xiāo)售、庫(kù)存、客戶等等，點(diǎn)擊任何一個(gè)視圖都會(huì)對(duì)所有視圖添加同樣的篩選條件，展現(xiàn)所有角度的變化。

每次點(diǎn)擊實(shí)際上是對(duì)所有視圖加了 Where 條件。當(dāng)數(shù)據(jù)超過(guò) 1 千萬(wàn)條，用普通數(shù)據(jù)庫(kù)的響應(yīng)時(shí)間就會(huì)很慢，不再是交互式。如果視圖超過(guò) 10 個(gè)，每次互動(dòng)產(chǎn)生的查詢很多，數(shù)據(jù)庫(kù)壓力也會(huì)很大。Tableau 等 BI 工具的解決方法是將查詢結(jié)果緩存起來(lái)，和對(duì)大數(shù)據(jù)集先采樣再計(jì)算。但這種緩存的設(shè)計(jì)比較考究，也增加了更多步驟——要先查緩存，緩存里的記錄也可能未及時(shí)更新。而 GPU 數(shù)據(jù)庫(kù)的響應(yīng)速度快，每個(gè)查詢的開(kāi)銷(xiāo)低，所以即使不用緩存、不采樣，每次都發(fā)新的 Query，同樣可以達(dá)到實(shí)時(shí)的效果。

MapD 曾有一個(gè)很棒的 Demo，展示紐約市出租車(chē)的交互式分析，數(shù)據(jù)量超過(guò) 10 億條。利用 GPU 數(shù)據(jù)庫(kù)的性能，加上查詢結(jié)果在顯存里，能實(shí)現(xiàn)動(dòng)畫(huà)式的交互：用戶可以在時(shí)間軸上拉一個(gè)窗口，并拉動(dòng)該窗口，其他視圖隨之變化，請(qǐng)見(jiàn)下圖底部時(shí)間軸的淺藍(lán)色塊，從左到右移動(dòng)效果。這就超越了指標(biāo)計(jì)算，可以更好地洞察趨勢(shì)。也可以戳地址(https://www.mapd.com/blog/content/images/2017/04/taxi-ride-filters.gif)看動(dòng)圖。 

這種拉動(dòng)窗口產(chǎn)生的查詢更密集，因此仍可以借助查詢緩存，利用之前的結(jié)果來(lái)加速響應(yīng)，實(shí)現(xiàn)流暢的動(dòng)畫(huà)效果。不過(guò)這種緩存更加簡(jiǎn)單，比如將查詢結(jié)果按 Key-Value 的形式放入緩存，Key 是查詢語(yǔ)句，Value 是查詢結(jié)果。

舉個(gè)例子，如果用 X、Y 軸分別展示航班的到達(dá)延誤和滿座率，通過(guò)拉動(dòng)時(shí)間窗口，可以看出不同航空公司的這兩個(gè)指標(biāo)組成的點(diǎn)的移動(dòng)。哪些公司的差距逐漸增大?哪些在減小?

小空間，大數(shù)據(jù)

大家都知道，GPU 數(shù)據(jù)庫(kù)的顯存小，那么有沒(méi)有處理 TB 級(jí)以上的例子呢?

除了 Kinetica 宣稱(chēng)能處理 100TB 級(jí)的數(shù)據(jù)之外，Sqream 也比較擅長(zhǎng)大數(shù)據(jù)量的 GPU 應(yīng)用：其最初客戶來(lái)源于癌癥研究中心，需要處理基因排序，比如對(duì)比癌癥患者的缺陷基因序列和正常序列，需要大表之間 JOIN。每對(duì)序列有 200 多 GB，多對(duì)序列的比對(duì)就需要 TB 級(jí)的處理能力。用關(guān)系型數(shù)據(jù)庫(kù)對(duì)比 12 對(duì)序列需要 2 個(gè)月，Sqream 通過(guò) GPU 比對(duì)幾百對(duì)序列，僅用了 2 小時(shí)。

他們的另一個(gè)場(chǎng)景和 Kinetica 最初的安全監(jiān)控很相似，反映了 GPU 數(shù)據(jù)庫(kù)的另一個(gè)優(yōu)勢(shì)。

5 個(gè)無(wú)人機(jī)加一個(gè)巡邏車(chē)進(jìn)行邊境巡邏，每小時(shí)無(wú)人機(jī)總共傳輸 8TB 給巡邏車(chē)，巡邏車(chē)要及時(shí)發(fā)現(xiàn)異常以便及時(shí)準(zhǔn)備扔石頭(好吧，后面這句是我編的，如有雷同，純屬巧合)。車(chē)?yán)镒疃嗄芊乓粌膳_(tái)服務(wù)器，GPU 數(shù)據(jù)庫(kù)當(dāng)仁不讓。

同樣，無(wú)人機(jī)在人群集中的廣場(chǎng)、景點(diǎn)巡邏時(shí)，可以將視頻傳輸?shù)阶诳Х瑞^里的便衣工作人員的筆記本上，由人臉識(shí)別等視頻軟件產(chǎn)生結(jié)構(gòu)化或半結(jié)構(gòu)化的數(shù)據(jù)，并由 GPU 數(shù)據(jù)庫(kù)實(shí)時(shí)處理，來(lái)識(shí)別可疑人物或異常移動(dòng)的車(chē)輛。靈活轉(zhuǎn)移的工作地點(diǎn)和隱秘性，使得一臺(tái)帶 GPU 的筆記本比幾臺(tái)服務(wù)器更適合。

機(jī)器學(xué)習(xí)和深度分析

GPU 數(shù)據(jù)庫(kù)在機(jī)器學(xué)習(xí)和深度分析上的應(yīng)用也越來(lái)越多。對(duì)于機(jī)器學(xué)習(xí)來(lái)講，在模型上跑機(jī)器學(xué)習(xí)算法，需要用多個(gè)數(shù)據(jù)集在多個(gè)模型上計(jì)算。越快算完，可驗(yàn)證的模型就越多。 這方面的應(yīng)用有很多文章，就不再贅述。

越來(lái)越多的廠家開(kāi)始用 UDF 將人工智能、回歸、分類(lèi)、預(yù)測(cè)等現(xiàn)成的代碼集成到 GPU 上運(yùn)算，以充分利用 GPU 加速線性回歸、隨機(jī)森林、灰度提升樹(shù)(GBT)或蒙特卡羅仿真等。一般的實(shí)現(xiàn)方式是先將自己的 Java/Python/C/C++ 的函數(shù)和 library 向 GPU 數(shù)據(jù)庫(kù)注冊(cè)成 UDF 函數(shù)，然后在自己的 Python/Spark/Tensor Flow/Caffe 里訪問(wèn)數(shù)據(jù)庫(kù)，比如通過(guò) UDF 向 GPU 數(shù)據(jù)庫(kù)傳入一個(gè)表，在 GPU 上執(zhí)行 UDF，返回?cái)?shù)值結(jié)果或二進(jìn)制的表結(jié)果。

GPU 數(shù)據(jù)庫(kù)的局限

GPU 數(shù)據(jù)庫(kù)擅長(zhǎng)能夠被轉(zhuǎn)化成并行處理的任務(wù)，比如 Group By、JOIN、Aggregates、Hash。但不擅長(zhǎng)某些難以并行的，比如排序，或者先排序再處理。

同時(shí)，由于顯存有限，在處理較大數(shù)據(jù)集時(shí)，需要內(nèi)存、顯存之間的交換。數(shù)據(jù)準(zhǔn)備、分塊、各個(gè)階段 IO 訪問(wèn)和 Kernel 的同步協(xié)調(diào)等執(zhí)行細(xì)節(jié)，對(duì)開(kāi)發(fā)者的要求和代碼質(zhì)量比較高。考慮到數(shù)據(jù)的實(shí)際物理分布、并行度、對(duì) JOIN 優(yōu)化等情況，還可能涉及到數(shù)據(jù)重分配，廣播等跨 GPU、跨節(jié)點(diǎn)的交換。雖然 NVidia 的 RDMA 通過(guò)支持 GPU 和網(wǎng)卡、GPU 同伴之間基于 PCI-E 總線的高速交換，能提高數(shù)據(jù)交換速度，但仍和開(kāi)發(fā)水平關(guān)系很大。

一旦涉及到大量的寫(xiě)操作，GPU 顯存小的劣勢(shì)更明顯，需要頻繁地和內(nèi)存、磁盤(pán)之間交換。隨著計(jì)算的比例下降，IO 的比例上升，GPU 在計(jì)算上的優(yōu)勢(shì)就被 IO 上的劣勢(shì)逐漸掩蓋。同時(shí)，分析型應(yīng)用和顯存的有限，導(dǎo)致 GPU 數(shù)據(jù)庫(kù)常用列式存儲(chǔ)。因此對(duì)于一致性要求較高的場(chǎng)景，需慎用。它們一般提供最終一致性。讀寫(xiě)并行時(shí)，如果有 20 個(gè)線程訪問(wèn)，19 個(gè)讀、1 個(gè)寫(xiě)，會(huì)讓所有讀都通過(guò)，無(wú)鎖、無(wú)事務(wù)，有可能帶來(lái)臟讀等問(wèn)題。

在并發(fā)處理上，更多的是依靠高速計(jì)算能力，十幾毫秒的響應(yīng)速度結(jié)合分布式、管道、隊(duì)列、消息系統(tǒng)等來(lái)提升并發(fā)性能。而如果十幾毫秒仍然不夠快， 從 GPU SIMD 的實(shí)施方式上來(lái)講，是獨(dú)占和單向的，有的指令要等所有核都計(jì)算完，數(shù)據(jù)同步后才能進(jìn)入下個(gè)指令。 因此，如果某個(gè)核所需的數(shù)據(jù)沒(méi)準(zhǔn)備好，有可能造成其他核空等。

實(shí)際上，GPU 數(shù)據(jù)庫(kù)這個(gè)稱(chēng)謂，和其發(fā)展現(xiàn)狀來(lái)比，還有甚遠(yuǎn)的距離。“數(shù)據(jù)庫(kù)”包括很多內(nèi)容，性能僅僅是一個(gè)小部分。MySQL、PostgreSQL 等開(kāi)源數(shù)據(jù)庫(kù)的成功遠(yuǎn)遠(yuǎn)不只是“性能”或“兼容”。窗口函數(shù)、CTE 等帶來(lái)的便捷、高可用、事務(wù)、ACID、元數(shù)據(jù)管理、冷熱數(shù)據(jù)分離、混合工作流等等都是大型數(shù)據(jù)庫(kù)集幾十年、數(shù)代的開(kāi)發(fā)和應(yīng)用逐漸積累的，基于 GPU 的數(shù)據(jù)產(chǎn)品還不能全面和商業(yè)數(shù)據(jù)庫(kù)媲美。

同時(shí)，站在數(shù)據(jù)湖的角度來(lái)看，GPU 能解決某些實(shí)時(shí)流處理、查詢和加工工作。而更多的報(bào)表、ETL、數(shù)據(jù)集市、關(guān)系型數(shù)據(jù)庫(kù)遷移、混合云等工作，還是需要基于 Hadoop 等分布式數(shù)據(jù)平臺(tái)，依靠全面的 ETL、索引、分區(qū)、冷熱數(shù)據(jù)分離、冷數(shù)據(jù)轉(zhuǎn)移、清理、合并、復(fù)制等。數(shù)據(jù)治理、元數(shù)據(jù)管理、安全和權(quán)限、彈性計(jì)算等方面，幾個(gè) Hadoop 平臺(tái)廠家也有成熟、全面且可靠、好用的方案。

任重而道遠(yuǎn)，且行且珍惜!