Azure Data Factory中一次性查询DB配置表驱动重复流水线活动方案问询

完全可以实现该需求，无需手动传递多环境参数，也不需要重复查询数据库，根据你的调度时长要求可以选择以下两种落地方式。

方案1：单流水线全局变量传递（适合单次触发后短期运行的调度流水线） #

• 流水线启动后第一步先运行一次性的查找活动（Lookup Activity），配置连接存储配置的DB表，查询过滤条件直接关联Data Factory预设的全局环境标识（DEV/TEST/PROD，该标识可在不同环境的Data Factory实例中固定配置，无需手动传参）
• 将查找活动返回的多组配置值赋值给流水线的全局变量，变量类型选择对象/数组类型即可兼容多配置项存储
• 后续添加Until循环活动，循环条件设置为永久不满足（或按你的业务停止规则配置），循环内先添加Wait活动设置等待时长为5分钟，再调用你需要执行的Orchestrator任务，任务直接引用前述已赋值的流水线全局变量即可获取配置值
• 注意：Azure Data Factory单条流水线的默认最长运行时长为8天，若需要更长时间的不间断调度，选择第二种方案

方案2：触发器+配置缓存（适合长期不间断的周期调度） #

• 首次运行时先执行一次性的DB查询活动，将拉取到的对应环境配置值存入集成运行时缓存，或存入Blob小文件、Redis等你现有可用的缓存介质，该同步操作仅需在配置更新、Data Factory服务重启时执行一次
• 给Orchestrator任务单独配置5分钟周期的调度触发器，任务运行时直接读取缓存内的配置值即可，无需重复查询DB
• 优势：不受单流水线运行时长限制，配置更新后只需触发一次缓存同步逻辑即可生效，不需要重启调度任务

• 若配置值存在更新需求，方案1需要重新运行流水线拉取最新配置，方案2仅需执行一次缓存同步即可
• 存储配置的DB表建议新增环境字段作为索引，查询时直接按环境过滤，避免拉取到其他环境的错误配置
• 密码、密钥等敏感配置不要明文存储在DB表中，建议存储在密钥管理服务中，DB仅存储对应的密钥引用标识

内容的提问来源于stack exchange，提问作者stonemusic