SETIHome 是早期互联网时代最有代表性的分布式计算项目之一。它把射电望远镜采集到的观测数据切成很小的数据片段通过互联网分发给全球志愿者的个人电脑让大量普通 CPU 在空闲时帮忙分析其中可能存在的地外文明信号。这个项目从 1999 年开放到 2020 年进入休眠虽然没有给出“发现外星信号”的确凿证据但它第一次让普通用户用一块家用 CPU 参与前沿科学计算也在工程层面留下了一套非常值得拆解的工作模式工作单元如何切分、重复计算结果如何校验、不可靠的志愿者节点如何调度、结果如何回溯。下面不聊情怀直接拆机制。先还原 SETIHome 的分布式计算链路再用一个最小 Python 原型复现“切分、分发、回传、校验、重试”五个环节最后对照 BOINC 平台总结设计这类众包计算系统时可以参考的工程原则和常见坑。1. SETIHome 的本质用互联网收集“空闲算力”1.1 一个普通 PC 是怎样参与到科学计算里的SETIHome 的思路可以压缩成一句话把超算中心才能算完的任务拆成无数个普通电脑都能算的小任务再通过互联网把结果收回来。志愿者要做的事情非常简单下载并安装客户端软件。客户端自动向服务器申请一个“工作单元”。电脑空闲时开始计算计算过程中屏幕保护程序会显示信号分析的图形。算完后把结果上传然后申请下一个工作单元。对志愿者电脑来说参与成本几乎为零。对项目方来说等于获得了由全球志愿者组成的超大规模计算集群。这个模式后来被统称为“志愿计算”它的工程本质是在不可信、不稳定、数量极大的计算节点上完成一组可分割、可校验、结果可重放的科学任务。注意一个关键点客户端不是一直满负荷运算。它通常在空闲时运行科学计算程序用户使用电脑时则让出 CPU 资源。这个机制让“算力捐赠”不打扰客户端主人的正常使用也决定了这类系统必须能随时中断、随时重来。1.2 什么样的任务适合这种“搬回家算”的模式不是所有计算任务都能搬上志愿者网络。SETIHome 能成功是因为射电数据处理恰好具备四个重要特征特征为什么重要SETIHome 的对应情况任务可切分只有切成独立小任务才能分发到不同电脑并行计算观测数据按时间片切分为工作单元计算量远大于传输量否则网络开销会吞掉算力收益一个工作单元约几百 KB分析却需要大量 FFT 计算结果可自动校验志愿者节点不可信必须能判断结果好坏同一个工作单元分发给多个节点比对回传结果数据低敏感数据需要发到外部节点不能涉及隐私和机密射电观测数据属于公开科学数据反过来如果任务强依赖执行顺序、需要节点之间频繁同步、数据不能出域、或者结果无法自动判断对错那就不适合众包计算。这也是很多企业内部建设“分布式任务计算平台”之前要先做任务适配性评估的原因。1.3 项目时间线与留给后来者的技术遗产SETIHome 的公开运营时间线大体如下1999 年 5 月项目正式对外开放志愿者通过经典客户端接收工作单元。2004 年前后项目迁移到 BOINC 平台客户端和服务器模型都被通用化。2020 年 3 月项目官方宣布进入休眠状态不再分发新的工作单元。2020 年 12 月阿雷西博射电望远镜因结构故障塌落项目的数据来源随之中断。项目休眠不等于遗产消失。它留下的东西至少有三类BOINC 平台一个不依赖 SETIHome 的通用志愿计算框架今天仍被多个科学项目使用。工作单元、结果校验、信用积分这一套工程模型成为后续众包计算系统的范式参考。全球数百万规模的志愿者参与记录证明了“闲置算力汇聚”在互联网上是可行的。了解完背景可以进入机制拆解了。这套机制决定了后来 BOINC 和同类平台的基本形态。2. 拆解核心机制工作单元、双副本计算与结果校验2.1 工作单元的切分和状态流转SETIHome 的服务器会把观测数据切成很多小份每一份就是一个工作单元英文叫 Work Unit。经典客户端时期一个工作单元大致对应约 107 秒的射电观测数据数据量在几百 KB 级别。服务端必须为每个工作单元维护一个状态否则无法回答这几个问题这个任务发出去没有发给了谁有没有按时回传结果靠不靠谱典型状态可以整理为状态含义谁负责维护pending等待分发服务端调度器in progress已发给某个客户端尚未回传服务端调度器completed结果通过校验并被采纳服务端校验器invalid结果超时、损坏或未通过校验服务端校验器error客户端上报计算失败或上传数据损坏服务端校验器状态流转的关键是“超时重新分发”。客户端可能断网、关机、误删任务服务端不可能无限等待。只要
拆解SETI@Home：工作单元切分、结果校验与分布式计算范式
SETIHome 是早期互联网时代最有代表性的分布式计算项目之一。它把射电望远镜采集到的观测数据切成很小的数据片段通过互联网分发给全球志愿者的个人电脑让大量普通 CPU 在空闲时帮忙分析其中可能存在的地外文明信号。这个项目从 1999 年开放到 2020 年进入休眠虽然没有给出“发现外星信号”的确凿证据但它第一次让普通用户用一块家用 CPU 参与前沿科学计算也在工程层面留下了一套非常值得拆解的工作模式工作单元如何切分、重复计算结果如何校验、不可靠的志愿者节点如何调度、结果如何回溯。下面不聊情怀直接拆机制。先还原 SETIHome 的分布式计算链路再用一个最小 Python 原型复现“切分、分发、回传、校验、重试”五个环节最后对照 BOINC 平台总结设计这类众包计算系统时可以参考的工程原则和常见坑。1. SETIHome 的本质用互联网收集“空闲算力”1.1 一个普通 PC 是怎样参与到科学计算里的SETIHome 的思路可以压缩成一句话把超算中心才能算完的任务拆成无数个普通电脑都能算的小任务再通过互联网把结果收回来。志愿者要做的事情非常简单下载并安装客户端软件。客户端自动向服务器申请一个“工作单元”。电脑空闲时开始计算计算过程中屏幕保护程序会显示信号分析的图形。算完后把结果上传然后申请下一个工作单元。对志愿者电脑来说参与成本几乎为零。对项目方来说等于获得了由全球志愿者组成的超大规模计算集群。这个模式后来被统称为“志愿计算”它的工程本质是在不可信、不稳定、数量极大的计算节点上完成一组可分割、可校验、结果可重放的科学任务。注意一个关键点客户端不是一直满负荷运算。它通常在空闲时运行科学计算程序用户使用电脑时则让出 CPU 资源。这个机制让“算力捐赠”不打扰客户端主人的正常使用也决定了这类系统必须能随时中断、随时重来。1.2 什么样的任务适合这种“搬回家算”的模式不是所有计算任务都能搬上志愿者网络。SETIHome 能成功是因为射电数据处理恰好具备四个重要特征特征为什么重要SETIHome 的对应情况任务可切分只有切成独立小任务才能分发到不同电脑并行计算观测数据按时间片切分为工作单元计算量远大于传输量否则网络开销会吞掉算力收益一个工作单元约几百 KB分析却需要大量 FFT 计算结果可自动校验志愿者节点不可信必须能判断结果好坏同一个工作单元分发给多个节点比对回传结果数据低敏感数据需要发到外部节点不能涉及隐私和机密射电观测数据属于公开科学数据反过来如果任务强依赖执行顺序、需要节点之间频繁同步、数据不能出域、或者结果无法自动判断对错那就不适合众包计算。这也是很多企业内部建设“分布式任务计算平台”之前要先做任务适配性评估的原因。1.3 项目时间线与留给后来者的技术遗产SETIHome 的公开运营时间线大体如下1999 年 5 月项目正式对外开放志愿者通过经典客户端接收工作单元。2004 年前后项目迁移到 BOINC 平台客户端和服务器模型都被通用化。2020 年 3 月项目官方宣布进入休眠状态不再分发新的工作单元。2020 年 12 月阿雷西博射电望远镜因结构故障塌落项目的数据来源随之中断。项目休眠不等于遗产消失。它留下的东西至少有三类BOINC 平台一个不依赖 SETIHome 的通用志愿计算框架今天仍被多个科学项目使用。工作单元、结果校验、信用积分这一套工程模型成为后续众包计算系统的范式参考。全球数百万规模的志愿者参与记录证明了“闲置算力汇聚”在互联网上是可行的。了解完背景可以进入机制拆解了。这套机制决定了后来 BOINC 和同类平台的基本形态。2. 拆解核心机制工作单元、双副本计算与结果校验2.1 工作单元的切分和状态流转SETIHome 的服务器会把观测数据切成很多小份每一份就是一个工作单元英文叫 Work Unit。经典客户端时期一个工作单元大致对应约 107 秒的射电观测数据数据量在几百 KB 级别。服务端必须为每个工作单元维护一个状态否则无法回答这几个问题这个任务发出去没有发给了谁有没有按时回传结果靠不靠谱典型状态可以整理为状态含义谁负责维护pending等待分发服务端调度器in progress已发给某个客户端尚未回传服务端调度器completed结果通过校验并被采纳服务端校验器invalid结果超时、损坏或未通过校验服务端校验器error客户端上报计算失败或上传数据损坏服务端校验器状态流转的关键是“超时重新分发”。客户端可能断网、关机、误删任务服务端不可能无限等待。只要