Kafka 不是为大消息构建的。时期。然而,越来越多的项目通过 Kafka 发送和处理 1Mb、10Mb,甚至更大的文件和其他大型有效负载。原因之一是 Kafka 专为大容量/吞吐量而设计 , 这是大消息所需的。本文介绍使用 Kafka 处理大型消息的用例、体系结构和权衡。

大型(卡夫卡)消息有效负载的用例

大型消息负载存在各种用例:图像识别、视频分析、音频分析和文件处理是广泛的例子。

图像识别和视频分析

图像识别和视频分析(也称为计算机视觉)可能是头号用例。 许多示例需要实时分析 视频,包括:

  • 安全和监控( 访问控制、入侵检测、运动检测)
  • 交通监控系统( 车辆交通检测、发生率检测、行人监控)
  • 医疗保健 (健康状况监测、远程医疗、手术视频分析)
  • 制造 (机器愿景,实现质量保证、增强支持和培训)

通过计算机视觉(例如 OpenCV)或深度学习/神经网络(例如 TensorFlow)等概念进行图像和视频处理,可减少时间、成本和人力,同时使行业更安全、更可靠、更一致。

音频分析

音频分析是一个有趣的用例,越来越多的出现:

  • 结合视频分析:请参阅上面的用例。通常,视频和音频需要一起处理。
  • 消费者物联网 (CIoT):提醒、通知、建议人们,例如,使用 音频分析
  • 工业物联网 (IIoT):使用高级声音分析的机器诊断和预测性维护,例如,使用 神经元音响软件
  • 自然语言处理 (NLP): 聊天机器人和其他现代系统使用文本和语音翻译,例如,使用来自主要云提供商的完全托管服务

大数据文件处理

最后,但最不重要的一点,在批处理模式下接收的大文件的处理不会很快消失。但是,大型文件可以集成到现代事件流工作流中,用于分离/分离关注点、连接到各种接收器。同时允许实时和批处理数据。

