之前我们提到大数据的时候就会提到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相关组件的进步，基于他们的技术栈学到了很多招式，希望他们可以更好的走下去。

【凡本网注明来源非中国IDC圈的作品，均转载自其它媒体，目的在于传递更多信息，并不代表本网赞同其观点和对其真实性负责。】