partition

spark map和mapPartitions的区别和使用场景 map和mapPartitions的主要区别： 1） map ：一次处理一个元素的数据 2）mapPartitions：一次处理一批数据 mapPartitions的优缺点： 优点： 速度快 ，一次处理一批数据，即一次接收所有的partition数据，在map过程中需要频繁创建额外的对象(例如将rdd中的数据通过jdbc写入数据库，map需要为每个元素创建一个链接，而mapPartition为每个partition创建一个链接)，则mapPartitions效率比map高的多。 缺点： 容易出现内存溢出 ，当接收的partition的数据量较大时，例如100万数据， 一次传入一个function以后，那么可能一下子内存不够，但是又没有办法去腾出内存空间来，可能就导致OOM（内存溢出）；而map一般较少出现内存溢出。 mapPartitions()出现内存溢出时的解决方法： 将数据切成较多的partition： repartition(100).mapPartitions(xx) 设置较大的处理器内存 --executor-memory 8g 代码demo_1.py： 每个partition仅仅初始化一次 Personas对象 def spark_get_order_personal_res(): spark_conf

目录 Kafka 简介 使用消息队列的好处 Kakfa 架构 分区 Kafka 简介 Kafka最初是由LinkedIn公司采用Scala语言开发的一个多分区、多副本并且基于ZooKeeper协调的分布式消息系统，现在已经捐献给了Apache基金会。目前Kafka已经定位为一个分布式流式处理平台，它以 高吞吐、可持久化、可水平扩展、支持流处理等多种特性而被广泛应用。 Kafka 是一个分布式的基于发布/订阅模式的消息队列（Message Queue），主要应用于大数据实时处理领域。 使用消息队列的好处 解耦 允许你独立的扩展或修改两边的处理过程，只要确保它们遵守同样的接口约束。 可恢复性 系统的一部分组件失效时，不会影响到整个系统。消息队列降低了进程间的耦合度，所以即使一个处理消息的进程挂掉，加入队列中的消息仍然可以在系统恢复后被处理。 缓冲 有助于控制和优化数据流经过系统的速度，解决生产消息和消费消息的处理速度不一致的情况。 灵活性 & 峰值处理能力 在访问量剧增的情况下，应用仍然需要继续发挥作用，但是这样的突发流量并不常见。如果为以能处理这类峰值访问为标准来投入资源随时待命无疑是巨大的浪费。使用消息队列能够使关键组件顶住突发的访问压力，而不会因为突发的超负荷的请求而完全崩溃。 异步通信 很多时候，用户不想也不需要立即处理消息。消息队列提供了异步处理机制

Labels 选择器 The API currently supports two types of selectors: equality-based and set-based . "metadata": { "labels": { "key1" : "value1", "key2" : "value2" } } 与 Name和UID 不同，标签不需要有唯一性。一般来说，我们期望许多对象具有相同的标签。 通过标签选择器（Labels Selectors），客户端/用户 能方便辨识出一组对象。标签选择器是kubernetes中核心的组成部分。 API目前支持两种选择器：equality-based（基于平等）和set-based（基于集合）的。标签选择器可以由逗号分隔的多个requirements 组成。在多重需求的情况下，必须满足所有要求，因此逗号分隔符作为AND逻辑运算符。 一个为空的标签选择器（即有0个必须条件的选择器）会选择集合中的每一个对象。 一个null型标签选择器（仅对于可选的选择器字段才可能）不会返回任何对象。 注意：两个控制器的标签选择器不能在命名空间中重叠。 Equality-based requirement 基于相等的要求 基于相等的或者不相等的条件允许用标签的keys和values进行过滤。匹配的对象必须满足所有指定的标签约束，尽管他们可能也有额外的标签

目录 客户端开发 必要的配置参数 消息的构建 消息的发送 客户端开发 步骤： 配置生产者参数 构建待发送的消息 发送消息 关闭生产者实例 Properties properties = new Properties(); properties.put(ProducerConfig.BOOTSTRAP_SERVERS_CONFIG,"localhost:9092"); properties.put(ProducerConfig.KEY_SERIALIZER_CLASS_CONFIG, StringSerializer.class); properties.put(ProducerConfig.VALUE_SERIALIZER_CLASS_CONFIG,StringSerializer.class); KafkaProducer producer = new KafkaProducer(properties); ProducerRecord producerRecord = new ProducerRecord("topic1","key","value"); try { producer.send(producerRecord); }catch (Exception e){ e.printStackTrace(); } 必要的配置参数 bootstrap.servers

Consumer Configuration在kafka 0.9+使用Java Consumer替代了老版本的scala Consumer。新版的配置如下： bootstrap.servers 在启动consumer时配置的broker地址的。不需要将cluster中所有的broker都配置上，因为启动后会自动的发现cluster所有的broker。 它配置的格式是：host1:port1;host2:port2… key.descrializer、value.descrializer Message record 的key, value的反序列化类。 group.id 用于表示该consumer想要加入到哪个group中。默认值是 “”。 heartbeat.interval.ms 心跳间隔。心跳是在consumer与coordinator之间进行的。心跳是确定consumer存活，加入或者退出group的有效手段。 这个值必须设置的小于session.timeout.ms ，因为： 当Consumer由于某种原因不能发Heartbeat到coordinator时，并且时间超过session.timeout.ms时，就会认为该consumer已退出，它所订阅的partition会分配到同一group 内的其它的consumer上。 通常设置的值要低于session.timeout

