今天介紹在混合云架構(gòu)中運行Presto Engine的內(nèi)容。將Presto工作負載從完全內(nèi)部部署環(huán)境遷移到云基礎(chǔ)架構(gòu)具有許多好處，包括減輕資源爭用并通過按需購買計算資源來降低成本。如果Presto在HDFS中存儲的數(shù)據(jù)上運行，則由于Presto的體系結(jié)構(gòu)使存儲和計算組件能夠獨立運行，因此云計算和本地存儲之間的分離是顯而易見的。在云中的Presto混合環(huán)境中，從本地環(huán)境中檢索HDFS數(shù)據(jù)的關(guān)鍵問題是兩個群集之間的網(wǎng)絡(luò)延遲。

這個關(guān)鍵的瓶頸嚴重限制了任何工作負載的性能，因為其大部分時間都花在了可能位于地理位置不同的網(wǎng)絡(luò)之間傳輸請求的數(shù)據(jù)上。結(jié)果，大多數(shù)公司將其數(shù)據(jù)復(fù)制到云環(huán)境中并維護該重復(fù)數(shù)據(jù)，也稱為Lift and Shift。有合規(guī)性和數(shù)據(jù)主權(quán)要求的公司甚至可能阻止組織將數(shù)據(jù)復(fù)制到云中。這種方法不可擴展，需要付出大量的人工才能獲得合理的結(jié)果。

本文介紹了Alluxio充當(dāng)數(shù)據(jù)編排層，以幫助有效地將數(shù)據(jù)提供給Presto的方法，而不是直接查詢遙遠的HDFS群集或?qū)?shù)據(jù)的本地化副本手動提供給云群集中的Presto。

　　具有Alluxio和Presto的混合云架構(gòu)

在以下架構(gòu)圖中，Presto和Alluxio進程都位于云群集中。就Presto而言，它正在查詢數(shù)據(jù)并將其寫入Alluxio，就好像它是位于同一位置的HDFS集群一樣。當(dāng)Alluxio收到數(shù)據(jù)請求時，最初會從遠程HDFS群集中獲取數(shù)據(jù)，但后續(xù)請求將直接從其緩存中獲得。

當(dāng)Presto發(fā)送數(shù)據(jù)以將其持久存儲到存儲中時，Alluxio會將數(shù)據(jù)異步寫入HDFS，從而使Presto工作量免于等待遠程寫入完成的麻煩。在讀取和寫入兩種情況下，除初始讀取外，Presto工作負載都能以與HDFS群集相同的網(wǎng)絡(luò)運行，即使不是更快，性能也一樣。請注意，除了部署和配置Alluxio以及在Presto和Alluxio之間建立連接之外，不需要其他配置或其他手動操作即可維護混合環(huán)境。

　　標桿績效

為了進行基準測試，我們將使用Presto作為計算框架，以對地理上分離的Hive和HDFS群集中的數(shù)據(jù)運行SQL查詢。

本節(jié)中用于實驗的混合云環(huán)境包括位于不同AWS區(qū)域的兩個Amazon EMR集群。由于兩個群集在地理位置上分散，因此群集之間存在明顯的網(wǎng)絡(luò)延遲。VPC對等用于創(chuàng)建VPC連接，以允許兩個AWS VPC之間通過全局AWS骨干網(wǎng)之間的流量，而不會出現(xiàn)帶寬瓶頸。如果使用AWS作為云提供商，則讀者可以按照白皮書中的教程來重現(xiàn)基準測試結(jié)果。

我們將行業(yè)標準TPC-DS基準中的數(shù)據(jù)和查詢用于決策支持系統(tǒng)，該系統(tǒng)可檢查大量數(shù)據(jù)并回答業(yè)務(wù)問題。

我們將TPC-DS查詢的子集分為以下幾類（根據(jù)此存儲庫中的可視化）：報告，交互式和深度分析。

使用Alluxio，我們?yōu)樗蠺PC-DS查詢收集兩個數(shù)字；用冷暖表示。

· 感冒是其中運行查詢之前的數(shù)據(jù)沒有在Alluxio存儲加載的情況下。在這種情況下，Alluxio在查詢執(zhí)行期間按需從HDFS提取數(shù)據(jù)。

· 在冷運行后，將數(shù)據(jù)加載到Alluxio存儲中的情況是熱的。后續(xù)訪問相同數(shù)據(jù)的查詢不會與HDFS通信。

借助HDFS，我們也可以收集兩個數(shù)字。本地和遠程。

· 本地是指Presto和HDFS位于同一區(qū)域的情況。此數(shù)字向我們顯示了在本地數(shù)據(jù)而不爆發(fā)到云中時在本地運行計算的性能。

· 遠程是Presto從另一個區(qū)域的存儲讀取的情況。

我們比較了Alluxio（冷和暖）和HDFS（本地和遠程）的性能?；鶞蕼y試表明，當(dāng)緩存因遠程訪問HDFS數(shù)據(jù)而受熱時，Alluxio的性能平均提高了3倍。

在此存儲庫中可用的104個查詢中，q72在遠程訪問數(shù)據(jù)時未完成，而在本地數(shù)據(jù)時花費了5個小時以上。除此之外，白皮書中的結(jié)果包括所有其余103個查詢。

下表按類別總結(jié)了結(jié)果。總體與Alluxio看到的最大改進是為Q9（7.1倍），最低是為q39a（1X -沒有區(qū)別）。

· 查詢類別：報告

· 最大改善：q27（3.1x）

· 最低改進：q43（2.7倍）

· 查詢類別：互動

· 最大改善：q73（3.9x）

· 最低改進：q98（2.2x）

· 查詢類別：深度分析

· 最大改善：q34（4.2x）

· 最低改進：q59（1.9倍）

對于具有10個節(jié)點的計算群集，從地理上分離的群集訪問數(shù)據(jù)時，貫穿所有查詢運行的峰值帶寬利用率保持在2Gbps以下。帶寬不是AWS骨干網(wǎng)的瓶頸。隨著利用率隨著計算群集的大小而擴展，當(dāng)不使用Alluxio時，較大的群集可能會遇到帶寬瓶頸，因為直接連接可用的帶寬可能會受到限制。

當(dāng)無縫緩存到本地的Alluxio群集中時，通過Alluxio可以看到的大多數(shù)性能提升都可以通過元數(shù)據(jù)和數(shù)據(jù)的延遲差異來解釋。

　　結(jié)論

混合云架構(gòu)允許將云計算資源用于數(shù)據(jù)分析，即使數(shù)據(jù)位于完全不同的網(wǎng)絡(luò)中也是如此。除了獲得顯著更好的性能外，概述的執(zhí)行計劃不需要對內(nèi)部部署基礎(chǔ)結(jié)構(gòu)進行任何重大重新配置。

由于用戶可以利用公共云的計算能力，因此這為Presto提供了更多機會，可將其用作可擴展的高性能計算框架，以使用內(nèi)部存儲的數(shù)據(jù)進行分析。

好了，關(guān)于在混合云架構(gòu)中運行Presto Engine的內(nèi)容介紹到這里就結(jié)束了，想了解更多關(guān)于云計算的信息，請繼續(xù)關(guān)注中培偉業(yè)吧。