作者：小智?

來源：智領(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)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。