大数据不就是写sql吗？—— Hive：把sql解析后用MapReduce跑 SparkSQL：把sql解析后用Spark跑，比hive快点 Drill/Impala/Presto：交互式查询OLAP Druid/Kylin：强调预计算，同样是OLAP
应届生小祖参加了个需求分析会回来后跟我说被产品怼了一句：
"不就是写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：交互式查询OLAP,都是类似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等
最后
产品又来需求了，现有系统还无法实现，上面四步再折腾一遍...
是的，我们就是写SQL。
