大数据现在的热度可谓居高不下，许多想加入这一领域的小伙伴都不知该如何下手。今天小鸟来给大家讲讲大数据领域相关的几种工作，首先从最底层开始。

一、Hadoop源码级工程师

想必大家在使用任何技术的时候，都会被告知不要用最新的版本。这是因为最新的版本并没有经过长时间的检验，因此在使用过程中可能会导致一些意想不到的问题出现。Hadoop其实也不例外，许多大公司都有着自己稳定的Hadoop版本。但是顶尖的科技公司并不会局限于某个版本。

举个例子，假如某公司的大数据平台在平稳运行着，每个组件之间也没有出现过兼容性问题。但是随着数据量的增长和版本的更替，现版本的Hive已经无法满足公司的需求，但是如果贸然升级为Hive更新的版本，则很可能会导致与其他组件的兼容问题。对于科技公司来说，上线的产品出现任何问题都可能出现致命的后果。这时候就需要源码级工程师出马了。他们需要在不影响线上产品的稳定型的情况下，尽可能的将新版Hive的新特征加入进来，以满足现在公司面临的新需求。

一般而言这种级别的工程师需要对Hadoop的某些组件或者全部组件的源码非常了解，对版本的理解也非常透彻。因此对于技术的要求是极高的，工资待遇自然也处于顶尖了。

二、大数据运维工程师

大数据平台都是一台台服务器组成的集群，既然有集群就必然要维护。运维工程师就是为了保障集群的稳定运行而生的。作为一名大数据运维工程师，需要对公司的大数据平台有着极为细致的了解。并且对整个大数据生态圈也要了然于心。最后其对公司的业务需求也要熟练掌握，要在不同的时期给予平台合理的规划。拿淘宝举例，类似双十一这种服务器灾难日，对相应的集群策略肯定是要作出对应的调整的。

三、大数据工程师

大数据通常是海量且杂乱的，因此对数据的提取需要有专业的工程师来操作，这些工程师就叫大数据工程师。它们的主要职责就是将海量的数据进行归纳和整理，然后将这些数据交给上层的其他部门使用。大数据工程师需要对Hadoop工具的使用非常熟悉，并且对其组件的框架也要极为了解。最常见工具的就是Hadoop、Hive和Spark等。

四、算法工程师

既然有数据就必然牵扯到算法，现在大型的互联网公司对数据的重视程度已经到了狂热的程度。但是在茫茫的海量数据中，如何发现有用的信息是极其困难的，而算法工程师就是来处理这个难题的。

例如现在各大企业都在完善的推荐系统，就需要通过对用户日志行为的分析，然后针对业务指定一套算法，在用户使用的时候给他们提供最优势的内容。某著名的咨询软件也正是凭借其优质的推荐内容发家致富的。

算法工程师需要处理的事情其实非常多，他们需要对数据挖掘，机器学习，自然语言处理，深度学习等方面有着深厚的理解。并且数学功底非常扎实。一般情况下，算法工程师的学历要求是最高的。

五、Web工程师

所谓一切的努力都是为了更好地呈现。前面的一系列工作，得出的结果都只是冰冷的数据而已。想要将这些数据呈现出来，那么平台的构建就必不可少。而web工程师还分为前端和后端。后端工程师需要编写逻辑代码，将数据输送到页面。而前端工程师就需要对页面进行规划和布局。比较常见的后端语言有Java、Php等，而前端工程师则需要精通html、css、js、jquery等。

听完这些，小伙伴们对于如何进入大数据领域是否更加清楚了呢？如果有所帮助，欢迎大家多多关注并帮忙收藏和转发，小鸟会提供更多优质的大数据教程和咨询。

晨起打开电视机，想看会新闻节目，父亲节将至，新闻自然会给予一定关住度，新闻中用到了大量的大数据提供的最为客观的信息，来调查父亲节礼物，这种统计方式让你不得不感叹科技的革新带来的巨大的变化，正在悄悄改变我们的生活。

大数据时代，名副其实的“信息社会”。大数据将重塑我们的生活、工作和思维方式。大数据需要人们重新讨论决策、命运和正义的性质。拥有知识曾意味着掌握过去，现在则更意味着能够预测未来。很多情况下，弄清楚“是什么”比找寻“为什么”更加重要，因为前者表明事实才是我们生活和思维的基础。

现在精明的企业，在想要采取任何一个动作前，最先做的是数据调查，用数据说话，这种数据不受个人意志为转移，无疑是更理性更具权威性，任何人都必须臣服于大数据的精准判断。

有需求就有市场，一大数据为依托的数据运维行业应运而生，但是由于市场的需求量大，大数据人才市场供不应求，目前互联网的朝阳行业，就算你掌握了大数据的命脉，假使你有一天想创业，自己当老板，掌握了数据思维就相当于掌握了珍贵的商业信息，总之，目前大数据真的是一项可以帮你转业提薪的绝佳机会，观望的越久，损失越大！

一根筋教育，名师指导，课程脉络一目了然，四个月时间，让你掌握一门手艺，也是一门生意经。想了解的就联系一根筋官网客服，课程大纲、还有免费资料可以拿。

分享之前我还是要推荐下我自己创建的大数据学习资料分享群 232840209，这是全国最大的大数据学习交流的地方，2000人聚集，不管你是小白还是大牛，小编我都挺欢迎，今天的源码已经上传到群文件，不定期分享干货，包括我自己整理的一份最新的适合2017年学习的前端资料和零基础入门教程，欢迎初学和进阶中的小伙伴。

