关于阿里云:消息队列Kafka检索组件重磅上线

3次阅读

共计 4271 个字符,预计需要花费 11 分钟才能阅读完成。

作者:Kafka&Tablestore 团队

前言

还在为音讯队列应用时,不能高效排查反复和失败的音讯而困扰吗?

还在为音讯队列应用时,无奈精确查找音讯内容和定位问题而苦恼吗?

。。。

音讯队列 Kafka「检索组件」来帮您~

本文对音讯队列 Kafka「检索组件」进行具体介绍,首先通过对音讯队列应用过程中的痛点问题进行介绍,而后针对痛点问题提出相应的解决办法,并对关键技术技术进行解读,旨在帮忙大家对音讯队列 Kafka「检索组件」的特点及应用形式更加相熟,以期能够帮忙大家更无效的解决在音讯排查过程中遇到的痛点问题。

痛点问题介绍

在音讯队列的应用过程中,业内默认的是假如音讯进入音讯队列后,音讯是牢靠的,失落的概率也是低的。但理论利用中会面临各种各样的问题:

利用时面临的痛点问题

  • 因为分布式系统的个性,音讯的失败、反复是不可避免的,对于失败和反复的排查,通常是依附客户端的日志来推导,但如果规模宏大,客户手动做这个事件的难度也会很大,这就会使音讯的可靠性受到挑战;
  • 此外,较大的我的项目个别由多人或多团队合作实现,音讯发送和生产的代码实现形式也各异,这会给音讯最终是否胜利完成使命带来挑战;
  • 除了对问题后果的排查外,音讯会不会在产生时就不合乎预期呢?这同样也是困扰客户的难点之一。从目前音讯队列的体系来看,还无奈提供依照内容查看的形式来排查,导致了业务的正确性排查难度较大。

简略来说,音讯畛域往往每条音讯都能代表具体的含意和动作,一旦呈现失败、失落和谬误,在业内现有的音讯队列现状下,很难排查具体问题,从而会导致定位整个上下游链路的问题难度较大。

技术侧面临的痛点问题

以上是客户在音讯利用的场景中会面临的问题。基于利用场景问题,在技术侧同样会面临不少痛点,在解决音讯问题排查时:

  • 首先须要研发的代码投入、部署和运维,同时运维人员须要比拟相熟 Kafka 的应用,须要通过应用 Kafka 客户端进行消费者生产,而后依照遍历的形式进行音讯确认,从而确认音讯的存在;
  • 除了须要研发的代码投入、部署和运维外,可能还须要引入其余产品,如对接流计算,通过流计算遍历音讯等。

更为麻烦的是,目前这种排查往往是十分频繁的,常常以周、甚至以天为单位,会使得研发、部署和运维投入较高的工夫老本;同时每次须要确认的元信息都不一样,会导致投入较大,而且灵活性也不高。

总结来说,音讯队列在应用过程中对失败和反复等问题排查时,一来在没有较好的工具和形式实现对内容的检索,排查难度较高,准确性和易用性都有余;二来须要投入较高的工夫和人力老本,投入大且不灵便。这些问题都会给用户在进行音讯问题排查时带来不少困扰。

Kafka 检索组件介绍

通过上述痛点问题的介绍能够看到,目前在音讯畛域,对音讯排查等存在比拟多的痛点问题,为了解决以上问题,阿里云音讯队列 Kafka 版重磅推出音讯检索组件。上面对组件内容进行具体介绍:

检索组件简介

音讯队列 Kafka「检索组件」是一个全托管、高弹性、交互式的检索组件,具备万亿级别音讯内容检索的秒级响应能力。

  • 次要面向运维人员故障排查和复原场景,用于音讯相干的全链路音讯排查,包含音讯的发送、反复生产和失落校验;次要性能包含反对音讯按 Topic 分区、位点范畴和工夫范畴检索,同时反对按音讯 Key 和 Value 关键字检索等;
  • 次要用来解决业内音讯产品不反对检索音讯内容的难题。

