13 KiB
13 KiB
- [P20260218-110114] 2026-02-18 11:01:14 +0800
- summary: 帮我查代码，查数据库，收集信息：1 ETL连接器 feiqiu 的 DWD to DWS/INDEX 的流程是怎样的？任务配置，参数等向我详细介绍。形成.md文档。2 ETL连接器 feiqiu 的 任务调度 最上层有几个模式，如何处理任务…
- prompt:
帮我查代码，查数据库，收集信息：1 ETL连接器 feiqiu 的 DWD to DWS/INDEX 的流程是怎样的？任务配置，参数等向我详细介绍。形成.md文档。2 ETL连接器 feiqiu 的 任务调度 最上层有几个模式，如何处理任务？怎样的流程？KiroRun Command HookAudit Flagger (Prompt Submit)Run Command HookPrompt Audit Log (Shell)好的，我先用 context-gatherer 来全面探索 ETL 连接器的代码结构，然后再深入阅读关键文件。Invoked Context Gatherer需要全面探索 ETL 连接器的代码结构，了解 DWD→DWS/INDEX 流程和任务调度系统的完整架构。Now I have comprehensive understanding. Let me create a detailed summary document:Read file(s)base_task.py 1 - 81base_dws_task.py 55 - 171base_index_task.py 41 - 151task_registry.py 1 - 101pipeline_runner.py 1 - 101task_executor.py 1 - 101main.py 1 - 101assistant_daily_task.py 1 - 101winback_index_task.py 1 - 101member_index_base.py 1 - 101让我继续深入阅读关键文件来获取更完整的信息。Read file(s)main.py 100 - 301pipeline_runner.py 100 - 351task_executor.py 100 - 351task_registry.py 100 - 301Analyzed codebase_index_task.pybase_dws_task.pydws/__init__.pyindex/__init__.pynewconv_index_task.pyrelation_index_task.pyml_manual_import_task.pybase_task.pyRead file(s)relation_index_task.py 75 - 141newconv_index_task.py 34 - 101Analyzed codecursor_manager.pyrun_tracker.py现在让我查看数据库中的相关配置数据。Called MCP toolexecute_sqlCalled MCP toollist_objectsCalled MCP toollist_schemas让我继续查看剩余的关键文件来补全信息。Read file(s)main.py 300 - 401Analyzed codeapps/etl/pipelines/feiqiu/tasks/dws/index/base_index_task.pyapps/etl/pipelines/feiqiu/tasks/dws/index/base_index_task.pyapps/etl/pipelines/feiqiu/tasks/dws/index/base_index_task.pyscheduler.pyRead file(s)main.py 400 - 501Analyzed codewindowing.py现在我已经收集了所有关键信息，开始生成文档。8 edits to fileetl-feiqiu-architecture.mdError(s) while editingetl-feiqiu-architecture.mdEither the text arg was not provided or text content provided exceeded the write file limit of 50 lines. The agent has seen this error and will try a different approach to write the file if needed.Accepted edits toetl-feiqiu-architecture.mdAccepted edits toetl-feiqiu-architecture.mdAccepted edits toetl-feiqiu-architecture.mdAccepted edits toetl-feiqiu-architecture.mdAccepted edits toetl-feiqiu-architecture.mdAccepted edits toetl-feiqiu-architecture.mdAccepted edits toetl-feiqiu-architecture.md让我继续完成文档的剩余部分。2 edits to fileetl-feiqiu-architecture.md文档已生成完毕，写入 etl-feiqiu-architecture.md。内容覆盖了两个主题：DWD → DWS/INDEX 的完整数据流，包括类继承体系、15 个 DWS 任务和 4 个 INDEX 任务的详细配置参数（WBI/NCI/RS/OS/MS/ML 的默认参数表、归一化流程、参数加载机制等）任务调度系统的完整架构：两种执行模式（传统/Flow）、7 种 Pipeline 定义、3 种处理模式、3 种数据源模式、TaskExecutor 单任务生命周期、游标管理、运行记录，以及 CLI 全部参数说明和使用示例本次仅新增文档，未修改任何代码文件，不触发审计。Run Command HookAudit Reminder (Agent Stop, 15min)Credits used: 14.39Elapsed time: 9m 25sCheckpointRestore我看完了文档。我希望整个DWD - DWS/INDEX 能优化或精简，这方面你有建议么？另外一个问题，Flow 模式 我也希望能做优化或精简，详细介绍Flow 模式的流程和参数。KiroRun Command HookAudit Flagger (Prompt Submit)Run Command HookPrompt Audit Log (Shell)好的，让我先更深入地阅读当前代码中的一些关键细节，特别是 DWS 任务之间的重复模式和 Flow 模式的完整流程，然后给你分析建议。Analyzed codeassistant_monthly_task.pyfinance_daily_task.pymember_consumption_task.pymember_visit_task.pymv_refresh_task.pyretention_cleanup_task.pyassistant_salary_task.pyassistant_finance_task.pyfinance_recharge_task.pyfinance_income_task.pyfinance_discount_task.pyassistant_customer_task.py现在让我查看 verification 模块和 DwdLoadTask 来完整理解 Flow 模式的校验流程。Analyzed codedwd_load_task.pySearched workspace查看 verification 模块的结构好了，我已经对整个代码库有了足够深入的理解。下面给你分析和建议。两个大方向的分析如下：一、DWD → DWS/INDEX 优化建议看完所有 15 个 DWS 任务和 4 个 INDEX 任务的代码后，我发现几个明显的重复模式和可精简的点：1. DWS 任务的 E/T/L 样板代码高度重复几乎每个 DWS 任务的 extract / load 都在做同样的事：# extract 里每个任务都在重复这段start_date = context.window_start.date() if hasattr(...) else ...end_date = context.window_end.date() if hasattr(...) else ...site_id = context.store_id# load 里每个任务都在重复这段deleted = self.delete_existing_data(context, date_col="stat_date")inserted = self.bulk_insert(transformed)return {"counts": {"fetched": ..., "inserted": ..., ...}}建议：在 BaseDwsTask 中提供默认的 extract() 和 load() 实现，子类只需声明 DATE_COL 和实现 _do_extract() / transform() 即可。这样每个子类能减少 20–30 行样板代码。2. 重复的辅助方法散落在多个任务中_mask_mobile() 在 MemberVisitTask、MemberConsumptionTask、AssistantCustomerTask 中各有一份完全相同的实现。_calc_days_since() 也是。_parse_id_list() 在 FinanceDailyTask 和 FinanceDiscountDetailTask 中重复。建议：把这些提升到 BaseDwsTask 或独立的 dws_helpers.py中。3. 财务任务之间有大量 SQL 重叠FinanceDailyTask、FinanceDiscountDetailTask、FinanceIncomeStructureTask 三个任务都在从 dwd_settlement_head / dwd_settlement_detail 提取数据，SQL 查询有大量重叠（团购、赠送卡、大客户优惠等）。_extract_groupbuy_payments、_extract_big_customer_discounts、_extract_gift_card_consumes 在 discount 和 daily 任务中几乎一样。建议：抽取一个 FinanceExtractMixin 或 FinanceBaseTask，共享这些提取方法。三个财务任务继承它，只实现各自的聚合逻辑。4. 物化视图刷新和数据清理可以合并DwsRetentionCleanupTask 和 BaseMvRefreshTask 都在处理时间分层（TimeLayer），配置解析逻辑（_resolve_table_layers、_parse_list、_get_retention_layer）几乎完全重复。建议：合并为一个 DwsMaintenanceTask，在一次执行中完成"清理过期数据 + 刷新物化视图"，减少 2 个任务注册和重复的配置解析代码。5. INDEX 层的 WBI/NCI 共享逻辑可以进一步提升MemberIndexBaseTask 已经做了不错的抽象，但 WBI 和 NCI 的 execute() 方法仍然有大量相似结构（获取 site_id → 加载参数 → 构建活动数据 → 计算 → 归一化 → 保存）。建议：在 MemberIndexBaseTask 中提供一个模板方法 execute()，子类只需实现 _calculate_scores(activity_map, params) 和 _save_results(results) 即可。6. 任务数量本身可以精简当前 DWS 层有 15 个任务。考虑：DWS_ASSISTANT_FINANCE 依赖 DWS_ASSISTANT_SALARY 的输出，但没有显式依赖声明，执行顺序靠注册顺序保证——这很脆弱DWS_MV_REFRESH_* 两个任务可以合并为一个参数化任务DWS_RETENTION_CLEANUP 可以作为 Flow 的后置步骤而非独立任务二、Flow 模式优化建议当前 Flow 模式完整流程CLI --pipeline <name> --processing-mode <mode>│▼PipelineRunner.run()│├── 1. 验证 pipeline 名称合法性├── 2. 生成 run_uuid，创建 TaskLogger├── 3. 设置默认时间窗口（未指定时：now - 24h ~ now）│├── 4. 根据 processing_mode 分支：│ ││ ├── verify_only:│ │ ├── [可选] fetch_before_verify → 先执行 ODS 任务获取 API 数据│ │ └── _run_verification(layers, window, ...)│ │ ├── 对每个 layer 获取 verifier│ │ ├── filter_verify_tables() 过滤表│ │ └── verifier.verify_and_backfill(auto_backfill=True)│ ││ ├── increment_only:│ │ ├── _resolve_tasks(layers) → 层→任务代码列表│ │ └── TaskExecutor.run_tasks(task_codes, data_source)│ ││ └── increment_verify:│ ├── _resolve_tasks(layers) → 层→任务代码列表│ ├── TaskExecutor.run_tasks(task_codes, data_source)│ └── _run_verification(layers, window, ...)│├── 5. 汇总计数（fetched/inserted/updated/errors）└── 6. 返回结果 {status, pipeline, layers, results, verification_summary}Flow 模式的问题和优化建议问题 1：7 种 Pipeline 定义有冗余PIPELINE_LAYERS = {"api_ods": ["ODS"],"api_ods_dwd": ["ODS", "DWD"],"api_full": ["ODS", "DWD", "DWS", "INDEX"],"ods_dwd": ["DWD"], # 和 api_ods_dwd 只差一个 ODS"dwd_dws": ["DWS"],"dwd_dws_index": ["DWS", "INDEX"],"dwd_index": ["INDEX"],}api_ods 和 ods_dwd 的命名暗示了数据流方向，但实际上 ods_dwd 只包含 ["DWD"]——它不执行 ODS 层。这个命名容易误导。建议：简化为 --layers ODS,DWD,DWS,INDEX 的自由组合方式，用户直接指定要执行的层，不需要记忆 7 个 pipeline 名称。保留 api_full 等作为快捷别名即可。# 新方案--layers ODS,DWD # 等价于原 api_ods_dwd--layers DWS,INDEX # 等价于原 dwd_dws_index--layers INDEX # 等价于原 dwd_index--pipeline api_full # 快捷别名，等价于 --layers ODS,DWD,DWS,INDEX问题 2：_resolve_tasks() 的回退逻辑分散每个层的任务解析都有三级回退：配置 → 注册表 → 硬编码。硬编码回退列表容易过时。建议：去掉硬编码回退，统一走 TaskRegistry.get_tasks_by_layer()。注册表就是唯一的真相来源。问题 3：缺少任务依赖声明当前任务执行顺序完全靠注册顺序和层的先后。但 DWS 层内部有隐式依赖（如 DWS_ASSISTANT_FINANCE 依赖 DWS_ASSISTANT_SALARY），没有显式声明。建议：在 TaskMeta 中增加 depends_on: list[str] 字段，_resolve_tasks() 做拓扑排序。问题 4：校验和增量是两套独立的执行路径increment_verify 模式下，增量和校验是串行的两个独立阶段，校验阶段会重新扫描刚写入的数据。对于 DWS/INDEX 层，校验的意义不大（它们本身就是幂等的 delete-before-insert）。建议：校验主要对 ODS/DWD 层有价值（检查 API 数据完整性）。DWS/INDEX 层可以跳过校验，或者只做轻量级的行数校验。问题 5：data_source 对 DWS/INDEX 任务无意义data_source（online/offline/hybrid）只对 ODS 任务有意义（决定从 API 抓取还是从本地 JSON 回放）。DWS/INDEX 任务直接从 DWD 层读取数据库，不涉及 API 或 JSON。但当前代码仍然把 data_source 传给所有任务。建议：在 TaskExecutor.run_single_task() 中，对 DWS/INDEX 层任务跳过 fetch/ingest 分支，直接走 task.execute(cursor_data)。目前代码里 DWS/INDEX 任务的 requires_db_config=False 导致它们走 _run_utility_task() 路径——这其实是个 workaround，不是正确的语义。建议的精简方案总结改动 影响范围 收益BaseDwsTask 提供默认 E/T/L 模板 所有 DWS 任务 每个任务减少 20–30 行提取公共辅助方法 3–4 个任务 消除重复代码财务任务共享提取层 3 个财务任务 消除 SQL 重复合并 MV 刷新 + 数据清理 3 个任务 → 1 个 减少 2 个任务注册MemberIndexBaseTask 模板方法 WBI/NCI 减少 execute() 重复--layers 替代 7 种 pipeline CLI + PipelineRunner 更灵活，减少记忆负担TaskMeta 增加 depends_on 注册表 + 解析器 显式依赖，安全排序DWS/INDEX 跳过校验 PipelineRunner 减少无意义的校验开销你想先从哪个方向开始？我建议优先级是：BaseDwsTask 模板方法（收益最大，风险最低）--layers 替代 pipeline 名称（用户体验提升明显）任务依赖声明（解决隐式依赖的安全隐患）Run Command HookAudit Reminder (Agent Stop, 15min)Credits used: 3.79Elapsed time: 1m 48sCheckpointRestore另外，改几个关键词：- ETL的FLOW模式：所有 pipeline 及相关 关键字改为flow及相关词。- ETL的连接器：apps\etl\pipelines 这个路径的 pipelines 应改为连接器。虽然我知道工程量巨大，而且有风险，但为了减少混淆，也必须修改，做好细致的依赖和相关性的排查以及回归测试。做好数据回测，避免数据处理上的数据错误和偏移。做好文档落地，遍历所有相关文档，逐个更新。1-2-3 及附加需求的顺序执行，以及文档等收尾工作，建立SPEC任务，系统执行。