大数据是一种在获取、存储、管理、分析等方面大大超出了传统数据库软件工具能力范围的数据集合。它具有大量的数据规模、快速的数据流转、多样的数据类型和价值密度低四大特征。 未来大数据相关人才缺口巨大。

大量优质岗位等你来

薪资待遇随工作年限呈阶梯式上涨

只有想不想学，没有能不能学

理论、实战双向并行，奠定入行扎实基础

一路暖心服务，不怕您货比三家

       大数据培训资料

　　虽然Kafka不是为大型邮件而出现的。但是，越来越多的项目通过Kafka发送和处理1Mb、10Mb甚至更大的文件和其他大型有效负载。因为Kafka是为大容量(吞吐量)而设计的——这也是大型消息所必需的。本文介绍了使用Kafka处理大型消息的用例、体系结构和取舍。

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

　　大型邮件有效载荷存在各种用例：图像识别，视频分析，音频分析和文件处理是广泛的示例。

　　图像识别和视频分析

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

　　安全和监视(访问控制，入侵检测，移动检测)

　　运输监控系统(车辆交通检测，事故检测，行人监控)

　　医疗保健(健康状况监控，远程医疗，手术视频分析)

　　制造业(机器视觉用于质量保证，增强的支持和培训)

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

　　音频分析

　　音频分析是一个有趣的用例，越来越多地出现：

　　与视频分析结合使用：请参见上面的用例。通常，视频和音频需要一起处理。

　　消费者物联网(CIoT)：例如使用音频分析向人们发出警报，通知和建议。

　　工业物联网(IIoT)：使用高级声音分析(例如，使用Neuron声音软件)进行机器诊断和预测性维护

　　自然语言处理(NLP)：聊天机器人和其他现代系统使用文本和语音翻译，例如，使用来自主要云提供商的完全托管服务

　　大数据文件处理

　　最后但并非最不重要的一点是，以批处理方式接收的大文件的处理不会很快消失。但是，可以将大文件合并到现代事件流工作流中，以将关注点分离，与各种接收器的连接。并且它允许实时和同时批量处理数据。

　　旧版系统将提供数据源，例如大CSV或专有文件或来自需要集成的数据库的快照/导出。数据处理包括流应用程序(例如KafkaStreams，ksqlDB或ApacheFlink)，以连续处理，关联和分析来自不同数据源的事件。诸如Hadoop或Spark之类的数据源以批处理模式(例如，映射/归约，改组)处理了传入数据。诸如数据仓库(例如Snowflake)或文本搜索(例如Elasticsearch)之类的其他数据源几乎实时地摄取数据。

　　Kafka不是什么

　　在研究了大型消息有效载荷的用例之后，让我们澄清一下Kafka不是什么：

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

　　例如，诸如Akamai，LimelightNetworks或AmazonCloudFront之类的内容交付网络(CDN)在全球范围内分发视频流和其他软件下载。或“大文件编辑和处理”(如视频处理工具)。或者使用Adobe，Autodesk，Camtasia和许多其他供应商的视频编辑工具来构造和显示所有视频信息，包括电影和电视节目，视频广告和视频文章。

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

　　Netflix每天使用Kafka处理6PB以上的数据。但是，这仅适用于消息编排，协调，数据集成，数据预处理，向数据湖中的提取，构建无状态和有状态业务应用程序以及其他用例。但是，Kafka并不用来共享和存储你在电视或平板电脑上观看的所有节目和电影。像Akamai这样的内容交付网络(CDN)与其他工具和产品结合使用，可以为你提供出色的视频流体验。

　　Kafka不是像CDN或视频编辑工具那样适合整体存储和处理大文件的工具。那么，为什么，何时以及如何使用Kafka处理大型邮件负载？用Kafka的术语来说，什么是“大讯息”？

　　使用Kafka处理大型邮件的功能和局限性

　　最初，Kafka并非用于处理大型邮件和文件。这并不意味着你无法做到！

　　Kafka限制了邮件的最大大小，代理配置“message.max.bytes”的默认值为1MB。

　　为什么Kafka默认会限制邮件大小？

　　与具有低延迟的关键任务实时群集相比，大型消息处理需要不同的大小，配置和调整。

