Azure Data Explorer 存储成本估算计算

我是 ADX 新手，目前正在研究将 parquet 从 Blob 存储摄取到 ADX 进行进一步处理的可能性。我目前正在尝试使用此模板得出每月的成本估算。

我很难理解如何使用 ADX 成本估算器计算“估算数据压缩”或 ADX 一般如何压缩数据。

我从不同的非官方来源看到数据压缩的默认设置是7（没有找到关于ADX中数据压缩率估计的官方文档）。

但是，当我将 parquet 文件从 blob 存储上传到 ADX 时（dev 和 prd 都产生相同的结果），我意识到摄取 parquet 文件的表的大小实际上与原始文件相比有所增加而不是被压缩。

Blob 存储（27MB parquet 文件）：

根据默认的数据压缩比，我对摄取后表大小的预期约为3-4 MB。

ADX（开发）（引擎：Dev（无 SLA）_Standard_D11_v2，1 个实例）& ADX (prd)（引擎：Standard_L16as_v3，2 个实例）：

但是，表的大小实际上是 74MB （TotalExtentSize：74MB，TotalOriginalSize：874MB），这是原始 parquet 文件大小的 3 倍。

预估数据压缩是指TotalOriginalSize/ TotalExtentSize吗？

原始 parquet 文件只有 27MB，TotalOriginalSize 874MB 是怎么回事？

我想知道如何为特定的 parquet 文件提供正确的估计数据压缩，以及是否有任何方法可以在数据摄取期间进一步压缩表的大小？

0
投票

原始大小是概念上未压缩的 CSV 数据的标准化大小，在数据被摄取后计算。这样做是为了提供跨所有数据格式和压缩策略的可比较的数字。因此，如果您将 Parquet 转换为未压缩的 CSV，大小将更接近 Kusto 提供的 OriginalSize 数字。

您是对的，压缩率通常计算为原始大小与范围大小之间的比率，但是只要成本计算器中原始大小除以压缩率的结果返回范围大小，那么计算结果就是正确，因为成本的主要方面是根据范围大小计算的。也就是说，建议使用 Kusto 提供的原始大小，以便与其他管道、数据格式和压缩进行比较。

至于为什么在这种情况下 Parquet 压缩比 Kusto 更好，很可能是因为 Kusto 中广泛的字符串和动态索引使其能够提供比直接查询 Parquet 更优越的性能。

顺便说一句，可以在这里找到更方便的成本估算器：http://aka.ms/adx.costestimator