什么技术才值得你长期投入? | 凌云时刻

article/2025/8/23 2:32:32

凌云时刻 · 洞见

导读:“每个人的时间都是有限的,在有限的时间里选择一项值得投入的技术会变得尤为重要。”那么,如何去选择一个值得投入的技术?一个值得长期投入的技术又具备哪些特性?

作者 | 简锋

来源 | 凌云时刻(微信号:linuxpk)

三大维度

笔者从 2008 年开始工作到现在也有 12 个年头了,一路走来都在和数据打交道,做过很多大数据底层框架内核的开发(Hadoop,Pig,Hive,Tez,Spark),也做过多年上层数据计算框架(Livy,  Zeppelin)以及数据应用开发,包括数据处理,数据分析以及机器学习。现在是 Apache Member 以及多个 Apache 项目的 PMC 。2018 年加入阿里巴巴实时计算团队专注在 Flink 的研发。

        

今天我想结合自己过去的职业经历来聊聊如何评估一项技术是否值得学习。我一直在大数据这个圈子,从最初的 Hadoop 到后来的 Hadoop 生态项目 Pig,Hive,Tez,然后又到新一代的计算引擎 Spark ,再到最近在做的 Flink ,大数据计算引擎贯穿我的整个职业生涯。我个人来说是比较幸运的,在每个阶段都在做比较火的技术,当时更多的是凭着自己的兴趣和直觉在选择技术类型。现在回过头来看我觉得需要从下面 3 个大的维度来评估一项技术是否值得学习。

 

  1. 技术深度

  2. 生态广度

  3. 进化能力

     

   

技术深度

技术深度是指这项技术的根基是否扎实,护城河是否够宽够深,是否很容易被其他技术所替代。通俗的来说就是这项技术是否解决了其他技术所不能解决的有重要价值的问题。这里有两个要点:

 

  • 这个问题没有人能解,是这项技术首先解决了这个问题。

  • 解决这个问题能够带来重大价值。

拿我职业生涯开始阶段学习的 Hadoop 为例。

当时 Hadoop 刚出来的时候是一项革命性的技术,因为当时除了 Google 宣称自己内部有一套 GFS 和 MapReduce 系统外,业界其他公司都没有一套完整的海量数据解决方案。而随着互联网技术的发展,数据量与日俱增,处理海量数据的能力迫在眉睫。Hadoop 的诞生正好解决了这一燃眉之急。

 

随着技术的发展, Hadoop 的处理海量数据能力的优势慢慢被人习惯,相反 Hadoop 存在的缺陷被人不断诟病(性能差,MapReduce 编写复杂等等)。而这时候Spark应运而生,解决了 Hadoop MapReduce 计算引擎的顽疾。Spark 远超过 Hadoop 的计算性能以及极其优雅简单的 API 迎合了当时用户的需求,受到了广大大数据工程师的热捧。

 

现在我在阿里巴巴从事的是关于 Flink 的研发工作,主要原因是我看到了工业界对实时性的需求以及 Flink 在实时计算这个领域的霸主地位。之前大数据遇到的最大挑战在于数据规模大(所以大家会称之为“大数据”),经过工业界多年的努力和实践,规模大这个问题基本已经解决了。接下来几年,更大的挑战在于速度,也就是实时性。而大数据的实时性并不是指简单的传输数据或者处理数据的实时性,而是从端到端的实时,任何一个步骤速度慢了,就影响整个大数据系统的实时性。

 

在 Flink 看来, Everything is stream 。Flink 的以 Stream 为核心的架构是业界独一无二的,由此而产生的性能优越,高扩展性,端到端 Exactly Once 等特性,更是使得 Flink 在流计算领域是当之无愧的王者。

 

目前主流的流计算引擎有 3 个:Flink、Storm 和 SparkStreaming 。

 

注:Spark Streaming 只能选择搜索字词,理论上这样的对比是不严谨的。但作为趋势,我们更关注的是其变化曲线,实际影响应该不大。

 

从上面的 Google trends 曲线可以看出,Flink 处在一个快速增长期, Storm 的热度在逐年下降,而 Spark Streaming 几乎进入了平台期。这就证明了 Flink 在流计算领域的根基之深,目前来看还没有谁可以超越 Flink 在流计算领域的霸主地位。

 

生态广度

一项技术只有技术深度是不够的,因为一项技术只能专注于做好一件事情,如果要解决实际生活中的复杂问题,必定要和其他技术整合联动,这就要求这项技术具有足够宽的生态广度。

