文件系统块级分层与协同分配的制作方法

文件系统块级分层与协同分配的制作方法
【专利摘要】本申请涉及文件系统块级分层与协同分配。本发明的实施例涉及块内组织的存储放置。一种实施例包括获得文件系统中的文件。文件被分成多个块。所述多个块被分成至少两个相关的子块。在文件系统元数据布局中为所述至少两个相关的子块确定在不同存储器设备上的文件内块组织的存储放置。
【专利说明】
文件系统块级分层与协同分配
技术领域
[0001] 本发明的实施例设及块内存储组织，并且，更具体而言，设及文件块内分层和协同 定位存储组织。
【背景技术】
[0002] 术语"大数据"被用作又大又复杂W至于变得难W利用手边的数据库管理工具或 传统数据处理应用来处理的数据集的任何集合的概括性术语。挑战包括捕获、策展 (curation)、存储、捜索、共享、传送、分析和可视化。与具有相同数据总量的单独的较小集 合相比，到更大数据集的趋势是由于可从单个大的相关数据集的分析得出的附加信息，从 而允许找出发现业务趋势的相关性、确定科研质量、预防疾病、链接法律引用、打击犯罪W 及确定实时道路交通情况。
[0003] 大数据难W利用大多数关系数据库管理系统W及桌面统计和可视化包进行工作， 而是代替地需要在数十、数百或者甚至数千台服务器上运行的大规模并行软件。什么被认 为是"大数据"依赖于组织管理数据集的能力、并依赖于传统上在其领域中被用来处理和分 析数据集的应用的能力而变化。大数据通常包括尺寸超过在容许的经过时间内管理和处理 数据的常用软件工具的能力的数据集。
[0004] 如本文所使用的，大型数据库是列式或混合列式数据库，其存储数据表作为数据 列而不是作为数据行的部分并且包括至少一千兆兆字节的数据。运种大型数据库目前被用 于其中非常大量的数据被存储、查询、聚集、分析和捜索的各种应用，诸如业务数据分析应 用。现代业务数据分析应用对大量的数据计算聚集，W便沿越来越多的维度逐渐积累 (roll-up)信息，诸如地域、人口、用户、产品，等等。传统上，在线业务分析数据库通过对数 据库的重要部分执行顺序扫描来执行运种查询。由于日益增加的尺寸和维度，W及如今大 型分析数据库的交互式查询响应时间的日益增加的重要性，通过扫描整个大型数据库来查 询数据库是不可行的。除了大型数据库的尺寸，其它因素也使得利用已知技术对大型数据 库进行低等待时间查询是困难的。例如，在在线分析数据库中，本质上特设(ad hoc)的数据 库查询的百分比高，运使得难W为大型数据库建立索引。大量的维度使得诸如预先计算立 方体的技术在空间和计算上都非常昂贵。
[0005] 目前，运些大型分析数据库被存储在传统的数据存储设备上，诸如硬盘驱动器等。 最近，在改善大型列式数据库的性能的尝试中，一些大型数据库已经被存储在高性能的存 储设备上，诸如固态设备或闪速存储器等。虽然在高性能存储设备上存储大型数据库提高 了对大型数据库的一些查询的速度，但是提高的性能是W高成本得到的，因为高性能存储 设备要比传统的数据存储设备昂贵得多。

【发明内容】

