压缩数据的部分下载的制作方法

压缩数据的部分下载


背景技术：

1.压缩算法长期以来一直用于压缩数据。通过压缩减少数据可以减少存储硬件开销、减少网络带宽消耗、增加信息传输速率等。改进压缩的大多数努力集中在压缩效率上，即给定单元数据的大小可以被减少多少。高效的压缩算法通常具有压缩器状态，压缩器状态控制如何编码(压缩)未压缩数据。压缩状态随着未压缩数据被读取和统计分析而适应。在任何时间点如何压缩数据取决于它前面的数据的压缩以及压缩算法。
2.通常，压缩器状态是未压缩字符串与分别对应的代码之间的关联的字典。未压缩数据的压缩版本通过统计分析而被生成，并且逐渐建立表示相应未压缩字符串的代码序列。未压缩数据的压缩形式将由代替未压缩词/字符串的代码组成。存在更复杂的技术和字典，但它们中的大多数涉及将未压缩数据映射到压缩数据的动态压缩状态。
3.如仅由发明人所观察到的，压缩算法的动态压缩/字典状态可以有利于压缩效率，但是它使得在不首先解压缩压缩数据之前的所有数据的情况下，解压缩压缩数据的内部部分是不可能的。为此，压缩数据当然必须可用。因此，随着数据被压缩而演进的压缩算法是有问题的，因为所有压缩数据必须可用，并且必须在需要的数据内部子集可以被解压缩之前被解压缩。所需部分前面的内容必须被解压缩，以便重新创建解压缩所需部分所需要的状态和字典。根据应用，这可能需要大量的处理时间、传输带宽、存储空间等。
4.这个问题的一个示例可以在包含数据项的压缩包中看到，数据项是压缩数据内的离散数据单元。服务器可能正在提供包含组成文件的压缩包以供下载。客户端可能知道它需要压缩包中的哪个文件，并且甚至可能能够向服务器指定文件在压缩流中的位置。然而，即使服务器仅提取了包含组成文件的压缩数据的相关子集，客户端也无法在没有压缩文件前面的所有压缩文件的情况下解压缩该子集。
5.下面讨论的是与解压缩压缩数据的内部段而不需要解压缩它前面的所有压缩数据有关的技术。


技术实现要素：