音讯队列 Kafka「音讯检索」借助 Kafka Connect 性能及表格存储(Tablestore)实现,通过 Connector 对 Topic 中的音讯进行转储,而后发送到表格存储中的数据表中,最初通过表格存储索引性能提供音讯检索的能力。

其外围是提供了齐备的音讯内容检索能力,能够疾速定位问题,同时便捷操作、节俭人力;当用户应用时,在实现音讯队列 Kafka 实例创立后,仅需简略五步即可实现对 Kafka 检索组件的利用:

上面简要对音讯队列 Kafka 版音讯检索的操作步骤进行介绍。

检索组件操作介绍

1)开明音讯检索

首先开明某个实例下 Topic 的音讯检索性能,以便依据须要对其 Topic 中的音讯进行检索。步骤如下:

  • 登录音讯队列 Kafka 版控制台;
  • 在概览页面的资源散布区域,抉择地区;
  • 在左侧导航栏,单击音讯检索;
  • 在音讯检索页面,从抉择实例的下拉列表抉择需检索 Topic 音讯所属的实例,而后单击开明音讯检索;
  • 开明音讯检索面板,填写开明参数,而后单击确定。

2)测试发送音讯

开明音讯检索后,能够向音讯队列 Kafka 版的数据源 Topic 发送音讯,以此来调度工作和测试音讯检索是否创立胜利。

  • 在音讯检索页面,找到须要测试的指标 Topic,依据工作状态在对应地位操作;
  • 在疾速体验音讯收发面板中发送测试音讯。

3)搜寻音讯

  • 在音讯检索页面,找到指标 Topic,在其操作列,单击搜寻;
  • 在搜寻面板,设置搜寻条件,在搜寻项下拉列表中抉择须要增加的搜寻项,单击增加搜寻项,增加搜寻项并在值列设置搜寻信息,而后单击确定即可。

4)查看音讯检索工作详情

  • 开明音讯检索后,即可查看主动创立的 Topic、Group、表格存储实例名称、表格存储数据表表名等详细信息,也能够在详情中间接进入表格存储数据表;
  • 在音讯检索页面,找到指标 Topic,在其操作列,单击详情;
  • 在工作详情页面能够查看到指标 Topic 相干音讯检索的详细信息;也能够在根底信息区域的指标服务栏,单击表格存储,即可进入数据表详情页面查看。

5)查看生产详情

反对查看订阅以后 Topic 的在线 Group 在 Topic 各个分区的生产进度,理解音讯的生产和沉积状况。

  • 在音讯检索页面,找到须要查看生产进度的指标 Topic,在其操作列,单击生产进度;
  • 如下图,在生产详情页面,能够查看 Topic 各分区的生产状况:

除以上性能外,在运行音讯检索性能时,还能够实现暂停音讯检索工作、启用音讯检索工作和删除音讯检索工作等操作。

Kafka 检索组件技术解读

之前音讯队列 Kafka 版的音讯检索形式仅反对依据生产位点或创立工夫的两种范畴来查找,依附 Kafka 零碎自身无奈很好的反对用户对于通过关键字检索音讯的需要。

为了更好的解决这个问题,Kafka 与 Tablestore 强强联合,将 Kafka 音讯通过 Connector 导入 Tablestore 的数据表中,利用 Tablestore 的能力实现关键字检索。

上面对关键技术进行解读:

Kafka Connect

Kafka Connect 的外围是为解决异构数据的同步问题。解决的思路是在各个数据源之间加一层消息中间件,所有的数据都通过消息中间件进行存储和散发。

这样做的益处有以下两点:

1)通过消息中间件做异步解耦,所有零碎只和消息中间件通信;

