一种高效融合CDN实时日志OLAP存储查询系统及其存储查询方法

摘要

本发明公开了一种高效融合CDN实时日志OLAP存储查询系统及其存储查询方法，属于计算机技术领域，包括：融合CDN厂商日志推送服务模块，用以实现融合厂商供应商的日志推送服务；反向服务器，用以作为融合厂商供应商的日志推送入口，融合CDN厂商日志推送服务模块的输出端与反向服务器的输入端连接；实时日志标准化服务模块，用以收集融合厂商供应商的日志并将其标准化，反向服务器的输出端与实时日志标准化服务模块的输入端连接；Kafka系统，用以存储融合厂商供应商的日志。本发明利用HBase存储特性，提供融合CDN日志的快速顺序写和随机读取要求；利用HBase的MOB特性，有效避免因频繁日志写入导致文件合并的问题。

说明书

技术领域

本发明涉及计算机技术领域，更具体地说，涉及一种高效融合CDN实时日志OLAP存储查询系统及其存储查询方法。

背景技术

融合CDN实时日志中，每条日志通常含有厂商，域名和请求时间3个维度以上及其他指标数据，且每秒会产生5百万条日志，其数据量非常庞大，背景是要实现如下功能：

1.即席查询：即基于厂商+域名+时间维度统计一段时间的CDN访问日志流量、平均下载速度、首包时间；

2.基于厂商+域名+时间维度快速查询CDN访问日志的原始日志用来排查日志；

3.保证日志高效及时入库，延迟低于1分钟；

我们在设计上对海量日志进行快速存储，通常会考虑以下方案：

(1)关系型数据库：适合存储关系型的日志数据，适合OLTP，但是不太适合海量日志的OLAP查询，但融合CDN日志是非结构化的(并且不同的厂商的格式会有较大的差异，而关系型数据库要求日志格式提前创建好)，所以关系型无法解决；

(2)分布式文件系统(HDFS)：HDFS适合用来存储非结构化的日志数据，适合顺序写入日志或者顺序读出日志，不利于随机写和随机度，虽然HDFS适合用来存储非结构化，但是HDFS设计为顺序写和顺序读的，融合CDN实时日志每秒会有大量日志，如果只是简单得进行顺序写入，则在查询的时候如果要根据厂商、域名和时间维度则要查询并且过滤大量日志行才能遍历到想要的数据，如果为了支持融合CDN日志的读需求场景，则需要按照相同的域名、厂商加上时间写相同的文件，这样可以满足读取需求，但是有2个问题：会有大量日志写入，可能同时间需要打开大量的文件句柄；对线上的HDFS集群压力增大著名的HDFSNameNode元数据问题，即大量的小文件不能通过扩容来解决融合实时日志经常延迟，又造成了以上2的问题

(3)对象存储(如七牛KODO,AWS S3)：对象存储系统通常可以容纳大量的小文件，存储廉价，可以很好扩容，对象存储系统和分布式文件系统有几个相同问题无法解决查询时候需要读取大量小文件，性能无法满足在实时写入情况，需要打开非常多的文件句柄，对线上集群压力增大；

(4)NOSQL(如HBASE)，可以快速写，高效的随机读取，写入时候无需进行提前设计好结构，HBase存储系统非常适合日志快速及时写入，并且满足随机读取，看起来很好满足，但是有以下缺点

(5)HBase基于HDFS文件系统，为了解决小文件问题，需要通过不断的进行小文件合并，这个会造成HBASE集群压力很大，影响到读取性能，甚至有时候由于运维不当导致经常服务宕机每条日志如果直接存入系统，就算数据已经经过压缩，仍然会有大量日志写入，存储资源浪费很严重，查询的时候还是会大量进行读取。

