之前我們提到大數(shù)據(jù)的時候就會提到Hadoop，Hadoop是大數(shù)據(jù)的基礎(chǔ)框架，是大數(shù)據(jù)技術(shù)的代表。提到HDFS、MapReduce、Yarn，提到HBase、Hive、TEZ等Hadoop生態(tài)圈中的一個又一個開源組件。但是最近好像有點不一樣了。

Hadoop三巨頭

曾經(jīng)的三巨頭之一MapR向加州就業(yè)發(fā)展局提交文件，稱如果找不到新的投資人，公司將裁員 122 人，并關(guān)閉位于硅谷的總部公司。這曾經(jīng)可是估值10億美元的Hadoop發(fā)行版廠商啊，說跪就要跪了，而另外兩巨頭則是抱團取暖，當然這也不能完全說明Hadoop面臨著一些問題。

2003年，依據(jù)Google發(fā)表的三篇論文將Google的三駕馬車從幕后搬到臺前，奠定了后面十幾年大數(shù)據(jù)的框架基礎(chǔ)，形成了Hadoop生態(tài)圈的第一圈：分布式文件系統(tǒng)HDFS、分布式計算MapReduce、HBase NoSQL數(shù)據(jù)庫(BigTable)和Yarn資源調(diào)度服務(wù)。一時之間如日中天，Hadoop生態(tài)蓬勃發(fā)展，Hortonworks、Cloudera 和 MapR一直在進行技術(shù)更新，開發(fā)了一款又一款的基于Hadoop的工具。Hive的出現(xiàn)實現(xiàn)了類SQL的支持，迅速占領(lǐng)了市場，后面基于SQL On Hadoop的組件更是層出不窮，Presto、Impala、Drill、Spark、Tez、Sqoop等等。Hadoop的生態(tài)圈越來越大，后面興起的新型計算框架和查詢框架都圍繞著Hadoop進行兼容，如Presto兼容Hive、Spark兼容HDFS存儲和Yarn調(diào)度，一切看起來都是美好的樣子。

但是，從之前的Hadoop是大數(shù)據(jù)的基礎(chǔ)框架到現(xiàn)在Hadoop已經(jīng)不能完全代表大數(shù)據(jù)了，Hadoop只是大數(shù)據(jù)技術(shù)領(lǐng)域的一個分支，而其他分支正在努力的演化為新的大數(shù)據(jù)實現(xiàn)方式。

大數(shù)據(jù)技術(shù)棧

大數(shù)據(jù)的技術(shù)棧我們通常認為分為：資源調(diào)度層、分布式存儲層、統(tǒng)一計算引擎層和統(tǒng)一接口層。

資源調(diào)度層：為了更好的對資源進行管理，解決上層應(yīng)用的問題，現(xiàn)在出現(xiàn)了很多新的技術(shù)，很多企業(yè)都開始利用容器編排技術(shù)來代替YARN進行資源管理。當然，Hadoop3之后Yarn也支持調(diào)度Docker應(yīng)用了，算是Hadoop的一個改進。

分布式存儲層：誠然HDFS是一個較為通用的存儲服務(wù)，但是它原生的痛點就是不支持小文件存儲，而且由于存儲特性無法實現(xiàn)高性能的隨機讀寫。

統(tǒng)一計算引擎：現(xiàn)在MapReduce已經(jīng)基本要被Spark和Flink所取代了，當然Spark和Flink也算Hadoop生態(tài)中的一員，但是不要忘了，當Spark底層存儲基于S3，調(diào)度基于K8S就可以完全拋開Hadoop了。畢竟誰還不是一個通用性的產(chǎn)品呢~

統(tǒng)一接口層：通過統(tǒng)一的SQL接口層來降低大數(shù)據(jù)技術(shù)的使用門檻是我們的共識，目前SQL on Hadoop技術(shù)也在蓬勃發(fā)展，SQL的支持度也在不斷的提升，但是如果不依賴HDFS存儲可就不見得SQL On Hadoop了。

上面說了這么多也不是在唱衰Hadoop，只是Hadoop目前看來確實好像遇到了瓶頸。但是Hadoop3也增加了大量的功能，Yarn支持Docker容器、支持TensorFlow的GPU調(diào)度，提供了對S3的支持。Hive的LLAP(低延時分析處理)、聯(lián)邦數(shù)據(jù)查詢和完全支持ACID事務(wù)也讓Hive朝著更好的方向發(fā)展。不得不說現(xiàn)在所有的技術(shù)都在朝著云原生的方向前進，如果不能成功上云，可能終將被遺忘。

云原生下開源的YuniKorn

