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或AzureDataLakeStorage，确保有读权限 - 数据集类型选
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 自身对此零抽象。
