Azure Databricks向Synapse专用SQL池写入时BufferedReader问题解决方法

问题根源 #

你碰到的HdfsBridge报错、BufferedReader异常以及“必须有12字节”这类提示，本质是Delta/Parquet和Synapse专用SQL池之间的数据类型序列化逻辑不匹配：

• 比如Parquet里的int类型，要是实际存储的数据范围超过了Synapse int的4字节限制（Delta有时候会隐式把数据转成更大范围的整数），就会触发字节长度错误；
• 原生Parquet的datetime存储格式（8字节时间戳）和Synapse默认datetime的精度范围不兼容，读取时就会出现字节校验失败。

用Apache Arrow解决的具体方案 #

不用动Parquet暂存文件，只需要在Synapse的COPY命令里启用Apache Arrow作为解析引擎，就能自动处理跨系统的类型映射，不用手动扩宽Synapse表的字段类型：

1. 修改COPY命令启用Arrow #

在Synapse专用SQL池的COPY语句里加上ENGINE = 'ARROW'参数，同时保留必要的配置：

COPY INTO [你的Schema].[目标表名]
FROM 'abfss://<容器名>@<存储账户名>.dfs.core.windows.net/Delta表导出的Parquet路径/'
WITH (
    FILE_TYPE = 'PARQUET',
    CREDENTIAL = (IDENTITY = 'Managed Identity'), -- 用托管身份或你的存储凭据
    USE_TYPE_DEFAULT = FALSE,
    DATA_SOURCE = '你配置的ADLS Gen2数据源',
    ENGINE = 'ARROW' -- 关键：启用Arrow解析引擎
)

2. Arrow自动处理的类型映射 #

Arrow会帮你搞定这些核心兼容问题：

• Parquet的int32/int64：自动匹配Synapse的int/bigint，不用改表结构；
• Parquet的timestamp[ns]：自动转成Synapse的datetime2(7)，保留原精度，不会触发字节长度错误；
• 小数、字符串这类类型，Arrow会按最小兼容原则映射，没必要的类型扩宽完全可以避免。

3. 额外注意事项 #

• 确保Databricks导出Parquet用的是标准格式：Delta表默认导出的Parquet是符合标准的，但如果有自定义写配置，别乱改timestamp或整数的存储格式；
• 先跑小批量测试：用少量数据验证Arrow引擎是否生效，没问题再扩到全量；
• 对齐列顺序：Synapse表的字段顺序要和Parquet文件的列顺序完全一致，Arrow对列顺序敏感，不匹配可能导致类型解析出错。

为什么Arrow能搞定 #

Apache Arrow提供了跨系统统一的内存数据格式，替换了Synapse原生的HdfsBridge解析逻辑，避开了原生解析器处理Delta衍生Parquet时的字节校验问题，还能自动完成无损的类型映射，既不用改Parquet文件，也不用动Synapse表结构。

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