Apache Impala (incubating) 與 Amazon Red-shift：在 AWS 上的 S3 整合、彈性、敏捷性與性價比優勢

2016 年 9 月 22 日

作者：Mostafa Mokhtar、Devadutta Ghat、Henry Robinson 和 Sailesh Mukil

原文：Cloudera Blog

根據多個面向的測量結果 (參見下列分析)，在數個常見的使用案例中，Impala 提供的雲端原生體驗優於 Redshift。

Impala2.6 在Amazon S3 上支援讀/寫作業，提供例如從 S3 直接查詢資料、運算資源彈性擴充以及無間斷的資料可攜性與彈性等雲端功能，這是其他雲端型分析資料庫所沒有的功能。隨著更多使用者想要在公有雲環境中部署與運行，Impala 讓雲端亦享受與傳統內部部署資料庫相同的優勢，即作為一個現代化的高效能分析 SQL 引擎，無論資料所在何處，皆能讓企業更加敏捷。

我們最近一篇部落格文章 (這裡和這裡) 探討唯有在AWS 上安裝 Impala 才能實現的有趣的雲端新功能和使用案例。除了這些發展以外，我們很高興與您分享 Impala 在 AWS 雲端上的功能與效能分析，並與 Amazon 本身的傳統分析資料庫 Redshift做比較。

以後提供輔助說明的詳細資料，先在這裡總結其結果：

• Impala憑藉下列功能促成了雲端型資料庫所無法實現的非常多種雲端原生型使用案例：

。直接查詢 S3 的資料

。運算資源彈性擴充

。資料可攜性與彈性

。橫跨多個檔案系統資料無?銜接，以及

。叢集短暫加速和減速

• Impala 不但能夠實現這些獨特的重要功能，而且成本效益與性價比也比針對一般用途的 Redshift 更好：Impala 的成本效益比Redshift更高 200% 而且在 S3 或 EBS 上傳輸量提高 4 至 10 倍。
• 即使 Redshift 已針對指定的固定報告測試基準預先微調過，Impala 仍表現不俗：

。在 EBS 上成本效益提高 28% 以及傳輸量增加 42%

。在大型 S3 叢集上成本效益提高 10% 以及傳輸量增加 90%

。在小型 S3 叢集上成本效益提高 8% 以及傳輸量僅少 17%

Redshift 與 Impala 的比較

Impala 是現代的 MPP 分析資料庫，專門運用儲存在開放的共享資料平台 (Apache Hadoop 的 HDFS 檔案系統、Apache Kudu 的欄位式儲存以及物件儲存庫如 S3) 上的資料。因為能夠查詢多個來源且用不同的開放格式 (Apache Parquest、Apache Avro 和文字) 儲存的資料，Impala 把資料拆解和運算，使用者不需要特別把資料移動/載入至 Impala 叢集即可查詢資料。在雲端中，這種能力尤其實用，因為您可以用 Impala 建立短暫的叢集來執行報告/分析，在完成時再把叢集關閉，或是彈性擴充運算資源來支援尖峰需求，以利節省叢集代管費用。Impala 的設計在大型資料集上執行效率高，而且可擴充至數百個節點和數百位使用者。您可以閱讀這篇部落格文章瞭解 S3 上執行Impala 的獨特使用案例。

相對的，Redshift 是採用單一龐大架構的傳統資料庫 (分別的儲存、中繼資料和運算資源緊密聯合)，它以 Amazon 向 ParAccel 收購而來的技術為基礎。Redshift 在專用的 AWS 實例上運行而且提供啟動、載入和查詢資料的介面。因此，您可以把 Redshift 想像成預先配置好要在 AWS 上運行的內部部署資料庫系統。

Redshift 本身具備緊密聯合的儲存管理程式和中繼資料儲存庫，還有一個查詢引擎，可查詢用專用資料格式儲存在其叢集上的資料。如此，Redshift 採用「傳統」的資料提取方法，先定義一個固定的模型架構，接著對資料的副本執行 ETL 作業再存入內部資料儲存庫，再提供資料查詢功能。此外，Redshift 可以在同時有數位使用者 (Redshift 建議不超過 15 個同時查詢) 而且叢集大小變動較少的資料集上執行。(Redshift 用完整的資料副本佈建新叢集而不是少量新增/移除節點。)由於這些限制，通常 Redshift 的客戶會讓叢集維持不變的資料大小全年無休運行，避免重複複製資料到新的或調整大小後的 Redshift 叢集。