旧系统将提供数据源,如大型 CSV 或专有文件或需要集成的数据库的快照/导出 数据源(如 Hadoop 或 Spark)以批处理模式处理传入数据(例如,映射/减少、洗牌)。其他数据源(如数据仓库(如雪花)或文本搜索(例如弹性搜索)几乎实时地访问数据。

卡夫卡不是

在探索大型消息负载的用例后,让我们阐明 Kafka 不是:

Kafka 通常不是存储和处理大型文件(图像、视频、专有文件等)整体的专有技术。产品是专门为这些用例构建的。

例如,Akamai、Limelight 网络或 Amazon CloudFront 等内容交付网络 (CDN) 在全球分发视频流和其他软件下载。或”大文件编辑和处理”(如视频处理工具)。或者,Adobe、Autodesk、Camtasia 和许多其他供应商的视频编辑工具用于构建和呈现所有视频信息,包括电影和电视节目、视频广告和视频文章。

让我们看一个结合了 Kafka 和其他工具的示例:

Netflix 使用 Kafka 每天处理超过 6 PB 的流程。但是,对于消息编排、协调、数据集成、数据预处理、引入数据湖、构建无状态和有状态的业务应用程序以及其他用例,这”只是”。但 Kafka 并不习惯于共享和存储您在电视上或平板电脑上观看的所有节目和电影。Akamai 等内容交付网络 (CDN) 与其他工具和产品结合使用,为您提供您了解的出色视频流体验。

好的,Kafka 不是存储和处理整个大型文件(如 CDN 或视频编辑工具)的合适的工具。为什么、何时以及应如何使用 Kafka 处理大型消息负载?卡夫卡语中的”大信息”是什么?

大型邮件使用 Kafka 的功能和限制

最初,Kafka 不是为处理大型消息和文件而构建的。这并不意味着你不能这样做!

Kafka 限制消息的最大大小。代理配置的默认值为”消息.max.字节”,为 1MB。

为什么默认情况下 Kafka 限制邮件大小?

  • 与低延迟的任务关键型实时群集相比,大型消息处理所需的大小、配置和调整不同。
  • 大型消息会增加代理 JVM 的内存压力。
  • 大消息处理成本高昂,可能会减慢经纪人的速度。
  • 合理的消息大小限制可以满足大多数用例的要求。
  • 如果需要处理大型邮件,则存在良好的解决方法。
  • 大多数云产品不允许使用大型消息。

增加允许的消息大小对性能有明显影响。

因此,在通过 Kafka 群集发送消息之前,请了解下面讨论的所有备选方案

话虽如此, 我见过客户处理的消息远远大于 10Mb 与 Kafka 。评估 Kafka 处理大型消息是有效的,而不是为此使用其他工具(通常与 Kafka 一起)。

LinkedIn 很久以前就谈到了两种不同方法的利弊:将”仅卡夫卡”与”卡夫卡”与”卡夫卡”与”另一种数据存储”结合使用。尤其是在公共云之外,大多数企业不能简单地将 S3 对象存储用于大数据。因此,如果一个系统(Kafka)足够好,或者您应该投资两个系统(Kafka 和外部存储),则出现一个问题。

让我们来看看使用 Kafka 处理大型消息的权衡。

大型消息的卡夫卡 – 替代和权衡

没有单一的最佳解决方案。如何处理使用 Kafka 处理大型消息的决定取决于您的用例、SLA 和现有的基础结构。

存在以下三种可用的替代方法,可用于使用 Kafka 处理大型消息:

  • Kafka 和外部存储中基于引用的消息
  • 没有外部存储的 Kafka 中的在线大消息支持
  • Kafka 中的在线大型消息支持和分层存储

以下是每种方法的特点和优点/缺点(这是 2016 年LinkedIn的扩展):

Apache Kafka for large message payloads and files - Alternatives and Trade-offs

此外,不要低估大型消息的压缩功能。某些大型文件(如 CSV 或 XML)只需将压缩参数设置为使用 GZIP、Snappy 或 LZ4 即可显著减小其大小。

即使是1GB的文件也可以通过卡夫卡发送,但毫无疑问,这不是卡夫卡的设计。在客户端和代理中,每 1GB 消息都需要在 JVM 中分配 1GB 内存块。因此,在大多数情况下,对于真正大型的文件,最好将它们外部化为对象存储,并且仅对元数据使用 Kafka。

您需要自己定义什么是”大消息”,以及何时使用此博客文章中讨论的设计模式。这就是为什么我写在这里…

以下各节将更详细地探讨这些备选方案。在开始之前,让我们解释上表中提到的 Kafka 的分层存储的一般概念。许多读者可能还不知道这一点。

卡夫卡的分层存储

Kafka 数据大多以流式处理方式使用尾部读取 旧数据通常从磁盘读取,用于回填或故障恢复目的,而且不常见。

在分层存储方法中,Kafka 群集配置了两层存储 – 本地存储和远程存储。本地层与当前 Kafka 相同,该卡夫卡使用 Kafka 代理上的本地磁盘来存储日志段。新的远程层使用外部存储系统(如 AWS S3、GCS 或 MinIO)来存储已完成的日志段。定义了两个单独的保留期,对应于每个层。

启用远程层后,本地层的保留期可以从几天显著缩短到几个小时。远程层的保留期可能更长、几个月甚至几年。

Kafka 的分层存储允许独立于 Kafka 群集中的内存和 CPU 进行扩展存储,从而使 Kafka 能够成为长期存储解决方案。这还可以减少存储在 Kafka 代理本地的数据量,从而减少在恢复和重新平衡期间需要复制的数据量。

使用者 API 不会更改。Kafka 应用程序会一样使用数据。他们甚至不知道在引擎盖下是否使用分层存储。

汇合分层存储

汇合分层存储目前 可在汇合平台中提供,并在汇合云的引擎盖下使用:

Confluent Tiered Storage for Kafka

从基础架构的角度来看,汇合分层存储需要外部(对象)存储,如 AWS S3、GCS 或 MinIO。但从操作和发展的角度来看,端到端通信的复杂性以及消息和文件的分离是开箱即用。

KIP-405 – 向卡夫卡添加分层存储

KIP-405 – 向卡夫卡添加分层 存储支持也在进行中。汇合正积极与开源社区合作。优步正在领导这项倡议。

Kafka = 分层存储是处理大型消息的令人兴奋的选项(在某些用例中)。它为运营商提供了单一的基础设施,但也节省了成本并提供了更好的弹性。

现在,我们了解使用 Kafka 处理大型消息有效负载的技术可行性。现在,让我们更详细地讨论不同的用例和体系结构。

使用 Kafka 实现大型消息负载的用例和体系结构

大型消息有效负载内容的处理取决于技术用例。是否要

  • 发送图像来分析或增强它?
  • 是否将视频流式传输到远程使用者应用程序?
  • 实时分析音频噪音?
  • 处理结构化(i

, 可拆分) 文件按行?

  • 将非结构化(即不可拆分)文件发送到使用者工具以进行处理?
  • 我介绍一些处理大型消息的用例:

    • 制造:工厂边缘生产线的质量保证
    • 零售:增强现实,实现更好的客户体验和交叉/向上销售
    • 制药和生命科学:药物发现的图像处理和机器学习
    • 公共部门:安全和监视
    • 媒体:大型视频文件的内容交付
    • 银行:客户服务聊天应用程序中的附件

    以下各节通过不同的体系结构方法探讨这些用例,以使用 Apache Kafka 处理大型消息有效负载,以讨论它们的优缺点:

    1. 卡夫卡原生有效负载处理
    2. 块和重新组装
    3. Kafka 中的元数据并链接到外部存储
    4. 可对大型有效负载进行外部化

    用于大消息有效负载的 Kafka + 图像处理

    计算机视觉和图像识别被用于许多行业,包括汽车、制造、医疗保健、零售和创新的”硅谷用例”。图像处理包括 OpenCV 等工具,还包括实现深度学习算法(如卷积神经网络 (CNN))的技术。

    让我们看一下不同行业的一些例子。

    卡夫卡原生图像处理机器视觉制造

    机器视觉是用于提供基于成像的自动检测和分析的技术和方法,用于自动检测、过程控制和机器人制导等应用,通常在工业中。

    Kafka 本机机器视觉实现将图像从摄像机发送到 Kafka。预处理会添加元数据并将其与其他后端系统的数据关联。然后,一个或多个应用程序使用该消息:

    Kafka-native Image Processing

    制药和生命科学中药物发现的图像处理和机器学习

    PhRMA说:”平均而言,一种新药至少需要十年才能完成从最初发现到市场的旅程。

    下面是一个示例,其中实时大规模事件流可显著提高此过程。

    递归存在 一些技术挑战。他们的药物发现过程是手动和缓慢,突发的批处理模式,不可扩展:

    Drug Discovery in manual and slow, bursty batch mode, not scalable

    为了解决这些挑战,递归利用Kafka及其生态系统构建了一个大规模并行系统,该系统结合了实验生物学、人工智能、自动化和实时事件流,以加速药物发现:

    Drug Discovery in automated, scalable, reliable real time Mode

    查看 Recusion 的卡夫卡峰会谈话, 了解更多详情。

    我看到许多不同行业的客户使用 Kafka 生态系统实施可扩展的实时机器学习基础架构。与上述用例相关,我在博客文章“Apache Kafka 和制药和生命科学中的事件流”中探讨了更多详细信息。下面显示了潜在的 ML 基础结构:

    Streaming Analytics for Drug Discovery in Real Time at Scale with Apache Kafka

    卡夫卡原生图像识别,实现零售业中增强现实

    增强现实 (AR) 是真实环境中的一种交互式体验,其中驻留在现实世界中的对象通过计算机生成的感知信息进行增强。AR 应用程序通常使用 Unity 或虚幻等引擎构建。不同行业的用例都存在。工业4.0是目前最存在的一个。但其他行业开始构建引人入胜的应用程序。想想从任天堂的神奇宝贝去你的智能手机。

    下面显示了电信行业AR提供创新零售服务的例子。客户制作一张他家的照片,将图片发送到 电信提供商的 OTT 服务,并接收增强的图片(例如,用一张新沙发购买您的家):

    Augmented Reality with Apache Kafka and Deep Learning for Picture Enhancement

    Kafka 用于协调、与后端服务集成,以及在智能手机和 OTT 电信服务之间发送原始和增强的图像kai-waehner.de/blog/2020/01/01/apache-kafka-edge-computing-industrial-iot-retailing-logistics/”rel=”不跟随”目标=”_blank”=卡夫卡越来越多的出现在边缘。下面是在工业物联网(IIoT) / 工业 4.0 (I4) 中与 Kafka 一起使用机器视觉的示例

    Hivecell and Confluent Platform for Image Processing at the Edge

    蜂巢节点配备

    • 汇合 MQTT 代理:与摄像机集成
    • 卡夫卡经纪人和动物园管理员:事件流平台
    • Kafka 流:数据处理,如筛选、转换、聚合等。
    • Nvidia 的 Triton 推理服务器:使用训练有素的分析模型进行图像识别
    • Kafka 连接和汇流复制器:机器视觉的复制导致云

    使用阿帕奇卡夫卡的视频流

    流媒体是传递和获取媒体的过程。数据由一个或多个消费者持续接收,并在提供商交付时呈现给一个或多个使用者。在消费者端缓冲视频的拆分数据集可确保连续的流。

    使用 Kafka 原生技术实现视频流非常简单:

    Video Streaming with Apache Kafka via Chunk + Re-Assemble Large Kafka Message Payloads

    此体系结构利用组合 消息处理器企业 集成模式 (EIP):

    Composed Message Processor Enterprise Integration Pattern

    用例更加简单,因为我们不需要基于内容的路由器。我们只是将拆分器和聚合器 ESP 组合在一起。

    用于公共部门安全和监控的拆分和聚合视频流

    下面显示了使用 Kafka 进行视频流安全和监控的用例:

    Video Streaming with Apache Kafka for Security and Surveillance as part of Modernized SIEM索赔检查 EIP是此问题的完美解决方案:

    Claim Check Pattern EIP

    Kafka 中的元数据和链接到外部存储,用于媒体行业中大型视频文件的内容交付

    许多大型视频文件是在媒体行业制作的。使用特定的存储和视频编辑工具。卡夫卡不发送这些大文件。但它在灵活、分离的实时体系结构中控制业务流程:

    Metadata in Kafka + Link to Object Storage for Large Files

    从金融服务专有系统进行传统集成,实现大规模有效负载的数字化

    许多行业必须处理大文件。在金融服务中,我看到了几个用例,其中大型专有文件必须在不同的旧版应用程序之间共享。

    与上面使用的索赔检查 EIP 类似,您还可以利用 Kafka 连接及其单消息转换 (SMT) 功能:

    Externalizing Large Payloads on the fly with Kafka Connect SMT

    使用 Kafka 和机器学习处理大型文本文件的自然语言处理 (NLP)

    机器学习和卡夫卡是完美的选择。我在过去的许多文章和讲座中都谈到了这个话题。只需谷歌或从这篇博客文章开始, 以获得关于这种方法的想法: “

    使用 Kafka 和机器学习处理大型文本文件的自然语言处理 (NLP) 是一个很好的例子。”具有 Python、Java 和 Apache Kafka 的连续 NLP管道”演示如何使用 Kafka 流、Kafka 连接和 S3 序列化器/去序列化器实现上述设计模式。

    我喜欢这个例子,因为它也解决了数据科学家(热爱Python)和生产工程师(喜欢Java)之间的阻抗不匹配。使用Python、Jupyter、KSQL 和 TensorFlow 的机器学习可以更详细地探讨这一挑战。

    银行客户服务聊天应用程序中的大消息

    您刚刚学会了如何使用 Kafka 处理大型文件,将其外部化为对象存储,并且仅通过 Kafka 发送元数据。在某些用例中,这是太多的努力或成本。通过 Kafka 直接发送大型文件是可能的,有时更容易实现。架构更简单、更具成本效益。

    我已经讨论过上面的权衡。但这里是一个极好的用例,发送大文件本机与Kafka:附件在客户服务的聊天应用程序中。

    高盛 (GoldmanSachs)就是一家金融公司使用卡夫卡(Kafka)进行聊天系统的一个例子。他们领导了 Symphony 的发展 这是一个行业计划,旨在构建一个基于云的平台,用于即时通信和内容共享,安全地连接市场参与者。Symphony 基于一种具有成本效益、可扩展且可定制以满足最终用户需求的开源业务模式。许多其他芬服务公司投资于交响乐,包括美国银行、伦敦电信梅隆银行、贝莱德银行、城堡公司、花旗银行、瑞士信贷银行、德意志银行、高盛、汇丰银行、杰弗里斯银行、摩根大通、小牛、摩根士丹利、野村银行和富国银行。

    卡夫卡是聊天应用程序的完美选择。代理存储和分离非常适合多平台和多技术基础架构。脱机功能和使用旧消息也内置于 Kafka 中。下面是一个游戏行业聊天 平台的示例

    Real-time Chat function at scale within games and cross-platform usings Apache Kafka

    文件、图像或任何其他二进制内容等附件可能是此实现的一部分。不同的架构是可能的。例如,您可以使用专用的 Kafka 主题来处理大型消息。或者你只是把它们放进你的”聊天消息”活动中。使用 汇流架构注册表,架构可以具有属性”附件”。或者,您可以使用上面讨论的索赔检查 EIP 将附件外部化。

    卡夫卡本地处理大型消息有其用例!

    正如您在此帖子中学到的,使用 Apache Kafka 及其生态系统处理大型消息文件存在大量用例。Kafka 专为大容量/吞吐量而构建 – 这是大消息所需的。[在汇流云中将 Apache Kafka 缩放到 10+ GB/秒]就是一个令人印象深刻的示例。

    但是,并非所有大型邮件都应使用 Kafka 进行处理。通常,您应该使用正确的存储系统,只需利用 Kafka 进行编排。了解不同的设计模式,并选择适合每个问题的技术。

    大量消息的 Kafka 本机处理的常见方案是处于其他数据存储通常不可用或会增加预配基础结构的成本和复杂性的边缘。

    在使用 Kafka 生态系统处理大型消息方面,您有什么经验?您是否计划使用阿帕奇卡夫卡及其生态系统?你的策略是什么?让我们在 一LinkedIn 讨论吧!

    Comments are closed.