“每個人的時間都是有限的，在有限的時間裡選擇一項值得投入的技術會變得尤為重要。”
筆者從 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、進化能力
技術深度
技術深度是指這項技術的根基是否紮實，護城河是否夠寬夠深，是否很容易被其他技術所替代。通俗的來說就是這項技術是否解決了其他技術所不能解決的有重要價值的問題。這裡有兩個要點：
1、這個問題沒有人能解，是這項技術首先解決了這個問題。
2、解決這個問題能夠帶來重大價值。
拿我職業生涯開始階段學習的 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的這篇文章，我對其中的觀點非常認同。
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 大次元，在這裡我還想分享下我在評估一項新技術時候的一些小技巧。
1、利用 Google trends 。Google trends 能很好的反映一項技術的發展勢頭，上面提到的趨勢圖很好的比較了 3 大流計算引擎 Flink ， Spark Streaming 和 Storm ，我們不難得出結論：Flink 是流計算領域的王者。
2、檢視 GitHub 上的awesome。一項技術受歡迎的一個名額是 GitHub 上的 awesome list，你可以看看這個 awesome list 的 GitHub star 數。此外你可以抽一個周末的時間看看這個 awesome list 上的内容，因為上面基本上是關于這項技術的精華内容，通過這些内容你大緻可以判斷出這項技術的價值。
3、看看技術網站上是否有一些技術布道者為這項技術背書（我個人經常會看medium.com）。技術圈裡通常有這樣一群人，他們對技術很執着，也很有品位。如果一項技術真的很好，那麼就會有技術布道者無償的為這項技術背書，分享如何這項技術的使用心得。
總結
每個人的時間都是有限的，在有限的時間裡選擇一項值得投入的技術會變得尤為重要。
以上是我對如何評估一項技術是否值得學習的一些思考，也算是對我自己事業生涯在技術選型方面的一個小小的總結和回顧，希望我的這些思考能對大家的職業生涯有所幫助。
作者資訊：章劍鋒（簡鋒），開源界老兵，Github ID：@zjffdu，Apache Member，曾就職于 Hortonworks，目前在阿裡巴巴計算平台事業部任進階技術專家，并同時擔任 Apache Tez、Livy 、Zeppelin 三個開源項目的 PMC ，以及 Apache Pig 的 Committer。有幸很早就接觸了大資料和開源，希望可以在開源領域為大資料和資料科學做點貢獻。