一种面向应用观测的流式存储方法及装置

摘要

本申请公开了一种面向应用的流式存储方法及装置，可以获取待存储数据流，并将待存储数据流包括的每个流存储至内存，内存包括块缓存、可变内存表和不可变内存表。待存储流在内存中的流转顺序依次为块缓存。可变内存表和不可变内存表，待存储数据流包括日志、指标或者调用日志中的其中一项或者多项；将不可变内存表中的数据刷到存储介质，并形成至少一个Segment存储于第一存储区域；将至少一个段(Segment)中每个段分别对应的存储区域的地址、每个段对应的键Key、以及每个段对应的段标识，存储至存储介质中的第二存储区域中。该方案可以避免重复写入的问题，并且可以支持顺序读取数据，从而提升了存储介质的访问性能。

说明书

技术领域

本申请涉及存储领域，特别是涉及一种面向应用观测的流式存储方法及装置。

背景技术

在IT系统中，Logs、Traces、Metrics是作为应用可观测的三个重要指标，基本可满足各类监控、告警、分析、问题排查等需求，但实际场景中它们拥有各自的适用形态。

在传统模式下，为了实现为了针对这三种维度的数据进行统一分析、展示，一般系统维度是Metrics，一般采用Prometheus组件收集、时序数据库TSDB存储；针对LOG或者Trace，则主要是基于消息中间件(Kafka)，Elasticsearch等完成采集后进行数据的存储。可以很直观的看出，这套架构中依然采用两条技术栈，存储层依然是相互隔离，这使得Metrics、Logging、Tracing三种指标分散在不同存储组件中，无法进行统一访问和有效聚合，这为后续对应用的观测和分析带来了挑战。

流存储的出现，将流和存储看作一体，实现了对Logs、Traces、Metrics等可观测性数据的一体化采集、存储、分析，完成了一套系统去解决所有类型数据。

发明内容

本申请实施例提供了一种面向应用观测的流式存储方法及装置。

第一方面，本申请实施例提供了一种面向应用观测的流式存储方法，所述方法包括：

获取待存储数据流，并将所述待存储数据流Stream包括的每个流存储至内存，所述内存包括块缓存block cache、可变内存表Active Memtable和不可变内存表ImmutableMemtable所述待存储流在内存中的流转顺序依次为block cache、Active Memtable、Immutable Memtable，所述待存储数据流包括日志log、指标Metrics或者调用日志Traces中的其中一项或者多项；

将所述Immutable Memtable的数据刷到存储介质，并形成至少一个Segment存储于第一存储区域；

将所述至少一个Segment中每个Segment分别对应的存储区域的地址、所述每个Segment对应的键Key、以及所述每个Segment对应的Segment标识，存储至所述存储介质中的第二存储区域中。

可选的，

所述第一存储区域采用分层、分片结构；

所述分层是指将第一存储区域划分为多个级(Level)，Level级数与该Level存储的数据的热度反相关，所述至少一个Segment存储在所述多个Level中的至少一个Level中；不同Level级采用不同的存储介质，Level级数与存储介质的价格反相关，以实现持久化存储、长期存储在不影响查询性能的前提下的混合部署；

所述分片是指不同存储数据流Stream的数据以段Segment为单位分布在不同Level，一个Stream包含多个Segment，每个Level中包括一个Stream对应的多个Segment，其中，一个或多个存储数据流Stream形成了独立的对象集合Schema，不同Schema对应不同维度的观测数据，所述Schema由用户定义。

可选的，所述Key还用于指示所述待存储数据流的版本。

可选的，所述待存储数据流的版本信息，包括：

所述Key产生的时间戳；

针对Update操作，数据因具备最新的版本信息使得在Segment下沉过程中，通过所述Key版本合并完成旧版本数据的删除；

针对Delete操作，则是通过将版本信息定义为无效信息system unvalid，使得在第二存储区域中的标识更新，完成了数据的逻辑删除。

可选的，所述将所述待存储数据流Stream包括的每个流存储至内存，包括：