大数据开发运维工程师（非数据分析挖掘）需要掌握的技能：

了解各种常用集群的搭建及性能调优

Hadoop集群，storm集群，spark集群

其实会hadoop的搭建，其它就很容易了

这里有时会涉及硬件管理或网络管理，具体看项目

这里需要到的技能是：对Linux系统的常用操作，包括对shell脚本语言的开发使用， 硬件管理(磁盘，内存，CPU等)，网络

2. 学会集群的各类组件的原理和使用及配置

这块内容比较多也比较杂，一般来说常用的组件有Hive, Yarn, Hdfs, Hbase, Zookeeper等

能够理解和使用Mapreduce算法框架

如果是做实时处理需要掌握Flume, Kafka, Redis等的使用

3. 会使用至少两种主流开发语言

包括 Java，Scala，Python，Java的话至少要掌握Java基础，J2ee一般可不考虑(具体看公司招聘需求)

数据分析挖掘工程师：

技能：传统SQL, HiveQL开发, Scala(对应Spark), R语言，Shell, 基础Linux操作，有的还需要一到两种主流开发语言(以上不一定要求都懂，具体看项目需求)

要会使用分析工具，包括spss等

要懂常用机器学习算法的适用场景及使用方法，包括聚类分析，逻辑回归等等

以上是我之前接触到的在大数据项目中会使用到的技术和工具，

不得不说，以上任何一个技术点单拎出来都能写一本书 。。。

而且大数据生态圈组件非常多，我们只是使用到了其中一部分，同时大数据相关技术更新也很快，

总体来说，Java或者Python程序员转大数据相对要容易些。

分享：你所不知的云计算与大数据运维工程师大揭秘--由成都达内小编分享给大家

2018年转眼即逝，在这半年里，各种大会铺天盖地，频频听到身边发问“近几年的运维大会真多呀”的朋友也越来越多。Linux运维及云计算仿佛成为了跟Web开发和平面设计一样的火爆岗位。

我们知道Linux诞生于1991年，那个时候“马云”还是一名教书匠，OICQ(QQ早期产品)的概念还没有出来，更不用提百度是什么了。那个时候的互联网在美国，而中国的互联网真正开始是从2000开始，百度，阿里，网易，搜狐等国内现在大家耳熟能详的老牌公司也均是那个时代的产物，时至今日依然影响着广大民众生活的方方面面，而且已然成为民众生活的“水”和“电”。

虽人们享受着当日送货上门的便利，亲朋好友千里之外流畅视频通话的温情，人类的吃穿住行及所能想像的任何物件背后都直接或间接基于Linux，却鲜有人知道：

Linux是什么?

运维是干什么的?

运维?网管?修电脑的?

现在手机在手，就能干很多事情，只需点一点屏幕，轻松完成聊天、娱乐、甚至支付功能。这些操作看似简单，但其背后，有一系列复杂请求和响应。而在阿里、百度等这些互联网巨头的机房里，就有千上万台服务器，为你服务请求提供服务的。这些服务器中，95%以上，是Linux系统、或类Linux系统。

从行业来划分：通信、金融、互联网、教育、电子商务、机械制造、军工航天、电器业等等，都离不开Linux平台。

远的不讲，近的来讲，马云的双十一。最大的变化诸位剁手的朋友印象应该很深，不再需要漫长的等待，就能拿到自己心仪的货品，最快的次日就已经拿到货品了。这背后少不了大数据的帮忙，而所有的这些均是基于Linux之上，而这只是ITLinux的冰山一角，在应用层面提出来“互联网+”的概念，大数据成为人类的资源，Linux的前景不言而喻。

运维工程师是干嘛的?

一句话概括：负责线上业务稳定，基于Linux平台集合网络、应用、数据库、开发、安全工作于一身的“复合性人才”。 就运维行业来讲，能力越大，责任越大，你有多大的能耐就有多大回报，平均年薪在10万+，动辄100w年薪也是常有的是，只要你够努力。

看看大公司的平台运维架构是什么样的?

搜狐畅游运维的演变：

苏宁大数据平台：

腾讯游戏智能运维平台：

稳定压力一切，运维很重要!

近年来，贵州将大数据产业作为转型升级、加快发展的战略重点，以大数据引领产业升级，促进新一代信息技术与三次产业融合发展。在贵州大数据产业的宏伟蓝图中，中国移动(贵州)大数据中心可谓是一颗璀璨夺目的明珠。

项目背景：

贵州移动大数据中心共有花溪、金阳和贵安三个省级数据机房，对内支撑贵州省移动公司所有业务，对外提供IDC存储、云计算等服务；机房拥有刀箱、刀片、虚拟化、网络安全等数量庞大的基础设施，需要一套综合运维管理系统对所有设施进行全方位的监控和管理，以保证移动业务的正常运行和高标准IDC服务的要求。

项目概述：

经过充分的调研，贵州移动最终选择卓豪数据中心运维管理解决方案，实现对网络设备、服务器、虚拟化、进程服务、存储、告警、网络拓扑等全面监控和管理。

其中，在网络监控方面：

