我嗅到了数据开发工程师的危机

发布于: 2020 年 06 月 24 日
我嗅到了数据开发工程师的危机

统计分析类数据的技术选型趋势

早些年

企业创办初期,为追求产品的快速迭代,往往不会花太多的精力和成本在统计分析类的数据上。

当某一天,数据分析被重视起来的时候,往往会面临一个巨大的问题:数据结构需要重新设计。满足业务需求的数据结构设计,和统计分析的场景差异甚大,强行使用同一套数据结构,会导致资源的紧张或是资源的浪费,若不进行分离,甚至还可能影响线上服务。

早些年在大数据没有普及的时候,人们选用的方案一般是,另外搭一套数据仓库,使用ETL工具将线上的业务数据同步过来,做分析、做报表。那个年代比较流行的是Oracle,比较吃香的岗位是Oracle的DBA。

后来

那时候Hadoop开始流行,一夜之间,所有人都在大谈特谈“大数据”、“分布式”、“Hadoop”、“MapReduce”。一些行动迅速的公司,开始逐步将Oracle上的数仓转移到Hadoop平台中,改用MapReduce或是当时还不够成熟的Hive来做离线数仓。

毫无疑问,分布式的Hadoop是有优势的。

仓库深处的那些低配置的小服务器,被运维拍了拍灰、拿了出来、放到了Hadoop集群里,充分地派上了用场,避免了被低价卖掉的命运。

MapReduce早期,学习成本是比较高的。但是Hadoop里出现了一个仅靠SQL语言就可以熟练使用的产品Hive,使得学习成本也极大的降低。

…………

以上诸多因素,都使得Hadoop方案的离线数仓盛极一时。这一时期,大数据开发工程师的招聘需求铺天盖地,薪资远高于普通的Java或C++开发。

近些年

不得不说,人都是越来越懒的。

使用Hadoop这样一个低成本的技术方案,大家也会希望有配套的ETL、任务调度、数据字典、血缘关系等等的服务。于是给了阿里云、AWS等云厂商机会,构建一套完善的大数据离线数仓的生态体系(例如阿里云的DataWorks),让数据开发人员能更专注于业务本身,减少甚至消除了后顾之忧。

后来,人们变得更懒了。懒到不想把精力花在数据仓库的建设上,想直接选用一款先进的数据存储,既做线上业务交互,又做数据的统计分析。于是,AWS做了aurora,阿里云做了PolarDb。云原生、存储计算分离等标签被打在上边,让开发者既可以做线上高并发、低延时的交互,又可以快速实现极低并发的数据分析,同时又避免了对线上业务的影响。

这一时期,部门企业意识到,不依靠传统的大数据技术,也可以做数据分析。从开发部门找一个SQL写得6的开发出来,就能搞定全部的数据分析需求。大数据行业,从火热到爆炸,逐步进入冷静期。

最近

实时数据分析,如果用刚才的PolarDb或aurora方案,只能极低并发。稍微高一点儿,就会对线上资源造成影响,造成严重的后果。所以又回到了“每跑一次数据,精神都十分紧张”的时代。

当然这个问题不能就这样放着,各大云厂商专门针对实时OLAP场景做了大量的新产品(例如:ClickHouse、阿里云的Hologres等等)。这类产品都有一个共同的特别:贵。

没办法,毕竟高性能都是靠堆CPU、堆内存堆出来的。

相应的,为了解决“懒”的问题,各大云厂商们把数据同步弄得越来越简单,甚至只需要简单地一键配置,数据就可以从线上业务库,低延时地同步到实时OLAP数据库中。

写在最后

云厂商的一系列新产品的推出,虽然让数据开发工程师们尝到了甜头。但是我们也可以从中敏锐地嗅出一丝危机的气味。

当技术越来越便利,免不了会导致一部分人失业。一个数据开发工程师,薪资大概10~20K,而一个大数据团队往往需要5人、10人甚至更多的人。而这些先进的OLAP数据库,每月的成本也就10~20K,却可以省下大量的数据架构、数据开发的工作量。会不会有的企业,直接选择了这些“看起来昂贵”的数据库,而废掉那个还在建设中、却迟迟不产出成果的大数据团队呢?

或许,下一个失业的,就是那些脱离业务、只做数据开发的工程师们了。

发布于: 2020 年 06 月 24 日 阅读数: 9
用户头像

无箭的丘比特

关注

带着同理心,追求完美 2018.07.07 加入

某创业公司大数据团队TeamLeader、阿里云MVP、一名普通的技术人、四只猫主子的铲屎官。从技术开发,走到技术管理。分享一些心得,供大家品味。

评论

发布
暂无评论
我嗅到了数据开发工程师的危机