01

什么是大数据运维？

首先，我先说一下整个软件的生命周期，大概会经历以下几个阶段：

售前的阶段。这一块基本上就是甲方跟乙方两个进行洽谈，确认甲方需要什么东西，乙方做需求的确认，确认好需求之后，就由架构师根据需求来设计软件。要什么样的平台、什么样的组件、性能情况、并发情况等等全都设计好。

设计好了之后有专门的需求分析的人，根据架构师的设计，做出来一个详细的设计文档，包括接口的怎么去写，传什么样的参数，设计文档都会写出来。

然后再交给开发人员。其实这里才第一次出现开发，就是我们应届生毕业了之后，去面试的一个很常见的工作，就是开发岗，他会根据别人写好的需求纯粹的去写代码。

写完代码完善之后，会交给测试去测一下写的代码，功能是否有bug ，如果没有bug ，就可以上线了，上线就相当于是实施环节。实施环节会有专门的人到现场或者是到客户那里去部署。部署好了之后开始用了。

在用的过程中，出现了问题可能就会有售后服务。售后服务可能售后到一定的过程中出现了问题，出了问题之后就需要有人去处理。

最后环节，就是运维工程师需要来介入的环节，运维包括普通运维，大数据运维。我们的环节都是在最后系统在上线运行之后出了问题，我们去处理。

其实在运维环节，交付的就是我们平台或者系统的稳定，因为平时出问题，就需要我们运维的人来解决问题，来维护业务，还有平台的一个正常运转。

02

大数据运维工程师的工作内容

运维这一块涉及到工作的内容其实非常多。从我这么多年的经验来看，在大数据这一块来看主要就是维护hadoop或者维护大数据的各个组件的正常的运行。

比如说hadoop生态里面最常见的几个组件，例如HDFS、Sqoop 等等，这些服务进程出了问题之后，就需要我们去处理。因为如果这几个组件都出了问题，那你在平台上运行的其他的业务肯定会出问题。比如说客户要查一个东西，他查不出来，一直在那里转圈圈，那这就是问题。然后还有一些比较常见的，就是调优。比如说正常的时候查询可能3秒钟就查到了，我现在查询一个东西，10秒钟还没有出来结果，那时候就有问题，我们需要就去调整，优化它。

还有一些最常见的就是磁盘出故障了，因为在做大数据处理的时候，数据都是存储在磁盘上，所以说磁盘的读取非常有压力。对磁盘的消耗很大，磁盘在我们大数据里面纯属是消耗品，所以换盘是最常见的问题。网络、数据库等等，如果出问题，都需要我们去进行相关的优化。

还有一个就是平时跑的任务也是属于平台的。虽然说开发写完了任务之后放过来跑了，但是跑了出问题了之后，也首先是需要我们去看的，如果说真的定位出来是开发写的代码有问题，那时候才能交给开发。如果是平台的问题就需要咱们自己去解决。

关于工作中的配合，首先面向后端，出问题必然是在客户那里，那必然运维会接触到客户。有的客户态度好一点，对你客客气气的；有的人可能正着急用的时候系统出问题了，那可能心情就不太好，就需要面对他的怒火，你也需要有强大的容忍性和耐心，给客户去解释，既不能损害我们公司的利益，又要让甲方觉得咱们系统还是可以的，就是偶尔出一下问题，我们也能立马解决掉。

面向前端的话，如果问题你能自己解决那最好，如果问题比较难，就需要求助公司里做开发的，或者说在公司里会有专门对接现场运维人员的。在后面我可以单独再去做一下解释。

如果对接的是开发，这时候前端的开发人员就需要顶上去，配合我们运维人员来解决现场出现的问题。所以说配合角色方面主要就是这两个：是甲方和我们后端的支持人员，支持人员可能是开发，也可能是别的人，我们统称为支持人员。

03

大数据运维工程师的工作流程

基本上就看整个系统的架构。你知道了架构之后，就知道了整个系统大体的运作，或者说大体的数据流向。有了架构之后，就可以去排查问题了。

比如我看到某一个组件报错了，那我需要找的是组件的前后分别是什么，就是把它前面的，后面的和相关联的找出来就可以了。不需要像开发一样去了解它的接口怎么样，了解它的需求是怎么样。这些基本上是没大有必要的。

当然还有一个岗位叫做开发运维工程师，既懂代码，又能做运维，而且岗位的薪资比纯开发或者纯运维都会高一些，对于技术要求也很高。

作为运维来说，特别是运维平台，我们大数据的组件其实就这么多，你掌握了大数据的一些相关组件的知识点，或者相关的架构、原理。如果能看懂代码，也可以看一下它的源码，是最好的了，也很有助于去处理这种问题。

04

运维工程师vs开发工程师区别/联系

大数据开发工程师：

从现在招聘情况来看，大数据开发也是分为多种的。最常见的就是数据清洗。即平时采集过来的量很大的数据，里面的脏数据太多，需要从里面提取出来有价值的数据。