2)须要开发的解析工具数量,也从原来的 n 平方个,变成线性的 2*n 个;Kafka Connect 则用于连贯音讯零碎和数据源,依据数据的流向不同,连贯能够分为 Source Connector 和 Sink Connector。

其原理也很简略,Source Connector 负责解析起源数据,转换成规范格局的音讯,通过 Kafka Producer 发送到 Kafka Broker 中。同理,Sink Connector 则通过 Kafka Consumer 生产对应的 Topic,而后投递到指标零碎中。在整个过程中,Kafka Connect 对立解决了任务调度、与音讯零碎交互、主动扩缩容、容错以及监控等问题,大大减少了重复劳动。

音讯队列 Kafka 版提供了全托管、免运维的 Kafka Connect,用于音讯队列 Kafka 版和其余阿里云服务之间的数据同步。如下图所示,能够看到音讯队列 Kafka 版反对了表格存储 Tablestore、Mysql Source Connector、OSS Sink Connector、MaxCompute Sink Connector 以及 FC Sink Connector 等支流的 Connector。如果用户想要应用这些 Connector 进行数据同步,只用在音讯队列 Kafka 控制台的图形界面上做几个配置,就能够一键拉起 Connector 工作。

表格存储 Tablestore

表格存储 Tablestore 是构建在阿里云飞天分布式系统之上的海量结构化数据存储服务。基于飞天盘古分布式文件系统作为存储底座,采纳存储计算拆散架构,弹性共享资源池设计,实现了一个云原生的 Serverless 存储产品。内置分布式索引零碎,可依据写入流量主动扩大构建索引所需的计算资源,撑持极高的写入流量。同时优化了索引构造,可能反对更疾速的含糊查问。存算拆散架构、高吞吐实时索引等要害能力让 Tablestore 可能撑持 Kafka 中海量数据的写入与高效搜寻,帮忙疾速无效检索所需信息。

技术当先性

Kafka+Kafka Connect+ 表格存储 Tablestore 的云原生数据利用解决方案,通过 Kafka Connect 作为实时处理工作触发器,可能实时接管到新发送到音讯队列集群的数据,而后转发到表格存储 Tablestore。

作为后续数据流转中的一环,Kafka Connect 除了保障数据的实时性以外,还解决了任务调度、与音讯零碎交互、主动扩缩容、容错以及监控等问题,大大减少了重复劳动。数据到了表格存储 Tablestore 当前,借助表格存储的分布式存储和弱小的索引引擎,可能反对 PB 级存储、千万 TPS 和毫秒级提早的服务能力,同时反对全托管、高弹性、交互式的检索组件,从而可实现秒级响应的万亿级别音讯内容检索能力。

面向用户的价值与劣势

Kafka 检索组件性能不仅具备较强的技术劣势,同时还能为用户的理论工作带来更多便当:

1、排查成本低

只须要控制台的简略配置就能实现 Kafka 服务器集群内所有的音讯的查看;

2、排查速度快

免开发、免资源评估、免部署、免运维;只有建设好检索条件,即可实现秒级查问响应;

3、排查准确性高

该检索组件性能由音讯商业化团队和 Tablestore 团队外围研发联结打造,依靠于阿里云云原生的能力,检索准确性高,可靠性和可用性能够失去很好的保障。

总结来说,Kafka 检索组件性能在理论业务中具备如下劣势:

  • 疾速定位问题,可实现音讯上下游产品的故障、异样疾速复原,缩小业务资损;
  • 节俭企业老本,缩小运维、研发等人员投入;
  • 升高学习老本,对音讯产品的了解机制要求升高。

总结

阿里云音讯队列 Kafka「检索组件」是音讯队列畛域内率先反对交互式音讯内容检索的组件,具备免开发、免运维、高弹性的特点。对于在音讯畛域中的中、重度用户来说,阿里云音讯队列 Kafka「检索组件」是日常排查音讯存在 & 正确性的利器。

点击 此处,返回相干产品文档理解详情!

正文完
 0