生态的广度有 2 个维度可以衡量:

 

  1. 上下游生态:上下游生态指从数据流的角度来说的数据上下游。

  2. 垂直领域生态:垂直领域生态是指某个细分领域或者应用场景的整合。

 

 

当 Hadoop 刚出来的时候只有 2 个基本的组件:HDFS 和 MapReduce ,分别解决了海量存储和分布式计算的问题。但随着发展,需要解决的问题越来越复杂,HDFS 和 MapReduce 已经不能很方便的解决一些复杂问题,这时候 Hadoop 的其他生态项目应运而生,比如 Pig,Hive,HBase 等等从垂直领域生态这个角度解决了 Hadoop 不容易或者不能解决的问题。

 

Spark 亦是如此,一开始的 Spark 是要替换原来的 MapReduce 计算引擎,后来 Spark 发展了各种语言接口,各种上层框架,比如 Spark SQL,Spark Structured Streaming,MLlib,GraphX 等等,大大丰富了 Spark 的使用场景,扩展了Spark的垂直领域生态。Spark 对各种 Data Source 的支持,更是让 Spark 这个计算引擎和存储结成了联盟,建立了强大的上下游生态系统,为端到端的解决方案奠定了基础。

我现在做的 Flink 项目的生态仍然处于起步阶段,当时我加入阿里巴巴,不仅仅是看到了 Flink 作为流计算引擎的霸主地位,更是因为看到了 Flink 生态的机会。大家如果从我的职业生涯来看,会发现些许变化,我在从一开始专注于大数据的核心框架层慢慢在往周边生态项目发展。一个主要的原因是我对整个大数据行业的判断:大数据上半场战斗集中在底层框架,目前已经接近尾声,未来的底层大数据生态圈中将不再有那么多的新的技术和框架,每个细分领域都将优胜劣汰,走向成熟,更加集中化。下半场战斗的重点讲从底层走向上层,走向生态。之前的大数据创新更偏向于 IAAS 和 PAAS ,未来你将看到更多 SAAS 类型的大数据产品和创新。

 

每次谈到大数据的生态,我都拿出上面这张图。这张图基本上把你日常需要处理的大数据场景都包括进来。从最左边的数据生产者,到数据收集,数据处理,然后再到数据应用(BI + AI)。你会发现 Flink 可以应用在每一个步骤。不仅涉及到大数据,也涉及到 AI ,但是 Flink 的强项在于流计算处理,在其他领域的生态仍在起步阶段,我个人正在做的工作就是完善 Flink 在上面这张图上端到端的能力。

   

 

进化能力

 一项技术如果技术深度和生态广度都没有问题,那么至少说明这项技术在当下是值得学习的。但是投资一项技术还需要从时间这个维度上考量。你肯定不希望自己学习的技术很快就被淘汰,每年都要去学习一项新技术。所以一项值得投资学习的技术必定需要具有持久的进化能力。

 

我最初学的 Hadoop 到现在已经 10 多年了,现在仍然被广泛使用着。虽然现在有很多公有云厂商在抢占 Hadoop 的市场,但你不得不承认如果一家公司要成立一个大数据部门,第一件事恐怕就是建一个 Hadoop 集群吧。当我们现在谈论 Hadoop 的时候,他已经不是当初的 Hadoop 了,他更多的是 Hadoop 生态圈的统称。大家有空可以看看 Cloudera CPO Arun 的这篇文章【1】,我对其中的观点非常认同。

 

Spark 项目就更不用多说了。Spark 经过 14,15 年爆发,现在已经进入平稳期。但是 Spark 仍在进化,仍在拥抱变化。Spark on K8s 就是 Spark 拥抱云原生的最好佐证。现在 Spark 社区炙手可热的Delta,MLFlow 更是 Spark 的强大的进化能力的佐证。现在的 Spark 也不仅仅是当年要取代 MapReduce 的那个 Spark ,更多是一个适用于多种场景的通用计算引擎。

 

我从 18 年加入阿里巴巴到现在差不多 1 年半时间,在这一年半的时间了,我正好见证了 Flink 的进化能力。

首先 Flink 经过几个大版本的发布,融入了 Blink 的大部分功能,将 Flink SQL 的能力提升了一大截。

其次 Flink 对 K8s 的支持,对 Python 的支持,对 AI 的支持都在向人们证明这Flink自身强大的进化能力。

 

小 Tips

除了以上的 3 大维度,在这里我还想分享下我在评估一项新技术时候的一些小技巧。

 利用 Google Trends

