如何使用 JuiceFS 在雲上優化 Kylin 4.0 的存儲性能?

2020-12-11 趣味科技

Apache Kylin 4.0 採用 Spark 作為構建引擎以及 Parquet 作為存儲,讓雲上部署和伸縮變得更容易,然而使用雲上的對象存儲相較於使用本地磁碟的 HDFS,可能存在部分兼容性和性能問題。面對這樣的問題,今天為大家帶來 JuiceFS 的優化方案。Kylin 4.0 的強大查詢引擎加上 JuiceFS 高效的本地緩存,就能實現兼容性和性能的雙贏!想了解更多詳情,快看這篇 Kylin 和 Juicedata 聯合出品的實用好文吧!

什麼是 Apache Kylin?

Apache Kylin 是一個為超大規模數據設計的、開源的、分布式的分析引擎,提供 Hadoop/Spark 之上的 SQL 查詢接口及多維在線分析(OLAP)能力,最初由 eBay 開發並貢獻至 Apache 軟體基金會,面對海量數據,Kylin 也能實現亞秒級的查詢響應。

【Apache Kylin 架構圖】

作為一個超高性能的查詢引擎,Kylin 可以下接各種數據源,如 Hive、Kafka,上接各種 BI 系統,比如 Tableau、Superset,還提供 JDBC/ODBC/REST API 等供各種應用集成。自開源以來,Kylin 已經得到大量使用,例如美團、小米、58 同城、貝殼找房、華為、汽車之家、攜程、同程、Vivo、雅虎日本、OLX Group 等,每日訪問量從幾萬到上千萬不等,大部分查詢能夠在 1-3 秒內完成。

如果你的產品/業務方找到你,說需要在幾十億甚至上百上千億的記錄上做靈活匯總查詢,響應要快,並發要高,同時資源佔用要少;為了支持應用開發,它還要完整支持 SQL 語法並且能夠無縫集成 BI,那麼 Apache Kylin 就是你的不二選擇。

Kylin 的核心思想是預計算,將數據按照指定的維度和指標,預先計算出所有可能的查詢結果(也就是 Cube,多維立方體),利用空間換時間來加速查詢模式固定的 OLAP 查詢。每一種維度組合稱之為 Cuboid,所有 Cuboid 的集合是一個 Cube。其中由所有維度組成的 Cuboid 稱為 Base Cuboid,其它的 Cuboid 都可以從 Base Cuboid 二次聚合出來。在查詢時,Kylin 會自動選擇滿足條件的最合適的 Cuboid,相比於從用戶的原始表進行計算,從 Cuboid 取數據進行計算能極大的降低掃描的數據量和計算量。

【一個四維 Cube 示例】

Kylin 從誕生之初選擇了 HBase 作為存儲引擎,基本滿足查詢性能的要求;然而基於 HBase 方案存在一系列痛點,例如 HBase 運維複雜、查詢節點存在單點問題、HBase 並非純列式存儲 IO 效率不高等。Apache Kylin v4 採用 Parquet + Spark 的組合,不再使用 HBase,使得計算和存儲相分離,是一次重大架構升級,更加適應雲原生的技術趨勢。

Kylin on Parquet 在雲上面臨的挑戰

相比以前,基於新一代的 Kylin 4,用戶可以在雲上更加快速簡單地部署高性能、低 TCO 的的數據分析服務。計算和存儲的分離,以及架構複雜性的降低,都使得 Kylin 成為雲上數據分析的最佳選擇之一。但是在雲上基於對象存儲抽象而來的文件系統和傳統的 HDFS 的巨大差異,帶來了一系列需要關注的問題,例如數據本地性、對象存儲 API 調用頻次限制、數據移動操作的一致性難以保證等,給 Kylin 構建和查詢帶來了一些穩定性和性能方面的挑戰。關於如何緩解乃至達到原生 HDFS 的優秀性能體驗,我們可以看到一些成功的解決方案,JuiceFS 就是其中之一。

什麼是 JuiceFS?

JuiceFS 是面向雲原生環境設計的分布式文件系統,完全兼容 POSIX 和 HDFS,適用於大數據、機器學習訓練、Kubernetes 共享存儲、海量數據歸檔管理場景。支持全球所有公有雲服務商,並提供全託管服務,客戶無需投入任何運維力量,即刻擁有一個彈性伸縮,並可擴展至 100PB 容量的文件系統。

在下面的這張架構圖中可以看出,JuiceFS 已經支持各種公有雲的對象存儲產品,同時也支持了開源對象存儲,如 Ceph、MinIO、Swift 等。在 Linux 和 macOS 上提供 FUSE 客戶端,在 Windows 系統上也提供原生客戶端,都可以將 JuiceFS 的文件系統掛載到系統中,使用體驗和本地盤一模一樣。在 Hadoop 環境中提供 Java SDK,使用體驗和 HDFS 一樣。JuiceFS 的元數據服務在所有公有雲上都部署了全託管服務,客戶不用自己維護任何服務,學習和使用門檻極低。

