Kyligence使用Alluxio加速雲上OLAP分析

作者：史少鋒 (shaofeng@kyligence.io)，Kyligence 高級架構師

編輯：Sammi

自上世紀以來，聯機分析處理 (OLAP) 技術已被企業廣泛採用；企業運用 OLAP 分析其業務數據，生成報表，從而幫助業務人員制定商務決策。在當今的大數據時代，OLAP 越來越重要，且面臨諸多挑戰；而雲計算使這種情況更加複雜化。本文介紹了大數據智能科技公司 Kyligence 如何在雲上利用 Alluxio 提升其OLAP引擎的性能。

• 背景

Kyligence 公司 [1] 成立於 2016 年，是一家專註於大數據分析領域的科技公司。 Kyligence 的產品基於 Apache Kylin 的開源技術。

Apache Kylin [2] 是一個開源 OLAP 引擎，可為 Hadoop 上的 PB 級數據場景提供互動式分析（Apache Hadoop 是對大型數據集進行分散式存儲和處理的開源軟體框架）。Apache Kylin 使用 Hadoop 的並行計算技術，將超大數據集構建到 OLAP Cube 中,通過 ANSI-SQL 查詢介面提供亞秒級低延遲響應。

Kyligence 的旗艦產品是 Kyligence Analytics Platform (KAP)。該產品基於 Apache Kylin，並提供了多種高級企業級功能。採用 KAP 後，用戶可使用行業標準的數據倉庫和商務智能 (BI) 運維方法，訪問 Hadoop 上的商業智能功能。在此過程中，KAP 可以簡化分析，提供自助式服務，與常用 BI 工具無縫交互。所有這一切無需編程即可實現。

• 雲端面臨的挑戰

KAP 利用 Hadoop MapReduce 和 Spark 將源數據構建到 OLAP Cube 中；OLAP Cube 存儲在 KyStorage 中。KyStorage 是基於分散式文件系統的並針對OLAP場景進行優化的列式存儲引擎。在收到 SQL 查詢時，KAP 將查詢轉換成對 KyStorage 的執行計劃，並通過 Spark executor 來執行。

在本地部署的集群中，HDFS 是 Hadoop 和 Spark 最廣泛採用的文件系統。由於數據存儲在本地磁碟，且操作系統會對文件塊做緩存，因此 HDFS 的訪問性能很出色；另外，HDFS的文件副本默認為 3，提供了相當高的可靠性。

然而在雲端，HDFS 並不是最佳選擇。雲上的Hadoop集群按需創建，根據工作量指標等動態增加或減小節點數。當節點停止時，虛擬機的本地磁碟將被擦除，這樣可能導致數據丟失。在這種情況下，AWS S3 和 Azure Blob Store 等雲存儲服務，因其近乎無限的容量和大於 99.999% 的 SLA，成為最佳替代品。AWS EMR 和 Azure HDInsight 等 Hadoop 產品為這些存儲服務提供原生支持。用戶可通過 MapReduce、Spark 或定製應用進行透明訪問，就像在常用分散式文件系統上一樣。

儘管雲存儲服務的擴展性和持續性好於 HDFS，但其性能受到所租用的虛擬機網路帶寬的限制。此外，S3 等雲存儲服務不是一個真正意義上的文件系統；其元數據操作如 『list』 會比較耗時，』rename』 操作實際上是 『copy』，對於大數據場景來說難以接受。所有這些都使其整體性能差於 HDFS。

KAP 作為一個低延遲的 OLAP 引擎，其性能在很大程度上依賴於分散式文件系統的性能。在引入 Alluxio 之前，移至雲端時，用戶不得不忍受性能降級，或者切換至HDFS並在 S3 與 HDFS 之間進行備份和恢復，以在性能與持久性之間獲得平衡，這使得部署和維護變得複雜，且容易出錯。

• KAP 如何利用 Alluxio

為了克服雲端的存儲限制問題，我們決定在存儲服務上為 KyStorage 添加一個緩存層，而Alluxio很好地滿足了這個需求。

