Hadoop的丧钟：并非公共云，而是复杂性
极客时间编辑部
讲述：丁婵大小：1.88M时长：04:06
此前，AI 数据平台 Splice Machine 的 CEO 蒙特·兹韦本（Monte Zweben）发表观点称：复杂性可能为 Hadoop 发行版敲响丧钟。公众号云头条将兹韦本的观点编译如下。
对于 Hadoop 的三大分销商而言，2019 年可谓是困难重重的一年，坏消息不断。也许最有说服力的内容来自 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 仍然很难，即便在公共云也是如此。
以上就是今天的内容，希望对你有所启发。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
该免费文章来自《极客视点》，如需阅读全部文章，
请先领取课程
请先领取课程
免费领取
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
精选留言
由作者筛选后的优质留言将会公开显示，欢迎踊跃留言。
收起评论