CN111159176A - 一种海量流数据的存储和读取的方法和*** - Google Patents

一种海量流数据的存储和读取的方法和*** Download PDF

Info

Publication number
CN111159176A
CN111159176A CN201911196972.1A CN201911196972A CN111159176A CN 111159176 A CN111159176 A CN 111159176A CN 201911196972 A CN201911196972 A CN 201911196972A CN 111159176 A CN111159176 A CN 111159176A
Authority
CN
China
Prior art keywords
data
stream data
stream
storage system
storage
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.)
Pending
Application number
CN201911196972.1A
Other languages
English (en)
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.)
Institute of Computing Technology of CAS
Original Assignee
Institute of Computing Technology of CAS
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 Institute of Computing Technology of CAS filed Critical Institute of Computing Technology of CAS
Priority to CN201911196972.1A priority Critical patent/CN111159176A/zh
Publication of CN111159176A publication Critical patent/CN111159176A/zh
Pending legal-status Critical Current

Links

Images

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/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/22—Indexing; Data structures therefor; Storage structures
    • G06F16/221—Column-oriented storage; Management thereof
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/245—Query processing
    • G06F16/2455—Query execution
    • G06F16/24568—Data stream processing; Continuous queries
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/245—Query processing
    • G06F16/2458—Special types of queries, e.g. statistical queries, fuzzy queries or distributed queries
    • G06F16/2474—Sequence data queries, e.g. querying versioned data
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Databases & Information Systems (AREA)
  • General Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Computational Linguistics (AREA)
  • Software Systems (AREA)
  • Fuzzy Systems (AREA)
  • Mathematical Physics (AREA)
  • Probability & Statistics with Applications (AREA)
  • Computing Systems (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本发明提供了一种海量流数据的存储方法，包括：接收来自客户端的流数据；将所述流数据以行式格式存储到分布式段式存储***，形成行式流数据；将所述流数据以列式格式异步地存储到分布式段式存储***，形成列式流数据；所述行式流数据存储完成后向客户端返回确认消息。

Description

一种海量流数据的存储和读取的方法和***
技术领域
本发明属于数据处理领域，尤其涉及一种海量流数据的存储和读取的方法和***。
背景技术
本部分的陈述仅仅是为了提供与本发明相关的背景信息，以帮助理解本发明，这些背景信息并不一定构成现有技术。
流数据是指顺序、大量、快速、连续到达的数据序列，一般情况下，可被视为一个随时间延续而无限增长的动态数据集合。随着互联网、移动互联网、云计算和物联网等技术的广泛普及和迅猛发展，产生于网络监控、传感器网络、航空航天、气象测控和金融服务等领域的流数据呈***式增长。这种增长速度极快、容量不停增大、没有止境的流数据也称为海量流数据。不断增加的数据需要不断扩张的存储空间，而存储容量的大小往往和存储性能呈反比。此外，与静态数据相比，流数据具有实时到达、到达次序独立且速率变化快、数据规模大、一经处理(除非特意存储)很难被再次处理等特点。因此，与流数据相关的应用对数据处理的时效性和吞吐量要求更高。
现有的数据存储***往往侧重于性能的某一方面。例如，Hadoop分布式文件***(HDFS，Hadoop Distribute File System)通过将数据组织为大粒度的数据块，减少了客户端和主控节点(Master)的通信，向用户提供高吞吐量的数据访问，但是HDFS高带宽的优势是以一定的延迟为代价的，当访问请求增多时，单主控节点的框架结构严重限制了HDFS的处理速度。再如，消息存储***Kafka通过使用较小的粒度传输数据，确保了数据写入的低延迟，然而Kafka的传输粒度不适用于海量数据的存储。列存储格式Apache ORC和Parquet基于其列存储结构获得更高的压缩比和查询性能，但是列存储结构集中式的元数据管理方案将其局限于有边界数据，不适合源源不断的流数据。
因此，为了满足海量流数据的高效率存储和读写的需求，至少解决上述问题之一，本发明提出了一种海量流数据的存储和读取的方法和***。
发明内容
本发明的一个方面涉及一种海量流数据的存储方法，包括：接收来自客户端的流数据；将所述流数据以行式格式存储到分布式段式存储***，形成行式流数据；将所述流数据以列式格式异步地存储到分布式段式存储***，形成列式流数据；所述行式流数据存储完成后向客户端返回确认消息。
可选的，其中，所述将所述流数据以列式格式异步地存储到分布式段式存储***，包括：在将所述流数据以行式格式存储到存储***的同时，将所述流数据以列式格式异步地存储到分布式段式存储***，形成列式流数据。
可选的，其中，所述将所述流数据以列式格式异步地存储到分布式段式存储***，包括：先将所述流数据以行式格式存储到分布式段式存储***，形成行式流数据；从所述分布式段式存储***中读取所述行式流数据，将所述行式流数据以列式格式异步地存储到分布式段式存储***，形成列式流数据。
可选的，其中，所述将所述流数据以列式格式异步地存储到分布式段式存储***，包括：提取所述流数据的数据模式；根据所述数据模式将所述流数据按列进行组织；为所述按列组织的流数据中的每一列簇分别开辟一个缓冲区；将所述按列组织的流数据按照列簇分别添加至与所述列簇对应的缓冲区的末尾空位；当所述缓冲区已满时，将所述缓冲区内的流数据写入所述分布式段式存储***，不同列簇的流数据存储在不同的段中。
可选的，还包括：为所述流数据中每个事件设定一个ID；记录所述缓冲区内每个事件的位置信息；当所述缓冲区已满时，将所述缓冲区内所有事件的ID及对应的位置信息附于所述缓冲区头部；将所述缓冲区内所有事件的ID及位置信息连同所述缓冲区内的所有流数据一起写入所述分布式段式存储***的数据单元内，所述缓冲区内所有事件的ID及位置信息位于所述数据单元的头部。
可选的，还包括：将所述列式流数据的元数据存储到分布式键值存储***，所述元数据包括流和段两个级别，其中，所述流级别的元数据包括：构成所述列式流数据的列簇的信息、存储所述列簇的段的信息；所述段级别的元数据包括：所述段内起止事件的位置信息、事件数目、最大值和最小值以及其他相关信息。
可选的，还包括：将所述流数据以列式格式异步地存储到分布式段式存储***后，若在预定的时间阈值内未接收到读取所述行式流数据的请求时，将所述行式流数据从所述分布式段式存储***中删除。
本发明的另一方面涉及一种基于上述存储方法进行的海量流数据的读取方法，包括：接收客户端读取数据的请求；根据所述读取数据的请求在所述分布式键值存储***中的查询所述数据的元数据；根据所述元数据从所述分布式段式存储***中读取所述数据并返回客户端。
可选的，还包括：根据所述数据的元数据确定所述数据的起始位置信息；提前读取所述数据起始位置后的数据并置入数据缓存区；从所述数据缓存区内读取所述数据。
本发明的另一方面涉及一种用于海量流数据的存储***，包括服务器和存储设备，能够用于上述任一所述的方法。
与现有技术相比，本发明的优点在于：
提供一种高吞吐量、低延迟、高效率查询的存储和读写方法和***。
附图说明
以下参照附图对本发明实施例作进一步说明，其中：
图1为本发明一个实施例的分层***架构示意图；
图2为Apache BookKeeper分布式段式存储示意图；
图3为DistributedLog软件栈结构示意图；
图4为本发明一个实施例的海量流数据的存储方法；
图5为本发明一个实施例的将流数据进行按列组织并写入存储***的示意图；
图6(a)为本发明一个实施例的流级别的元数据在一级K/V表中的存储结构示意图；
图6(b)为本发明一个实施例的段级别的元数据在二级K/V表中的存储结构示意图；
图7为本发明一个实施例的流数据存储方法的示意图；
图8为本发明另一个实施例的流数据的存储方法；
图9为本发明一个实施例中在列式流存储完成后删除行式流的示意图；
图10为本发明一个实施例的海量流数据的读取方法的示意图；
图11示出了本发明一个实施例中流数据的读取方法的示意图；
图12(a)为本发明一个实施例的存储***与Kafka写入性能对比图；
图12(b)为本发明一个实施例的存储***与Kafka读取性能对比图；
图12(c)为本发明一个实施例的存储***与Kafka、Parquet查询性能对比图。
具体实施方式
为了使本发明的目的，技术方案及优点更加清楚明白，以下结合附图通过具体实施例对本发明进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本发明，并不用于限定本发明。
本发明中的海量流数据的存储和读取方法和***是在分层***框架下运行的。图1示出了本发明一个实施例中的分层***架构示意图。如图 1所示，该框架可分为三层，从下到上依次为存储层，核心服务层以及应用层。其中，存储层用于提供基础的存储服务；核心服务层连接存储层和应用层，用于将应用层产出或接收到的流数据传递到存储层，并对数据进行必要的组织和管理；应用层上运行着各类数据分析应用，例如可以包括全时域数据分析、流计算或批处理等。
在一个实施例中，存储层可以采用Apache分布式段式存储*** BookKeeper进行持久化。BookKeeper是一个针对实时工作负载优化的可扩展、高容错和低延迟的存储***。一个BookKeeper集群可以由多个存储节点(bookies)和元数据(metadata)存储构成。其中，bookies用于提供一系列独立的存储服务(sever)，每个存储节点负责具体的数据存储。BookKeeper***具有很好的可扩展性，当需要增加容量的时候，只需从 BookKeeper集群里自动选出新的存储节点并添加即可。新加入的存储节点由于剩余的空间大，会被优先使用，更多的接收新的数据，而且其中不会涉及到任何已有数据的拷贝和搬移。此外，BookKeeper采用多数投票并行复制算法(quorum-vote parallel replication algorithm)，对所有数据都会复制和存储相同的多份副本到其他bookie中。如果某个存储节点失效，可以从集群中其他的存储节点中并发读取数据，并对失效节点的数据自动进行数据的恢复，不会对前端的服务有影响。quorum-vote可以由客户端设置，确保低延迟复制数据。BookKeeper集群中的元数据存储通常使用 ZookKeeper，用于服务发现和元数据管理。ZookKeeper存储与段(segments，在BookKeeper内部也被称作ledgers)相关的元数据，包括当前可用的存储节点，段分布的位置等。
使用BookKeeper存储数据前，通常需要设定三个参数，即最小节点数量(ensemblesize，表示用户要使用几个bookies)、最小写入数(write quorum，表示写入的数据要保留几个备份)和最小响应数(ack quorum，表示有几个写入操作成功后就返回消息)，当完成指定的最小响应数后， bookies认为写入成功，返回写入成功的消息。
图2示出了BookKeeper分布式段式存储示意图。如图2所示， BookKeeper以段(segments/ledgers)为存储的基本单元，一个段是一个独立数据集合，包含有若干个数据单元(entry)。每个段都会被均匀分散到 BookKeeper集群中，以保证数据和服务在多个存储节点上的均匀性。每个段都是一个递增的数据结构，通过单一写入模式保持数据写入，并通过上述复制机制被复制到其他存储节点上。
BookKeeper内部除了基础的段存储，还提供流(stream)和表(table) 两种服务，其中，流服务是通过一定的方式，将一组段按照顺序共同管理起来形成一个源源不断的流，而表用来存取流计算的中间状态。 BookKeeper通过提供流和表两种服务，可以很方便的满足在实时数据处理中的绝大部分的存储需求。
综上，BookKeeper基于其高写入可用(即存储不局限于单个服务器的限制，总bookies容量足够就能写入成功)和高读取可用(即能够在集群中分散读取的流量)等特性，能够为本发明提供高吞吐、低延迟、持久性、可扩展、一致性的存储服务。
存储层之上的核心服务层用于进行数据的组织和管理，例如可以包括数据格式管理、段状态管理、元数据管理以及生命周期管理等。本发明中海量流数据的存储和读取方法主要应用于核心服务层。
由于对流数据的访问往往只涉及数据部分属性，例如使用特定属性进行模型训练、对特定属性进行即席查询(Ad-hoc Query)等，因此使用列式存储流数据可以快速查询流数据相关属性的数据记录，并只返回与属性相关的值即可，显著减少CPU和I/O的消耗，减少查询响应时间，提升查询效率。然而列式存储中需要对流数据中每个事件均进行字段提取并统计各个字段信息，在相同资源的情况下，列式存储速度慢于行式存储，延迟时间较长。本发明采用行式存储和列式存储并行的存储模式，并在行式存储完成后立即向客户端返回确认消息，可以降低延迟并提升查询效率。
行式存储，又称行式格式存储，是指数据按照行数据为基础逻辑存储单元进行存储，同一行中的数据在存储介质中以连续的存储形式存在。以行式格式存储的流数据称为行式流数据，简称行式流。
在一个实施例中，可以使用Apache DistributedLog将接收到的流数据按序写入BookKeeper中形成行式流。DistributedLog是一个高性能的日志复制服务，其利用BookKeeper提供的流服务，通过分类维护日志记录的序列(sequences of records)形成行式流，也称日志流(Log stream)，然后基于配置好的策略，要么是可配置的时间段(例如两个小时)，要么是可配置的最大规模(例如128M)，将数据流分割为同等大小的段(segments)，均匀分布到分段存储节点(bookies)上。
图3示出了DistributedLog软件栈结构示意图。如图3所示， DistributedLog构建在BookKeeper存储层之上的核心服务层，核心服务层进一步被细分为核心层和无状态的服务层。在核心层中，将记录写入 DistributedLog的进程称为写者(writer)，从DistributedLog中读取并处理记录的进程称为读者(reader)。每条数据记录都是一个字节序列，writer 将记录按照序列写入到它们选择的行式流(Log stream)中，并分配一个唯一的序列号(DLSN，DistributedLog Sequence Number)。除了DLSN外，应用程序还可以在构建数据记录的时候设置自己的序列号(Transaction ID)。当读者从它们选择的行式流中读取记录时，会从某个给定的位置开始并严格按照行式流的顺序进行读取，这个给定的位置可以是DLSN，也可以是Transaction ID。同一个行式流中，不同的读者可以在不同的起始位置读取记录。核心层支持单写者、多读者的语义，即对于某个行式流，在给定的时间点上，只能有一个激活的写者，但可以存着多个激活的读者。在核心层之上的服务层包含写入代理(write proxy)和读取代理(read proxy)，分别管理多个写者和读者，并接收客户端大规模数据的扇入(fan-in) 和扇出(fan-out)。读取代理也可以将数据记录放到缓存中，优化读者的读取路径，以应对多个读者读取同一行式流的情况。
列式存储是相对于行式存储而言的，又称列式格式存储，是指按照列数据为基础逻辑存储单元进行存储的，同一列中的数据在存储介质中以连续的存储形式存在。以列式格式存储的流数据称为列式流数据，简称列式流。
在一个实施例中，在接收到来自客户端的流数据后，可以同时进行行式格式存储形成行式流数据和列式格式存储形成列式流数据，并在行式流数据存储完成后立即向客户端返回确认消息。
图4示出了本发明一个实施例中海量流数据的存储方法，具体包括以下步骤：
步骤410，服务器接收来自客户端的流数据。
本发明中存储方法可以应用于服务器端，当客户端通过远程计算机发送RemoteProcedure Call(RPC)请求程序请求写入流数据时，服务器可以接收请求并接收来自客户端(包括第三方平台)的流数据，例如可以是各类日志文件、网购数据、游戏内玩家活动、社交网站信息、金融交易信息或地理空间服务以及来自数据中心内所连接设备或仪器的遥测数据等。流数据通常具有规模较大、按序持续到达等特点，通常需要按记录或根据滑动时间窗口按顺序对流数据进行递增式、近实时处理。
流数据由不同事件构成的，每个事件包含多个属性。随着时间的前进，新的事件不断产生并被持续汇入到流数据中。流数据的数据模式(schema) 表示每个事件的结构，由多个字段构成，每个字段表示一个属性，具有明确的类型。
步骤420，将流数据按照行式格式存储到存储***中，形成行式流数据。
如上所述，行式存储可以采用DistributedLog***存储接收到的流数据形成行式流，在此不再赘述。
步骤430，同时提取该流数据的数据模式，根据其数据模式将流数据按列组织，并异步地写入BookKeeper形成列式流数据。
在一个实施例中，服务器可以在DistributedLog存储行列流的同时，将接收到的流数据按列组织，根据流数据的数据模式从中提取出各个字段形成不同列(column)，列可以被划分为多个列簇(column family)，同一列簇的数据可以被连续地持久化到BookKeeper的存储节点的同一段中。
图5示出了一个实施例中将流数据进行按列组织并写入存储***的示意图。如图5所示，服务器可以在内存中先将接收到的流数据进行初始化，提取其数据模式，将具有相同属性的数据组织成一列，例如键(key)列或时间戳(time stamp)列(记录数据的写入时间)等。列又可以被划分成若干个列簇，可以将关联性较强或具备共同IO特性的列划分为一个列簇。列簇名可以作为前缀使用在列名中以方便检索记录。同一列簇的数据通常可以按序被持久化到BookKeeper中同一段中。当数据量较大，考虑到整个存储集群的存储空间和负载状况，服务器端需要定期切换段，此时，同一列簇的数据也可能被持久化到不同的段中。每个段都是一个递增的数据结构，同一列簇的数据可以通过单一写入模式依次写入各个数据单元中。当某一列簇的数据存储完毕或段中所有数据单元都被写满后，该段被均匀分散到BookKeeper集群中，以保证数据和服务在多个存储节点上的均匀性。
按列组织的流数据可以采用聚集写入的策略。在一个实施例中，服务器可以在内存中为按列组织的流数据中的每个列簇开辟一个大小合适的缓冲区。当数据到来后可以先存入缓冲区的末尾空位，待缓冲区存满，将缓冲区内的所有数据一起持久化到bookies中，然后清空缓冲区继续使用。若缓冲区未满，则暂不写入存储层。在一个实施例中，将缓冲区数据写入到存储设备时，可以采用适合存储设备IO传输的粒度，以获得更高的写入效率。
在一个实施例中，在使用缓冲区聚集写入按列组织的流数据时，还可以为流数据中每个事件赋予一个唯一的ID，当缓冲区已满后，将该缓冲区内事件的ID及其位置信息附于缓冲区头部，并与当前缓冲区内的所有数据一起写入bookie的数据单元中。可以将缓冲区设置成与数据单元大小一致，则当缓冲区内的头部信息及其所有数据存入数据单元时，该头部信息也位于数据单元的头部。通过将事件位置到段式存储***存储位置的映射记录到数据单元的头部信息中，可以快速定位到流数据的任意位置，减少了使用键值***存储位置映射信息的开销，读取任意位置时进行二分查找可得到存储位置。
在一个实施例中，可以将列式存储中产生的流级别元数据和段级别的元数据存储在分布式键值存储***(K/V,Key-Value Storage System)，其中，流级别的元数据为一级元数据，是指将流数据按列组织并存储到段中产生的中间数据；段级别的元数据为二级元数据，用于记录存储列簇的段的统计信息。K/V存储***是以表的形式存储元数据的，每个K-V对确定的单元内存储与之对应的元数据的唯一值。图6(a)示出了一个实施例中流级别的元数据在一级K/V表中的存储结构示意图。如图6(a)所示，表中每一行的主键(Key)为各个数据流的ID(简称流ID)，列可以包括构成数据流的列簇以及存储列簇的段，表中每个行、列确定的单元的值即为各个数据流及其对应的列簇及段的信息。图6(b)示出了一个实施例中段级别的元数据在二级K/V表中的存储结构示意图。如图6(b)所示，表中每一行的主键(Key)为各个段的ID(简称段ID)，列可以包括段内的起止事件的ID及位置、事件数目以及最大及最小值等。将流级别和段级别的元数据存储于分布式键值***，既克服了传统的列式存储格式只能将元数据存储于文件尾部的局限，又可以充分发挥键值***点查询的高效，便于用户快速访问元数据进行数据读取。
步骤440，完成行式流数据的存储后立即向客户端返回存储成功的消息。
基于DistributedLog能够同时应对上千客户端每秒大量的读取和写入操作，提供毫秒级延迟，在完成行式流存储后立即向客户端返回存储成功的消息可以有效避免因列式存储而产生的延迟。
图7示出了本发明一个实施例中流数据存储方法的示意图，如图7所示，服务器接收来自客户端的数据后，使用DistributedLog将数据写入存储设备形成行式流数据，完成后立即向客户端返回确认消息；同时服务器在内存中提取流数据的数据模式并根据其数据模式将流数据按列组织存入缓冲区，当缓冲区存满后写入以列簇为基础的段式存储设备中，列式存储中产生的元数据可以存入分布式键式存储***，当需要切换段式，将新的段的信息添加到键式存储***中。
当流数据的写入量较大时，由于列式流的存储较慢，且会消耗过多的 CPU资源，可能造成大量数据积压在内存中，因此需要对列式流数据的写入资源进行限制。在一个实施例中，可以将行式流的读者作为实时数据的中转，并使用单线程拉取实时数据，从而避免大量数据快速到达服务器端而无法快速处理的问题。图8示出了本发明另一个实施例的流数据的存储方法，如图8所示，服务器接收到来自客户端的流数据后，可以先将所述流数据以行式格式存储到DistributedLog中形成行式流数据，再使用 DistributedLog中的读者进程从存储***中读取所述行式流数据作为列式存储的数据来源，提取所述行式流数据的数据模式，根据所述数据模式将所述行式流数据在内存中按列组织再以列式格式写入bookie中。可以为每个列簇分配一个写入线程，由于列式流采用聚集写入的策略，只有聚集到一定的数据量后才进行数据写入，因此单线程获取数据然后进行列式组织和存储对列式流的吞吐影响不大。
由于本发明中采用行式存储和列式存储共存的存储方法，存储***中同时存储有行式流数据和列式流数据。行式流和列式流长期共存的会占用大量存储空间，浪费存储资源。在一个实施例中，在完成列式流的存储后，若服务器在预定的时间阈值内未接收到读取所述行式流数据的请求时，可以将所述行式流数据从所述存储***中删除，以保持流数据的完整性，并节省存储空间。图9示出了一个实施例中在列式流存储完成后删除行式流的示意图。如图9所示，服务器先将接收到的流数据进行行式存储形成行式流，然后将行式流按列组织并存储为列式流，经过一段时间后(例如Tn时刻)，可以将行式流删除，***中仅存储有列式流数据。
当服务器接收到来自客户端的读取数据的请求时，在行式流和列式流共存的情况下，既可以从行式流中读取数据，也可以从列式流中读取数据。由于行式流的存储比列式流的存储更加迅速，在行式流存储完成后，可能列式流的存储还未完成，这种情况下，服务器可以优先从行式流中读取数据以快速响应客户端的请求，有效解决数据读取中的延时问题。当行式流数据被删除后，从列式流数据中读取数据并返回请求结果。
图10示出了本发明一个实施例中海量流数据的读取方法，如图10所示，服务器接收到客户端从远程计算机发来的RPC读取数据请求后，可以先从分布式键式存储***中查询所请求数据的元数据，根据其元数据确定所请求数据的位置，并从段式存储设备中读取该数据后返回客户端。来自客户端的读取请求中例如可以包括所请求数据所属的流数据的信息、属性信息或所属的事件的信息，根据所属的流数据的信息或所属的事件的信息可以确定所请求数据所属的流ID、列簇以及事件ID，根据一级、二级K/V 表中的流级别的元数据和段级别的元数据，以及段的数据单元头部信息中的事件ID及其位置信息，可以有效定位所请求数据的位置。
通常情况下，用户按列读取数据时是对特定范围内的全部数据进行读取。因此为了提高按列读取数据的效率，在一个实施例中，服务器可以采用主动预取的策略，即在使用上述读取方法定位到特定数据的起始位置后，提前从段式存储***中读取下一批数据放在缓存中。图11示出了本发明一个实施例中流数据的读取方法的示意图，如图11所示，服务器收到来自客户端的读取数据的请求后，可以先在缓存中查询，若所请求的数据存在缓存中，则直接从缓存中读取数据并返回客户端，若所请求的数据不在缓存中，再从分布式键式存储***中查询所请求数据的元数据，根据其元数据从段式存储设备中读取该数据并返回客户端。
主动预取的方法可以有效减少读取过程中的时间延迟，但是需要使用大量内存资源。在一个实施例中，服务器对主动预取使用的资源进行了限制，使用资源中控组件控制集群允许的总的预取数目，并通过内部的计数器进行记录。每当创建一个流的列式读者时，服务器会根据用户读取的列创建多个列簇读者，每个列簇读者会向资源中控组件申请用户设置的预取数目，资源中控组件返回能够预读取的数据单元数目并将内部维护的计数器减去相应的数目；当关闭一个列式读者时，服务器会更新资源中控组件，资源中控组件接下来会对其内部的计数器加上相应的数目。这样可以避免当同时服务大量的列式读取时，主动预取占用的内存资源导致其他功能模块受影响的情况发生。
本发明支持服务器端的灵活部署，既可以将服务器端部署到独立的节点，又可以将其和分布式段式存储***的存储节点部署在同一个节点。将服务器端和分布式段式存储***的存储节点部署在同一个节点时，能够减少服务器端和段式存储***间的跨网络消息传输，一定程度上降低延迟。随着高速网络的快速发展，通过本地存储设备存取数据和通过网络存取数据的延迟已经相差不大，因此在高速网络环境下，也可以选择将服务器端部署在单独的节点，以便于对不同类型的节点进行分别管理。
在本发明的一个实施例中，可以以计算机程序的形式来实现本发明。计算机程序可以存储于各种存储介质(例如，硬盘、光盘、闪存等)中，当该计算机程序被处理器执行时，能够用于实现本发明中的存储方法和读取方法。实现本发明中上述存储和读取方法的计算机程序名为“CStream”。
经实验测试，CStream在写入、读取以及查询方面的能远远优于同类存储***。图12(a)示出了写性能对比表(3复本)，每个流含6个字段，共38字节，如图12(a)所示，对于事件流的写入，无论是单个流还是多个流，CStream的吞吐量和延迟都优于Kafka；图12(b)示出了读性能对比表(3复本)，每个流含6个字段，共38字节，图12(b)所示，对于事件流的读取，无论是单个流还是多个流，CStream的吞吐量和延迟也优于Kafka；图12(c)示出了TPC-H查询性能(SF＝300)，如图12(c)所示，当数据刚刚被加载进CStream时，其查询性能与Kafka接近，因为此时的数据还是行式存储。随着时间推移，CStream把越来越多的数据转换成了列式存储，其查询性能越来越接近Parquet(Parquet是基于HDFS的列存储)，优于Kafka。
在本发明的另一个实施例中，可以以电子设备的形式来实现本发明。该电子设备包括处理器和存储器，在存储器中存储有计算机程序，当该计算机程序被处理器执行时，能够用于实现本发明的方法。
本文中针对“各个实施例”、“一些实施例”、“一个实施例”、或“实施例”等的参考指代的是结合所述实施例所描述的特定特征、结构、或性质包括在至少一个实施例中。因此，短语“在各个实施例中”、“在一些实施例中”、“在一个实施例中”、或“在实施例中”等在整个本文中各处的出现并非必须指代相同的实施例。此外，特定特征、结构、或性质可以在一个或多个实施例中以任何合适方式组合。因此，结合一个实施例中所示出或描述的特定特征、结构或性质可以整体地或部分地与一个或多个其他实施例的特征、结构、或性质无限制地组合，只要该组合不是不符合逻辑的或不能工作。本文中出现的类似于“根据A”、“基于A”、“通过A”或“使用A”的表述意指非排他性的，也即，“根据A”可以涵盖“仅仅根据A”，也可以涵盖“根据A和B”，除非特别声明或者根据上下文明确可知其含义为“仅仅根据A”。在本申请中为了清楚说明，以一定的顺序描述了一些示意性的操作步骤，但本领域技术人员可以理解，这些操作步骤中的每一个并非是必不可少的，其中的一些步骤可以被省略或者被其他步骤替代。这些操作步骤也并非必须以所示的方式依次执行，相反，这些操作步骤中的一些可以根据实际需要以不同的顺序执行，或者并行执行，只要新的执行方式不是不符合逻辑的或不能工作。
由此描述了本发明的至少一个实施例的几个方面，可以理解，对本领域技术人员来说容易地进行各种改变、修改和改进。这种改变、修改和改进意于在本发明的精神和范围内。虽然本发明已经通过优选实施例进行了描述，然而本发明并非局限于这里所描述的实施例，在不脱离本发明范围的情况下还包括所作出的各种改变以及变化。

Claims (10)

1.一种海量流数据的存储方法，包括：
接收来自客户端的流数据；
将所述流数据以行式格式存储到分布式段式存储***，形成行式流数据；
将所述流数据以列式格式异步地存储到分布式段式存储***，形成列式流数据；
所述行式流数据存储完成后向客户端返回确认消息。
2.根据权利要求1所述的方法，其中，所述将所述流数据以列式格式异步地存储到分布式段式存储***，包括：
在将所述流数据以行式格式存储到存储***的同时，将所述流数据以列式格式异步地存储到分布式段式存储***，形成列式流数据。
3.根据权利要求1所述的方法，其中，所述将所述流数据以列式格式异步地存储到分布式段式存储***，包括：
先将所述流数据以行式格式存储到分布式段式存储***，形成行式流数据；
从所述分布式段式存储***中读取所述行式流数据，将所述行式流数据以列式格式异步地存储到分布式段式存储***，形成列式流数据。
4.根据权利要求1所述的方法，其中，所述将所述流数据以列式格式异步地存储到分布式段式存储***，包括：
提取所述流数据的数据模式；
根据所述数据模式将所述流数据按列进行组织；
为所述按列组织的流数据中的每一列簇分别开辟一个缓冲区；
将所述按列组织的流数据按照列簇分别添加至与所述列簇对应的缓冲区的末尾空位；
当所述缓冲区已满时，将所述缓冲区内的流数据写入所述分布式段式存储***，不同列簇的流数据存储在不同的段中。
5.根据权利要求4所述的方法，还包括：
为所述流数据中每个事件设定一个ID；
记录所述缓冲区内每个事件的位置信息；
当所述缓冲区已满时，将所述缓冲区内所有事件的ID及对应的位置信息附于所述缓冲区头部；
将所述缓冲区内所有事件的ID及位置信息连同所述缓冲区内的所有流数据一起写入所述分布式段式存储***的数据单元内，所述缓冲区内所有事件的ID及位置信息位于所述数据单元的头部。
6.根据权利要求1所述的方法，还包括：
将所述列式流数据的元数据存储到分布式键值存储***，所述元数据包括流和段两个级别，其中，
所述流级别的元数据包括：构成所述列式流数据的列簇的信息、存储所述列簇的段的信息；
所述段级别的元数据包括：所述段内起止事件的位置信息、事件数目、最大值和最小值以及其他相关信息。
7.根据权利要求1所述的方法，还包括：
将所述流数据以列式格式异步地存储到分布式段式存储***后，若在预定的时间阈值内未接收到读取所述行式流数据的请求时，将所述行式流数据从所述分布式段式存储***中删除。
8.一种基于权利要求6所述的存储方法进行的海量流数据的读取方法，包括：
接收客户端读取数据的请求；
根据所述读取数据的请求在所述分布式键值存储***中的查询所述数据的元数据；
根据所述元数据从所述分布式段式存储***中读取所述数据并返回客户端。
9.根据权利要求8所述的读取方法，还包括：
根据所述数据的元数据确定所述数据的起始位置信息；
提前读取所述数据起始位置后的数据并置入数据缓存区；
从所述数据缓存区内读取所述数据。
10.一种用于海量流数据的存储***，包括服务器和存储设备，能够用于实现权利要求1-9中任一所述的方法。
CN201911196972.1A 2019-11-29 2019-11-29 一种海量流数据的存储和读取的方法和*** Pending CN111159176A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201911196972.1A CN111159176A (zh) 2019-11-29 2019-11-29 一种海量流数据的存储和读取的方法和***

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201911196972.1A CN111159176A (zh) 2019-11-29 2019-11-29 一种海量流数据的存储和读取的方法和***

Publications (1)

Publication Number Publication Date
CN111159176A true CN111159176A (zh) 2020-05-15

Family

ID=70556253

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201911196972.1A Pending CN111159176A (zh) 2019-11-29 2019-11-29 一种海量流数据的存储和读取的方法和***

Country Status (1)

Country Link
CN (1) CN111159176A (zh)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111930751A (zh) * 2020-08-31 2020-11-13 成都四方伟业软件股份有限公司 一种时序数据的存储方法及装置
CN112257051A (zh) * 2020-12-23 2021-01-22 畅捷通信息技术股份有限公司 一种基于微信的选择数据处理方法、装置、介质
CN113608674A (zh) * 2021-06-25 2021-11-05 济南浪潮数据技术有限公司 一种实现分布式块存储***读写的方法及装置
WO2022166071A1 (zh) * 2021-02-04 2022-08-11 华为技术有限公司 一种流数据存储***中流数据访问方法及装置
CN115563128A (zh) * 2022-12-07 2023-01-03 深圳市加推科技有限公司 社交数据的管理方法、装置、设备及介质

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101996250A (zh) * 2010-11-15 2011-03-30 中国科学院计算技术研究所 一种基于Hadoop的海量流数据存储和查询方法及***
CN102298641A (zh) * 2011-09-14 2011-12-28 清华大学 一种基于键值库的文件与结构化数据统一存储方法
CN102332027A (zh) * 2011-10-15 2012-01-25 西安交通大学 一种基于Hadoop的海量非独立小文件关联存储方法
CN105095247A (zh) * 2014-05-05 2015-11-25 中国电信股份有限公司 符号数据分析方法和***
CN109542889A (zh) * 2018-10-11 2019-03-29 平安科技（深圳）有限公司 流式数据列存储方法、装置、设备和存储介质
CN110362572A (zh) * 2019-06-25 2019-10-22 浙江邦盛科技有限公司 一种基于列式存储的时序数据库***

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101996250A (zh) * 2010-11-15 2011-03-30 中国科学院计算技术研究所 一种基于Hadoop的海量流数据存储和查询方法及***
CN102298641A (zh) * 2011-09-14 2011-12-28 清华大学 一种基于键值库的文件与结构化数据统一存储方法
CN102332027A (zh) * 2011-10-15 2012-01-25 西安交通大学 一种基于Hadoop的海量非独立小文件关联存储方法
CN105095247A (zh) * 2014-05-05 2015-11-25 中国电信股份有限公司 符号数据分析方法和***
CN109542889A (zh) * 2018-10-11 2019-03-29 平安科技（深圳）有限公司 流式数据列存储方法、装置、设备和存储介质
CN110362572A (zh) * 2019-06-25 2019-10-22 浙江邦盛科技有限公司 一种基于列式存储的时序数据库***

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
VLADIMIR NIKULIN: "On the method for data streams aggregation to predict shoppers loyalty", 《2015 INTERNATIONAL JOINT CONFERENCE ON NEURAL NETWORKS (IJCNN)》, 1 October 2015 (2015-10-01) *
赵永霞: "数据库原理与应用", 华中科技大学出版社, pages: 219 *
陈绍斌: "大规模流式数据存储研究与应用", 《信息科技辑》 *
陈绍斌: "大规模流式数据存储研究与应用", 《信息科技辑》, 15 August 2018 (2018-08-15) *

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111930751A (zh) * 2020-08-31 2020-11-13 成都四方伟业软件股份有限公司 一种时序数据的存储方法及装置
CN112257051A (zh) * 2020-12-23 2021-01-22 畅捷通信息技术股份有限公司 一种基于微信的选择数据处理方法、装置、介质
CN112257051B (zh) * 2020-12-23 2021-03-19 畅捷通信息技术股份有限公司 一种基于微信的选择数据处理方法、装置、介质
WO2022166071A1 (zh) * 2021-02-04 2022-08-11 华为技术有限公司 一种流数据存储***中流数据访问方法及装置
CN113608674A (zh) * 2021-06-25 2021-11-05 济南浪潮数据技术有限公司 一种实现分布式块存储***读写的方法及装置
CN113608674B (zh) * 2021-06-25 2024-02-23 济南浪潮数据技术有限公司 一种实现分布式块存储***读写的方法及装置
CN115563128A (zh) * 2022-12-07 2023-01-03 深圳市加推科技有限公司 社交数据的管理方法、装置、设备及介质

Similar Documents

Publication Publication Date Title
US11153380B2 (en) Continuous backup of data in a distributed data store
CN109213772B (zh) 数据存储方法及NVMe存储***
CN111159176A (zh) 一种海量流数据的存储和读取的方法和***
US10579610B2 (en) Replicated database startup for common database storage
US9946735B2 (en) Index structure navigation using page versions for read-only nodes
CN107423422B (zh) 基于网格的空间数据分布式存储及检索方法和***
KR102564170B1 (ko) 데이터 객체 저장 방법, 장치, 및 이를 이용한 컴퓨터 프로그램이 저장되는 컴퓨터 판독가능한 저장 매체
EP2735978B1 (en) Storage system and management method used for metadata of cluster file system
US8285686B2 (en) Executing prioritized replication requests for objects in a distributed storage system
US20170024315A1 (en) Efficient garbage collection for a log-structured data store
CN113377868B (zh) 一种基于分布式kv数据库的离线存储***
CN103595797B (zh) 一种分布式存储***中的缓存方法
CN107832423B (zh) 一种用于分布式文件***的文件读写方法
CN107798130A (zh) 一种分布式存储的快照方法
CN103246616A (zh) 一种长短周期访问频度的全局共享缓存替换方法
CN107368608A (zh) 基于arc替换算法的hdfs小文件缓存管理方法
WO2011064742A1 (en) Super-records
CN111984191A (zh) 一种支持分布式存储的多客户端缓存方法及***
CN108776690B (zh) 基于分层治理的hdfs分布式与集中式混合数据存储***的方法
CN112463073A (zh) 一种对象存储分布式配额方法、***、设备和存储介质
KR102127785B1 (ko) 효율적인 인덱싱을 제공하기 위한 방법, 장치 및 컴퓨터-판독가능 매체에 포함된 컴퓨터 프로그램
WO2022267508A1 (zh) 元数据压缩方法及装置
WO2024021470A1 (zh) 一种跨区域的数据调度方法、装置、设备及存储介质
US11341163B1 (en) Multi-level replication filtering for a distributed database
CN115509437A (zh) 存储***、网卡、处理器、数据访问方法、装置及***

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
RJ01 Rejection of invention patent application after publication

Application publication date: 20200515

RJ01 Rejection of invention patent application after publication