最近，这个问题被很多正在转，或者准备转大数据开发的小伙伴们经常问到。大家之所以这么问，根本原因在于，他们时不时就能在网上或者从身边的朋友那里听说，他们对大数据开发工作内容的描述或者抱怨，说所谓的大数据开发，不过就是写写SQL而已。以前传统关系型数据库的时候写SQL，到了现在大数据技术，怎么还是写SQL？
自从2004年以来，大数据技术经过这些年来的持续不断发展，不得不承认，截止到今天为止，几乎所有流行的技术组件都在往【SQL化】这个方向转，好像哪个技术如果不支持SQL就发展不起来似的。尤其一些跟数据计算、数据存储相关的组件（如计算引擎和数据库），你能叫上名字的几乎都支持丰富的SQL查询与计算功能。那这么说来，是不是作为一个大数据开发，就只能当一个SQL boy了呢？Emm... 我觉得你不要盲目悲观，现实往往并非你听到，或者想到的那样，我们说看问题，要看全貌，不要让局部认知限制了你的视野。
要知道，任何一个大数据项目，或者一个大数据系统，它都是从0到1逐步建设起来的。那么它一定会经历一个从无到有、从有到优的漫长过程，而在这个过程中，正常情况下都会经历技术选型、性能测试、架构优化、以及代码工程建设这些基础步骤的。那么这整个过程中，就需要你对各个用到的大数据技术组件的应用场景、性能极限、优缺点、可扩展性等指标要非常的清楚，否则你的项目技术架构将无从谈起，这个过程肯定是不需要你写SQL的，且这个过程会非常锻炼你的基础能力。然后，就是对于数据源接入这个过程的开发，之前文章和视频都说过，这个是所有大数据系统的第一步，把数据源从目的地取回到大数据系统端、需要将数据源进行一系列比如：字段归一化、脏数据剔除、空值填充、字段信息补全等数据清洗操作，也是很少用到SQL的。其次，在软件工程建设的初期，需要写很多的脚手架代码、工具类代码、连接池代码等等，这一类为后续的大数据处理提供辅助的代码，也基本上和SQL没什么关系。最后，如果在你的数据处理过程中，只用到了Spark的RDD api或者Flink的DataStream api的话，也是用不到SQL的。其实，在整个大数据开发中，全程用SQL的情况，相对于整个大数据系统的建设周期来说，所占的比重是很低的。一般只有在系统建设稳定之后，各个数据处理流程已经很规范、健全的情况下，才会大范围普及开发者对SQL的使用。
SQL之所以这么流行，受到大家的热捧，且这么多年来，一直经久不衰，一定有着其过人之处，我觉得总结起来，有如下几点：1，作为一门结构化的数据操纵语言，其规范的语法特点，可以有效减少经验不足的开发者对系统的侵入性、和犯错的几率，让系统尽可能少的遭受不规范的代码侵害；2，因为SQL是最贴近业务的数据处理语言，普适性强，对业务理解非常友好，使用人群广，可以有效减少沟通壁垒；3，简单易上手，对使用者的技术背景要求相对不高，经过简单的培训就可以上岗，减少企业的用工成本；上面提到了SQL的一些优点，当然，那是站在用人单位的角度，为了追求规范、效率、和低成本而导致的技术走向。那为什么作为程序员，我们要尽可能避免去当一个单纯的SQL boy呢？1，作为一个大数据开发，如果你每天工作的全部内容，都只是用写SQL的方式来对数据进行各种操作，响应业务方的需求，那么就久而久之，你的技术能力就会变得狭窄和单一、其他的技能也会随着时间的流逝而逐渐退化，人也会慢慢变的工具化；2，长久跟SQL打交道，可能让你误以为这就是大数据技术的全貌，技术眼界和视野势必会受限，让你的市场竞争力下降，可替代性强，年纪一大，很容易被优化；
想要成为一个有核心竞争力的大数据开发，一定要想办法跳出这种认知局限，想办法看到大数据技术的全貌，尽可能去参与到与业务不那么【强绑定】的工作内容中，尽量去接触那些【普适】和有【深度】的技术，让你的技能具备【可移植】性。
我这有一个高质量的大数据学习讨论群，不怎么扯淡、偶尔活跃气氛、大部分时间都在讨论技术，你在群里的几乎任何大数据相关的问题，都可以得到解答，要不要进来试试呢？拉你进群啊...
原文作者：安瑞哥是码农；如有侵权，请联系管理员删除。
