本文的翻译是专门为数据工程师课程的学生准备的。
在Cloudera和MapR几周前宣布他们的业务处于困难时期之后，我看到了一系列主题为“ Hadoop已死”的社交媒体帖子。 这些职位并不新鲜，但是在一个技术专家很少为社交网络制作高质量材料的行业中，这些惊呼声越来越大。 我想考虑一些有关Hadoop状态的争论。
免费比赛
Cloudera的建议可帮助Hadoop成为更完整的解决方案。 这些工具是在devop广泛传播之前出现的，并且很少有自动化部署。
他们的工具为2600多个客户提供了优惠，但是他们提供的大多数软件都是开源的和免费的。 Cloudera最终会与免费软件竞争。 最重要的是，许多Hadoop生态系统开发人员曾在Cloudera进行过一次或多次工作，即 最后，他们以某种方式补贴了与其竞争的免费产品。
随着他们与免费竞争，Cloudera将永远不会为Hadoop用户群提供100％的服务。 出于这个原因，我不敢将它们用作Hadoop健康状况的指标。
其他提供交钥匙式Spark和Presto解决方案的公司正试图与Hadoop品牌保持距离。 他们的报价可能包括来自各个Hadoop项目的数百个.jar文件，但是，这些公司希望尽一切可能避免与免费报价竞争，同时通过使用开源软件来降低开发成本。 如果您的客户可以合法地下载报价的80％而无需付费，那么销售就变得不那么容易了。
与AWS竞争
2012年，我与其他25个承包商一起实施Hadoop。 我的一些同事来自Google，其他同事则继续为Cloudera工作。 涉及大量预算，该团队产生了许多带薪小时，但Hadoop生态系统的一小部分已经准备就绪。
在短短几年内，AWS EMR出现并开始吸收其市场份额。 通过EMR，您只需单击几下即可运行安装了多种软件的Hadoop集群。 它可以按点复制工作，从而将设备成本降低了约80％，并且可以在S3上存储数据，而S3一直且廉价且可靠，为99.9999999999％。
突然，该项目上不再需要25个承包商。 在某些项目中，除我的其他职责外，只有我（一名全职工人）和其他几名兼职人员参与基础设施的准备工作。 仍然需要使用AWS EMR的项目顾问，但是这种工作的总体账单潜力远低于几年前。
支持EMR的Cloudera潜在业务份额损失了多少？ Cloudera在设置和管理裸机集群方面做得很好，但是如今，大多数数据世界都在云中。 值得考虑的是Hadoop对您的业务有多大吸引力，仅是因为AWS提供了带有点副本的托管产品。
什么是Hadoop？
如果您问我Hadoop的定义，我会说这是大量开源软件的集合，它们在某种程度上进行了集成并具有几个通用库。 我将Hadoop视为分区数据库，几乎就像是操作系统的数据分发版。
并非Hadoop赞助的所有软件项目都是Apache项目。 Presto就是这样一种例外。 诸如ClickHouse之类的其他产品，即将支持HDFS和Parquet，将不会被许多人视为Hadoop项目，尽管它们很快就会打勾兼容性图。
直到2012年，还没有ORC文件或Parquet。 这些格式有助于在Hadoop中实现快速分析。 在使用这些格式之前，工作负载大多是面向行的。 如果您需要转换TB的数据并可以并行进行处理，那么Hadoop将完美地完成这项工作。 MapReduce是经常用于此目的的框架。
提供列存储的目的是在几秒钟内分析数TB的数据。 事实证明，这对于大量企业而言是更有价值的主张。 数据科学家可能只需要少量数据就能获得一个想法，但是首先，他们将需要查看潜在的PB数据来选择正确的数据。 列分析对于他们流畅地处理必要的数据以了解需要选择的内容至关重要。
MapReduce具有两个功能性的数据处理运算符，即映射和归约，并将数据视为字符串。 Spark紧随其后，并具有更多的功能运算符，例如过滤器和联合，并感知以有向无环图（Direct Acyclic Graph-DAG）结构化的数据。 这些元素使Spark可以运行更复杂的工作负载，例如机器学习和图形分析。 Spark仍可以将YARN用作容量调度程序，就像MapReduce中的任务一样。 但是Spark团队也开始构建自己的调度程序，后来又增加了对Kubernetes的支持。
在某个时候，Spark社区试图与Hadoop生态系统保持距离。 他们不想被视为Legacy软件的附件，也不希望被视为Hadoop的“附件”。 考虑到Spark与其余Hadoop生态系统的集成程度，以及Spark使用的其他Hadoop项目中的数百个库，我不同意Spark是独立产品的观点。
目前，MapReduce可能不是大多数工作负载的首选，但是使用hadoop distcp时它仍然是基本环境-该软件包可以比任何其他产品
更快地在AWS S3和HDFS之间传输数据经过测试。
每个Hadoop工具是否成功？
不，有些项目已经使新项目黯然失色。
例如，许多以前由Oozie自动化的工作负载现在已由Airflow自动化。 Oozie的主要开发人员Robert Kanter提供了当今代码库的重要组成部分。 不幸的是，自2018年离开Cloudera以来，Robert不再积极参与该项目。 同时，Airflow有800多名参与者，在过去一年中，这个数字几乎翻了一番。 自2015年以来，几乎与我合作的每个客户都在其组织的至少一个部门中使用了Airflow。
Hadoop提供了构成数据平台的各种构建块和元素。 通常，几个项目会争相提供相同的功能。 最后，其中一些项目逐渐消失，而另一些项目则带头。
在2010年，有几个项目被定位为各种工作负载的首选，其中只有几个参与者，或者在某些情况下，还有几个重要的部署。 这些项目来来去去的事实被用作整个Hadoop生态系统濒临灭绝的证据，但是我没有从中得出这样的结论。
我认为项目之间的这种弱关联是开发许多强大功能的一种方式，这些功能可以在不收取大量最终用户许可费用的情况下使用。 这是优胜劣汰的原则，它证明了对于每个问题都考虑了不止一种方法。
更新：我最初说过，根据GitHub上的报告，Oozie有17个成员。 实际上，Oozie拥有152个开发人员提交的直接提交和补丁，而不仅仅是GitHub计算中出现的17个。 罗伯特·坎特（Robert Kanter）在此文章首次发表后与我联系，并提供了另外135位作者的证据，我感谢他的澄清。
搜索流量不起作用
支持Hadoop“死亡”的论点之一是，各种Hadoop技术上的Google搜索流量不起作用。 近年来，Cloudera和许多其他顾问在筹款工作方面做得很好，并为推进其建议做出了巨大的努力。 反过来，这引起了极大的兴趣，并且在某些时候，一波研究这些技术的人们出现在技术界。 这个社区是多种多样的，在某些时候，大多数人一如既往地转向其他事物。
在Hadoop的整个历史中，今天没有提供如此丰富的功能，而且它从未在战斗中如此稳定和经过测试。
Hadoop项目由成千上万的作者编写的数百万行代码组成。 每周，数百名开发人员致力于各种项目。 如果每周至少有少数工程师对其代码数据库进行重大改进，那么大多数商业数据库产品都是幸运的。
Hadoop为什么特别？
首先，存在容量超过600 PB的HDFS群集。 RAM中HDFS元数据的性质意味着您可以轻松地每秒处理60k次操作。
AWS S3打破了POSIX文件系统上的许多功能，以实现可扩展性。 快速文件更改（例如将CSV文件转换为Parquet文件时所需的快速更改）在S3中无法实现，并且如果要分配工作负载，则需要HDFS之类的内容。 如果将转换软件修改为仅使用上述S3的工作负载，则在数据局部性方面的权衡可能很重要。
其次，Hadoop Ozone项目旨在创建一个与S3 API兼容的系统，该系统可以在群集中存储数万亿个对象，而无需使用自己的云服务。 该项目旨在为Spark和Hive提供内置支持，从而使其与Hadoop生态系统的其余部分很好地集成。 一旦发布，该软件将成为首批可以在一个集群中存储如此多文件的开源产品之一。
第三，即使您不使用PB的数据，Hadoop生态系统中为您提供的API也提供了一致的接口来处理TB的数据。 Spark是分布式机器学习的最终解决方案。 一旦您熟悉了该API，便可以用GB或PB来衡量工作量，也不必重写所创建的代码，只需要更多的机器来运行它即可。 我将首先教别人如何编写SQL和PySpark代码，然后教他们如何在多台计算机上分发AWK命令。
第四，Hadoop生态系统的许多功能是商业供应商的领导者。 专有数据库的每一次营销失败都将导致销售部门发现他们提供了多少缺失的功能，权衡和瓶颈。 每个POC故障都会导致销售团队发现其内部软件测试的可靠性。
至此，翻译的第一部分结束了。 延续可以在
这里阅读 。 现在，我们正在等待您的评论，并邀请所有人参加有关该主题的免费网络研讨会：
“构建流分析系统的原则”。