InchStack 与传统 ETL / 数据集成平台的边界
对比 InchStack 与传统 ETL、数据集成、Airbyte、Fivetran、DataX、Kettle 等工具的分工：执行引擎负责连接和运行，InchStack 负责治理上下文、审批证据和交付闭环。
适用对象
核心结论
- 不要把 InchStack 理解为替代所有 ETL 工具，它更适合管理交付上下文和控制流程。
- 传统 ETL 工具的连接器、执行、同步和调度能力仍然有价值。
- InchStack 可把治理口径、字段映射、质量校验、审批证据和交付回执组织起来。
传统 ETL 和数据集成平台通常围绕连接器、任务编排、数据同步、转换执行、监控告警和失败重试展开。Airbyte、Fivetran、DataX、Kettle 以及企业自研同步系统，都在这些方面提供了成熟或专门能力。
InchStack 不应被包装成替代所有 ETL 工具的平台。企业已经有稳定执行引擎时，替换成本和生产风险都很高。更合理的定位是：继续让传统 ETL 工具负责连接和执行，让 InchStack 管理这次数据变更背后的治理上下文、业务目标、字段口径、审批证据和交付材料。
两类工具关注的问题不同。传统 ETL 更常回答“数据如何从 A 到 B”，InchStack 更关注“为什么要同步这些数据、字段如何解释、转换规则谁确认、质量校验是否通过、失败后如何回滚、最终交付给业务什么证据”。
AI 的价值也应该放在这个边界内。模型可以帮助起草字段映射、转换规则、异常说明和变更影响分析，但执行前需要 dry-run、权限校验、质量校验和人工审批。这样既利用 AI 降低方案设计成本，又避免模型绕过生产控制点。
因此，当用户已经拥有 ETL 工具时，推荐路径不是迁移，而是先选择一个高频、低风险但沟通成本高的数据集成场景，用 InchStack 建立可审批、可验证、可回滚的交付闭环。验证有效后，再逐步扩展到更多数据域。
常见问题
什么时候应该优先选择传统 ETL 工具？
当主要需求是连接器覆盖、批量同步、调度执行和运行监控时，传统 ETL 或数据集成平台更直接。
什么时候应该引入 InchStack？
当 ETL 变更涉及业务口径、治理规则、人工审批、质量证据、客户交付或复盘责任时，InchStack 可以补齐控制面。