用 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 定价
为了容易理解 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
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 跟 Redshift + Spectrum 一样, 支持两种模式的存储: BigQuery 内部存储和外部存储, 其中外部存储支持了 Google BigTable, Cloud Storage 和 Cloud Drive, 基本上涵盖了所有的 GCE 的存储服务; 但从系统层面上来说, BigQuery 更像是自带优化后的存储的 Athena: 一个大集群按需付费, 存储额外收费, 但使用的不是原生格式而是优化后的 Capacitor.
0x02 数据 load 时间对比
文中使用的测试数据集是 CSV size: 997GB (~1TB). 测试的场景是从 S3/Google Cloud Storage 加载到对应的 Redshift 或者 BigQuery, 由于 Athena 是直接查询 S3 上的数据, 因此不需要加载, 或许这是 Athena 的唯一优势了
| 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 查询时间对比
大多数情况下, 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 --