下表是 Redshift 與 Impala 之間值得注意的差異：

接著我們來仔細看看測試基準。

測試基準設定

在這項分析中我們採用 TPC-DS 測試基準，使用 3 TB 的資料集並從 99 項查詢中挑選出 70 項，在不作任何修改或使用變數的情況下同時在 Redshift 和 Impala 上執行。我們想要使用更大型的資料集 (與我們在上一個測試基準所使用者相同)，但是囿於 Redshift 的資料載入時間，我們必須縮減資料大小。(注意：這個測試基準由TPC-DS 基準衍生而來，因此無法與已發表的 TPC-DS 結果直接比對。)

模型架構

Impala 方面：一般用途模型架構按照 TPC-DS 的定義，事實表格依日期欄位切割。

至於 Redshift，我們用兩套模型架構執行測試基準：

• 一般用途模型架構– 與上述 Impala 一般用途模型架構完全相符，事實表格依 *_dates_sk 欄位排序且按照 TPC-DS 的定義。Redshift 上的一般用途模型架構工作負載與探索性、自助式和/或特設的工作負載相似，與採用重複的熟知的罐頭報告之模型架構設計不同，如同下述固定報告模型架構。
• 固定報告模型架構– 包含 Redshift 特別為已知的 TPC-DS 工作負載調整並最佳化的其他模型架構。Redshift 允許管理員在模型架構上設定主鍵、連外鍵依存性、排序鍵和分配鍵。雖然這個方法協助 Redshift 在載入時用最佳方法分發資料，若您日後想要變更分配鍵或排序鍵，Redshift 必須重新整理整個表格，因此會產生停機時間。Amazon 建議設定這些鍵以達到最佳效能。

硬體組態

• Redshift 比較適合數量少、較大型和較昂貴的節點。Impala 的橫向擴充設計用在數量更多、較平價的標準雲端實例上速度更快且成本效益更高。
• 為了保證比較之直接與公平性，我們使用最佳的實例數量，確保 Redshift 和 Impala 可以使用相同的 CPU 計數。
• 測試過程中，RAM/原始資料比保持一致。

以下是硬體組態的詳細資料：

(重要事項：這些結果顯示 Redshift 使用費用最低的美國區域；在北加洲執行 Redshift 的客戶將要額外支付 33% 費用。)

在 S3 上執行Impala 擁有獨特功能，不必依存於資料而可以單獨擴充查詢引擎的運算資源，以利達到更高的傳輸量和效能。如之前所展示者，將雲端的即收即付定價、S3 整合及雲端的彈性結合起來，擴充至較大節點有助於提高性價比，因為有更大的傳輸量可以加速完成工作。因此，要測量這個傳輸量對效能的影響，我們也把在 S3 上執行 64 個節點 Impala (以及執行 32 個節點者) 納入測量，通常每小時費用是 2 倍。

結果

恢復時間

公有雲的一大優勢是即收即付模式，使用者僅支付他們所使用的資源。

如上所述，因為單一龐大的結構，Redshift 使用者無法把資料留在 S3 並按需求加速運算，而Impala 使用者透過直接查詢 S3 的功能便可以做到。另一項優勢是讓未使用的 Redshift 叢集休眠然後在需要時再恢復。

為了保證公平的同類同等比較，在此分析中我們用比較方式測量客戶把 Redshift 叢集和 Impala 叢集從休眠狀態啟動並取得首個結果要花費的成本。Redshift 必須花費其恢復時間把 S3 的快照還原，所以快照越大，便需要花更多時間才能存取一個可執行、可使用的叢集。

如上述結果所示，與 Impala 相比，Redshift 需要 15 倍更長的時間讓叢集從休眠中還原而且相較於 EBS 上的 Impala 成本增加 11 倍。換言之，將休眠中的 Impala 叢集還原只需大約 4.5 分鐘，而 Redshift 完成相同的作業卻需要超過一小時。

ETL + 單一使用者測試

在雲端的現代分析資料庫透過 ETL 程序從多個來源提取資料。在雲端最常見的使用案例是使用 Apache Hive 或 Apache Spark 針對多個來源的資料批次執行 ETL 作業，然後再寫入到 S3，由一個分析資料庫如 Impala 或 Redshift 讀取出來供報告或分析使用。

