将Hadoop迁移到云端：存储容量翻倍，运维成本降低

一面是一家专注于数字商务数据分析的领先人工智能驱动数据分析服务商。我们提供关于商业战略、产品开发及数字商务运营的实时洞察。众多客户中，不乏个人护理、美妆、食品饮料、宠物及汽车行业的领军企业，如宝洁、联合利华和玛氏。

最初，我们的技术架构是在本地数据中心搭建的基于CDH（Cloudera分布式Hadoop）的大数据集群。随着业务扩张，数据量激增。

为应对扩容周期长、计算与存储资源不匹配及高昂维护成本等挑战，我们决定重构数据架构，迁移至云端，并采用存储与计算分离策略。经过审慎评估，我们选择了阿里云弹性MapReduce（EMR）搭配JuiceFS及阿里云对象存储服务（OSS）。

如今，借助JuiceFS，我们已成功构建了计算与存储解耦的架构，总存储容量翻倍。值得一提的是，性能并未受到显著影响，而运营成本却大幅下降。

本文将分享我们迁移Hadoop至云端的架构设计，为何选择JuiceFS+EMR+OSS，以及新架构带来的益处。旨在为面临类似挑战的读者提供有价值的见解。

旧架构与挑战

为满足日益增长的需求，我们已从数百个大型网站爬取数据，目前数量超过500个。随着时间的推移，我们积累了大量的原始、中间及结果数据。随着网站爬取范围和客户群的扩大，数据量迅速增长，因此我们决定扩充硬件以适应增长的需求。

原始架构

下图展示了我们之前的架构，基于CDH的大数据集群部署在数据中心内：

• 关键组件包括Hive、Spark和HDFS。
• 多个数据生产系统，其中Kafka是其一，向集群提供数据。
• 我们还使用了其他存储解决方案，如TiDB、HBase和MySQL，与Kafka并行。

Original architecture at Yimian

数据从上游应用系统和数据收集系统流入，写入Kafka。我们利用Kafka Connect集群将数据同步至HDFS。

在此架构基础上，我们开发了名为OneWork的自定义数据开发平台，用于管理各类任务。这些任务通过Airflow进行调度，并在任务队列中处理。

痛点

我们面临的挑战如下：

• 应用数据快速增长与扩展周期过长： 我们于2016年部署的CDH集群，至2021年已处理了数PB级别的数据。然而，数据增长往往超出硬件规划，导致每半年频繁进行扩容，消耗了大量资源和时间。
• 存储与计算紧耦合及容量规划困难： 传统Hadoop架构中存储与计算的紧密结合，使得根据存储或计算需求独立进行扩展和规划变得困难。例如，扩展存储时也必须购买不必要的计算资源，导致资源分配效率低下。
• 因CDH版本老旧而惧怕升级： 我们的CDH版本较旧，由于担心稳定性和兼容性问题，一直犹豫不决是否进行升级。
• 高昂的运维成本： 尽管公司约有200名员工，却仅配备一名全职运维人员，工作负担沉重。为缓解此压力，我们寻求一种更稳定、简化的架构。
• 单一数据中心存在单点故障风险： 所有数据存储于单一数据中心，长期来看存在较大风险。一旦发生电缆损坏或其他问题，单一数据中心就成为故障的集中点。

我们对新架构的需求

为应对上述挑战并满足日益增长的数据需求，我们决定进行一些架构调整。在升级过程中，我们主要考虑了以下几个方面：

• 云采用、弹性扩展和操作灵活性：采纳云服务将简化运营。例如，利用基于云的存储使我们能够专注于应用程序，同时避免维护任务。此外，云资源实现了无需冗长硬件部署和系统配置的弹性扩展。
• 存储与计算解耦：我们的目标是将存储和计算分离，以实现更好的灵活性和性能。
• 偏好开源组件，避免供应商锁定：尽管我们使用云服务，但我们寻求最小化对特定供应商的依赖。在使用AWS Redshift为客户服务的同时，我们倾向于为内部操作选择开源组件。
• 与现有解决方案兼容，控制成本和风险：我们的目标是确保与当前解决方案的兼容性，以最小化开发成本和对应用程序的影响。

为何选择JuiceFS+EMR+OSS

在评估了多种解决方案后，我们选择了EMR+JuiceFS+OSS来构建一个存储与计算分离的大数据平台，并逐步将我们的本地数据中心迁移到云端。

New architecture at Yimian

在此架构中，对象存储替代了HDFS，而JuiceFS作为协议层，因其支持POSIX和HDFS协议。在最上层，我们使用了一个半托管的Hadoop解决方案，EMR，它包含了Hive、Impala、Spark、Presto/Trino等组件。

