应届生小祖参加了个需求分析会回来后跟我说被产品怼了一句:
"不就是写 SQL 吗, 要那么久吗"
我去, 欺负我小弟, 这我肯定不能忍呀, 于是我写了一篇文章发在了公司的 wiki
贴出来给大家看看, 省略了一些敏感的内容. 当然内部版言辞也会温和一点, 嘻嘻
在哪里写 SQL?
这个问题高级点的问法是用哪种 SQL 引擎?
SparkSQL,Hive,Phoenix,Drill,Impala,Presto,Druid,Kylin (这里的 SQL 引擎是广义的, 大家不必钻牛角尖)
我用一句话概括下这几个东西, 先不管你们现在看不看得懂:
Hive: 把 sql 解析后用 MapReduce 跑
SparkSQL: 把 sql 解析后用 Spark 跑, 比 hive 快点
Phoenix: 一个绕过了 MapReduce 运行在 HBase 上的 SQL 框架
Drill/Impala/Presto 交互式查询, 都是类似 google Dremel 的东西, 区别这里就不说了
Druid/Kylin olap 预计算系统
这就涉及到更多的问题了, 对这些组件不熟悉的同学可能调研过程就得花上一个多月.
比如需求是实时计算还是离线分析?
数据是增量数据还是静态数据?
数据量有多大?
能容忍多长的响应时间?
总之, 功能, 性能, 稳定性, 运维难度, 开发难度这些都是要考虑的
对哪里的数据执行 SQL?
你以为选完引擎就可以开写了? too naive!
上面提到的大部分工具都仅仅是查询引擎, 存储呢?
"啥, 为啥还要管存储?"
不管存储, 那是要把 PB 级的数据存在 MySQL 是吧...
关系型数据库像 MySQL 这种, 查询引擎和存储是紧耦合的, 这其实是有助于优化性能的, 你不能把它们拆分开来.
而大数据系统 SQL 引擎一般都是独立于数据存储系统, 获得了更大的灵活性. 这都是出于数据量和性能的考虑.
这涉及到的问题就更多了. 先要搞清楚引擎支持对接哪些存储, 怎么存查询起来方便高效.
可以对接的持久化存储我截个图, 感受一下 (这还只是一小部分)
用哪种语法写 SQL?
你以为存储和查询搞定就可以开写了? 你以为全天下的 sql 都是一样的? 并不是!
并不是所有的引擎都支持 join;
并不是所有的 distinct 都是精准计算的;
并不是所有的引擎都支持 limit 分页;
还有, 如果处理复杂的场景经常会需要自定义 sql 方法, 那如何自定义呢, 写代码呀.
举几个简单而常见的栗子:
见过这样的 sql 吗?
select `user`["user_id"] from tbl_test ;
见过这种操作吗?
insert overwrite table tbl_test select * from tbl_test where id>0;
卧槽, 这不会锁死吗? hive 里不会, 但是不建议这样做.
还能这么写
from tbl_test insert overwrite table tbl_test select * where id>0;
怎么用更高效的方式写 SQL?
好了, 全都搞定了, 终于可以开始愉快地写 SQL 了.
写 SQL 的过程我用小祖刚来公司时的一句话来总结:
"卧槽, 这条 SQL 有 100 多行!"
事实表, 维表的数据各种 join 反复 join, 这还不算完还要再 join 不同时间的数据, 还要 $#@%^$#^...
不说了, 写过的人一定知道有多恶心
(此处省略 100 多行字)
终于写完了, 千辛万苦来到这一步, 满心欢喜敲下回车...
时间过去 1 分钟...
10 分钟...
30 分钟...
1 小时...
2 小时...
......
别等了, 这样下去是不会有结果的.
老实看日志吧, 看日志也是一门很大的学问.
首先你得搞清楚这个 sql 是怎么运行, 底层是 mapReduce 还是 spark 还是解析成了其他应用的 put,get 等接口;
然后得搞清楚数据是怎么走的, 有没有发生数据倾斜, 怎么优化.
同时你还得注意资源, CPU, 内存, io 等
最后
产品又来需求了, 现有系统还无法实现, 上面四步再折腾一遍...
来源: https://www.cnblogs.com/uncleData/p/9736285.html