将所述待存储数据流和无效数据存储至内存中的第一缓存行中，所述内存中的第一缓存行所能容纳的数据量大于所述待缓存数据流对应的数据量，所述待存储数据流对应的数量和所述无效数据的数据流之和，等于所述第一缓存行所能容纳的数据量。

可选的，所述待存储数据流中包括所述待存储数据流的数据来源。

可选的，所述待存储数据流，通过如下方式获得：

采集原始数据；

为所述原始数据添加数据来源；

根据所述原始数据和所述原始数据的数据来源，得到所述待存储数据流。

可选的，所述原始数据包括以下任意一项或者多项：

log、Metrics或者Traces。

可选的，所述待存储数据流对应的数据来源，包括：

log、Metrics以及Traces中的其中一项或者多项。

可选的，所述方法还包括：

接收数据查询请求，所述数据查询请求中包括查询关键字；

以所述查询关键字为索引查询所述第二存储区域，得到所述查询关键字对应的存储地址和segment标识；

以所述存储地址和segment标识为索引，查找所述第一存储区域，得到查询结果；

输出所述查询结果。

第二方面，本申请实施例提供了一种面向应用观测的流式存储装置，所述装置包括：

获取单元，用于获取待存储数据流；

第一存储单元，用于将所述待存储数据流Stream包括的每个流存储至内存，所述内存包括块缓存block cache、可变内存表Active Memtable和不可变内存表ImmutableMemtable所述待存储流在内存中的流转顺序依次为block cache、Active Memtable、Immutable Memtable，所述待存储数据流包括日志log、指标Metrics或者调用日志Traces中的其中一项或者多项；

第二存储单元，用于将所述Immutable Memtable的数据刷到存储介质，并形成至少一个Segment存储于第一存储区域；

第三存储单元，用于将所述至少一个Segment中每个Segment分别对应的存储区域的地址、所述每个Segment对应的键Key、以及所述每个Segment对应的Segment标识，存储至所述存储介质中的第二存储区域中。

可选的，

所述第一存储区域采用分层、分片结构；

所述分层是指将第一存储区域划分为多个级(Level)，Level级数与该Level存储的数据的热度反相关，所述至少一个Segment存储在所述多个Level中的至少一个Level中；不同Level级采用不同的存储介质，Level级数与存储介质的价格反相关，以实现持久化存储、长期存储在不影响查询性能的前提下的混合部署；

所述分片是指不同存储数据流Stream的数据以段Segment为单位分布在不同Level，一个Stream包含多个Segment，每个Level中包括一个Stream对应的多个Segment，其中，一个或多个存储数据流Stream形成了独立的对象集合Schema，不同Schema对应不同维度的观测数据，所述Schema由用户定义。

可选的，所述Key还用于指示所述待存储数据流的版本。

可选的，所述待存储数据流的版本信息，包括：

所述Key产生的时间戳；

针对Update操作，数据因具备最新的版本信息使得在Segment下沉过程中，通过所述Key版本合并完成旧版本数据的删除；

针对Delete操作，则是通过将版本信息定义为无效信息system unvalid，使得在第二存储区域中的标识更新，完成了数据的逻辑删除。

可选的，所述将所述待存储数据流Stream包括的每个流存储至内存，包括：

将所述待存储数据流和无效数据存储至内存中的第一缓存行中，所述内存中的第一缓存行所能容纳的数据量大于所述待缓存数据流对应的数据量，所述待存储数据流对应的数量和所述无效数据的数据流之和，等于所述第一缓存行所能容纳的数据量。

可选的，所述待存储数据流中包括所述待存储数据流的数据来源。

可选的，所述待存储数据流，通过如下方式获得：

采集原始数据；

为所述原始数据添加数据来源；

根据所述原始数据和所述原始数据的数据来源，得到所述待存储数据流。

可选的，所述原始数据包括以下任意一项或者多项：

log、Metrics或者Traces。

可选的，所述待存储数据流对应的数据来源，包括：

log、Metrics以及Traces中的其中一项或者多项。

可选的，所述装置还包括：

接收单元，用于接收数据查询请求，所述数据查询请求中包括查询关键字；

第一查询单元，用于以所述查询关键字为索引查询所述第二存储区域，得到所述查询关键字对应的存储地址和segment标识；

