我可能永远也没办法成为全栈工程师了，看看你还差多少？( 二 ) _全栈

至于技术，不胜枚举：

数据接入已经从十年前的库表文件导入或者业务录入转化成多元化的数据接入技术。除了传统的TCP和UDP数据接入外，爬虫也大行其道；至于商业化公司如elastic公司的elkb这种体系化的数据接入和处理流程也是深受欢迎。
数据处理处理传统的java外，数据处理已经从第一代的mapreduce、hive、storm以及impala框架进化到了以spark或者flink为主的新一代批流一体化的框架所代替。而且这些框架也互有攻守，无法形成一家独大的行业标准。
数据存储已经不是之前的sql以及jdbc的行业标准，而变成了以数据库为导向的不同api的操作，虽然现在都在推SQL标准在不同数据库的落地，但是大部分的情况下，还是需要使用不同的api进行各种操作，学习成本可见一斑。
数据挖掘就不多说了，之前基本上就没有。随着大数据时代的来临，机器学习以及人工智能大行其道。这对于一个人的综合实力的要求还是很高的，尤其是各种数学以及算法，真正考验基本功了。我也开始理解为什么很多算法岗位的招聘要求是211、985硕士甚至博士起，因为没有长时间的基本功沉淀是真的搞不定啊。而作者确实也”不负众望“，从入门到放弃仅仅用了一周的时间。

前端现在的前端以及分网页端和移动端的双端了，而且前端的全栈的要求已经是端到端了，即从移动端到网页端的业务和数据的处理和展示。
至于技术，也是五花八门，作者不是很熟悉前端，这里就不多说了。当初作者放弃前端的一个原因就是因为前端的内容多于繁琐和复杂，而现在更是有过之而无不及。
数据库这算是作者的老本行了，最近这些年基本上都是以这个为基础结合上下游来展开工作。当前的数据库已经不是当年的数据库了，不仅种类多了很多，而且单一种类也有很多不同的产品应对不用的业务场景。更麻烦的是，每个数据库产品都无法覆盖所有的场景，而且很多数据库之间都有交叉，没办法做到one db to rule them all！这无疑极大地增加了学习成本。
下面就是现在的数据库分类：

SQL
NoSql
NewSql
GraphDB

细节的分类和数据库就不多说了，因为实在是太多了,而且新的数据库也是层出不穷，更过分的是每个数据库基本上都有受众，也都能火那么一段时间，大部分也仅仅就是那么一段时间，但是对于从业者来说大多数时候真的是痛并“快乐”着....
运维之前的运维玩明白linux和一个主流的运维软件即可。现在的运维真的是玩出花了。
之前的虚拟化已经难堪大用，云计算和云平台登上了历史舞台，公有云和私有云遍地开花；再后来是以Docker为首的容器掀起了容器化的浪潮；再后来云原生横空出世，甚至抛出了“一切皆可云原生”的豪言壮语。
当前的运维已经慢慢形成了以K8S为首的容器编排与管理，istio等一系列service mesh作为辅助的运维体系，在这个体系周围衍生出的技术也不胜枚举。运维小哥哥再也不能一招鲜吃遍天下了，而对于研发人员来说，想跨界搞专业运维的难度和成本也越来越高
至于监控，虽然Prometheus+grafana在大多数场景下都是标准选择，很多组件也都有响应的扩展包来支持在上述二者上的部分监控。但是多数情况下，很多专业的监控以及运维还是需要定制化的监控界面，甚至很多大厂都自行开发监控和运维工具以求更精准和有效的运维。
总结曾几何时，作者的理想也是做一个全栈工程师。但是十年之后笔者才发现，原来当初刚刚怀揣这个理想的时候竟然是离目标最近的时候。
这里面固然有作者水平有限的问题，但是更深层次上的是技术和业务的发展速度已经大大地超出了预期。此一时彼一时，当前的技术广度大大增加，而技术密度却逐渐降低。一招鲜吃遍天下或者一个架构搞定一个行业的时代早已不复存在了。
而此时的全栈已经很难和当初的全栈相提并论，能做到细分领域的全栈或者一专多能已经相当不易了。但是理想还是可以有的，能不能实现不重要，能作为前进的动力就好。
白月光虽好，但总是遥不可及；朱砂痣若有，牢牢把握住就好！
全栈不死，只是凋零；不是全栈淘汰了我们，而是时代淘汰了全栈！
文章到这里就结束了，最后路漫漫其修远兮，大数据之路还很漫长。如果想一起大数据的小伙伴，欢迎点赞转发加关注，下次学习不迷路，我们在大数据的路上共同前进！