searchusermenu
  • 发布文章
  • 消息中心
点赞
收藏
评论
分享
原创

日志全文检索引擎:ZeroETL思想下的存储与计算

2023-05-26 07:37:06
24
0

前言

在ZeroETL思想下设计实现一个存算分离,全文检索海量日志引擎。

 

ZeroETL

传统ETL主要是将各个业务系统中不同数据结构的数据经过提取(Extract),转换清洗(Transform)和加载(Load)到大数据存储平台的一个过程。传统的ETL又以下缺点。

1,ETL 数据处理流程长,速度慢,需要大量资源,而且有很多出错的机会。

2,ETL 流程长冗长,无法适应业务需求的快速迭代,以及不断变化和新增的数据源。

3,ETL 成本很高,不仅仅是资源成本还有运维成本,特别是在海量数据吞吐的情况下,数据在时间上是存在冗余的。

因此出现了ZeroETL的思想,ZeroETL本义在于尽量减少T(转换清洗Transform)这个过程,因此数据的标准化是ZeroETL的核心。

不过业务系统是不可能标准化所有数据的,但是别忘了ZeroETL主要的意义在于去‘T’而不是E和L都去掉,因此在CDC的过程中,即可直接将数据标准化,这样的话在全文检索的系统中即可去除到处理和加工的过程。直接结构化落盘,那现在我们看看如何实现这个全文检索的过程。

 

痛点

传统的全文检索日志服务基本符合ETL架构,即采集->处理加工->落盘全文引擎的主流程,因此存在以下痛点。

1,传统日志服务ETL架构采集,消费,存储流程过长,系统稳定性弱,成本过高的问题;

2,存储和计算耦合节点导致服务存在状态,动态扩缩能力弱的问题;

3,传统日志服务区分消息队列和存储步骤,系统复杂度高,系统的可扩展性低;

4,数据冗余,在主流程上,数据会重复读写至少3遍。

 

目的

在ZeroETL的思想下海量的日志数据中,实现一个日志全文检索引擎,提供存算分离的能力,无状态计算节点的,存储节点的感横向扩容,承接PB级别的数据索引和schema-on-read检索。在存储引擎的角度上支持多种可插拔索引,提供比如稀疏索引,布隆过滤器,倒排索引等。同时日志数据使用append-only的有序写入方式,FIFO先进先出的存储模式,兼具了消息队列和存储引擎的功能。减少ETL中‘T’的过程。在计算引擎的角度上支持schema-on-read使用外接交互式查询引擎开发connector查询读取,比如spark,flink,presto等;

 

架构

主要思路

1,写Write客户端按指定的主题和元数据,通过服务发现,找到计算集群的指定计算节点,建立连接,发送写数据请求。写入数据首先缓存在计算节点的内存中,然后通过存储节点的客户端使用DistributedLog一致性算法,将写入数据同时发送给存储集群的指定的一批存储节点中,同时这一批中的一些节点返回写入成功的响应则表示此次写请求成功;

2,读Read客户端初始化流程和Write客户端一致,首先获得计算节点,先读取缓存中是否命中,如果命中直接返回,没有则通过存储节点的客户端查询存储集群。使用随机读算法(避免长尾效应)同时发多个读请求,依次读取写缓存,查询缓存,索引文件,存储段。直至命中数据返回;

 

索引

主要思路

1,客户端将日志数据LogEntry写入事务日志队列中,事务日志队列使用append-only的方式有序落盘。事务日志落盘后即表示当前节点写成功,数据的一致性使用DistributedLog算法;

2,事务日志落盘后,在将LogEntry写入内存Buffer中,排序,去重,按相应算法异步实现索引构建,比如稀疏索引,布隆过滤器索引,全文倒排索引,不同的索引结构均为可插拔插件式(Pluggable);

3,LogEntry在内存buffer中定时刷盘,存储到存储段Segment中,使用append-only的方式写入,FIFO的方式存储,每一个节点中,只有一个Segment是允许写入的,当存储段Segment写满后,或者异常崩溃后,存储段Segment变为自读状态;

4,同时在存储段Segment落盘的过程中,索引的构建也同步进行同步构建,稀疏索引是必然构建,倒排索引会首先经历一个分词过程,然后构建倒排表存储;

5,存储段Segment和索引可以使用适配器的方式将数据放到远程和第三方存储中;

 

检索

主要思路

1,客户端首先查询写缓存,命中直接返回;

2,客户端查询读缓存,命中直接返回;

3,客户端缓存都没命中的情况下,依次查询稀疏索引,布隆索引,全文索引,然后找到指定的存储段Segment的对应Offset;

4,文件系统对查询到的存储段Segment的对应Offset开始预读数据,写入读缓存。返回查询结果数据;

 

总结

在ZeroETL思想设计实现的存算分离,全文检索海量日志引擎,不仅仅缩减了ETL的流程,标准化了数据结构,是系统更加轻便和灵活,还存在以下的一些优点。

1,存算分离,无状态计算节点无缝扩缩,存储节点扩缩秒级切换。

2,计算成本大大减少,传统ETL架构中的消息队列和和数据存储整合,减少两次海量数据写入。大大减少资源成本。

3,多级索引灵活构建,支持倒排全文索引外部存储。

4,相比于传统的ETL架构,优势在于整合了消息队列和存储和查询引擎,大大减少资源成本;

5,在存算分离的架构上,整合append-only的写入模式和FIFO的存储模式,构建多种索引,例如全文索引,实现消息队列和存储结合的能力;

6,支持schema-on-read,支持多种外接式无状态交互式查询引擎。

0条评论
0 / 1000
wanghg11
13文章数
2粉丝数
wanghg11
13 文章 | 2 粉丝
原创