第二查询单元，用于以所述存储地址和segment标识为索引，查找所述第一存储区域，得到查询结果；

输出单元，用于输出所述查询结果。

与现有技术相比，本申请实施例具有以下优点：

本申请实施例提供了一种面向应用观测的流式存储方法，它用于存储流数据(Stream)，并采用分层和分片的两层架构实现，其中，分层是指层级(Level)的概念，不同Level中存储不同热度的数据，Level级数越高，数据热度越低，实现了数据的冷热分离；不同Level可采用不同的存储介质，一般Level级越高，介质越廉价，实现了持久化存储、长期存储在不影响查询性能的前提下的混合部署。分片是指所述不同Stream的数据以段(Segment)为单位分布在不同Level，一个Stream包含多个Segment，每个Level中也允许一个Stream存在多个Segment，其中一个或多个Stream形成了独立的对象集合(Schema)，不同Schema对应了不同维度的观测数据，由用户定义。

本申请实施例提供了一种面向应用观测的流式存储方法，在一个示例中，可以获取待存储数据流，所述待存储数据流包括日志log、指标Metrics或者调用日志Traces中的其中一项或者多项。所述待存储数据流至少存在一个Segment，随着数据量的增加，Segment也会逐步下沉至更高层级的Level。在所述方法中，包含两个存储区域，第一存储区域、第二存储区域。其中，第一存储区域将所述至少一个Segment和所述至少一个Segment中各个Segment对应的Segment标识顺序存储至存储介质中的至少一个第一存储区域中，所述Segment标识用于标识所述待存储数据流对应的数据来源，所述Segment会分布在不同Level中，在本申请中每个Level会设置能存储单个Segment最大字节数MAX，当存储的数据量超过所述MAX，会自动向下一级Level创建新的Segment完成新增数据写入，并以此类推，其中不同Level可选择不同的存储介质；在第二存储区域中并将所述至少一个Segment中每个Segment分别对应的存储区域的地址、所述每个Segment对应的键Key、以及所述每个Segment对应的Segment标识，存储至所述存储介质中的第二存储区域中。由此可见，对于各个Segment(也就是所述待存储数据流本身)，仅存储一份，即存储在第一存储区域中，而不是分别在第一存储区域和第二存储区域各存储一份，一方面，避免了重复写入的问题，减少了冗余副本带来的存储开销，另一方面，因在第一存储区内的Segment数据是顺序写入，而面对观测数据的查找，也是从Segment中顺序读出，能够提升访问的性能。另外，本方案中第二存储区域存储有每个Segment分别对应的存储区域的地址、所述每个Segment对应的键(Key)、以及所述每个Segment对应的Segment标识，因此，当以Key为索引读取第一存储区域中的数据时，可以顺序读取。换言之，本方案可以支持顺序写和顺序读，与顺序写、随机读相比，能够有效提升存储介质的性能。在本方案中，所述Key在实际应用中存在键值冲突的场景，因此Key中包含了版本信息，一般是指Key产生的时间戳，但不局限于此，针对Update操作，数据因具备最新的版本信息使得在Segment下沉过程中，通过版本合并完成旧版本数据的删除；针对Delete操作，则是通过将版本信息定义为无效信息“system unvalid”，使得在第二存储区域中的标识更新，完成了数据的逻辑删除，弥补了业界在Update、Delete操作上的不足。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请中记载的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本申请实施例提供的一种面向应用观测的流式存储方法的流程示意图；

图2为本申请实施例提供的一种存储数据的示意图；

图3为本申请实施例提供的一种数据获取方法的流程示意图；

图4为本申请实施例提供的一种数据查询方法的流程示意图；

图5为本申请实施例提供的一种面向应用观测的流式存储装置的结构示意图。

具体实施方式

为了使本技术领域的人员更好地理解本申请方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

下面结合附图，详细说明本申请的各种非限制性实施方式。

参见图1，该图为本申请实施例提供的一种面向应用观测的流式存储方法的流程示意图。图1所示的方法，例如可以由服务器执行。在本实施例中，所述方法例如可以包括以下步骤：S101-S103。

