之前我們提到大資料的時候就會提到Hadoop，Hadoop是大資料的基礎框架，是大資料技術的代表。提到HDFS、MapReduce、Yarn，提到HBase、Hive、TEZ等Hadoop生態圈中的一個又一個開源元件。但是最近好像有點不一樣了。
Hadoop三巨頭
曾經的三巨頭之一MapR向加州就業發展局提交檔案，稱如果找不到新的投資人，公司將裁員 122 人，並關閉位於矽谷的總部公司。這曾經可是估值10億美元的Hadoop發行版廠商啊，說跪就要跪了，而另外兩巨頭則是抱團取暖，當然這也不能完全說明Hadoop面臨著一些問題。
2003年，依據Google發表的三篇論文將Google的三駕馬車從幕後搬到臺前，奠定了後面十幾年大資料的框架基礎，形成了Hadoop生態圈的第一圈：分散式檔案系統HDFS、分散式計算MapReduce、HBase NoSQL資料庫（BigTable）和Yarn資源排程服務。一時之間如日中天，Hadoop生態蓬勃發展，Hortonworks、Cloudera 和 MapR一直在進行技術更新，開發了一款又一款的基於Hadoop的工具。Hive的出現實現了類SQL的支援，迅速佔領了市場，後面基於SQL On Hadoop的元件更是層出不窮，Presto、Impala、Drill、Spark、Tez、Sqoop等等。Hadoop的生態圈越來越大，後面興起的新型計算框架和查詢框架都圍繞著Hadoop進行相容，如Presto相容Hive、Spark相容HDFS儲存和Yarn排程，一切看起來都是美好的樣子。
但是，從之前的Hadoop是大資料的基礎框架到現在Hadoop已經不能完全代表大資料了，Hadoop只是大資料技術領域的一個分支，而其他分支正在努力的演化為新的大資料實現方式。
大資料技術棧
大資料的技術棧我們通常認為分為：資源排程層、分散式儲存層、統一計算引擎層和統一介面層。
- 資源排程層：為了更好的對資源進行管理，解決上層應用的問題，現在出現了很多新的技術，很多企業都開始利用容器編排技術來代替
YARN進行資源管理。當然，Hadoop3之後Yarn也支援排程Docker應用了，算是Hadoop的一個改進。 - 分散式儲存層：誠然
HDFS是一個較為通用的儲存服務，但是它原生的痛點就是不支援小檔案儲存，而且由於儲存特性無法實現高效能的隨機讀寫。 - 統一計算引擎：現在
MapReduce已經基本要被Spark和Flink所取代了，當然Spark和Flink也算Hadoop生態中的一員，但是不要忘了，當Spark底層儲存基於S3，排程基於K8S就可以完全拋開Hadoop了。畢竟誰還不是一個通用性的產品呢~ - 統一介面層：通過統一的
SQL介面層來降低大資料技術的使用門檻是我們的共識，目前SQL on Hadoop技術也在蓬勃發展，SQL的支援度也在不斷的提升，但是如果不依賴HDFS儲存可就不見得SQL On Hadoop了。
上面說了這麼多也不是在唱衰Hadoop，只是Hadoop目前看來確實好像遇到了瓶頸。但是Hadoop3也增加了大量的功能，Yarn支援Docker容器、支援TensorFlow的GPU排程，提供了對S3的支援。Hive的LLAP（低延時分析處理）、聯邦資料查詢和完全支援ACID事務也讓Hive朝著更好的方向發展。不得不說現在所有的技術都在朝著雲原生的方向前進，如果不能成功上雲，可能終將被遺忘。
雲原生下開源的YuniKorn
而Hortonworks和Cloudera的合併可能是Hadoop發展的又一轉折點，畢竟合併的戰略目標是專注於雲。就在昨天，19年7月17日，Cloudera 官方部落格發文開源了一個幕後工作很久的大資料儲存和通用計算平臺交叉的新專案——YuniKorn。據介紹，YuniKorn 是一種輕量級的通用資源排程程式，適用於容器編排系統，負責為大資料工作負載分配 / 管理資源，包括批處理作業和常駐執行的服務。有興趣的可以關注一下Github地址：https://github.com/cloudera/yunikorn-core
YuniKorn[‘ju:nikɔ:n] 是一個虛構的詞，“Y”代表 YARN，“K”代表 K8s，“Uni”代表統一，其發音與“Unicorn”相同。建立它是為了最初支援這兩個系統，但最終目的是建立一個可以支援任何容器協調器系統的統一排程程式。一方面在大規模，多租戶環境中有效地實現各種工作負載的細粒度資源共享，另一方面可以動態地建立雲原生環境。YuniKorn 為混合工作負載提供統一的跨平臺排程體驗，包括無狀態批處理工作負載和狀態服務，支援但不限於 YARN 和 Kubernetes。
YuniKorn 的主要模組
YuniKorn -scheduler-interface：排程程式介面是資源管理平臺（如 YARN / K8s）將通過諸如 GRPC / 程式語言繫結之類的 API 與之交談的抽象層。
YuniKorn Core：YuniKorn Core 封裝了所有排程演算法，它從資源管理平臺（如 YARN / K8s）下面收集資源，並負責資源分配請求。它決定每個請求的最佳部署位置，然後將響應分配傳送到資源管理平臺。排程程式核心與下層平臺無關，所有通訊都通過排程程式介面。
Scheduler Shim Layers：排程程式 Shim 在主機系統內執行（如 YARN / K8s），它負責通過排程程式介面轉換主機系統資源和資源請求，並將它們傳送到排程程式核心。在做出排程程式決策時，它負責實際的 pod / 容器繫結。
Scheduler UI：排程程式 UI 為已託管的節點，計算資源，應用程式和佇列提供簡單檢視。
YuniKorn 的一些特性
- 排程功能支援批處理作業和長期執行 / 有狀態服務
- 具有最小 / 最大資源配額的分層池 / 佇列
- 佇列，使用者和應用程式之間的資源公平性
- 基於公平性的跨佇列搶佔
- 自定義資源型別（如
GPU）排程支援 - 豐富的編排約束支援
- 根據策略自動將傳入的容器請求對映到佇列
- 對節點使用專用配額 /
ACL管理將大的叢集拆分成若干子群集 - 支援
K8s謂詞。如 pod 親和 / 反親和，節點選擇器 - 支援持久化儲存，配額申請等
- 從
configmap動態載入排程程式配置（熱重新整理） - 可以在
Kubernetes之上部署 YuniKornWeb 支援監視排程程式佇列，資源使用，應用程式等
我們不止一次聽說過XX不是銀彈，沒有一種技術可以解決所有的問題，技術一直在發展。哪怕是在Hadoop生態圈內，隨著實時資料的處理能力提高，構建實時數倉，打造實時資料處理與計算平臺已經比離線任務模式要吃香了。上雲總歸來說是一個大的趨勢，對於大小公司都是如此，畢竟可以節省非常多的成本。但是也不排除雲+本地的混合模式，畢竟資料現在可是金子~。不管怎麼說，一直受Hortonworks和Cloudera的影響推動著Hadoop相關元件的進步，基於他們的技術棧學到了很多招式，希望他們可以更好的走下去。
參考資料：
被“圍攻”的 Hadoop 沒有對手
2019 年，Hadoop 還是資料處理的可選方案嗎?
Cloudera 開源新專案：輕量級通用資源排程程式 YuniKorn
歡迎關注我：叄金大資料