Google trends 能很好的反映一项技术的发展势头,上面提到的趋势图很好的比较了 3 大流计算引擎 Flink , Spark Streaming 和 Storm ,我们不难得出结论:Flink 是流计算领域的王者。

 查看 GitHub 上的 awesome

一项技术受欢迎的一个指标是 GitHub 上的 awesome list,你可以看看这个 awesome list 的 GitHub star 数。此外你可以抽一个周末的时间看看这个 awesome list 上的内容,因为上面基本上是关于这项技术的精华内容,通过这些内容你大致可以判断出这项技术的价值。

 看技术布道趋势

技术圈里通常有这样一群人,他们对技术很执着,也很有品位。如果一项技术真的很好,那么就会有技术布道者无偿的为这项技术背书,分享如何这项技术的使用心得。技术布道者经常在一些科技论坛进行分享,我个人经常会看medium.com。

总结

每个人的时间都是有限的,在有限的时间里选择一项值得投入的技术会变得尤为重要。

 

以上是我对如何评估一项技术是否值得学习的一些思考,也算是对我自己事业生涯在技术选型方面的一个小小的总结和回顾,希望我的这些思考能对大家的职业生涯有所帮助。

【1】:Hadoop is Dead. Long live Hadoop. By Arun C Murthy

https://medium.com/@acmurthy/hadoop-is-dead-long-live-hadoop-f22069b264ac

作者信息:

章剑锋(简锋),开源界老兵,Github ID:@zjffdu,Apache Member,曾就职于 Hortonworks,目前在阿里巴巴计算平台事业部任高级技术专家,并同时担任 Apache Tez、Livy 、Zeppelin 三个开源项目的 PMC ,以及 Apache Pig 的 Committer。有幸很早就接触了大数据和开源,希望可以在开源领域为大数据和数据科学做点贡献。

END

往期精彩文章回顾

阿里云 VS AWS,谁能赢得上云战役

Kubernetes迁移指北

从青铜到王者,代码人生之路

云原生的What、Why、How

从AWS到阿里云:产品体系差异分析

在售后技术服务里,Kubernetes到底是什么?

长按扫描二维码关注凌云时刻

每日收获前沿技术与科技洞见


http://chatgpt.dhexx.cn/article/1k9l7cCT.shtml

相关文章

龙蜥社区首届理事大会圆满召开!14家理事代表出席

凌云时刻 编者按:2021年7月6日,OpenAnolis龙蜥社区成功召开首届理事大会,来自阿里云、统信软件、Intel、红旗软件、万里红、联通、电信云、移动云、龙芯、兆芯、飞腾、中科方德等14位家单位的理事代表出席。本次会议由龙蜥社区运营委员会主席…

SRS为何加入木兰社区孵化?

凌云时刻 SRS正式加入木兰开源社区孵化,我想很多朋友只是大概知道木兰社区是国家级的开源社区,是一件很值得荣耀的事情,其他的事情可能就了解不多了。 这次和大家分享下我对这个事情的理解和思考,如果有疑问欢迎评论区留言&#x…

陈绪:被疫情加速的云计算 | 凌云时刻