S101：获取待存储数据流Stream，并将所述待存储stream中的每个Stream存储至内存，所述内存包括块缓存(block cache)、可变内存表(Active Memtable)、不可变内存表(Immutable Memtable)。

在一个示例中，所述待存储Stream在内存中的流转顺序依次为block cache、Active Memtable、Immutable Memtable。在一个示例中，block cache可以完成对cache操作的优化，它通过内核提供的posix_fadvise予以干预。block cache可以在几乎不损失性能的前提下，通过主动释放存储文件的页缓存(page cache)，可以达到减缓内存压力的目的，从而来应对极端内存需求的场景，这一优化能够很好的预防性能抖动的发生。但是，目前的block cache可能会存在伪共享的问题。因为一个处理器核对内存的修改，将导致另外的核在该处内存上的缓存失效。具体地：当多线程修改看似互相独立的变量时，如果这些变量共享同一个缓存行，就会在无意中影响彼此的性能。

在一个示例中，为了解决上述问题，在本申请实施例中，当所述待存储数据流的数据量小于内存中某一个缓存行(例如第一缓存行)所能容纳的数据量时，让所述待存储数据流独占所述第一缓存行，对于所述第一缓存行中的多余部分，可以插入无效数据。换言之，在一个示例中，可以将所述待存储数据流和无效数据存储在所述第一缓存行中，所述内存中的第一缓存行所能容纳的数据量大于所述待缓存数据流对应的数据流，所述待存储数据流对应的数量和所述无效数据的数据流之和，等于所述第一缓存行所能容纳的数据量。

在一个示例中，block cache中的cache页写满后，即将页内数据写到ActiveMemtable，Active Memtable主要用于缓存用户的写入数据，一般设定最大字节数AC_MAX，当写入的数据量超过AC_MAX值，Active Memtable自动切换为Immutable Memtable，并重新在内存中创建Immutable Memtable；所述Immutable Memtable代表其中存储的不可写，但可读，它代表了用户写磁盘文件的数据，这样的好处是当内存向磁盘进行数据刷新时，块数据能更好的利用IO，后台线程存储Immutable Memtable的数据进磁盘；在所述ActiveMemtable、Immutable Memtable，均针对不同的Schema单独开辟，不同Stream的ActiveMemtable、Immutable Memtable并不共享。

在本申请实施例中，所述待存储数据流根据来源不同，一个或多个Stream可定义为不同的概要(Schema)。在一个示例中，Schema可以根据待存储数据流Stream对应的数据来源确定。例如，所述待存储数据流包括log、Metrics、Trace三个数据来源的数据，可分别定义为三个不同的Schema，也可以讲log、Trace合并为一个Schema，具体取决于用户的需求，Schema的数据则后续以Segment的形式进行存储。

关于所述数据来源，需要说明的是，在本申请实施例中，所述数据来源可以包括：日志(log)、指标(Metrics)或者调用日志(Traces)。关于log、Metrics和Traces，需要说明的是：

log：记录事/物变化的载体，常见的访问日志、交易日志、内核日志等文本型以及GPS、音视频等泛型数据也包含在其中。日志在调用链场景结构化后其实可以转变为Trace，在进行聚合、降采样操作后会变成Metrics。

Metrics：聚合后的指标，相对比较离散，一般由名称(name)、标签(labels)、时间(time)、值(values)组成。Metrics数据量一般不大，相对存储成本更低，查询的速度比较快。

Traces：标准的调用日志，除了定义了调用的父子关系外，一般还会定义操作的服务、方法、属性、状态、耗时等详细信息，通过Trace能够代替一部分Log的功能，通过Trace的聚合也能得到每个服务、方法的Metrics指标。

在传统技术中，为了实现为了针对log、Metrics和Traces这三种维度的数据进行统一分析、展示。Metrics一般采用时序数据库(TimeSeriesDatabase，TSDB)存储。针对LOG或者Trace，一般输出到Elasticsearch(ES)进行存储。可以很直观的看出，这套架构中采用两条技术栈，存储层依然是相互隔离的。而存储层隔离主要的而问题包括：数据不互通、系统维护代价巨大。而在本方案中，采用流式存储的方式，统一存储log、Metrics以及Traces数据，从而有效避免了上述数据不互通以及系统维护代价巨大的问题。

