dagster中资产（asset）是可调度、可观察、可复用的最小单元，须用@asset声明输入输出与依赖，禁用io操作，依赖iomanager处理读写，键（key）决定真实依赖关系，调试需用materialize而非build_assets_job。
资产（Asset）不是装饰，是 Dagster 里可调度、可观察、可复用的最小单元
你写了个数据清洗函数，但 Dagster 报错 AssetKey must be provided——这不是语法错误，是思维没切过去。Dagster 不鼓励“写个函数再塞进 job”，它要求你从第一行就声明：这个输出是什么、依赖什么、怎么更新。比如用 @asset 装饰器定义一个表，它自动获得 lineage 追踪、materialization 日志、上游变更触发重算能力；而用 @op 写同样逻辑，你就得手动拼 ConfigurableResource、自己管重试和状态上报。
-
@asset函数必须返回具体值（如pd.DataFrame），不能只做副作用（如只写文件） - 多个资产间依赖靠函数参数名自动绑定：
@asset def orders_cleaned(customers: pd.DataFrame):→customers参数名必须和上游资产的key或函数名一致 - 别在
@asset里调yield Output(...)，那是@op的用法，会直接报TypeError: asset functions must return a value
从 @op 迁移到 @asset 时，I/O 逻辑必须外提成 Resource 或 I/O Manager
Dagster 要求资产专注“计算”，不许混 IO。你在 @op 里写的 pd.read_parquet("s3://...") 和 .to_sql()，搬到 @asset 后会立刻失败——因为资产函数体里禁止任何外部存储读写。
- 读取逻辑移进
IOManager：实现load_input方法，Dagster 自动在依赖注入时调用 - 写出逻辑也交给
IOManager：覆盖handle_output，返回None即可，别在资产函数里open().write() - 如果用
ConfigurableResource（比如PostgresResource），确保它只被IOManager或@op使用，@asset函数签名里不能出现资源实例参数
资产分组（group_name）和键（key）不一致，会导致 UI 里找不到依赖关系
你在代码里写了 @asset(group_name="sales")，但上游资产定义在另一个模块，用的是 @asset(key=AssetKey(["sales", "orders"])) ——Dagster UI 上这两个资产不会连成线，调度时也不会自动感知变更。资产键才是真实 ID，group_name 只是 UI 分组标签，不参与依赖解析。
- 推荐统一用
key显式声明：例如@asset(key=AssetKey(["marketing", "campaign_spend"])) - 避免仅靠函数名推导 key，尤其跨文件时容易冲突（两个同名函数 → 同 key → 调度冲突）
-
group_name可以留空，或只用于前端归类，别指望它影响执行逻辑
本地调试资产时，build_assets_job 会掩盖真正的执行路径
你跑 build_assets_job 测试单个资产，结果发现日志里没触发 IOManager.handle_output，或者上游资产根本没运行——因为 build_assets_job 是为测试 job 编排设计的，它会跳过未声明依赖的资产，也不走完整 materialize 流程。
立即学习“Python免费学习笔记（深入）”；
- 真要验证资产行为，用
materialize([my_asset])，它模拟真实调度上下文，强制加载IOManager、触发所有load_input/handle_output -
materialize默认使用InMemoryIOManager，想测 S3/DB 行为，得显式传resources参数绑定真实 resource 实例 - 别在
materialize调用里改 asset 函数体加print()，Dagster 会缓存函数对象，改了也不生效，得重启 Python 进程
资产化迁移最难的不是写法，是把“我写个脚本处理数据”的习惯，换成“我声明一个有明确输入、输出、生命周期的数据实体”。一旦 key、IO、依赖这三块对齐了，后续加监控、设 SLA、接告警，才真正顺下来。