　　大消息会增加代理JVM的内存压力。

　　大消息处理起来很昂贵，可能会使代理变慢。

　　合理的消息大小限制可以满足大多数用例的要求。

　　如果你需要处理大型邮件，则存在良好的解决方法。

　　大多数云产品都不允许大型消息。

　　增加允许的邮件大小会对性能产生明显影响。

　　因此，在通过Kafka集群发送大于1Mb的消息之前，请了解下面讨论的所有替代方法。

　　根据正常运行时间和延迟的SLA，应考虑使用单独的Kafka群集来处理大型邮件。

　　话虽如此，我已经看到客户使用Kafka处理远远大于10Mb的消息。评估Kafka处理大型邮件是有效的，而不是为此使用其他工具(通常与Kafka结合使用)。

　　LinkedIn很久以前就谈到了两种不同方法的优缺点：使用“仅Kafka”与“将Kafka与其他数据存储结合使用”。尤其是在公共云外部，大多数企业不能简单地将S3对象存储用于大数据。因此，如果一个系统(Kafka)足够好，还是应该投资两个系统(Kafka和外部存储)，就会出现问题。

　　让我们看一下使用Kafka处理大型邮件的权衡。

　　大消息的Kafka–替代方案和折衷方案

　　没有单一的最佳解决方案。如何使用Kafka处理大型邮件的决定取决于你的用例，SLA和已经存在的基础架构。

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

　　Kafka和外部存储中基于参考的消息传递

　　Kafka中的在线大消息支持，无需外部存储

　　Kafka中的在线大消息支持和分层存储

　　以下是每种方法的特点和优点/缺点(这是2016年LinkedIn演示文稿的扩展)：

　　另外，请不要低估大型邮件的压缩能力。仅通过将压缩参数设置为使用GZIP，Snappy或LZ4，某些大文件(例如CSV或XML)就可以显著减小其大小。

　　甚至可以通过Kafka发送1GB的文件，但这无疑不是Kafka的设计目的。在客户端和代理中，将需要为每1GB消息在JVM中分配1GB内存。因此，在大多数情况下，对于很大的文件，最好将它们外部化到对象存储中，并仅将Kafka用于元数据。

　　你需要自己定义什么是“大信息”，以及何时使用本文中讨论的哪种设计模式。这就是这篇文章的目的。

　　以下各节将更详细地探讨这些替代方案。在开始之前，让我们解释上表中提到的Kafka分层存储的一般概念。许多读者可能还没有意识到这一点。

　　Kafka分层存储

　　Kafka数据主要是通过使用尾部读取以流方式使用的。尾部读取利用操作系统的页面缓存来提供数据，而不是磁盘读取。通常会从磁盘读取较旧的数据，以进行回填或故障恢复，并且这些数据很少见。

　　在分层存储方法中，Kafka集群配置了两层存储—本地和远程。本地层与当前的Kafka相同，后者使用Kafka代理上的本地磁盘存储日志段。新的远程层使用外部存储系统(例如AWSS3，GCS或MinIO)存储完整的日志段。对应于每个层定义了两个单独的保留期。

　　启用远程层后，可以将本地层的保留期从几天显着减少到几个小时。远程层的保留期可能更长，几个月甚至几年。

　　Kafka的分层存储允许扩展存储而不依赖于Kafka集群中的内存和CPU，从而使Kafka成为长期存储解决方案。这也减少了在Kafka代理上本地存储的数据量，因此减少了在恢复和重新平衡期间需要复制的数据量。

　　使用者API完全不变。Kafka应用程序像以前一样使用数据。他们甚至都不知道引擎盖下是否使用了分层存储。

　　汇合的分层存储

　　Confluent分层存储现已在Confluent平台中可用，并在ConfluentCloud的幕后使用：

　　从基础架构角度看，Confluent分层存储需要外部(对象)存储，例如AWSS3，GCS或MinIO。但是从操作和开发的角度来看，端到端通信的复杂性以及消息和文件的分离是在幕后提供的。

　　KIP-405-将分层存储添加到Kafka

　　KIP-405–正在向Kafka添加分层存储支持。Confluent正在与开源社区积极合作。优步正在领导这项计划。