阿里云与其他公有云的对比

经过仔细评估，我们选择了阿里云而非AWS和Azure，主要基于以下因素：

• 接近性: 阿里云的可用区与我们的数据中心同城，确保了低延迟和降低的网络成本。
• 全面的开放源代码组件: 阿里云EMR提供了广泛的与Hadoop相关的开放源代码组件。除了我们大量使用的Hive、Impala、Spark和Hue外，它还与Presto、Hudi、Iceberg等实现了无缝集成。在我们的研究中，我们发现只有EMR原生包含Impala，而AWS和Azure要么提供较低版本，要么需要手动安装和部署。

JuiceFS与JindoFS的对比

什么是JuiceFS?

JuiceFS 是一个开源的、云原生的、高性能的分布式文件系统。它提供完全的POSIX兼容性，允许在不同平台和地区将对象存储作为大规模本地磁盘使用。

JuiceFS采用数据-元数据分离的架构，实现了分布式文件系统的设计。当使用JuiceFS存储数据时，数据持久化存储在如Amazon S3这样的对象存储中，而元数据可以存储在Redis、MySQL、TiKV、SQLite等数据库中。

除了POSIX，JuiceFS完全兼容HDFS SDK，允许无缝替换HDFS以实现存储计算分离。

The JuiceFS architecture

为何选择JuiceFS而非JindoFS

我们基于以下考虑选择了JuiceFS而非JindoFS：

• 存储设计: JuiceFS采用数据与元数据分离存储的架构，实现分布式文件系统设计。数据持久化存储于对象存储中，而元数据则可存储于Redis、MySQL、TiKV、SQLite等多种数据库，提供更高的灵活性。相比之下，JindoFS的元数据存储在EMR集群的本地硬盘上，使得维护、升级和迁移变得不那么便捷。
• 存储灵活性: JuiceFS提供多种存储方案，支持不同方案间的在线迁移，增强了可移植性。JindoFS块数据仅支持OSS。
• 开源社区支持: JuiceFS基于开源社区，支持所有公有云环境，便于未来扩展至多云架构。

整体架构设计

考虑到部分应用仍将保留在数据中心的Hadoop集群中，我们实际上采用了一种混合云架构，如下图所示。

A hybrid cloud architecture

在架构图中：

• 顶部是Airflow和OneWork，两者均支持分布式部署，因此可以轻松进行水平扩展。
• 左侧是IDC，采用传统的CDH架构和部分Kafka集群。
• 右侧是在阿里云上部署的EMR集群。

IDC与EMR集群通过高速专线连接。

我们从新架构中获得的益处

存储与计算分离带来的好处

通过存储计算解耦，我们的总存储容量翻倍，而计算资源保持稳定。偶尔根据需要启用临时任务节点。在我们的场景中，数据量迅速增长，而查询需求保持稳定。自2021年以来，我们的数据量已翻倍。从初期到现在，除了偶尔启用弹性资源和临时任务节点以满足特定应用需求外，计算资源的变动极小。

性能变化

对于我们主要涉及大规模批处理进行离线计算的应用场景，性能上没有显著影响。但在PoC阶段，我们观察到即席Impala查询的响应时间有所改善。

在PoC阶段，我们进行了一些简单测试。然而，由于多种影响因素，准确解读结果颇具挑战：

• 从HDFS迁移到JuiceFS
• 组件版本升级
• Hive引擎的变更
• 集群负载的变化

所有这些因素使得与我们在裸机服务器上部署CDH的先前版本相比，难以得出关于性能差异的明确结论。

易用性与稳定性

我们未遇到JuiceFS的问题。

在使用EMR时，我们遇到了一些小问题。总体而言，CDH被认为更稳定且用户友好。

实施复杂性

在我们的场景中，最耗时的过程是增量双写和数据验证。回顾过去，我们在验证上投入过多，其实可以简化。

复杂性受多种因素影响：

• 应用场景（离线/实时、表/任务数量、上层应用）
• 组件版本
• 支持工具和储备

未来计划

我们的未来计划包括：

• 继续将剩余应用迁移至云端。
• 探索使用JuiceFS+OSS的冷热分层存储策略。JuiceFS文件在OSS上完全拆分，使得文件级分层实施较为困难。我们目前的做法是将JuiceFS中的冷数据迁移到OSS，设置为归档存储，并修改Hive表或分区的LOCATION，不影响使用。
• 如果数据量增加且Redis使用压力增大，未来可能会考虑转向TiKV或其他引擎。
• 探索EMR的弹性计算实例，以降低使用成本同时满足应用服务级别协议。