一台服务器上运行 60 个容器
一个裸金属服务器运行数十到数百个 Hoody 容器。KSM 和 BTRFS 去重使边际成本接近零。
容器·快照
use-cases / daily-rollups-no-orchestrator / hero
DAILY ROLLUPS · NO ORCHESTRATOR
无需编排器的每日汇总
每晚 1 点,一条 cron 条目 curl 一个 exec URL。脚本在 sqlite URL 上跑你的汇总 SQL,把每日表写回去。无 Airflow Postgres,无 DAG 文件,无带 14 个组件的调度器仪表盘,也没人为编排器自身待命。
ROLLUP / TODAY
https://exec.containers.hoody.com/scripts/rollup/today200 OK
SIGNUPS1,284+12.4% WoW
MRR$48,720+3.1% WoW
CHURN1.8%-0.4 pp WoW
DAU9,613+0.2% WoW
ROLLUP.SQL
rollup.sqlSELECT date_trunc('day', created_at) AS d,
count(*) AS n
FROM events
WHERE created_at >= 'today'
GROUP BY 1 -- the whole pipelineCRON0 1 * * *
LAST RUN2026-05-04 01:00:07 UTC
仪表盘就是编排器。一个 URL。一份调度。
use-cases / daily-rollups-no-orchestrator / mechanism
两个 URL 加一份五字段调度
整条流水线就是一条 cron 条目指向一个 exec URL。cron 条目是一次 POST 到 /users/root/entries。exec URL 是个小脚本,打开 sqlite URL、跑汇总 SQL、返回新行。这就是整个 DAG。
POST /users/root/entries
调度// every night at 01:00 UTC
POST /users/root/entries
{
"schedule": "0 1 * * *",
"command": "curl -fsS https://exec.containers.hoody.com/scripts/rollup/run"
}1AM · CURL
exec.containers.hoody.com/scripts/rollup/run
流水线// the entire pipeline body
import { Database } from "bun:sqlite";
const db = new Database("events.db");
db.run(`INSERT INTO rollup_daily
SELECT date_trunc('day', created_at), count(*)
FROM events GROUP BY 1;`);
return { ok: true, rows: db.query("SELECT * FROM rollup_daily").all() };汇总失败,cron 日志会说。要补昨天的数据,你手动 curl exec URL 加一个 date 参数。无第二套系统要学,无调度器数据库要存活,无 DAG 文件要提交。编排器,就是一条指向 URL 的 cron 条目。
use-cases / daily-rollups-no-orchestrator / powers
你不必再造的轮子
Hoody Kit 把调度器、运行时、存储以普通 HTTP 服务的形式交付。流水线就是它们之间的那次 curl——别无他物。
无编排守护进程
调度器是一条 HTTP 条目
hoody-cron 把调度作为资源存在 /users/root/entries。无需备份的 Postgres 元数据库,无需保活的调度器容器,无需部署的 DAG 仓库。POST 一行,运行触发。
无运行时接线
脚本就是一个 URL
hoody-exec 在 exec.containers.hoody.com/scripts/rollup/run 按需运行汇总脚本。cron curl 它,拿到 200,记录响应。无 worker 队列,无 broker,无 pickle 化的任务图。
无日志管道
运行历史就是响应体
每次 exec 调用以 JSON 形式返回新行,并由 cron 记录状态、时间戳和 stdout。补数、失败、重跑都活在同样的两个 URL 里——不必额外推送到日志聚合器。
use-cases / daily-rollups-no-orchestrator / backfill
如果运行失败——或需要补数
流水线就是两个 URL 加一个日期参数。重跑昨天与每晚跑形状一致,只是 exec URL 上加 ?date=2026-04-30。无重放 UI,无调度器怪癖。
- 01 · 检测
cron 日志说它失败了
如果 1 点的运行返回非 2xx,该条目在 hoody-cron 上的最后一次运行记录会显示退出码和捕获的响应体。无需另接告警服务——GET 条目读一下即可。
- 02 · 补数
用 ?date= curl exec URL
脚本接受一个日期参数。传昨天的日期,它会重算那一天的 rollup 行,通过 INSERT OR REPLACE 替换坏的那一行。一条命令,无需 DAG 重触发 UI。
- 03 · 验证
响应就是新写入的那一行
exec 以 JSON 返回刚写入的 rollup 行。和你预期 diff 一下,然后继续干别的。没别的要查——仪表盘 URL 服务的就是你刚写的那张表。
// rerun yesterday's rollup by handcurl -fsS https://exec.containers.hoody.com/scripts/rollup/run?date=2026-04-30
use-cases / daily-rollups-no-orchestrator / capacity
流水线的形状
三个数字描述整个系统。把它们和今天你仓库里的 Airflow 部署对比一下。
- 字段 · CRON 调度5
分、时、日、月、周。这就是“运行何时触发”的全部配置面。
- URL · ENTRY + EXEC2
一个 POST 注册调度,一个 GET 跑脚本。这就是整条可部署的流水线。
- 守护进程 · 无编排器0
无需保活的调度器进程,无元数据库,无 worker 池。Hoody Kit 持有调度并运行脚本。
数字描述了 Hoody Kit 上的 cron + exec 模型。你现有的流水线大概率有更多活动部件;这正是对比的意义。
use-cases / daily-rollups-no-orchestrator / punchline
编排器,就是一条指向 URL 的 cron 条目。
之前 · 一摞调度栈之后 · 一行 cron
BEFOREairflow webserver + scheduler + worker + postgres + dags/rollup_daily.py五个进程、一个元数据库、一个 DAG 文件仓库
NOW0 1 * * * curl -fsS https://exec.containers.hoody.com/scripts/rollup/run一行。一个 URL。一份调度。
use-cases / daily-rollups-no-orchestrator / replaces
它替代了什么
编排层坍缩成一行 cron。DAG 活在你的脚本里。
- Apache Airflow为一条查询装上 Postgres + Redis + 调度器 + worker
- Prefect云账号、agent 安装、flow 注册
- DagsterPythonic,但仍然是一个要运维的服务
- Luigi为每晚的 SQL 装一个图引擎
- GitHub Actions schedules锁在 main,无按租户上下文
- dbt Cloud用 SaaS 包一层 CLI 再去包一个 SELECT
- 自定义 Python 调度器一个 while 循环加 try/except,自称"健壮"
use-cases / daily-rollups-no-orchestrator / cta
别再运维编排器。运维一条 cron 条目就够了。
use-cases / daily-rollups-no-orchestrator / related
阅读其他内容