在這個測試中，從 S3 載入資料檔，接著是在 Redshift 和 Impala 上運算統計，再來是執行針對性的 TPC-DS 查詢。

從上述圖表，以相同的工作負載而言：

• 採用一般用途模型架構的 Redshift 之效能比其他選項遜色許多，差距達 122-200%。
• 採用固定報告模型架構的 Redshift 與 S3 上執行 Impala 的任一設定之成本相近，但是仍比在 EBS 上執行的 Impala 之成本高出 27%。

純粹從效能的角度出發，在 EBS 上執行的 Impala 是最快連續完成所有查詢的 (用了 32 分鐘)，而 Redshift 的一般用途模型架構則是最慢 (執行相同的查詢花了超過 5 小時)。採用固定報告模型架構的 Redshift 用了 42 分鐘，速度第二快，接著是在 S3 上執行的 64 節點 Impala 叢集，花了 44 分鐘相差不遠，還有在 S3 上執行的 32 節點 Impala 叢集，花了 80 分鐘。(我們會在下方的多使用者小節詳細探討關於效能和性價比的詳細資訊。)

如圖所示，在 Redshift 上採用特設的工作負載運行不但速度超慢而且極昂貴！

ETL + 多使用者測試

在真實世界中，會有多位使用者運用 BI 叢集同時執行多個查詢，幾乎毫無例外。在多使用者測試中，我們同時在四個查詢串中執行上述相同的查詢。在查看多使用者的結果時，請考慮兩個標準：

• 成本：從開始到結束完成指定的工作負載所需成本
• 傳輸量：在指定時間內系統能夠處理的查詢數量 (例如每分鐘查詢數)

先從成本角度切入，您可以從下圖看到，在 EBS 上執行的 Impala 之成本效益最佳，而代價最高昂的部份都屬於 Redshift：

• Redshift 一般用途是成本最高的，比 EBS 上執行的 Impala 高出 275% 而且與任一 S3 上的 Impala 叢集比較時，成本高出 200%。
•  Redshift 固定報告的成本比 EBS 上執行的 Impala 高出 28% 而且與任一 S3 上的 Impala 叢集相比，其成本高出 8 至 10%。

若論效能，下方圖表中我們測量完全運行的系統之傳輸量 (即移除資料負載和運算統計時間) 來測量最終使用者在執行時間會注意到的效能。

如您所見，這一次在 S3 上執行的 64 節點 Impala 效能表現最出色，次之是在 EBS 上執行的 Impala (上圖成本效益表現領先者)，而 Redshift 一般用途則是最低傳輸量，與 S3 上執行的 64 節點 Impala 叢集相比低了 10 倍以上，而與 EBS 上執行的 Impala 相比則是低了 7.8 倍。

Redshift 的最佳傳輸量結果 (採用 Redshift 固定報告模型架構)，較之 EBS 上執行的 Impala 或是 S3 上執行的 64 節點 Impala 叢集，均較為遜色。

• 在 EBS 上執行的 Impala，效能表現高出 42%
• 在 S3 上執行的 64 節點 Impala，效能表現高出 90%

因此，唯有Impala 才能促成之前無法使用的雲端功能和使用案例，而且以更出色的成本效益、效能與性價比達成目標！

結論

如果您打算在公有雲上部署和執行分析資料庫，而且正在考慮 Impala 和 Redshift 兩者，這些結果證明您的選擇簡單明瞭。相較於 Redshift，Impala 支援在 S3 上讀取和寫入，無論資料大小皆可擴充運算資源且沒有停機時間，加上無可比擬的資料敏捷性，為若干常見的使用案例提供更好的雲端原生體驗。Impala 不但額外提供這些的重要功能，它也用更好的性價比實現這項優勢。

Cloudera 分析資料庫解決方案一直不斷努力促進 Impala 的效能，它的最新版本，相較於之前兩個版本，執行安全工作負載的效能提高了12 倍。未來這項性價比優勢一定還會增長，也會持續改良增進雲端功能，例如支援其他公有雲物件儲存庫。

Mostafa Mokhtar 是 Cloudera 軟體工程師，在 Impala 團隊服務。

Devadutta Ghat 是 Cloudera 的資深產品經理。

Henry Robinson 是 Cloudera 的軟體工程師，也是 Apache Impala PMC 的成員。

Sailesh Mukil 是 Cloudera 的軟體工程師以及 Apache Impala PMC 的成員。