通过卓豪OpManager网络监控模块，对贵州移动花溪、金阳和贵安三个数据中心的基础网络设施进行监控，系统采用独立部署模式，通过一套系统监控三个数据中心的所有网络、安全设备，对其设备性能进行监控、对链路通断和流量进行分析告警；在设备性能超标、链路中断和流量满载情况下及时报警通知管理人员；形成三个IDC数据中心的机房拓扑图和贵州移动IDC机房总拓扑图，通过逻辑拓扑图实时呈现IDC机房网络运行情况。

在机房设施监控方面：

通过卓豪Applications Manager性能监控模块，对贵州移动三个IDC机房的机房基础设施进行监控，整体思路是从3个方向去实现IDC机房整体监控：

第一：从底层的IBM刀箱、刀片的处理器、磁盘状态、LED告警灯状态、主板等物理性能指标的监控，到其上运行的VMware虚拟化集群、主机等的CPU、内存、流量、容量等性能指标再到虚拟机的CPU、内存、磁盘等性能监控，最终形成VMware虚拟化拓扑视图，最后再对虚拟系统上的数据库、中间件、应用等进行纵向全方位监控，最终形成业务视图。

第二：从底层的Cisco UCS进行物理级别的处理器，磁盘状态等物理性能指标进行监控，到其上的VMware虚拟化监控，最后再对虚拟系统上的数据库、中间件、应用等进行纵向全方位监控，最终形成业务视图。

第三：从存储方向对IDC机房内部的存储设备包括RAID、光纤交换机等进行监控；包括磁盘状态、容量、LUN、卷等，光纤交换机的端口状态、流量等最终形成了存储环境的业务逻辑拓扑图。

统一门户展示平台：

通过和合作伙伴通力合作，进一步打造贵州移动统一门户展示平台，首先通过卓豪运维监控系统对基础设施的整体监控，提供基础性能和告警数据，然后通过统一门户平台的集中展示，直观呈现贵州移动大数据中心IT基础设施的整体性能状态。

客户评价：

贵州移动表示：“卓豪的解决方案完全满足我们对监控项目的需求，实施团队专业的实施能力，为该项目顺利落地提供了有利的保障，满足了我们对大数据中心的三个IDC机房基础设施实时监控的需求。后续，我们还要将卓豪IT运维管理系统作为机房租赁服务的增值服务为全省的机房租赁用户提供IT运维管理支持。”

ManageEngine各款产品均提供免费试用和技术支持服务，欢迎来官网下载体验: https://manageengine

综述

日志和监控开发人员工作中必不可少的两只眼睛，日志是为了快速定位排查故障，监控是为了发现潜在问题并能及时告警，是故障诊断和分析的重要辅助利器，同样监控系统对大数据平台重要性不言而喻。在发生事故之前就能预警，最大限度降低系统故障率，是监控的终极目标和价值体现。本文旨在帮助大家了解监控系统，并能快速搭建公司的监控平台。

监控体系

监控粒度、监控指标完整性、监控实时性是评价监控系统的三要素。从分层体系可以把监控系统分为三个层次：

业务层：业务系统本质目的是为了达成业务目标，因此监控业务系统是否正常最有效的方式是从数据上监控业务目标是否达成。对业务运营数据进行监控，可及时发现程序bug或业务逻辑设计缺陷，比如注册失败率、登录失败率、付款失败率等。业务系统的多样性决定了应由各个业务系统实现监控指标开发。应用层：对应用的整体运行状况进行了解、把控，如果将应用当成黑盒子，开发、运维就无从知晓应用当前状态，不能及时发现潜在故障。应用监控不应局限于业务系统，还包括各种中间件、计算引擎，如Spark、Jstorm、redis、zookeeper、kafka等。常用监控数据：JVM堆内存、GC、CPU使用率、线程数、TPS、吞吐量等。一般通过抽象出的统一指标收集组件，收集应用级指标，比如不管是支付系统还是交易系统，都要监控jvm内存使用。系统层：实时掌握服务器工作状态，留意性能、内存消耗、容量和整体系统健康状态，保证服务器稳定运行。监控指标：内存、磁盘、CPU、网络流量、系统进程等系统级性能指标架构设计

工欲善其事必先利其器，根据对现有监控产品的调研，以及我们对监控的分层介绍、所需解决的问题，可以发现监控系统从收集到分析的流程架构：采集－存储－展示－告警：

Telegraf：插件化的指标收集和指标报告服务，能定制化开发并轻松添加所需插件。已经内置了很多常用服务的插件，这也是我们选择telegraf的原因之一，不用再重复造轮子

InfluxDB：高性能的布式时间序列指标数据库。监控指标收集是非常频繁的，否则就失去了实时性，高频收集的结果就是大数据量，也要对时间序列进行分析，InfluxDB就能满足这种应用场景

Grafana：时间序列分析和监控的开放平台，支持多种数据源(InfluxDB、OpenTSDB时间序列数据库)、丰富的展现形式、支持email/dingding报警

Telegraf

go语言编写的插件化指标收集agent，编译成一个没有外部依赖的二进制文件，安装部署很便捷，直接下载、解压就行，默认配置文件在$TELEGRAF_HOME/etc/telegraf/telegraf.conf目录下。telegraf插件分为两大类：input、output。

input：收集inputs配置的所有指标，已内置的input插件：elasticsearch、redis、jolokia等。也可直接收集运行agent server的各种指标，比如内存、cpu、磁盘、磁盘IO、进程、swap等。input配置都很简明易用，一般只需配置服务IP地址就可以，如redis指标收集配置：

