Hadoop現在怎么樣了？
之前我們提到大數據的時候就會提到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 之上部署
- YuniKorn Web 支持監視調度程序隊列，資源使用，應用程序等
我們不止一次聽說過XX不是銀彈，沒有一種技術可以解決所有的問題，技術一直在發展。哪怕是在Hadoop生態圈內，隨著實時數據的處理能力提高，構建實時數倉，打造實時數據處理與計算平臺已經比離線任務模式要吃香了。上云總歸來說是一個大的趨勢，對于大小公司都是如此，畢竟可以節省非常多的成本。但是也不排除云+本地的混合模式，畢竟數據現在可是金子~。不管怎么說，一直受Hortonworks和Cloudera的影響推動著Hadoop相關組件的進步，基于他們的技術棧學到了很多招式，希望他們可以更好的走下去。
