查看原文
其他

大数据不就是写SQL吗?

程序猿DD 2019-07-13

来源:大叔据


应届生小祖参加了个需求分析会回来后跟我说被产品怼了一句:


"不就是写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吗?

  1. select `user`["user_id"] from tbl_test ;


见过这种操作吗?

  1. insert overwrite table tbl_test select * from tbl_test  where id > 0;


卧槽,这不会锁死吗?hive里不会,但是不建议这样做。

还能这么写

  1. 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。


 近期热文:

关注我

点击“阅读原文”,看本号其他精彩内容

    您可能也对以下帖子感兴趣

    文章有问题?点此查看未经处理的缓存