1.基本概念 *Producer: 消息生产者，往Topic发布消息 *Consumer: 消息消费者，往Topic取消息并处理 *Consumer Group: topic 可以广播给不同的group，一个group只能有一个consumer消费消息 *Broker(物理概念): Kafka集群，每个节点为一个broker *Topic(逻辑概念): 消息类别，对数据进行区分、隔离 *Partition(物理概念): Kafka存储的基本单位，一个Topic数据会被分散存储在多个Partition,每个Partition是有序的； 一个Partition只会在一个broker上； 消费者的数目<=Partition数目 *Replication:(副本) 同一个Partition可能会有多个Replication，多个Replication数据是一样的; 基本单位是Partition； 读和写都是在Leader； Follower实时复制Leader数据 *Replication Leader: 负责Partition上与Producer和Consumer的交互，一个Partition只有一个Leader 2.基本结构 3.特点 多分区、多副本、多订阅者、基于Zookeeper调度 高吞吐量、低延迟、高并发、时间复杂度为O(1) 数据可持久化、容错性、消息自动平衡 4

背景： 当今社会各种应用系统诸如商业、社交、搜索、浏览等像信息工厂一样不断的生产出各种信息，在大数据时代，我们面临如下几个挑战： 如何收集这些巨大的信息 如何分析它 如何及时做到如上两点 以上几个挑战形成了一个业务需求模型，即生产者生产（produce）各种信息，消费者消费（consume）（处理分析）这些信息，而在生产者与消费者之间，需要一个沟通两者的桥梁-消息系统。 从一个微观层面来说，这种需求也可理解为不同的系统之间如何传递消息。 Kafka诞生： 由 linked-in 开源 kafka-即是解决这类问题的一个框架，它实现了生产者和消费者之间的无缝连接。 kafka-高产出的分布式消息系统(A high-throughput distributed messaging system) Kafka特性： 它形容自己的设计是独一无二的，先看一下它有如何过人之处： 快：单个kafka服务每秒可处理数以千计客户端发来的几百MB数据。 可扩展性：一个单一集群可作为一个大数据处理中枢，集中处理各种类型业务 持久化：消息被持久化到磁盘（可处理TB数据级别数据但仍保持极高数据处理效率），并且有备份容错机制 分布式：着眼于大数据领域，支持分布式，集群可处理每秒百万级别消息 实时性：生产出的消息可立即被消费者消费 Kafka的组件： topic：消息存放的目录即主题 Producer

　　 其实Rocketmq的给第三方的插件已经全了，如果大家有兴趣的话请移步 https://github.com/apache/rocketmq-externals 。本文主要是结合笔者已有的rmq在spark中的应用经验对rocketmq做简单介绍以及经验总结，当然免不了会将rocketmq和如今特别火爆的kafka做一些对比（Ps：为了方便打字rmq后面会是rocketmq的缩写）。 　　 首先对rocktmq做一些流行的消息队列对比。 　　提到mq不得不提消息队列，对应于数据结构里面的“先进先出”的队列。而rocketmq就是应用于大数据时代拥有高吞吐低延迟特性的分布式消息拥有发布订阅功能的队列系统。这样的分布式消息系统主要提供应用解耦、流量消峰、消息分发等功能。本片不会对安装集群做过多的介绍，安装单机版本rmq的教程移步官方文档 http://rocketmq.apache.org/docs/quick-start/ 。 rocktmq是阿里研发主要作用于双十一这样的高峰期实时流数据处理，起初是基于activemq，但是随着对吞吐量的要求逐步提高，阿里的开发者们逐渐把眼光向kafka转移，但是kafka并不具备低延迟和高可靠性。因此阿里决定研究这样一个兼并传统的订阅消息系统的发布订阅场景与高并发零误差低延时的传输系统。 　　

timestamp 类型分区请移步=> MySql表分区(根据时间timestamp) 环境: 　　 MySql8.0.18 (5.6和5.7的未验证) 　　分区条件的字段类型是 datetime 完整的sql操作表分区的语句如下： -- 1.删除表 drop table t_test; -- =================================================================================== -- 2.创建一个表并对其分区,被创建分区的字段必须为主键,或者创建分区时表中没有主键 -- 2.1 方式一:表和分区一起创建 create table t_test ( id int, dates timestamp )partition by range (unix_timestamp(dates)) ( -- 小于2018-01-01的 partition p1 values less than (unix_timestamp('2018-01-01')), partition p2 values less than (unix_timestamp('2018-02-01')), partition p3 values less than (unix_timestamp('2018-03-01')), -- 大于2018

Kafka是分布式发布-订阅消息系统。它最初由LinkedIn公司开发，之后成为Apache项目的一部分。Kafka是一个分布式的，可划分的，冗余备份的持久性的日志服务。它主要用于处理活跃的流式数据。 在大数据系统中，常常会碰到一个问题，整个大数据是由各个子系统组成，数据需要在各个子系统中高性能，低延迟的不停流转。传统的企业消息系统并不是非常适合大规模的数据处理。为了已在同时搞定在线应用（消息）和离线应用（数据文件，日志）Kafka就出现了。Kafka可以起到两个作用： 降低系统组网复杂度。 降低编程复杂度，各个子系统不在是相互协商接口，各个子系统类似插口插在插座上，Kafka承担高速数据总线的作用。 1、Kafka主要特点： 同时为发布和订阅提供高吞吐量。据了解，Kafka每秒可以生产约25万消息（50 MB），每秒处理55万消息（110 MB）。 可进行持久化操作。将消息持久化到磁盘，因此可用于批量消费，例如ETL，以及实时应用程序。通过将数据持久化到硬盘以及replication防止数据丢失。 分布式系统，易于向外扩展。所有的producer、broker和consumer都会有多个，均为分布式的。无需停机即可扩展机器。 消息被处理的状态是在consumer端维护，而不是由server端维护。当失败时能自动平衡。 支持online和offline的场景。 2、Kafka的架构