大数据不就是写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等

最后

产品又来需求了，现有系统还无法实现，上面四步再折腾一遍...