凌云时刻 导读:"疫情是云计算腾飞的一个推动力,只是突然而来的肺炎病毒,在给所有人带来损失的同时,也为云计算的生态格局创造了一个全新的变化。" 作者 | 陈绪 来源 | 凌云时刻(微信号:linuxpk…

申通上云?技术详解! | 凌云时刻

凌云时刻 技术 导读:如果说,快递行业上半场的竞争拼的是规模、服务乃至价格,进入下半场,快递企业们还需要比拼硬核的技术实力。 作者 | 周金龙(遥方) 来源 | 凌云时刻(微信号:linux…

eBPF Internal: Instructions and Runtime | 凌云时刻

凌云时刻 技术 导读:eBPF 是最近几年异常火爆的一门内核技术,从2011年开发至今,eBPF 社区依然非常活跃。eBPF 可以通过热加载的方式动态的获取、修改内核中的关键数据和执行逻辑,避免内核模块的方式可能会引入宕机风险&#xff0…

乘风破浪的中国数据库 | 凌云时刻

凌云时刻 洞见 导读:从80年代萨师煊教授的一行板书,到今天国产数据库的百花齐放,四十年科技自研,中国数据库都经历了什么? 作者 | 丹如 来源 | 杭派工程师 前言 “科技行业已经没有什么惊心动魄的大事了!”…

harmonyos开发者社区,HarmonyOS开发者创新大赛结果公布,社区渠道参赛队伍战果斐然...

HarmonyOS开发者创新大赛是华为HarmonyOS开发者生态建设的重要一环,致力于挖掘优秀的应用创新人才及项目。参赛队伍基于HarmonyOS的创新特性,结合应用场景,开发出具有全新体验、全新交互的终端应用。对有市场前景的项目,华为不吝帮…

凌云抒志 星海航帆 | 汇佳学校MYP社区设计展隆重举办

毕业,一个带着憧憬、喜悦和不舍的复杂字眼。在那些不曾预料的挑战和困难中,拥有不寻常经历的2022届MYP毕业生,通过为期一年的社区服务与行动,为这个词增添了新的注解:毕业,还需要“勇气”与“坚毅”&#x…

YOLOv2相比于yolov1的改进

1.Batch Normalization Batch Normalization可以提升模型收敛速度,而且可以起到一定正则化效果,降低模型的过拟合。在YOLOv2中,每个卷积层后面都添加了Batch Normalization层,并且不再使用droput。使用Batch Normalization后&…

YOLOv1,YOLOv2,YOLOv3解读

本文依次讲解YOLOv1,v2,v3。博客地址https://blog.csdn.net/hancoder/article/details/87994678 文章目录 YOLOv11.1 Introduction1.2 Unified Detection1.3 网络框架1.4 Loss解读LOSS: 1.5 test附:NMS示例: 1.7 YOLOv1结语待解决问题 YOLOv22.1 Better更…

Yolov2模型——pytorch实现

论文传送门:YOLO9000: Better, Faster, Stronger Yolov2的改进: 1.批标准化(Batch Normalization):在conv后加入BN(conv不再使用bias),改善模型的收敛性,同时去掉dropout; 2.高分辨率分类器(High Resolut…

【YOLO系列】--YOLOv2超详细解读/总结

本章论文: YOLOv2论文(YOLO9000: Better, Faster, Stronger)(原文+解读/总结+翻译) YOLO系列解读直通车🚀: YOLO系列-【YOLOv1】🚀 YOLO系列-【YOLOv2】&a…

YOLOv1、YOLOv2和YOLOv3对比

YOLOv1、YOLOv2和YOLOv3对比 R-CNN系列YOLOv1结构目标输出网络训练YOLOv1的局限性和R-CNN系列的对比 YOLOv2结构目标输出网络训练关于YOLO9000 YOLOv3结构目标输出网络训练YOLOv3系统做过的不成功的尝试 未来 YOLO深度卷积神经网络已经经过原作者Joseph Redmon已经经过了3代4个…

YOLOv2 论文笔记

论文地址:YOLO9000: Better, Faster, Stronger 项目主页:YOLO: Real-Time Object Detection (最近博客下很多人请求Caffe 代码,受人所托,已经不再提供,且关闭本文评论,望请见谅) …

YOLO - v1

先理解预测阶段: 1)一个448*448*3的图像经过YOLO这个黑箱输出一个7*7*30矩阵; 2)7*7*30的矩阵中的30维是5520;5是预测的bbox的x,y,w,c;20是20个类别的条件概率; 解释c: 解释条件概率:它的意义是…

YOLOV2网络模型

目录 资料 网络模型原理 网络框架 相对于yoloV1的改进 Batch Norm High Resolution Classifier Convolutional With Anchor Boxes Dimension Clusters New Network:Darknet-19 Direct location prediction PassThrough Multi-Scale Training Loss YOLOV2的训…

YOLOv3

YOLOv3 论文信息论文标题:论文作者:收录期刊/会议及年份: 论文学习YOLOv3 网络架构:YOLO 输出特征图解码(前向过程):训练策略与损失函数(反向过程):精度与性能…

从YOLO到YOLO v2再到YOLO v3

配置相关博客链接: YOLO V3-GPU版本在Windows配置及注意事项 YOLO v3在Windows下的配置(无GPU)opencv3.2.0VS2015 前不久YOLO v3出来了,就迫不及待的想试一下。以前装过darknet所以我把整个darknet的文件夹全部删掉。 然后按照…

yolovx

1.输入端 (1)Strong augmentation Yolox主要采用了Mosaic、Mixup两种数据增强方法 有两点需要注意: (1)在训练的最后15个epoch,这两个数据增强会被关闭掉。 而在此之前,Mosaic和Mixup数据增…

史上最通俗易懂的YOLOv2讲解

博主本来想自己写一篇关于YOLOv2的论文笔记的,在找资料的过程中看到这篇天秀的博客,就“据为己用”了。不得不出,很多大佬写的都太深刻了,还是转载比较舒服点~~~~~~ 本文转自目标检测|YOLOv2原理与实现(附YOLOv3) 前 言 在前面的…