从参数直传到Pipeline: 一次可复现可观测的数据处理管线改造实践
从参数直传到 Pipeline:一次可复现、可观测的数据处理管线改造实践 副标题: 为什么当处理链变得越来越长时,“配置驱动 + 上下文 + 外部存储”的 Pipeline 模式会比“参数直传”更适合工作? 标签: Python / Pipeline / ETL / 数据工程 / 架构设计 适读人群: 后端开发、数据工程师、做文档处理/Embedding/索引构建的同学 阅读时间: 10–15 min 摘要: 本文记录我从“领域模型传来传去”的后端式写法,迁移到“配置驱动 Pipeline”模式的过程,总结落地要点、踩过的坑,以及为什么这种模式更适合复杂的数据加工链。 🧭 写这篇文章的动机 做后端时,我长期习惯一种简单粗暴的风格: 需要什么参数就一直往下传,函数链一路 call 下去。 很多业务都是这么写的: 输入是个模型/DTO 处理完传下一个函数 大对象在链路里飘来飘去 但当我开始做 文档处理、Embedding、实体提取、索引构建 这种“多步骤、可重跑、需观测”的任务时,这种写法很快失效: 需要重跑某一步时必须重建整条调用链 中间产物无法落地检查 改一个策略需要改一堆函数签名 并发 / 异常恢复都难处理 后来接触到构建数据处理 Workflow / ETL Pipeline 的方式,发现它的核心思路完全不一样: 配置驱动策略 → 上下文承载运行态 → 外部存储承载数据流。 这套体系让多步处理链突然变得可插拔、能恢复、能观测、能重放。 于是就有了这篇文章,把我的心智迁移过程与实践要点记录下来。 ⚡ TL;DR(你只看这一屏也能理解本文核心) 配置驱动: 路径、模型、超参都写 config,而不是塞进函数参数里。 上下文 context: 统一管理 I/O 句柄、缓存、回调、统计、运行时标志。 外部存储: 步骤间不传大对象,读写约定表名:documents → text_units → entities → index。 可插拔 Pipeline: “步骤名 → 函数指针”的顺序列表,可一键切换 Standard/Fast 等方案。 幂等与恢复: 中间表持久化,可覆盖或版本化,崩溃后能断点续跑。 观测与回调: start/end/进度统一上报,产出 stats.json,定位问题更快。 异步友好: 步骤 await 执行,内部可分片并发或调用 LLM。 取舍: 成本是心智负担增加;收益是可观察、可重跑、可替换、低耦合。 👥 目标读者 适合以下同学阅读: ...