Data Domain 中涉及的压缩技术使用先进的技术来减少客户数据所需的物理空间。因此，压缩级别的技术和衡量是复杂的主题。本文档讨论了一些术语、取舍和度量，以便更好地解释 Data Domain 系统中使用的压缩类型、术语以及压缩的其他方面。
适用于：
所有 Data Domain 型号
上次更新时间：2024
年 1 月 压缩是一种数据缩减技术，旨在使用更少的物理空间存储数据集。在 Data Domain 系统 （DDOS） 中，我们执行重复数据消除和本地压缩来压缩用户数据。重复数据消除用于识别冗余数据段并仅存储唯一数据段。本地压缩使用某些压缩算法进一步压缩唯一数据段，例如 lz, gzfast, gz，依此类推。DDOS 中的整体用户数据压缩是重复数据消除和本地压缩共同作用的结果。DDOS 使用“压缩比”来衡量其数据压缩的有效性。通常，它是总用户数据大小与压缩数据总大小或已用物理空间大小的比率。
Data Domain 文件系统是一种“日志结构式”重复数据消除文件系统。日志结构文件系统仅将数据附加到系统，而删除本身无法释放物理空间。此类文件系统依赖于垃圾收集来回收不再需要的空间。日志结构文件系统的特征与经过重复数据消除的技术相结合，使得很难清楚地了解 DDOS 中压缩的所有方面。
对于压缩，我们可以衡量许多方面。在本文档中，我们将逐步讨论详细信息，以帮助了解 DDOS 压缩。首先，我们介绍整体系统压缩效果，它告诉我们在 Data Domain 系统中实现的实际压缩、用户数据量、占用的物理空间量以及它们的比率。此比率在本文档中称为“系统有效压缩比”。DDOS 执行内联重复数据消除，并跟踪原始用户数据段、重复数据消除后的唯一数据段的统计信息以及本地压缩对唯一数据段的影响。这些内联压缩统计信息用于衡量内联压缩效果。可针对每次写入测量线内压缩统计信息。此外，DDOS 还会跟踪不同级别的统计信息;文件、MTree 和整个系统。
在本文档发布之前，本文档的内容可应用于所有 DDOS 版本，直至 DDOS 7.13。无法保证所有内容在未来版本中都准确无误。在 5.0 之前的版本中，整个系统只有一个 mtree，并且没有明确使用术语 mtree。
系统范围的整体压缩效果通过系统有效压缩比来衡量，即用户数据大小与已用物理空间大小的比率。fileys show compression （FSC） CLI 命令会报告此问题（UI 上也提供了相应的信息）。 FSC 的输出示例如下所示：
# filesys show compression
From: 2023-12-31 03:00 To: 2024-01-07 03:00
Active Tier:
Pre-Comp Post-Comp Global-Comp Local-Comp Total-Comp
(GiB) (GiB) Factor Factor Factor
(Reduction %)
---------------- -------- --------- ----------- ---------- -------------
Currently Used:* 6439.6 113.4 - - 56.8x (98.2)
Written:
Last 7 days 135421.3 1782.0 35.1x 2.2x 76.0x (98.7)
Last 24 hrs 532.5 1.5 334.3x 1.1x 356.5x (99.7)
---------------- -------- --------- ----------- ---------- -------------
* Does not include the effects of pre-comp file deletes/truncates
since the last cleaning on 2024/01/05 11:34:13.
系统有效压缩比在 CLI 输出的结果部分的第 1 行报告。该行在上面突出显示。用户数据总大小标记为“Pre-Comp”。使用的总物理空间（包括数据和元数据）标记为“Post-Comp”。
“Pre-Comp”编号和“Post-Comp”编号均在运行时读取。FSC 隐式同步整个系统，然后查询这两个数字。这两个数字的测量方法与“filesys show space”命令相同。
系统有效压缩比 = 压缩前/压缩后
FSC 输出的其余部分描述了线内压缩统计信息，我们将在后面讨论它们。
有一些操作可能会影响系统有效压缩比：
快速拷贝
当快速复制是从活动命名空间中的文件（而不是快照）完成的，这是一种完美的重复数据消除，因为目标文件不需要额外的物理空间。快速复制的效果是，我们在不占用额外物理空间的情况下增加了用户数据大小。这将提高系统有效压缩比。完成许多快速拷贝后，系统有效压缩比可能会人为变高。
虚拟合成
虚拟合成备份往往显示较高的系统有效压缩比。这是因为虚拟合成备份会进行逻辑完整备份，但仅将更改的数据或新数据传输到 Data Domain 系统。虚拟合成对系统有效压缩比的影响与快速复制的影响类似。
覆盖
覆盖会占用更多物理空间，但不会增加数据集的逻辑大小，因此覆盖会降低系统有效压缩比。
存储稀疏文件
稀疏文件包含大型“孔”，这些“孔”计入逻辑大小，但由于压缩而不占用物理空间。因此，它们可以使系统有效压缩比看起来很高。
存储小文件
对于某些内部元数据，DDOS 会为每个文件增加近 1 KB 的开销。当系统存储大量小文件（大小小于 1 KB 或大小为个位数 KB）时，元数据的开销会降低有效压缩比。
存储预压缩或预加密文件
压缩和加密可以放大数据更改级别并降低重复数据消除的可能性。此类文件通常不能很好地进行重复数据消除，从而降低系统有效压缩比。
删除
删除会减少系统的逻辑大小，但在垃圾收集运行之前，系统不会获得相应的未使用空间。许多已删除的文件使压缩比变低，直到垃圾数据收集 （GC） 运行。
垃圾收集 （GC） 或清理
GC 会回收不再被任何文件看到的数据段占用的空间。如果最近删除了许多文件，GC 可能会通过减少物理空间占用来提高系统压缩比。
积极拍摄快照
拍摄 Mtree 的快照时，不会更改数据集的逻辑大小。但是，快照引用的所有数据段都必须锁定，即使快照捕获的所有文件在快照创建后被删除也是如此。GC 无法回收快照仍需要的空间;因此，拥有大量快照可能会使系统有效压缩比显得较低。但是，快照是有用的崩溃恢复工具。在需要时，我们应毫不犹豫地创建快照或设置适当的快照计划。
当数据写入系统时，DDOS 会内联执行重复数据消除。它会跟踪线内重复数据消除和本地压缩对每次写入的影响，并在文件级别累积统计信息。在 mtree 级别和系统级别进一步汇总每个文件的内联压缩统计信息。压缩的衡量基于内联统计信息中的三个数字：
根据上述三个数字，DDOS 定义了两个更细粒度的压缩比：
累积的内联压缩统计信息是 DDOS 中文件元数据的一部分，存储在文件信息节点中。DDOS 提供了在所有三个级别检查线内压缩的工具;文件、MTree 和系统范围。我们将在以下各节中详细介绍它们。
3.1 文件压缩
可以使用“filesys show compression <path”CLI 命令检查文件压缩情况>，该命令报告存储在文件索引节点中的累积压缩统计信息。指定目录后，将汇总并报告该目录下所有文件的内联压缩统计信息。在 CLI 输出中，raw_bytes标记为“Original Bytes”;pre_lc_size标记为“全局压缩”;post_lc_bytes标记为“本地压缩”;其他开销报告为“元数据”。这两个示例是从实际 DD 中捕获的：
示例 1：文件的内联压缩统计信息
# filesys show compression /data/col1/main/dir1/file_1
Total files: 1; bytes/storage_used: 7.1
Logical Bytes: 53,687,091,200
Original Bytes: 11,463,643,380
Globally Compressed: 4,373,117,751
Locally Compressed: 1,604,726,416
Meta-data: 18,118,232
示例 2：目录下所有文件（包括所有子目录）的内联压缩统计信息
# filesys show compression /data/col1/main/dir1
Total files: 13; bytes/storage_used: 7.1
Logical Bytes: 53,693,219,809
Original Bytes: 11,501,978,884
Globally Compressed: 4,387,212,404
Locally Compressed: 1,608,444,046
Meta-data: 18,241,880
系统在上述 CLI 输出中将整体线内压缩比报告为“字节/storage_used”。 但是，在解释上述信息时必须小心谨慎，由于各种原因，这些信息可能会有误导性。原因之一是，pre_lc_size 和 post_lc_size 是在处理数据操作时记录的。删除最初添加这些数据段的文件后，应增加剩余文件中唯一数据段的数量。
例如，假设将文件 sample.file 备份到 Data Domain，并且在第一次备份中，文件的压缩信息为 pre_lc_size=10GiB，post_lc_size=5GiB。
接下来，假设此文件的数据是唯一的，不与任何其他文件共享数据。在文件的第二个备份中，进一步假设文件获得理想的重复数据消除，使得pre_lc_size和post_lc_size都应为零，因为文件的所有段都已存在于系统上。删除第一个备份后，该文件的第二个备份将成为引用 5 GiB 数据段的唯一文件。在这种情况下，理想情况下，第二次备份中的文件的 pre_lc_size 和 post_lc_size 应分别从零更新为 10 GiB 和 5 GiB。但是，无法检测应该为哪些文件执行操作，因此现有文件的内联压缩统计信息保持不变。
影响上述数字的另一个因素是累积统计数据。当文件被大量覆盖时，无法跟踪累积统计信息反映引入实时数据的写入的程度。因此，在很长一段时间内，内联压缩统计信息只能被视为一种启发式方法，以粗略估计特定文件的
压缩。另一个值得强调的事实是，无法按任意时间间隔测量文件的内联压缩。文件内联压缩统计信息是累积结果，涵盖文件收到的所有写入。当文件收到大量覆盖时，raw_bytes可能远远大于文件的逻辑大小。对于稀疏文件，文件大小可能大于“原始字节数”。
3.2 MTree 压缩
我们可以使用 "mtree show compression" （海安会）CLI 命令。内联压缩统计信息的绝对值在 MTree 的生命周期内是累积的。鉴于 MTree 的生存期可能长达数年，随着时间的推移，这些值提供的信息会越来越少。为了解决此问题，我们使用内联压缩统计信息的更改量（增量），并仅报告特定时间间隔的压缩。底层方法是定期将 MTree 内联压缩统计信息转储到日志中。当客户端使用 MSC 命令查询 MTree 压缩时，我们使用日志来计算压缩报告的数字增量。默认情况下，MSC 报告过去 7 天和过去 24 小时的压缩，但可以指定任何感兴趣的时间段。
为了进行演示，假设 MTree A 的日志如下：
3:00AM, raw_bytes=11000GB, pre_lc_size=100GB, post_lc_size=50GB 4:00AM, raw_bytes=12000GB, pre_lc_size=200GB, post_lc_size=100GB
则此小时的 MTree A 压缩为：
g_comp = (12000-11000)/(200-100) = 10x l_comp = (200-100)/(100-50) = 2x overall compression ratio = (12000-11000)/(100-50) = 20x
上述压缩比计算不会对数据集大小执行任何操作。例如，上述 mtree 可能只有 500 GB 逻辑数据。
MSC 支持“daily”和“daily-detailed”选项，就像“filesys show compression”命令一样。指定“daily”时，该命令会以日历方式报告每日压缩。它使用 raw_bytes 和 post_lc_size 的每日增量来计算每日压缩比。指定“daily-detailed”时，该命令显示每天的所有三个增量（分别为raw_bytes、pre_lc_size和post_lc_size）;它还计算g_comp和l_comp以及总压缩系数。
这些系统的输出示例位于 附录中。
3.3 系统压缩
了解了如何在 MTree 上报告压缩后，就可以直接将这个概念扩展到整个系统了。系统范围的压缩内联统计信息收集和报告与 MTree 完全相同。唯一的区别是范围，一个在特定的 MTree 中，而一个在整个系统上。可以使用“filesys show compression”命令检查结果。可以在第 2 节中找到这方面的示例。FSC 输出中结果部分的最后两行中报告“过去 7 天”和“过去 24 小时”的系统压缩。
在实施了云层的 DD 上，存储分为活动层和云层，这是两个独立的重复数据消除域。用户只能将数据注入活动层。稍后，可以使用 DDOS 数据移动功能将数据从活动层迁移到云层。因此，空间和压缩测量和报告在每一层中都是独立处理的。但在文件级别，我们不会按层区分并报告内联压缩统计信息;它们与我们在第 3.1 节中描述的完全相同。
要重点介绍的最后一个主题是重复数据消除的一些特征，重复数据消除在许多 Data Domain 文档中称为“全局压缩”。虽然它包含“压缩”一词，但它与传统的压缩概念完全不同，传统的压缩概念也由 DDOS 以“本地压缩”的名称提供。
本地压缩使用特定算法减小数据片段的大小（某些类型的数据不可压缩，对它们应用压缩算法可能会略微增加数据大小）。通常，一旦确定了算法，数据本身是压缩比的唯一因素。
但是，重复数据消除则不同 — 它不是本地概念，而是全局概念。传入数据段会针对已消除重复数据的域中的所有现有数据段（包括非云 Data Domain 系统上的所有数据）进行重复数据消除。数据段本身在重复数据消除过程中无关紧要。
在实践中，我们很少在数据集的初始备份中看到高重复数据消除率。在初始备份中，主要的数据缩减通常来自本地压缩。当后续备份进入 Data Domain 时，重复数据消除将显示出其优势，并成为压缩的主导因素。重复数据消除的有效性取决于这样一个事实：数据集在备份之间的更改率很低。因此，更改率高的数据集无法很好地进行重复数据消除。当备份应用程序以高频率将自己的元数据块（Data Domain 称为标记）插入备份映像时，也可能无法获得良好的重复数据消除率。我们的标记处理技术有时会有所帮助，但并非总是如此。
鉴于这些观察结果，我们能期待什么？
在经过重复数据消除的文件系统中，衡量压缩是很困难的，但在日志结构的重复数据消除文件系统中则更难。我们必须了解重复数据消除的工作原理以及如何跟踪压缩统计信息。压缩比是了解特定系统行为的有用信息。系统有效压缩比是最重要、最可靠且信息量最大的度量。内联压缩统计信息也可能很有帮助，但在某些情况下，它们可能只不过是启发式方法。
附件：以下项的输出示例： "mtree show compression" 命令
：假设有一个 MTree 保存 254792.4 GiB 的数据。它在过去 7 天内收到了 4379.3 GiB 的新数据，在过去 24 小时内收到了 78.4 GiB（可以指定其他时间间隔）。“daily”选项报告过去 33 天的内联压缩统计信息。当提供“daily-detailed”选项时，将总压缩比分为全局压缩比和本地压缩比，从而进一步详细说明。
Mtree 列表输出：
# mtree list /data/col1/main Name Pre-Comp (GiB) Status --------------- -------------- ------ /data/col1/main 254792.4 RW --------------- -------------- ------ D : Deleted Q : Quota Defined RO : Read Only RW : Read Write RD : Replication Destination IRH : Retention-Lock Indefinite Retention Hold Enabled ARL : Automatic-Retention-Lock Enabled RLGE : Retention-Lock Governance Enabled RLGD : Retention-Lock Governance Disabled RLCE : Retention-Lock Compliance Enabled M : Mobile m : Migratable
# mtree show compression /data/col1/main
From: 2023-09-07 12:00 To: 2023-09-14 12:00
Pre-Comp Post-Comp Global-Comp Local-Comp Total-Comp
(GiB) (GiB) Factor Factor Factor
(Reduction %)
------------- -------- --------- ----------- ---------- -------------
Written:
Last 7 days 4379.3 883.2 3.4x 1.5x 5.0x (79.8)
Last 24 hrs 784.6 162.1 3.3x 1.4x 4.8x (79.3)
------------- -------- --------- ----------- ---------- -------------
使用“每日”选项：
# mtree show compression /data/col1/main daily
From: 2023-08-12 12:00 To: 2023-09-14 12:00
Sun Mon Tue Wed Thu Fri Sat Weekly
----- ----- ----- ----- ----- ----- ----- ------ -----------------
-13- -14- -15- -16- -17- -18- -19- Date
432.0 405.9 284.1 438.8 347.0 272.7 331.4 2511.8 Pre-Comp
85.5 66.2 45.3 81.9 61.4 57.4 66.3 464.1 Post-Comp
5.0x 6.1x 6.3x 5.4x 5.7x 4.7x 5.0x 5.4x Total-Comp Factor
-20- -21- -22- -23- -24- -25- -26-
478.0 387.8 450.2 533.1 386.0 258.4 393.6 2887.1
100.6 81.5 100.8 119.0 84.0 40.6 75.3 601.8
4.8x 4.8x 4.5x 4.5x 4.6x 6.4x 5.2x 4.8x
-27- -28- -29- -30- -31- -1- -2-
27.6 1.0 0.4 470.7 467.3 517.7 641.9 2126.7
4.9 0.2 0.1 83.9 92.3 89.8 140.1 411.2
5.6x 5.6x 4.3x 5.6x 5.1x 5.8x 4.6x 5.2x
-3- -4- -5- -6- -7- -8- -9-
539.6 495.0 652.8 658.7 537.1 398.7 305.5 3587.3
110.8 108.0 139.4 137.0 111.5 78.3 48.3 733.3
4.9x 4.6x 4.7x 4.8x 4.8x 5.1x 6.3x 4.9x
-10- -11- -12- -13- -14-
660.2 738.3 787.2 672.9 796.9 3655.5
143.9 152.5 167.6 126.9 163.3 754.2
4.6x 4.8x 4.7x 5.3x 4.9x 4.8x
----- ----- ----- ----- ----- ----- ----- ------ -----------------
Pre-Comp Post-Comp Global-Comp Local-Comp Total-Comp
(GiB) (GiB) Factor Factor Factor
(Reduction %)
-------------- -------- --------- ----------- ---------- -------------
Written:
Last 33 days 14768.3 2964.5 3.4x 1.5x 5.0x (79.9)
Last 24 hrs 784.6 162.1 3.3x 1.4x 4.8x (79.3)
-------------- -------- --------- ----------- ---------- -------------
Key:
Pre-Comp = Data written before compression
Post-Comp = Storage used after compression
Global-Comp Factor = Pre-Comp / (Size after de-dupe)
Local-Comp Factor = (Size after de-dupe) / Post-Comp
Total-Comp Factor = Pre-Comp / Post-Comp
Reduction % = ((Pre-Comp - Post-Comp) / Pre-Comp) * 100
使用“每日详细”选项：
# mtree show compression /data/col1/main daily-detailed
From: 2023-08-12 12:00 To: 2023-09-14 12:00
Sun Mon Tue Wed Thu Fri Sat Weekly
----- ----- ----- ----- ----- ----- ----- ------ -----------------
-13- -14- -15- -16- -17- -18- -19- Date
432.0 405.9 284.1 438.8 347.0 272.7 331.4 2511.8 Pre-Comp
85.5 66.2 45.3 81.9 61.4 57.4 66.3 464.1 Post-Comp
3.5x 4.1x 4.3x 3.6x 3.8x 3.3x 3.4x 3.7x Global-Comp Factor
1.4x 1.5x 1.5x 1.5x 1.5x 1.4x 1.5x 1.5x Local-Comp Factor
5.0x 6.1x 6.3x 5.4x 5.7x 4.7x 5.0x 5.4x Total-Comp Factor
80.2 83.7 84.1 81.3 82.3 78.9 80.0 81.5 Reduction %
-20- -21- -22- -23- -24- -25- -26-
478.0 387.8 450.2 533.1 386.0 258.4 393.6 2887.1
100.6 81.5 100.8 119.0 84.0 40.6 75.3 601.8
3.3x 3.3x 3.0x 3.0x 3.3x 4.1x 3.6x 3.3x
1.4x 1.5x 1.5x 1.5x 1.4x 1.5x 1.4x 1.5x
4.8x 4.8x 4.5x 4.5x 4.6x 6.4x 5.2x 4.8x
79.0 79.0 77.6 77.7 78.2 84.3 80.9 79.2
-27- -28- -29- -30- -31- -1- -2-
27.6 1.0 0.4 470.7 467.3 517.7 641.9 2126.7
4.9 0.2 0.1 83.9 92.3 89.8 140.1 411.2
4.4x 3.7x 2.6x 3.8x 3.5x 3.9x 3.2x 3.5x
1.3x 1.5x 1.6x 1.5x 1.4x 1.5x 1.5x 1.5x
5.6x 5.6x 4.3x 5.6x 5.1x 5.8x 4.6x 5.2x
82.1 82.2 76.8 82.2 80.3 82.7 78.2 80.7
-3- -4- -5- -6- -7- -8- -9-
539.6 495.0 652.8 658.7 537.1 398.7 305.5 3587.3
110.8 108.0 139.4 137.0 111.5 78.3 48.3 733.3
3.4x 3.1x 3.2x 3.4x 3.3x 3.4x 4.1x 3.3x
1.4x 1.5x 1.5x 1.4x 1.4x 1.5x 1.6x 1.5x
4.9x 4.6x 4.7x 4.8x 4.8x 5.1x 6.3x 4.9x
79.5 78.2 78.6 79.2 79.2 80.4 84.2 79.6
-10- -11- -12- -13- -14-
660.2 738.3 787.2 672.9 796.9 3655.5
143.9 152.5 167.6 126.9 163.3 754.2
3.1x 3.4x 3.2x 3.7x 3.4x .3x
1.5x 1.4x 1.5x 1.4x 1.5x 1.5x
4.6x 4.8x 4.7x 5.3x 4.9x 4.8x
78.2 79.3 78.7 81.1 79.5 79.4
----- ----- ----- ----- ----- ----- ----- ------ -----------------
Pre-Comp Post-Comp Global-Comp Local-Comp Total-Comp
(GiB) (GiB) Factor Factor Factor
(Reduction %)
-------------- -------- --------- ----------- ---------- -------------
Written:
Last 33 days 14768.3 2964.5 3.4x 1.5x 5.0x (79.9)
Last 24 hrs 784.6 162.1 3.3x 1.4x 4.8x (79.3)
-------------- -------- --------- ----------- ---------- -------------
Key:
Pre-Comp = Data written before compression
Post-Comp = Storage used after compression
Global-Comp Factor = Pre-Comp / (Size after de-dupe)
Local-Comp Factor = (Size after de-dupe) / Post-Comp
Total-Comp Factor = Pre-Comp / Post-Comp
Reduction % = ((Pre-Comp - Post-Comp) / Pre-Comp) * 100