　　Kafka+分层存储是处理大型消息的一个令人兴奋的选项(在某些用例中)。它为操作员提供了单一的基础架构，还节省了成本并提高了弹性。

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

　　使用Kafka处理大量邮件的用例和体系结构

　　大消息有效负载内容的处理取决于技术用例。你想要......吗？

　　发送图像进行分析或增强？

　　将视频流传输到远程消费者应用程序？

　　实时分析音频噪声？

　　逐行处理结构化(即，可拆分)文件？

　　将非结构化(即，不可拆分)文件发送到使用者工具以进行处理？

　　一些处理大型消息的用例：

　　制造业：部署在工厂边缘的生产线的质量保证

　　零售：增强现实技术，可提供更好的客户体验和交叉/向上销售

　　制药与生命科学：用于药物发现的图像处理和机器学习

　　公共部门：安全和监视

　　媒体：大型视频文件的内容交付

　　银行业务：用于客户服务的聊天应用程序中的附件

　　以下各节使用不同的体系结构方法探索这些用例，以使用ApacheKafka处理大型消息有效负载，以讨论其优缺点：

　　1.Kafka原生负载处理2.块并重新组装3.Kafka中的元数据并链接到外部存储4.快速外部化大型有效载荷

　　Kafka用于大型邮件有效负载–图像处理

　　计算机视觉和图像识别已在许多行业中使用，包括汽车，制造业，医疗保健，零售和创新的“硅谷用例”。图像处理不仅包括诸如OpenCV之类的工具，还包括实现诸如卷积神经网络(CNN)之类的深度学习算法的技术。

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

　　Kafka原生图像处理技术在制造业中的应用

　　机器视觉是一种技术和方法，通常为工业中的自动化检查，过程控制和机器人指导等应用提供基于图像的自动检查和分析。

　　Kafka原生的机器视觉实现将相机中的图像发送到Kafka。预处理会添加元数据并将其与其他后端系统中的数据相关联。然后，该消息将被一个或多个应用程序使用：

　　药物和生命科学领域中用于药物发现的图像处理和机器学习

　　“平均而言，从立项到上市的新药开发至少需要10年时间”，PhRMA说。

　　这是一个示例，其中大规模实时事件流显着加快了此过程。

　　递归有几个技术挑战。他们的药物发现过程是手动且缓慢，突发的批处理模式，无法扩展：

　　为了解决这些挑战，Recursion利用Kafka及其生态系统构建了一个大型并行系统，该系统结合了实验生物学，人工智能，自动化和实时事件流技术，以加快药物研发：

　　我看到各行各业的许多客户都在使用Kafka生态系统实施可扩展的实时机器学习基础架构与上述用例相关。下面显示了潜在的ML基础结构：

　　用于零售业增强现实的Kafka原生图像识别

　　增强现实(AR)是现实环境中的交互式体验，其中，计算机生成的感知信息可以增强驻留在现实世界中的对象。AR应用程序通常使用Unity或Unreal等引擎构建。用例存在于各个行业。工业4.0是当今最流行的一种。但是其他行业开始构建引人入胜的应用程序。只需考虑任天堂为你的智能手机发布的PokemonGo。

　　以下显示了电信行业中提供创新零售服务的AR的示例。客户对自己的房屋进行拍照，然后将其发送给电信公司的OTT服务，并接收增强后的图片(例如，购买新的沙发)。

　　Kafka用于编排，与后端服务集成，以及在智能手机和OTTTelco服务之间发送原始和增强的图像。

　　Confluent和Hivecell在工业物联网(IIoT)边缘的机器视觉

　　Kafka越来越多地出现在边缘。这是在工业物联网(IIoT)/工业4.0(I4)中使用Kafka进行边缘机器视觉的示例：

　　Hivecell节点配备了

　　融合的MQTT代理：与摄像机集成

　　KafkaBroker和ZooKeeper：事件流平台

　　KafkaStreams：数据处理，例如过滤，转换，聚合等。

　　Nvidia的Triton推理服务器：使用经过训练的分析模型进行图像识别

　　KafkaConnectandConfluentReplicator：将机器视觉复制到云中

　　使用ApacheKafka进行视频流

　　流媒体是传递和获取媒体的过程。数据在提供者传递的同时不断地被一个或多个消费者接收并呈现给他们。在用户端缓冲视频的拆分数据包，以确保连续流。

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

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

