用途：帮助开发者与数据工程师在 Azure ADLS Gen2 上设计、实施和运维 Snowpipe 的业务连续性与灾难恢复（BCDR）。仅覆盖 Azure ADLS Gen2，AWS S3 / GCS 变体不在范围内。
主要能力：支持六种模式并按 RPO、RTO、成本与复杂度选型——1 手动补偿（单管道）；2 双活加去重（Zero RPO，约 1 分钟 RTO）；3 RA-GRS 读取；4 主备（SF + GRS）；5 仅 Snowflake Failover Group；6 双存储双管道。模式 2–6 需要 Business Critical 版本以使用 Failover Groups，低版本仅适用模式 1。
核心规则：每个文件集只允许一个写入者（模式 2 除外，它通过去重处理）；存储集成的 STORAGE_ALLOWED_LOCATIONS 必须同时放行主、备两个 azure:// URL；COPY_HISTORY 在 Failover Groups 中会复制但只保留 14 天，需更久历史时应维护 FILE_LOAD_HISTORY 备份表；ALTER PIPE ... REFRESH 硬上限为 7 天，更早文件改用 DIRECTORY(@stage) + COPY INTO；入站通知集成（DIRECTION = INBOUND）不会复制，故障转移提升后须在 DR 账户中以同名重建，并重新建立 Service Principal 信任、创建 DR 区域 Event Grid 订阅。
使用方式：先确认前置条件（版本、Azure 存储类型、目标区域的 Event Grid 与 Storage Queue），再实施所选模式，通用步骤为存储集成 → 外部阶段 → 带 AUTO_INGEST=TRUE 与通知集成的管道 → 监控视图 → 补偿流程；模式 2 用 MD5(METADATA$FILENAME) 作 FILE_HASH、MD5(CONCAT_WS(...)) 作 RECORD_HASH，并以 Dynamic Table 按 FILE_HASH、RECORD_HASH 去重；模式 6 先建主备两条 AUTO_INGEST 管道，再将备管道 PIPE_EXECUTION_PAUSED 设为 TRUE。之后通过 SYSTEM$PIPE_STATUS 与 SNOWFLAKE.ACCOUNT_USAGE.COPY_HISTORY 验证待处理文件数、错误率与加载延迟；故障转移时暂停主管道、记录检查点、启用备管道并 REFRESH MODIFIED_AFTER 指定时间点，补偿可选 REFRESH、COPY INTO 或对比 DIRECTORY 与 COPY_HISTORY 的游标过程。
限制与常见错误：两管道同时运行会造成重复加载；集成缺少备 URL 会在故障转移时 ACCESS_DENIED；依赖 14 天以外 COPY_HISTORY 会找不到文件；缺少 DR Event Grid 订阅会出现 pendingFileCount = 0；对旧文件用 REFRESH 会被静默跳过；重建管道未带 AUTO_INGEST=TRUE 会停止自动加载；入站通知集成未重建则管道看似正常但无待处理文件。流程含两处停止点（执行 CREATE/ALTER 前、暂停主管道前）需等待用户确认。资料未提供安装命令。