如果没有内置收集插件，有两种实现方案：

开发input插件，但这需要有GO语言基础借助于httpjson input插件，该插件请求http url，返回json格式。url配置为自定义指标收集服务，在指标收集服务内实现指标收集功能，然后指标封装成json返回或指标数据直接在服务内入库。我们监控Kettle Carte、spark、jstorm等用的这种实现思路。output：将收集到的度量数据序列化存储，Telegraf指标由四个部分组成：度量、标签、字段、时间戳。支持以下存储结构：InfluxDB、Graphite、JSON，比如度量输出到InfluxDB的配置：

urls：InfluxDB端口

database：存储的数据库

retention_policy：数据保留策略

调度频率：所有指标收集频率是一样的，在配置文件agent项下配置：

服务启动：

--config：配置文件

--config-directory：配置文件目录，如果有多个配置文件时使用

InfluxDB

InfluxDB是为时间序列构建的高性能数据存储，提供类SQL的查询语言、特定分析时间序列的功能。通过设置数据保留策略，自动从系统中删除过期数据，释放存储空间。社区版只支持单台服务器，会有单点故障风险，商业版版支持高可用，对我们来说，单机InfluxDB已经能满足需求。选择InfluxDB的原因：

InflluxDB是用GO写的，编译后是一个完全无依赖的二进制文件，安装部署非常便捷，解压缩包即可高性能时间序列专有数据库，对时间序列的存储和查询都做了优化类SQL查询语言，降低使用门槛数据保留策略可以有效的自动清理过期数据 InfluxDB的数据是以shard groups形式存储，指定时间间隔的数据存储到一个shard groups里，这个时间间隔称为shardGroupDuration。

服务启动：

influx进入shell命令行:

常用命令：

show databases：查看所有数据库

use db_name：进入数据库

show measurements：显示数据库下所有度量

select *from cpu limit 10：查询一个度量的数据

Telegraf默认是将收集的数据持久化到telegraf这个数据库下，每个input对应一个度量表，比如zookeeper的指标数据就在zookeeper这个度量下：

查询数据保留策略：

duration：数据保留时间，0表示无限制，InfluxDB默认30分钟检查一次保留策略。ALTER RETENTION语句修改保留7天数据。

replicaN：每个度量在集群里的副本数，副本保证数据高可用性，社区版(单节点)不支持副本数设置

Java Client：

Java Client对http api进行了封装，底层用Retrofit框架进行http请求，是线程安全的，只需在一个应用中创建一个InfluxDB Client对象。

client的写操作支持batch，其实现原理：1、创建后台单线程定时调度任务，线程每隔一定时间发送请求：

2、每次writer时，把请求放到BlockingQueue队列里，如果队列大于batch数，就启动线程发送请求：

Client Api使用例子: 1、创建数据库连接：

InfluxDB influxDB= InfluxDBFactory.connect(url, user, password);

url：InfluxDB的地址和端口，比如 http://localhost:8086

user/password：InfluxDB的用户名/密码

2、设置访问的数据库：

influxDB.setDatabase(database);

3、数据写入：

Point.Builder builder = Point.measurement(measurement);

builder.tag(tags);

builder.fields(fields);

influxDB.write(builder.build());

Grafana

Grafana是一个指标查询、可视化、监控的开源应用，有着非常漂亮的图表和布局展示，功能齐全的度量仪表盘和图形编辑器，支持Graphite、zabbix、InfluxDB、Prometheus和OpenTSDB作为数据源。

Grafana主要特性：

灵活丰富的图形化组件，包括热力图、直方图、地图等在同一dashboard内可以混合多种展示组件开源社区有大量的插件可供选择，包括数据源插件、图形插件、通知插件可以在同一个视图里使用多个不同数据源简单使用介绍：

安装：下载&解压二进制包配置：配置文件：$GRAFANA_HOME$/conf配置端口号、Email、登录用户start:命令：/opt/grafana/bin/grafana-server start访问:http://ip:port连接数据源、图表开发、报警设置可参看官方文档本文为原创，欢迎分享到朋友圈。

随着智能科技发展的今天，几乎所有的行业客户都将业务系统建立在网络应用的基础之上，互联网的应用与业务的融合给用户带来了巨大的效率提升和持续的竞争力，而在背后默默支撑这一切的都基于大数据深度运算和应用。作为大数据典型产物的人工智能更被誉为人类科技上的一次飞跃。然而，近年来，因遭受互联网攻击而直接导致的经济损失，并呈现出逐年增加的趋势，这无疑给让企业在享受智能改变的同时，也面临巨大的考验。

如果说过去我们反复降调企业用户在互联网安全领域中居安思危，面对安全故障我们应该迅速做出补救修复措施。那么在海量数据面前，企业能承担多少个下一秒的损失呢？

“大数据”时代的来临 ，在安全领域中信息系统的规划，建设，投资等决策将日益基于数据和分析做出判断，而非过去基于经验和直觉的模式。如何采集，分析数据，提供定期的报表统计，包括攻击类型分布，高风险攻击事件统计，安全漏洞发布等。如何直观展现信息系统的实时安全态势，为安全决策提供数字依据成为企业安全运维面临的首要问题。

那么我们应该如何着手建设安全机制方面的运维管理呢？

1 建立信息系统安全事件监测机制，及时发现信息系统安全隐患。