在一个示例中，所述待存储数据流中包括所述待存储数据流的数据来源，此处提及的数据来源，可以包括以上提及的log、Metrics或者Traces中的其中一项或者多项。

S102：将所述Immutable Memtable的数据刷到存储介质，并形成至少一个Segment存储于第一存储区域。

所述存储介质可以是磁盘存储器，为物理硬件设备；所述第一存储区域位于所述存储介质上，并包含多个Level级，所述Level的数量在系统初始化前定义。所述数据所在Schema首次写所述存储介质时，形成的Segment位于Level0，而在系统初始化前定义每个Level会设置能存储单个Segment最大字节数MAX，当存储的数据量超过所述MAX，会自动向下一级Level1创建新的Segment完成新增数据写入，并以此类推至最后一级Level所在存储介质。

所述第一存储区域包括多个级Level，Level级数与该Level存储的数据的热度反相关，所述至少一个Segment存储在所述多个Level中的至少一个Level中。即：Level级数越高，该Level存储的数据的热度越低。S102在具体实现时，可以将所述至少一个Segment和所述至少一个Segment中各个Segment对应的Segment标识顺序存储至存储介质中的至少一个第一存储区域中，所述Segment标识用于标识所述待存储数据流对应的数据来源。

S103：将所述至少一个Segment中每个Segment分别对应的存储区域的地址、所述每个Segment对应的Key、以及所述每个Segment对应的Segment标识，存储至所述存储介质中的第二存储区域中。

关于S102和S103，需要说明的是，本申请不具体限定所述存储介质，所述Level层级可由用户自定义，不同Level层级可采用采用串行ATA(Serial Advanced TechnologyAttachment，SATA)的存储介质，又如可以是固态硬盘(Solid State Drive，SSD)、对象存储(Object Storage Service，OSS)，此处不一一列举说明，一般建议Level层级越高选用的存储介质成本越低。

在一个示例中，所述第一存储区域可以对应流存储(Stream Storage)区域中的某一区域，所述第二存储区域可以对应流存储表格(Stream Storage table)中的某个流存储表格。接下来，结合图2，介绍S102-S103。图2为本申请实施例提供的一种存储数据的示意图。

如图2所示，所述Stream Storage采用分层和分片两种架构，所谓分层，指的是所述Stream Storage包括多个级(Level)，所谓分片，指的是一个Level可以包括多个不同Schema的Segment，其中，不同Level存储不同热度的数据，Level越低，热度越高，相应的，数据访问频率越高。所述Stream Storage table则采用分片结构，主要根据Segment的不同进行分片。

如图2所示，在一个示例中，所述第一存储区域待存储数据可以存储在所述StreamStorage的Level 1中，如图2所示，所述Level 1中数据按照{value，Segment-ID}的形式存储，其中，所述value指的是待存储数据中的部分数据(即：Segment)，而Segment-ID为该value对应的Segment标识。相应的，所述第二存储区域存储的数据可以对应streamstorage table中的table(1)，table(1)中的数据按照{Key，address，Segment-ID}，其中，所述Key为value对应的Key，所述address为value在Stream Storage中的存储地址。

关于所述Key需要说明的是，在一个示例中，对于log和Traces，可以以业务(例如业务名称，或者，业务标识)作为Key，对于Metrics，可以以指标作为Key。

通过以上描述可知，利用本申请实施例的方案，对于各个Segment(也就是所述待存储数据流本身)，仅存储一份，即存储在第一存储区域中，而不是分别在第一存储区域和第二存储区域各存储一份，避免了重复写入的问题，能够提升存储介质的性能。另外，本方案中第二存储区域存储有每个Segment分别对应的存储区域的地址、所述每个Segment对应的键(Key)、以及所述每个Segment对应的Segment标识，因此，当以Key为索引读取第一存储区域中的数据时，可以顺序读取。换言之，本方案一方面，避免了重复写入的问题，减少了冗余副本带来的存储开销，另一方面，因在第一存储区内的Segment数据是顺序写入，而面对观测数据的查找，也是从Segment中顺序读出，能够提升访问的性能

