Microsoft Fabric/Data Factory复制数据时是否压缩？为何复制量小于Hyperscale SQL表？

以下是核心原因：

1. SQL物理存储包含大量非数据冗余开销 #

Hyperscale SQL表显示的3GB物理大小并非纯业务数据量，它包含了SQL引擎的各种存储开销：

• 聚集/非聚集索引的存储空间
• 数据页填充因子预留的空闲空间
• 行版本控制生成的历史数据（若启用快照隔离等特性）
• 数据库页头、元数据等额外结构占用

Fabric Data Factory在复制时仅提取实际业务行数据，不会携带这些SQL层的存储冗余，因此读取后的原始数据量本身就远小于SQL表的物理大小。

2. Data Factory传输阶段默认启用压缩 #

Fabric Data Factory在源读取与目标写入之间的传输环节，默认启用了传输层压缩（如Gzip或Deflate）：

• 你看到的2.1GB是传输过程中压缩后的数据量，这个压缩发生在Parquet接收器的Snappy压缩之前
• 传输压缩与Parquet文件的Snappy压缩是独立的两个环节，两者叠加最终得到1.6GB的Parquet文件

3. 数据类型的高效转换与编码优化 #

SQL中的部分数据类型被Fabric读取后，会被转换为更紧凑的内存表示与传输编码：

• 固定长度的char/nchar会转为可变长度的高效编码，消除空字符冗余
• 日期时间、数值类型会采用更节省空间的二进制编码格式
• 空值会使用稀疏编码方式，避免无效存储

这些优化会在Parquet写入前进一步降低数据体积。

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