Java后端开发工程师是否该转大数据开发?
撰写我对java后端开发工程师选择方向的想法,写给在java后端选择转方向的人
背景
看到一些java开发工程师,对java后端薪酬太悲观了。认为换去大数据领域就会高工资。觉得java后端没有前途。我从事java后端开发,对大数据领域工作有些了解,但不深入。本文描述一下我对java后端和是否转大数据开发的个人见解。
目的
- 分析大数据领域分类
- 分析大数据工作工资高的原因
- 分析造成觉得java后端开发不够前景的原因
- java后端转大数据工作做什么
- 转去大数据领域的各类方向与java后端比较衡量
点赞再看,关注公众号:【地藏思维】给大家分享互联网场景设计与架构设计方案 掘金:地藏Kelvin https://juejin.im/user/5d67da8d6fb9a06aff5e85f7
一、大数据领域工作我认为分4类
类别 | 业务开发 | 架构组 |
---|---|---|
1数据处理 | ETL、爬虫 | 未知 |
2数据统计 | 实时流式计算、离线流式计算、Elastic-search分词统计 | 架构研究spark hadoop源码开发数坊系统、shuffle优化。 |
3数据分析 | 基于mahout、sparkStream 做机器学习、自然语言 | 性能优化 |
4数据算法/建模 | 推荐算法、用户画像、风控建模 | 未知 |
二、大数据领域工资高的原因
大家看到大数据工资高,其实是大数据领域包含了建模或者算法工程师那部分。高工资的就只有推荐算法、用户画像、风控建模、自然语言这些工作,职位为算法或者建模工程师。
然而大数据领域的大部分工作,都是上图表中,第1、2类的工作,如:etl、爬虫、实时离线流式计算,es、顶多就机器学习。即使这些工作也只是工程级的应用(换句话说就是写业务代码,搬砖),如果工资高也是有架构能力(提升spark性能之类),而不是大数据应用开发。
三、分析造成觉得java后端开发不够前景的原因
有人觉得java后端开发工资低,没有前景,没有适应时代。
第一、大数据时代很久了,很早就开始招大数据了,不是需求火爆的状态,如安卓工程师一开始火,如现在做的人多了,像安卓变多了,大数据的应用开发就不像2014年刚开始的时候那么高工资了,但是大数据中算法、建模工程师依然高薪,那种要求高质量高的工作都是10个人里面只有1个会的那种。
第二、很多java后端开发都是业务开发,写好业务没bug渡过一天又一天,没有遇到好项目或者没有自主学习,导致做了很久的java开发工程师,都是做业务,写CRUD、redis、mq等,会写代码是一回事,但是有没有好的技术方案就是另外一回事。
四、Java后端转大数据工作做什么
java换去做大数据其实只能做etl、爬虫、实时离线流式计算,es、顶多就机器学习这些工程级的应用,也就换套工具写业务代码,换套工具搬砖而已。
因为Java开发人员多数是使用、应用程度,而不是研究程度,所以Java工程师转大数据很少有人会做到第3、4类的工作,如果做第3、4类估计是重新开始了。
其实第1、2类这些工作薪酬跟java后端没什么区别,毕竟两个领域都有纯业务搬砖和自带技术体系的人。
这些大数据工程级应用(第1、2类),也有架构组,如同java后端一样,也有业务架构和基础架构。其实如果积累经验java后端和这些大数据晋升我认为是一样的。
举例
假如表中的第2类,大数据工程级应用做spark、hadoop,一种是做应用开发,如双11在页面显示华为、小米等品牌实时出货量多少,就用实时流式计算。 另一种属于架构工作,如开发个数坊系统(也叫数据仓库、DataWareHouse)出来让大数据应用开发同事在上面做 OLAP。这些架构组的人,一般需要对hadoop、spark、presto源码有过研究,或许会在上面二次开发,或者进行性能优化工作。 前者是换套工具搬砖,后者是架构组。如同java也有些业务代码和架构设计。
五、转去大数据领域的各类方向与java后端比较衡量
考虑方向
- 要么转做大数据架构,如研究spark、hadoop、presto,搞个数坊系统(又叫DataWareHouse、数据仓库)、shuffle调优等,毕竟属于架构组,工资会高一点。
- 要么转做推荐算法、用户画像、建模/算法类。而这部分工作都是有要求的,算法过硬、研究生、985、211 、数学专业,这些工作也会更高。数据挖掘与分析不止会mathot、spark streaming,还有SAS/SPSS 。
- 如果转做大数据应用做实时流式计算、离线流式计算、es分词统计,其实是相当于业务码农,如果有java后端开发经验的话,这种那还不如在java后端继续深耕,毕竟换去做大数据应用开发深耕也是一样的。
考虑晋升机会
-
考虑另一部分,能晋升到领导位置的,一般是伴随公司成长的核心员工。公司成长,开始是业务,一般都是java后端业务代码。等到中期、后期做报表才会用上大数据业务开发(第1、2类),有性能问题就会有架构组,再后期才到推荐算法这些让app更好体验的东西,如淘宝首页推荐。所以业务架构在前期就比较容易晋升。
-
等公司成长起来了,公司有钱自然就会招很好的算法、建模工程师做真正有价值的部分。 而实时流式计算、elastic-search这些业务码农,也只是搬砖,现在做的人像安卓一样多了,就不像2014年刚开始的时候那么高工资了。
考虑所在城市的岗位数量
如第3、4类工作,岗位比较少,换公司换工作是否方便,有些公司如:中国移动 的第3类大数据工作就有外包出去,不是正式编制。 画好跳槽路线,因为转行第一间不一定是你的终点,所以要看其他的更上流的企业的要求是否能匹配自己。
BackUp作用
- 多学大数据只是防止当前公司业务停止,没有业务开发时,java后端开发工程师可能被裁员掉,学大数据和前端React.js类只是对于java后端开发另谋活路的backup。因为有些职位就希望你全栈,但现在很多都前后端分离的。
- 而被淘汰掉的java后端只是写业务代码,用用redis、mq。
- java后端人人都会写,java后端技术领域还是很广的,但有没有写出好的技术方案就另外一回事。
总结
大数据、前端页面开发对于java后端开发工程师来讲,我觉得了解就可以了,知道有解决办法,不必每个领域都精通,况且没办法每个领域都精通。
如果后端开发转去做大数据、项目经理、产品经理岗位,估计都是java后端技术没做上去(本身不喜欢做程序员的也有可能),或者是只会做纯业务代码这些被淘汰掉了,所以就换领域了,还有转hr的。 不过同级别的java后端开发和产品经理薪资确实有差距,估计一两千。
我觉得大数据工程级应用开发(第1、2类)和Java后端开发薪资就没什么差距,以前java后端能转大数据应用开发,是因为那时候还缺人,现在不缺人了,要招都是招有真实经验的。
如果你从事java后端开发几年了,要转大数据领域,相当于你有一个升高级java开发工程师的机会,还是选择中级大数据应用开发工程师的机会,反正都是写业务代码的。
如果你的条件过硬,如985/211学历、数学专业、算法研究经验,如果要转算法/建模工程师就早点转,大数据领域高工资的就是这类人。
如果java后端开发工作经验4以上年了,没有硬性条件,建议继续深入后端学习。
如果java后端开发工作一两年,你想怎么转都可以。
如想了解薪酬,可以在招聘网站搜大数据工程师(一般就是指第1、2类的),和算法工程师、风控建模工程师、推荐算法工程师、用户画像工程师。我所知道有个风控建模经理三万多。
欢迎留言跟我讨论
欢迎关注
我的公众号 :地藏思维
掘金:地藏Kelvin
简书:地藏Kelvin
CSDN:地藏Kelvin
我的Gitee: 地藏Kelvin https://gitee.com/dizang-kelvin
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
spring cloud系列教程第一篇-介绍
spring cloud系列教程第一篇-介绍 前言: 现在Java招聘中最常见的是会微服务开发,微服务已经在国内火了几年了,而且也成了趋势了。那么,微服务只是指spring boot吗?当然不是了,微服务需要治理,需要监控等等一系列的组件。这就诞生了spring cloud。从本篇开始,凯哥(凯哥Java:kaigejava)将和大家分享spring cloud系列教程。凯哥将和大家分享2020年之前的spring cloud热门技术。还要会和大家分享2020年比较火的spring cloude Alibaba相关的组件。好了,我们言归正传. 本文主要内容:1:微服务介绍;2:分布式体系常用的几个维度;3:spring cloud以及2020年开始升级的替代技术。 本文是由凯哥(凯哥Java:kagejava)发布的《spring cloud系列教程》教程的第一篇:《spring cloud系列教程第一篇-介绍》。 一:微服务介绍: Martin Fowler在2014年3月份对微服务的定义: 翻译: 微服务架构是一种架构模式,它提倡将单一的应用程序划分成一组小的服务,服务之间相互协调...
- 下一篇
使用TiDB把自己写分库分表方案推翻了
背景 在日益数据量增长的情况下,影响数据库的读写性能,我们一般会有分库分表的方案和使用newSql方案,newSql如TIDB。那么为什么需要使用TiDB呢?有什么情况下才用TiDB呢?解决传统分库分表的什么问题呢?还会解释一些关键点和踩坑点。下面我会用比较白话的形式解读,当做对TiDB进行推广。 目前痛点 目前分库表无论使用原生JDBC+ThreadLocal方案,还是使用中间件proxy、还是SDK嵌入代码的形式,即使用sharding-jdbc、zdal、mycat都存在着以下问题。 分库分表算法方案的选型 分库分表后带来的后续维护工作,每次增加节点,都需要申请磁盘、机器 新增节点需要进行停机、然后迁移数据,停机迁移对线上用户造成实时的读写影响。迁移失败还有代码回滚。迁移前还要等mysql没有binlog产生后才能迁移。 分库分表后,跨库一致性问题,都是使用最终一致性,代码维护繁琐。 数据存储压力、数据存放量偏移于某个节点 数据索引查询效率:即使是分库了,要走索引查询,其实还是需要查询多个库后得出结果后汇聚的。 不支持跨库left join其他表 唯一索引在跨库跨表不能保证唯一,...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- CentOS7,CentOS8安装Elasticsearch6.8.6
- CentOS6,CentOS7官方镜像安装Oracle11G
- CentOS7编译安装Cmake3.16.3,解决mysql等软件编译问题
- SpringBoot2编写第一个Controller,响应你的http请求并返回结果
- CentOS8编译安装MySQL8.0.19
- SpringBoot2配置默认Tomcat设置,开启更多高级功能
- Windows10,CentOS7,CentOS8安装Nodejs环境
- Docker快速安装Oracle11G,搭建oracle11g学习环境
- CentOS8,CentOS7,CentOS6编译安装Redis5.0.7