partition

对于磁盘的分区表 MBR与GPT区别。 MBR：MBR分区表(即主引导记录)大家都很熟悉，是过去我们使用windows时常用的。 所支持的最大卷：2T，而且对分区有限制：最多4个主分区或3个主分区加一个扩展分区 GPT： GPT（即GUID分区表）。是源自EFI标准的一种较新的磁盘分区表结构的标准，是未来磁盘分区的主要形式。与MBR分区方式相比，具有如下优点。 突破MBR 4个主分区限制，每个磁盘最多支持128个分区。支持大于2T的分区，最大卷可达18EB。 对于 GPT 的分区，建议使用 parted 工具进行分区，fdisk 在 GPT 这块不是很好。 Parted 介绍 Parted 命令分为两种模式：命令行模式和交互模式。 命令行模式 parted [option] device [command] ,该模式可以直接在命令行下对磁盘进行分区操作，比较适合编程应用。如： 显示磁盘/dev/sdb分区。 parted /dev/sdb print 交互模式 parted [option] device 进入交互模式。尤其是对 parted 命令不是很熟悉的情况下建议使用交互模式。 parted /dev/sdb parted命令常用选项 进入 交互模式下， 输入 help 可以看到如下提示，本文基于 Parted 3.2 进行说明。 test@test01:~$ sudo

1.什么是Druid？ Druid是一个高效的数据查询系统，主要解决的是对于大量的基于时序的数据进行聚合查询。数据可以实时摄入，进入到Druid后立即可查，同时数据是几乎是不可变。通常是基于时序的事实事件，事实发生后进入Druid，外部系统就可以对该事实进行查询。 shared-nothing架构与lambda架构 Druid设计三个原则: 1.快速查询（Fast Query） : 部分数据聚合（Partial Aggregate） + 内存华（In-Memory） + 索引（Index） 2.水平拓展能力（Horizontal Scalability）:分布式数据（Distributed data）+并行化查询（Parallelizable Query） 3.实时分析（Realtime Analytics）：Immutable Past , Append-Only Future 2.Druid的技术特点 数据吞吐量大 支持流式数据摄入和实时 查询灵活且快速 3.Druid基本概念： Druid在数据摄入之前，首先要定义一个数据源（DataSource,类似于数据库中表的概念） Druid是一个分布式数据分析平台,也是一个时序数据库 数据集合（时间列，维度列，指标列） 数据结构： 基于DataSource与Segment的数据结构，DataSource相当于关系型数据库中的表。

1、基本概念 需要了解producer,consumer,groupId,broker,topic,partition,segment的概念，如下图。 2、版本名 kafka_2.10-0.8.2.jar，2.10是指Scala版本，0.8.2是指kafka版本。 3、核心功能 Producer API允许程序发布数据流到一个到多个Kafka topic。 Consumer API允许程序订阅一个到多个topic，并且进行消费。 Streams API允许程序作为一个数据流处理，将一个或多个topic中输入的数据进行消费，并生产数据流到一个或多个topics中。 Connector API，可以通过Connector管理Kafka和另一个系统之间的数据复制，比如去捕获关系型数据库中的任意改变到一个表中。 4、topic介绍 topic（不同的业务数据，分流到不同的topic进行处理） kafka对与zookeeper是强依赖的，是以zookeeper作为基础的，即使不做集群，也需要zk的支持。以下是kafka中必须要填写的配置文件，id为在zk中注册的brokerid，后者为要注册到的zookeeper的host和port。 broker.id=0 zookeeper.connect=localhost:2181 zk说白了，就是一个节点服务系统，至于用这个节点做什么，做单活

