分布式计算框架有哪些：适配不同业务场景按需选用

前段时间接手公司离线数仓重构的活儿，被同事追问分布式计算框架有哪些，随口报了几个主流框架，事后复盘自己过往踩过的各类部署、适配的糟心经历，才发现很多同行包括新人，都只是听过框架名字，压根不知道什么场景该用哪一款。

最开始接触分布式计算，脑子里只记得Spark、MapReduce两个名字，那会儿刚入行做数据清洗，傻乎乎不管数据量级、任务类型，所有离线批量任务全都一股脑用MapReduce去跑。那会根本不懂底层运行逻辑，只觉得官方教程普及度最高，上手门槛看着很低。

现在回想起来纯是白费功夫。大批量日志脱敏、多表关联统计这类常规离线任务，MapReduce跑起来极其笨重，完整链路拆分太多，读写磁盘的频次高得离谱，两百多万条用户行为数据，单次聚合任务能硬生生跑三个多小时。而且开发效率极低，写简单的统计逻辑，都要单独编写Mapper和Reducer两层代码，代码冗余度高到离谱，改一行参数都要重新打包上传集群。

也就只有超大型老旧集群，且团队技术栈固化、不愿意更换架构的企业，还会保留这款框架，其余场景基本都被替代了。

换框架的契机，是某次紧急报表需求。业务那边要求四小时内输出日活分层报表，沿用MapReduce铁定超时。组里老员工直接让换成Spark，也是这次实操，才算真正摸清这款框架的优势。

内存计算的特性真的能拉开巨大差距，同样两百万条数据的聚合任务，Spark直接跳过反复读写磁盘的步骤，依托内存完成数据迭代计算，耗时直接压缩到二十分钟以内。其实Spark的适配范围特别广，离线批量计算、交互式数据分析、简单的流式任务都能兼顾，而且兼容绝大多数Hive SQL语法，不用大规模改写原有业务代码。

但也不是完美无缺，内存占用是最大痛点。之前做千万级数据全量join操作，没手动调整资源分配，直接导致集群内存溢出，整个任务直接挂掉，连带占用其余节点资源，耽误了小半天的工作进度。反正做实时性偏弱、追求开发效率的批量任务，选它准没错；高频次超高并发的实时场景，就别硬上。

很多人容易忽略Flink，我之前也一样，一直把它和Spark混为一谈，直到做实时风控系统才彻底分清二者的区别。

简单说，Flink才是主打实时计算的王牌。底层基于流式架构，所有数据都会被当成实时数据流处理，支持毫秒级的数据处理延迟，适配风控告警、实时大屏、订单监控这类对时效性要求极高的业务。之前搭建实时用户行为监控大屏，用Spark Streaming做尝试，延迟始终维持在秒级，切换成Flink之后，延迟直接稳定在百毫秒区间。

为数不多的短板，就是学习成本偏高。状态管理、checkpoint容错机制这些专属概念，需要花时间吃透，新手上手很容易出现数据重复计算、数据丢失的问题。

还有两个偏小众，但实用性拉满的框架。

Ray，算是近些年新兴的轻量化分布式计算框架，和前面几款侧重点完全不同。它不主打大数据批量处理，核心服务于AI训练、模型推理、复杂算法调度。之前协助算法组做模型分布式训练，传统框架配置繁琐，Ray只需要几行简单代码，就能拆分算力、调度多节点并行训练，轻量化属性是它最大的杀手锏。

最后就是Oceanus，腾讯开源的一站式分布式计算平台，本质是封装了Flink的上层工具，不用底层编写大量原始代码，可视化界面就能配置实时、离线任务。小型互联网团队、没有专职大数据开发的小组，用它能省下超多开发成本。

下班关电脑前，盯着桌面上还没整理完的框架适配文档，只觉得行业里从来不存在万能的分布式计算框架。所有人纠结的点从来都不是单纯知道有哪些框架，而是没办法结合自身业务，筛选出最合适的那一个。