[0006] 本发明的实施例设及文件内块存储组织。一种实施例包括一种方法，该方法包括 获得文件系统中的文件。将文件分成多个块。将所述多个块分成至少两个相关的子块。在文 件系统元数据布局中为所述至少两个子块确定在不同存储器设备上的文件内块组织的存 储放置。
[0007] 另一实施例包括用于块内存储器管理的计算机程序产品。该计算机程序产品包括 具有体现在其中的程序代码的计算机可读存储介质。程序代码可由处理器执行，W便由处 理器获得文件系统中的文件。处理器将文件分成多个块。处理器将多个块中的每个块分成 至少两个相关的子块。由处理器在文件系统元数据布局中为所述至少两个相关子块确定在 不同存储器设备上的文件内块组织的存储放置。
[0008] -种实施例包括一种方法，该方法包括获得文件系统中的文件的块。将块分成至 少两个子块。在文件系统元数据布局中为所述至少两个子块确定在不同存储器设备上的文 件内块分层和协同定位存储放置。
[0009] 本发明的运些和其它特征、方面和优点将参考下面的描述、所附权利要求和附图 变得被理解。
【附图说明】
[0010] 图1示出了根据实施例的云计算节点。
[0011] 图2示出了根据实施例的云计算环境。
[0012]图3示出了根据实施例的一组抽象模型层。
[0013] 图4示出了根据实施例的在计算机系统/服务器中的特征的更多细节。
[0014] 图5示出了表如何跨节点/集群中的计算机系统/服务器被逻辑地表示为分布式文 件系统(DFS)块中的单个FlashQueryFile文件/布局。
[0015] 图6示出了具有表中的数据值的行和列的原始关系。
[0016] 图7示出了用于选择列的选择优化布局。
[0017] 图8示出了预测模型的离线和运行时创建W引导运行时列数据放置的流程图。
[0018] 图9示出了根据实施例的将块分割成子块。
[0019] 图10示出了根据一种实施例的将来自图6的表的子块放置在闪存和HDD上。
[0020] 图11示出了根据实施例的子块的文件内块分层和协同定位。
[0021] 图12示出了根据实施例的用于文件内块组织的存储放置的过程的框图。
【具体实施方式】
[0022] W下参考根据本发明实施例的方法、装置(系统)和计算机程序产品的流程图说明 和/或框图来描述本发明的各方面。将理解，流程图说明和/或框图的每个方框及流程图说 明和/或框图中方框的组合可W由计算机程序指令来实现。运些计算机程序指令可W提供 给通用计算机、专用计算机或者其它可编程数据处理装置的处理器，来产生一种机器，使得 经由计算机或者其它可编程数据处理装置的处理器执行的指令产生用于实现在所述流程 图和/或框图的一个或多个方框中所指定的功能/动作的装置。
[0023] 大多数已知的数据库存储分层技术旨在在高性能、可随机存取的诸如"闪存层"的 层上放置流行的、经常存取的数据。数据的流行程度W反应方式确定，由此，模块记录工作 负荷的存取模式，并且，如果数据集开始被存取很多，则它被认为是流行的并且被移动到高 性能层。运种反应技术遭受确定存取模式的反应时间和不能提供前期(upfront)性能保证 之害。此外，运些技术当中大多数处于低得多的块级并且没有关于在列级处的数据的语义 知识。
[0024] -种实施例提供包括获得文件系统中的文件的方法。文件被分成多个块。所述多 个块中的每个块被分成至少两个相关的子块。在文件系统元数据布局中为所述至少两个相 关的子块确定在不同存储器设备上的文件内块组织的存储放置。应当指出的是，文件系统 元数据具有文件系统元数据结构，也被称为"文件系统元数据布局"。文件系统元数据结构 或文件系统元数据布局是指被文件系统用于存储文件系统元数据的布局或格式。文件系统 元数据与文件系统元数据布局相关联。如果存储介质(例如，系统储存器34(图1))利用一个 或多个盘实现，则文件系统元数据布局被称为文件系统盘布局。文件系统元数据布局可W 改变，W支持添加到文件系统的新功能，或者支持不同的文件尺寸(例如，更大）。文件系统 元数据包括描述用户数据的各种特性的信息字段。
[0025] 在一种实施例中，文件内块组织的存储放置基于不同存储器设备(例如，固态驱动 器(SSD)和硬盘驱动器化孤））上的文件内块分层或协同定位。在一种实施例中，实现了由应 用将通告(advisory)传递到文件系统W便将进入的文件块放置在特定的层/存储池上的机 审IJ。在一种实施例中，机制指定对文件块协同定位的约束。索引节点（inode)结构被修改来 支持文件内分层并且两个块之间的关系被在索引节点结构中指定。应当指出的是，索引节 点存在于文件系统中，或其上，并且表示关于文件的元数据。索引节点包含诸如所有权（用 户、组）、存取模式(读、写、执行许可)和文件类型的信息。
[0026] 云计算是一种服务交付模式，用于对共享的可配置计算资源池进行方便、按需的 网络访问。可配置计算资源是能够W最小的管理成本或与服务提供者进行最少的交互就能 快速部署和释放的资源，例如可W是网络、网络带宽、服务器、处理、内存、存储、应用、虚拟 机和服务。运种云模式可W包括至少五个特征、至少=个服务模型和至少四个部署模型。
[0027] 特征包括：
[0028] 按需自助式服务:云的消费者在无需与服务提供者进行人为交互的情况下能够单 方面自动地按需部署诸如服务器时间和网络存储等的计算能力。
[0029] 广泛的网络接入:计算能力可W通过标准机制在网络上获取，运种标准机制促进 了通过不同种类的瘦客户机平台或厚客户机平台（例如移动电话、膝上型电脑、个人数字助 理PDA)对云的使用。
[0030] 资源池:提供者的计算资源被归入资源池并通过多租户(multi-tenant)模式服务 于多重消费者，其中按需将不同的实体资源和虚拟资源动态地分配和再分配。一般情况下， 消费者不能控制或甚至并不知晓所提供的资源的确切位置，但可W在较高抽象程度上指定 位置(例如国家、州或数据中屯、），因此具有位置无关性。
[0031] 迅速弹性:能够迅速、有弹性地(有时是自动地)部署计算能力，W实现快速扩展， 并且能迅速释放来快速缩小。在消费者看来，用于部署的可用计算能力往往显得是无限的， 并能在任意时候都能获取任意数量的计算能力。
[0032] 可测量的服务：云系统通过利用适于服务类型（例如存储、处理、带宽和活跃用户 帐号）的某种抽象程度的计量能力，自动地控制和优化资源效用。可W监测、控制和报告资 源使用情况，为服务提供者和消费者双方提供透明度。
[0033] 服务模型如下：
[0034] 软件即服务(SaaS):向消费者提供的能力是使用提供者在云基础架构上运行的应 用的能力。可W通过诸如网络浏览器的瘦客户机接日（例如基于网络的电子邮件)从各种客 户机设备访问应用。除了有限的特定于用户的应用配置设置外，消费者既不管理也不控制 包括网络、服务器、操作系统、存储、乃至单个应用能力等的底层云基础架构。
[0035] 平台即服务(PaaS):向消费者提供的能力是在云基础架构上部署消费者创建或获 得的应用，运些应用利用提供者支持的程序设计语言和工具创建。消费者既不管理也不控 制包括网络、服务器、操作系统或存储的底层云基础架构，但对其部署的应用具有控制权， 对应用托管环境配置可能也具有控制权。
[0036] 基础架构即服务(IaaS):向消费者提供的能力是消费者能够在其中部署并运行包 括操作系统和应用的任意软件的处理、存储、网络和其他基础计算资源的能力。消费者既不 管理也不控制底层的云基础架构，但是对操作系统、存储和其部署的应用具有控制权，对选 择的网络组件(例如主机防火墙)可能具有有限的控制权。
[0037] 部署模型如下：
[0038] 私有云：云基础架构单独为某个组织运行。云基础架构可W由该组织或第=方管 理并且可W存在于该组织内部或外部。
[0039] 共同体云:云基础架构被若干组织共享并支持有共同利害关系(例如任务使命、安 全要求、政策和合规考虑）的特定共同体。共同体云可W由共同体内的多个组织或第=方管 理并且可W存在于该共同体内部或外部。
[0040] 公共云:云基础架构向公众或大型产业群提供并由出售云服务的组织拥有。
[0041] 混合云：云基础架构由两个或更多部署模型的云（私有云、共同体云或公共云）组 成，运些云依然是独特的实体，但是通过使数据和应用能够移植的标准化技术或私有技术 (例如用于云之间的负载平衡的云突发流量分担技术)绑定在一起。
[0042] 云计算环境是面向服务的，特点集中在无状态性、低禪合性、模块性和语意的互操 作性。云计算的核屯、是包含互连节点网络的基础架构。
[0043] 现在参考图1，示出了根据实施例的云计算节点/群集的例子的示意图。云计算节 点/群集10只是可W在存储/处理大数据中被使用的合适的云计算节点/群集的一个例子， 并且不是要暗示关于本文所述实施例的使用范围或功能的任何限制。不管怎样，云计算节 点/群集10都能够被实现和/或执行本文所阐述的任何功能。
[0044] 在云计算节点/群集10中，存在多个计算机系统/服务器12,它们可W与众多其它 通用或专用计算系统环境或配置一起进行操作。多个计算机系统/服务器12通过连接82(诸 如光纤，等等)来连接。虽然在图1中示出一个计算机系统/服务器12的具体细节，但是所述 细节适用于计算节点/群集10中的其它计算机系统/服务器12。可W适合与计算机系统/月良 务器12-起使用的众所周知的计算系统、环境和/或配置的例子包括但不限于，个人计算机 系统、服务器计算机系统、瘦客户端、胖客户端、手持或膝上型设备、多处理器系统、基于微 处理器的系统、机顶盒、可编程消费电子产品、网络PC、小型计算机系统、大型机计算机系统 W及包括任何W上系统或设备的分布式云计算环境，等等。
[0045] 计算机系统/服务器12可W在由计算机系统执行的计算机系统可执行指令(诸如 程序模块)的一般语境下描述。通常，程序模块可W包括执行特定的任务或者实现特定的抽 象数据类型的例程、程序、目标程序、组件、逻辑、数据结构等。计算机系统/服务器12可W在 通过通信网络链接的远程处理设备执行任务的分布式云计算环境中实施。在分布式云计算 环境中，程序模块可W位于包括存储设备的本地或远程计算系统存储介质上。
[0046] 如图1所示，云计算节点10中的计算机系统/服务器12W通用计算设备的形式表 现。计算机系统/服务器12的组件可W包括但不限于：一个或者多个处理器或者处理单元 16,系统存储器28,连接不同系统组件(包括系统存储器28和处理单元16)的总线18。
[0047] 处理器单元16包括处理电路(处理器电路），W读取、处理和执行计算机可执行指 令，如本领域技术人员理解的。
[0048] 总线18表示几类总线结构中的一种或多种，包括存储器总线或者存储器控制器、 外围总线、图形加速端口、处理器或者使用多种总线结构中的任意总线结构的局域总线。举 例来说，运些体系结构包括但不限于工业标准体系结构（ISA)总线，微通道体系结构(MAC) 总线，增强型ISA总线、视频电子标准协会(VESA)局域总线W及外围组件互连(PCI)总线。
[0049] 计算机系统/服务器12典型地包括多种计算机系统可读介质。运些介质可W是能 够被计算机系统/服务器12访问的任意可获得的介质，包括易失性和非易失性介质，可移动 的和不可移动的介质。
[0050] 系统存储器28可W包括易失性存储器形式的计算机系统可读介质，例如随机存取 存储器(RAM)30和/或高速缓存存储器32。计算机系统/服务器12可W进一步包括其它可移 动/不可移动的、易失性/非易失性计算机系统存储介质。仅作为举例，存储系统34可W用于 读写不可移动的、非易失性磁介质（图1未显示，通常称为"硬盘驱动器"、"硬盘"和/或"硬盘 磁盘驱动器"）。尽管图1中未示出，可W提供用于对可移动非易失性磁盘(例如"软盘"）读写 的磁盘驱动器，W及对可移动非易失性光盘(例如CD-ROM,DVD-ROM或者其它光介质）读写的 光盘驱动器。在运些情况下，每个驱动器可W通过一个或者多个数据介质接口与总线18相 连。存储器28可W包括至少一个程序产品，该程序产品具有一组(例如至少一个)程序模块， 运些程序模块被配置W执行本发明各实施例的功能。
[0051] 作为例子但不是限制，存储器28可W包括操作系统、一个或多个应用程序、其它程 序模块W及程序数据。操作系统、一个或多个应用程序、其它程序模块W及程序数据(或它 们的某种组合)可W包括联网环境的实现。
[0052] 此外，计算机系统/服务器12包括闪速存储器75(也被称为闪存）。如本文根据实施 例所讨论的，闪速存储器75连同硬盘驱动器34 -起存储大数据。闪速存储器75包括 FlashQueryFile(闪存查询文件）80JlashQue巧File 80可W存储在存储器28的其它部分 中。FlashQueryFile 80具有执行如本文所描述的实施例的功能和/或方法的程序模块42 (其可W是一个或多个软件应用）Jlash如eryFile 80可W实现本文进一步讨论的算法。虽 然Flash如eryFi Ie 80的特征在单个计算机系统/服务器12中被突出，但是Flash如eryFiIe 80 (及其功能）可W跨计算节点/群集10中的其它计算机系统/服务器12分布。 Flash如eryFile 80被配置为具有实现本文讨论的实施例所需的所有软件元素。
[0053] 计算机系统/服务器12也可W与一个或多个外部设备14(例如键盘、指向设备、显 示器24等)通信，还可与一个或者多个使得用户能与该计算机系统/服务器12交互的设备通 信，和/或与使得该计算机系统/服务器12能与一个或多个其它计算设备进行通信的任何设 备（例如网卡，调制解调器等等）通信。运种通信可W通过输入/输出（I/O)接口 22进行。并 且，计算机系统/服务器12还可W通过网络适配器20与一个或者多个网络（例如局域网 化AN),广域网(WAN)和/或公共网络，例如因特网）通信。如图所示，网络适配器20通过总线 18与计算机系统/服务器12的其它模块通信。应当明白，尽管图中未示出，其它硬件和/或软 件模块可W与计算机系统/服务器12-起操作，包括但不限于:微代码、设备驱动器、冗余处 理单元、外部磁盘驱动阵列、RAID系统、磁带驱动器W及数据备份存储系统等。
[0化4] 现在参考图2,其中显示了示例性的云计算环境50。如图所示，云计算环境50包括 云计算消费者使用的本地计算设备可W与其相通信的一个或者多个云计算节点10,本地计 算设备例如可W是个人数字助理(PDA)或移动电话54A，台式电脑54B、笔记本电脑54C和/或 汽车计算机系统54N。云计算节点10之间可W相互通信。可W在包括但不限于如上所述的私 有云、共同体云、公共云或混合云或者它们的组合的一个或者多个网络中将云计算节点10 进行物理或虚拟分组（图中未显示）。运样，云的消费者无需在本地计算设备上维护资源就 能请求云计算环境50提供的基础架构即服务（laaS)、平台即服务(PaaS)和/或软件即服务 (SaaS)。应当理解，图2显示的各类计算设备54A-N仅仅是示意性的，云计算节点10 W及云计 算环境50可W与任意类型网络上和/或网络可寻址连接的任意类型的计算设备(例如使用 网络浏览器)通信。
[0055] 现在参考图3,其中显示了云计算环境50(图2)提供的一组功能抽象层。首先应当 理解，图3所示的组件、层W及功能都仅仅是示意性的，本发明的实施例不限于此。如图3所 示，提供下列层和对应功能：
[0056] 硬件和软件层60包括硬件和软件部件。硬件部件的例子包括:大型机61;基于RISC (精简指令集计算机)体系架构的服务器62;服务器63;刀片服务器64;存储设备65; W及网 络和联网部件66。在一些实施例中，软件部件包括网络应用服务器软件67和数据库软件68。
[0057] 虚拟层70提供一个抽象层，该层可W提供下列虚拟实体的例子:虚拟服务器71、虚 拟存储72、虚拟网络73(包括虚拟私有网络）、虚拟应用和操作系统74, W及虚拟客户端75。
[0058] 在一个示例中，管理层80可W提供下述功能:资源供应功能81:提供用于在云计算 环境中执行任务的计算资源和其它资源的动态获取;计量和定价功能82:在云计算环境内 对资源的使用进行成本跟踪，并为此提供帐单和发票。在一个例子中，该资源可W包括应用 软件许可。安全功能:为云的消费者和任务提供身份认证，为数据和其它资源提供保护。用 户口户功能83:为消费者和系统管理员提供对云计算环境的访问。服务水平管理功能84:提 供云计算资源的分配和管理，W满足必需的服务水平。服务水平协议(SLA)计划和履行功能 85:为根据SLA预测的对云计算资源未来需求提供预先安排和供应。
[0059] 工作负荷层90提供如下功能的例子:云计算环境可W用于该功能。从运个层可W 提供的工作负荷和功能的例子包括:地图绘制与导航91;软件开发及生命周期管理92;虚拟 教室教学提供93;数据分析处理94;事务处理95; W及块级分层和协同分配处理96。如W上 所提到的，关于图3描述的所有前面的例子都仅仅是说明性的，并且本发明不限于运些例 子。
[0060] 应当理解，如本文所描述的一个或多个实施例的所有功能通常都由图4中所示的 系统执行，其可W被有形地体现为程序/实用程序40的程序代码42的模块(图1)。但是，情况 不必如此。更确切地说，本文所描述的功能可W由图3中所示的层60、70、80和90当中任何一 个执行/实现和/或启用。
[0061] 重申一遍，虽然本公开内容包括关于云计算的详细描述，但是本文所描述的教导 的实现不限于云计算环境。更确切地说，本发明的实施例意在利用现在已知或W后开发的 任何类型的群集计算环境来实现。
[0062] 在大数据SQL分析中，数据库表被存储为专口的文件格式（例如，Parquet， ORCFile，等等）的文件。每种文件格式具有对文件进行读和写的相关联的IO串行器和解串 器（串行解串器）。对于大数据，用于查询处理的存储性能可W通过W下来增强:通过使用IO 高效的串行器/解串器（串行解串器)和列式布局来减少每个查询需要被扫描的数据、依靠 用于更高IO吞吐量的向外扩展（scale-out)并行化，和/或充分利用更快的介质，诸如用于 对数据快速存取的存储器或闪存。
[0063] 现有技术的大数据SQL分析文件格式W及关联的串行器和解串器是为HDD设计的， 其中所有的体系架构决策、数据结构、投影算法（pro ject ion algorithm)、选择算法 (selection algorithm)和加入算法（join algorithm)，连同参数一起，都基于皿D的基本 性能特性。给定HDD中固有的高寻道时间，尽可能多地避免随机1/0,并且强调顺序存取，因 为顺序存取比皿D上的随机存取快几个数量级。充分利用更快和可随机存取的存储介质(诸 如存储器层次结构中的闪存）的一种途径曾经是经由反应式分层。在反应式分层中，存储模 块监视对数据的存取模式并将被频繁存取的数据移动到高性能闪存层（即，闪速存储器）。 运种移动是透明地进行的，而没有任何应用察觉。其结果是，应用利用为硬盘固有地设计的 相同算法、预取机制、应用程序接口（API)继续存取现在驻留在闪存上的数据。其结果是，所 获得的性能只是可利用闪存优化算法和代码实现的性能的一小部分。如在现有技术中所使 用的，当利用HDD-优化的算法和假设的同时在闪存中的现有结构化英语查询语言（S化)文 件格式中的一种的简单数据放置能够充分利用非常小的性能增益(performance gain)和 细粒度数据跳过(data skipping)，而运种性能增益和细粒度数据跳过可利用此类可随机 存取介质W其它方式实现。为了提取最佳性能/$W证明（justify)闪存的更高成本是有道 理的，从顺序存取HDD到诸如闪存的可随机存取的存储介质的过渡要求重新检查串行解串 器的基本设计决定、数据布局、选择和投影算子。
[0064] 图4示出了根据一种实施例的具有块级处理410的存储器28。一种优化技术设及用 于跨存储在计算机节点/群集10中的大数据的SQL的被称为Flash如eryFi 1 e 80的闪存优化 的串行解串器。FlashQueryFi Ie的选择算法104、投影算法106、摄入算法（ingest ion algorithm)102、由FlashRCFile提供的数据布局(布局)304W及元数据为诸如闪存（闪速存 储器75)的可随机存取存储器进行优化，W产生提高的性能八DFlashQueryFile 80是存储 分层察觉部，并且W应用察觉方式提供适合闪存的、流行列的子集在闪存层（闪速存储器 75)中的预测放置(经由放置算法108)的机制。运允许Flash如eryFiIe 80对特设(ad hoc) 分析查询提供前期性能保证。通过借助于从根本上重新设计数据结构和元数据W允许细粒 度的数据跳过并且通过充分利用谓词下推和晚期物化Qate materialization)，从而在选 择和投影期间只读取用于查询绝对必需的数据，FlashQueryFile 80减少了查询处理等待 时间。Flash如eryFile 80还在其选择算法中采用数据存取并行化，运是通过闪存允许的内 部10并行化而成为可能的。FlashQueryFile 80仔细考虑在平衡扫描算法中的顺序和随机 存取时闪存75的特性，运是非常重要的，因为每个随机存取也具有与之关联的API开销。如 果API调用开销变成主导，则单纯地(Naively)制做多个小的随机存取而不是一个大的顺序 存取实际上会损害性能。Flash如eryFile 80可W显示利用高性能10 API、对象串行化和解 串W及能够得出闪存的性能优势的数据结构的重要性。使用固有地为硬盘设计的API,诸如 积极地缓冲和预取的API,实际会否定闪存75的性能优点。如下面进一步描述的，根据一种 或多种实施例，Flash如eryFiIe 80可W利用用于文件内块分层和/或文件内块协同定位的 块级处理410来改进。
[0065] 按照惯例，现有研究主要着眼于将闪存结合在更新繁重(update-heavy)、在线交 易处理(OLTP)工作负荷当中。对于在分析处理(OLAP)工作负荷中充分利用闪存，已经做了 一些工作。根据一种或多种实施例，Flash如eryFile 80为大数据分析查询处理提供闪存优 化的串行解串器，并且通过文件内块放置和协同定位处理410来增强。
[0066] 闪存没有容量受限的RAM那么贵并且对于被用作二级高速缓存也比添加额外的 RAM好。关于使化doop对查询和迭代计算更快的大量最近的工作在很大程度上依赖于非常 大的RAM尺寸。闪存可W比RAM实现高得多的性能/$，因为它允许W低得多的成本得到比RAM 高得多的容量。闪存也比硬盘节能和与能源成比例得多；另外，在能量成本的降低对总体拥 有成本具有显著影响的地方，使之成为用于在大数据群集中进行存储的有吸引力的选择。 此外，对于存储映射化简作业(Map Reduce job)的映射输出，闪存是非常期望的，并且使得 导致显著数量中间数据的排序和其它基准的性能增加3倍。总体而言，闪存的高性能、小占 用面积、低功耗、下降的价格和非易失性使其作为大数据集群中的存储层/高速缓存是非常 期望的。
[0067] 图5示出了根据实施例的表如何可W被逻辑地表示为单个FlashQueryFile文件/ 布局304,其（由Flash如eryFile 80)被分割(存储)成跨节点/群集10中的计算机系统/服务 器12散布的多个分布式文件系统(DFS)块。虽然图5示出了存储在存储器28中的文件块301， 但文件块301代表跨节点/群集10中的多个计算机系统/服务器12分布的各种文件块301。如 下面所讨论的，图5还强调存储在闪速存储器75中的元数据标头。
[0068] 因此，FlashQueryFi Ie文件/布局304中的列被水平地划分成多个行组，每个行组 都包含可配置数量的行。文件块301包含多个行组。FlashQueryFiIe 80在S个不同的层次 维护元数据标头：1)称为RCHeader的块级标头，2)称为RGHeader的行组级标头，W及3)称为 ColHeader的列级标头。标头（即，RCHeader 310、RGHeader 315和CoWeader 320)维护用于 方便对必要数据的快速随机存取并允许细粒度的数据跳过的数据结构。元数据标头 RC胎ader 310、RGHeader 315和Co化eader 320每个都包括如下元数据：该元数据可W被 Flash如eryFile 80读取W便在执行查询时（例如，查询的选择阶段/部分)确定何时跳过整 个文件块（W及然后移到下一个文件块）、跳过行组（W及然后移到下一个行组)和/或跳过 列（W及然后移到下一列）。作为例子，示出选择列325、低基数投影列330和非常高基数投影 列335。
[0069] (文件块)RC胎ader 310包含文件块中行组的个数(n_rgs)和版本号，版本号在部 署的生命期间帮助FlashQueryFile 80软件跨文件块结构的各种版本维护向后和向前的兼 容性。RG化ader 315标头包括文件块中行组的开始的偏移量(rg_offset)(或者rg_偏移量） 和文件块中行组的尺寸(rg_size)(或者rg_尺寸）DRGHeader 315还包含行组中存在的行和 列的数量。例如，如果行组的尺寸被配置为对文件块是1000万，则rg_rows(rgJf)字段将包 含1000万作为值。
[0070] Co化eader 320维护用于文件块中各种可能的列布局的文件偏移量指针。列的字 典的文件偏移量和尺寸被分别维护在u_offset(u_偏移量)和u_size(u_尺寸）中。对于为快 速投影和选择而充分利用字典(例如，选择字典和/或投影字典）的FlashQueryFile布局填 充u_of f sedPu_si ze字段。l_of f set (IJ扁移量)和l_s ize (1_尺寸)字段包含在投影优化布 局中使用的查找结构的文件偏移量。字段toff Se t (dj扁移量)和i ze (d_尺寸)包含被原 样存储的列的数据的文件偏移量(例如，具有基数=1的列被原样存储而无任何字典）。如由 FlashQueryFi Ie 80执行的，箭头：341、：342、：343、：344、：345、：346、：347、：348、：349、350、351、352、 353、354示出了元数据标头的关系和使用。箭头341-354示出了在文件块301中偏移量字段 和该偏移量字段指向的数据结构之间的关系。
[0071] 所有结构中的数据类型都已经被仔细地选择，从而保持合理的空间效率。 Flash如eryFile 80在Flash如eryFile文件304中维护（由摄取算法102决定的）两个数据布 局：一个优化用于查询的选择阶段/部分并且另一个优化用于查询的投影阶段/部分。虽然 谓词值W及列的次序和数量跨特设查询变化，但一些列往往作为投影或选择列是流行的。 例如，在TPCH数据集中，两个列，L_EXTEND抓PRICE (未示出）和1_01SCOUNT，是最流行的投影 列。它们的流行是直观的，因为TPCH被建模为金融基准;运些数值列处理金钱并且聚合只能 对数值发生。具有日期类型的列，诸如L_WIPDATE(图2B中），作为选择列是非常流行的，因 为日期通常是分析查询中的重要方面。类似地，主键(prima巧key)和外键(foreign key) 是流行的选择列。Flash如eryFiIe 80为列数据提供S种数据格式:优化用于流行的选择列 的快速选择的一种格式，优化用于流行的投影列的快速投影的另一种格式，W及第=种格 式是用于被用作投影和/或选择列的列的混合布局（在查询中不同的时间）。缺省布局是混 合格式，其中，为了比混合布局更好的空间效率，管理员和/或(Flash如eryFi 1 e 80中的）预 测器模块可W选择"仅选择"或"仅投影"布局。行业跟踪的早期分析已经发现，即使在特设 分析查询中，选择列的集合也保持非常可预测。通过运种观察的指导，FlashQueryFile 80 (经由摄取算法102)可选地允许用户和/或查询引擎将表中的一些列标记为如下列:仅投影 列、仅选择列和/或投影列和选择列的组合。因此，FlashQueryFi Ie 80(经由摄取算法102) 为了（在Flash如eryFile文件304中）空间效率而在其数据布局决定中充分利用用于运种信 息的因素（即，在表中被标记为仅投影列、仅选择列和/或其组合的列的那些列）。摄取时间 算法102在下面的表1中描述。应当指出的是，主键是唯一识别行的一列或一组列。每个表应 当有主键，并且表不能有多于一个主键。主键特性可W被指定为列定义的一部分，如在表的 第一列中，或者它可W被指定为CREATE TA化E语句的单独子句。外键是一个表中的一列或 一组列，其值必须匹配另一(或同一)表的主键中的值。外键被认为是引用其主键。外键是用 于维护数据完整性的机制。
[0072] 表1:闪存优化的摄取算法
[0073]

「00751
[0076] 图6示出了表中具有数据值的列和行的原始关系401(数据库表"lineitem")。该表 被FlashQueryFile 80摄取到计算机系统/服务器10中，W便为闪速存储器进行优化。该表 不存储在原始关系中。该表的块作为文件Iineitem 601存储。当行被摄取到计算机系统/月良 务器10中时，串行器构建块，并且文件系统跨一个或多个系统/服务器10在群集上散布块。
[0077] 图7示出了用于可变尺寸的流行投影列的(基本)选择优化布局。从图6中的表的原 始关系401，图7中所示的选择优化数据布局402(通过用于存储的FlashQu&ryFile 80)已被 设计为在选择子句/部分期间（例如，包含谓词的子句)方便快速谓词匹配并减少数据读取。 对于每个可能的选择列，FlashQueryFile 80提取在列的每个行组中出现的独特值并且在 选择字典403中连续存储独特值。列标头维护到独特值的起始的偏移量(off)。接下来，对于 每个值，Flash如eryFile 80存储其中每个独特值在列中出现的行位置的集合的偏移量450 (缩写为off和/或0)和长度（即，尺寸）（未在图7中示出，但在图5中示出）。最后， FlashQueryFile 80在行位置指定405中存储用于每个独特值的行位置的集合。偏移量450 对应于用于个别独特值的行位置的每个收集/分组的位置。在元数据标头中， Flash如eryFile 80还对每个行组的列中的条目的maximum ,minimum、mid、average和count 保持跟踪(存储）emaximum指最大值，minimum指最小值，mid指中间值，average指列的每个 行组中出现的平均值。count指列的行组中行的数量。与图6中原始关系表401相比，选择优 化数据布局402是存储列Cl而不必重复相同数据值的存储的不同方式。
[0078] 大数据文件系统群集通常具有充当数据节点的多个服务器并且文件在摄取时被 分割成块并跨该群集散布。每个块在数据集中包含可配置数量的行。在一种实施例中， FlashQueryFile 80将块分割为两个子块，其中一个子块包含被确定为合适闪存的流行列 的子集，并且第二个子块包含剩余的列。
[0079] 诸如闪存(Flash)的高性能、可随机存取的存储设备比皿D昂贵得多并且具有更小 的容量。而且，闪存提供比皿D高10-1000倍的随机lOP，而顺序带宽只比HDD高3-7倍。因此， 在闪存上放置仅要被顺序存取的数据比放置要被更多地随机存取的数据会实现更低的每 美元性能。不是所有的流行数据都会通过放置在高性能、可随机存取的层上而产生高的每 美元性能。实施例设及仔细选择要放置在最有益的层上的列数据块W便获得最佳每美元性 能的放置决策机制，其中块可W针对不同存储器类型（即，皿D和SDD/闪存）的索引节点 (inode)数据结构而被协同定位。
[0080] 用于大型数据库的历史和运行时查询信息也可被用来选择列的每个块存储在其 上的存储设备。历史查询信息包括查询中列的每个块的使用类型(例如，select子句（即，投 影），where子句（即，选择），加入(join)，等等），查询的选择性，等等。历史查询信息被用来 创建查询间和查询内列块关系图，其中边定义查询中任意两列之间的选择/投影/加入关 系。每个关系边具有与之关联的权重，该权重是通过使用寻求最大化接受容量约束的查询 的每美元性能的优化算法来确定的。在其中不存在历史查询日志的实施例中，（基于列块 的）列关系图是基于进入的查询在运行时构建的。在摄取时，列关系图被排名并且每个列块 被分配得分。得分越高的列块被放在越高性能的存储设备上。
[0081] 用于存储大型数据库的多层企业存储系统可W包括与第一存储设备和第二存储 设备通信的计算机系统(例如，计算机系统/服务器12(图1))。第一存储设备可W包括一个 或多个高性能、可随机存取的存储设备，诸如闪存，而第二存储设备可W包括一个或多个低 性能的存储设备，诸如HDD。计算机系统被配置为接收包括例如大型数据库的工作负荷，并 且还被配置为在第一存储设备和第二存储设备每一个上面存储大型数据库的至少一列的 块。在一种示例性实施例中，块可W在（1 ineitem 601的）索引节点1110(图11)上协同定位 并且在第一存储器设备(例如，S孤数据块1121)和第二存储器设备(例如，HDD数据块1120) 上分层。在示例性实施例中，基于列块的属性和基于任何可用的历史和运行时查询信息来 确定列的每个块应当存储在第一存储设备和第二存储设备当中哪一个上。
[0082] 在示例性实施例中，对于更有可能被随机存取的大型数据库的列的数据块被存储 在第一存储设备中并且更有可能被顺序存取的列的数据块被存储在第二存储设备中。例 如，如果列（即，查询的选择子句中的列）的一个或多个数据块具有低基数，则它将主要受益 于被顺序存取，因为大量的行位置会匹配谓词并且因此应当被存储在第二存储设备中。另 一方面，列的具有高基数的一个或多个数据块只会匹配几行，因此具有更多机会被随机存 取并且被存储在第一存储设备上。在一种或多种实施例中，通过将更可能被随机存取的大 型数据库的列的数据块仅存储在第一存储设备中，由第一存储设备实现的每美元性能增益 可W被最大化。
[0083] 在示例性实施例中，也可W基于第一存储设备和第二存储设备的特性来确定大型 数据库的列的哪些块要存储在第一存储设备上。第一存储设备和第二存储设备的特性可W 包括但不限于，顺序存取时间、随机存取时间、容量、等待时间，等等。在一种实施例中，如果 大型数据库的列的数据块有可能被随机存取，那么，如果确定数据块将超过第一存储设备 的容量的阔值百分比，则它们不能被存储在第一存储设备上。在一种或多种实施例中，第一 存储设备和第二存储设备的性能特性是非常不同的，并且选择在哪个设备上存储列的每个 数据块被设计为利用运些差异。
[0084] 在一种或多种实施例中，大型数据库的列的每个数据块可W被计算机系统基于查 询内和查询间加权列关系图的排名给予得分。在一种或多种实施例中，得分表示通过将列 的数据块存储在第一存储设备而不是第二存储设备上将会实现的每美元的可能性能增益。 然后，基于对于列的每个数据块的得分、每个列数据块的尺寸和第一存储设备的容量来选 择要被存储在第一存储设备上的列的数据块。采用高性能存储设备的常见方法是将经常存 取的、流行的数据块放置在运种设备上。但是，运种单纯的（naive )技术不产生最佳的每 美元性能。因此，在一种或多种实施例中，并不是所有流行的列数据块都将被放在第一存储 设备中。例如，如果第一存储设备是闪存，则被非常频繁地但是W顺序方式存取的列的数据 块可能不具有被选择用于将其存储在第一存储设备中的足够高的得分。通常被投影的列数 据块比通常在查询的选择侧的列数据块被分配更高的权重。通常在选择子句中出现的列数 据块的信息的部分(诸如独特值的字典)缺省地保存在第一存储设备上。排名将仅确定列数 据块的包含用于每个独特值的行位置的剩余部分的放置。
[0085] 图8示出了根据实施例的用于生成可被用来指引运行时列块数据放置决定的预测 模型的过程800的流程图。在一种或多种实施例中，可W基于用于大型数据库的历史和运行 时查询信息来确定列的每个数据块应当存储在多层企业存储系统的哪个存储设备上。如在 方框802处所示，过程800通过接收包括要存储在多层企业存储系统中的大型数据库的工作 负荷开始。接下来，如在决定方框804处所示，过程800包括确定对该工作负荷是否存在历史 查询日志。如果存在历史查询日志，则过程800前进到方框806，并且分析针对该大型数据库 的历史查询的查询日志。接下来，如在方框808处所示，过程800包括基于分析创建查询间和 查询内加权列关系图。在一种或多种实施例中，查询中的每列基于其在"selection"(选 择）、"projection"(投影)或"join"(加入)子句中的出现而连接到同一查询中的其它列。例 如，都出现在投影子句中的两列将由"select-select"(选择-选择)关系进行连接。如果一 列出现在"SeIection"子句中而另一列出现在"pro jection"子句中，则它们将由"seIect- Where"(选择-地点）关系进行连接。如在方框810处所示，过程800还包括基于旨在对训练窗 口中的查询最大化每美元性能的优化算法向列关系图分配权重。
[0086] 如果历史查询日志不存在，则过程800前进到方框812,并且在运行时期间通过解 析进入的查询而创建列关系图形式的预测模型。在一种或多种实施例中，对于"select"(选 择)子句（即，正被投影的列），将评估由具有该选择子句中的列的历史和运行时查询检查/ 投影的行的分布。如果由选择子句检查的行的百分比低，则其指示列仅在期望的行位置处 可W通过被随机存取而获得性能。但是，如果由选择子句检查的行的百分比高于选择性阔 值，则其指示该列应当被顺序存取。如在方框814处所示，过程800还包括利用新进入的查询 信息更新列关系图。
[0087] 因此，在一种或多种实施例中，有可能（stand to)通过被随机存取而获得性能的 投影列将被分配更高的权重，使得它们具有让其数据块存储在第一存储设备上的更高机 会。另一方面，将被顺序存取的列将被分配较低的权重，使得其数据块将具有被存储在第二 存储设备上的更低机会。
[0088] 在一种或多种实施例中，分析查询日志包括在大型数据库的列之间建立查询内关 系图并且基于关系对性能的贡献向每个关系或者所连接的列之间的边分配权重。一旦权重 被分配，列就基于得分被排名，该得分是进入的边的权重之和。在一种或多种实施例中，通 过建模由历史日志中每个查询中的每列所经历的性能并最大化接受约束(诸如第一存储设 备的尺寸)的性能来确定权重的值。
[0089] 在一种实施例中，如果列被认为作为投影列是流行的并且查询日志指示在设及该 列的查询中通常检查低百分比的行，则将该列的数据块放置在第一存储设备中相较于将该 列的数据块放置在第二存储设备中将导致性能提高。此外，如果第一存储设备允许高IO并 行化，则将列的数据块放置在第一存储设备中相较于将该列的数据块放置在第二存储设备 中将导致甚至更多的性能提高。在另一实施例中，如果列被认为作为投影列是流行的并且 查询日志指示在设及该列的查询中检查高百分比的行，则与将该列的数据块放置在第二存 储设备中相比，将该列的数据块放置在第一存储设备中将导致较少性能增益（即，作为第一 存储设备的闪存与作为第二存储设备的皿D相比的顺序带宽中的差异因子）。运种试探法指 导由放置算法使用的查询内列图中的权重分配。
[0090] 在一种实施例中，用于在大型数据库创建过程中将该大型数据库的列的数据块预 测性地放置在多层企业存储系统中的过程包括接收包含要存储在多层企业存储系统中的 大型数据库的工作负荷。该过程包括评估大型数据库的列的一个或多个属性。加权列关系 图被排名并且列的关联排名被用来指导将其数据块放置在存储层次结构中。该过程还包括 基于一个或多个属性确定大型数据库的列的每个数据块是应当存储在多层企业存储系统 的第一还是第二存储设备上。在一种或多种实施例中，还可W基于该多层企业存储系统的 存储设备的一个或多个特性确定列的每个数据块应当存储在多层企业存储系统的哪个存 储设备上。
[0091] 在一种或多种实施例中，在大型数据库已加载到多层企业存储系统之后，计算机 系统将监视大型数据库的使用并且将周期性地在第一存储设备与第二存储设备之间移动 大型数据库的列的数据块。因此，计算机系统将会基于进入的分析查询对列数据块的流行 性W及运行时中列之间的关系的变化作出反应。列内关系图和列排名将对由运行时查询呈 现出的模式作出反应而改变。未来的数据块放置决定也将相应地改变。
[0092] 预测列放置闪存比HDD更昂贵并且具有更小的空间。为了证明闪存的较高成本是 有道理的，重要的是将列的数据块的正确子集放在产生最高性能/$的闪存中。不是所有列 数据块都一样，并且通过放置在闪存中不会产生相同性能八。因为对于随机I0P，闪存比HDD 快40-1000倍，而对于顺序存取只快2-7倍，因此当数据被随机存取时，闪存产生最高的性 能/$。与将只被顺序存取的列的数据块相比，放置将有可能被随机存取的列的数据块对利 用闪存将更划算(bang for the buck)。
[0093] 跨闪存层和皿D层分割列数据块的单纯方式是将流行的列数据块放置在闪存层 中。即使在具有高百分比的特设查询的工作负荷中，一些列数据块也固有地跨查询或者作 为选择或者作为投影列数据块更流行。虽然谓词值W及列的次序和数目跨查询而改变，但 是一些列确实往往比其它列作为投影或选择列出现更多。
[0094] 在一种或多种实施例中，本文所述的过程在多层存储系统中使用预测列数据块放 置模型，该预测列数据块放置模型除了考虑列数据块的流行性，还考虑到几个额外的因素， W便跨查询产生最佳的性能/$。考虑列数据块的各种属性，诸如它们的基数、排序次序、稀 疏性及其列数据块分层决定中的尺寸。此外，通过分析历史(如果可用的话)和运行时查询 日志来执行训练放置模型。如果历史查询日志不存在，则过程利用运行时查询的可配置窗 口来训练运行时模型。利用查询日志创建查询内和查询间加权列关系图并且利用优化算法 分配权重，该优化算法考虑列数据块特性及其通过被放置在闪存上而对增强性能/$的影 响。
[00M]或者在历史或者在运行时查询日志中的可配置数量的查询可被用于训练预测列 数据块放置模型。针对查询窗口内的所有查询创建查询内和查询间列关系图。列之间的关 系可W是选择-选择、投影-选择或者投影-投影。因为选择算法有可能从被放在闪存中获益 最大，因此较高的权重被分配给投影-投影关系，并且如果任何一个投影列不放在闪存上， 则放慢(bring down)查询。因为将一些列数据块部分地放置在闪存中不影响性能，所W选 择-选择中的列获得最低的权重。每个列的排名的被特征化为：
[0096]
[0097] 其中，cardinality是列中的独特值的百分比，如果该列被排序，则sorLorder是 1，否则是0 ,popularity是在所考虑的窗口内的查询中该列出现的次数，colmm_type指定 列在查询中被使用的方式并且对于选择列是0,对于投影列是1，并且如果列W两种方式都 使用则是2。在求和中，j属于与i处于对应关系（SS表示选择-选择，SP表示选择-投影，并且 PP表示投影-投影)的邻居的列表。关系的权重依赖于训练数据中查询的选择性。
[0098] 在一种或多种实施例中，如果查询的选择性低（即，很少行位置匹配谓词），则投影 算法对该行位置的文件偏移量进行点存取，W读取投影列的值。运变换成随机存取W及将 投影列数据块放置在闪存中产生每美元高性能增益。另一方面，如果查询的选择性高，并有 大量行位置匹配谓词，则投影算法回到顺序模式，其中投影算法群集行位置并且从投影列 读取大块的数据。将投影列数据块放置在闪存中将不产生如前一场景中那么高的每美元性 能增益。因此，查询的选择性对闪存中列数据块的性能有影响。
[0099] 对于每个查询，列放置的所有可能组合的矩阵被用作独立的变量。例如，如果查询 具有7列，则有128种可能的列数据放置组合，甚至具有更多的列数据块组合。列被表示为二 进制，其中1表示放在闪存上并且0表示放在盘上。在查询等待时间（即，基线查询等待时间/ 分层查询等待时间）中观察到的加速和放置的成本构成从属变量。列放置组合的成本简单 地就是闪存中其用于列放置的尺寸*闪存存储器/GB的成本和假设要放在盘上的列的尺寸* 盘/GB的成本的因子。每种列组合对查询性能的影响（即，加速)针对查询窗口内的每个查询 建模。除了列的特性和查询的选择性，在建模时还考虑硬盘和闪存的性能特性（例如，带 宽)。
[0100] 为简单起见，假设查询等待时间是存取查询中每个个别列所需的预期时间之和。 令C = Cl，C2, ... ,Ck是查询中出现的列。
[0101]
(2)
[0102] 令yi是表示列Ci是放置在闪存中还是放置在皿D中的标记。
[0103]
(3}
[0104] 性能建模是基于早先讨论过的选择和投影算法。如果Cl驻留在闪存上并且是选择 列，则查询等待时间如下计算：
[01 化]Eki] = (^cardinalit yi*RGsize+selectivity(q)*4/BWfiash [0106] (4)
[0107] 根据选择算法，每个行组被并行处理，并且首先从每个行组读取对应于 cardinalityi*RG size的独特值，并且然后读取对应于selectiVity(q)*4的匹配行位置， 其中selectivity(q)是被建模的查询的选择性并且4是每个行位置的尺寸。基线查询性能 是通过利用盘带宽数顺序读取查询中的每一列来确定的。
[0108] 如果驻留在闪存上并且是投影列，则查询等待时间如下计算：
[0109] E[ci] = selectivity(q)*fieldsizei/BWfiash (5)
[0110] 其中，selectivity(q)是查询的选择性并且fieldsizei是列Ci的字段尺寸。运是投 影算法的近似。
[0111] 如果i驻留在盘上，则与利用现有技术算法的情况一样，它被整体读取。Eki] = sizei/BWhdd，其中Sizei是文件中列的总尺寸。所得到的矩阵被优化，W产生列的有序集合， 当该有序集合被放在闪存上时，为所有查询产生最大加速，同时最小化成本。然后，所得到 的列集合被用来利用回归分析确定系数$\曰1地3$等的值。排名等式被用来确定出现在数据 集中的每个新列的排名，W确定其在存储层次结构中的放置。列被排名并且列排名在确定 列在闪存中的放置时使用;最高排名的列被放置在闪存中。在每一轮训练中，查询图利用窗 口中的查询重新生成并且系数被重新确定，W确保预测模型的通用(州rrency)。
[0112] 在数据库初始创建时，并且在缺少用于类似数据库的历史查询日志的情况下，自 举放置算法基于观察到的列特性和试探法确定列的初始放置。在第一步中，被摄取的可配 置数量的行被缓存在存储器中。从缓存的行学习特性(例如，基数、排序次序，等等）。
[0113] 在一种或多种实施例中，自举算法还需要知道列作为选择或投影列的潜在用途。 自举算法还尝试找出列的潜在流行性。潜在的流行性列可W W多种方式进行：1)由用户提 供的提示，2)从数据集、字段类型、名称获取的见解，从应用获取的通告，等等。例如，在表 中，主键和外键倾向于在大量查询中出现，并因此是固有地流行的选择列。在财务数据集 中，具有货币属性的列（例如，税、折扣、价格、工资，等等）往往是用于聚集查询 (aggregation query)的流行投影列。例如，在根据财务数据集建模的TPCH数据集中，在 line item表中，l_discount和Lxtendedprice是最流行的投影列。
[0114] 然后，试探法被用来基于先前确定的特性来确定列的放置。试探法由投影和选择 算法通知。为了 了解试探法背后的直觉知识，描述由选择算法通知的选择列的放置决定。算 法中的第一部分设及用于执行谓词匹配的独特值的顺序读取。由于第二部分设及为匹配谓 词的每个值读取行位置blob,因此其具有多得多的随机存取的可能。如果行位置blob尺寸 小并且如果大量独特值匹配谓词，则算法的第二部分导致大量的随机存取。当列的基数高 时，发生运种场景，并且在闪存中放置列数据块将产生选择算法的更高的每美元性能。另一 方面，如果行位置blob尺寸非常大，则在谓词匹配后提取行位置blob导致少量的大顺序存 取;运是在列具有低基数的情况下的典型的场景。将运种列数据块放在闪存中允许选择算 法的较低的每美元性能。列的尺寸也在每美元性能产出中起到类似的作用。在列具有高基 数的情况下放置试探法排名更高。
[0115] 图9示出了根据实施例的将块910分割成子块920、922的例子。在一种实施例中，块 910和关联的子块920和922利用文件IineitemSOl进行分割。然后，关联的子块920和922在 SDD或闪存层930和HDD层940中在服务器12上协同定位。在一种实施例中，当行保持被摄取 到数据库表401中时，FlashQueryFile 80的FlashQue巧FiIe串行器构建文件系统块。 FlashQueryFile串行器将每个文件系统块910分割成两个子块920和922: -个子块(子块 920)包含闪存-最佳流行列的子集和可配置数量的行，并且另一个子块(子块922)包含数据 库表401中剩余的列和与另一子块相同数量的行。
[0116] 图10示出了根据一种实施例的将服务器（SI和S2) 12上的来自图6被存储为 Iineitem文件601的表的子块放置到闪存75的SDD或闪存块和HDD 34的HDD块中。在一种实 施例中，Flash如eryFile串行器使用块级处理410的由服务器/系统12的底层文件系统暴露 的提供用于Flash如eryFile串行器的API(图4)来将两个子块(例如，子块920和922,图9)和 它们的存储层通告传递到文件系统。此外，块级处理410的API向文件系统提供用于两个子 块的协同定位通告-该协同定位通告建议文件系统将两个子块放在同一个服务器12上;但 是，放在存储器块的不同层中（闪存层930/闪存块和皿D层940/皿D块）。
[0117] 在一种实施例中，文件系统接收调用Write(子块1，层=闪存，子块2,层=HDD,协 同定位=真）。然后，文件系统定位在闪存层930/闪存块上具有用于子块1(例如，子块920) 的足够空间并且在皿D层940/皿D块上具有用于子块2(例如，子块922)的足够空间的服务器 12。一旦服务器12被定位，文件系统就将子块1放置在闪存层930/闪存块上并将子块2放在 皿D层940/皿D块上。
[0118] 基于上面定义的算法来确定化AP数据库中的流行列（只读，并且数据只附加到 表）。该算法在确定通过放置在SSD中而将优化性能的列（基于列是将被顺序还是更随机地 存取)之前考虑几个因素，诸如尺寸、基数、数据分布，等等。根据实施例，除了对千兆兆字节 数据的OLAP类型的用例(use case)，还有其它几种激励用例用于在GPFS和GPFS-FPO环境中 都执行块级分层。块协同定位跨所有用例可能或可能不需要。下面的例子提供了其中块协 同定位可能重要的用例:在化doop环境中，在诸如RCFile的常见DB文件格式中，表被表示为 单个文件并且跨数据节点被分割。每个文件系统块包含固定数量的行。在一种或多种实施 例中，块被分成将包含SSD友好的流行列的一块和将包含剩余列的另一块。在一种实施例 中，同一数据节点上运两个分割块的协同定位由于许多原因而是重要的。如果查询设及两 种类型的列，则对HDD层上的列的存取不应当招致额外的网络等待时间（如果块被放在另一 个节点上，运将会发生）。由于两个块共同驻留在该数据节点上，因此它们都可W由相同的 映射任务处理。运对于性能将是重要的。如果其碎片目前被放在SSD上的行不再重要，贝U GPFS可能需要执行块的迁移。因为行可能再次流行并且可能需要执行向上分层返回到SSD 层，因此维护块之间的协同定位信息将是重要的。在一种实施例中，协同定位信息有助于在 同一数据节点上的正确层上放置数据块。在一种实施例中，在重新划分的情况下，分割的块 需要被一起移动。
[0119] 在hadoop环境中，OLAP表被W多个文件格式存储，例如，RCFile(混合行/列）、 ORCFile(优化行/列）、CIF(列），等等。文件被分成跨群集散布的块。每个块包含n个行组。查 询引擎使用算法将RCFile块分成两块-一块具有流行的列元数据和数据并且另一块具有不 流行的列元数据。在一种实施例中，查询引擎通过W下与底层文件系统接口，同时创建并加 载RCFile:提供提示W将流行的列块放在SSD池上并且将不流行的列块放在HDD池上；W及 指定用于行组的流行/不流行列块被放置在同一数据节点上的约束。在一种实施例中，因为 来自不流行的列的数据可W从同一节点上的HDD提取而不招致网络成本，因此在同一节点 上协同定位对性能是非常重要的。在一种或多种实施例中，FS需求包括:对文件跨存储池的 块级分层的支持;对用于让应用对数据放置提供通告和约束的机制的支持；W及对在摄取、 重新划分、迁移和向上分层期间维护流行和不流行块之间的关系并且共同放置它们的支 持。
[0120] 常规系统具有包括W下的存储级:非常少的语义信息；只有块的视图；粗粒度的决 策;没有关于进入的数据在正确的层上的前期、最佳放置的摄取时间决定，因为它们本质上 主要是反应式的；HSM:在文件系统的外部；依赖存根(S化b)(例如，重新分析点，EA)来捕获 到另一层的数据移动；单纯文件系统级分层:文件系统支持存储池化孤，SSD，等等)并基于 策略跨池移动文件;所有现有的文件系统(例如，GPFS、EMC的化eFS、Sto曲ext,等等)在整个 文件级执行文件系统分层，其中同一文件的不同块不能被放在不同的池上。大多数现有的 方法(例如，Easy Tier)在摄取之后的时间被执行并且本质上是反应式的，由此，一旦系统 认识到数据块中的一些被频繁存取，运些块就被移动到SSD层中。其结果是，常规系统不能 提供前期性能保证。运些系统在系统堆找中也低级得多并且没有可用于诸如文件系统的应 用或更高层的语义知识。其它系统（例如，VerticaFlexStore)依靠用户对流行的列提供提 示，并且将运种列放在SSD层上。运种系统有几个问题：1)用户可能甚至认识不到所有流行 的列，并因此，运种提示是不全面的，2)如果流行性度量随时间改变，则运种静态方案不能 捕获该变化，W及3)仅仅在SSD中单纯地放置所有的流行列可能甚至不可行，因为SSD的容 量有限，并且因此，重要的是W选择或投影子句中列尺寸、预期选择性和列的存在性为准来 优化流行列的放置。其它非分层解决方案依赖于近似查询处理来减少查询等待时间。在存 储器中维护底层表的元组的高速缓存样本。
[0121] -种或多种实施例利用应用具有关于其数据的最多语义知识并且可W连同必要 的查找信息一起分配和打包具有对SSD最适合的数据的数据块的事实。在一种实施例中，一 种机制被用来向文件系统传递通告，W便将进入的文件块放置在特定的层/存储池上;对于 数据块协同定位指定约束;索引节点结构被修改，W支持文件内分层;利用修改后的索引节 点结构指定两个块之间的关系。
[0122] -种或多种实施例允许应用在文件摄取本身的时候对将数据块放置在期望层上 进行控制，运提供了前期性能保证。一种或多种实施例允许文件系统:如果一些块呈现比其 它块更高的热度，则向上分层运些块，并且，或者利用应用的通告或者响应于块热度变化而 反应性地主动复制一些块。
[0123] 在一种实施例中，应用为块分层提供通告和约束，并且文件系统选择对在它们各 自的层上的块都具有空间的数据节点。文件系统为索引节点中的块创建条目并且表示索引 节点中块之间的关系。在一种实施例中，有效的文件内分层不同于文件跨层的文件过渡迁 移或失败的迁移。一种或多种实施例维护跨文件迁移、重新划分等的协同定位，W确保应用 约束被兑现。
[0124] 图11示出了根据实施例的文件内块分层和协同定位的例子1100。在一种实施例 中，Iineitem文件601(图6)的索引节点1110具有用于支持文件内级块分层和协同定位的子 块关系的结构。在一种实施例中，通过在索引节点1110中添加块的SSD或闪存块列表1120中 的子块920的信息或块的皿D块列表1130中的子块922的信息，更新Iineitem文件601的索引 节点1110。在一种实施例中，两个子块920和922之间的关系1140被记录，W说明两个子块 920和922包含互补的信息。在一种实施例中，在随后的迁移、重新划分等期间使用运种关 系。
[0125] -种或多种实施例利用用于皿D和S孤上两个子块的分层（即，文件内块分层)在索 引节点1110上协同定位来自同一文件的文件块（即，文件内块协同定位），W用于提供文件 内块组织的存储放置。在一个例子中，来自文件的第一子块920作为HDD数据子块被分层并 且来自该文件的第二子块922作为闪存或SDD数据子块被分层，从而用于文件内块分层。 OLAP数据库中的流行列（只读，并且数据只附加到表)可W基于上述算法来确定，该算法在 确定通过放在SSD或闪存分层中而将优化性能的列(基于列是将被顺序还是更随机地存取） 之前考虑几个因素，诸如尺寸、基数、数据分布，等等。在一种实施例中，修改算法W确定列 子块分层，并且来自同一文件的子块针对索引节点1110协同定位，W用于提供文件内块协 同定位。
[01%] 除了对千兆兆字节数据的OLAP类型的用例，还有用于在GPFS和GPFS-FPO环境二者 中执行块级分层(文件内块分层)的几种其它激励用例。子块协同定位跨用例可能或可能不 需要。下面的例子提供了其中文件内子块协同定位可能重要的用例。在化doop环境中，在诸 如RCFile的常见DB文件格式中，表被表示为单个文件并且跨数据节点被分割。每个文件系 统块包含固定数量的行。在一种实施例中，块被分割/划分成将包含闪存/SSD友好的流行列 的一个子块和将包含剩余列的另一子块。在运种示例实施例中，由于W下的许多原因运两 个分割的块在同一数据节点上的文件内块协同定位是重要的：1)如果查询设及两种类型的 列，则对皿D层上的列的存取不应当招致额外的网络等待时间（如果块被放在另一个节点 上，运将会发生）。因为两个块它们共同驻留在该数据节点上，因此它们都可W由相同的映 射任务处理，运对于性能是重要的；2)如果其碎片目前被放置在SSD上的行不再重要，贝U GPFS可能需要执行块的迁移。维护因为行可能再次流行并且可能需要执行向上分层返回到 SSD层，因此维护块之间的协同定位信息将是重要的。协同定位信息有助于在同一数据节点 上的正确层上放置块;3)在重新划分的情况下，分割的块需要被一起移动。
[0127] 不是所有的块在文件中都一样并且一种或多种实施例将层（例如，SDD或闪存和 皿D层)的性能与存储在文件块中的数据的重要性匹配。查询引擎具有关于表中各个列的相 对重要性的多得多的语义信息并且可W W运样一种方式创建块:流行的被存取列信息/元 组和索引被合并到文件块中。运种块将是针对闪存/SSD或类似运种更快的层的更大匹配。 为了确保性能，在同一节点中协同分配具有用于匹配行组的剩余列的子块也是重要的。诸 如Easy Tier的大多数分层解决方案在系统堆找中低级得多并且没有可用于诸如文件系统 的应用或更高层的语义知识。GPFS目前提供跨存储池的分层;但是，就像对于一种或多种实 施例，分层仅仅是在文件级并且不在文件内块分层级。
[0128] 图12是根据实施例的示出用于在文件系统中的文件内块组织存储放置的过程 1200的框图。在一种实施例中，在方框1210中，在文件系统中获得文件。在一种实施例中，在 方框1220中，文件被分成多个块(例如，2个或更多个）。在方框1230中，多个块中的每个块被 分成至少两个相关的子块。在方框1240中，在文件系统元数据布局中为所述至少两个相关 的子块确定在不同存储器设备上的文件内块组织的存储放置。在一种实施例中，过程1200 可W提供为至少两个相关的子块确定在不同存储器设备上的文件内块分层。在一种实施例 中，过程1200可W包括为至少两个相关的子块确定在不同存储器设备上的文件内块协同定 位。在另一实施例中，过程1200可W提供为至少两个相关的子块确定在不同存储器设备上 的文件内块分层和协同定位。
[0129] 在一种实施例中，为了为用于多个块中的每一个的至少两个相关的子块确定在不 同存储器设备上的块存储放置，过程1200还可W确定文件系统中的应用通告。在一种实施 例中，修改后的索引节点结构支持文件内块分层并且包括条目，该条目包括指示驻留在文 件系统中同一数据节点服务器上的分层子块之间的协同定位关系的信息。在一种实施例 中，过程1200可W在文件摄取时提供在期望层上的应用控制块放置，W用于提供前期性能 保证。
[0130] 在一种实施例中，过程1200还可W包括确定至少两个相关子块当中用于目标针对 第一存储器层的文件的第一子块，确定至少两个相关子块当中用于目标针对第二存储器层 的文件的第二子块，并且选择具有用于在第一存储器层上的第一子块的和在第二存储器层 上的第二子块的空间的数据节点服务器。在一种实施例中，过程1200可W提供对有效的文 件内块分层与跨层的文件过渡内迁移或失败迁移的区分。在一种实施例中，过程1200可W 包括维护至少两个相关的子块之间的关系，其中一个子块包含流行列的子集且第二子块包 含剩余的列，并且在文件摄取、存储器重新划分、文件迁移和文件块向上分层期间共同放置 流行块和不流行块。
[0131] 在一种实施例中，过程1200还可W包括由应用提供用于在SSD池上放置包含流行 列的子集的子块且在HDD池上放置包含剩余列的子块的通告，并且对于指定数量的行指定 包含流行列的子集的子块和包含剩余列的子集的子块放置在文件系统中同一数据节点服 务器上不同存储池上的约束。
[0132] 如本领域技术人员将认识到的，本发明的各方面可W体现为系统、方法或计算机 程序产品。因此，本发明的各方面可W采取完全硬件实施例、完全软件实施例(包括固件、驻 留软件，微代码，等等），或者组合软件和硬件方面的实施例的形式，所有运些一般全都可W 在本文中被称为"电路"、"模块"或"系统"。此外，本发明的各方面可W采取体现在一个或多 个计算机可读介质中的计算机程序产品的形式，在该计算机可读介质上包含计算机可读程 序代码。
[0133] 可W使用一种或多种计算机可读介质的任意组合。计算机可读介质可W是计算机 可读信号介质或者计算机可读存储介质。计算机可读存储介质可W是例如，但不限于，电、 磁、光、电磁、红外线或者半导体系统、装置或设备或者W上所述的任意合适组合。计算机可 读存储介质的更具体例子(非穷尽列表)将包括W下：具有一条或多条电线的电连接、便携 式计算机磁盘、硬盘、随机存取存储器（RAM)、只读存储器（ROM)、可擦可编程只读存储器 化PROM或者闪存存储器）、光纤、便携式光盘只读存储器(CD-ROM)、光学存储设备、磁性存储 设备或者W上所述的任意合适组合。在本文档的背景下，计算机可读存储介质可W是可W 包含或者存储由指令执行系统、装置或设备使用或者与指令执行系统、装置或设备联合使 用的程序的任何有形介质。
[0134] 计算机可读信号介质可W包括在基带中或者作为载波的一部分的其中体现计算 机可读程序代码的传播数据信号。运种传播信号可W采取多种形式中的任何一种，包括但 不限于电磁、光或者其任意合适组合。计算机可读信号介质可W是非计算机可读存储介质 而且可W传送、传播或者运输由指令执行系统、装置或设备使用或者与其联合使用的程序 的任何计算机可读介质。
[0135] 体现在计算机可读介质上的程序代码可W利用任何适当的介质发送，包括但不限 于，无线电、有线线路、光纤电缆、RF等，或者其任意合适组合。
[0136] 用于执行本发明各方面的操作的计算机程序代码可W用一种或多种编程语言的 任意组合来写，编程语言包括面向对象的编程语言，例如化va、Smal 1化化、C++等，及传统的 过程编程语言，例如编程语言或者类似的编程语言。程序代码可W完全在用户的计算机 上、部分地在用户的计算机上、作为独立的软件包、部分在用户的计算机上而且部分在远端 计算机上或者完全在远端计算机或服务器上执行。在后一种场景下，远端计算机可W通过 任何类型的网络连接到用户的计算机，包括局域网化AN)或广域网(WAN),或者可W连接到 外部的计算机(例如，通过利用互联网服务提供商的互联网）。
[0137] W下参考根据本发明实施例的方法、装置(系统)和计算机程序产品的流程图说明 和/或框图来描述本发明的各方面。将理解，所述流程图说明和/或框图的每个方框及所述 流程图说明和/或框图中方框的组合可W由计算机程序指令来实现。运些计算机程序指令 可W提供给通用计算机、专用计算机或者其它可编程数据处理装置的处理器，来产生一种 机器，使得当所述指令经计算机或者其它可编程数据处理装置的处理器执行时，产生用于 实现在所述流程图和/或框图中的一个或多个方框中所指定的功能/动作的装置。
[0138] 运些计算机程序指令还可W存储在可W指示计算机的计算机可读介质中、其它可 编程数据处理装置或者W特定的方式起作用的其它设备中，使得存储在计算机可读介质中 的指令产生一种制造物品，该物品包括实现在流程图和/或框图中的一个或多个方框中所 指定的功能/动作的指令。
[0139] 计算机程序指令还可W加载到计算机、其它可编程数据处理装置或者其它设备 上，W产生要在计算机、其它可编程装置或者其它设备上执行的一系列操作步骤，从而产生 计算机实现的过程，使得在所述计算机或者其它可编程装置上执行的指令提供用于实现流 程图和/或框图中的一个或多个方框中所指定的功能/动作的过程。
[0140] 附图中的流程图和框图显示了根据本发明的多个实施例的系统、方法和计算机程 序产品的可能实现的体系架构、功能和操作。在运点上，流程图或框图中的每个方框可W代 表模块、程序段或者代码的一部分，所述模块、程序段或代码的一部分包含用于实现(一个 或多个)规定的逻辑功能的一个或多个可执行指令。在一些替换的实现中，方框中所标注的 功能也可WW不同于附图中所标注的顺序发生。例如，连续示出的两个方框实际上可W基 本并行地执行，或者方框有时可W按相反的顺序执行，运依赖所设及的功能而定。也要注意 的是，框图和/或流程图说明中的每个方框W及框图和/或流程图说明中方框的组合可W用 执行规定的功能或动作或者执行专用硬件与计算机指令的组合的专用的基于硬件的系统 来实现。
[0141] 除非明确地如此陈述，否则权利要求中对单数形式的元素的引用并非意在表示 "一个且唯一"，而是指"一个或多个"。目前本领域普通技术人员已知或W后知道的与上述 示例性实施例的元素等效的所有结构和功能要被本权利要求涵盖。本文没有权利要求元素 要援引35U.S.C第112部分第6段来解释，除非该元素明确地利用短语"用于…的装置"或"用 于…的步骤"来阐述。
[0142] 本文所使用的术语仅仅是为了描述特定的实施例而不是要作为本发明的限制。如 本文所使用的，除非上下文明确地另外指出，否则单数形式"一个"和"运个"是要也包括复 数形式。还应当理解，当在本说明书使用时，术语"包括"规定所述特征、整数、步骤、操作、元 素和/或部件的存在，但是并不排除一个或多个其它特征、整数、步骤、操作、元素、部件和/ 或其组的存在或添加。
[0143] W下权利要求中所有方式或步骤加功能元素的对应结构、材料、动作及等同物都 是要包括用于结合具体所述的其它所述元素执行所述功能的任何结构、材料或动作。已经 为了说明和描述目的给出了本发明的描述，但运不是详尽的或者要把本发明限定到所公开 的形式。在不背离本发明范围与精神的情况下，许多修改和变化对本领域普通技术人员都 将是清楚的。实施例的选择和描述是为了最好地解释本发明的原理和实践应用，并使本领 域普通技术人员能够理解本发明具有适于预期特定使用的各种修改的各种实施例。
【主权项】
1. 一种方法，包括： 获得文件系统中的文件； 将文件分成多个块； 将所述多个块中的每个块分成至少两个相关的子块；以及 在文件系统元数据布局中为所述至少两个相关的子块确定在不同存储器设备上的文 件内块组织的存储放置。2. 如权利要求1所述的方法，其中，确定文件内块组织的存储放置包括为所述至少两个 相关的子块确定在不同存储器设备上的文件内块分层。3. 如权利要求1所述的方法，其中，确定文件内块组织的存储放置包括为所述至少两个 相关的子块确定在不同存储器设备上的文件内块协同定位。4. 如权利要求1所述的方法，其中，确定文件内块组织的存储放置包括为所述至少两个 相关的子块确定在不同存储器设备上的文件内块分层和协同定位。5. 如权利要求1所述的方法，还包括为了为所述至少两个相关的子块确定在不同存储 器设备上的块存储放置而确定文件系统内的应用通告。6. 如权利要求2所述的方法，其中修改后的索引节点结构支持文件内块分层，并且包括 条目，该条目包括指示驻留在文件系统中同一数据节点服务器上的分层的子块之间的协同 定位关系的信息。7. 如权利要求5所述的方法，其中，在文件摄取时应用控制在期望层上对所述至少两个 相关子块的子块放置，以用于提供前期性能保证。8. 如权利要求2所述的方法，还包括： 为目标针对第一存储器层的文件确定所述至少两个相关子块中的第一子块； 为目标针对第二存储器层的文件确定所述至少两个相关子块中的第二子块；以及 选择具有用于第一存储器层上的第一子块和第二存储器层上的第二子块二者的空间 的数据节点服务器。9. 如权利要求2所述的方法，其中，有效的文件内块分层与跨层的文件过渡迀移或失败 的迀移不同。10. 如权利要求3所述的方法，还包括： 维护所述至少两个相关子块之间的关系，其中一个子块包含流行列的子集并且第二个 子块包含剩余列；以及 在文件摄取、存储器重新划分、文件迀移和文件块向上分层期间共同放置流行块和不 流行块。11. 如权利要求10所述的方法，还包括： 由应用提供用于在固态驱动器(SSD)池上放置包含流行列的子集的子块并且在硬盘驱 动器(HDD)池上放置包含剩余列的子块的通告；以及 对于指定数量的行指定包含流行列的子集的子块和包含剩余列的子块放置在文件系 统中同一数据节点服务器上不同存储池上的约束。12. -种用于文件内块存储器管理的计算机系统，包括： 处理器； 耦合到处理器的存储器； 存储在存储器中并由处理器执行的程序代码，以便： 由处理器获得文件系统中的文件； 由处理器将文件分成多个块； 由处理器将所述多个块中的每个块分成至少两个相关的子块；以及 由处理器在文件系统元数据布局中为所述至少两个相关的子块确定在不同存储器设 备上的文件内块组织的存储放置。13. 如权利要求12所述的计算机系统，其中： 确定文件内块组织的存储放置包括为所述至少两个相关的子块确定在不同存储器设 备上的文件内块分层。14. 如权利要求12所述的计算机系统，其中，确定文件内块组织的存储放置包括为所述 至少两个相关的子块确定在不同存储器设备上的文件内块协同定位。15. 如权利要求12所述的计算机系统，其中，确定文件内块组织的存储放置包括为所述 至少两个相关的子块确定在不同存储器设备上的文件内块分层和协同定位。16. 如权利要求12所述的计算机系统，其中，可由处理器执行的程序代码还：由处理器 为了为所述至少两个相关的子块确定在不同存储器设备上的块存储放置而确定文件系统 内的应用通告。17. 如权利要求13所述的计算机系统，其中，可由处理器执行的程序代码还： 由处理器为目标针对第一存储器层的文件确定所述至少两个相关子块中的第一子块； 由处理器为目标针对第二存储器层的文件确定所述至少两个相关子块中的第二子块； 以及 由处理器选择所述文件系统中具有用于第一存储器层上的第一子块和第二存储器层 上的第二子块二者的空间的数据节点服务器。18. 如权利要求14所述的计算机系统，其中，可由处理器执行的程序代码还： 维护所述至少两个相关子块中的包含流行列的子集的第一子块与所述至少两个相关 子块中的包含剩余列的第二子块之间的关系； 由处理器在包括摄取、存储器重新划分、文件迀移和文件块向上分层中的一个或多个 的文件系统操作期间共同放置并一起管理第一子块和第二子块； 由应用提供用于在固态驱动器（SSD)池上放置文件的第一子块并且在硬盘驱动器 (HDD)池上放置文件的第二子块的通告；以及 指定第一子块和第二子块放置在文件系统中同一数据节点服务器上的约束。19. 一种方法，包括： 获得文件系统中的文件的块； 将块分成至少两个相关的子块；以及 在文件系统元数据布局中为所述至少两个相关子块确定在不同存储器设备上的文件 内块分层和协同定位。20. 如权利要求19所述的方法，还包括： 为了为所述至少两个相关的子块确定在不同存储器设备上的子块存储放置而确定文 件系统内的应用通告； 确定用于所述至少两个相关的子块中的第一子块的第一存储器层；
【文档编号】G06F17/30GK106021268SQ201610177924
【公开日】2016年10月12日
【申请日】2016年3月25日
【发明人】R·考什克
【申请人】国际商业机器公司