(6)公开号“CN111190875A”记载了“一种基于容器平台的日志聚合方法及装置，所述方法应用于基于容器平台实现的集群中，所述集群包括至少一个节点，所述方法包括：采集每个节点的日志数据，压缩打包并附加标识信息后发送给每个日志处理单元；每个日志处理单元根据所述标识信息，处理对应自身处理级别的日志数据压缩包，得到待聚合的日志数据；日志聚合单元根据待聚合的日志数据中定位标识，将来自不同日志处理单元且属于相同应用的待聚合的日志数据进行聚合，得到聚合日志数据；对所述聚合日志数据进行分类存储以供调用访问。本发明实施例提供的基于容器平台的日志聚合方法及装置，能够降低了容器平台的运维成本，提高了容器平台的可用性以及拓展性”，该专利仍然无法完美解决上述融合CDN厂商日志推送服务模块(1)﹣Log﹣Server系统(5)所具有的问题。

发明内容

针对现有技术中存在的问题，本发明的目的在于提供一种高效融合CDN实时日志OLAP存储查询系统及其存储查询方法，它利用HBase存储特性，提供融合CDN日志的快速顺序写和随机读取要求；利用HBase的MOB特性，有效避免因频繁日志写入导致文件合并的问题；实现OLAP中上钻(Roll-Up)功能按照融合CDN日志中的域名、厂商和时间维度对流量指标进行预计算(避免在查询流量的时候需要扫描原始日志)；实现OLAP中的下拉(Drill-Down)功能，也就是在查询流量的时候能够知道其流量之和是由哪些原始日志加总(快速定位原始CDN日志)；相同维度的日志高效存储，利用压缩并且用高效的存储格式写入存储系统，提升读取时的效率。

为解决上述问题，本发明采用如下的技术方案：

一种高效融合CDN实时日志OLAP存储查询系统，包括：

融合CDN厂商日志推送服务模块，用以实现融合厂商供应商的日志推送服务；

反向服务器，用以作为融合厂商供应商的日志推送入口，所述融合CDN厂商日志推送服务模块的输出端与反向服务器的输入端连接；

实时日志标准化服务模块，用以收集融合厂商供应商的日志并将其标准化，所述反向服务器的输出端与实时日志标准化服务模块的输入端连接；

Kafka系统，用以存储融合厂商供应商的日志，所述实时日志标准化服务模块的输出端与Kafka系统的输入端连接；

Log﹣Server系统，用以实现预聚合和压缩高效进行存储，所述Kafka系统的输出端与Log﹣Server系统的输入端连接；

Apache HBase系统，用以存储预聚合后的日志及归类的原始日志，所述Log﹣Server系统的输出端与Apache HBase系统的输入端连接；以及

实时日志读取服务模块，用以根据用户查询条件，搜索日志流量或者查找原始日志，所述Apache HBase系统的输出端与实时日志读取服务模块的输入端连接。本发明利用HBase存储特性，提供融合CDN日志的快速顺序写和随机读取要求；利用HBase的MOB特性，有效避免因频繁日志写入导致文件合并的问题；实现OLAP中上钻(Roll-Up)功能按照融合CDN日志中的域名、厂商和时间维度对流量指标进行预计算；实现OLAP中的下拉(Drill-Down)功能，也就是在查询流量的时候能够知道其流量之和是由哪些原始日志加总；相同维度的日志高效存储，利用压缩并且用高效的存储格式写入存储系统，提升读取时的效率。

作为本发明的一种优选方案，所述Log﹣Server系统包括：

实时日志预聚合及日志归类模块，用以消费kafka日志并且进行按照厂商+域名+时间预聚合和归类，内存中进行聚合，满足大小或者时间策略，进行刷盘写入本地文件系统；以及

实时日志上传模块，用以读取刷盘后的预聚合文件，并将其写入Apache HBase系统中。

作为本发明的一种优选方案，所述Log﹣Server系统具有OLAP的Roll-up特性：用以实现写入Apache HBase系统之前，先在内存中按照厂商+域名+时间维度进行对流量预聚合，避免读取流量的时候进行全量日志读取然后再对计量求和；以及

具有OLAP的Drill-down特性：用以将相同维度的日志归类压缩，并采用apacheavro格式进行存储。

作为本发明的一种优选方案，所述Apache HBase系统具有HBase的Mob特性：用以避免日志频繁合并，提升HBase读写吞吐量。

作为本发明的一种优选方案，所述实时日志读取服务模块具有如下功能：

提供按照厂商+域名+时间维度查询融合CDN日志流量；

提供按照厂商+域名+时间维度查询原始CDN日志日志。

