用 SQL 分析數據, AWS 有 Redshift 和去年 re:Invent 2016 上發布了基于 Presto 的 Athena, 用于查詢 S3 上的數據, Google 的 GCE 有 BigQuery. 我只有 Presto 的使用經驗, 一直想了解一下其他幾個. 讀了一篇關于幾個查詢引擎對比的文章: GCE BigQuery vs AWS Redshift vs AWS Athena, 做點兒筆記.

文中涉及的性能數據均來自原文, 本人未經任何驗證, 正確與否不負任何責任.

0x00 背景

AWS 方案

在 AWS 上想使用 SQL 查詢數據, 除了 EMR 中的 Hive/Presto/Spark 外, 可選的還有 Redshift(Spectrum) 和 Athena.

Redshift 是 AWS 很早就發布的數據倉庫產品, 在 Spectrum 功能發布之前, 用戶需要將數據 Copy 到 Redshift 集群中, 因此集群擴容就要考慮計算和存儲兩個方面的因素, 而且如果查詢時想 Join 在 S3 上的 Hive table 卻不可能實現, 很是蛋疼; 今年 AWS 發布了 Redshift 的新功能 Spectrum: 允許用戶直接從 Redshift 中創建 External Table, 查詢在 S3 上的數據, 算是解決了這一痛點, 徹底打通了所有數據. 值得一提的是, 雖然在 AWS 內部訪問 S3 是不收取流量費用的, 而且 Redshift 集群本身已經付費, 但 Redshift Spectrum 查詢 S3 上的數據卻是按照查詢讀取的數據量, 每個 TB 需要 5$ 的費用的, 具體參見 官方文檔 Redshift Spectrum 定價

AWS Redshift 和 Athena

為了容易理解 Redshift Spectrum, 舉個 SQL 查詢的例子: t_users 表和 t_user_city 表都存儲在 Redshift 上, t_orders 表存儲在 S3. 那么如下查詢的執行計劃如圖:

SELECT c.city_name,
       u.user_name,
       o.*
FROM t_users u
JOIN t_user_city c ON u.user_id = c.user_id
JOIN t_orders o ON u.user_id = o.user_id

Redshift Spectrum 查詢計劃示例

AWS 的 Athena 是去年 re:Invent 上發布的基于 Presto 的產品, 可以說是 SQL as a Service, 無需部署, 按照查詢讀取的數據量收費. 使用 Athena 要注意的就是文件格式的學問了, 傻乎乎的存 CSV 文本進去, 肯定不如 Parquet 等格式查詢起來劃算. 不過將 Presto 做成一個 Service 出來賣錢, 架構上肯定有很多挑戰, 有時間可以倒是可以 YY 一下: 如果讓我設計 Athena, 該如何實現.

Google 的 BigQuery

Google 早在 2010年就有發表了一篇 paper: Dremel: Interactive Analysis of Web-Scale Datasets, 介紹了自己已經用了不知道多少年的黑科技 Dremel, 教大家怎么做人咳咳.

云計算領域, Google 發布了 BigQuery, 將 Dremel 包裝成服務拿出來給大家用(關于 Dremel 推薦閱讀 大數據那些事(23):我是怎么分析Dremel系統的). 具體 BigQuery 的設計可以參見官方博客 BigQuery under the hood, 基本上就是從存儲到網絡到調度都是基于原來的黑科技, 比如 Borg 啥的, 存儲格式也換成了最近的 Capacitor, 參見官方博客: Inside Capacitor, BigQuery’s next-generation columnar storage format

BigQuery Architecture

從用戶的角度來說, BigQuery 跟 Redshift + Spectrum 一樣, 支持兩種模式的存儲: BigQuery 內部存儲和外部存儲, 其中外部存儲支持了 Google BigTable, Cloud Storage 和 Cloud Drive, 基本上涵蓋了所有的 GCE 的存儲服務; 但從系統層面上來說, BigQuery 更像是自帶優化后的存儲的 Athena: 一個大集群按需付費, 存儲額外收費, 但使用的不是原生格式而是優化后的 Capacitor.

BigQuery

0x02 數據 load 時間對比

文中使用的測試數據集是 CSV size: 997GB (~1TB). 測試的場景是從 S3/Google Cloud Storage 加載到對應的 Redshift 或者 BigQuery, 由于 Athena 是直接查詢 S3 上的數據, 因此不需要加載, 或許這是 Athena 的唯一優勢了

BigQuery 比 Redshift 快這么多? 我個人猜測, BigQuery 是一個 cluster, 按需付費; Redshift 本次測試僅僅使用了一臺 server, 肯定處于劣勢.

0x03 查詢時間對比

查詢時間對比

大多數情況下, BigQuery 都是完勝的, Athena 都是完敗的, 不過考慮到 BigQuery 內部存儲格式已經使用了優化后的 Capacitor, 如果在跑不過 Athena 就更說不過去了.

0x04 查詢費用對比

查詢費用對比

費用上來說, BigQuery 和 Redshift 由于走的是不同的設計, 收費大不相同: BigQuery 跟 Athena 很像, 存儲額外收費, 查詢實際用量收費; 而 Redshift 確是按小時(或者通過 RI 包年) 收費, 很難對比費用究竟哪個劃算. 不過可以看出的是, 由于 Athena 在存儲上使用的 CSV, 每次查詢費用上比 BigQuery 貴了好幾倍, 真的應該找機會試試 Parquet 格式.

0x05 每次查詢讀取的數據量

每次查詢讀取的數據量

查詢讀取的數據量, Redshift 沒有給出對應的數據, 而 Redshift 和 Athena 都有詳細的數據, 畢竟是按照這個收費的. 可以看出:

• BigQuery 由于使用了 Capacitor, 讀取量有很大優勢, 呼喚 Parquet
• Athena 雖然傻傻的由于 CSV 格式讀取量接近于全部, 但 885.8GB 與全部數據量997GB 差了很多, 看示例查詢并沒有任何 LIMIT 操作, 因此不涉及讀取一部分數據的情況, 那為何少讀取了這么多? 有優化? 還是....?

總結

其實這種涉及到不同云計算廠商的產品間的比較, 看看就行了, 畢竟云計算廠商的選型也不會僅僅基于 SQL 查詢的性能, 還是要看綜合考量, 比如你家業務跑在 AWS, 你非要選 BigQuery, 來回 copy 數據不蛋疼死. 同一云計算廠商的不同產品間的比較, 確是很有必要, 看清楚性能, 在做產品選型的時候心里有底.

針對 AWS 來說, Athena 是快速上手查詢數據的首選, 但直接查詢文本格式的數據也有些傷錢, 還是要借助 ORC/Parquet 才劃算. Redshift 這種包月/包年型的, 確實降低了運維成本, 但系統容量規劃的時候要考慮存儲和計算資源兩個因素, 雖然 Spectrum 也是可以臨時查詢一些數據的, 但也是有成本的.

YY 一下, 要是 Spectrum 本身不收費了, 估計 Redshift 競爭力就更上一層樓了: 熱數據存儲在 Redshift 內部, 其他日志一律走 Spectrum, 交互式查詢還有誰能比?

-- EOF --