Kafka

本文由阿里巴巴高级技术专家邓小勇（静行）分享，主要用 Demo 演示如何通过实时计算 Flink 实时计算pv/uv的场景。内容将从以下几部分进行： App 计算 pv/uv 场景 实现方案（From Flink-1.11） DDL DML 实操 首先为大家展示一个比较简单的pv/uv场景。以下图所示的APP为例，整个业务构架需要几个入口，包括用户访问入口、作者入口和运营人员入口。在运营人员入口进去可以查看系统的一些指标，比如app 的pv/uv。 在开始介绍如何计算实时pv/uv之前，可以先了解下上图的10个字段和它们对应的含义。通过这些字段可以了解到，用户在APP上的任何一次操作都会在数据库中留下一条对应的记录，所有记录就是该用户在APP上的操作流水。 那么如何实时计算pv/uv呢？ 有两种方案。 方案一，MySQL的变更数据同步到Kafka后进行实时计算。由于 Flink在设计之初是具有流表二象性的，所以在 Flink 1.1版本之后，就可以实现 Flink 对 Kafka变更数据的处理了，包括处理一些修改、删除等操作。处理后的结果会放到阿里云Hologress里，方便用户进行大数据查询和分析。 方案二，从上图可以看到方案一比方案二只多了一个Kafka，在 Flink 1.11 版本之后，可以直接通过Debezium连接MySQL，然后经过Flink 实时计算

目录 开篇导语 序列化器 分区器 Flink中的Kafka序列化器 源码解读 自定义序列化器示例 Flink中的Kafka分区器 源码解读 自定义分区器示例 结束语 开篇导语 Flink将数据sink至Kafka的过程中，在初始化生产者对象FlinkKafkaProducer时通常会采用默认的分区器和序列化器，这样数据只会发送至指定Topic的某一个分区中。对于存在多分区的Topic我们一般要自定义分区器和序列化器，指定数据发送至不同分区的逻辑。 此篇博客所涉及的组件版本 Flink：1.10.0 Kafka：2.3.0 序列化器 在Kafka生产者将数据写入至Kafka集群中时，为了能够在网络中传输数据对象，需要先将数据进行序列化处理，对于初学者来说，在初始化生产者对象时，一般都会采用默认的序列化器。 默认的序列化器不会对数据进行任何操作，也不会生成key。如果我们需要指定数据的key或者在数据发送前进行一些定制化的操作，那么我们就需要自定义序列化器，并且在初始化生产者对象时指定我们自己的序列化器。 分区器 对于Kakfa中一个topic存在多个分区的情况下，我们怎么知道发送的数据会被分配到哪个分区呢，这时候就要通过分区器来进行区分。 在Kafka中，主要有以下四种数据分区策略 第一种分区策略：给定了分区号，直接将数据发送到指定的分区里面去 第二种分区策略：没有给定分区号