运维阶段中，我们如何及时提前发现异常行为？这是正常用户应该出现的行为吗？该用户是否被控制或穿了马甲？举个栗子：某天某台服务器出现了大量的外联上传行为，进出访问IP中出现大量境外IP，或者CNCERT 通报的恶意IP等。应该如何识别呢？

因此，企业用户需要建立一套有效的安全事件监控和预警措施，能够在信息系统即将遭受攻击，或者已经遭受攻击的同时，迅速精准的发现攻击行为，并且迅速启动处置和应急机制，同时可以对信息系统的安全事件进行综合分析，了解当前整体系统的安全态势，为整体网络与信息安全规划提供有效的数据支持。

2 预先防范，提前做好安全性检查，全面提升主动检测能力。

WEB 应用的安全性成为越来越需要关注的问题，有近40% 的入侵是由于web 应用的问题造成的。在Applied Research 发表的一份调查报告中，企业反馈超过一半的最频繁的攻击是针对web 应用的，这些攻击种甚至有一半在著名的“OWASP 十大威胁”名单中，面对这些持续而频繁的攻击，企业用户需要进行定期的安全检查，及时主动发现信息系统中存在的安全漏洞及潜在威胁。

3 提高安全事件的相应和处理能力。

综合监控中发现的问题，以及在安全检查中对自身系统脆弱性的认识，为应急方案提供依据。同时，根据企业自己的运行情况及行业特性，建立安全知识库，鉴于目前多数企业不具备完全独立处理安全事件的技术能力，企业通常也可以借助专业安全服务厂商提供安全事件的预警，相应和必要的技术支持，提供企业的安全事件处理能力。

4 通过强大的综合分析能力，为信息部门提供数据参考和决策支持。

应随时了解信息系统的运行情况和安全状况，安全态势，在海量数据的基础上，进行综合分析，得出宏观的规律和不同事件相互联系的规律。为信息部门提供强有力的数据参考和决策支持。

关注创联致信，关注更多技术资讯

更多详情请致电

创联致信，中国优秀IT运维服务商

苏宁大数据平台基本介绍

大数据平台运维的痛点及解决方案

痛点1. 部署及运维复杂痛点2. 无资源使用视图

痛点3. 任务相互影响，资源隔离性差

痛点4. 排查问题耗时长，应用优化门槛高

解决1. 平台化、自动化

大数据管理平台：主机管理，集群管理自动化

元数据管理：数据字典，权限申请审批实施自动化

数据流管理平台：集成Flume，智能扩缩容，插件式

数据开发平台：支持10种不同的任务类型，支持任务流/任务管理，解决复杂依赖问题，可扩展

解决2.资源可视化、人民币化

存储/计算资源计量计费

资源池使用可视化

任务展板

解决3.差异化服务、物理隔离

解决4. 智能诊断、优化建议

平台优化及增强

稳定

Hive metaserver 连接数过高的问题

修改bonecp的配置：maxConnectionsPerPartition=1

Spark Streaming & Druid System CPU过高的问题

设置vm.zone_reclaim_mode=0

透明大页导致System CPU过高的问题

echo never >/sys/kernel/mm/transparent_hugepage/defrag

安全

账户/权限体系：每个系统一个账户，不允许跨账户写

Hive metaserver 密码加密

基于User/IP的访问控制策略：RPC层面控制，白名单

skipTrash禁用：防止误删数据

扩展性

结合HDFS的压力、瓶颈问题的逐步优化：

程序优化，扫全表: Hive慎用unix_timestamp方法

小文件合并

YARN日志降低副本至1

YARN日志单独放在另一个集群

Federation + Alluxio 实现统一命名空间

DOING & TO DO

Flink推广OLAP平台建设

流计算消息回溯

多活&灾备

资源统一管理

大数据与医疗

随着大数据技术的发展成熟以及国家对大数据产业发展的支持，搭建大数据平台也不在限与BAT级别的大型互联网企业，越来越多企业或个人参与到大数据行业中，并且已经尝到了大数据和大数据技术带来的甜头。

大数据与旅游

而由于大数据井喷式的发展，作为技术人员，很多的人考虑的是学习大数据开发技术，大数据与业务应用。但技术产业的不断发展成熟，分工也必将越来越明确，尤其是互联网产业，个人是很难完全掌控全局的。

分工明确，环环相扣

大数据产业当中，企业的IT架构不断扩展，服务器、存储设备的数量越来越多，网络也变得更加复杂，从而给运维工作带来了巨大的挑战，特别是分支机构众多的大型企业或垂直层级较多的政府单位，为了保障良好的用户体验和数据时效性，运维工作显得十分艰巨。因此，在大数据集中趋势越来越明显的时代，具备实时采集和海量分析能力的IT运维管理产品将会成为数据分析应用的新增长点。

IT运维产品的发展趋势决定了，要在企业复杂的异构网络环境和系统面前毫不畏惧，有这种实力才能实现业务系统所依托的网络平台资源、服务器资源、应用系统资源、信息服务资 源等进行统一综合管理。

大数据运维需要掌握什么

那么对于本身从事运维工作，或从其他岗位转做大数据运维工程师的朋友，应该掌握哪些技能，才能让我们在实际工作中得心应手，运筹帷幄呢？

linux

