CN113111038B - 文件存储方法、装置、服务器及存储介质 - Google Patents

文件存储方法、装置、服务器及存储介质 Download PDF

Info

Publication number
CN113111038B
CN113111038B CN202110352578.3A CN202110352578A CN113111038B CN 113111038 B CN113111038 B CN 113111038B CN 202110352578 A CN202110352578 A CN 202110352578A CN 113111038 B CN113111038 B CN 113111038B
Authority
CN
China
Prior art keywords
data
stored
partition
file
space occupation
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN202110352578.3A
Other languages
English (en)
Other versions
CN113111038A (zh
Inventor
李九仙
李涛
程伟
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Beijing Dajia Internet Information Technology Co Ltd
Original Assignee
Beijing Dajia Internet Information Technology Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Beijing Dajia Internet Information Technology Co Ltd filed Critical Beijing Dajia Internet Information Technology Co Ltd
Priority to CN202110352578.3A priority Critical patent/CN113111038B/zh
Publication of CN113111038A publication Critical patent/CN113111038A/zh
Application granted granted Critical
Publication of CN113111038B publication Critical patent/CN113111038B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/17—Details of further file system functions
    • G06F16/172—Caching, prefetching or hoarding of files
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/18—File system types
    • G06F16/182—Distributed file systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
    • G06F3/0625—Power saving in storage systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0638—Organizing or formatting or addressing of data
    • G06F3/064—Management of blocks
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0638—Organizing or formatting or addressing of data
    • G06F3/0643—Management of files

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Human Computer Interaction (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本公开公开了一种文件存储方法、装置、服务器及存储介质，属于存储技术领域。该文件存储方法，包括：写入待存储文件至一个或多个数据分区；获取各数据分区存储的第一数据的空间占用量；根据空间占用量以及数据块的存储容量，确定存储待存储文件所需数据块的数量；将待存储文件发送至上述数量的数据块，上述数量的数据块用于存储待存储文件。采用本公开提供的文件存储方法、装置、服务器及存储介质，至少能够有效限制小文件的生成，提高存储资源的利用效率。

Description

文件存储方法、装置、服务器及存储介质
技术领域
本公开涉及存储技术领域，具体涉及一种文件存储方法、装置、服务器及存储介质。
背景技术
目前，分布式文件系统已经得到了比较广泛的应用。以海杜普分布式文件系统(Hadoop Distributed File System，HDFS)为例，HDFS作为一种适合运行在通用硬件上的分布式文件系统，可以适用于比较多应用环境。HDFS通常以数据块为单位进行文件的存储，也就是说，一个文件可能划分为多个子文件分别存储至不同的数据块中。
Hive作为基于海杜普(Hadoop)的一种数据仓库工具，其分区表存储功能可以有效提升查询性能，因此比较多地应用在HDFS的文件存储过程中。然而，Hive的应用往往会带来大量的文件大小明显小于数据块存储容量的小文件的情况，且每一小文件通常需要占用一个数据块，如此，导致了HDFS中存储资源的浪费。
发明内容
本公开实施例的目的是提供一种文件存储方法、装置、服务器及存储介质，以至少解决现有技术的分布式文件系统中存在的存储资源浪费的问题。
本公开的技术方案如下：
根据本公开实施例的第一方面，提供一种文件存储方法，包括：
写入待存储文件至一个或多个数据分区；
获取各数据分区存储的第一数据的空间占用量；
根据空间占用量以及数据块的存储容量，确定存储待存储文件所需数据块的数量；
将待存储文件发送至上述数量的数据块，上述数量的数据块用于存储待存储文件。
在其中一个实施例中，写入待存储文件至一个或多个数据分区，包括：
在将待存储文件写入至数据仓库中的情况下，依据预设对象信息对待存储文件进行分组，得到分组的数量P，P为正整数；
从数据仓库中确定P个数据分区，将待存储文件划分至P个数据分区中进行存储。
在其中一个实施例中，获取各数据分区存储的第一数据的空间占用量，包括：
获取数据分区存储的第一数据的数据行数；
根据数据分区关联的元数据，获取数据分区的单行数据空间占用量；
根据数据分区存储的第一数据的数据行数与数据分区的单行数据空间占用量，确定数据分区存储的第一数据的空间占用量。
在其中一个实施例中，根据数据分区关联的元数据，获取数据分区的单行数据空间占用量，包括：
从数据分区关联的元数据中获取数据分区的历史数据空间占用量与历史数据行数，历史数据空间占用量为写入至数据分区的历史数据的空间占用量，历史数据行数为历史数据的数据行数；
根据历史数据空间占用量与历史数据行数，确定数据分区的单行数据空间占用量。
在其中一个实施例中，根据历史数据空间占用量与历史数据行数，确定数据分区的单行数据空间占用量，包括：
计算历史数据空间占用量与历史数据行数的比值；
将比值作为数据分区的单行数据空间占用量。
在其中一个实施例中，根据空间占用量以及数据块的存储容量，确定存储待存储文件所需数据块的数量，包括：
获取数据块的存储容量与每一数据分区存储的第一数据的空间占用量；
根据存储容量与每一数据分区存储的第一数据的空间占用量，分别确定存储每一数据分区存储的第一数据所需数据块的数量；
根据存储每一数据分区存储的第一数据所需数据块的数量，确定存储待存储文件所需数据块的数量。
根据本公开实施例的第二方面，提供一种文件存储装置，包括：
写入模块，被配置为执行写入待存储文件至一个或多个数据分区；
获取模块，被配置为执行获取各数据分区存储的第一数据的空间占用量；
确定模块，被配置为执行根据空间占用量以及数据块的存储容量，确定存储待存储文件所需数据块的数量；
发送模块，被配置为执行将待存储文件发送至上述数量的数据块，上述数量的数据块用于存储待存储文件。
在其中一个实施例中，上述写入模块，包括：
分组单元，被配置为执行在将待存储文件写入至数据仓库中的情况下，依据预设对象信息对待存储文件进行分组，得到分组的数量P，P为正整数；
划分存储单元，被配置为执行从数据仓库中确定P个数据分区，将待存储文件划分至P个数据分区中进行存储。
在其中一个实施例中，获取模块，包括：
第一获取单元，被配置为执行获取数据分区存储的第一数据的数据行数；
第二获取单元，被配置为执行根据数据分区关联的元数据，获取数据分区的单行数据空间占用量；
第一确定单元，被配置为执行根据数据分区存储的第一数据的数据行数与数据分区的单行数据空间占用量，确定数据分区存储的第一数据的空间占用量。
在其中一个实施例中，第二获取单元，包括：
获取子单元，被配置为执行从数据分区关联的元数据中获取数据分区的历史数据空间占用量与历史数据行数，历史数据空间占用量为写入至数据分区的历史数据的空间占用量，历史数据行数为历史数据的数据行数；
确定子单元，被配置为执行根据历史数据空间占用量与历史数据行数，确定数据分区的单行数据空间占用量。
在其中一个实施例中，确定子单元被配置为具体执行：
计算历史数据空间占用量与历史数据行数的比值；
将比值作为数据分区的单行数据空间占用量。
在其中一个实施例中，第一确定模块，包括：
第三获取单元，被配置为执行获取数据块的存储容量与每一数据分区存储的第一数据的空间占用量；
第二确定单元，被配置为执行根据存储容量与每一数据分区存储的第一数据的空间占用量，分别确定存储每一数据分区存储的第一数据所需数据块的数量；
第三确定单元，被配置为执行根据存储每一数据分区存储的第一数据所需数据块的数量，确定存储待存储文件所需数据块的数量。
根据本公开实施例的第三方面，提供一种服务器，该服务器可以包括：
处理器；
用于存储处理器可执行指令的存储器；
其中，处理器被配置为执行指令，以实现如第一方面的任一项实施例中所示的文件存储方法。
根据本公开实施例的第四方面，提供一种计算机可读存储介质，当计算机可读存储介质中的指令由文件存储装置的处理器执行时，使得文件存储装置实现以实现如第一方面的任一项实施例中所示的文件存储方法。
根据本公开实施例的第五方面，提供一种计算机程序产品，包括计算机程序，计算机程序被处理器执行时实现如第一方面的任一项实施例中所示的文件存储方法。
本公开实施例提供的文件存储方法，通过获取待存储文件写入到各数据分区中的数据的空间占用量与数据块的存储容量，来确定存储待存储文件所需数据块的数量；将待存储文件发送至上述数量的数据块以进一步实现对待存储文件的存储，如此，在将待存储文件存入数据块的过程中时，能够通过该数量来限制实际用于存储待存储文件的数据块的数量，进而能够有效限制小文件的生成，提高存储资源的利用效率。
应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限值本公开。
附图说明
此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理，并不构成对本公开的不当限定。
图1是根据一示例性实施例示出的一种文件存储的架构图；
图2是根据一示例性实施例示出的一种文件存储方法的流程图；
图3是根据一示例性实施例示出的将待存储文件写入Hive分区的流程图；
图4是根据一示例性实施例示出的对Hive分区中的第一数据的空间占用量进行获取的流程图；
图5是根据一示例性实施例示出的对Hive分区的单行数据空间占用量进行获取的流程图；
图6是根据一示例性实施例示出的确定存储待存储文件所需数据块的目标数量的流程图；
图7是根据一示例性实施例示出的一种文件存储装置的结构框图；
图8是根据一示例性实施例示出的一种服务器的框图；
图9是根据一示例性实施例示出的用于文件存储的设备的框图。
具体实施方式
为了使本领域普通人员更好地理解本公开的技术方案，下面将结合附图，对本公开实施例中的技术方案进行清楚、完整地描述。
需要说明的是，本公开的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本公开的实施例能够以除了在这里图示或描述的那些以外的顺序实施。以下示例性实施例中所描述的实施方式并不代表与本公开相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本公开的一些方面相一致的装置和方法的例子。
本公开所提供的文件存储方法，可以应用于如图1的架构中，具体结合图1进行详细说明。
图1是根据一示例性实施例示出的一种文件存储的架构图。
如图1所示，该架构图中可以包括数据仓库工具(Hive)10与海杜普分布式文件系统(Hadoop Distributed File System，HDFS)20，Hive与HDFS可以是海杜普(Hadoop)分布式系统基础架构中的两个常用的组件。
其中，HDFS可以用于文件的分布式存储。具体来说，HDFS采用主从(Master/Slave)结构模型，并且往往以HDFS集群的形式存在，每一HDFS通常主要包括一个主节点(NameNode)和多个从节点(DataNode)；其中，DataNode通常以数据块的形式存在，每一数据块往往具有预设大小的存储容量；当待存储的文件的空间占用量，即文件大小大于单个数据块的存储容量时，该文件可以被分开存储在多个数据块中，这多个数据块与文件的关联关系，则可以记录在NameNode中。换而言之，NameNode是HDFS集群重要的节点，可以用于进行数据块的管理、维护文件与数据块之间的对应关系等。
举例来说，在Hadoop的实际应用中，各数据块的存储容量通常为64MB或者128MB，以数据块的存储容量为128MB为例，当待存储的文件的空间占用量为200MB时，可以将其存储在两个数据块中，该文件在其中一个数据块中存储的数据所占用空间可以为128MB，在另一个数据块中存储的数据所占用空间相应为72MB。因此，在HDFS中，存储该文件实际占用的存储资源则对应两个数据块的总存储容量，即256MB。此外，为保证在对该文件进行读取时，能够准确地对该文件对应的存储数据进行提取，则需要在NameNode中将该文件与用于存储该文件的两个数据块的节点信息进行记录。
如上文，Hive可以定义为基于Hadoop的一种数据仓库工具，在向HDFS的数据块中存储文件时，可以先在Hive中写入文件，经过Hive处理后再存储至数据块。
Hive的应用存在比较多的优势，举例来说：Hive可以提供结构化查询语言(Structured Query Language，SQL)查询功能，并且可以将SQL查询语言转换为映射归约(MapReduce)任务进行数据的并行运算；Hive可以实现待存储的文件的分区，在待存储的文件占用空间较大的情况下，使用Hive的分区表存储可以带来查询性能的极大提升；此外，Hive可以通过Hive表的形式来管理元数据，例如Hive表名、如Hive表注释、字段属性等表基础信息，以及与Hive表中数据存储相关的信息，比如数据行数、文件数，压缩前后存储空间等。
然而，在使用Hive的分区表存储功能时，往往也会引入小文件生成过多的问题。小文件即上文中提及的占用空间量明显小于数据块存储容量、但占据了一个单独的数据块的文件。此外，在实际应用场景中，经常会使用Hive多级分区表存储文件，而Hive多级分区表的使用，进一步加剧了上述小文件生成过多的问题。
举例来说，Hive通常会基于映射-归约模型(MapReduce)对待存储文件进行处理，再将处理后的待存储文件发送至HDFS进行存储。MapReduce包括Map(对应映射)函数与Reduce(对应归约)函数。
其中，Map函数可以对待存储文件进行处理，得到键值对，记为<key,value>，其中，key对应为“键”，value对应为“值”，而key则可以通过哈希值(hash)进行表示。
Reduce函数则用于直接或间接接收Map函数的输出，并输出可用于直接存储至数据块的文件。比如，Map函数可以输出多个键值对，而Reduce函数可以将具有相同hash值的键值对进行集中后输出，该集中的过程可以称为对键值对的归约。
Map函数与Reduce函数本质上可以是Hive中常见的两类函数，在实际应用中，可以在不同的进程中调用同一类函数。比如，可以在多个进程中各自调用Reduce函数进行归约。
一般来说，单个调用Reduce函数的进程处理能力有限，比如，单个调用Reduce函数的进程能够处理1000MB的数据，而待存储文件的空间占用量为8000MB，则可能需要8个调用Reduce函数的进程。待存储文件经过Map处理后，得到多个键值对。以各个键值对的key的hash值对调用Reduce函数的进程的数量取模，可以得到各个键值对对应的调用Reduce函数的进程。
为便于理解，取模的过程可以认为是将hash值除以8，得到余数，余数的取值范围为0～7，对应了8个调用Reduce函数的进程；而余数的取值与调用Reduce函数的进程可以是一一对应的关系；如此，可以将任一个键值向对应的调用Reduce函数的进程输入。而调用Reduce函数的进程对具有相同上述余数的键值对进行接收以集中的过程，也可以是对键值对的归约过程。
若在Hive中，应用Map→Reduce的处理流程，每个调用Reduce函数的进程对输入的键值对进行归约，对应输出一个文件；相应地，此时Hive将生成8个文件，这8个文件将被发送至HDFS进行存储。当然，受到数据块存储容量的限制，HDFS存储这8个文件可能使用到的数据块的数量会更多，但每个数据块的存储容量基本上可以得到有效使用。
在实际应用中，当调用Map函数的进程输出的键值对中，key的hash值过于相似或集中时，若应用Map→Reduce的处理流程，大部分的键值对可能分配到同一个调用Reduce函数的进程中，从而造成数据倾斜，影响数据处理效率。因此，通过会在调用Map函数的进程的处理过程与调用Reduce函数的进程之间加入分区的处理过程。
以下对在调用Map函数的进程的处理过程与调用Reduce函数的进程的处理过程之间加入分区的处理过程进行介绍(对应使用Hive的分区表存储功能)。假设在一级分区中，生成了100个分区；以一个分区为例，一个分区中可能有多个键值对，若分区中的数据为均匀分布(即多个键值对中的hash值与8相除得到的余数可以是0～7)，则该分区的键值对会输入至上述的8个调用Reduce函数的进程，并相应输出8个文件。如此，100个分区则会输出100×8＝800个文件。待存储文件总的空间占用量为8000MB，则800个文件每一个文件的占用空间量只有10MB，小文件生成的数量较多。
进一步地，如果使用多级分区，即在一级分区的基础上，再进行二级分区；假设每个一级分区下存在9个二级分区，则调用Reduce函数的进程最终会输出100×9×8＝7200个文件。待存储文件总的空间占用量为8000MB，则这7200个文件中每一个文件的占用空间量只有1MB多，加剧了小文件生成过多的问题。
由于每个小文件需要占用一个数据块，因此，这些数据块的存储容量并未得到充分的利用，导致HDFS中存储资源的浪费。在HDFS集群中，由于NameNode需要花费一定的内存来对每一数据块进行管理，数据块使用数量的提升，则增大了NameNode的内存占用量，加大了HDFS内存负担，制约了HDFS的存储性能和集群扩展性。
基于此，本公开在上述架构的基础上，针对文件存储过程进行了改进。具体来说，在使用Hive的分区表存储功能时，会存在将待存储的文件，即待存储文件，预先写入到Hive中的N个Hive分区中的情况，N为正整数；此时，可以根据待存储文件写入到各个Hive分区中的数据的空间占用量，以及数据块的存储容量，来确定存储该待存储文件所需数据块的目标数量，通过该目标数量来限制或者说指导实际存储该待存储文件所采用的数据块的数量，从而在存储阶段限制小文件的生成数量，进而能够减小HDFS中存储资源的浪费，并降低对上述NameNode的内存占用量。
当然，在实际应用中，上述文件存储的架构，还可以是基于例如Ceph等类型的分布式文件系统而建立的，在这些类型的分布式文件系统中，同样可能存在对数据进行分区写入，以及分区中数据写入数据块中的过程，因此，也可能存在存储资源浪费的问题。
以下实施例中，将主要以基于Hive与HDFS建立的架构为例，来对本公开提供的数据存储方法进行说明；相应地，上述的数据分区可以对应为Hive分区。
图2是根据一示例性实施例示出的一种文件存储方法的流程图，该文件存储方法可以由服务器执行；如图2所示，该文件存储方法包括以下步骤：
步骤201，写入待存储文件至一个或多个数据分区；
步骤202，获取各数据分区存储的第一数据的空间占用量；
步骤203，根据空间占用量以及数据块的存储容量，确定存储待存储文件所需数据块的数量；
步骤204，将待存储文件发送至上述数量的数据块，上述数量的数据块用于存储待存储文件。
由此，通过获取待存储文件写入到各个数据分区中的第一数据的空间占用量与数据块的存储容量，来确定存储待存储文件所需数据块的数量；发送文件存储请求，响应于接收到的数据块列表，并基于数据块列表，将待存储文件发送至上述数量的数据块以进一步实现对待存储文件的存储，如此，在将待存储文件存入数据块的过程中时，能够通过该数量来限制实际用于存储待存储文件的数据块的数量，进而能够有效限制小文件的生成，提高存储资源的利用效率。
与此同时，结合HDFS的分布式文件系统的应用场景，上述的文件存储方法可以具体由包括Hive的服务器执行。在使用HDFS对待存储文件进行存储时，小文件数量的降低，也使得HDFS中NameNode的内存占用量能够相应得到降低，进而提升HDFS的工作性能。
当然，在实际应用中，Hive对待存储文件的分区写入结果，也可以交互至presto、impala或者sparksql等类型查询引擎中，这些查询引擎可能具有对应的用于数据存储的数据块，例如，对于presto查询引擎，其可能对应有mysql中的数据库及数据库中的数据块等。换而言之，以上用于待存储文件存储的数据块，并不局限于HDFS中的数据块。
当然，为了简化描述，以下实施例中将主要以使用HDFS中的数据块对待存储文件进行存储为例进行说明，其中，数据分区以Hive分区为例。
下面对上述步骤进行详细说明，具体如下所示。
对于步骤201，通常来说，在Hive中可以创建例如分区表的Hive表，对于分区表，可以对应有一个或者多个分区，即对应上述的Hive分区，每个Hive分区可以是以文件夹的形式单独存在分区表文件夹的目录下。换而言之，在Hive中可以存在一个或多个Hive分区。
待存储文件可以写入到一个或多个Hive分区中，例如，在实际应用中，可以将待存储文件分为多个数据，手动将这些数据分别写入到对应的Hive分区中；或者是基于一些预设条件，例如预设的字段或者字符等，将待存储文件自动分为多个数据，并将这些数据分别写入到对应的Hive分区中。前者可以认为是使用Hive的静态分区，而后者可以认为是使用Hive的动态分区。
举例来说，待存储文件的具体内容中，可能包括了日期分别为20200101(可以理解为2020年1月1日，以下不再一一说明)、20200102以及20200103的数据。对于该待存储文件，可以在Hive中创建分区表，该分区表中包括了名称分别为“20200103”、“20200102”以及“20200103”的目录，每一个目录对应了一个Hive分区。其中，名称为“20200101”的目录对应的Hive分区中，可以写入日期为20200101的数据；类似地，其余的目录对应的Hive分区中，也可以写入相应日期的数据，此处不做一一说明。
对于步骤202，在待存储文件写入至在数据仓库工具Hive中的一个或多个Hive分区中的情况下，待存储文件写入到每一Hive分区的数据，即上述第一数据的空间占用量，是可以进行获取的。
待存储文件，可以是视频、图片、音乐、文档等，此处不做具体限定。
对于步骤203，如上文描述的内容，对于数据块来说，其存储容量可以是预先设定的，例如，在HDFS中，数据块的存储容量通常为64MB，或者为128M。因此，数据块的存储容量是可以预先得到的。
第一数据的空间占用量可以理解为存储第一数据所需的存储容量，对于任一个Hive分区中的第一数据，可以根据其空间占用量与数据块的存储容量，来确定存储该第一数据所需的数据块的数量；而将待存储文件在所有Hive分区中的第一数据的存储所需数据块的数量进行整合，可以得到存储待存储文件所需数据块的目标数量。
例如，对于某一待存储文件，写入到Hive中的2个Hive分区，写入第一个Hive分区的第一数据的空间占用量为200MB，写入到第二个Hive分区的第一数据的空间占用量为300MB；同时，假设数据块的存储容量为128MB，则对于第一个Hive分区的第一数据，所需存储用的数据块的数量可以为2，对于第二Hive分区的第一数据，所需存储用的数据块的数量可以为3；将针对两个Hive分区计算得到的存储用的数据块的数量相加，可以得到存储该待存储文件所需数据块的目标数量为5。
当然，在实际应用中，目标数量的确定，也可以考虑例如余量或者计算偏差等因素，来对上述目标数量进行修正，得到存储待存储文件实际需要的数据块的数量，或者说最终确定的目标数量。
对于步骤204，可以将待存储文件发送至上述数量的数据块，上述数量的数据块用于存储待存储文件。
举例来说，在步骤204中，Hive可以向HDFS的NameNode发送文件存储请求，而NameNode可以响应于该文件存储请求，向Hive发送数据块列表。该数据块列表可以记录了可写的数据块的地址信息等内容。换而言之，NameNode可以向Hive发送可以用于存储待存储文件的DataNode的信息。
进一步地，Hive可以响应于接收到的数据块列表，将待存储文件发送至上述目标数量的数据块以进一步实现对待存储文件的存储，这些用于存储待存储文件的数据块，可以是数据块列表所指示的数据块。
具体来说，Hive可以根据数据块列表提供的DataNode的地址信息等，通过调用Reduce函数的进程向DataNode输出文件，DataNode存储接收到的文件，以实现对待存储文件在HDFS中的存储。
通过目标数量来对实际用于待存储文件进行存储的数据块的数量进行限制，有效避免基于Hive来进行待存储文件存储时小文件大量生成的情况，提高存储容量的利用率。
结合上文中将8000MB的待存储文件写入了两级分区的应用场景，待存储文件共写入到100×9＝900个Hive分区；若这900个Hive分区中存储的第一数据的空间占用量是一致的，即各Hive分区中存储的第一数据的空间占用量约9MB；数据块的存储容量为128MB。因此，存储每个Hive分区中的第一数据所需的数据块的数量为1，存储待存储文件所需数据块的数量为900。
在这种情况下，通过900这个数值来进一步限制存储待存储文件所需的数据块的数量，避免在无限制的情况下，Hive将待存储文件利用映射-归约模型进行处理，生成7200个文件，然后利用7200个数据块分别存储7200个文件(即利用7200个数据块对待存储文件进行存储)。
而具体的实现方式，可以是将一个Hive分区中所有的键值对中key的hash值修改为一致，或者通过其他方式使得一个Hive分区中所有的键值对均输入至其中的一个调用Reduce函数的进程进行处理等等，此处不作限定。
为了在将待存储文件写入Hive中的一个或多个Hive分区中的过程中，比较高效地实现分区写入的过程，本公开的再一些实施例中，步骤201可以包括对待存储文件进行动态分区写入的过程。
图3是根据一示例性实施例示出的将待存储文件写入Hive分区的流程图,如图3所示，对待存储文件进行动态分区写入过程包括如下步骤：
步骤301，在将待存储文件写入至数据仓库中的情况下，依据预设对象信息对待存储文件进行分组，得到分组的数量P，P为正整数；
步骤302，从数据仓库中确定P个数据分区，将待存储文件划分至P个数据分区中进行存储。
下面对上述步骤进行详细说明，具体如下所示：
在步骤301中，预设对象信息可以理解成预设对象的字段信息，或者说预设维度的字段信息。
结合一些实际应用场景，在待存储文件中可能存在较多的具有并列关系的数据，例如，待存储文件可以包括来自多个业务线的数据，各个业务线的数据之间可以认为是存在并列关系的。这些具有并列关系的数据一般具有相同的字段或信息，例如获取时间、业务线、版本号等等，可以从这些对象中预先选取一些对象，即上述的预设对象，来作为动态分区写入的分区依据。这些预设对象在待存储文件中具体可以体现为一些预设的字段信息，例如“time”(对应时间)、“service line”(对应业务线)、“edition”(对应版本号)等。
通常来说，待存储文件最初可以是作为一个整体写入到数据仓库(例如Hive)中的，例如，待存储文件整体写入到Hive后，得到一张Hive表，记为Hive_tb1；在Hive_tb1中，一般存在一个总目录。
举例来说，待存储文件的内容可能包括一个业务线的在不同时间采集的数据，比如，名为“service line A”的业务线，在20200101、20200102以及20200103这天内采集的数据。相应地，在Hive_tb1中，可能存在“service line A”这一目录，而不存在“20200103”、“20200102”以及“20200103”这些目录。换而言之，在“service line A”这一总的目录之下可能不存在子目录。
换而言之，在得到Hive_tb1的过程中，可以认为暂未使用到Hive的分区表存储功能。
Hive可以通过对上述预设对象信息进行查询来实现对待存储文件的分组，进而得到分组数量P，该分组的过程可以认为是Hive使用动态分区功能插入数据的过程。容易理解的是，Hive通常提供有动态分区功能，其可以基于查询预设对象信息在待存储文件中的位置来建立分区。在一定程度上，可以认为Hive是将预设对象信息作为对待存储文件分组的依据。
举例来说，待存储文件的内容可能包括：“time，20200101；data，AAA；time，20200102；data，BBB；time，20200103；data，CCC”，若将“time”作为预设对象信息，则可以将待存储文件分为“time，20200101；data，AAA”、“time，20200102；data，BBB”以及“time，20200103；data，CCC”这三组。
上述每一个分组可以对应一个第一数据。结合上文举例，在待存储文件中可能存在较多的具有并列关系的数据，而一个第一数据，可以是这些具有并列关系的数据中的某一个数据。比如，第一数据可以是“time，20200101；data，AAA”、“time，20200102；data，BBB”或者“time，20200103；data，CCC”。
在实现了对上述第一数据的获取的情况下，在步骤302中，可以根据第一数据的数量，从数据仓库中确定相应数量的数据分区。在一定程度上，可以认为是对每一第一数据分配一个数据分区。
在实际应用中，数据仓库可以是上述的Hive，相应地，数据分区可以是上述的Hive分区。可以在对待存储文件分组完成后，再从Hive中确定Hive分区；也可以在每获得一个第一数据的情况下，从Hive中确定一Hive分区，确定该Hive分区后，可将第一数据写入该Hive分区。
在通过分组得到多个第一数据的情况下，多个第一数据写入到对应的Hive分区中的过程，可以是并行的。
在对每个第一数据分配了相应的Hive分区后，可以进一步创建一张新的Hive表，记为Hive_tb2；在Hive_tb2中，可以具有若干数量的子目录，这些子目录一般是与确定的Hive分区一一对应的。一般来说，在各第一数据能够正常写入对应的Hive分区的情况下，Hive_tb2可以指示上述P个分组中的第一数据写入到了P个Hive分区。
同样以待存储文件包括名为“service line A”的业务线在20200101、20200102以及20200103这天内采集的数据为例，在Hive_tb2中，可以具有“service line A”这一总目录，还具有“20200103”、“20200102”以及“20200103”这些子目录。其中，举例来说，在子目录“20200103”对应的Hive分区中，可以写入了“time，20200101；data，AAA”这一第一数据。
本实施例基于预设对象信息进行待存储文件在Hive中的P个Hive分区中的写入过程，可以利用Hive的动态分区功能来实现待存储文件的分区，有效提高待存储文件的写入到Hive分区的效率。
本公开的一个可选实施例中，上述步骤201中的获取各数据分区存储的第一数据的空间占用量，可以是基于数据分区关联的元数据来对第一数据的空间占用量进行获取的。
参见图4，图4是根据一示例性实施例示出的对数据分区中的第一数据的空间占用量进行获取的流程图，具体包括如下步骤：
步骤401，获取数据分区存储的第一数据的数据行数；
步骤402，根据数据分区关联的元数据，获取数据分区的单行数据空间占用量；
步骤403，根据数据分区存储的第一数据的数据行数与数据分区的单行数据空间占用量，确定数据分区存储的第一数据的空间占用量。
结合HDFS的应用场景，数据分区关联的元数据，或者说Hive分区所关联的元数据，可以从Hive元数据信息中获取。
本实施例中，可以利用Hive中已有的元数据信息，来得到各Hive分区的单行数据空间占用量，并基于各Hive分区的单行数据空间占用量与待存储文件写入到各Hive分区中的第一数据的数据行数，来较为准确高效地得到各Hive分区中的第一数据的空间占用量。
具体来说，在步骤401中，Hive分区中的第一数据的数据行数，可以理解为待存储文件写入到任一Hive分区中的数据的数据行数。
在实际应用中，可以通过一些查询指令获取Hive分区中的数据行数，例如count指令；另外，结合上文中Hive_tb1与Hive_tb2的说明，可以在Hive_tb1中获取总的数据行数，而在Hive_tb2中，可以获取分入各个Hive分区中的数据的数据行数。
为便于说明，以下主要就一个Hive分区中的第一数据的数据行数进行说明，将此处的数据行数可以记为partition_rowsi，其中，下标i可以代表了Hive分区的编号。
在步骤402中，数据分区关联的元数据，例如数据仓库工具Hive的元数据，通常来说，可以用于存储Hive表名、表注释、字段属性等表基础信息以及表中数据存储相关的信息，比如行数、文件数、压缩前后存储大小等。
通过读取Hive元数据信息，可以得到各个Hive分区在用于数据写入时生成的历史信息；具体到本步骤当中，这些历史数据可以体现为在Hive分区中的单行数据空间占用量。换而言之，此处的单行数据空间占用量，可以认为是根据历史信息得到的一个经验值，并可以通过读取Hive元数据信息来获得。
为便于说明，可以将Hive分区中的单行数据空间占用量记为row_sizei，同样地，下标i可以代表了Hive分区的编号。
在得到上述partition_rowsi与row_sizei两个参数的情况下，即可以对Hive分区中的第一数据的空间占用量进行确定。相应地，在步骤403中限定了该确定过程。
通常来说，Hive分区中的第一数据的空间占用量可以是partition_rowsi与row_sizei之间的乘积；当然，在实际应用中，也可以考虑余量或误差等因素，对partition_rowsi或者row_sizei按照预设规则进行调整后再求取第一数据的空间占用量，或者，也可以是对partition_rowsi与row_sizei之间的乘积按预设规则进行调整后得到第一数据的空间占用量等。
参见图5，图5是根据一示例性实施例示出的对数据分区的单行数据空间占用量进行获取的流程图。具体来说，上述步骤402，根据数据分区关联的元数据，获取数据分区的单行数据空间占用量，可以包括：
步骤501，从数据分区关联的元数据中获取数据分区的历史数据空间占用量与历史数据行数，历史数据空间占用量为写入至数据分区的历史数据的空间占用量，历史数据行数为历史数据的数据行数；
步骤502，根据历史数据空间占用量与历史数据行数，确定数据分区的单行数据空间占用量。
同样以数据分区为Hive分区为例，如上文实施例中所描述的，Hive分区的单行数据空间占用量可以认为是一个经验值；本实施例中，可以根据Hive分区的历史数据空间占用量与历史数据行数，来获取该Hive分区的单行数据空间占用量。由于Hive分区的历史数据空间占用量与历史数据行数通常是Hive的元数据中比较常见的两类参数，基于这两类参数来确定Hive分区的单行数据空间占用量，有助于适应不同应用场合下对不同Hive分区的单行数据空间占用量的获取需求。
在一个示例中，上述待存储数据写入到Hive分区中后，可以长期保存在Hive分区中，在下一次数据的写入的过程中，待存储数据作为历史数据来提供单行数据空间占用量等经验值。
作为一个可选的实施例，上述步骤502，可以具体包括：
计算历史数据空间占用量与历史数据行数的比值；
将比值作为数据分区的单行数据空间占用量。
也就是说，本实施例中，可以根据历史数据占用量与历史数据行数，来计算历史数据在写入到Hive分区中每行数据的空间占用量的平均值，并将该平均值作为后续计算第一数据的空间占用量时的单行数据空间占用量。
通常来说，在一个Hive分区中，写入数据的数据行数会较多，通过计算平均值的方式，可以比较准确地反映该Hive分区中写入的单行数据所需的空间占用量。换而言之，在一般的应用场合下，通过计算平均值的方式来得到各Hive分区的单行数据空间占用量，有助于保证后续计算得到的各Hive分区中的第一数据的空间占用量的准确度。
当然，在一些实际应用场景中，在确定Hive分区的单行数据空间占用量时，也可以根据实际需要选择计算方法。例如，当写入到某一个Hive分区的历史数据的空间占用量较小时，历史数据行数较小，也就是说，用于确定单行数据空间占用量这一经验数据的样本数量较少，导致通过计算平均值得到的单行数据空间占用量不具有较高的代表性；若直接将上述平均值作为Hive分区的单行数据空间占用量，可能导致计算得到的第一数据的空间占用量偏小，进而导致确定的数据块的目标数量偏少，无法满足对第一数据的存储要求。
因此，在一些可选的实施方式中，可以在历史数据空间占用量与历史数据行数的比值的基础上，加上一预设空间占用量，或者乘以某一预设系数，来得到Hive分区的单行数据空间占用量。
比如，若历史数据空间占用量与历史数据行数的比值为5kb。在该比值的基础上，可以加入一预设空间占用量0.2kb，得到Hive分区的单行数据空间占用量为5.2kb；或者，也可以在上述比值的基础上，乘以一预设系数1.05，得到Hive分区的单行数据空间占用量为5.25kb。
可见，通过以上处理方式，可以在一定程度上增加计算得到的第一数据的空间占用量，进而有助于有效避免出现确定的数据块的目标数量偏少的情况。
当然，Hive分区的单行数据空间占用量的计算方式，也可以结合其他实际需要进行确定，此处不做一一说明。
参见图6，图6是根据一示例性实施例示出的确定存储待存储文件所需数据块的目标数量的流程图。如图6所示，上述步骤203，根据空间占用量以及数据块的存储容量，确定存储待存储文件所需数据块的数量，包括：
步骤601，获取数据块的存储容量与每一数据分区存储的第一数据的空间占用量；
步骤602，根据存储容量与每一数据分区存储的第一数据的空间占用量，分别确定存储每一数据分区存储的第一数据所需数据块的数量；
步骤603，根据存储每一数据分区存储的第一数据所需数据块的数量，确定存储待存储文件所需数据块的数量。
同样以数据分区为每一Hive分区为例，本实施例中，针对每一Hive分区中的第一数据，分别计算存储其所需的数据块的子数量，并可以根据这些子数量得到上述的目标数量，例如将这些子数量进行相加，得到存储整个待存储文件所需数据块的目标数量；如此，可以针对每一Hive分区中的第一数据均分配合理数量的数据块进行数据存储，保证各个Hive分区中的第一数据存储至数据块后的独立性。
对于步骤601，如上文，在例如HDFS等存储架构中，数据块的存储容量往往是预设的且容易进行获取的；例如，在Hadoop2.x中，HDFS的数据块的默认存储容量为128MB。每一Hive分区中的第一数据的空间占用量，可以根据Hive的元数据，结合查询指令等来进行获取。
在步骤602中，可以是根据任一Hive分区中的第一数据的空间占用量与存储容量的比值，来确定该Hive分区对应的子数量，也就是存储该Hive分区中的第一数据所需数据块的个数；具体来说，可以将该比值取整后加1；当然，也可以考虑例如余量或误差，将该比值取整后加上一大于1的整数等等。
为简化说明，以下主要以某一Hive分区对应的子数量等于total_sizei/block_size为例进行说明，其中，total_sizei可以代表该Hive分区中的第一数据的空间占用量，下标i代表该Hive分区的编号，block_size则代表数据块的存储容量。在此基础上，上述步骤603的计算过程可以表示为：
其中，file_nums可以代表上述的存储待存储文件所需数据块的目标数量。
同时，结合上文实施例，在一可选的实施方式中，上述total_sizei可以通过如下公式进行求取：
total_sizei＝partition_rowsi·row_sizei
本公开实施例中，在将待存储文件写入到数据块的阶段，可以预计算待存储文件写入到各个数据分区中的第一数据的空间占用量，及其存储各第一数据分别所需的数据块的数量，并对这些数量进行求和得到用于存储整个待存储文件所需数据块的目标数量；通过该目标数量对实际使用到的数据块的数量进行限制，有效避免小文件的生成。
在一个示例中，基于各个Hive分区的单行数据空间占用量、各个Hive分区的第一数据的数据行数以及数据块的存储容量，可以在将个第一数据存储至数据块的过程中，确定合适的存储到每一数据块中的数据行数，使得待存储文件存储到每一数据块中的数据的空间占用量，基本上与数据块的存储容量相同，进而充分利用数据块中的存储资源。
在一个示例性实施例中，在调用Reduce函数的进程的数量为多个的情况下，各调用Reduce函数的进程输入的文件可以以并行的方式发送至HDFS以进行存储。
具体地，若一个Hive分区对应一个调用Reduce函数的进程，则各Hive分区中的第一数据经调用Reduce函数的进程进行归约处理后，输出的文件(记为第二数据)可以是分别发送至HDFS进行存储。多个第一数据所对应的多个第二数据，可以通过并行存储的方式将待存储文件存储至数据块中，可以有效提升待存储文件存储至数据块中的效率。
举例来说，待存储文件的空间占用量为300MB，在Hive中，将该待存储文件写入了两个数据分区，各数据分区中存储的第一数据的空间占用量为200MB与100MB。这两个第一数据分别经过调用Reduce函数的进程处理后，输出空间占用量为200MB与100MB的两个第二数据。这两个第二数据可以并行发送至HDFS。
从HDFS的角度来说，200MB的第二数据可以先写满一个128MB的数据块A(对应DataNode)后，再将剩余的72MB数据写入至数据块B；而100MB的第二数据可以写入至数据块C。其中，将128MB的数据写入数据块A的过程，与将100MB的数据写入数据块C的过程，可以是同步进行的。
本公开实施例中，实际上提供的是一种“事先”治理小文件的文件存储方法，即在Hive分区中的数据写入数据块前，通过利用Hive元数据，提前计算存储待存储文件所需的数据块的目标数量，并以该目标数量限制实际应用的数据块数量，在源头处避免了大量小文件的产生。
而现有技术中存在一些倾向于“事后解决”的小文件处理方式，具体来说，这类处理方式在待存储文件在数据块中存储完毕后，通过人工配置合并参数的方式重新开启一轮合并任务，对生成的小文件做合并操作，在海量数据的处理场景下，一轮合并任务必然会影响计算任务的执行效率；在实际使用场景中，通过这类处理方式对小文件处理后，仍然可能存在较多的小文件，处理效果不佳。
相较之下，本公开实施例提供的文件存储方法在使用Hive的分区表存储海量数据、动态分区较多以及分区数据分布不均匀等情况下，依然能够在保证存储效率前提下，有效降低小文件数量。
需要说明的是，上述本公开实施例描述的应用场景是为了更加清楚的说明本公开实施例的技术方案，并不构成对于本公开实施例提供的技术方案的限定，本领域普通技术人员可知，随着新应用场景的出现，本公开实施例提供的技术方案对于类似的技术问题，同样适用。
基于相同的发明构思，本公开还提供了一种文件存储装置。具体结合图8进行详细说明。
图7是根据一示例性实施例示出的一种文件存储装置，包括：
写入模块701，被配置为执行写入待存储文件至一个或多个数据分区；
获取模块702，被配置为执行获取各数据分区存储的第一数据的空间占用量；
确定模块703，被配置为执行根据空间占用量以及数据块的存储容量，确定存储待存储文件所需数据块的数量；
发送模块704，被配置为执行将待存储文件发送至上述数量的数据块，上述数量的数据块用于存储待存储文件。
本实施例通过获取待存储文件写入到各数据分区中的数据的空间占用量与数据块的存储容量，来确定存储待存储文件所需数据块的数量；将待存储文件发送至上述数量的数据块以进一步实现对待存储文件的存储，如此，在将待存储文件存入数据块的过程中时，能够通过数量来限制实际用于存储待存储文件的数据块的数量，进而能够有效限制小文件的生成，提高存储资源的利用效率。
在一些实施例中，上述写入模块701还可以包括：
分组单元，被配置为执行在将待存储文件写入至数据仓库中的情况下，依据预设对象信息对待存储文件进行分组，得到分组的数量P，P为正整数；
划分存储单元，被配置为执行从数据仓库中确定P个数据分区，将待存储文件划分至P个数据分区中进行存储。
本实施例基于预设对象信息进行待存储文件在数据仓库中的各个数据分区中的写入过程，可以利用数据仓库的动态分区功能来实现待存储文件的写入，有效提高待存储文件的写入到数据分区的效率。
在一些实施例中，获取模块702，可以包括：
第一获取单元，被配置为执行获取数据分区存储的第一数据的数据行数；
第二获取单元，被配置为执行根据数据分区关联的元数据，获取数据分区的单行数据空间占用量；
第一确定单元，被配置为执行根据数据分区存储的第一数据的数据行数与数据分区的单行数据空间占用量，确定数据分区存储的第一数据的空间占用量。
本实施例中，可以利用数据分区关联的元数据，来得到各数据分区的单行数据空间占用量，并基于各数据分区的单行数据空间占用量与待存储文件写入到各数据分区中的第一数据的数据行数，来较为准确高效地得到各数据分区中的第一数据的空间占用量。
在一些实施例中，第二获取单元，可以包括：
获取子单元，被配置为执行从数据分区关联的元数据中获取数据分区的历史数据空间占用量与历史数据行数，历史数据空间占用量为写入至数据分区的历史数据的空间占用量，历史数据行数为历史数据的数据行数；
确定子单元，被配置为执行根据历史数据空间占用量与历史数据行数，确定数据分区的单行数据空间占用量。
本实施例中，可以根据数据分区的历史数据空间占用量与历史数据行数，来获取该数据分区的单行数据空间占用量。由于数据分区的历史数据空间占用量与历史数据行数，通常是Hive等类型的数据仓库的元数据中比较常见的两类参数，基于这两类参数来确定数据分区的单行数据空间占用量，有助于适应不同应用场合下对不同数据分区的单行数据空间占用量的获取需求。
在一些实施例中，确定子单元被配置为具体执行：
计算历史数据空间占用量与历史数据行数的比值；
将比值作为数据分区的单行数据空间占用量。
本实施例中，可以根据历史数据占用量与历史数据行数，来计算历史数据在写入到数据分区中，每行数据的空间占用量的平均值，并将该平均值作为后续计算第一数据的空间占用量时的单行数据空间占用量。在一般的应用场合下，通过计算平均值的方式来得到各数据分区的单行数据空间占用量，有助于保证候选计算得到的各数据分区中的第一数据的空间占用量的准确度。
在一些实施例中，确定模块703，可以包括：
第三获取单元，被配置为执行获取数据块的存储容量与每一数据分区存储的第一数据的空间占用量；
第二确定单元，被配置为执行根据存储容量与每一数据分区存储的第一数据的空间占用量，分别确定存储每一数据分区存储的第一数据所需数据块的数量；
第三确定单元，被配置为执行根据存储每一数据分区存储的第一数据所需数据块的数量，确定存储待存储文件所需数据块的数量。
本实施例中，针对每一数据分区中的第一数据，可以分别计算存储其所需的数据块的子数量，并可以将这些子数量进行相加等方式的处理，来得到存储整个待存储文件所需数据块的数量；如此，可以针对每一数据分区中的第一数据均分配合理数量的数据块进行数据存储，保证各个数据分区中的第一数据存储至数据块后的独立性。
关于上述实施例中的装置，其中各个模块执行操作的具体方式已经在有关该方法的实施例中进行了详细描述，此处将不做详细阐述说明。
图8是根据一示例性实施例示出的一种服务器的框图。参照图8，本公开实施例还提供了一种服务器，包括处理器810、通信接口820、存储器830和通信总线840，其中，处理器810、通信接口820和存储器830通过通信总线840完成相互间的通信。
该存储器830，用于存放处理器810可执行的指令。
该处理器810，用于执行存储器830上所存放的指令时，实现如下步骤：
写入待存储文件至一个或多个数据分区；
获取各数据分区存储的第一数据的空间占用量；
根据空间占用量以及数据块的存储容量，确定存储待存储文件所需数据块的数量；
该通信接口820，用于将待存储文件发送至上述数量的数据块，上述数量的数据块用于存储待存储文件。
可见，应用本公开实施例，通过获取待存储文件写入到各数据分区中的数据的空间占用量与数据块的存储容量，来确定存储待存储文件所需数据块的数量；将待存储文件发送至上述数量的数据块以进一步实现对待存储文件的存储，如此，在将待存储文件存入数据块的过程中时，能够通过该数量来限制实际用于存储待存储文件的数据块的数量，进而能够有效限制小文件的生成，提高存储资源的利用效率。
图9是根据一示例性实施例示出的用于文件存储的设备的框图。例如，该设备900可以被提供为一服务器。参照图9，设备900包括处理组件922，其进一步包括一个或多个处理器，以及由存储器932所代表的存储器资源，用于存储可由处理组件922的执行的指令，例如应用程序。存储器932中存储的应用程序可以包括一个或一个以上的每一个对应于一组指令的模块。此外，处理组件922被配置为执行指令，以执行上述任一实施例的文件存储方法。
该设备900还可以包括一个电源组件926被配置为执行设备900的电源管理，一个有线或无线网络接口950被配置为将设备900连接到网络，和一个输入输出(I/O)接口958。设备900可以操作基于存储在存储器932的操作系统，例如Windows ServerTM，Mac OS XTM，UnixTM,LinuxTM，FreeBSDTM或类似。
在本公开一些实施例中，还提供了一种存储介质，当该存储介质中的指令由服务器的处理器执行时，使得服务器能够执行上述任一实施例所示的文件存储方法。
可选地，该存储介质可以是非临时性计算机可读存储介质，示例性的，非临时性计算机可读存储介质可以是ROM、随机存取存储器(RAM)、CD-ROM、磁带、软盘和光数据存储设备等。
在本公开一些实施例中，还提供了一种计算机程序产品，当计算机程序产品中的指令由服务器的处理器执行时，使得服务器能够执行上述任一实施例所示的文件存储方法。
本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本公开的其它实施方案。本申请旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由下面的权利要求指出。
应当理解的是，本公开并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求来限制。

Claims (10)

1.一种文件存储方法，其特征在于，包括：
写入待存储文件至一个或多个数据分区；
获取各数据分区存储的第一数据的空间占用量；
根据所述空间占用量以及数据块的存储容量，确定存储所述待存储文件所需数据块的数量；
将所述待存储文件发送至所述数量的数据块，所述数量的数据块用于存储所述待存储文件；
所述获取各数据分区存储的第一数据的空间占用量，包括：
获取所述数据分区存储的第一数据的数据行数；
根据所述数据分区关联的元数据，获取所述数据分区的单行数据空间占用量；
根据所述数据分区存储的第一数据的数据行数与所述数据分区的单行数据空间占用量，确定所述数据分区存储的第一数据的空间占用量；
所述根据所述数据分区关联的元数据，获取所述数据分区的单行数据空间占用量，包括：
从所述数据分区关联的元数据中获取所述数据分区的历史数据空间占用量与历史数据行数，所述历史数据空间占用量为写入至所述数据分区的历史数据的空间占用量，所述历史数据行数为所述历史数据的数据行数；
根据所述历史数据空间占用量与所述历史数据行数，确定所述数据分区的单行数据空间占用量。
2.根据权利要求1所述的方法，其特征在于，所述写入待存储文件至一个或多个数据分区，包括：
在将所述待存储文件写入至数据仓库中的情况下，依据预设对象信息对所述待存储文件进行分组，得到分组的数量P，P为正整数；
从所述数据仓库中确定P个数据分区，将所述待存储文件划分至所述P个数据分区中进行存储。
3.根据权利要求1所述的方法，其特征在于，所述根据所述历史数据空间占用量与所述历史数据行数，确定所述数据分区的单行数据空间占用量，包括：
计算所述历史数据空间占用量与所述历史数据行数的比值；
将所述比值作为所述数据分区的单行数据空间占用量。
4.根据权利要求1所述的方法，其特征在于，所述根据所述空间占用量以及数据块的存储容量，确定存储所述待存储文件所需数据块的数量，包括：
获取数据块的存储容量与每一所述数据分区存储的第一数据的空间占用量；
根据所述存储容量与每一所述数据分区存储的第一数据的空间占用量，分别确定存储每一所述数据分区存储的第一数据所需数据块的数量；
根据存储每一所述数据分区存储的第一数据所需数据块的数量，确定存储所述待存储文件所需数据块的数量。
5.一种文件存储装置，其特征在于，包括：
写入模块，被配置为执行写入待存储文件至一个或多个数据分区；
获取模块，被配置为执行获取各数据分区存储的第一数据的空间占用量；
确定模块，被配置为执行根据所述空间占用量以及数据块的存储容量，确定存储所述待存储文件所需数据块的数量；
发送模块，被配置为执行将所述待存储文件发送至所述数量的数据块，所述数量的数据块用于存储所述待存储文件；
所述获取模块，包括：
第一获取单元，被配置为执行获取所述数据分区存储的第一数据的数据行数；
第二获取单元，被配置为执行根据所述数据分区关联的元数据，获取所述数据分区的单行数据空间占用量；
第一确定单元，被配置为执行根据所述数据分区存储的第一数据的数据行数与所述数据分区的单行数据空间占用量，确定所述数据分区存储的第一数据的空间占用量；
所述第二获取单元，包括：
获取子单元，被配置为执行从所述数据分区关联的元数据中获取所述数据分区的历史数据空间占用量与历史数据行数，所述历史数据空间占用量为写入至所述数据分区的历史数据的空间占用量，所述历史数据行数为所述历史数据的数据行数；
确定子单元，被配置为执行根据所述历史数据空间占用量与所述历史数据行数，确定所述数据分区的单行数据空间占用量。
6.根据权利要求5所述的装置，其特征在于，所述写入模块，包括：
分组单元，被配置为执行在将所述待存储文件写入至数据仓库中的情况下，依据预设对象信息对所述待存储文件进行分组，得到分组的数量P，P为正整数；
划分存储单元，被配置为执行从所述数据仓库中确定P个数据分区，将所述待存储文件划分至所述P个数据分区中进行存储。
7.根据权利要求5所述的装置，其特征在于，所述确定子单元被配置为具体执行：
计算所述历史数据空间占用量与所述历史数据行数的比值；
将所述比值作为所述数据分区的单行数据空间占用量。
8.根据权利要求5所述的装置，其特征在于，所述确定模块，包括：
第三获取单元，被配置为执行获取数据块的存储容量与每一所述数据分区存储的第一数据的空间占用量；
第二确定单元，被配置为执行根据所述存储容量与每一所述数据分区存储的第一数据的空间占用量，分别确定存储每一所述数据分区存储的第一数据所需数据块的数量；
第三确定单元，被配置为执行根据存储每一所述数据分区存储的第一数据所需数据块的数量，确定存储所述待存储文件所需数据块的数量。
9.一种服务器，其特征在于，包括：
处理器；
用于存储所述处理器可执行指令的存储器；
其中，所述处理器被配置为执行所述指令，以实现如权利要求1至4中任一项所述的文件存储方法。
10.一种计算机可读存储介质，其特征在于，当所述计算机可读存储介质中的指令由文件存储装置的处理器执行时，使得所述文件存储装置实现如权利要求1至4中任一项所述的文件存储方法。
CN202110352578.3A 2021-03-31 2021-03-31 文件存储方法、装置、服务器及存储介质 Active CN113111038B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202110352578.3A CN113111038B (zh) 2021-03-31 2021-03-31 文件存储方法、装置、服务器及存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202110352578.3A CN113111038B (zh) 2021-03-31 2021-03-31 文件存储方法、装置、服务器及存储介质

Publications (2)

Publication Number Publication Date
CN113111038A CN113111038A (zh) 2021-07-13
CN113111038B true CN113111038B (zh) 2024-01-19

Family

ID=76713711

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202110352578.3A Active CN113111038B (zh) 2021-03-31 2021-03-31 文件存储方法、装置、服务器及存储介质

Country Status (1)

Country Link
CN (1) CN113111038B (zh)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114168081A (zh) * 2021-12-09 2022-03-11 中国电信股份有限公司 高维特征存储方法及装置、存储介质、电子设备
CN114564149B (zh) * 2022-02-25 2024-03-26 上海英方软件股份有限公司 一种数据存储方法、装置、设备及存储介质
CN115454330A (zh) * 2022-08-03 2022-12-09 中勍科技股份有限公司 一种并行管理多个ssd读写的方法

Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106682047A (zh) * 2015-11-11 2017-05-17 杭州华为数字技术有限公司 一种数据导入方法以及相关装置
CN109739828A (zh) * 2018-12-29 2019-05-10 咪咕文化科技有限公司 一种数据处理方法、设备及计算机可读存储介质
CN110134738A (zh) * 2019-05-21 2019-08-16 中国联合网络通信集团有限公司 分布式存储系统资源预估方法、装置
CN110196871A (zh) * 2019-03-07 2019-09-03 腾讯科技（深圳）有限公司 数据入库方法和系统
CN110321329A (zh) * 2019-06-18 2019-10-11 中盈优创资讯科技有限公司 基于大数据的数据处理方法及装置
CN111046045A (zh) * 2019-12-13 2020-04-21 中国平安财产保险股份有限公司 处理数据倾斜的方法、装置、设备及存储介质
CN111221470A (zh) * 2019-10-12 2020-06-02 平安科技（深圳）有限公司 数据处理方法、电子装置及存储介质
CN111694791A (zh) * 2020-04-01 2020-09-22 新华三大数据技术有限公司 一种分布式基础框架中的数据存取方法及装置
CN112579586A (zh) * 2020-12-23 2021-03-30 平安普惠企业管理有限公司 数据处理方法、装置、设备及存储介质

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9495427B2 (en) * 2010-06-04 2016-11-15 Yale University Processing of data using a database system in communication with a data processing framework

Patent Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106682047A (zh) * 2015-11-11 2017-05-17 杭州华为数字技术有限公司 一种数据导入方法以及相关装置
CN109739828A (zh) * 2018-12-29 2019-05-10 咪咕文化科技有限公司 一种数据处理方法、设备及计算机可读存储介质
CN110196871A (zh) * 2019-03-07 2019-09-03 腾讯科技（深圳）有限公司 数据入库方法和系统
CN110134738A (zh) * 2019-05-21 2019-08-16 中国联合网络通信集团有限公司 分布式存储系统资源预估方法、装置
CN110321329A (zh) * 2019-06-18 2019-10-11 中盈优创资讯科技有限公司 基于大数据的数据处理方法及装置
CN111221470A (zh) * 2019-10-12 2020-06-02 平安科技（深圳）有限公司 数据处理方法、电子装置及存储介质
CN111046045A (zh) * 2019-12-13 2020-04-21 中国平安财产保险股份有限公司 处理数据倾斜的方法、装置、设备及存储介质
CN111694791A (zh) * 2020-04-01 2020-09-22 新华三大数据技术有限公司 一种分布式基础框架中的数据存取方法及装置
CN112579586A (zh) * 2020-12-23 2021-03-30 平安普惠企业管理有限公司 数据处理方法、装置、设备及存储介质

Also Published As

Publication number Publication date
CN113111038A (zh) 2021-07-13

Similar Documents

Publication Publication Date Title
CN113111038B (zh) 文件存储方法、装置、服务器及存储介质
US20210182241A1 (en) Utilizing metadata to prune a data set
US9405574B2 (en) System and method for transmitting complex structures based on a shared memory queue
US10853242B2 (en) Deduplication and garbage collection across logical databases
WO2018149271A1 (zh) 数据查询方法、装置及计算设备
CN108509462B (zh) 一种同步活动事务表的方法及装置
US11080207B2 (en) Caching framework for big-data engines in the cloud
CN108196787B (zh) 集群存储系统的配额管理方法以及集群存储系统
US10747739B1 (en) Implicit checkpoint for generating a secondary index of a table
CN111159219B (zh) 一种数据管理方法、装置、服务器及存储介质
US10635650B1 (en) Auto-partitioning secondary index for database tables
WO2020215689A1 (zh) 一种列存储文件的查询方法及查询装置
CN109657009B (zh) 数据预分区存储周期表创建方法、装置、设备和存储介质
US20240061712A1 (en) Method, apparatus, and system for creating training task on ai training platform, and medium
CN111723161A (zh) 一种数据处理方法、装置及设备
JP2022543306A (ja) ブロックチェーンデータ処理の方法、装置、機器及び可読記憶媒体
US9898614B1 (en) Implicit prioritization to rate-limit secondary index creation for an online table
CN112948178A (zh) 一种数据处理方法、装置、系统、设备及介质
JP7440007B2 (ja) データベースをクエリするためのシステム、方法および装置
CN111428114A (zh) Elasticsearch搜索引擎的索引创建方法及装置
CN107832121B (zh) 一种应用于分布式串行长事务的并发控制方法
CN112818021B (zh) 数据请求处理方法、装置、计算机设备和存储介质
CN112711606A (zh) 数据库访问方法、装置、计算机设备和存储介质
CN111427920A (zh) 数据采集方法、装置、系统、计算机设备及存储介质
Koschel et al. Evaluating time series database management systems for insurance company

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant