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

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

早些年



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



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



早些年在大数据没有普及的时候，人们选用的方案一般是，另外搭一套数据仓库，使用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，却可以省下大量的数据架构、数据开发的工作量。会不会有的企业，直接选择了这些“看起来昂贵”的数据库，而废掉那个还在建设中、却迟迟不产出成果的大数据团队呢？



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