用 SQL 分析數(shù)據(jù), AWS 有 Redshift 和去年 re:Invent 2016 上發(fā)布了基于 Presto 的 Athena, 用于查詢 S3 上的數(shù)據(jù), Google 的 GCE 有 BigQuery. 我只有 Presto 的使用經(jīng)驗, 一直想了解一下其他幾個. 讀了一篇關(guān)于幾個查詢引擎對比的文章: GCE BigQuery vs AWS Redshift vs AWS Athena, 做點兒筆記.
文中涉及的性能數(shù)據(jù)均來自原文, 本人未經(jīng)任何驗證, 正確與否不負(fù)任何責(zé)任.
0x00 背景
AWS 方案
在 AWS 上想使用 SQL 查詢數(shù)據(jù), 除了 EMR 中的 Hive/Presto/Spark 外, 可選的還有 Redshift(Spectrum) 和 Athena.
Redshift 是 AWS 很早就發(fā)布的數(shù)據(jù)倉庫產(chǎn)品, 在 Spectrum 功能發(fā)布之前, 用戶需要將數(shù)據(jù) Copy 到 Redshift 集群中, 因此集群擴(kuò)容就要考慮計算和存儲兩個方面的因素, 而且如果查詢時想 Join 在 S3 上的 Hive table 卻不可能實現(xiàn), 很是蛋疼; 今年 AWS 發(fā)布了 Redshift 的新功能 Spectrum: 允許用戶直接從 Redshift 中創(chuàng)建 External Table, 查詢在 S3 上的數(shù)據(jù), 算是解決了這一痛點, 徹底打通了所有數(shù)據(jù). 值得一提的是, 雖然在 AWS 內(nèi)部訪問 S3 是不收取流量費用的, 而且 Redshift 集群本身已經(jīng)付費, 但 Redshift Spectrum 查詢 S3 上的數(shù)據(jù)卻是按照查詢讀取的數(shù)據(jù)量, 每個 TB 需要 5$ 的費用的, 具體參見 官方文檔 Redshift Spectrum 定價
為了容易理解 Redshift Spectrum, 舉個 SQL 查詢的例子: t_users 表和 t_user_city 表都存儲在 Redshift 上, t_orders 表存儲在 S3. 那么如下查詢的執(zhí)行計劃如圖:
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
AWS 的 Athena 是去年 re:Invent 上發(fā)布的基于 Presto 的產(chǎn)品, 可以說是 SQL as a Service, 無需部署, 按照查詢讀取的數(shù)據(jù)量收費. 使用 Athena 要注意的就是文件格式的學(xué)問了, 傻乎乎的存 CSV 文本進(jìn)去, 肯定不如 Parquet 等格式查詢起來劃算. 不過將 Presto 做成一個 Service 出來賣錢, 架構(gòu)上肯定有很多挑戰(zhàn), 有時間可以倒是可以 YY 一下: 如果讓我設(shè)計 Athena, 該如何實現(xiàn).
Google 的 BigQuery
Google 早在 2010年就有發(fā)表了一篇 paper: Dremel: Interactive Analysis of Web-Scale Datasets, 介紹了自己已經(jīng)用了不知道多少年的黑科技 Dremel, 教大家怎么做人咳咳.
云計算領(lǐng)域, Google 發(fā)布了 BigQuery, 將 Dremel 包裝成服務(wù)拿出來給大家用(關(guān)于 Dremel 推薦閱讀 大數(shù)據(jù)那些事(23):我是怎么分析Dremel系統(tǒng)的). 具體 BigQuery 的設(shè)計可以參見官方博客 BigQuery under the hood, 基本上就是從存儲到網(wǎng)絡(luò)到調(diào)度都是基于原來的黑科技, 比如 Borg 啥的, 存儲格式也換成了最近的 Capacitor, 參見官方博客: Inside Capacitor, BigQuery’s next-generation columnar storage format
從用戶的角度來說, BigQuery 跟 Redshift + Spectrum 一樣, 支持兩種模式的存儲: BigQuery 內(nèi)部存儲和外部存儲, 其中外部存儲支持了 Google BigTable, Cloud Storage 和 Cloud Drive, 基本上涵蓋了所有的 GCE 的存儲服務(wù); 但從系統(tǒng)層面上來說, BigQuery 更像是自帶優(yōu)化后的存儲的 Athena: 一個大集群按需付費, 存儲額外收費, 但使用的不是原生格式而是優(yōu)化后的 Capacitor.
0x02 數(shù)據(jù) load 時間對比
文中使用的測試數(shù)據(jù)集是 CSV size: 997GB (~1TB). 測試的場景是從 S3/Google Cloud Storage 加載到對應(yīng)的 Redshift 或者 BigQuery, 由于 Athena 是直接查詢 S3 上的數(shù)據(jù), 因此不需要加載, 或許這是 Athena 的唯一優(yōu)勢了
| BigQuery | Redshift Dense Compute dc1.8xlarge | Redshift Dense Storage ds2.xlarg | Athena |
|---|---|---|---|
| 46 m | 9h 30m | 8h 23m | 0s(no need to load the data) |
BigQuery 比 Redshift 快這么多? 我個人猜測, BigQuery 是一個 cluster, 按需付費; Redshift 本次測試僅僅使用了一臺 server, 肯定處于劣勢.
0x03 查詢時間對比
大多數(shù)情況下, BigQuery 都是完勝的, Athena 都是完敗的, 不過考慮到 BigQuery 內(nèi)部存儲格式已經(jīng)使用了優(yōu)化后的 Capacitor, 如果在跑不過 Athena 就更說不過去了.
0x04 查詢費用對比
費用上來說, BigQuery 和 Redshift 由于走的是不同的設(shè)計, 收費大不相同: BigQuery 跟 Athena 很像, 存儲額外收費, 查詢實際用量收費; 而 Redshift 確是按小時(或者通過 RI 包年) 收費, 很難對比費用究竟哪個劃算. 不過可以看出的是, 由于 Athena 在存儲上使用的 CSV, 每次查詢費用上比 BigQuery 貴了好幾倍, 真的應(yīng)該找機(jī)會試試 Parquet 格式.
0x05 每次查詢讀取的數(shù)據(jù)量
查詢讀取的數(shù)據(jù)量, Redshift 沒有給出對應(yīng)的數(shù)據(jù), 而 Redshift 和 Athena 都有詳細(xì)的數(shù)據(jù), 畢竟是按照這個收費的. 可以看出:
- BigQuery 由于使用了 Capacitor, 讀取量有很大優(yōu)勢, 呼喚 Parquet
- Athena 雖然傻傻的由于 CSV 格式讀取量接近于全部, 但
885.8GB與全部數(shù)據(jù)量997GB差了很多, 看示例查詢并沒有任何 LIMIT 操作, 因此不涉及讀取一部分?jǐn)?shù)據(jù)的情況, 那為何少讀取了這么多? 有優(yōu)化? 還是....?
總結(jié)
其實這種涉及到不同云計算廠商的產(chǎn)品間的比較, 看看就行了, 畢竟云計算廠商的選型也不會僅僅基于 SQL 查詢的性能, 還是要看綜合考量, 比如你家業(yè)務(wù)跑在 AWS, 你非要選 BigQuery, 來回 copy 數(shù)據(jù)不蛋疼死. 同一云計算廠商的不同產(chǎn)品間的比較, 確是很有必要, 看清楚性能, 在做產(chǎn)品選型的時候心里有底.
針對 AWS 來說, Athena 是快速上手查詢數(shù)據(jù)的首選, 但直接查詢文本格式的數(shù)據(jù)也有些傷錢, 還是要借助 ORC/Parquet 才劃算. Redshift 這種包月/包年型的, 確實降低了運維成本, 但系統(tǒng)容量規(guī)劃的時候要考慮存儲和計算資源兩個因素, 雖然 Spectrum 也是可以臨時查詢一些數(shù)據(jù)的, 但也是有成本的.
YY 一下, 要是 Spectrum 本身不收費了, 估計 Redshift 競爭力就更上一層樓了: 熱數(shù)據(jù)存儲在 Redshift 內(nèi)部, 其他日志一律走 Spectrum, 交互式查詢還有誰能比?
-- EOF --