首先Linux，对于从事开发工作的朋友，必然并不陌生，即使没有系统学习过，但是简单常用的命令必然了解。但对于想从事大数据运维朋友们，我们必须要进行系统的学习，除了常用的命令，基础的有网络安全、用户、磁盘管理，文件目录管理，系统监测维护；之后是Linux下部署企业中用到的各种服务和构建各种高级服务的方法，特别是系统管理员日常管理工作中常见的问题，最初步的安装到系统的安全和优化，以及各种服务的搭建和管理都有一些小技巧，都必须掌握。

关于Linux这块，作为大数据运维工程师，我们还需要具备Linux下进行进程控制开发、进程间通信开发、多线程开发、网络的开发能力，为后续深入掌握嵌入式Linux驱动和系统编程打下坚实的基础。然后逐步进阶，再通过项目实战，搞定Linux中小规模集群构建与优化。当然这里必须要提一下，需要熟练掌握运用Shell编程。

Redis

作为运维工作人员，常规数据库的操作必不可少，而针对大数据运维，一些高性能数据库必须熟悉，如Redis等。在此基础上，基本可以尝试完成一些大规模集群架构构建了。

Python自动化运维

自动化运维能够大大提高运维效率，而python凭借其灵活性，在自动化运维方面已经被广泛使用，而且服务器规模越大，优势越明显。通过python实现自动监控，系统安全、报表管理，Ansible，Saltstack等等。学习过程中可以可以使用python自动化运维实现大规模流量监控与管理，来体验自动化运维在实际业务场景的应用，提升实际使用能力。

hadoop生态圈

既然是大数据运维，大数据平台集群构建和云计算平台集群构建自然需要熟练，了解hadoop生态体系，有条件的话，可以尝试搭建千万级的高并发大数据网站平台（自学估计比较困难）。针对云计算平台，OpenStack易于部署、功能丰富且易于扩展，应该作为我们重点学习对象。针对这块也有像COA认证等受认可的培训认证，有条件的朋友可以参与，对就业帮助还是非常不错的。

OpenStack

讲了这么多，其实很多本身从事企业网管、技术支持或者硬件网络方面的朋友，对文中的部分内容还是非常熟悉的。对于这类有一定经验基础的朋友，学习起来自然会更轻松。运维工作相对与编码，比较看重人的逻辑思维能力，对于未知情况做出逻辑判断，主动出击，对于沟通、团队能力更加看重。有兴趣的朋友可以尝试深入了解。

大数据时代，“连接一切”将是一个时尚的词句，物物相连，人人相连，人物相连。在这个巨大且复杂的网络中，以大数据、云计算为基础的智能感知世界，让我们张开双臂，拥抱未来，以大数据为基础，精准感知，精准运维。

【IT168 技术】本文根据徐小飞在2018年5月12日【第九届中国数据库技术大会(DTCC)】现场演讲内容整理而成。

讲师简介：

徐小飞，阿里巴巴技术专家，目前就职于阿里计算平台大数据基础工程技术团队，主要负责支撑阿里大数据智能运维体系(公司内部产品名称——Tesla)的建设，团队致力于打造通用的智能化SRE中台，目前该中台运维体系承载阿里10w+规模节点运维工作。

本文摘要：

介绍Tesla如何支撑阿里离线计算和实时计算两大海量大数据平台的标准化日常运维运营，以及探索如何构筑运维领域的知识图谱，打造针对大数据平台和大数据业务的数据化全息投影，实现多维的立体化监控、智能决策分析、自动化执行的运维闭环。Tesla是面向企业级复杂业务系统的数据化驱动运维解决方案，解决方案包含一个统一运维门户(运维工单、运维垂直搜索)和四个运维基础平台(流程平台、配置平台、作业平台、数据平台)，集日常运维工单管理、自动化发布变更、统一配置管理、统一任务调度、智能监控告警管理、异常检测预测、故障自愈等。

分享大纲：

·运维新趋势

·Tesla运维解决方案

·DataOps数据化运维

·数据价值转化

·AIOps征程

演讲正文：

大家好，我叫徐小飞，很开心能够有这样的一个机会在这里和大家交流。今天主要给大家介绍一下围绕阿里大数据体系的的运维智能化实践。

我所在的团队叫大数据基础工程技术，通俗点说就是大数据SRE(为什么起基础工程技术这个名字? SRE文化里有个最核心的点就是使用软件工程的思想来解决运维问题)，我们团队支撑的是整个阿里大数据生态的运维运营，并沉淀出一套自己的运维解决方案体系——Tesla，这套体系是一个分层体系，包含了面向运维领域功能的运维中台和面向具体大数据平台业务的运维应用。目前Tesla承载了阿里大数据平台及业务共10w+规模节点的日常运维工作。相信了解阿里的人都听过这样一个词——“大中台和小前台”战略，同样在运维领域，我们也是利用这个战略来构筑我们的业务：大中台提供通用的运维领域功能，而小前台可以基于业务场景快速试错、创新。首先我们先看下运维的新趋势。

一.运维新趋势

刚好这几天Google IO大会也正在召开，相信在座的很多同学都会关注，今年的大会中有一个很吸引眼球的话题，就是在开场第一天放出来的两段Demo视频，是个电话录音视频，内容是Google助手帮助客户打电话到发廊或餐厅去做预约。那么亮点在哪里呢?在整个电话预约的过程中，发廊和餐厅的人完全没有感知到和他们交流的是AI机器人。换句话说，AI机器人已经达到了以假乱真的效果，不仅在交流过程中有语气词和思考，而且当话题出现中断时，还会提出反问句，能让话题回到机器人所要的情景进行下去。