举个例子，假设有一个小偷，偷了东西，需要监控，我采集到了半小时的监控之后，可能在这半小时内，只有几秒钟照到了人的脸，那只有这几秒钟的数据才是有意义的，剩下的那些都没意义。时候就需要把没意义的数据都给干掉。还有比如我采集一些你平时的消费记录，从淘宝或者京东上买东西的相关信息来分析你的相关画像，或者是预测你未来，都可能需要进行数据的相关清洗。清洗后把数据存到库里面，再查询，就直接从库里面去查。

清洗完了之后，有时候来不及直接存到库里，就需要把清洗后的数据，先暂时存到一个缓存里面，或者说消息队列，以及从消息队列里取消费数据，也有专门的人去写代码，这是第二种。

第三种就是写SQL的，常见的写Hive SQL、Spark SQL，去专门对着SQL来进行查询、建模，这种大多数都是和SQL打交道了，但是打交道也需要知道平台背后的原理，因为写的SQL后面只有两个引擎，一个是MapReduce，一个是Spark ，这两个都是大数据里面很重要的组件。只有很清楚这两个组件的底层原理，这个时候写的SQL才会更加的优化，更加好。

再就是和平台相关的了。比如Hadoop，或者Spark ，有的公司觉得它封装出来的接口并不是太好用，它的学习成本还是太高，有的公司想着通过界面随便操作一下功能就实现了。这相当于是针对于开源的Hadoop生态圈组件，再做一次封装，把这种难的东西给屏蔽掉，呈现给用户的，给开发人员的仅仅是界面上一些简单的东西，这就相当于是对平台做二次封装开发。

基本上有点规模的公司都会做的事情。业务只需要关注业务，基本上你不需要去了解底层Hadoop的原理，或者是复杂的相关的逻辑。

最后就是很厉害的人，这种就是业界的大牛。就是我刚才提到的，能够改开源代码，也能够给社区贡献代码的人，这种都是顶尖的人了。

大数据运维工程师：

在我看来的运维可能比开发需要懂的内容更加宽一些，广一些。比如既要懂网络，还要懂硬件，懂相关的调优。那可能开发人员就做SQL，把mr引擎或者Spark 引擎研究透，写好SQL就足够了，其他的不需要关注，而做大数据运维，只要平台用到的组件都有可能出问题，那都有可能找到你。这个时候就需要对平台的各个组件都有所了解。

我们Hadoop生态组件可能达到20到30个组件了。每一个组件是干什么的，能帮助你做什么事情，它的内部架构、原理，甚至说有能力阅读一下它的源码，这个时候才能够帮助我们更好的去做相关的运维，那么这是我对这两个岗位关系的一个认知。

05

大数据运维的核心竞争力

在大数据运维这个层面上，需要前面普通运维知识的一个积累，加上大数据的一个积累，这些个知识基本上都不会变化太大。因为些东西都是开源，而不是像业务一样，业务是开发人员在平台上，基于平台实现的一些功能。我们不需要去掌握业务的东西，只需要保证平台的东西稳定即可。

所以有差别的地方，就是上层的业务，平台基本上不会太变，这个时候掌握核心竞争力无非就是加大对开源组件的了解，了解它的底层运行原理、框架，甚至去读代码。这些东西掌握了即使跳槽到别的公司薪资也不会太低。

还有做运维是需要靠经验，比如处理一个问题，这个问题之前碰到过，我第一眼看过去觉得很眼熟，我有点印象，这个时候你处理起来的效率就可能会比别人高一些。

06

胜任大数据运维师要具备的能力

大数据运维是有一定门槛的。至少得会一些Java ，因为Hadoop的组件绝大多数都是用Java来写，当然Spark用的是scala语言，但是绝大多数都是用Java 。再就是Linux得会，因为这些的组件、程序基本上都是在Linux 服务器上去运行，所以说环境得会一些，这是两个最基本的前提条件。

另外，如果你有普通运维的相关技术积累，再去学大数据运维这样会更好一点。如果前期没有普通运维相关的基础技术也没关系，有了Java 基础，有了Linux 基础，再加上Hadoop相关原理或者框架知识的学习也基本上能够胜任大数据运维，只不过是在胜任的过程中需要不断的去积累经验。

07

大数据运维工程师职业晋升路径

在我看来你无论从事什么岗位，都差不太多，前几年肯定都是经验积累，无论是做开发、测试或者是运维，线路基本是一样的。三五年后技术基础差不多了，那这个时候需要考虑是继续做开发、运维或者测试，还是说专管理岗，再或者转别的。无论你做哪个岗位，前面都是积累，到了一定的程度，你会根据当时的情况做一个正确的选择。

无论是测试、开发、运维这三者最顶端的都是架构师的角色，架构师不仅仅要求技术层面广度，还需要有技术的深度。