一种高效融合CDN实时日志OLAP存储查询系统，将开源的Apache Druid替代权利要求3中Log﹣Server系统的OLAP的Roll-up特性。

一种高效融合CDN实时日志OLAP存储查询系统，将通用化的Roll-up加Drill-down特性日志OLAP系统替代权利要求1中的Log﹣Server系统。

一种高效融合CDN实时日志OLAP存储查询方法，包括如下步骤：

S100、融合CDN日志高效写入；

S200、融合CDN日志高效读取。

作为本发明的一种优选方案，在步骤S100中，包括如下步骤：

S110、读取实时融合CDN日志并存储在Kafka系统中,按照CDN日志的厂商、域名和时间维度对流量进行预聚合,完成内存KV存储的设计；

S120、读取实时融合CDN日志并存储在Kafka系统中,相同CDN日志的厂商、域名和时间维度的日志会被压缩高效进行存储并将其写入内存中；

S130、当内存中的预聚合流量和高效存储的日志满足一定大小就把内存中的数据写入磁盘，或者是不满足一定大小的时候但是达到一定时间写入本地磁盘，避免内存瓶颈,实现落盘；

S140、落盘的文件通过异步线程读取快速写入Apache HBase系统。

作为本发明的一种优选方案，在步骤S200中，包括如下步骤：

S210、由于日志已经对流量按照厂商+域名+时间进行了预聚合，查询流量无须通过读取原始日志在进行计算，查询速度非常快；

S220、相同厂商+域名+时间的日志作为Key存储到Apache HBase系统中，如果相同维度的日志有很多，利用Apache HBase系统的顺序读取功能，就能定位到原始日志。

相比于现有技术，本发明的优点在于：

(1)本发明利用HBase的Mob特性避免日志频繁合并，提升HBase读写吞吐量；

(2)本发明利用OLAP的Roll-up特性，写入HBase之前，先在内存中按照厂商+域名+时间维度进行对流量预聚合，避免读取流量的时候进行全量日志读取然后再对计量求和；

(3)本发明利用OLAP的Drill-down特性，把相同维度的日志归类压缩，并采用apache avro格式进行存储；

(4)本发明中相同维度的CDN日志在内存中提前归类并高效压缩存储，减少了日志存储空间

附图说明

图1为本发明一种高效融合CDN实时日志OLAP存储查询系统的结构示意图；

图2为本发明一种高效融合CDN实时日志OLAP存储查询系统中Log﹣Server系统处的的结构示意图；

图3为本发明一种高效融合CDN实时日志OLAP存储查询方法的流程图。

图中标号说明：

1、融合CDN厂商日志推送服务模块；2、反向服务器；3、实时日志标准化服务模块；4、Kafka系统；5、Log﹣Server系统；51、实时日志预聚合及日志归类模块；52、实时日志上传模块；6、Apache HBase系统；7、实时日志读取服务模块。

具体实施方式

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

实施例1：

请参阅图1-2，一种高效融合CDN实时日志OLAP存储查询系统，包括：

融合CDN厂商日志推送服务模块1，用以实现融合厂商供应商的日志推送服务；

反向服务器2，用以作为融合厂商供应商的日志推送入口，融合CDN厂商日志推送服务模块1的输出端与反向服务器2的输入端连接；

实时日志标准化服务模块3，用以收集融合厂商供应商的日志并将其标准化，反向服务器2的输出端与实时日志标准化服务模块3的输入端连接，实时日志标准化服务模块3主要接收融合厂商供应商的日志并且进行标准化，然后写入Kafka系统4中进行存储；

Kafka系统4，用以存储融合厂商供应商的日志，实时日志标准化服务模块3的输出端与Kafka系统4的输入端连接；

Log﹣Server系统5，用以实现预聚合和压缩高效进行存储，Kafka系统4的输出端与Log﹣Server系统5的输入端连接，其中：Log﹣Server系统5包括：

