zookeeper的选举机制分为第一次启动和非第一次启动两种情况。

第一个就是controller的选举，这个选举是借助于zookeeper的独享锁实现的，先启动的broker会在zookeeper的/contoller节点上面增加一个broker信息，谁创建成功了谁就是主节点，其他的broker会启动watch监视器进行监听其中的数据变化，如果宕机了其他的节点会抢占这个节点选举为controller节点。这就是主分区宕机后的选举实现，但是选择的节点一般都是数据比

Explain呈现的执行计划，由一系列Stage组成，这一系列Stage具有依赖关系，

管理表意味着Hive会完全接管该表，包括元数据和HDFS中的数据。指定文件格式，常用的文件格式有，textfile（默认值），sequence file，orc file、parquet file等等。该语法允许用户利用select查询语句返回的结果，直接建表，表的结构和查询语句的结构保持一致，且保证包含select查询语句放回的内容。外部表通常可用于处理其他工具上传的数据文件，对于外部表，Hiv

注：Compaction的触发时机Major Compaction时间会持续比较长，整个过程会消耗大量系统资源，对上层业务有比较大的影响。通过CompactionChecker线程来定时检查是否需要执行compaction（RegionServer启动时在initializeThreads()中初始化），每隔10000毫秒（可配置）检查一次。是选取一些小的、相邻的StoreFile将他们合并成一个

工作的过程中我们会遇见数据分类的情况，想要根据自己的需求定义分区的规则，让符合规则的数据发送到不同的分区中，这个时候我们就需要自定义分区器了。定义分区器，让数据发送到不同的分区，从而不同的task任务输出的文件结果内容也不同# 自己创建数据data/a.txt# 需求就是将数据按照规则进行分发到不同的分区中# 存储的时候一个文件存储hello其他的文件存储tom jack分区器的定义需要实现分区器

对于executor端，driver端的变量是外部变量。excutor端修改了变量count，根本不会让driver端跟着修改。

shuffle是一个涉及到CPU（序列化反序列化）、网络IO（跨节点数据传输）以及磁盘IO（shuffle中间结果落盘）的操作。spark.reducer.maxSizeInFlight：reduce task的拉取缓存，默认48m。spark.shuffle.file.buffer：map task的写磁盘缓存，默认32k。spark.shuffle.io.maxRetries：拉取失败的最大重

zookeeper可以实现controller的选举，并且记录topic和partition的元数据信息，帮助多个broker同步数据信息。首先要设定process.roles，可以人为指定每个人的角色，如果指定broker那么它永远是broker。在新版本中的kraft模式中可以这个管理和选举可以用kafka自己完成，而不再依赖zookeeper。一般一个集群中会设定大部分是broker，少量的

hbase:meta表有: region_p在。