服务启动时，会给cloud-stream 装载绑定中间件的配置，而spring cloud stream默认使用的序列化方式为ByteArraySerializer,这就导致stream 在发送数据时使用l了服务装载StringSerializer序列化方式，从而导致了java.lang.ClassCastException: [B > cannot be cast to java.lang.String的问题出现。
作者：肖力涛 前言 在WeTest舆情项目中，需要对每天千万级的游戏评论信息进行词频统计，在生产者一端，我们将数据按照每天的拉取时间存入了Kafka当中，而在消费者一端，我们利用了spark streaming从kafka中不断拉取数据进行词频统计。 本文首先对spark streaming嵌入kafka的方式进行归纳总结，之后简单阐述Spark streaming+kafka 在舆情项目中的应用，最后将自己在Spark Streaming+kafka 的实际优化中的一些经验进行归纳总结。（如有任何纰漏欢迎
该文介绍了如何利用Spark Streaming进行实时数据处理，包括批处理和流处理。文章首先介绍了Spark Streaming的基本概念、适用场景、工作原理和关键概念，然后详细讲解了如何利用Spark Streaming进行批处理和流处理，以及如何处理Kafka等分布式消息队列。最后，作者提供了一些优化建议，以提升Spark Streaming的性能和稳定性。
随着数据湖概念的流行，涌现了很多关于Apache Hudi的文章，但很多文章在阐述时仅仅将Hudi当做一种表格式，这引发了社区的思考，思考Hudi的愿景到底是什么，并且在Hudi社区发起了讨论重新审视Hudi。
实时订单开发，说实话，最近开发，掉了一半的头发，复杂度，我就点到为止，还是希望大家多看看flink，这个可是开发利器。写这篇文章的目的，就是给大家分享一下实时订单的开发思路和遇到问题如何去解决。我就写的比较简单点，很多花里胡哨的业务逻辑我就隐藏了，以及给下游提供数据，给策略提供数据这些我就不追溯了。
Kafka Connect 是一个工具，它可以帮助我们将数据从一个地方传输到另一个地方。比如说，你有一个网站，你想要将用户的数据传输到另一个地方进行分析，那么你可以使用 Kafka Connect 来完成这个任务。
Kafka Connect 是 Apache Kafka 的一部分，提供了数据存储和 Kafka 之间的流式集成。对于数据工程师来说，只需要配置 JSON 文件就可以使用 。Kafka 为一些常见数据存储的提供了 Connector，比如，JDBC、Elasticsearch、IBM MQ、S3 和 BigQuery 等等。对于开发人员来说，Kafka Connect 提供了丰富的 API，如果有必要还可以开发其他 Connector。除此之外，还提供了用于配置和管理 Connector 的 REST API。
根据数据来源不同可以分为OGG数据和Canal数据，两者之间有相同的属性：table，因此将该属性作为公共属性进行提取，抽象成基类
无论你将kafka当作一个队列、消息总线或者数据存储平台，你都需要通过一个生产者向kafka写入数据，通过一个消费者从kafka读取数据。或者开发一个同时具备生产者和消费者功能的程序来使用kafka。 例如，在信用卡交易处理系统中，有一个客户端的应用程序（可能是一个在线商店）在支付事物发生之后将每个事物信息发送到kafka。另外一个应用程序负责根据规则引擎去检查该事物，确定该事物是否被批准还是被拒绝。然后将批准/拒绝的响应写回kafka。之后kafka将这个事物的响应回传。第三个应用程序可以从kafka中读取事物信息和其审批状态，并将他们存储在数据库中，以便分析人员桑后能对决策进行检查并改进审批规则引擎。 apache kafka提供了内置的客户端API，开发者在开发与kafka交互的应用程序时可以使用这些API。 在本章中，我们将学习如何使用kafka的生产者。首先对其设计理念和组件进行概述。我们将说明如何创建kafkaProducer和ProducerRecord对象。如何发送信息到kafka，以及如何处理kafak可能返回的错误。之后，我们将回顾用于控制生产者行为的重要配置选项。最后，我们将深入理解如何使用不同的分区方法和序列化。以及如何编写自己的序列化器和分区器。 在第四章我们将对kafka消费者客户端和消费kafka数据进行阐述。
flink任务本身提供了各种类型的指标监控，细化到了每一个Operator的流入/流出量、速率、Watermark值等，通常在实际应用中需要对接入数据做格式化例如转json，符合要求的数据会向下流动，不符合要求或者格式化异常称为脏数据会被过滤掉，现在目标实现一个通用化方式能够对正常数据与脏数据进行指标统计。 实现思路：
内容架构是 QQ 浏览器搜索的内容接入和计算层，主要负责腾讯域内的内容接入和处理，当前接入了多个合作方的上千类内容。正如前面《如何避免旧代码成包袱？5步教你接手别人的系统》中提到，这是一套包含 93 个小服务的微服务架构。经过 23 年 Q1 的大力治理，让我们稳住阵脚，进一步对老系统做深入的评估：
在第一篇博客我们了解到一个kafka系统，通常是生产者Producer 将消息发送到 Broker，然后消费者 Consumer 去 Broker 获取，那么本篇博客我们来介绍什么是生产者Producer。
上一篇文章我们主要介绍了什么是 Kafka，Kafka 的基本概念是什么，Kafka 单机和集群版的搭建，以及对基本的配置文件进行了大致的介绍，还对 Kafka 的几个主要角色进行了描述，我们知道，不管是把 Kafka 用作消息队列、消息总线还是数据存储平台来使用，最终是绕不过消息这个词的，这也是 Kafka 最最核心的内容，Kafka 的消息从哪里来？到哪里去？都干什么了？别着急，一步一步来，先说说 Kafka 的消息从哪来。
在本文章中，我们创建一个简单的 Java 生产者示例。我们会创建一个名为 my-topic Kafka 主题（Topic），然后创建一个使用该主题发送记录的 Kafka 生产者。Kafka 发送记录可以使用同步方式，也可以使用异步方式。
摘要：本文介绍了 Flink CDC 利用 Kafka 进行 CDC 多源合并和下游同步更新的实践分享。内容包括：
KafkaProducer会将消息先放入缓冲区中，然后由单独的sender线程异步发送到broker服务端，那么既然消息是批量发送的，那么触发批量发送的条件是什么呢？
上篇文章说了，kafka新版旧版的区别，producer全部异步发消息，并且提供回调机制callback，判断是否成功，通过分批次发送batching保证吞吐量，分区策略更加合理，旧版本默认是在一段时间内把消息发到固定区域，新版本采用轮询，消息更加均匀。Consumer新版为单线程执行，单个consumer线程管理多个socker，在10版本后，加入了心跳线程，这最多也就算了是双线程。偏移量 在新版本交给kafka处理，舍弃了zookeeper，这样可以依赖kafka备份机制天然实现高可用原理。
关于大数据面试中对Spark的知识考查不需本菌多解释什么了吧~本篇博客，博主为大家分享20个Spark热门技术点，希望今年出去面试，实习的同学，尤其是想去大厂的同学，一定要把下面的20个技术点看完。
Flink 1.12 版本在 20 年 12 月已经正式 Release，目前我们的 Flink SQL 作业的 Flink 引擎版本还是 1.10，本文主要用以评估 Flink 1.10 升级到 1.12 整体所能带来的预期收益，同时结合所需投入的成本，决定是否需要升级 Flink SQL 引擎版本到 1.12。本次升级所评估的收益包含 1.11 和 1.12 版本所带来的收益，如有理解错误，欢迎指出，一起交流。
在Apache Hudi中，Hudi的一条数据使用HoodieRecord这个类表示，其中包含了hoodie的主键，record的分区文件位置，还有今天本文的关键，payload。payload是一个条数据的内容的抽象，决定了同一个主键的数据的增删改查逻辑也决定了其序列化的方式。通过对payload的自定义，可以实现数据的灵活合并，数据的自定义编码序列化等，丰富Hudi现有的语义，提升性能。
Spring Kafka 是 Spring Framework 提供的一个集成 Apache Kafka 的库，用于构建基于 Kafka 的实时数据流处理应用程序。Apache Kafka 是一个高性能、分布式的流数据平台，广泛用于构建可扩展的、实时的数据处理管道。
本文章部分内容摘自 朱忠华老师的《深入理解Kafka：核心设计与实践原理》，也特别推荐广大读者购买阅读。
Java的序列化机制是通过在运行时判断类的serialVersionUID来验证版本一致性的。在进行反序列化时，JVM会把传来 的字节流中的serialVersionUID与本地相应实体（类）的serialVersionUID进行比较，如果相同就认为是一致的，可以进行反序 列化，否则就会出现序列化版本不一致的异常。
本文介绍了如何在 IntelliJ IDEA 中自动生成 serialVersionUID，从而解决在实现 Serializable 接口时无法自动生成 serialVersionUID 的问题。首先，介绍了如何安装并设置 GenerateSerialVersionUID 插件。然后，介绍了通过设置 Inspections 功能，在创建类并实现 Serializable 接口时生成 serialVersionUID 的步骤。
Apache IoTDB v0.13.1 已经发布，此版本是 0.13.0 的 bug-fix 版，主要修复了对齐序列的相关读写异常，memtable 刷盘异常、重启异常等。同时进行了一些改进，如支持对结果集空值的过滤，通过 Session 根据模板创建时间序列等，支持 select 表达式中填写常量，C++ 写入接口避免排序的优化等。
简单来说，Java的序列化机制是通过类的serversionUID来验证版本一致性的。在反序列化时，JVM会将传来的字节流中的serialVersionUID与本地相应实体类的serialVersionUID进行比较，如果相同就认为是一致的，如果相同就认为是一致的，可以进行反序列化，否则就会出现序列化版本不一致的异常，即是InvalidCastException。
当我们有需求将HashMap转为Json格式的String时，切记不要使用HashMap的toString()方法，需要使用FastJson/Gson将HashMap转为String。如果使用toString()方法进行转换时，是无法将字符串再转为HashMap的。它只会出现序列化报错：
其中KafkaProducer是⽤于发送消息的类，ProducerRecord类⽤于封装 Kafka 的消息。
上篇聊了Kafka概况，包含了Kafka的基本概念、设计原理，以及设计核心。本篇单独聊聊Kafka的生产者，包括如下内容：
Producer 的拦截器（Interceptor）和 Consumer 的 Interceptor 主要⽤于实现Client端的定制化控制逻辑。 对于Producer⽽⾔，Interceptor使得⽤户在消息发送前以及Producer回调逻辑前有机会对消息做⼀些定制化需求，⽐如修改消息等。同时，Producer允许⽤户指定多个Interceptor按序作⽤于同⼀条消息从⽽形成⼀个拦截链(Interceptor Chain)。Intercetpor 的实现接⼝是org.apache.kafka.clients.producer.ProducerInterceptor，其定义的⽅法包括：
导读：大家好，很荣幸跟大家分享 Apache Beam 架构原理及应用实践。讲这门课之前大家可以想想，从进入 IT 行业以来，不停的搬运数据，不管职务为前端，还是后台服务器端开发。随着这两年科技的发展，各种数据库，数据源，应运而生，大数据组件，框架也是千变万化，从 Hadoop 到现在的 Spark、Flink，数据库从先前的 oracle、MySQL 到现在的 NOSQL，不断延伸。那么有没有统一的框架，统一的数据源搬砖工具呢？
现 Kafka Producer 需要把 Customer 类的对象序列化成字节数组发送给 Kafka Broker，同时 Kafka Consumer 需要把字节数组反序列化为一个 Customer 对象
应用程序通过KafkaConsumer订阅一个topic之后收取数据来完成从kafka的数据读取。从kafka读取数据与从其他消息系统读取数据只有少许不同，几乎没用什么独特的概念。如果不理解这些概念，你将很难使用消费者API。我们首先对一些重要的概念进行解释，然后介绍一些示例，这些示例展示了使用消费者API在不同需求的应用程序中的不同方式。
最近IntelliJ又由于自己的骚操作给弄崩溃了，导致之前弄的一大波配置又找不到了，十分蛋疼的又要开始重头开始弄环境。很多之前精心搞过的配置又都记不住了，为了防止以后出现这种情况，这里就把我日常用的配置和注意点记一下，免得以后又要重新摸索。尽量持续更新。
Apache Kafka 是由 Apache 软件基金会开发的开源分布式流处理平台。最初是由 LinkedIn 团队开发，用于处理该公司产生的大量实时数据。Kafka 的设计旨在处理大型数据流并提供实时数据处理能力。
serialVersionUID用作Serializable类中的版本控件。如果您没有显式声明serialVersionUID，JVM将根据您的Serializable类的各个方面自动为您执行此操作，如Java（TM）对象序列化规范中所述。 序列化运行时将每个可序列化类与版本号相关联，称为serialVersionUID，在反序列化期间使用该版本号来验证序列化对象的发送方和接收方是否已加载与该序列化兼容的该对象的类。如果接收者为具有与相应发送者类的serialVersionUID不同的对象加载了一个类，则反序列化将导致InvalidClassException。 通俗理解就是serialVersionUID是适用于Java的序列化机制，Java的序列化机制是通过判断类的serialVersionUID来验证版本一致性的。在进行反序列化时，JVM会把传来的字节流中的serialVersionUID与本地相应实体类的serialVersionUID进行比较，如果相同就认为是一致的，可以进行反序列化，否则就会出现序列化版本不一致的异常，即是java.io.InvalidClassException。 serialVersionUID两种生成方式： a.显式声明，该字段必须是static，final和long类型： private static final long serialVersionUID = 1L; b.如果没有显式声明serialVersionUID，JVM将使用自己的算法生成默认SerialVersionUID。
Apache Flink 作为流式处理领域的先锋，为实时数据处理提供了强大而灵活的解决方案。其中，KafkaSink 是 Flink 生态系统中的关键组件之一，扮演着将 Flink 处理的数据可靠地发送到 Kafka 主题的角色。本文将深入探讨 KafkaSink 的工作原理、配置和最佳实践，帮助读者全面掌握在 Flink 中使用 KafkaSink 的技巧和方法。
KafkaProperties-> Consumer->valueDeserializer
前面我们总结了broker端的核心参数，一些服务端原理细节后面文章再聊。本文我们重点讨论Producer端的消息发送机制，希望通过本文我们能整体掌握Producer端的原理。
KafkaProducer 是线程安全的，可以在多个线程中共享单个 KafkaProducer 实例，也可以将 KafkaProducer 实例进行池化来供其他线程调用。
类通过实现 java.io.Serializable 接口以启用其序列化功能。未实现此接口的类将无法进行序列化或反序列化。可序列化类的所有子类型本身都是可序列化的。
ConsumerInterceptor是Kafka中的一个重要组件，它允许开发人员在Kafka消费者端拦截和修改消息的处理过程。ConsumerInterceptor可以用于实现各种功能，从消息监控到数据转换和错误处理，为开发人员提供了更大的灵活性和可定制性。
发送拉取消息和Broker服务端存储消息，都是以批为单元进行的，消费者在拉取消息后，在客户端把批消息解开，再一条一条交给用户代码处理。
http://spark.apache.org/docs/2.4.5/structured-streaming-kafka-integration.html
通过前面 7 篇文章的介绍，小伙伴们应该对 Kafka 运行工作原理有一个相对比较清晰的认识了。为了提高平时的工作效率，帮助我们快速定位一些线上问题，比如查看部分 Partition 堆积机器 IP 等操作，这篇文章总结了一些平时常用到的一些 Kafka 命令及常用配置，方便日后查阅（该文章中提到的相关配置会持续更新）。
serialVersionUID是在Java序列化、反序列化对象时起作用的一个字段。Java的序列化机制是通过判断类的serialVersionUID来验证版本一致性的。在进行反序列化时，JVM会把传来的字节流中的serialVersionUID与本地相应实体类的serialVersionUID进行比较，如果相同就认为是一致的，可以进行反序列化，否则就会出现序列化版本不一致的异常，即是InvalidClassException。
作为消息队列，Kafka允许发布和订阅数据，这点和其他消息队列类似，但不同的是，Kafka作为一个分布式系统，是以集群的方式运行的，可以自由伸缩。同时还提供了数据传递保证—可复制、持久化等。
FlinkKafkaConsumer08可以消费一个或多个Kafka topic的数据，它的构造器需要接收以下参数:
众所周知，Kafka作为一款优秀的消息中间件，在我们的日常工作中，我们也会接触到Kafka，用其来进行削峰、解耦等，作为开发的你，是否也是这么使用kafka的：
领取专属 10元无门槛券
手把手带您无忧上云
