Hadoop 的丧钟：并非公共云、而是复杂性

　　作者：Monte Zweben 是 AI 数据平台公司 Splice Machine 的首席执行官。　　

　　Hadoop 正在慢慢地死去，但是致命因素就隐藏在我们眼皮底下。（提示：在标题中。）

　　复杂性可能为 Hadoop 发行版敲响丧钟。

　　对于 Hadoop 的三大分销商而言，2019 年可谓是困难重重的一年。从对于 1 月份完成的 Cloudera/Hortonworks 合并的内部乐观和外部怀疑，到 MapR 在 5 月份发布即将完蛋的信函、随后被 HPE 收购，再到 Cloudera 在 6 月份非常糟糕的周三（股价暴跌和首席执行官 Tom Reilly 离职），这个领域尽是不好的消息。也许最有说服力的内容来自 Cloudera 的季度收益公告，该公告将 Hadoop 的挑战描述为需要云解决方案：

　　“虽然第一季度一些客户因预料新平台的发布而选择推迟续订和扩展协议，从而影响了我们的全年前景，但这种客户反馈和热情证实了客户需要我们目标市场中的企业数据云解决方案。”

　　复杂性很致命

　　Hadoop 在云端也很复杂。

　　好多文章声称，公共云已杀死了 Hadoop，但是正如我之前在这里所写的那样，对于这种分布式技术的未来，我却持相反的看法。

　　Hadoop 面临两大挑战：

• 运维复杂性：DevOps 面临的负担是，为基于商用硬件的大规模分布式系统确保可用性、高性能和安全性。
• 开发复杂性：开发团队面临的负担是，将许多不同的计算和存储部件捆绑起来，组成一种实用的解决方案，又没有数据移动造成的延迟。

　　公共云消除了运维复杂性方面的挑战。这对像 Cloudera、Hortonworks 和 MapR 这些很晚进入到云时代的 Hadoop 发行版公司来说是沉重的打击。AWS、Azure 和谷歌云平台（GCP）几乎消除了运行 Hadoop 生态系统核心组件的运维复杂性。

　　然而我认为，即便在公共云，成功采用这项技术仍存在巨大的挑战。AWS 的产品页面上实际上有数百种计算和存储解决方案。我们认为业界对开发人员过于依赖。

　　你是想要造车还是开车？

　　使用 Hadoop 就好比用诸多部件组装一辆汽车。

　　Hadoop 是一套很棒的技术组件！我们用它来搭建自己的数据平台。但是与为 Hadoop 实施而苦恼的多位 CIO 交谈后发现，我逐渐认为这些组件可能实在太低级了。打个比方，我们需要运输时，我们根据运输需求购买汽车。我们并不购买单独的汽车零部件，比如喷油器、车轴、发动机和悬架系统。我们让那些部件由制造商来组装。

　　同样，你要连接 AWS Dynamo 来运行应用程序时、连接 AWS Redshift 来分析数据、连接 AWS SageMaker 来构建机器学习模型、连接 AWS EMR 来运行基于 Spark 的 ETL 等时，你就在组装“汽车”。这就是“Lambda 架构”所谓的管道胶带。

　　然而，这导致了复杂性和数据移动。而数据移动导致了等待数据进行“ETL 处理”时常常遇到的延迟。此外，创建这些架构所需的技能稀缺且昂贵。

　　因此，无论是不是可以通过迁移到云端来消除运维复杂性（这的确并非易事），你仍然面临把所有计算和存储部件捆绑起来的集成复杂性。

　　一种预先集成的包装方法

　　我们的观点是，就像用于运输的“汽车”一样，公司需要大规模可扩展的基础设施来处理操作、分析和机器学习等混合工作负载，但它们应该没必要自行组装该实用功能。

　　我们认为，Hadoop 的某些组件很适合嵌入和集成，从而让公司既能够构建新的应用程序，又能够更新改造现有的应用程序。另一些公司以其他方式将这些组件集成起来。不过，我们认为这种预先集成必不可少；除非预先集成普及开来，否则 Hadoop 仍很难，即便在公共云也是如此。