而Hortonworks和Cloudera的合并可能是Hadoop發(fā)展的又一轉(zhuǎn)折點，畢竟合并的戰(zhàn)略目標是專注于云。就在昨天，19年7月17日，Cloudera 官方博客發(fā)文開源了一個幕后工作很久的大數(shù)據(jù)存儲和通用計算平臺交叉的新項目——YuniKorn。據(jù)介紹，YuniKorn 是一種輕量級的通用資源調(diào)度程序，適用于容器編排系統(tǒng)，負責(zé)為大數(shù)據(jù)工作負載分配 / 管理資源，包括批處理作業(yè)和常駐運行的服務(wù)。有興趣的可以關(guān)注一下Github地址：https://github.com/cloudera/yunikorn-core

YuniKorn[‘ju:nikɔ:n] 是一個虛構(gòu)的詞，“Y”代表 YARN，“K”代表 K8s，“Uni”代表統(tǒng)一，其發(fā)音與“Unicorn”相同。創(chuàng)建它是為了最初支持這兩個系統(tǒng)，但最終目的是創(chuàng)建一個可以支持任何容器協(xié)調(diào)器系統(tǒng)的統(tǒng)一調(diào)度程序。一方面在大規(guī)模，多租戶環(huán)境中有效地實現(xiàn)各種工作負載的細粒度資源共享，另一方面可以動態(tài)地創(chuàng)建云原生環(huán)境。YuniKorn 為混合工作負載提供統(tǒng)一的跨平臺調(diào)度體驗，包括無狀態(tài)批處理工作負載和狀態(tài)服務(wù)，支持但不限于 YARN 和 Kubernetes。

YuniKorn 的主要模塊 

YuniKorn -scheduler-interface：調(diào)度程序接口是資源管理平臺(如 YARN / K8s)將通過諸如 GRPC / 編程語言綁定之類的 API 與之交談的抽象層。

YuniKorn Core：YuniKorn Core 封裝了所有調(diào)度算法，它從資源管理平臺(如 YARN / K8s)下面收集資源，并負責(zé)資源分配請求。它決定每個請求的最佳部署位置，然后將響應(yīng)分配發(fā)送到資源管理平臺。調(diào)度程序核心與下層平臺無關(guān)，所有通信都通過調(diào)度程序接口。

Scheduler Shim Layers：調(diào)度程序 Shim 在主機系統(tǒng)內(nèi)運行(如 YARN / K8s)，它負責(zé)通過調(diào)度程序接口轉(zhuǎn)換主機系統(tǒng)資源和資源請求，并將它們發(fā)送到調(diào)度程序核心。在做出調(diào)度程序決策時，它負責(zé)實際的 pod / 容器綁定。

Scheduler UI：調(diào)度程序 UI 為已托管的節(jié)點，計算資源，應(yīng)用程序和隊列提供簡單視圖。

YuniKorn 的一些特性

• 調(diào)度功能支持批處理作業(yè)和長期運行 / 有狀態(tài)服務(wù)
• 具有最小 / 最大資源配額的分層池 / 隊列
• 隊列，用戶和應(yīng)用程序之間的資源公平性
• 基于公平性的跨隊列搶占
• 自定義資源類型(如 GPU)調(diào)度支持
• 豐富的編排約束支持
• 根據(jù)策略自動將傳入的容器請求映射到隊列
• 對節(jié)點使用專用配額 / ACL 管理將大的集群拆分成若干子群集
• 支持 K8s 謂詞。如 pod 親和 / 反親和，節(jié)點選擇器
• 支持持久化存儲，配額申請等
• 從 configmap 動態(tài)加載調(diào)度程序配置(熱刷新)
• 可以在 Kubernetes 之上部署
• YuniKorn Web 支持監(jiān)視調(diào)度程序隊列，資源使用，應(yīng)用程序等

我們不止一次聽說過XX不是銀彈，沒有一種技術(shù)可以解決所有的問題，技術(shù)一直在發(fā)展。哪怕是在Hadoop生態(tài)圈內(nèi)，隨著實時數(shù)據(jù)的處理能力提高，構(gòu)建實時數(shù)倉，打造實時數(shù)據(jù)處理與計算平臺已經(jīng)比離線任務(wù)模式要吃香了。上云總歸來說是一個大的趨勢，對于大小公司都是如此，畢竟可以節(jié)省非常多的成本。但是也不排除云+本地的混合模式，畢竟數(shù)據(jù)現(xiàn)在可是金子~。不管怎么說，一直受Hortonworks和Cloudera的影響推動著Hadoop相關(guān)組件的進步，基于他們的技術(shù)棧學(xué)到了很多招式，希望他們可以更好的走下去。