6.包括以下发明内容仅是为了介绍以下具体实施方式中讨论的一些概念。该发明内容不是全面的，并且不旨在描述所要求保护的主题的范围，该范围由最后提出的权利要求阐述。
7.客户端能够解压缩服务器上的压缩文件的内部部分，而不必下载和解压缩在内部部分前面的压缩文件部分。这可以通过具有离线过程记录以及在压缩期间的离散时间处捕获压缩器的状态来实现，例如，字典被周期性地捕获并且与压缩文件中的位置相关联地被存储。服务器存储与压缩文件相关联的压缩器状态和位置。如果压缩文件已经存在，则压缩器可以处理未压缩文件以生成压缩器状态，而不必生成压缩文件。备选地，服务器端可以在客户端请求时按需计算字典的状态。客户端向服务器标识压缩文件的内部段。服务器选择其位置最接近内部段的压缩器状态；压缩器状态可以是预先计算的状态，或者可以由服务器按需计算。服务器向客户端发送所选择的压缩器状态和压缩文件的内部部分。客户端利
用发送的压缩器状态准备解压缩器，然后准备的解压缩器解压缩压缩文件的内部部分。
8.下面将参考结合附图考虑的以下详细描述来解释许多伴随特征。
附图说明
9.根据附图阅读以下详细描述，将更好地理解本描述，其中在所附描述中使用相同的附图标记来表示相同的部件。
10.图1示出了客户端从服务器下载压缩文件以获得压缩文件的内部段。
11.图2示出了在压缩未压缩文件时如何捕获压缩检查点。
12.图3示出了用于生成随机访问数据的过程。
13.图4示出了客户端和服务器如何协作以使客户端能够下载和解压缩最少量的压缩文件数据以获得所需的段。
14.图5示出了客户端接收压缩文件的内部部分、关联的压缩器状态和偏移。
15.图6示出了用于部分下载和解压缩的另一个实施例。
16.图7示出了计算设备的细节。
具体实施方式
17.图1示出了客户端100从服务器104下载压缩文件102以获得压缩文件102的内部段106。段106是内部的，因为它不在压缩文件102的起始。针对讨论，本文提到的段或部分将被假设是内部的。
18.在客户端100需要段106之前，压缩文件102由压缩器108压缩未压缩文件110而生成。未压缩文件110相对于压缩器108是“未压缩的”；未压缩文件110内的数据可能碰巧先前已被另一个压缩器压缩。当客户端100需要段106时，客户端执行过程111。即，客户端向服务器104标识压缩文件102。服务器104通过将压缩文件102提供给客户端100来响应。客户端100具有解压缩器112，解压缩器112解压缩压缩文件102，并且输出解压缩文件114，解压缩文件114相当于未压缩文件110。然后，客户端从解压缩文件114中提取所需的段106。注意，一些解压缩器可以在段106的末尾已被解压缩之后停止解压缩。在任何情况下，客户端100至少需要段106前面的所有压缩文件102(被称为压缩前缀)。如可以看出的，即使客户端不需要解压缩前缀的数据，也可能需要下载和解压缩可能相当大的压缩前缀。需要压缩前缀来解压缩段106。压缩也可以由除服务器之外的实体来执行。
19.仍然参考图1，术语“客户端”和“服务器”是用于区分如图1中所示那样交换压缩数据的任何两个实体的标签。客户端和服务器可以是通过通信链路或网络通信的相应计算设备。客户端和服务器可以是计算云中的服务或实体。客户端和服务器也可以是在相同设备上执行的部件，例如虚拟机或容器。针对讨论，假设客户端使用适于通过网络从服务器传输文件的应用级协议(例如，超文本传输协议)。
20.为了方便起见，本文将单个服务器描述为执行各种行动以及提供各种信息。在实践中，行动和信息可以由几个合作的服务器端计算设备来处理。第一服务器设备可以存储未压缩文件，第二服务器设备可以通过处理第一服务器设备处的未压缩文件来生成压缩器状态数据，并且第三服务器设备可以将压缩器状态和压缩数据提供给客户端设备。未压缩文件、压缩文件和压缩器状态可以在相应的设备上。压缩数据和压缩器状态可以通过内容
分发网络(cdn)分发。cdn可以是对等网络，其中对等方都分发和消费压缩数据和压缩器状态。在本文提到单个“服务器”的情况下，也包括这些多设备架构变型。此外，服务器和客户端设备可以被替换为可能托管在云中的等效的云服务或虚拟机。
21.假设图1中压缩的文件是相对于由压缩器108实现的压缩算法的单个压缩单元。换句话说，文件作为单个编码单元被压缩，其中文件的最后部分的压缩可能取决于文件起始处的内容。这与文件被分段并且每个段仅基于其自己的内容进行压缩的压缩方法形成对比。换句话说，压缩算法持续应用于整个文件而不被复位。在大多数情况下，压缩算法将是无损的，但是本文描述的技术也可以与具有滚动压缩状态的任何有损压缩算法一起被使用。压缩器108和解压缩器112被称为不同的元件，但实际上它们可以是相同的模块或应用，其中解压缩是压缩的反函数。
22.如接下来讨论的，不是下载整个压缩文件102来获得段106，而是压缩器108可以被修改，使得可以在压缩的不同阶段捕获压缩器状态，或根据需要计算压缩流中任何给定位置的压缩器状态。如果客户端仅需要压缩文件的段，则将压缩文件的最近包含部分和对应的压缩器状态发送给客户端。客户端利用压缩器状态准备其压缩器，然后准备的压缩器解压缩包含的压缩数据，而无需解压缩包含的压缩数据前面的任何压缩数据。
23.图2示出了在压缩未压缩文件110时可以如何捕获压缩检查点120。在开始压缩之前，经修改的压缩器108没有状态。压缩器108开始压缩未压缩文件108。压缩器被配置为周期性地捕获检查点120。该周期可以是基于已处理的未压缩数据量、已生成压缩数据量、压缩状态(例如，字典的大小)、未压缩文件的比率(例如，1/100)和/或类似的度量。可以通过设置压缩器的参数来控制检查点速率或基准。也可以基于文件的内容或基于使用数据，启发式地偏置检查点或粒度，并且也可以设置参数来标识特定的感兴趣区域。关于前者，可以在文件内容中的元素或数据项的边界处或附近强制设置检查点。可以增加粒度以匹配组成数据项的大小。在文件包含许多小数据项的情况下，可以使检查点粒度更细。在文件包含大数据项的情况下，可以使检查点粒度更粗。关于使用数据，如果有关于最频繁访问压缩文件的哪些组成部分的历史数据，则可以在最频繁访问的组成部分的边界处强制设置检查点。
24.当压缩器108确定已经达到第一周期时，捕获第一检查点120。至少，检查点包括压缩器状态122，在图1中被表示为s1。压缩器在分析和压缩未压缩数据时构建其压缩器状态(通常是字典)。在图1中，状态s1是压缩器在压缩未压缩文件的前面部分(在图1中被标记为部分fu1)之后构建的信息(例如字典)。检查点120还可以包括针对fu1的未压缩文件偏移124(ou1)，以及针对压缩文件104的对应部分的压缩文件偏移126(oc1)。这些是距相应文件起始的距离。如下面将解释的，这些偏移可以用于查找客户端解压缩压缩文件中的任何给定段或点所需的压缩器状态和压缩数据。
25.在取得第一个检查点之后，压缩继续直到到达下一个检查点。下一个检查点被捕获，其包括直到压缩的当前点的偏移和压缩器状态。压缩器状态可能已从先前的压缩器状态改变。压缩器状态将取决于已被压缩的所有数据。重复该过程直到整个未压缩文件已被压缩，以产生压缩文件102。检查点120被存储为与压缩文件相关联的数据集，优选地按照它们被捕获的顺序。针对压缩文件的末尾的检查点不是必需的。检查点数据将被称为随机访问数据128，因为它使能对压缩数据的准随机访问，而不必下载和解压缩所有前面的压缩数据。
26.在一个实施例中，如果未压缩文件是包含诸如组成文件的离散元素的包或存档。在该情况下，压缩器还可以在每次达到离散元素边界时强制设置检查点。这些检查点可以与周期性检查点组合使用或代替周期性检查点使用。在另一个实施例中，组成元素的偏移在遇到时被捕获，但压缩器状态仅被周期性地捕获。
27.图3示出了用于生成随机访问数据128的过程。在初始化步骤140处，压缩器108获得压缩参数，并且利用该些参数对其自身进行配置。压缩参数可以包括已知参数，诸如使用哪种算法、压缩水平(如果适用)等。该些参数还可以打开或关闭检查点，设置检查点参数，诸如检查点的频率(粒度)，检查点可能发生的特定位置，或者将如何标记检查点。虽然细颗粒的粒度是可能的，但压缩状态相对于文件的大小可能有点大(例如，对于1gb文件，50mb)。过多的检查点可以引起存储和效率问题。
28.在配置压缩器108之后，压缩步骤142开始。压缩器以通常的方式开始压缩未压缩文件，累积压缩器状态并且输出压缩数据，压缩数据是每个压缩器状态迄今为止遇到的未压缩数据的编码。压缩器状态可以是通常由压缩器产生并且以某种形式保留以供压缩器在稍后阶段使用的任何状态(并且类似地由解压缩器产生和使用)。当压缩器确定已达到检查点时，压缩器状态和对应的文件偏移被捕获。压缩和检查点继续进行，直到未压缩文件已经被压缩。在最后步骤144处，检查点被存储为随机访问数据128，随机访问数据128可以是合适的对象、数据结构或格式，例如标记文件、表格、javascript对象符号文件等。随机访问数据128与压缩文件102相关联地被存储，使得当请求压缩文件的段时，服务器访问正确的随机访问数据128。备选地，检查点可以与压缩文件一起被打包，在元数据报头中或散布在压缩文件中的对应点处。
29.图4示出了客户端100和服务器104如何协作，以使客户端能够下载和解压缩最少量的压缩文件数据来获得所需的段106。在图4中，在客户端需要段106之前，压缩文件和随机访问数据在服务器上已经可用。在步骤160处，客户端开始于确定需要哪个文件及其段。段可以通过偏移和长度(压缩或未压缩)来标识，或者，在压缩文件包含离散描述和标识的数据项的情况下，段可以通过数据项的标识符来标识。然后，在下载请求162中将文件的标记和段的标记发送到服务器。
30.在步骤164处，服务器接收下载请求162。服务器使用请求中的标识符，来标识压缩文件及其相关联的随机访问数据128。在压缩文件和随机访问数据128被打开或可访问之后，服务器使用段106的标记，来确定在压缩文件中的段的开头前面并且最接近该开头的检查点。如果段106由数据项标识符标识，则服务器将使用它来标识段的开头。如果客户端发送了未压缩文件中的段的开头的位置，则检查点数据可以用于找到最近的先前检查点。如果客户端发送了压缩文件中的段的开头的位置，则搜索随机访问数据，以找到小于压缩文件中的段的开头的、具有最大压缩偏移的检查点。
31.在找到开始检查点之后，为了最小化需要被发送到客户端的压缩数据的量，服务器还可以确定结束检查点，结束检查点具有最接近、但在压缩文件中的段的末尾之后的压缩偏移(其可以由客户端提供或通过段的身份推断)。结束检查点偏移可以被服务器使用，来确定要发送的压缩数据的量，该压缩数据的量既最小又足以由客户端解压缩。备选地，服务器可以发送压缩数据，直到客户端终止传输。
32.当起始偏移和要发送的压缩数据的量(如果有的话)已知时，服务器向客户端发送
回复166，起始偏移的压缩器状态以及检查点的偏移中的一个或两个。然后，服务器开始从检查点的压缩偏移开始发送压缩数据。在图2和图4的示例中，在压缩文件中，所需段106恰好被包含在压缩文件的第三压缩部分(fc3)内。最近的先前检查点是第二检查点(ou2，oc2，s2)。因此，服务器至少发送针对第二检查点(s2)的压缩器状态，并且还可以发送一个或两个偏移。当服务器发送了先前确定的压缩数据量或当客户端结束传输时，服务器停止发送压缩数据。
33.在步骤168处，客户端接收压缩器状态和一个或多个偏移。利用压缩器状态(例如，s2)准备客户端的解压缩器108。这涉及利用一种状态配置解压缩器，如果解压缩器解压缩了压缩文件中的压缩器状态检查点之前的所有压缩数据，它将自然获得该状态。在图2和图4的示例中，假设是从压缩文件的起始到fc3的开头的压缩数据，即oc2。
34.当解压缩器已被准备时，解压缩器开始解压缩来自服务器的压缩文件数据。当解压缩器开始解压缩以生成解压缩文件数据时，客户端将需要知道它何时到达由解压缩器输出的解压缩数据内的所需段106的起始。如果段的开头作为从未压缩文件的起始的偏移而对客户端已知，则段的开头将是解压缩数据中的一个位置，该位置被选择为使得在该位置处的解压缩数据量加上从服务器的未压缩偏移(例如，ou2)等于该段在未压缩文件中的偏移。备选地，段的开头可以通过解压缩数据内的数据模式、标记标签、数据模式、标识段的标识符等来标识。客户端继续接收和解压缩数据，直到到达段的末尾，可以以类似的方式找到段的末尾。如上所述，客户端可以向服务器发信号以停止发送数据。客户端通过仅下载压缩数据的内部子部分、压缩器状态和可能的其他信息来帮助标识或提取该段，而获取了所需的段106。
35.图5示出了客户端100接收压缩文件102的内部部分180，以及相关联的压缩器状态122和偏移124。首先，客户端(例如执行由用户操作的网络浏览器)获得并且显示来自服务器的目录列表。用户操作网络浏览器，以从目录列表选择压缩文件102。然后，客户端获得内容信息，诸如清单、元数据、目录、存档/包报头或列出压缩文件中的数据项的类似信息。用户操作网络浏览器以交互地选择压缩文件中的数据项以进行下载。网络浏览器向服务器发送信息，允许服务器标识数据项，例如偏移和长度、标识符、压缩文件中指向数据项的节点等。
36.服务器使用关于数据项的信息，来找到其偏移在数据项的开头最紧密前面的检查点。对应的压缩器状态(通过压缩检查点之前的数据获得)和可能的项目标识信息被发送到网络浏览器，该网络浏览器利用压缩器状态准备解压缩器，并且开始将来自服务器的压缩数据传递给它，解压缩器开始解压缩该压缩数据，以输出包含段的解压缩文件数据182。项目标识信息可以是偏移(并且可以是未压缩数据中的数据项的长度偏移或末尾偏移)或解压缩数据内的数据模式，该数据模式划分数据项。在一些实施例中，服务器不发送任何项目标识信息。相反，客户端使用先前从服务器获得的数据项的标记(例如文件名、inode标识符、xpath等)。当网络浏览器确定或检测到所需段的开头时，网络浏览器开始将该段保存或提取到本地存储。当确定或检测到段的末尾时，该段完成并且被保存，并且解压缩和下载停止。
37.图6示出了用于部分下载和解压缩的另一个实施例。在步骤190处，客户端向服务器标识文件。在该实施例中，在步骤192处，服务器将文件的随机访问数据发送给客户端。然
后，客户端具有向服务器标识所需压缩数据所需的所有信息。在步骤194处，以与先前描述的服务器活动类似的方式，客户端确定它需要什么段。基于段和随机访问数据，客户端确定它将需要什么压缩器状态以及压缩文件的什么部分。客户端上已经可用的压缩器状态被加载到客户端的解压缩器中。在步骤196处，客户端向服务器发送对文件的压缩数据的请求，按照随机访问数据指定压缩文件中的开始偏移。在步骤198处，客户端接收压缩数据，利用准备的解压缩器解压缩，并且从由解压缩器输出的解压缩文件数据提取所需的段。
38.上面描述的技术可以与自适应压缩一起使用。自适应压缩涉及在压缩相同的一组数据时在压缩算法之间切换。当压缩器捕获检查点时，压缩器还包括具有检查点数据的压缩算法。当压缩器第一次切换到新算法时，下一个检查点将包括针对该算法的压缩器状态。不需要向客户端通知算法切换；解压缩器将基于压缩数据的内容自动切换算法，就像压缩器所做的那样。
39.图7示出了可以用作主机100的计算设备300的细节。本文的技术公开将足以让编程者编写软件和/或配置可重新配置的处理硬件(例如，现场可编程门阵列(fpga)))，和/或设计专用集成电路(asic)等，以在计算设备300上运行来实现本文描述的任何特征或实施例。
40.计算设备300可以具有一个或多个显示器322、网络接口324(或多个)，以及存储硬件326和处理硬件328，它们可以是以下任何一个或多个的组合：中央处理单元，图形处理单元、模数转换器、总线芯片、fpga、asic、专用标准产品(assp)或复杂可编程逻辑器件(cpld)等。可以是本地和/或远程的存储硬件326可以是磁性存储、静态存储器、易失性存储器、非易失性存储器、光学或磁性可读物质等的任何组合。本文使用的术语“存储”的含义不是指信号或能量本身，而是指物理装置和物质状态。计算设备300的硬件元件可以以机器计算领域中熟知的方式协作。此外，输入设备可以与计算设备300集成或与之通信。计算设备300可以具有任何形状因子或者可以用于任何类型的包含设备中。计算设备300可以是手持设备的形式，诸如智能手机、平板计算机、游戏设备、服务器、机架安装或背板的板上计算机、片上系统或其他。
41.上面讨论的实施例和特征可以以存储在易失性或非易失性计算机或设备可读存储硬件中的信息的形式来实现。这被认为至少包括硬件，诸如光学存储(例如，压缩盘只读存储器(cd-rom))、磁介质、闪存只读存储器(rom)或任何存储数字信息以使处理硬件328容易获得的部件。所存储的信息可以是以下形式：机器可执行指令(例如，编译的可执行二进制代码)、源代码、字节码或可以用于使能或配置计算设备执行上面讨论的各种实施例的任何其他信息。这也被认为至少包括易失性存储器(诸如随机存取存储器(ram)和/或虚拟存储器，其在实施实施例的程序的执行期间存储诸如中央处理单元(cpu)指令等信息)以及用于存储允许加载或执行程序或可执行文件的信息的非易失性介质。实施例和特征可以在任何类型的计算设备上执行，包括便携式设备、工作站、服务器、移动无线设备等。