ADF不支持原生XML数据集，因其设计聚焦高吞吐结构化格式，而XML的嵌套、命名空间等特性难以统一建模；必须用Binary数据集间接处理，并在外接计算资源中解析。

XML 数据集在 Azure Data Factory（ADF）中不能直接作为源或目标使用——ADF 原生不支持 XML 格式的数据集类型，所有 XML 文件必须通过通用格式（如 Binary 或 DelimitedText）间接处理，再配合自定义逻辑解析。

为什么 ADF 没有原生 XML 数据集

ADF 的数据集设计聚焦于高吞吐、可并行的结构化/半结构化格式（如 Parquet、Json、Avro），而 XML 的嵌套深度、命名空间、混合内容、DTD/XSD 依赖等特性难以统一建模为 schema-on-read 流水线。官方明确将 XML 归类为「需自定义处理」场景，不提供 Xml 类型数据集选项。

用 Binary 数据集读取 XML 文件的实操要点

这是最常用且稳定的方式：把 XML 当作二进制流拉取，在后续活动（如 Databricks、Azure Function 或自定义 .NET 活动）中解析。

• Linked Service 使用 AzureBlobStorage 或 AzureData

  

  LakeStorage，确保有读权限
• 数据集类型选 Binary，不是 Json 或 Xml（后者会报错“Unsupported dataset type”）
• 在 Binary 数据集配置中，fileName 可用通配符（如 *.xml），但 folderPath 必须明确，不支持递归扫描（除非用 @pipeline().parameters 动态拼接）
• 若 XML 文件较大（>100 MB），避免在 Lookup 活动中直接读取——会触发内存溢出；改用 Copy Activity 输出到临时 Blob，再交由下游解析

用 DelimitedText 数据集“伪装”简单 XML 的风险

仅当 XML 极其扁平（无嵌套、无属性、单根节点、每行一个标签）时，有人尝试设 columnDelimiter 为 或 >，但这属于 hack 行为，极易断裂：

• 任意含 的文本内容（如注释 ）会导致列错位
• XML 命名空间（xmlns:ns="..."）和属性（）完全无法识别
• ADF 不校验 XML 合法性，解析失败会静默丢弃整行，而非报错
• 不推荐用于生产，调试成本远高于直接用 Binary + 显式解析

真正解析 XML 的推荐路径

ADF 本身不解析 XML，必须外接计算资源。常见组合：

• Databricks Notebook（Python/Scala）：用 spark.read.format("xml")（需 databricks-spark-xml 包），支持 schema inference 和 namespace 处理
• Azure Function（C#）：接收 Binary 数据集输出的 blob URL，用 XDocument.Load() 或 XmlSerializer 解析后写入 SQL/ADLS
• 自定义 .NET 活动：上传已编译的 EXE，通过 Activity 的 extendedProperties 传入文件路径和解析规则

关键点：所有解析逻辑必须独立于 ADF 数据集定义；Binary 数据集只负责“搬运”，不承担“理解”职责。

最容易被忽略的是命名空间处理——90% 的 XML 解析失败源于未声明 xmlns 前缀绑定，而不是语法错误。无论用 Spark 还是 .NET，都得显式调用 SetPrefix 或 XmlNamespaceManager，ADF 自身对此零抽象。