日志全文检索引擎:ZeroETL思想下的存储与计算

2023-05-26 07:37:06
24
0

前言

在ZeroETL思想下设计实现一个存算分离,全文检索海量日志引擎。

 

ZeroETL

传统ETL主要是将各个业务系统中不同数据结构的数据经过提取(Extract),转换清洗(Transform)和加载(Load)到大数据存储平台的一个过程。传统的ETL又以下缺点。

1,ETL 数据处理流程长,速度慢,需要大量资源,而且有很多出错的机会。

2,ETL 流程长冗长,无法适应业务需求的快速迭代,以及不断变化和新增的数据源。

3,ETL 成本很高,不仅仅是资源成本还有运维成本,特别是在海量数据吞吐的情况下,数据在时间上是存在冗余的。

因此出现了ZeroETL的思想,ZeroETL本义在于尽量减少T(转换清洗Transform)这个过程,因此数据的标准化是ZeroETL的核心。

不过业务系统是不可能标准化所有数据的,但是别忘了ZeroETL主要的意义在于去‘T’而不是E和L都去掉,因此在CDC的过程中,即可直接将数据标准化,这样的话在全文检索的系统中即可去除到处理和加工的过程。直接结构化落盘,那现在我们看看如何实现这个全文检索的过程。

 

痛点

传统的全文检索日志服务基本符合ETL架构,即采集->处理加工->落盘全文引擎的主流程,因此存在以下痛点。

1,传统日志服务ETL架构采集,消费,存储流程过长,系统稳定性弱,成本过高的问题;

2,存储和计算耦合节点导致服务存在状态,动态扩缩能力弱的问题;

3,传统日志服务区分消息队列和存储步骤,系统复杂度高,系统的可扩展性低;

4,数据冗余,在主流程上,数据会重复读写至少3遍。

 

目的

在ZeroETL的思想下海量的日志数据中,实现一个日志全文检索引擎,提供存算分离的能力,无状态计算节点的,存储节点的感横向扩容,承接PB级别的数据索引和schema-on-read检索。在存储引擎的角度上支持多种可插拔索引,提供比如稀疏索引,布隆过滤器,倒排索引等。同时日志数据使用append-only的有序写入方式,FIFO先进先出的存储模式,兼具了消息队列和存储引擎的功能。减少ETL中‘T’的过程。在计算引擎的角度上支持schema-on-read使用外接交互式查询引擎开发connector查询读取,比如spark,flink,presto等;

 

架构

主要思路

1,写Write客户端按指定的主题和元数据,通过服务发现,找到计算集群的指定计算节点,建立连接,发送写数据请求。写入数据首先缓存在计算节点的内存中,然后通过存储节点的客户端使用DistributedLog一致性算法,将写入数据同时发送给存储集群的指定的一批存储节点中,同时这一批中的一些节点返回写入成功的响应则表示此次写请求成功;

2,读Read客户端初始化流程和Write客户端一致,首先获得计算节点,先读取缓存中是否命中,如果命中直接返回,没有则通过存储节点的客户端查询存储集群。使用随机读算法(避免长尾效应)同时发多个读请求,依次读取写缓存,查询缓存,索引文件,存储段。直至命中数据返回;

 

索引

主要思路

1,客户端将日志数据LogEntry写入事务日志队列中,事务日志队列使用append-only的方式有序落盘。事务日志落盘后即表示当前节点写成功,数据的一致性使用DistributedLog算法;

2,事务日志落盘后,在将LogEntry写入内存Buffer中,排序,去重,按相应算法异步实现索引构建,比如稀疏索引,布隆过滤器索引,全文倒排索引,不同的索引结构均为可插拔插件式(Pluggable);

3,LogEntry在内存buffer中定时刷盘,存储到存储段Segment中,使用append-only的方式写入,FIFO的方式存储,每一个节点中,只有一个Segment是允许写入的,当存储段Segment写满后,或者异常崩溃后,存储段Segment变为自读状态;

4,同时在存储段Segment落盘的过程中,索引的构建也同步进行同步构建,稀疏索引是必然构建,倒排索引会首先经历一个分词过程,然后构建倒排表存储;

5,存储段Segment和索引可以使用适配器的方式将数据放到远程和第三方存储中;

 

检索

主要思路

1,客户端首先查询写缓存,命中直接返回;

2,客户端查询读缓存,命中直接返回;

3,客户端缓存都没命中的情况下,依次查询稀疏索引,布隆索引,全文索引,然后找到指定的存储段Segment的对应Offset;

4,文件系统对查询到的存储段Segment的对应Offset开始预读数据,写入读缓存。返回查询结果数据;

 

总结

在ZeroETL思想设计实现的存算分离,全文检索海量日志引擎,不仅仅缩减了ETL的流程,标准化了数据结构,是系统更加轻便和灵活,还存在以下的一些优点。

1,存算分离,无状态计算节点无缝扩缩,存储节点扩缩秒级切换。

2,计算成本大大减少,传统ETL架构中的消息队列和和数据存储整合,减少两次海量数据写入。大大减少资源成本。

3,多级索引灵活构建,支持倒排全文索引外部存储。

4,相比于传统的ETL架构,优势在于整合了消息队列和存储和查询引擎,大大减少资源成本;

5,在存算分离的架构上,整合append-only的写入模式和FIFO的存储模式,构建多种索引,例如全文索引,实现消息队列和存储结合的能力;

6,支持schema-on-read,支持多种外接式无状态交互式查询引擎。

文章来自个人专栏
日志服务
11 文章 | 1 订阅
0条评论
0 / 1000
请输入你的评论
0
0