Alluxio [3] 原名 Tachyon，是世界上第一個以內存為中心的虛擬分散式存儲系統。它統一了數據訪問方式，為上層計算框架和底層存儲系統構建了橋樑。應用程序只需連接 Alluxio 即可訪問存儲在任意底層存儲系統中的數據。此外，Alluxio 以內存為中心的架構使得數據訪問速度比現有方案快幾個數量級。

在大數據生態系統中，Alluxio 介於計算框架或任務(如 Apache Spark、Apache MapReduce、Apache HBase、Apache Hive 或 Apache Flink)與各種存儲系統（如Amazon S3、Google Cloud Storage、OpenStack Swift、GlusterFS、HDFS、MaprFS、Ceph、NFS 和 Alibaba OSS）之間。Alluxio 顯著提升了大數據生態系統的性能。Alluxio 與 Hadoop 兼容。現有數據分析應用程序，如 Spark 和 MapReduce 程序，可以不修改任何代碼，直接在 Alluxio 上運行。

此外，Alluxio 提供分層存儲，不僅可以管理內存，還可管理 SSD 和 HDD，讓更大的數據集存儲在 Alluxio 上。數據在不同層之間自動進行管理，確保熱數據在更快的存儲層上。

藉助 Alluxio，KAP不需要進行代碼或架構更改。將 Alluxio 安裝在 Spark 運行的每個節點上，將 S3 存儲桶或 Azure Blob Store 映射為Alluxio的底層文件系統。然後，配置 KAP 通過 Alluxio 來讀取S3 或 Blob Store 中的 KyStorage 文件。首次載入時會有點慢，因為 Alluxio 需要將數據讀取到內存中。但此後的訪問速度會快很多，因為 Alluxio 會智能地從 Spark executor 運行的本地工作機中返回數據塊。

下面是引入 Alluxio 後的架構：

由於熱數據緩存在 Alluxio 中，從而改進了讀取 KyStorage 的性能，極大提升了KAP查詢引擎的性能和吞吐量。我們在 AWS 和 Azure 上分別進行了基準測試，所獲得的結果驗證了這一推斷。

• AWS S3 測試

測試信息：

Apache JMeter 在 KAP 上運行 SSB 查詢，並禁用查詢緩存，因此每次需要從文件系統中讀取 KyStorage。我們分別在 S3 和 Alluxio上收集查詢性能。下面是在 S3 和 Alluxio 上運行 SSB 的統計信息。

在對比所有查詢的平均查詢延遲後，我們得到以下結果：

從上圖可以看出，Alluxio 上的平均查詢延遲為 0.4 秒，在 S3 上為 1.8 秒。KAP 在 Alluxio 上的性能比在 S3 上的性能快 4 倍之多。

• Azure Blob Store 測試

為了深入了解 Alluxio 在 Windows Azure Storage Blob (WASB) 上的性能，我們進行了另一項測試。這次，我們選擇真實場景（用戶畫像分析）並添加了使用HDFS的場景，從 Web 應用程序中收集查詢樣例。在運行多次後，取其平均值。

測試信息：

樣例查詢如下：

以下是三個存儲系統的平均查詢時間。

從上圖可以看出，本地 HDFS 在 5 個場景中，有 4 個場景的性能是最佳的。Azure Blob Store 的執行時間在所有場景中是最長的。Alluxio 的性能介於 HDFS 和 Blob Store 之間，但與 HDFS 非常接近。平均而言，與直接讀取 Azure Blob Store 相比，Alluxio 可助力 KAP 提升 3 至 4 倍的性能。

• 總結

Alluxio 可以通過使用其透明的命名和掛載 API，跨不同存儲系統有效管理數據。採用 Alluxio 後，KAP 可以在雲端，在性能、成本和管理之間實現良好的平衡。

參考文獻：

[1] Kyligence

[2] Apache Kylin

[3] Alluxio

[4] SSB-Kylin

推薦閱讀：