Google对外宣称在某些特定领域，例如预约领域，他们已经通过了图灵测试。图灵测试大家可以去了解一下，图灵有一篇针对未来机器智能的论文，一句话解释论文里的图灵测试：当人机交互时，人类完全感觉不到对方是个机器人，那么就标志着进入了机器智能的时代。

大概在三年前，Google提出了AI战略。时至今日，我们看到Google在很多领域都渗透了AI，Google的AI并不是做一个全新的AI产品，而是将AI赋能到它的顶尖产品中。所以，我们表面看到的是预约服务，但其实为了达到这个效果是需要很强大的数据+算法的支撑。我们经常提到的ABC(AI，BigData，Cloud)，想要实现AI，前提一定是大数据和云计算，而在运维领域也同样是如此。这两年AIOps特别火，同样地我们认为要实现AIOps，一定是先有运维的数据和计算，就是说从DevOps到AIOps之间，有一段DataOps必经之路。

如何理解DataOps呢?首先，我们要拿数据来感知我们所运维的系统，继而利用数据分析做一些决策，再往下就是去触发自动化的智能闭环。我们认为DataOps中最核心的过程就是运维感知、决策和执行。

我们把无人驾驶和无人运维做了一个类比。无人驾驶也是Google第一个提出来的，现在有很多厂商投身其中，如果细看无人驾驶，其实我们发现与无人运维类似——无人驾驶是在传统汽车上附加智能感知、决策、智能控制系统。但是真正的无人驾驶还没有达到，即使是Tesla(马斯克的特斯拉)也不例外。而终极AIOps想要达到的是也是无人运维的效果，即在DataOps 的感知、决策和执行三个阶段都附加上AI智能。接下来先看下整体的Tesla运维解决方案。

二.Tesla运维解决方案

上面这张图是阿里大数据的体系，左边最底层是基础设施，包含了底层依赖，机房、天基、Staragent;其上有两大基础平台，一个是飞天平台，这是完全自研的，另一个是Hadoop平台。这两套平台之上分别对应的是MaxCompute和StreamCompute两大存储计算平台;再往上是数据应用层。而右边是Tesla大数据运维解决方案，我们可以看到Tesla贯穿了整个阿里的大数据体系，负责从基础设施到基础平台到存储计算平台的所有产品的运维支撑。

简而言之，Tesla就是在为阿里的大数据保驾护航。

MaxCompute是大数据的核心业务，而DataWorks可以理解为是一个面向开发者的前端，是MaxCompute的门户。 MaxCompute基本上承载了集团90%以上的计算和存储。在阿里，凡是和数据打交道同学都会用到DataWorks。StreamCompute承载了集团几十个BU的实时作业。大家可能感触最多的是每年的双11大屏，这背后都是由StreamCompute实时作业传上去的，可以达到秒级、毫秒级。最后是我们内部的机器学习PAI和AnalyticDB。

这张图是Tesla运维解决方案架构图。整个Tesla运维解决方案是一个分层的体系，从SRE中台到SRE应用。整体是一个垂直体系，也可以拿SPI来分，中台最底层是IaaS，IaaS层是最基础的公共集团的设施，之上是核心运维PaaS层，其中包含四大平台+两大类服务。 四大平台与运维人日常的工作相关，分别是配置平台、作业平台、流程事件平台和数据分析平台。再往上就是SaaS层，提供了所有的平台和服务。Tesla平台支撑了阿里大数据的十几个平台，因为每个大数据平台业务产品的运维特性都是不一样的，肯定无法做到一套运维系统支撑所有的产品运维运营，所以我们就采用了分层战略： 运维开发团队提供平台，而针对具体产品的运维应用由SRE同学利用平台去构筑。典型的SRE应用包括常见的集群管理、资源管理、监控告警、故障管理等。在这张图里我们可以看到DataOps体现在数据分析平台这一层。

这张图是应用维度。SRE应用这一层的功能也是分层的，最下面是其所依赖的基础平台，往上是面向业务的功能(包含业务中心、服务管控、平台运营、工具服务、运维中心和运筹优化)，利用这些功能向上支撑具体的运维场景(围绕稳定性、成本、质量、效率、安全以及体验的维度)，最终服务好业务的各类用户。

在运维/运营平台中抽象出了几块内容，开发框架、资源整合、运维数据化和智能分析。因为最终系统都是相似的，所以我们会给提供前后端框架、服务网关、二方依赖包以及工具插件，业务SRE只需在环境上去获取数据，做数据处理、元数据管理以及提供数据查询的服务。运维数据化(DataOps)就是我们前面提到的，智能分析支撑常见的运维场景，比如最典型的故障处理、监控分析、大促保障以及值班客服等，他们面临的客户是一堆客户，这也是DataOps在SRE应用上的体现。接下来我们重点解释到底什么是DataOps。

三.DataOps数据化运维

什么是DataOps?如何做DataOps?阿里五新战略中有一个新能源，我们认为数据就是新能源，现在已经进入到信息爆炸的时代，大家刷淘宝天猫时的每一次行为都会触发日志，这些日志最终都流到我们的平台里。如此海量的数据，如果能有效的组织管理好，那么就可以从中挖掘出价值，但如果管理不好，就可能会是个大灾难。