Ŀ¼ 0. Ŀ¼ 0. Ŀ¼ 配置生产者客户端参数，创建生产者实例 构建待发送的消息 发送消息 关闭生产者 public class ProducerRecord < K , V > { private final String topic ; //必填项 private final Integer partition ; private final Headers headers ; private final K key ; private final V value ; //必填项 private final Long timestamp ; } key用来计算分区号，确定发送到指定分区 bootstrap.servers：指定kafka集群的broker的地址，默认为空，虽然可以从给定的broker找到其他broker，但是为防止某一节点宕机导致消息发送失败，建议填写至少2个broker地址。 key.serializer、value.serializer client.id：客户端ID，若不设置，会自动生成非空字符串。 设置技巧： 属性名不好记，可以使用 ProducerConfig 类中的常量。 发后即忘（fire-and-foget） 性能最高，可靠性最差 try { producer . send ( record ); } catch ( Exception e

两种方案： 方案二，producer将消息发送到指定partition分区 解析： 方案一：kafka默认保证同一个partition分区内的消息是有序的，则可以设置topic只使用一个分区，这样消息就是全局有序，缺点是只能被consumer group里的一个消费者消费，降低了性能，不适用高并发的情况 方案二：既然kafka默认保证同一个partition分区内的消息是有序的，则producer可以在发送消息时可以指定需要保证顺序的几条消息发送到同一个分区，这样消费者消费时，消息就是有序。 producer发送消息时具体到topic的哪一个partition分区，提供了三种方式 1）指定分区 2）不指定分区，有指定key 则根据key的hash值与分区数进行运算后确定发送到哪个partition分区 3）不指定分区，不指定key，则轮询各分区发送

fetch.min.bytes. #获取最小字节数据 Consumer 向broker中要数据时是按大小来返回的，如果数据没有达到指定的M数，consumer会处于等待状态，直到broker 从producer 哪里获取到指定大小的数据为止。获取取的最小数据大小是指的每个partition上的数据。 fetch.max.wait.ms 当consumer 一直在等待broker的数据达到最小字节数时，如果一直没有达到，consumer是不会一直处于block状态的，会根据fetch.max.wait.ms 设置的时间取结束block 状态。假如说设置fetch.min.bytes 的大小是1m,但是一直没有达到1m，但是到了fetch.max.wait.ms 设置的最大等待时间时会结束掉当前的block状态，有多少数据，获取多少数据。默认值是500ms. 通过这2个参数来控制客户端和服务端的通讯次数，而且还能进行批量作业。 max.partition.fetch.bytes 控制每1个partition最大的字节数。默认是1mb 假如1个topic中有20个partitions,有5个consumer读取partition上的数据，每个consumer只能读取到4M的concumer records. session.timeout.ms

测试目的： 1.分区表的动态分区与静态分区 2.每层数据，数据流向，数据是否在每层都保留一份 测试结果： 1.动态分区/静态分区略 2.每层表的数据都会保留，因此在生产上odm层的数据是可以删除的（不管是内表还是外表） 数据源： 1,jack,shanghai,20190129 2,kevin,beijing,20190130 3,lucas,hangzhou,20190129 4,lily,hangzhou,20190130 1. 创建数据库 create database TestFenQu; 2. 创建源数据表（外表） create external table TestFenQu.dept( id int, name string, address string, day string ) row format delimited fields terminated by ','; 加载数据： load data local inpath '/home/kong/test.dat' into table TestFenQu.dept; 3. 创建分区表1（外表） create external table TestFenQu.dept_part( id int, name string, address string )partitioned by(day string)

1：kafka可以通过多个broker形成集群，来存储大量数据；而且便于横向扩展。 2：kafka信息存储核心的broker，通过partition的segment只关心信息的存储，而生产者只负责向leader角色的partition提交数据，而消费者pull数据的时候自己通过zk存储offset信息，严格讲broker基本只关心存储数据； 3：kafka的ack策略也是提高吞吐量的手段： 　　1）生产者的acks如果设置0则只向leader发送数据，并不关心leader数据是否存储成功； 　　2）如果设置为1在向leader发送数据后需要等待leader存储成功后才会认为一次操作成功； 　　3）如果设置为-1在向leader发送数据后不但需要等待leader存储成功，还要等待各个follow角色的partition，从leader拉取数据后存储完成才算一次完整的ack，当然这种情况会降低kafka的吞吐量； ps:而且kafka底层是通过NIO顺序写数据，效率也是非常高的

Kafka * broker：server； topic：消息贴标签组成一类 分类的过程，同一类，方便处理，有了topic 就可以隔离其他类数据，他是一个逻辑概念； partiion:物理概念要落盘 不可更改只读，一个topic多个分区，一个分区一个目录， 一个分区代表一个文件夹 一个分区多个副本 放在不同的broker上； zk:broker的负载均衡，leader的选举，元数据存储，CG之间的rebalance，配置管理等； 2.kafka的partiton是一个先进先出队列，写入消息追加尾部，消费消息在队列头部； 3.kafka的CG内部的cosumer是互斥的，不同CG之间是共享消息的； 4.kafka最小数据存储单元是segment，它包含（offset.index offset.timeindex,offset.log）三个文件，offset 是消息在分区中的唯一标识，他是有序的。 offset.index数据格式：偏移量，位置； offset.timeindex数据格式：时间，偏移量； 5.kafka机制： 消息在broker中（server）按照topic分类，打上标签；然后 每个topic划分为多个partition，每个partition进行 多个备份副本；多个consumer组成CG 进行订阅消费数据 6.队列在资源调度的作用？ 答：共享集群资源，隔离任务 7

关于 Kafka Kafka 是最初由 Linkedin 公司开发，是一个分布式、支持分区的（partition）、多副本的（replica），基于 zookeeper 协调的分布式消息系统，它的最大的特性就是可以实时的处理大量数据以满足各种需求场景：比如 基于 hadoop 的批处理系统、低延迟的实时系统、storm/Spark 流式处理引擎，web/nginx 日志、访问日志，消息服务等等，用scala语言编写，Linkedin 于 2010 年贡献给了 Apache 基金会并成为顶级开源 项目。（ 以时间复杂度为 O(1) 的方式提供消息持久化能力，即使对 TB 级以上数据也能保证常数时间的访问性能。） Kafka 的特点 ①高吞吐量，低延迟： Kafka 每秒可以处理几十万条消息 延迟最多只有几毫秒 ②可扩展性： Kafka 集群支持热扩展（ 热扩展指不重启整个集群的前提下，向集群中添加新的节点 ） ③持久性，可靠性：消息被持久化到本地磁盘并且支持数据备份防止丢失 ④容错性：允许集群中的节点失败 ⑤高并发：支持数千个客户端同时读写 Kafka 使用场景 ①日志收集：一个公司使用 Kafka 收集各种服务的 log ②消息系统：解耦和生产者和消费者、缓存消息等。（解耦：在项目启动之初来预测将来项目会碰到什么需求，是极其困难的。消息系统在处理过程中间插入了一个隐含的