【JuiceFS 架構圖】

為什麼 Kylin 和 JuiceFS 要一起使用?

如果客戶在公有雲上使用 Kylin,並且希望將數據存儲在對象存儲上,會遇到兩個問題:

首要問題是兼容性,Kylin 默認支持 HDFS 和 Amazon S3,其他的公有雲也都提供了 「S3 兼容」 的對象存儲,但是在實際的測試中我們發現,目前除了 AWS 和 Azure,其他公有雲的對象存儲存在不兼容的情況,比如我們在阿里雲上基於 OSS 運行 Kylin,無論是基於阿里雲 EMR 和 CDH 自建集群,都會在 Cube 構建階段失敗。

第二個問題是性能,從用戶角度看在大數據場景下由 HDFS 換成對象存儲,能感受到的是性能下降。造成性能下降的原因有幾個:

1、網絡開銷增加:用 HDFS 做存儲有 data locality 特性,換成對象存儲後數據傳輸全部要經過網絡,會增加一定的開銷,導致性能下降;

2、元數據性能下降:在 Cube 構建過程中有大量文件元數據操作,尤其是 Listing 和 Rename,這兩個操作在對象存儲上的性能相比 HDFS 是很差的,會導致整個 job 的時間消耗增加,導致性能下降;

3、讀放大帶來的性能下降:當 Kylin 的數據換成 Parquet 文件格式後,數據查詢時,往往不需要讀出完整的 Parquet 文件,僅需要讀取 header 或 footer,這需要存儲系統提供良好的隨機讀能力,這恰恰是對象存儲的短板,所以會造成讀放大,增加了整個查詢任務的 I/O,導致性能下降。

JuiceFS 在大數據場景中可以徹底解決兼容性和性能問題,下面說說是怎麼做到的。

首先說兼容性,JuiceFS 的元數據服務提供一個 Java SDK,它的作用和 HDFS 的 Java SDK 是等價的,實現了 HDFS 所有文件接口 API 的 Interface,在行為上保證和 HDFS 一致,只要是支持 HDFS 的計算引擎都可以使用 JuiceFS,不會有任何兼容性問題。而且,JuiceFS 支持全球所有的公有雲服務,提供一致的體驗,用戶完全不用再關心不同雲廠商對象存儲的差異性。

其次說性能,解釋一下 JuiceFS 如何解決上面三個方面帶來的性能下降:

1、使用 JuiceFS 的計算集群也是存儲計算分離架構,同樣失去了 HDFS 的 data locality 特性,但是 JuiceFS 在客戶端上提供了數據緩存能力,所有從 JuiceFS 讀出來的數據會自動緩存到客戶端所在節點(虛擬機或容器都可以)的本地存儲上,下次再訪問這份數據,就會直接從本地存儲中讀取,不再經過網絡。在大數據的查詢分析場景中,數據通常是有熱點的,在 JuiceFS 緩存的支持下,可以明顯提升性能(見下文測試結果)。您可能還會關心緩存的管理、過期、一致性問題,JuiceFS 有一套完整的處理機制,值得單獨一篇文章講講,本文不做展開。

2、元數據性能,JuiceFS 有自己獨立的元數據服務,Listing、Rename 操作都由 JuiceFS 元數據響應,性能方面比對象存儲快幾十倍,相比 HDFS 也提升了 50% 以上,具體可以參看 JuiceFS的測試用例。

3、JuiceFS 的緩存能夠有效地降低隨機讀的延遲並減少讀放大,在基於 Parquet 和 ORC 數據格式的查詢分析場景有非常明顯的性能優勢。

綜上,JuiceFS 可以獲得與 HDFS 相當的性能表現,同時對 Hadoop 生態的產品提供完美的兼容性支持。更重要的一點是,無論客戶使用哪家公有雲,都可以使用 JuiceFS,獲得一致的體驗。

性能比較

上面解釋了 Kylin on Parquet 和 JuiceFS 一起使用能獲得的收益,下面來看一下性能測試的結果。

前文提到基於 OSS 做 Cube 構建出現兼容性問題,無法正確構建 Cube。但是我們把 JuiceFS 上構建好的 Cube 數據拷貝到 OSS 上執行 Query 是可以的,所以我們基於 TPC-H 10GB 大小的數據集,測試了其中的 Query1 至 Query22,在總的執行時間上 JuiceFS 比 OSS 快了 38%。

JuiceFS 使用 70,423ms

OSS 使用 113,670ms

下表給出詳細的測試環境配置和所有測試 Query 執行時間:

