大数据不就是写SQL吗?
Posted uncledata
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了大数据不就是写SQL吗?相关的知识,希望对你有一定的参考价值。
【原创,转载请注明出处】
应届生小祖参加了个需求分析会回来后跟我说被产品怼了一句:
"不就是写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等
最后
产品又来需求了,现有系统还无法实现,上面四步再折腾一遍...
推荐阅读
大数据需要学什么?
zookeeper-操作与应用场景-《每日五分钟搞定大数据》
zookeeper-架构设计与角色分工-《每日五分钟搞定大数据》
zookeeper-paxos与一致性-《每日五分钟搞定大数据》
zookeeper-zab协议-《每日五分钟搞定大数据》
以上是关于大数据不就是写SQL吗?的主要内容,如果未能解决你的问题,请参考以下文章