存算分离实践：构建轻量、云中立的大数据平台

原创

于 2023-08-16 17:18:36 发布 · 872 阅读

1 ·

CC 4.0 BY-SA版权

文章标签：

#大数据

本文详细描述了多点DMALL如何从存算一体架构转向云原生的存算分离，使用JuiceFS解决数据迁移和权限管理问题，实现性能优化和成本节省。

今天我们将分享社区用户多点 DMALL 的案例。多点 DMALL 是亚洲领先的全渠道数字零售解决方案服务商，目前已与 380 家零售企业达成合作，覆盖 6 个国家和地区。

面对 B 端客户日益增长的企业数据，存算一体的架构显得力不从心。计算资源冗余浪费、所依靠的CDH发行版技术栈复杂、部署运维困难及计算资源潮汐现象严重等问题，迫使多点启动架构升级的进程。同时，为满足 B 端客户多样化的需求，多点需要构建一个可以在多云环境下更具性价比、可复用的大数据底层基座和平台工具链。基于此，多点的大数据团队开始搭建存算分离的云原生大数据架构。

本文深入剖析这次改造的架构设计与演进过程，分享多点 DMALL 在此过程中的经验和挑战。值得一提的是，他们利用 JuiceFS 社区版实现了与 Ranger 组件进行权限的对接，希望此经验能为其他使用 JuiceFS 的企业提供参考。

一、存算一体架构下的痛点和挑战

1.1 架构原生存在的痛点

存算一体架构带来的成本和运维挑战，是大部分企业在大数据发展中一定会面对的问题。

传统的 Hadoop 生态体系中，数据存储角色与计算角色通常会部署在相同的机器上，一个占据硬盘提供存储，一个利用 CPU 和内存做计算。为此，MapReduce 和 Spark 也适应性的设计了多层级的数据本地化策略，即任务尽可能被分配到存储所需数据的对应节点上做计算，以减少中间数据交互产生的网络开销和额外的存储压力，提升整体的大数据应用效率。

可是，随着企业业务的发展，大数据存储量的增长速率与计算所需节点数量的增长速率很难保持一致。尤其是在“数据就是企业核心资产”的思想下，大量历史数据、冷数据的积累，导致企业数据存储量的增长诉求远远高于计算资源。最后企业只好不断新增机器存储更多数据，但大量计算资源得不到充分利用造成了闲置与浪费。

同样是增加存储资源，存算一体架构下会闲置部分计算资源，存算分离则不会有这个问题。

此外，数据量的不断增长还带来了 HDFS NameNode 元数据压力、集群节点规模扩张受限等问题。这些问题也时时刻刻牵动着各个大数据团队紧绷的神经。

1.2 多点DMALL 面临的挑战

多点DMALL 的大数据体系在构建之初，也是采用传统 Hadoop 存算一体的技术栈。除了上述企业发展中架构原生带来的困境外，面对 To B 多样化的业务场景，多点DMALL 大数据团队面临更多场景化的挑战：

组件多技术栈复杂：之前主要依赖 CDH 发行版本，该套架构组件繁多，架构复杂，共包括11类服务（存储、计算、运维、监控、安全等），22 种角色类型。并且随着时间推移，很多新技术引入异常麻烦，需要考虑非常多兼容性问题。
部署复杂 & 运维困难：私有化部署、SaaS 服务模式一度给大数据团队带来了巨大的工作量，交付效率不高，包括网络规划、容量规划、公有云机型选择、漏洞修复和多环境日常维护等。
计算资源潮汐现象严重：存算一体的架构下大数据集群和业务集群是相互独立的，资源使用有着不同的特点。大数据集群资源使用的高峰在凌晨，白天只有零散的即席查询占资源不多；业务集群的峰值在白天，晚上流量很少，这也是领域内老生常谈的“潮汐现象”，因此计算资源浪费和闲置一直没有彻底解决。