实时日志预聚合及日志归类模块51，用以消费kafka日志并且进行按照厂商+域名+时间预聚合和归类，内存中进行聚合，满足大小或者时间策略，进行刷盘写入本地文件系统，本模块主要读取存储在Kafka系统4中的融合CDN日志，按照厂商+域名+时间维度对日志进行分类并存储在内存中的KEY-VALUE结构中，其中KEY就是厂商+域名+时间，VALUE包含了预聚合的流量指标和原始日志，当内存中的KEY-VALUE满足一定大小或者满足一定时间，写入磁盘，清除KEY-VALUE内存，然后循环读取下一批日志，同时通知日志上传模块上传日志到HBASE；以及

实时日志上传模块52，用以读取刷盘后的预聚合文件，并将其写入Apache HBase系统6中，实时日志上传模块52收到通知后，读取KEY-VALUE文件，其中KEY解析为HBASE的KEY，Value解析为预聚合的流量指标和原始日志2个HBASE CELL；

具体的，Log﹣Server系统5具有OLAP的Roll-up特性：用以实现写入Apache HBase系统6之前，先在内存中按照厂商+域名+时间维度进行对流量预聚合，避免读取流量的时候进行全量日志读取然后再对计量求和；以及

具有OLAP的Drill-down特性：用以将相同维度的日志归类压缩，并采用apacheavro格式进行存储；

Apache HBase系统6，用以存储预聚合后的日志及归类的原始日志，Log﹣Server系统5的输出端与Apache HBase系统6的输入端连接；具体的，Apache HBase系统6具有HBase的Mob特性：用以避免日志频繁合并，提升HBase读写吞吐量；以及

实时日志读取服务模块7，用以根据用户查询条件，搜索日志流量或者查找原始日志，Apache HBase系统6的输出端与实时日志读取服务模块7的输入端连接，具体的，实时日志读取服务模块7具有如下功能：

a、提供按照厂商+域名+时间维度查询融合CDN日志流量；

b、提供按照厂商+域名+时间维度查询原始CDN日志日志

请参阅图3，一种高效融合CDN实时日志OLAP存储查询方法，包括如下步骤：

S100、融合CDN日志高效写入，包括如下步骤：

S110、读取实时融合CDN日志并存储在Kafka系统4中,按照CDN日志的厂商、域名和时间维度对流量进行预聚合,完成内存KV存储的设计；

S120、读取实时融合CDN日志并存储在Kafka系统4中,相同CDN日志的厂商、域名和时间维度的日志会被压缩高效进行存储并将其写入内存中；

S130、当内存中的预聚合流量和高效存储的日志满足一定大小就把内存中的数据写入磁盘，或者是不满足一定大小的时候但是达到一定时间写入本地磁盘，避免内存瓶颈,实现落盘；

S140、落盘的文件通过异步线程读取快速写入Apache HBase系统6；

S200、融合CDN日志高效读取，包括如下步骤：

S210、由于日志已经对流量按照厂商+域名+时间进行了预聚合，查询流量无须通过读取原始日志在进行计算，查询速度非常快；

S220、相同厂商+域名+时间的日志作为Key存储到Apache HBase系统6中，如果相同维度的日志有很多，利用Apache HBase系统6的顺序读取功能，就能定位到原始日志。

本发明主要是高效实现了Roll-up和Drill-down2个OLAP特性，并且实现了高效的日志入库和快速统计功能，利用HBase的LSM特性极大提升了写入性能，利用HBase的MOB对象存储特性避免文件频繁合并带来吞吐量下降问题。

实施例2：

本实施例提供了一种高效融合CDN实时日志OLAP存储查询系统，实施例2与实施例1的区别在于：将Log﹣Server系统5的OLAP的Roll-up特性用开源的Apache Druid替代，但是其不能同时实现预聚合和原始日志按照域名+厂商+时间维度压缩归档功能(也就是不能同时满足OLAP中的ROLLUP和Drill-down这2个功能)，因此需要保留Log﹣Server系统5的OLAP的Drill-down特性。

实施例3：

本实施例提供了一种高效融合CDN实时日志OLAP存储查询系统，实施例3与实施例1的区别在于：将Log﹣Server系统5整体使用“通用化的Roll-up加Drill-down特性日志OLAP系统”替代。

以上所述，仅为本发明较佳的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，根据本发明的技术方案及其改进构思加以等同替换或改变，都应涵盖在本发明的保护范围内。