在一个示例中，考虑到传统的流式存储方案(例如基于Apache Bookkeeper(BK)实现的流式存储方案)，其不支持更新(Update)和删除(Delete)操作。而在本申请实施例的一种实现方式中，所述Key在实际应用中存在键值冲突的场景，因此Key中包含了版本信息，一般是指Key产生的时间戳，但不局限于此，针对Update操作，数据因具备最新的版本信息使得在Segment下沉过程中，通过版本合并完成旧版本数据的删除；针对Delete操作，则是通过将版本信息定义为无效信息“system unvalid”，使得在第二存储区域中的标识更新，完成了数据的逻辑删除，弥补了业界在Update、Delete操作上的不足。

如前文，所述待存储数据流可以存储在缓存中，接下来，结合图3介绍在将所述待存储数据存储至缓存中之前，获得所述待缓存数据的方式。图3为本申请实施例提供的一种数据获取方法的流程示意图。图3所示的方法，可以包括如下S201-S203。

S201：采集原始数据。

在一个示例中，所述原始数据可以包括log、Metrics以及Traces。

在一个示例中，可以按照所述log、Metrics以及Traces数据分别支持的数据协议，采集所述log、Metrics以及Traces数据。

在一个示例中，S201在具体实现时，可以基于flink采集所述原始数据。

接下来，以采集log为例介绍S201的实现方式。

由于log为可扩展标记语言(Extensible Markup Language，XML)格式，需要等待接收到完整的结构体才能完成其内容的解析，而log作为流数据一条一条流入Flink，无法同一时刻接收到完整的结构体，考虑到其结构的特殊性，可以使用了Flink state这一特性，并将任务的并行度设置为1，严格保证日志读取的顺序。由于log格式非常统一，每个gc记录均由开始并由结束，十分便于定位一条gc记录。在接收到一次gc记录的第一行时，不会立即处理而是存储在state中直至读取到最后一行再提交XML解析类去处理。通过解析后即可获得所述日志数据。在一个示例中，解析获得的日志可以组织成map的格式输出至Elasticsearch的指定索引(index)中存储。

S202：为所述原始数据添加数据来源。

S203：根据所述原始数据和所述原始数据的数据来源，得到所述待存储数据流。

在一个示例中，获得所述原始数据之后，可以对所述原始数据进行进一步处理，例如，为所述原始数据添加相应的字段(例如时间戳)，得到处理后的中间数据。进一步地，基于所述中间数据和中间数据对应的中间来源，得到所述待存储数据流。

基于以上实施例提供的流式存储方法，本申请实施例还提供了一种数据查询方法。接下来结合附图介绍该数据查询方法。图4为本申请实施例提供的一种数据查询方法的流程示意图。图4所示的方法，可以包括如下S301-S304。

S301：接收数据查询请求，所述数据查询请求中包括查询关键字。

关于所述查询关键字，需要说明的是，在一个示例中，所述查询关键字可以是业务(例如业务名称或者业务标识)，也可以是指标。本申请实施例不做具体限定。

此处提及的数据查询请求，例如可以是结构化查询语言(Structured QueryLanguage，SQL)语句。

S302：以所述查询关键字为索引查询所述第二存储区域，得到所述查询关键字对应的存储地址和Segment标识。

S303：以所述存储地址和Segment标识为索引，查找所述第一存储区域，得到查询结果。

在一个示例中，可以以所述查询关键字为索引，查询所述第二存储区域中对应的Key，从而确定与所述查询关键词匹配的Key。相应的，将与所述查询关键词匹配的Key对应的存储地址和Segment标识，确定为所述查询关键字对应的存储地址和Segment标识。

而后，以所述存储地址和Segment标识为索引，查找所述第一存储区域，得到查询结果，即得到所述存储地址和Segment标识对应的value。

S304：输出所述查询结果。

获得所述查询结果之后，可以输出所述查询结果，在本申请实施例中，可以以可视化的方式输出所述查询结果，例如，以文本和/或图表的方式输出所述查询结果。

