Hadoop曾经是开源人士的宠儿，在其鼎盛时期一时风头无两。然而随着其功能的扩充，系统也变得越来越复杂，似乎它已经不再能够满足当今时代的数据管理需求，关于“Hadoop已死”的论调时有出现。那么，Hadoop是否真的已经跌下神坛？对于这个问题，或许我们需要更加理性地思考。
 
Cloudera认为，Hadoop代表的是数据领域的开源社区，即使传统的Hadoop已经不复存在，但“Hadoop哲学”永存。作为领先的企业数据云公司，Cloudera从未停止拥抱新的主流技术，持续为客户带来价值。Cloudera Data Platform（CDP）的诞生便是其持续创新的最佳证明，它提供了拥有一致的安全及治理能力的数据平台，来帮助企业更好的对生命周期内的数据进行控制。重要的是，它依旧是100%基于“Hadoop哲学”。
 
技术永远是在“打破”与“被打破”中得以发展。最初，Hadoop的框架最核心的设计就是HDFS和MapReduce。后来，MapReduce逐渐被Spark取代，从前的“Hadoop发行版”如今所提供的软件包含了Spark、HBase、Hive，Kafka、Flink、NiFi等众多组件，早已超出了最初的批处理功能和基于磁盘的本地部署。
 
通常， Apache项目较大堆栈的特点是在任何层都具有可替换性。各发行商已相互竞争多年，角逐各个项目。许多发行商都有自己的版本，这些版本仍然是开源的。根据Apache网站上的说法，Hadoop如今包含两个文件系统（HDFS和Hadoop Ozone），一个用于并行处理大数据集的系统Hadoop MapReduce，一个作业调度和集群资源管理器Hadoop YARN，以及近期发布的一个机器学习引擎Submarine。
 
数据存储的革新从未停止
 
在数据迁移至云愈演愈烈的时代，来自云平台的对象存储正在逐渐取代HDFS。Apache Ozone在某种程度上是为了创建一个现代开放式的替代方案，它符合所有层的理念。一些人提到了Hadoop兼容文件系统（HCFS），然而，事实上Apache软件基金会无法确定第三方文件系统是否与Apache Hadoop兼容，相关言论皆为供应商所作声明，Apache软件基金会并未对此进行验证。
 
一些IT专家可能会辩称MapReduce曾是主流，但如今它经常被Spark所替代，甚至有人认为Spark才是我们应该谈论的标准化处理组件。另外，还有人表示：“可以动态处理数据的时候，就不要等着数据停下来”，他们对Kafka、NiFi和Flink也提出了相同的看法。
 
Apache的定义确实包含了机器学习组件，但Submarine是第二年才出现的新项目，而它现在已升级为顶级项目。可以说，早期基于Mahout的机器学习尝试并未主导Hadoop的使用，Submarine也许会取得更大的成功。Gartner的研究表明，市场正在转向功能更齐全的商业产品，而不再是针对工程师的开源代码算法集合。Submarine正是一个朝着这个方向发展的更完整的集合，因此，与“Hadoop组件”相比，它更有希望成为一个机器学习开发平台。
 
丰富生态，打造专属“平台”
 
从这些组件以及其他所有组件中所选取的特定集合都将具有自己独特的优势，来适用于特定的用例。在其他层有类似的替代方案，但其实还有另一个关键点，就是几乎没有用例仅依赖一层，绝大部分重要的企业级需求都可能依赖于其中的三层或更多层。因此，“平台”这一概念其实相当于我们所说的“发行版”，只不过换了一个说法而已。
 
谈到现在使用的具体技术，从传统的商业智能分析、数据集成、数据库管理系统（DBMS）、机器学习供应商到云平台供应商，如今每个人都想拥有一个“平台”。通常情况下，他们都在某些核心堆栈的某些层上替换了一些组件，特定层的一些替代组件可与其他层的替代组件进行通信。例如，您可能想在AWS上使用Spark（与Kinesis而不是Kafka一起使用）从S3读取日志数据，因为所连接的应用程序选择了Kinesis进行存储。Spark可以做到这一点，然而并非所有项目都有如此丰富的生态系统。在使用Microsoft HDInsight和Google DataProc时也会出现类似的情况，无论在哪里部署，都会有“本地收藏夹”选项。
 
早期的Hadoop团队通常只关心自己的集群之内，他们无需太担心与访问控制以外的其余结构的治理或安全性的连接。如今的团队还需要对所交付的商业软件包中的许多组件进行检测，以实现基于角色的精细安全性、元数据管理、沿袭、数据质量、迁移性以及分布式应用程序的协调等等。使用这项技术的团队在日常工作中需要与公司内的其余业务和技术部门进行协调、交换数据并参与策略的执行。此外，还需要有资源管理、编配、治理和安全等工作。
 
从具体问题出发
 
所有这些都表明Hadoop这个名称已不再能够表示我们当今堆栈中的各项技术的真正作用，现在我们应该开始讨论的是数据湖、机器学习、运营数据管理等用例，将这些具体用例作为设计、开发、集成和运营计划的基础会更具说明性和实用性。或许我们可以通过拥抱“Hadoop哲学”来实现这一目标。
 
曾经的Hadoop供应商早已开始这一转型。我们也应该根据用例、功能活动、结果和受众等方面重新思考，以便为高价值用户提供以分析为依据的更高首选产品可视性。谈论Hadoop还是有意义的，不过如果单纯从Hadoop这个主题开始，就无法有效地推进讨论成果。我们应该从具体问题出发，比如客户系统，基于机器学习的数字化转型，或者是为现场运行提供更丰富的数据，实现我们思考方式的转型。