partition

There are a number of questions about how to obtain the number of partitions of a n RDD and or a DataFrame : the answers invariably are: rdd.getNumPartitions or df.rdd.getNumPartitions Unfortunately that is an expensive operation on a DataFrame because the df.rdd requires conversion from the DataFrame to an rdd . This is on the order of the time it takes to run df.count I am writing logic that optionally repartition 's or coalesce 's a DataFrame - based on whether the current number of partitions were within a range of acceptable values or instead below or above them. def repartition(inDf:

常用命令总结： 创建主题： ./kafka-topics.sh --create --topic words --replication-factor 3 --partitions 3 --zookeeper cloud0001:2181 查看主题： ./kafka-topics.sh --list --zookeeper cloud0001:2181 消费者客户端消费信息： ./kafka-console-consumer.sh --bootstrap-server cloud0001:9092 --from-beginning --topic words 消息只能被消费组里面的一个消费者消费，如果被多个消费者消费，这些消费者必须在不同的消费组里面。 Kafka需要维持的元数据只有一个offset值，Consumer每消费一个消息，offset就会加1，消息的状态完全是由Consumer控制的，Consumer可以跟踪和重设这个offset值，这样的话Consumer就可以读取任意位置的消息。 replication-factor是以partition为单位的，只有一个partition的副本会被选举成leader作为读写用. Producer在发送消息后，会得到一个响应，出现了一个重要的参数：默认值好像是0，在Producer中配置。 acks = 0 :

背景分析 消息队列这个类型的组件一直是非常重要的组件，当经过两家企业后我就很坚信这个结论了。队列这种东西，最广泛的作用还是在于解耦，宽泛一点的说，它可以将不同部门的工作内容进行有效的整合，基于一个约定好的格式，就可以两头互相不干扰的进行开发。可以说这个生产消费的思想不仅仅适用于程序也适用于非常多的地方。 目前对于我看到的来说，kafka更多的还是做为一个数据源，数据桥梁的作用，不同业务之间的沟通。比如需要实时接入A部门的业务数据的话，就会有这样的手段： 落地到HDFS的数据会用来进行一些算法上的离线处理，而kafka端则是给需要实时性的消费方。其实数据的消费方式无非也就实时和离线两种方式。 Kafka和activemq对比 相比过去经常使用的activemq，kafka确实非常的不同，做一个对比来深化印象 对比 Activemq Kafka 接口协议 遵守JMS规范,各语言支持较好 没有遵循标准MQ接口协议,使用较为复杂 吞吐量 较低，磁盘随机读写 较高，磁盘顺序读写 游标位置 AMQ来管理，无法读取历史数据 客户端自己管理，不乐意甚至重新读一遍也行 HA机制 主从复制,竞争锁的方式来选举新的主节点 和hadoop系列产品一样,由zk管理所有节点 说到底，主要还是做为kafka的消费方，能感受到最大的不同还是在于几个： 吞吐量确实非常高 2.可以重读历史数据 但是也有一些缺点： 1

1.kafka架构 Kafka的整体架构非常简单，是显式分布式架构，producer、broker（kafka）和consumer都可以有多个。Producer，consumer实现Kafka注册的接口，数据从producer发送到broker，broker承担一个中间缓存和分发的作用。broker分发注册到系统中的consumer。broker的作用类似于缓存，即活跃的数据和离线处理系统之间的缓存。客户端和服务器端的通信，是基于简单，高性能，且与编程语言无关的TCP协议。几个基本概念： 1）Topic：特指Kafka处理的消息源（feeds of messages）的不同分类。 2）Partition：Topic物理上的分组，一个topic可以分为多个partition，每个partition是一个有序的队列。partition中的每条消息都会被分配一个有序的id（offset）。 3）Message：消息，是通信的基本单位，每个producer可以向一个topic（主题）发布一些消息。 4）Producers：消息和数据生产者，向Kafka的一个topic发布消息的过程叫做producers。 5）Consumers：消息和数据消费者，订阅topics并处理其发布的消息的过程叫做consumers。 6）Broker：缓存代理

Kafka是分布式发布-订阅消息系统。它最初由LinkedIn公司开发，之后成为Apache项目的一部分。Kafka是一个分布式的，可划分的，冗余备份的持久性的日志服务。它主要用于处理活跃的流式数据。 Kafka主要特点： 同时为发布和订阅提供高吞吐量。据了解，Kafka每秒可以生产约25万消息（50 MB），每秒处理55万消息（110 MB）。 可进行持久化操作。将消息持久化到磁盘，因此可用于批量消费，例如ETL，以及实时应用程序。通过将数据持久化到硬盘以及replication防止数据丢失。 分布式系统，易于向外扩展。所有的producer、broker和consumer都会有多个，均为分布式的。无需停机即可扩展机器。 消息被处理的状态是在consumer端维护，而不是由server端维护。当失败时能自动平衡。 支持online和offline的场景。 Kafka的架构： Kafka的整体架构非常简单，是显式分布式架构，producer、broker（kafka）和consumer都可以有多个。Producer，consumer实现Kafka注册的接口，数据从producer发送到broker，broker承担一个中间缓存和分发的作用。broker分发注册到系统中的consumer。broker的作用类似于缓存，即活跃的数据和离线处理系统之间的缓存。客户端和服务器端的通信

Shuffle过程是MapReduce的核心，也被称为奇迹发生的地方。要想理解MapReduce， Shuffle是必须要了解的。我看过很多相关的资料，但每次看完都云里雾里的绕着，很难理清大致的逻辑，反而越搅越混。前段时间在做MapReduce job 性能调优的工作，需要深入代码研究MapReduce的运行机制，这才对Shuffle探了个究竟。考虑到之前我在看相关资料而看不懂时很恼火，所以在这里我尽最大的可能试着把Shuffle说清楚，让每一位想了解它原理的朋友都能有所收获。如果你对这篇文章有任何疑问或建议请留言到后面，谢谢！ Shuffle的正常意思是洗牌或弄乱，可能大家更熟悉的是Java API里的Collections.shuffle(List)方法，它会随机地打乱参数list里的元素顺序。如果你不知道MapReduce里Shuffle是什么，那么请看这张图： 这张是官方对Shuffle过程的描述。但我可以肯定的是，单从这张图你基本不可能明白Shuffle的过程，因为它与事实相差挺多，细节也是错乱的。后面我会具体描述Shuffle的事实情况，所以这里你只要清楚Shuffle的大致范围就成－怎样把map task的输出结果有效地传送到reduce端。也可以这样理解， Shuffle描述着数据从map task输出到reduce task输入的这段过程。

与基于继承的分区(inheritance-based partitioning)不同，PostgreSQL 10中引入的声明式分区对数据如何划分没有任何影响。PostgreSQL 11的查询优化器正准备利用这种“无推理”表示。第一个提交的是partition-wise join。 什么是partition-wise join 如果连接表的分区键之间存在相等连接条件，那么两个类似分区表之间的连接可以分解为它们的匹配分区之间的连接。分区键之间的等连接意味着一个分区表的给定分区中给定行的所有连接伙伴必须在另一个分区表的相应分区中。因此，分区表之间的连接可以分解为匹配分区之间的连接。这种将分区表之间的连接分解为分区之间的连接的技术称为partition-wise join。 PostgreSQL中的partition-wise join 让我们从一个例子开始。考虑按如下方式分区的两个表: create table prt1 (a int, b int, c varchar) partition by range(a); create table prt1_p1 partition of prt1 for values from (0) to (5000); create table prt1_p2 partition of prt1 for values from (5000) to

原文： https://blog.csdn.net/xiaofei2017/article/details/80924800 #encoding=utf-8 ''' @author: sea ''' import threading import os import sys from kafka import KafkaConsumer, TopicPartition, OffsetAndMetadata from consumers.db_util import * from consumers.json_dispose import * from collections import OrderedDict threads = [] # col_dic, sql_dic = get() class MyThread(threading.Thread): def __init__(self, thread_name, topic, partition): threading.Thread.__init__(self) self.thread_name = thread_name # self.keyName = keyName self.partition = partition self.topic = topic def run(self): print("Starting