Azure Data Factory无法读取YouTube Reporting API JSON架构的解决方法咨询

• YouTube Analytics API返回的JSON存在两个和ADF原生解析逻辑不兼容的结构：
  • 表头信息独立存放在columnHeaders数组中，每个字段的实际名称在columnHeaders.name属性里
  • 数据行在rows字段中是无键名的二维数组，每个值的位置和上方表头的顺序一一对应，没有自带的键标识
• ADF原生仅支持带键名的对象数组格式的JSON解析，面对无键的嵌套二维数组无法自动探测架构，直接复制必然失败。

方案1：Mapping Data Flow 内置转换链路（无代码、全自动化） #

这是完全依托ADF内置能力实现的无代码方案，多数人之前用Data Flow处理这类结构效果差，核心原因是源端配置没有选对JSON文档模式，导致根本读不到嵌套的rows字段。正确配置流程如下：

1. 源端配置
   • 关联Blob存储中的原始YouTube返回JSON文件，JSON格式配置选择「单个文档」（不要选择数组文档模式，否则无法读取到根级的两个独立数组字段）
   • 手动定义源端的架构，不依赖自动探测：
     • 根级字段kind定义为字符串类型
     • 根级字段columnHeaders定义为数组类型，数组内元素包含name、dataType两个字符串字段
     • 根级字段rows定义为二维数组类型，无需提前定义嵌套元素结构
2. 全局聚合提取基础元数据
   • 添加聚合转换，不设置任何分组列，做全表级别的全局聚合，输出两个字段：
     • 列名列表：通过表达式collect(columnHeaders.name)，把所有表头的字段名收集成一维字符串数组，比如["views", "likes", "comments"]
     • 原始行矩阵：通过表达式collect(rows)，把所有数据行的二维值数组完整收集为统一矩阵
3. 扁平化拆分行记录
   • 添加Flatten（扁平化）转换，选择展开列是之前提取的原始行矩阵，把二维数组中的每一行值拆分为单独的记录，此时每条记录对应一个长度和列名列表一致的一维值数组
4. 动态匹配键值生成标准对象
   • 添加派生列转换，开启动态列映射开关，使用内置的mapArray函数完成键值绑定，无需编写自定义脚本：
     • 核心逻辑是通过zip(列名列表, 当前行的一维值数组)把列名和对应位置的值一一配对，再将配对结果转换为键值对结构，最终生成ADF可识别的带键对象数组
5. 目标端写入
   • 关联Azure SQL数据库作为目标，将动态生成的字段映射到SQL表的对应列即可。注意提前保持SQL表的字段顺序和API请求的metrics顺序一致，YouTube API返回的列顺序是严格和请求参数对齐的，不会出现随机错位。

方案2：轻量前置格式转换（低配置成本） #

如果觉得Data Flow配置链路复杂，可以在API返回结果存入Blob后、进入ADF流程前，增加一个轻量的Azure Function步骤做格式预处理：

• 转换逻辑代码量极少，仅需3步核心处理：
  1. 读取Blob中的原始JSON，解析提取columnHeaders中的所有字段名，组成列名数组
  2. 遍历rows中的每一行值，按照数组索引和列名一一配对，把原来的无键数组转换为带键的对象（比如把[1200, 35, 2]转换为{"views":1200, "likes":35, "comments":2}）
  3. 把所有转换后的对象组成标准数组，重新写入Blob路径
• 预处理完成后，ADF的复制活动可直接自动识别JSON架构，一键完成到SQL库的同步，无需额外转换步骤。

• 不要尝试直接用ADF复制活动解析原始JSON结构——复制活动的JSON解析仅支持固定架构场景，不具备动态生成键值的能力，面对无键的嵌套二维数组必然识别失败
• 不要依赖自动架构探测，源端配置时手动定义基础结构，避免ADF对嵌套数组的识别逻辑出错
• 列顺序一致性是数据准确性的核心保障，YouTube API的返回列严格按照请求的metrics顺序排列，不存在乱序，映射时无需做额外的顺序校验

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