機器配置

在阿里雲上使用 CDH 5.16 搭建集群,詳細配置和軟體版本如下:

所有測試查詢執行時間

總結

Kylin 4.0 引入計算和存儲分離的架構,使得 Kylin 在雲上的部署和伸縮變得更加容易,然而使用雲上的對象存儲相較於使用本地磁碟的 HDFS ,一方面存在對接開發以及兼容性問題,另一方面性能會有所下降。使用 JuiceFS 搭配 Kylin,在所有公有雲上都無需特殊適配,即可在 EMR 或者自建 Hadoop 集群中使用雲存儲服務進行大數據計算。JuiceFS 讓你的集群實現存儲計算分離架構的同時,通過高效的本地緩存減少每次網絡 IO 帶來的開銷,在基於 Parquet 格式的查詢分析場景中,對於隨機讀可以有效降低延遲,並減少讀放大,獲得跟 HDFS 接近的性能。在我們的測試場景中,使用 JuiceFS 相比於直接使用對象存儲性能提升了 38%。

如果你打算在公有雲上使用 Kylin 來完成數據分析需求,存儲使用 JuiceFS 配合對象存儲,能在兼容性和性能上雙贏。

相關焦點

  • 雲端共享文件系統 JuiceFS 在 2021 年選擇開源
    開源地址:www.github.com/juicedata/juicefsJuiceFS 是什麼JuiceFS是基於Redis和對象存儲(例如Amazon S3)構建的開源POSIX文件系統,針對雲本機環境進行了設計和優化。通過使用廣泛採用的Redis和S3作為持久性存儲,JuiceFS可以用作無狀態中間件,以使許多應用程式輕鬆共享數據。
  • Kylin Cube構建原理+調優
    , location]、[item, supplier]、[location, supplier]3種;三維度(3D)的組合也有4種;最後還有零維度(0D)和四維度(4D)各有一種,總共16種。Kylin Cube構建優化使用衍生維度(derived dimension)衍生維度用於在有效維度內將維度表上的非主鍵維度排除掉,並使用維度表的主鍵(其實是事實表上相應的外鍵)來替代它們。
  • Apache Kylin 4.0.0-alpha 發布,開源分布式分析引擎
    Apache Kylin 4.0.0-alpha 發布了。
  • Kylin入門|Kylin on Parquet 介紹和快速上手
    本文主要包括以下幾方面的內容:首先會給大家介紹架構設計,然後說明一下我們為什麼會去做 Kylin on Parquet,接下來會介紹一下全新的構建和查詢引擎以及相比較於 Kylin 3.0 的性能表現,最後有一個現場演示 Demo,給大家介紹一下產品的使用和代碼調試方法。
  • Kylin的RESTful API使用
    註:ADMIN:KYLIN使用Base64編碼後結果為:QURNSU46S1lMSU4=返回結果:{"userDetails":{"password":null,"username":"ADMIN","authorities":[{"authority":"ROLE_ADMIN"},{"authority":"ROLE_ANALYST
  • 企業上雲的極速存儲挑戰,華為雲全新極速IO雲硬碟性能評測
    在測試中,至頂網評測實驗室還是使用FIO測試工具並設置文件塊大小為1MB、8JOB、8隊排的方式對華為雲硬碟的帶寬進行評測。FIO的測試結果比較有趣,只能對一個JOB的最大、最小、平均帶寬進行統計,也就是說上面表格中的平均帶寬要乘以8,才會與雲硬碟實際的傳輸帶寬能力相接近,因此只能做為一個參考,而華為雲極速IO雲硬碟的實際隨機讀寫帶寬均達到了4000MiB/s以上,其帶寬傳輸性能比對比測試的華為雲超高IO雲硬碟提升了10倍以上。具體性能可參見下面在測試過程中的實際帶寬截圖。
  • Apache Kylin 2.4.0 發布,支持 Kafka 與 Hive 表 join
    Apache Kylin 2.4.0 發布了,Apache Kylin 是一個開源的分布式的 OLAP 分析引擎,來自 eBay
  • Mysql innodb 存儲引擎的性能優化
    一個給某個存儲引擎寫的應用程式可能在其它存儲引擎下表現良好。2.4. 每個存儲引擎都有特定的優化方式,所以它們只對特定的設計模式有用。2.5. 我們覆蓋所有對於InnoDB存儲引擎的做何不做。3. 使用事務3.1. InnoDB默認就是使用事務,甚至你不知道如何使用。
  • Apache Kylin v3.0.0-alpha 正式發布
    Apache Kylin v3.0.0-alpha 正式發布!歡迎大家下載使用。
  • 聽雲應用性能管理大講堂 APP性能優化專場乾貨大放送
    4月18日,聽雲舉辦的第二期《聽雲應用性能管理大講堂——APP性能優化專場》在IC咖啡如約登場,有接近200名的現場觀眾以及超過300人同時觀看線上直播,分享來自聽雲、騰訊雲、藝龍、唱吧幾位高級工程師、研發總監與架構師的技術乾貨。
  • etcd 的性能怎麼樣?需要優化嗎?
    原來的實現方式是遍歷內部引 BTree 使用的內部鎖粒度比較粗,這個鎖很大程度上影響了 etcd 的性能,新的優化減少了這一部分的影響,降低了延遲;針對於lease 規模使用的優化:優化了 lease revoke 和過期失效的算法,將原來遍歷失效 list 時間複雜度從 O(n) 降為 O(logn),解決了 lease 規模化使用的問題;最後是針對於
  • 華為雲CTO張宇昕首次解密:從毫秒進入微秒時代的華為雲存儲為何越...
    那麼圍繞雲計算「最後一公裡」瓶頸,華為雲存儲如何實現微秒實時處理?又如何通過AI來實現數據利用越來越快。至頂網採訪了華為雲CTO張宇昕。張宇昕分享了華為雲解決數據實時處理難題的黑科技。張宇昕表示,首先,為了實現這「最後一公裡」的百微秒級突破,平均時延達4毫秒的機械硬碟(7200轉)成為了第一個被優化的對象。
  • Kylin、Druid、ClickHouse核心技術對比
    01Kylin數據模型Kylin的數據模型本質上是將二維表(Hive表)轉換為Cube,然後將Cube存儲到HBase表中,也就是兩次轉換。04Druid索引結構Druid索引結構使用自定義的數據結構,整體上它是一種列式存儲結構,每個列獨立一個邏輯文件(實際上是一個物理文件,在物理文件內部標記了每個列的
  • 如何回答性能優化的問題,才能打動阿里面試官?
    對應用進行性能優化,是一個系統性的工程,對工程師的技術廣度和技術深度都有所要求。一個簡單的應用,它不僅包含了應用代碼本身,還和容器(虛擬機)、作業系統、存儲、網絡、文件系統等緊密相關,線上應用一旦出現了性能問題,需要我們從多方面去考慮。
  • 海量挑戰:騰訊雲ES可用性及性能優化實踐
    這樣 SLA 就難以保障,達不到 4 個 9 的要求,質量團隊經常面臨系統崩潰之後用戶問題得不到及時跟進和解決的困擾。 (2)性能 第二個問題在於性能。疫情爆發之後,峰值系統寫入量接近 300w/s,這個量是非常大的。由此造成了系統數據同步延遲比較高,大量數據堆積在裡面長時間得不到消費。
  • 解放I/O性能 12Gb/s SAS引領存儲新時代
    帶動存儲I/O進化 雙倍帶寬打破存儲性能瓶頸  隨著PCIe 3.0成為伺服器與存儲系統控制器的主流總線,後端的SAS接口規格,也必須跟著升級到12Gb SAS,才能充分發揮PCIe 3.0的傳輸率潛力。
  • 性能優化之PHP優化
    性能優化之PHP優化(一):PHP結構1.字符串此函數執行起來相當快,因為它不做任何計算,只返回在zval結構(C的內置數據結構,用於存儲PHP變量)中存儲的已知字符串長度。但是,由於strlen()是函數,多多少少會有些慢,因為函數調用會經過諸多步驟,如字母小寫化、哈希查找,會跟隨被調用的函數一起執行。
  • 微秒級數據處理,華為雲存儲的「快」節奏
    所以整個數據處理IO從進來到出去,能實現50μs -100μs的穩定時延。而關於存儲介質時延問題,華為雲採用Flash替代掉了HDD,將介質時延從原本四毫秒左右縮短到幾十微秒的級別。當然這並不是簡單的替換就可以的。俗話說好馬配好鞍,有了高速Flash介質,還需要對軟體進行優化才能讓介質性能得到最大限度的發揮。
  • Oppo百萬級高並發mongodb集群性能數十倍提升優化實踐
    2.3 wiredtiger存儲引擎優化從上一節可以看出平均時延從200ms降低到了平均80ms左右,很顯然平均時延還是很高,如何進一步提升性能降低時延?繼續分析集群,我們發現磁碟IO一會兒為0,一會兒持續性100%,並且有跌 0 現象,現象如下:
  • 阿里雲如何打破Oracle 遷移上雲的壁壘
    【IT168 評論】摘要:2018第九屆中國資料庫技術大會,阿里雲資料庫產品專家蕭少聰帶來以阿里雲如何打破Oracle遷移上雲的壁壘為題的演講。Oracle是指「資料庫管理系統」,面對Oracle遷移上雲的壁壘,阿里雲如何能夠打破它呢?