使用Azure Synapse导入Blob CSV至表存储无法选接收器咨询

• 组件支持范围限制：你当前使用的Synapse映射数据流组件，原生接收器清单里没有纳入Azure Table Storage，只有低代码复制活动在匹配支持矩阵时才会展示该选项，做字段转换的映射数据流链路本身不支持直连Table Storage做写入。
• 前置校验拦截：就算切换到支持Table Storage的复制活动，如果Synapse工作区托管标识没有配置目标存储账户的Table写入权限、或者目标账户关闭了共享密钥/受信任服务访问，系统会自动过滤该选项，不会出现在可选接收器列表里。
• 资源路径选择错误：Azure Table Storage是独立于ADLS Gen2文件系统的表存储服务，不属于ADLS容器下的文件类资源，如果你配置目标时进入了ADLS文件系统的路径选择页，根本无法识别到Table服务端点，自然找不到对应选项。

没有强制要求，但针对你700GB大CSV的场景，强烈建议加Parquet中转层，性价比远高于直写：

• 直写Table Storage本身有严格的性能上限：单分区写入阈值为1000实体/秒，单批写入最多支持100个实体，700GB的CSV直接做流式转换写入，极容易触发限流、超时、事务重试，甚至全量任务失败。中间落Parquet时可以提前按Table的分区键做数据分片、裁剪无效列，把写入批次拆到匹配Table吞吐量限制的粒度，写入稳定性会提升一个量级。
• 大CSV直接做转换的开销极高：CSV是无schema、无内置压缩的纯文本格式，700GB文件全量解析、字段转换的内存和IO开销，比读取同体量Parquet高3~5倍，很容易因为Synapse集成运行时资源不足触发任务失败。Parquet本身带schema自描述、内置压缩，落盘后不仅转换环节速度快，后续排错、补数也不需要重新扫全量源CSV。
• 不加中间层的替代方案存在明显缺陷：你可以绕开映射数据流，直接用复制活动手动配置源CSV的schema、目标Table的分区键/行键映射做直写，但这种方案对700GB体量的文件来说，单次运行时长通常在10小时以上，任务中断后无法从断点续传，失败重跑的成本极高。

操作界面截图

内容的提问来源于stack exchange，提问作者Ahmad M.