算法+技术，再结合数据就会产生新能源，而现在比较通用的数据挑战是我们怎么有效的去收集、清洗数据?如何保证数据的实时性、准确性?如何将无序的、没有结构的数据有序、有结构的分类、组织、存储管理起来?如何通过算法去打通数据，连接、分析数据，并从中提炼出价值?这一系列的问题就是DataOps需要解决的。

什么是数据化运维? 我们这样定义：就是把所有系统的运维数据全部采集起来、真正打通，深度挖掘这些数据的价值，为运维提供数据决策基础和依赖。 从系统“稳定性、成本、效率、安全”多个维度去驱动自动化、智能化的运维运营，从而助力实现真正的AIOps。

相比于传统运维，DataOps的改变可能就是把传统的使用命令、人工决策的运维过程转变成数据+算法的模式。

DataOps是实现AIOps的一个必经之路，是一个运维闭环。如何做数据化运维呢?右边这张图来自《大数据之路》这本书，当然这张图说的是阿里整个的数据中台，阿里数据中台把全公司所有和数据相关的东西都整合了起来，提供了一套统一的数据中台。其中，最下面是数据采集层，往上是数据库同步工具，中间是MaxCompute和StreamCompute，也就是数据存储计算层，最上面是数据服务层和数据应用层。

数据中台中的方案体系是OneData，它是用来规范数据中台，如何维护、组织、管理和使用数据的。OneData之上是OneService，有了这套组织管理和两大计算平台之后，就可以提供各式各样的数据服务，并再向上提供数据应用。在阿里，基本上所有的业务部门都是按照这个套路来做的。

如何做数据化运维?其实就是利用这套大数据体系来构筑大数据的数据化运营体系。这句话可能有点难以理解，更直白一点说，这套体系是由我们来运维保障的，但是过程中我们也利用其来构筑了运维运营体系。因为我们的使命是为阿里大数据保驾护航，而我们的做法也是用阿里大数据来做运维分析，数据化运维分解下来就是运维的数据采集、运维的数据计算、运维的数据服务以及运维的数据应用。

前面讲的是方法论，现在讲讲具体的实操。利用数据中台，我们首先做的是按照OneData规范建立运维的数据仓库，然后把所有运维相关的数据做分类抽象，包含公共数据、业务数据、元数据，runtime实时数据。基于这些数据抽象，我们提供了大量的运维服务和数据服务，比如异常检测分析、故障自愈、可视化流程、运维搜索、运筹优化、全链路诊断以及业务驱动。下面结合几个例子来具体解释下如何做数据化运维。

以全链路分析诊断为例，MaxCompute是一套离线计算平台框架，每天有百万级的任务在跑，这些任务都是由开发同学提交，当作业因为各种原因出现不可预知的错误，大家就会@运维值班人员看看是哪里的问题。后来我们发现，大部分问题是相似的，所以就总结经验，从用户都在这个平台上提交作业到最后执行的每个阶段都去打点、采集分析，做了一套全链路作业诊断工具。

这是一个自助式的全链路诊断产品，提供一个入口，用户只要输入作业ID，我们就能延伸到整个上下游去查询所有的有可能的问题，包括它的资源申请情况、配置是否正确、数据依赖是否都已满足、历史情况如何、是否有长尾倾斜等等。

上图中有我们工具的页面截图，可以看到左边是有分类的，其实在做这个全链路分析工具的时候，我们就把这个场景和去医院体检做了个类比，体检时医生要针对病人的各个环节做判断，然后输出病人的状态，OK还是不OK?如果有问题，立即提出来让病人去某诊室随诊。同样的，我们也是针对作业做了多个维度的检测，而且还会将诊断详情、时间分析、图表分析以及历史对比等，全部都透视给用户。最后的结果报告是用图表分析的，例如稀疏图形资源争抢，毛刺图形部分长尾、任意机器进程CPU消耗分析。

第二个案例场景是硬件自愈，目前我们已经有10万+台物理机了，每天有大量的硬件故障在发生，比如硬盘坏了，主板坏了等等。如果机器比较少，那么我们可能人肉或者直接提单就可以了，但是当量级到了一定程度，每天几十单或者是上百单的硬件故障，这种方式就不适用了。

所以我们就利用这套数据化的思路做了一个硬件自愈的流程。我们也是从服务器上采集到数据，然后流进流计算平台Blink再到数据仓库，做检测分析并得出决策。决策触发流程平台做一些自动化执行的action，调用集群操作系统去做机器维修等。

硬件自愈的本质也是一个三阶段的闭环，在这其中我们的角色有很多。例如有些故障重启一下服务或者双向配置即可解决，而有些故障需要使用万能大法，重启机器才能解决。如果碰到解决不了的问题就要进入无盘状态，去做业务隔离、重新克隆、整机维修，维修完之后自动上线。整套流程全部是自动流转，我们是无人值守的状态。

四.数据价值转化

通过前文的方法论和两个案例，我们大概解释了一下如何做数据化运维，接下来，我们再透视一下数据化运维的本质——从运维数据到知识的价值提取。

这里会涉及到几个概念，数据化运维的前提是先将一切对象数据化，也就是运维的全域数据，构筑完之后，使用知识图谱将这些数据连接起来，之后将数据当做服务提供给人，利用运维搜索去提供一些快速直达的服务。...