Kubernetes重构大数据处理规则：Moka平台架构解析

某数字剪贴板提供商发布文章，阐释了其新一代大规模数据处理的蓝图——新平台Moka。该机构正将核心工作负载从老化的Hadoop基础设施迁移到基于Kubernetes的系统上，该系统运行于某中心的EKS服务，并以Apache Spark为主要引擎，同时计划支持其他框架。

在一个由两部分组成的博客系列中，该机构大数据平台的工程师描述了团队如何为下一代超大规模数据处理平台寻找替代方案，因为内部称为Monarch的现有基于Hadoop的系统局限性日益明显。他们将Moka视为这一探索的成果，也是其基于EKS的云原生数据处理平台，目前已在生产环境中处理该机构规模的工作负载。该系列的第一部分聚焦于整体设计和应用层，而第二部分则转向作者所说的"侧重于基础设施的Moka方面，包含经验教训和未来方向"。

文章从实际出发阐述了向Kubernetes的迁移。这展示了一种行业范围的转变：大型科技公司现在将Kubernetes视为数据控制平面，而不仅仅是无状态服务平台。受到大数据社区日益增长的人气和采纳率的鼓舞，团队探索了基于Kubernetes的系统作为Hadoop 2.x最可能的替代品。任何候选平台都必须满足围绕可扩展性、安全性、成本以及承载多种处理引擎能力的精确标准。Moka是一个范例，展示了如何在不放弃现有Spark投资的情况下现代化Hadoop时代的数据平台。

第二篇文章的一个核心主题是如何在Kubernetes上大规模运行Spark。作者解释了如何围绕Moka添加日志记录、指标和作业历史服务，以便工程师无需了解底层集群拓扑即可调试和调优作业。他们致力于使用Fluent Bit标准化日志收集，并利用OpenTelemetry和与Prometheus兼容的端点发布统一指标。这为基础设施和应用团队提供了系统健康状况的一致视图。

该机构还投资通过基础设施即代码使平台可复现。文章概述了团队如何使用Terraform和Helm创建EKS集群、配置网络和安全，并部署支持组件，如Spark History Server。

工程师们还讨论了处理不同硬件架构的问题。他们描述了如何构建多架构镜像，以便其数据工作负载能在Intel和基于ARM的实例（包括某机构的Graviton）上良好运行，并将此与大规模集群的成本和效率目标联系起来。一位编辑对该项目的总结指出，Moka"提供容器级隔离、ARM支持、YuniKorn调度，并通过整合工作负载和跨实例类型自动扩缩实现显著的成本节约"。这些细节将这项工作置于云用户寻求在不牺牲性能的前提下降低基础设施成本的更广泛趋势中。

关于处理引擎的更广泛行业讨论为该机构的案例增添了细微差别。在一篇单独的文章中，一位工程师写道："虽然Spark是我们的主要工具，但Moka的成功意味着该机构的其他用例也在跟进：Flink批处理已在生产中，Apache Ray紧随其后，Flink流处理预计在今年晚些时候部署。" 关于Spark和Flink的技术深度解析强调了这一点的重要性，指出Spark仍然非常适合大规模批处理和交互式分析工作负载，而Flink则是"为实时、有状态的流处理而构建"，具有严格的事件逐条处理能力。团队将Moka展示为一个灵活的底座，可以根据特定工作负载的需求添加不同的引擎，而不是一个仅支持Spark的平台。

外部观察者从该案例中汲取了经验。一份机器学习工程师通讯将Moka文章描述为"部署EKS集群、Fluent Bit日志记录、OTEL指标管道、镜像管理以及用于Kubernetes上Spark的定制Moka UI"的范例，将其与其他现代数据基础设施的案例研究并列。这些反应表明，Moka在某种程度上被视为一类云原生数据系统的参考架构。

然而，团队将其迁移工作呈现为一个持续的过程，而非已完成的项目。在博客和另一篇文章中，作者讨论了"经验教训和未来方向"，并描述了早期的概念验证如何随着对新技术栈信心的增长，引导了逐步远离Hadoop的过程。一位工程师指出"最佳问题出现在大规模时"，构建平台涉及在转移真实工作负载时"解决各种小问题"。对于其他组织而言，这种经验可能是最重要的教训。复制围绕Kubernetes、EKS和Spark的技术选择相对简单，但解耦遗留系统并投资于可观测性、自动化和多引擎支持的过程，可能是未来真正的工作所在。FINISHED