基于以上实施例提供的方法，本申请实施例还提供了一种装置，以下结合附图介绍该装置。

参见图5，该图为本申请实施例提供的一种面向应用观测的流式存储装置的结构示意图。所述装置500例如可以具体包括：获取单元501、第一存储单元502、第二存储单元503和第三存储单元504。

获取单元501，用于获取待存储数据流；

第一存储单元502，用于将所述待存储数据流Stream包括的每个流存储至内存，所述内存包括块缓存block cache、可变内存表Active Memtable和不可变内存表ImmutableMemtable所述待存储流在内存中的流转顺序依次为block cache、Active Memtable、Immutable Memtable，所述待存储数据流包括日志log、指标Metrics或者调用日志Traces中的其中一项或者多项；

第二存储单元503，用于将所述Immutable Memtable的数据刷到存储介质，并形成至少一个Segment存储于第一存储区域；

第三存储单元504，用于将所述至少一个Segment中每个Segment分别对应的存储区域的地址、所述每个Segment对应的键Key、以及所述每个Segment对应的Segment标识，存储至所述存储介质中的第二存储区域中。

可选的，

所述第一存储区域采用分层、分片结构；

所述分层是指将第一存储区域划分为多个级(Level)，Level级数与该Level存储的数据的热度反相关，所述至少一个Segment存储在所述多个Level中的至少一个Level中；不同Level级采用不同的存储介质，Level级数与存储介质的价格反相关，以实现持久化存储、长期存储在不影响查询性能的前提下的混合部署；

所述分片是指不同存储数据流Stream的数据以段Segment为单位分布在不同Level，一个Stream包含多个Segment，每个Level中包括一个Stream对应的多个Segment，其中，一个或多个存储数据流Stream形成了独立的对象集合Schema，不同Schema对应不同维度的观测数据，所述Schema由用户定义。

可选的，所述Key还用于指示所述待存储数据流的版本。

可选的，所述待存储数据流的版本信息，包括：

所述Key产生的时间戳；

针对Update操作，数据因具备最新的版本信息使得在Segment下沉过程中，通过所述Key版本合并完成旧版本数据的删除；

针对Delete操作，则是通过将版本信息定义为无效信息system unvalid，使得在第二存储区域中的标识更新，完成了数据的逻辑删除。

可选的，所述将所述待存储数据流Stream包括的每个流存储至内存，包括：

将所述待存储数据流和无效数据存储至内存中的第一缓存行中，所述内存中的第一缓存行所能容纳的数据量大于所述待缓存数据流对应的数据量，所述待存储数据流对应的数量和所述无效数据的数据流之和，等于所述第一缓存行所能容纳的数据量。

可选的，所述待存储数据流中包括所述待存储数据流的数据来源。

可选的，所述待存储数据流，通过如下方式获得：

采集原始数据；

为所述原始数据添加数据来源；

根据所述原始数据和所述原始数据的数据来源，得到所述待存储数据流。

可选的，所述原始数据包括以下任意一项或者多项：

log、Metrics或者Traces。

可选的，所述待存储数据流对应的数据来源，包括：

log、Metrics以及Traces中的其中一项或者多项。

可选的，所述装置还包括：

接收单元，用于接收数据查询请求，所述数据查询请求中包括查询关键字；

第一查询单元，用于以所述查询关键字为索引查询所述第二存储区域，得到所述查询关键字对应的存储地址和segment标识；

第二查询单元，用于以所述存储地址和segment标识为索引，查找所述第一存储区域，得到查询结果；

输出单元，用于输出所述查询结果。

由于所述装置500是与以上方法实施例提供的方法对应的装置，所述装置500的各个单元的具体实现，均与以上方法实施例为同一构思，因此，关于所述装置500的各个单元的具体实现，可以参考以上方法实施例的描述部分，此处不再赘述。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本申请的其它实施方案。本申请旨在涵盖本申请的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本申请的真正范围和精神由下面的权利要求指出。

应当理解的是，本申请并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本申请的范围仅由所附的权利要求来限制。

以上所述仅为本申请的较佳实施例，并不用以限制本申请，凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。