玩乐案例：用开源技术从Hadoop迁移到Kubernetes的PB级数据平台之旅

你能构建一个具备可扩展性、可靠性、易管理性和易部署性的数据平台，让多个团队可以并行工作，并且不需要供应商绑定吗？让我们一起看看！
在这篇博客中，我将介绍我们为Play打造的数据平台。这个真实的案例展示了通过使用开源技术我们可以实现什么。

我们的情况是，我们在本地环境中搭建了一个集群，但我们选择的都是开源技术，可以在任何云服务商上顺利运行。

Play 是一家以消费者为中心的波兰移动网络运营商，拥有超过 1500 万用户。它为消费者和企业（尤其是中小企业）提供移动语音、短信、数据和视频服务，这些服务包括合约和预付费在内的各种形式提供。其现代且成本效益高的 2G/3G/4G LTE/5G 电信网络覆盖了波兰 99% 的人口居住区域。自 2007 年商业发布以来，Play 从最初的挑战者位置成长为 2017 年波兰移动市场的领头羊。

在当今快速发展的数据环境中，组织正寻求更灵活、可扩展且高效的管理数据基础设施的方式。HDP，因其强大的大数据解决方案而广受好评，已成为许多企业在处理大规模数据处理和分析方面的基石。然而，随着HDP生命周期的结束（2021年12月支持结束），PLAY需要一个新方案来应对不断增长的数据处理和分析需求。新平台需要满足以下要求：

• 100% 开源
• 云端友好
• 更轻松的应用部署
• 适合多个团队
• 维护和开发轻松
• 可扩展性与资源管理
• 安全（支持 Kerberos 和 SSO）

YARN：替代品

认识到容器化是分发软件的最佳方式，因为它提供了一致性、便携性和隔离性，我们希望利用这些优势来构建我们的平台。鉴于Kubernetes已成为编排容器化应用的事实上的标准，我们决定使用它作为部署应用和运行大数据处理工作负载的平台。
Kubernetes通过在机器集群中编排容器化应用来运行应用程序。应用程序被打包成容器（使用Docker等技术），打包应用代码及其依赖。应用程序被表示为一组声明性的YAML文件，定义所需资源：容器镜像、副本数量等。提交后，k8s将负责运行应用程序，根据需要扩展，并在故障时重启应用。

Kubernetes: 简化版架构

Kubernetes 提供了我们所寻找的多个功能，比如：

• 便携性: 可在多种环境中运行，包括本地部署、公共云或混合云部署。
• 效率: 优化底层基础设施资源（如CPU、内存和存储）的使用。
• 韧性: 通过内置的故障检测与恢复机制，确保应用程序的高可用性和高可靠性。
• 开发人员生产力: 简化应用程序的部署和管理，让开发人员能够专注于编写代码而非管理基础设施。

大方向

我们的现有HDP平台由……组成

• 一个在本地虚拟机上运行的单个 Apache Airflow，我们团队管理大约有 150 个 DAG
• 分析师使用的 Jupyterhub 也运行在本地虚拟机上
• 用于数据处理的 Apache Spark（运行在 YARN 上）
• 安装在集群每个节点上的 Trino，用于 SQL 数据分析
• 作为存储层的 HDFS（基于 Hadoop）

对于新的集群，我们决定使用一组类似的工具，但采取了显著不同的部署方式。如下所示，除了存储外，所有主要组件都在Kubernetes上运行，并且由ArgoCD管理（稍后再详述）。

平台的全貌

• 存储空间:

作为存储方案，我们在独立于k8s集群的k8s节点上安装了Hadoop HDFS。HDFS是一个强大的分布式文件系统，具备可扩展性，旨在跨多台机器处理大型数据集。它的架构确保了高吞吐量、容错性和高效存储，从而确保了高可用性和数据可靠性。HDFS是此方案中最重要的组件之一，我们希望它独立于Kubernetes，这样Kubernetes的任何问题都不会影响到HDFS。我们也考虑过其他选项，例如Ceph和Apache Ozone，但考虑到其易用性（我们有丰富的使用经验）和稳定性，HDFS最终成为最适合我们的解决方案。这种配置提供了一个性能优秀的稳定HDFS集群，数据存储在Kubernetes节点上。为了进一步提升性能，我们还配置Spark的临时目录位于HDFS磁盘上。在云环境中，可以将HDFS替换为云存储解决方案。

• 管弦编排

Apache Airflow 是我们的首选调度器。它是一款强大的工具，用于协调各种工作流程。这一选择很简单，因为我们已经在 Airflow 上运行了大约 150 个 DAG，这些 DAG 正在等待迁移，并且我们有丰富的使用经历。我们使用官方的 Airflow Helm 图在 k8s 上部署了它。通过使用 LocalKubernetesExecutor，我们确保资源密集型的任务，比如 Spark 作业，在单独的 pod 中运行，而轻量级的 Python 作业或 API 交互则作为 Airflow 调度器的子进程运行，以最少资源。

• 处理引擎

我们使用 Apache Spark 和 Trino 作为处理引擎。两者都在 Kubernetes 上运行。Trino 是一个用于大数据分析的分布式 SQL 查询引擎。它通过 Helm Chart 部署为一组 Pod（协调器和工作者）。它主要被数据分析师用来以类似 SQL 的方式查询数据，使用各种连接器——例如从 Jupyterhub 的魔法命令到本地的 dBeaver。

我们在Airflow（批处理）和Jupyterhub（交互模式）上运行Spark。在这两种情况下，我们使用客户端模式，因为这样可以让我们完全掌控Spark进程。

将 Spark 驱动程序（Spark driver）作为 Airflow 任务的子进程运行，可以实现与 Airflow 的紧密集成。首先，Spark 日志会被实时传输到 Airflow 任务日志中，从而实现对 Spark 处理的实时监控。其次，如果 Airflow 任务被终止（无论是从 UI 手动终止还是其他原因），Spark 进程也会被终止。这确保了 Airflow 任务的状态准确反映了 Spark 作业的状态，从而大大提高了 ETL 过程的可读性和维护便捷性。

我们在k8s上运行Spark非常有效，即使在大规模的任务中——每天都是这样。在处理高峰期时，我们一次请求大约1500个核心和4TB左右的内存，没有任何麻烦。

• 商务智能、数据科学

为了满足数据科学和报表的需求，我们使用了Jupyterhub和Apache Superset——所有这些服务都在k8s上通过官方的Helm图表来部署。

Apache Superset 是一个开源的商业智能工具，作为付费解决方案的替代品，它允许用户轻松创建复杂的仪表板。它可以与多种数据库配合使用（例如我们在使用Trino和Postgres），并提供单点登录（SSO）集成以及可配置的缓存层。所有这些功能结合无代码的网页界面和丰富的内置可视化选项，这使得 Superset 成为一个极具吸引力的付费解决方案替代品。

Jupyterhub 是我们用户与集群交互的起点。它允许用户使用 Python 笔记本文件来进行数据探索。我们为用户提供了一系列预设的连接器，用于连接 Trino 和 Spark，我们还提供了详尽的教程。这些连接器帮助用户以多种方式查询数据——从纯 SQL（通过使用 sql 魔法命令）到 pandas，再到 pySpark。

我们也为用户提供包含其选择的库和包的定制镜像。通过将用户环境打包进 Docker 镜像，我们确保他们能够获得最流畅的体验——无需担心虚拟环境或依赖项冲突。用户只需从提供的列表中选择所需的镜像，整个环境几秒钟就能准备好。添加新库不会破坏现有进程，因为新镜像是用新标签构建的。用户在准备好后可以随时切换，并且如果需要的话，还可以切换回之前的版本。

• 安全 (例如网络安全)

每个应用都有用户界面，并通过Oauth2与企业单点登录系统集成，根据用户的角色授予访问权限。

HDFS 和 Trino 通过 Kerberos 进行安全保护。为了访问权限控制，HDFS 集成了 Apache Ranger 插件，而 Trino 则使用 Open Policy Agent (OPA)。Ranger 和 OPA 也在 Kubernetes 中运行。

• 让用户更强大 — 使用代码管理的基础架构即代码与 ArgoCD

需要支持多个团队。

为了多个团队能够方便地利用集群及其处理能力，我们需要一种方式来统一部署多个应用，使其变得简单易行。幸运的是，有一个开源的解决方案可以解决这个问题——这就是我们所说的 ArgoCD。

以下文档 — ArgoCD 是一个声明式 GitOps 连续交付工具，适用于 Kubernetes。这意味着所有的基础设施都以代码形式存储在 Git 仓库中，而 ArgoCD 负责将这些基础设施部署到 k8s 集群。

我个人认为这是我们集群上最重要的应用，因为它主要的任务是简化部署——它确实做得很出色。将所有基础设施作为代码来管理确保了配置的重用性。得益于 ArgoCD 和 Kustomize，一个配置文件中的更改会自动应用到所有相关的命名空间。它还提高了可见性，因为所有的基础设施组件都在同一个位置。ArgoCD 还会通知集群中的任何配置与仓库中的配置不一致，并详细说明即将进行的更改。

所以例如，如果一个团队过来表示“嘿，我们想写自己的Airflow管道”，我们只需为他们提供一个Airflow实例。我们只需要做一些公司安全设置（git仓库、用户、角色和权限），在git仓库中创建一个新values-<团队名称>.yaml文件，包含特定团队的Airflow设置，然后——一个新的Airflow实例就可以准备部署了。然后，只需点击一下“同步按钮”就完成了。

• 轻松维护

部署内容的可见性减少了变更惰性，因此生产环境的变更变得更加频繁，因为频繁变更不再令人害怕 (✌️)。另外，ArgoCD 还提供了一个回滚功能，遇到问题时可以使用。

当我们的用户遇到新写的Trino查询失败时，我们很快确定这是一个已经在稍后版本中修复的Trino bug。部署新版本到生产环境大约花费了一个小时，包括在两个环境中的测试。这是因为只需在values.yaml文件中更新镜像版本，然后在ArgoCD中点击“同步”按钮即可。

尽管它现在运行得很顺畅，我们在设置其组件时也遇到了一些挑战。

在某个时刻，当我们启动了足够多的Spark进程并行运行时，DNS服务响应变得非常缓慢，以至于执行器因无法解析驱动器名称而失败。为解决这个问题，我们绕过了DNS，在Spark.driver.host中直接设置了IP地址。

我们也在Kubernetes上设置了PostgreSQL数据库，这些数据库作为各种应用程序的后端使用。在这里，过了一段时间后，我们才发现问题是由于慢速文件系统引起的。我们在Kubernetes中使用Ceph进行持久化存储，其中慢速的HDD驱动器导致了这个问题。当我们把PVC存储类改为Ceph中的SSD驱动器后，问题就解决了。

结论部分

通过应用容器化和最佳的软件实践，如版本控制、基础设施作为代码以及定期自动部署，我们构建了一个能够高效处理大量数据的数据平台，服务于多个团队和不同用户的需求。上述原则确保了该平台的可维护性，使得升级、修复和添加新组件变得简单直接。

我们还创建了一套预定义的配置和接口，以便用户可以访问数据，从而用户可以专注于创造业务价值。

最后但同样重要的是，这一切都是通过使用开源技术实现的 &#128170;。

观看我们在2024年大数据技术大会期间关于这个项目的演示：点击观看视频观看视频。

您可以看看这种数据平台是否适合您的业务，只需与我们的专家预约一次免费的35分钟咨询会。

博客作者：Franciszek Grobelny——数据工程师（作者）

这篇文章最初发表于https://getindata.com。