Hadoop与Spark：大数据计算平台的演进

在过去几年中，我在多个Hadoop项目中积累了丰富的经验。尤其是在2012至2016年间，我们主要利用本地Hadoop基础设施进行工作。

当初的挑战

在早期阶段，Hadoop尚未完全成熟，我们面临许多挑战。例如，采购和部署Hadoop节点、开发和管理大数据管道等工作需要投入大量的时间和精力。当时，缺乏充足的文档和专业技能使得这些问题更加复杂。此外，管理和维护多节点集群环境也极具挑战性，因为需要考虑多种因素：

• 操作系统补丁：升级操作系统补丁时，尤其是在多台机器上，操作难度较大，特别是当某些补丁需要重启系统时。
• Hadoop版本升级：与操作系统补丁类似，Hadoop也需要定期升级。虽然Hadoop的改进，如Namenode High Availability和滚动升级等，带来了一定的帮助，但仍然存在一些问题。
• 可扩展性：尽管Hadoop理论上可以水平扩展，但在实际应用中，增加新节点需要额外的硬件资源，这在资源有限的情况下较为困难。
• 对现代框架的支持：相较于MapReduce，新兴框架如Spark对内存和CPU的需求更高。随着机器学习和人工智能的广泛应用，对更强硬件的需求日益增加。

云时代的到来

随着云计算技术的兴起，许多早期的问题得到了解决。云计算的灵活性使得按需添加新节点变得简单快捷。为了更好地利用云资源，我们采用了多种方法：

• 创建Hadoop/Spark集群：利用云服务商的虚拟机产品（如Amazon EC2）创建Hadoop集群。安装Hadoop和Spark时，可以选用各种发行版（如Cloudera和Hortonworks）或直接使用开源版本。
• 利用云服务：使用云服务商提供的内置服务，如Amazon EMR或Azure HDInsight。虽然这种方式的成本略高，但提供了更快的部署速度、较低的技术要求和更好的可伸缩性及监控功能。
• 混合云模式：部分客户倾向于采用混合云策略，即结合多个云服务商的资源。例如，我们曾使用AWS和Azure的虚拟机构建一个200节点的Hadoop集群。尽管这种方式在当时看来有些过度设计，但客户希望保持多种选择以应对价格波动。

新的工作流程

自从云计算普及以来，整个工作流程发生了显著变化。由于云资源的高度灵活性，我们现在可以根据需要快速调整数据管道，从而减少了对永久Hadoop/Spark集群的需求。

传统云模型的数据湖通常包含永久存储层和计算层。虽然将计算平台迁移至云端解决了资源调配、可扩展性和升级等方面的问题，但全天候运行的集群成本较高。尤其是当集群需要持续运行以支持不定时的计算任务时，资源利用率可能较低，导致性能下降。

无服务器数据管道与临时集群

近年来，越来越多的客户倾向于使用无服务器数据管道，如AWS Glue或临时Hadoop/Spark集群。这些方法允许每个计算任务在独立的集群中运行，或者在一个专门为此任务创建的临时集群中运行。这种方式的主要优点包括：

• 降低成本：通过按需使用资源并在空闲时段释放资源，可以大幅节约成本。
• 提高性能：预定义资源的使用确保了任务能够按时完成。

无服务器计算平台非常适合那些希望简化管理、减少成本并且可以接受一定延迟的用户。此外，借助微服务模型，数据管道可以根据传入请求的变化动态调整计算能力，从而实现高可扩展性。

微服务模型的应用

几个月前，我们使用Kubernetes部署了一个无服务器OCR-NLP管道的原型。该项目涉及处理数百个PDF文件的光学字符识别（OCR）和自然语言处理（NLP）。客户希望通过无服务器方法实现高可扩展性，并且能够根据一天中的负载变化灵活调整资源。

利用Amazon EKS和AWS Fargate上的Kubernetes，我们成功构建了一个无服务器计算管道。尽管这种方法与使用云原生服务的无服务器方法类似，但它具有更高的可扩展性。数据管道能够感知到传入请求的变化，并据此调整计算资源，从而有效应对大量输入请求。

总的来说，微服务模型特别适合那些既希望享受无服务器计算平台的灵活性，又希望实现高水平可扩展性的客户。未来，我们计划在更多项目中采用这种方法，并将在适当时机向大家报告进展情况。

希望这篇文章能为您提供有价值的见解。