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

怎么样，看完之后有什么感想，知道大数据的SQL来之不易了吧，大数据写SQL只是一方面，我们跳出SQL这个圈，从本质看看大数据到底要学些什么？

思维导图

下面的是我之前整理的一张思维导图，内容分成几大块，包括了分布式计算与查询，分布式调度与管理，持久化存储，大数据常用的编程语言等等内容，每个大类下有很多的开源工具，想知道要学些什么的同学，告诉你一个“坏消息”，这些就是作为大数据程序猿又爱又恨折腾得死去活来而你想要成为大数据大牛又必须要学习的东西了。

大数据需要的语言

Java

java可以说是大数据最基础的编程语言，据我这些年的经验，我接触的很大一部分的大数据开发都是从Jave Web开发转岗过来的（当然也不是绝对我甚至见过产品转岗大数据开发的，逆了个天）。

• 一是因为大数据的本质无非就是海量数据的计算，查询与存储，后台开发很容易接触到大数据量存取的应用场景
• 二就是java语言本事了，天然的优势，因为大数据的组件很多都是用java开发的像HDFS,Yarn,Hbase,MR,Zookeeper等等，想要深入学习，填上生产环境中踩到的各种坑，必须得先学会java然后去啃源码。

说到啃源码顺便说一句，开始的时候肯定是会很难，需要对组件本身和开发语言都有比较深入的理解，熟能生巧慢慢来，等你过了这个阶段，习惯了看源码解决问题的时候你会发现源码真香。

Scala

scala和java很相似都是在jvm运行的语言，在开发过程中是可以无缝互相调用的。Scala在大数据领域的影响力大部分都是来自社区中的明星Spark和kafka,这两个东西大家应该都知道（后面我会有文章多维度介绍它们），它们的强势发展直接带动了Scala在这个领域的流行。

Python和Shell

shell应该不用过多的介绍非常的常用，属于程序猿必备的通用技能。python更多的是用在数据挖掘领域以及写一些复杂的且shell难以实现的日常脚本。

分布式计算

什么是分布式计算？分布式计算研究的是如何把一个需要非常巨大的计算能力才能解决的问题分成许多小的部分，然后把这些部分分配给许多服务器进行处理，最后把这些计算结果综合起来得到最终的结果。

举个栗子，就像是组长把一个大项目拆分，让组员每个人开发一部分，最后将所有人代码merge，大项目完成。听起来好像很简单，但是真正参与过大项目开发的人一定知道中间涉及的内容可不少。

比如：

• 这个大项目如何拆分？
• 任务如何分配？
• 每个人手头已有工作怎么办？
• 每个人能力不一样怎么办？
• 每个人开发进度不一样怎么办？
• 开发过程中组员生病要请长假他手头的工作怎么办？
• 指挥督促大家干活的组长请假了怎么办？
• 最后代码合并过程出现问题怎么办？
• 项目延期怎么办？
• 项目最后黄了怎么办？

仔细想想上面的夺命十连问，其实每一条都是对应了分布式计算可能会出现的问题，具体怎么对应大家思考吧我就不多说了，其实已经是非常明显了。也许有人觉得这些问题其实在多人开发的时候都不重要不需要特别去考虑怎么办，但是在分布式计算系统中不一样，每一个都是非常严重并且非常基础的问题，需要有很好的解决方案。

最后提一下，分布式计算目前流行的工具有：

• 离线工具Spark，MapReduce等
• 实时工具Spark Streaming，Storm，Flink等

这几个东西的区别和各自的应用场景我们之后再聊。

分布式存储

传统的网络存储系统采用的是集中的存储服务器存放所有数据，单台存储服务器的io能力是有限的，这成为了系统性能的瓶颈，同时服务器的可靠性和安全性也不能满足需求，尤其是大规模的存储应用。

分布式存储系统，是将数据分散存储在多台独立的设备上。采用的是可扩展的系统结构，利用多台存储服务器分担存储负荷，利用位置服务器定位存储信息，它不但提高了系统的可靠性、可用性和存取效率，还易于扩展。

上图是hdfs的存储架构图，hdfs作为分布式文件系统，兼备了可靠性和扩展性，数据存储3份在不同机器上（两份存在同一机架，一份存在其他机架）保证数据不丢失。由NameNode统一管理元数据，可以任意扩展集群。

主流的分布式数据库有很多hbase，mongoDB，GreenPlum，redis等等等等，没有孰好孰坏之分，只有合不合适，每个数据库的应用场景都不同，其实直接比较是没有意义的，后续我也会有文章一个个讲解它们的应用场景原理架构等。

分布式调度与管理

现在人们好像都很热衷于谈"去中心化"，也许是区块链带起的这个潮流。但是"中心化"在大数据领域还是很重要的，至少目前来说是的。

• 分布式的集群管理需要有个组件去分配调度资源给各个节点，这个东西叫yarn;
• 需要有个组件来解决在分布式环境下"锁"的问题，这个东西叫zookeeper；
• 需要有个组件来记录任务的依赖关系并定时调度任务，这个东西叫azkaban。

当然这些“东西”并不是唯一的，其实都是有很多替代品的，我这里只举了几个比较常用的例子。

以上非常粗略地讲了下大数据的几个方面的内容，没有涵盖的东西还有很多。大数据是一条很长的路，无论你是新入门的菜鸟还是大厂架构师想要保持竞争力都不能停止学习的脚步，你停了你就会看见有很多人从你身后走到你身前，这是作为程序猿最苦的地方，但是也是最有趣的，因为努力就会有希望。

转载于:https://blog.51cto.com/9587671/2300951