本文将学习Kafka生产者的使用和原理，文中使用的kafka-clients版本号为2.6.0。下面进入正文，先通过一个示例看下如何使用生产者API发送消息。 public class Producer { public static void main (String[] args) { // 1. 配置参数 Properties properties = new Properties(); properties.put( "bootstrap.servers" , "localhost:9092" ); properties.put( "key.serializer" , "org.apache.kafka.common.serialization.StringSerializer" ); properties.put( "value.serializer" , "org.apache.kafka.common.serialization.StringSerializer" ); // 2. 根据参数创建KafkaProducer实例（生产者） KafkaProducer<String, String> producer = new KafkaProducer<>(properties); // 3. 创建ProducerRecord实例（消息） ProducerRecord

上一篇 说了一个案例是为了说明如何去考量一个Kafka集群的部署，算是一个参考吧，毕竟大家在不同的公司工作肯定也会有自己的一套实施方案。 这次我们再回到原理性的问题，这次会延续 第一篇 的风格，带领大家把图一步一步画出来。 Kafka的Producer原理 首先我们得先有个集群吧，然后集群中有若干台服务器，每个服务器我们管它叫Broker，其实就是一个个Kafka进程。 如果大家还记得 第一篇 的内容，就不难猜出来，接下来肯定会有一个controller和多个follower，还有个ZooKeeper集群，一开始我们的Broker都会注册到我们的ZooKeeper集群上面。 然后controller也会监听ZooKeeper集群的变化，在集群产生变化时更改自己的元数据信息。并且follower也会去它们的老大controller那里去同步元数据信息，所以一个Kafka集群中所有服务器上的元数据信息都是一致的。 上述准备完成后，我们正式开始我们生产者的内容。 名词1——ProducerRecord 生产者需要往集群发送消息前，要先把每一条消息封装成ProducerRecord对象，这是生产者内部完成的。之后会经历一个序列化的过程。之前好几篇专栏也是有提到过了，需要经过网络传输的数据都是二进制的一些字节数据，需要进行序列化才能传输。 此时就会有一个问题

简介： 为了消灭数据孤岛，企业往往会把各个组织的数据都接入到数据湖以提供统一的查询或分析。本文将介绍流利说当前数据接入的整个过程，期间遇到的挑战，以及delta在数据接入中产生的价值。 背景 流利说目前的离线计算任务中，大部分数据源都是来自于业务 DB，业务DB数据接入的准确性、稳定性和及时性，决定着下游整个离线计算 pipeline 的准确性和及时性。同时，我们还有部分业务需求，需要对 DB 中的数据和 hive 中的数据做近实时的联合查询。 在引入阿里云 EMR Delta Lake 之前，我们通过封装 DataX 来完成业务 DB 数据的接入，采用 Master-Slave 架构，Master 维护着每日要执行的 DataX 任务的元数据信息，Worker 节点通过不断的以抢占的方式获取状态为 init 和 restryable 的 DataX 任务来执行，直到当天的所有的 DataX 任务全都执行完毕为止。 架构图大致如下: Worker 处理的过程如下: 对于近实时需求，我们是直接开一个从库，配置 presto connector 去连接从库，来实现业务 BD 中的数据和 hive 中的数据做近实时的联合查询需求。 这种架构方案的优点是简单，易于实现。但是随着数据量也来越多，缺点也就逐渐暴露出来了: 性能瓶颈: 随着业务的增长，这种通过 SELECT

简介： 如何使用实时计算 Flink 搞定数据处理难题？实时计算 Flink 客训练营产品、技术专家齐上阵，从 Flink的发展、 Flink 的技术原理、应用场景及行业案例，到开源Flink功能介绍和实时计算 Flink 优势详解，现场实操，9天即可上手！ 本篇内容将介绍如何实时计算 Flink 与自身环境打通。 一、运行作业的Jar如何存储在OSS上 在VVP平台有两种方法可以上传作业的jar。 方法一 ，借助VVP提供的资源上传功能，可以直接使用这个功能对Jar进行上传目前该功能支持200兆以内的Jar包上传。使用时，直接在创建作业的时候选择上传的jar包就可以了，演示如下： ● 进入到VVP平台，点击左侧资源上传功能，然后在打开页面点击右上角的上传资源，选择要上传的Jar包，完成上传； ● 上传成功后，点击左侧创建作业，完善作业名等信息。在Jar URI栏，下拉选择刚刚上传的Jar包，点击确定完成创建作业，然后启动即可使用。 方法二 ，直接在OSS的控制台上面，将要使用的Jar上传上去，然后使用OSS是提供的Jar链接来行使用。使用的时候也比较简单，直接使用OSS提供的Jar链接，演示如下： ● 打开OSS控制台，选择在创建VVP时候使用的Bucket，再选择目录，点击上传文件，上传时可以将它的权限设置为公共读，点击上传文件即完成； ● 使用时

Kafka 简介 Apache Kafka 是一个分布式发布-订阅消息系统。是大数据领域消息队列中唯一的王者。最初由 linkedin 公司使用 scala 语言开发，在2010年贡献给了Apache基金会并成为顶级开源项目。至今已有十余年，仍然是大数据领域不可或缺的并且是越来越重要的一个组件。 Kafka 适合离线和在线消息，消息保留在磁盘上，并在集群内复制以防止数据丢失。kafka构建在zookeeper同步服务之上。它与 Flink 和 Spark 有非常好的集成，应用于实时流式数据分析。 Kafka特点： 可靠性：具有副本及容错机制。 可扩展性：kafka无需停机即可扩展节点及节点上线。 持久性：数据存储到磁盘上，持久性保存。 性能：kafka具有高吞吐量。达到TB级的数据，也有非常稳定的性能。 速度快：顺序写入和零拷贝技术使得kafka延迟控制在毫秒级。 Kafka 底层原理 先看下 Kafka 系统的架构 Kafka 架构 kafka支持消息持久化，消费端是主动拉取数据，消费状态和订阅关系由客户端负责维护， 消息消费完后，不会立即删除，会保留历史消息 。因此支持多订阅时，消息只会存储一份就可以。 broker ：kafka集群中包含一个或者多个服务实例（节点），这种服务实例被称为broker（一个broker就是一个节点/一个服务器）； topic

ARTS A001 2021W2(2021-01-16) Algorithm # Category Difficulty Title Solution 1 algorithms Easy Two Sum java Review Maximizing Developer Effectiveness , Tim Cochran, 06 January 2021 Tip Java UUID Share OutOfMemory的Kafka学习笔记(1) 来源： oschina 链接： https://my.oschina.net/wang7x/blog/4910951

基于事件驱动的系统架构在日常的平台开发中早已司空见惯，通过消息队列进行事件的发送，然后分别构建对应的生产者和消费者。不过在传统的业务开发模式不同的事件会有不同的格式，不同的生产者生成出的事件格式也各不相同，消费者能消费的格式也是千差万别，本质上事件、生产者、消费者还是耦合的。那如何解决该问题呢？那就是我们今天要聊的CloudEvent。 CloudEvent简介 从官网的CloudEvents描述中我们可以看出，CloudEvent本质上就是一个描述事件数据的规范。所以对于CloudEvents的学习有的时候，我们更多的应该是取理解其设计规范，而不是其所呈现出的数据结构形态。就像大家去学tcp协议一样， 你不是去学的这个字段叫什么，而是要理解为什么会有这个字段，其解决的问题是什么。 如何解耦 对于CloudEvents的学习笔者采用自顶向下的方式来进行学习，即先去了解CloudEvents是如何在平台上进行事件、消费者、生产者的解耦，然后在去思考底层的相关字段的细节 一个事件的生命周期通常会包含生产、传输、消费三个环节，下面我们分别对这三个环节来进行介绍cloudevent与传统事件开发模式的区别。 事件生产 在传统的开发模式下不同的业务生产的的事件也各不相同，并且事件本身数据会相对较少，更多的是类似信号传递的角色，即通知后端服务某个类型事件发生了

目录 一、集群使用场景 二、集群搭建 1.ZooKeeper集群搭建 2.Kafka集群搭建 三、多集群同步 1.配置 2.调优 总结 集群是一种计算机系统， 它通过一组松散集成的计算机软件和/或硬件连接起来高度紧密地协作完成计算工作。在某种意义上，他们可以被看作是一台计算机。集群系统中的单个计算机通常称为节点，通常通过局域网连接，但也有其它的可能连接方式。集群计算机通常用来改进单个计算机的计算速度和/或可靠性。一般情况下集群计算机比单个计算机，比如工作站或超级计算机性能价格比要高得多。 集群的特点 集群拥有以下两个特点： 可扩展性 ：集群的性能不限制于单一的服务实体，新的服务实体可以动态的添加到集群，从而增强集群的性能。 高可用性 ：集群当其中一个节点发生故障时，这台节点上面所运行的应用程序将在另一台节点被自动接管，消除单点故障对于增强数据可用性、可达性和可靠性是非常重要的。 集群的能力 负载均衡 ：负载均衡把任务比较均匀的分布到集群环境下的计算和网络资源，以提高数据吞吐量。 错误恢复 ：如果集群中的某一台服务器由于故障或者维护需要无法使用，资源和应用程序将转移到可用的集群节点上。这种由于某个节点的资源不能工作，另一个可用节点中的资源能够透明的接管并继续完成任务的过程，叫做错误恢复。 负载均衡和错误恢复要求各服务实体中有执行同一任务的资源存在，而且对于同一任务的各个资源来说