寻找任何使用 Microsoft Fabric 的数据工程师。我看到从超大规模 SQL 到 Fabric Data Lake 的数据大小被大量压缩。
我知道，为什么要质疑一件好事？
在将 SQL 转换为 Parquet 时，我通常期望正常的快速压缩，但是当 Fabric 在 Parquet Sink 之前从 SQL 读取/摄取数据时，我看到了压缩。这是因为数据工厂使用的压缩编解码器吗？ （Gzip、Deflate、BZIP2）？
从超大规模复制 SQL 表时，这些是我得到的大小类型
为什么 Fabric（数据工厂）复制的大小比 SQL 表小？
希望对这里发生的事情有一个基本的了解。 感谢团队。
通过 Azure 数据工厂将数据从超大规模 SQL 复制到 Fabric Data Lake 时数据大小的减小可能归因于多种因素，包括使用的压缩技术、数据移动过程中的优化以及目标存储的性质（Data Lake）在这种情况下存储）。
以下是观察到的数据大小减少的一些可能的解释。
1）Parquet柱式存储 Parquet 是一种列式存储格式，以其高压缩比和高效存储而闻名。当数据写入Parquet文件时，它是按列组织的，这种列式存储格式自然压缩得很好。它减少了存储空间并增强了查询性能，因为只需要读取与查询相关的列。
2）数据移动优化。 Azure 数据工厂可能在数据移动过程中采用优化技术。这可能包括过滤掉不必要的列、应用谓词下推（如果可能）以及其他优化以减少传输的数据量。
3）数据类型和编码的差异。 与 SQL 表相比，目标 Parquet 文件可以使用更有效的数据类型编码。 Parquet 允许针对不同数据类型提供更紧凑、更高效的编码方案。
4) 压缩编解码器。 Parquet 文件的压缩编解码器的选择也可能发挥作用。不同的编解码器（例如 Snappy、Gzip、Deflate）具有不同的压缩比和性能特征。 SQL Server 和 Parquet 之间的默认压缩编解码器可能不同。
5）元数据开销。 与源 SQL 表相比，Parquet 文件的元数据开销可能更少，从而可以更有效地利用存储。
值得注意的是，实际数据大小的减少可能取决于数据的具体特征、架构设计以及 Azure 数据工厂中应用的设置。
有关更多详细信息，您可以参考 Azure 数据工厂的文档，以及数据复制操作期间与压缩相关的任何相关设置或配置。此外，您可以联系 Azure 社区或 Microsoft 支持人员，了解有关数据移动期间应用的优化的更多具体详细信息。