　　用例更加简单，因为在这种情况下我们不需要基于内容的路由器。我们只是结合了Splitter和AggregatorEIP。

　　分割和汇总视频流，以实现公共部门的安全和监视

　　以下显示了使用Kafka进行安全和监视的视频流的用例：

　　在这种情况下，视频流是现代化SIEM(安全信息和事件管理)的一部分。音频流的工作方式非常相似。

　　智能城市是使用Kafka进行视频，图像和音频处理的另一个例子。

　　Kafka用于大型邮件有效负载—大数据文件(CSV，视频，专有)

　　在上方，我们已经看到了处理特定大型消息的示例：图像，视频，音频。在许多用例中，需要处理其他类型的文件。大文件包括：

　　结构化数据，例如大型CSV文件

　　非结构化数据，例如完整视频(非连续视频流)或其他二进制文件，例如分析模型

　　如前所述，Kafka不是存储大文件的正确技术。为此构建了特定的工具，包括对象存储，例如AWSS3或MinIO。

　　该索赔检查EIP是这个问题的完美解决方案：

　　Kafka中的元数据并链接到外部存储以在媒体行业中传输大型视频文件

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

　　快速外部化大型负载以实现金融服务专有系统的旧式集成

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

　　与上面使用的“声明检查EIP”类似，你还可以利用KafkaConnect及其单消息转换(SMT)功能：

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

　　使用Kafka的自然语言处理(NLP)和大型文本文件的机器学习就是一个很好的例子。“使用Python，Java和ApacheKafka的连续NLP管道”展示了如何使用Kafka流，KafkaConnect和S3序列化器/反序列化器实现上述设计模式。

　　我喜欢这个示例，因为它还解决了数据科学家(喜欢Python)和生产工程师(喜欢Java)之间的阻抗失配问题。“使用Python，Jupyter，KSQL和TensorFlow进行机器学习”将更详细地探讨这一挑战。

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

　　你刚刚学习了如何通过使用Kafka将大文件外部化到对象存储中并仅通过Kafka发送元数据来处理它们。在某些用例中，这是太多的工作或成本。直接通过Kafka发送大文件是可能的，有时易于实现。该体系结构更加简单且更具成本效益。

　　我已经在上面讨论了权衡问题。但是，这是使用Kafka本地发送大文件的一个很好的用例：聊天应用程序中的附件，用于客户服务。

　　高盛(GoldmanSachs)是一个使用Kafka聊天系统的金融公司的例子。他们领导了Symphony的开发，Symphony是一项行业计划，旨在为即时通信和内容共享构建基于云的平台，从而安全地连接市场参与者。Symphony基于一种开源业务模型，该模型具有成本效益，可扩展性和可定制性，可以满足最终用户的需求。许多其他FinServ公司也投资了Symphony，包括美国银行，纽约梅隆银行，贝莱德，城堡，花旗银行，瑞士信贷，德意志银行，高盛，汇丰银行，杰富瑞，摩根大通，小牛，摩根士丹利，野村和富国银行。

　　Kafka非常适合聊天应用程序。代理存储和去耦非常适合多平台和多技术基础架构。Kafka还内置了脱机功能和使用旧消息。这是游戏行业聊天平台的示例：

　　附件(如文件，图像或任何其他二进制内容)可以是此实现的一部分。不同的架构是可能的。例如，你可以使用专用的Kafka主题来处理大型消息。或者，你只是将它们放入“聊天消息”事件中。使用ConfluentSchemaRegistry，该模式可以具有属性“attachment”。或者，你可以使用上面讨论的ClaimCheckEIP将附件外部化。

　　Kafka本机处理大消息有其用例！

　　正如你在本文中所了解的那样，存在许多用例来使用ApacheKafka及其生态系统处理大型消息文件。Kafka是为大容量/吞吐量而构建的—这是大消息所必需的。“在ConfluentCloud中将ApacheKafka每秒扩展到10+GB每秒”是一个令人印象深刻的例子。

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

　　Kafka本机处理大型消息的常见方案是处于边缘，那里通常没有其他数据存储，否则将增加配置基础结构的成本和复杂性。