[[201558]]

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

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

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

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

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

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

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

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

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

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

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

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

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

GPU 和 SIMD

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

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

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

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

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

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

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

推特表的情況如下：

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

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

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

用 SQL 對這張 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  

對兩張 2000 萬條記錄的電影統(tǒng)計表關(guān)聯(lián)、排序和模糊匹配，響應(yīng)時間是 53 毫秒。既然是排序，那么 limit 100 對響應(yīng)時間的幫助應(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  

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

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

多維交叉可視化查詢

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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