从Hadoop到云原生,谈如何消除程序员35岁危机
作者:小智?
來源:智領(lǐng)云科技
前
言
35歲這個“職場枯榮線”,確實(shí)真實(shí)存在。
不知從何時起,很多企業(yè)將入職門檻限定在35歲以下,“35歲”已然成為職場中年的魔咒。尤其是程序員這個群體,年齡絕對是最難以隱忍的痛點(diǎn)。因?yàn)楹芏喑绦騿T普遍存在于如前期“打英雄”發(fā)育快,越到后期越乏力的尷尬窘境。
提前做好規(guī)劃,看清技術(shù)趨勢,不沉迷于以往的成就,不僅可以優(yōu)雅過渡35歲危機(jī),甚至?xí)瓉砺殘稣嬲狞S金期。
無論么時候,錘煉和深挖自己的技能都是必不可少的。但是,跟上快速迭代的技術(shù)變化,同樣不可忽視。比如,很多程序員聲稱自己是Hadoop專家,此前他們對此的確非常精通,而如今在精湛的技能下卻不得不感到危機(jī),畢竟Hadoop正面臨著淘汰,這就意味著以前是專家以后很可能沒飯吃。所以,程序員必須意識到技術(shù)是不斷前進(jìn)的,如何掌握技術(shù)趨勢而不是追求熱點(diǎn)才是關(guān)鍵所在。
讓Hadoop面臨淘汰的,正是來自云原生的力量
伴隨云計(jì)算的滾滾浪潮,云原生的概念應(yīng)運(yùn)而生,而如此火爆的概念卻難以用只言片語解釋清楚,因?yàn)樵圃恢痹诎l(fā)展變化之中,解釋權(quán)不歸某個人或組織所有。
CNCF對云原生的定義:云原生技術(shù)有利于各組織在公有云、私有云和混合云等新型動態(tài)環(huán)境中,構(gòu)建和運(yùn)行可彈性擴(kuò)展的應(yīng)用。云原生的代表技術(shù)包括容器、服務(wù)網(wǎng)格、微服務(wù)、不可變基礎(chǔ)設(shè)施和聲明式API。這些技術(shù)能夠構(gòu)建容錯性好、易于管理和便于觀察的松耦合系統(tǒng)。結(jié)合可靠的自動化手段,云原生技術(shù)使工程師能夠輕松地對系統(tǒng)作出頻繁和可預(yù)測的重大變更。
我們以CNCF官方的定義來看,云原生的代表技術(shù)包括容器、服務(wù)網(wǎng)格、微服務(wù)、不可變基礎(chǔ)設(shè)施和聲明式API。云原生技術(shù)可以讓系統(tǒng)松耦合,支持彈性伸縮、可管理且清晰。通過整合健壯且有效的自動化,工程師可以用很少的勞動來完成頻繁的、預(yù)期中的高危代碼修改。
說白了,如果是Cloud Native的程序,寫完之后在云上一發(fā)布,程序就自動運(yùn)行和運(yùn)維了,我只需要負(fù)責(zé)業(yè)務(wù)邏輯就可以了。通俗來說其特征是:
發(fā)布的時候最簡化,不用指定主機(jī)、端口、存儲……
日志、容錯、數(shù)據(jù)備份、監(jiān)控都是自動的
底層硬件錯誤跟程序員沒有關(guān)系
自動擴(kuò)容、降容、加機(jī)器、換機(jī)器都不是程序員的事情
別人發(fā)布應(yīng)用肯定不會影響自己的應(yīng)用
如果這家云廠商太貴了,可以直接遷到另一家云上運(yùn)行
只為自己實(shí)際使用的計(jì)算和存儲付費(fèi),不用預(yù)先購買
實(shí)際上,近兩年云計(jì)算概念被清晰細(xì)分,“云原生”已經(jīng)成為那條最大的魚。“大魚”來了,程序員們能做的不應(yīng)該是墨守成規(guī),而是必須擁抱“大魚”。
Hadoop使命已經(jīng)完成 并一定會被取代
Elephant in the room,比喻一個問題因太過于龐大或麻煩,導(dǎo)致沒有人愿意去碰。
巧的是,Hadoop的標(biāo)志就是一頭大象,正面臨著“Elephant in the room”這樣的窘境。
不得不說,很多大數(shù)據(jù)系統(tǒng)不是云原生的,像Hadoop、Hive、Mongo等絕大部分大數(shù)據(jù)組件發(fā)展于云計(jì)算技術(shù)成熟之前,所以這些組件必須自己做協(xié)同、存儲、備份、日志,來處理資源與集群管理。
而像Kubernetes這樣的云基礎(chǔ)設(shè)施,很長一段時間對Stateful Applications(有狀態(tài)應(yīng)用)的支持并不友好。即使像Spark這樣在云原生的環(huán)境下開發(fā)的應(yīng)用(其原生就是在Mesos集群中發(fā)布),并沒有做自己調(diào)度和集成管理,但是后期為了與K8s兼容,還是做了很多改動,今年年初才進(jìn)入GA的階段。
但是,隨著Kubernetes對各種大數(shù)據(jù)組件的支持不斷完善,Hadoop的歷史使命似乎已經(jīng)逐漸完成,而所有的新的大數(shù)據(jù)應(yīng)用,大概率都會基于容器發(fā)布,否則必將失去市場。
Hadoop如何被取代?
Hadoop的三駕馬車是MapReduce、YARN、HDFS。
其中,MapReduce因效率太低,早已被Spark所取代;YARN并非正規(guī)的容器且效率不高,可以被類似于K8s的新一代容器調(diào)度體系取代;唯一生命力比較強(qiáng)的是HDFS,因?yàn)榇蟛糠执髷?shù)據(jù)組件的HDFS API是兼容的,所以取代HDFS暫時有些難度。
盡管,HDFS很難被去掉,不過不用擔(dān)心,因?yàn)榛旧螲DFS只有API是真正有用的。
因?yàn)楹芏喑绦蚴怯肏DFS的API使用的,如圖通過HDFS連接器,再通過TCP訪問HDFS,效率是最高的。當(dāng)然也可以通過S3A、WASBS、O3FS訪問相應(yīng)的S3、MinIO、Ozone……但如果意識到HDFS是真正的存儲,下面都是其他的存儲,只需要使用相同的API就可以了。
所以,其實(shí)Hadoop里所有的東西都可以替換。如圖,顯示了在不安裝Hadoop的情況下,可以相對應(yīng)替代的工具。
圖片來源:Cloud Native Data Platform without Hadoop Installation
以前,傳統(tǒng)Hadoop的方式,在Lambda架構(gòu)中所有的應(yīng)用都在各自的主機(jī)上運(yùn)行。
圖片來源:Big Data without Hadoop/HDFS? MinIO tested on Jupyter + PySpark
現(xiàn)在,可以把所有的數(shù)據(jù)處理放在云上。
甚至可以把整個存儲放在Kubernetes上。
綜上所述,我們看到,Hadoop的去除,使得應(yīng)用在容器化中運(yùn)行,能夠讓管理更加方便,從而大大減少工作的復(fù)雜度,全面的讓大數(shù)據(jù)平臺,享受云原生的好處,因此,這必定是未來的趨勢。
當(dāng)然,并不是只有我們意識到了Hadoop如今尷尬的問題,像這樣的說法其實(shí)已經(jīng)得到了初步的共識,諸如像《云原生數(shù)據(jù)平臺,無需安裝Hadoop》《沒有Hadoop/HDFS的大數(shù)據(jù),怎么樣用Jupyter+PySpark來做MinIO測試》《構(gòu)建云原生,在各個云上都可以遷移的數(shù)據(jù)湖》這樣的文章,都能夠窺見“去Hadoop”的趨勢。
其中一篇名為《沒有Hadoop的大數(shù)據(jù)》的文章,介紹“用戶已經(jīng)在公有云上為特定地區(qū)建立了一個完整的數(shù)據(jù)湖和分析解決方案,并希望將這個解決方案部署到另一個區(qū),而此前的數(shù)據(jù)湖并不是云原生的,所以負(fù)責(zé)解決方案的部門通過一系列操作(如圖),實(shí)現(xiàn)了云原生架構(gòu),才得以在不同的公有云上順利實(shí)現(xiàn)該解決方案。”
云原生的組件
原文鏈接:
https://towardsdatascience.com/building-a-cloud-native-cloud-agnostic-data-lake-376aa2f2aacd
云原生新思考 它為什么越來越重要?
首先,我們來看一下CNCF發(fā)布的云原生全景圖,這張全景圖技術(shù)之多規(guī)模之大,無疑會讓人感到震驚。可見,云原生發(fā)展之迅猛,可提供的服務(wù)與選擇非常多。
云原生技術(shù)圖譜
關(guān)于這份云原生技術(shù)圖譜,詳細(xì)內(nèi)容可以參考我們之前發(fā)布的文章《都在說云原生,它的技術(shù)圖譜你真的了解嗎?》。
顯然,現(xiàn)在構(gòu)建一個系統(tǒng)比云原生之前的時代容易多了。如果構(gòu)建恰當(dāng),云原生技術(shù)將提供更強(qiáng)大的靈活性。在現(xiàn)如今快速變化的技術(shù)生態(tài)中,這可能是最重要的能力之一。
接下來,我們要講的重點(diǎn)是云原生的要點(diǎn)之一DevOps,作為是一個合成詞,DevOps由開發(fā)(Developments)和運(yùn)維(Operations)兩個單詞組成,其主要目的是拆斷不同部門之間隔離的墻。簡而言之,DevOps可以讓公司的流程更快、更有效,并且更可靠。
那么,DevOps的平臺功能,是作為容器調(diào)度平臺完全基于編排和部署,并且能夠?qū)⒃圃鷳?yīng)用的生命周期進(jìn)行抽象,可以替換存儲、CRI等,甚至發(fā)布流程都可以用不同的策略來管理;以代碼形式部署集群;開放接口CRI、CNI、CSI的插件架構(gòu)。
這就是DevOps的核心價值,在此基礎(chǔ)上還提供了一些常用服務(wù),例如:負(fù)載均衡、存儲編排、自動部署和回滾、混排、容錯、機(jī)密和配置管理……
K8s將整個分布式集群的發(fā)布變成云原生,發(fā)布到一個分布式集群,用K8s一整套的YAML描述出來就可以在一個集群上發(fā)布,也可以在另一個集群上發(fā)布。
DataOps與DevOps十分形似,也有著與DevOps類似的軟件開發(fā)角色,它是數(shù)據(jù)工程師簡化數(shù)據(jù)使用、實(shí)現(xiàn)以數(shù)據(jù)驅(qū)動企業(yè)的方法,也是企業(yè)順利實(shí)現(xiàn)第三階段的關(guān)鍵。
那么,我們的思考是DataOps是否也可以這樣做?
將DevOps變量替換到DataOps,我們看DataOps的核心價值主要是基于容器的部署和編排、生命周期的抽象、DSL——作為代碼的管理部署、支持不同分析工作負(fù)載的插件架構(gòu)。以及常用服務(wù)調(diào)度、元數(shù)據(jù)、數(shù)據(jù)質(zhì)量、訪問控制、版本控制、自動部署和回滾、日志/審計(jì)……
簡而言之,DataOps遵循類似于 DevOps 的方法:從編寫代碼到生產(chǎn)部署的路徑(包括調(diào)度和監(jiān)控)應(yīng)由同一個人完成,并遵循系統(tǒng)管理的標(biāo)準(zhǔn)。與提供許多標(biāo)準(zhǔn) CI、部署、監(jiān)控工具以實(shí)現(xiàn)快速交付的 DevOps 類似,通過標(biāo)準(zhǔn)化大量大數(shù)據(jù)組件,新手可以快速建立生產(chǎn)級的大數(shù)據(jù)應(yīng)用并充分利用數(shù)據(jù)的價值。(關(guān)于DataOps的詳細(xì)內(nèi)容,可以參考我們之前發(fā)布的文章《一文讀懂DataOps》。)
從Hadoop的氣數(shù)已盡到云原生的風(fēng)光正好,看起來是說新技術(shù)的快速迭代,但實(shí)際上對于Hadoop這樣的分布式系統(tǒng)的深入理解其實(shí)也是精通云原生架構(gòu)大數(shù)據(jù)體系的基礎(chǔ)。總之,我們要避免的是固守就有技術(shù),以為“一招鮮吃遍天”,而是要從架構(gòu)、體系上,充分理解自己的工作內(nèi)容,并不斷鞏固算法、架構(gòu)、測試、工程管理與溝通等基礎(chǔ)知識技能體系。
最重要的是,要時刻保持學(xué)習(xí)和提高的心態(tài)。如果這樣,程序員完全不會存在35歲危機(jī),而會在這個黃金年齡迎來自己的收入巔峰。如今,云原生與數(shù)字化的轉(zhuǎn)型大潮才剛剛開始,我們希望所有的程序員都能夠抓住機(jī)會,深耕專業(yè)技術(shù)能力實(shí)現(xiàn)人生價值。
往期推薦
如何快速部署一個Elasticsearch集群?
微軟云打印將直接與 OneDrive 集成等
畢業(yè)=失業(yè)?還在埋頭寫這么多代碼?
被 AI?算法“監(jiān)控”的打工人
點(diǎn)分享
點(diǎn)收藏
點(diǎn)點(diǎn)贊
點(diǎn)在看
總結(jié)
以上是生活随笔為你收集整理的从Hadoop到云原生,谈如何消除程序员35岁危机的全部內(nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 发布 128 核 Altra Max,自
- 下一篇: 漫话云计算,这次加了点儿剧情