Onepager

• 大数据组件
  • HDFS
    • HDFS组件结构 | Client(切分file,交互), NN(namespace, block映射，读写请求), DN(存储，心跳), SNN(aux Fsimage&editslog), HA(主备，ZK), QJM(共享存储存Editlog, Paxos一致性协议)
    • 发散 | NNProxy, 跨NN, HDFS租约
    • HDFS 读写流程
      • 写 | client(DFS/FSDataOutputStream)，NN(鉴权、目录)，file-blcok粒度请求地址，dn多副本pipeline, pipline正向block-packet粒度发送，反向ack应答队列
      • 读 | block粒度并行读取，距离近+状态非STALE优先，每个块都会做Checksum校验
      • 发散 | 读写过程Datanode宕机、坏块、丢块等
    • 小文件 | NN内存，HDFS Compact压力， Spark读取Task过多
  • YARN
    • YARN 组织结构 | 组成(RM/NM(AM,Container))，调度器(FIFO, Capacity, Fair)
  • Hive
  • Hive
    • 常见的压缩算法 | 压缩率高-低： zstd > LZ4 > GZIP > Snappy 压缩解压吞吐量：LZ4 > Snappy > zstd 和 GZIP
    • 常见的列式存储及特点 | Parquet：嵌套结构支持, 查询和压缩性能稍逊orc. ORC：更好的查询性能和压缩比，复杂结构支持较弱
  • Hbase
  • Spark
    • SparkOnYarn运行机制 | RM - NM(container(AM(sc, dagscheduler, taskshdueler))) AM-RM-NM-Container(CoarseGrainedExecutorBackend)
    • DAG | RDD宽窄依赖，transform, action， checkpoint vs 持久化, lineage
    • Spark Vs MR | MR: 多进程单线程，Task进程级别隔离，单线程资源控制稳定。Spark 多进程多线程；内存密集型，迭代运算；RDD血缘容错；同一个executerJVM中共享内存和资源，资源控制上不容易控制。
    • Spark 内存模型 | node manager 管理的内存 = executor.memoryOverhead + executor.memory(onheap, unified mem: storage+execution+other+reserved)
    • Spark 内存模型 | node manager 管理的内存 = executor.memoryOverhead + executor.memory(onheap, unified mem: storage+execution+other+reserved)
    • Spark 参数调优 | driver(am, mem, core, resultsize), executor(num, mem, core, dynamic), AE, speculation, hdfs shuffle, file compact, compression
    • Spark 参数调优 | driver(am, mem, core, resultsize), executor(num, mem, core, dynamic), AE, speculation, hdfs shuffle, file compact, compression
    • Spark Join | BroadcastHashJoin, ShuffleHashJoin, ShffuleSortMergeJoin, Catersian Join, BroadcastNestLoopJoin
  • MR
    • MR读写流程 | Map(split,hashpartition,circular-buffer,sort-combiner-spill,merge), Reduce(copy, buffer+disk merge, reduce)
    • 发散 | map merege: 一个map任务产生的多个spill文件进行归并生成最终的一个已分区且已排序的大文件, map done - notify AM/JobTracker - Reducer fetch own partition
  • Kafka
  • Kafka
    • what is kafka? and components? |
    • kafka producer ack 机制 | todo
    • kafka file | 顺序写入，逻辑日志文件分段（每段一个文件，多个消息offset）, 稀疏索引+二分查找
    • 顺序性 | produce, consume todoss
    • 顺序性 | produce, consume todoss
    • 如何保证数据不丢 | producer: ack=1/-1, consumer: 通过topic里记录的offset， broker: replication
    • Kafka消息数据积压，Kafka消费能力不足怎么处理？
    • Kafka消息数据积压，Kafka消费能力不足怎么处理？
    • atleat/most/exactly once
  • MQ
    • 消息队列特点 | 解耦，冗余，异步，流量薛峰天谷，扩展
  • Flink
  • Flink
  • ClickHouse
  • Redis
  • Memcache
  • 其他
    • ES
    • Presto
    • RockMQ
    • Abase
  • SQL
    • 常用的HiveSQL/SparkSQL内建函数 | fromunixtime, unixtimestamp, datediff, datesub, dateadd
    • 常见SQL题目 |
• 数仓
  • 什么是数仓 | 数据仓库是一个面向主题的、集成的、相对稳定的、反映历史变化的数据集合，沉淀数据资产，用于支持数据分析、推荐和管理决策。
  • 维度建模
    • 事实表
    • 维度表
    • 拉链表
  • 原子指标/衍生指标 | todo guowen
  • 分层和规范 | 为何分层：1. 统一数据标准和口径 2. 抽象加工逻辑，公共部分提取和复用，减少重复计算和存储 3.数据标准处理，屏蔽底层，便于使用
  • 数仓从0到1的过程 | 调研（业务、需求和数据），主题域，维度建模，QA, DM门户，数据治理
  • 数据治理 | todo mobile phone
    • 计算治理
    • 存储治理
    • 任务治理
• 大数据理论
  • CAP
  • 分布式一致性协议 | todo blog
    • 2 PC
    • 3 PC
    • Paxos
    • ZBS
  • 拓扑结构
    • Master/Slave
    • Primary/Backup
    • ReplicaSet
• Java | todo blog
  • Collections
    • HashMap/HashTable/ConcurrentHashMap
    • List/Map
• JVM
  • JVM内存结构
    • GC
  • #
  • JVM内存模型
    • HappensBefore
• OS
  • 用户空间/内核空间
  • 零拷贝
  • 进程/线程
• HTTP/TCP
  • 三次握手，四次挥手
  • 长短链接
• Security
  • 加密

前言
大数据面试常见知识体系。
掌握重要的、高频的知识点，理解透彻，能够发散。80%。
熟悉已用的、在用的，和流行的。15%。
了解底层的、冷门的。5%。

大数据组件 HDFS HDFS组件结构 | Client(切分file,交互), NN(namespace, block映射，读写请求), DN(存储，心跳), SNN(aux Fsimage&editslog), HA(主备，ZK), QJM(共享存储存Editlog, Paxos一致性协议) 发散 | NNProxy, 跨NN, HDFS租约

9. 请说下HDFS的组织架构
1）Client：客户端
（1）切分文件。文件上传HDFS的时候，Client将文件切分成一个一个的Block，然后进行存储
（2）与NameNode交互，获取文件的位置信息
（3）与DataNode交互，读取或者写入数据
（4）Client提供一些命令来管理HDFS，比如启动关闭HDFS、访问HDFS目录及内容等
2）NameNode：名称节点，也称主节点，存储数据的元数据信息，不存储具体的数据
（1）管理HDFS的名称空间
（2）管理数据块（Block）映射信息
（3）配置副本策略
（4）处理客户端读写请求
3）DataNode：数据节点，也称从节点。NameNode下达命令，DataNode执行实际的操作
（1）存储实际的数据块
（2）执行数据块的读/写操作
4）Secondary NameNode：并非NameNode的热备。当NameNode挂掉的时候，它并不能马上替换NameNode并提供服务
（1）辅助NameNode，分担其工作量
（2）定期合并Fsimage和Edits，并推送给NameNode
（3）在紧急情况下，可辅助恢复NameNode

4. NameNode在启动的时候会做哪些操作
NameNode数据存储在内存和本地磁盘，本地磁盘数据存储在fsimage镜像文件和edits编辑日志文件

首次启动NameNode
1、格式化文件系统，为了生成fsimage镜像文件
2、启动NameNode
（1）读取fsimage文件，将文件内容加载进内存
（2）等待DataNade注册与发送block report
3、启动DataNode
（1）向NameNode注册
（2）发送block report
（3）检查fsimage中记录的块的数量和block report中的块的总数是否相同
4、对文件系统进行操作（创建目录，上传文件，删除文件等）
（1）此时内存中已经有文件系统改变的信息，但是磁盘中没有文件系统改变的信息，此时会将这些改变信息写入edits文件中，edits文件中存储的是文件系统元数据改变的信息。
第二次启动NameNode
1、读取fsimage和edits文件
2、将fsimage和edits文件合并成新的fsimage文件
3、创建新的edits文件，内容为空
4、启动DataNode
5. Secondary NameNode了解吗，它的工作机制是怎样的
Secondary NameNode 是合并NameNode的edit logs到fsimage文件中；

它的具体工作机制：
（1）Secondary NameNode询问NameNode是否需要checkpoint。直接带回NameNode是否检查结果
（2）Secondary NameNode请求执行checkpoint
（3）NameNode滚动正在写的edits日志
（4）将滚动前的编辑日志和镜像文件拷贝到Secondary NameNode
（5）Secondary NameNode加载编辑日志和镜像文件到内存，并合并
（6）生成新的镜像文件fsimage.chkpoint
（7）拷贝fsimage.chkpoint到NameNode
（8）NameNode将fsimage.chkpoint重新命名成fsimage
所以如果NameNode中的元数据丢失，是可以从Secondary NameNode恢复一部分元数据信息的，但不是全部，因为NameNode正在写的edits日志还没有拷贝到Secondary NameNode，这部分恢复不了

6. Secondary NameNode不能恢复NameNode的全部数据，那如何保证NameNode数据存储安全
这个问题就要说NameNode的高可用了，即 NameNode HA
一个NameNode有单点故障的问题，那就配置双NameNode，配置有两个关键点，一是必须要保证这两个NN的元数据信息必须要同步的，二是一个NN挂掉之后另一个要立马补上。

元数据信息同步在 HA 方案中采用的是“共享存储”。每次写文件时，需要将日志同步写入共享存储，这个步骤成功才能认定写文件成功。然后备份节点定期从共享存储同步日志，以便进行主备切换。
监控NN状态采用 zookeeper，两个NN节点的状态存放在ZK中，另外两个NN节点分别有一个进程监控程序，实施读取ZK中有NN的状态，来判断当前的NN是不是已经down机。如果standby的NN节点的ZKFC发现主节点已经挂掉，那么就会强制给原本的active NN节点发送强制关闭请求，之后将备用的NN设置为active。
> 如果面试官再问HA中的 共享存储 是怎么实现的知道吗？
    可以进行解释下：NameNode 共享存储方案有很多，比如 Linux HA, VMware FT, QJM等，目前社区已经把由 Clouderea 公司实现的基于 QJM（Quorum Journal Manager）的方案合并到 HDFS 的 trunk 之中并且作为默认的共享存储实现
    基于 QJM 的共享存储系统主要用于保存 EditLog，并不保存 FSImage 文件。FSImage 文件还是在 NameNode 的本地磁盘上。QJM 共享存储的基本思想来自于 Paxos 算法，采用多个称为 JournalNode 的节点组成的 JournalNode 集群来存储 EditLog。每个 JournalNode 保存同样的 EditLog 副本。每次 NameNode 写 EditLog 的时候，除了向本地磁盘写入 EditLog 之外，也会并行地向 JournalNode 集群之中的每一个 JournalNode 发送写请求，只要大多数 (majority) 的 JournalNode 节点返回成功就认为向 JournalNode 集群写入 EditLog 成功。如果有 2N+1 台 JournalNode，那么根据大多数的原则，最多可以容忍有 N 台 JournalNode 节点挂掉

7. 在NameNode HA中，会出现脑裂问题吗？怎么解决脑裂
假设 NameNode1 当前为 Active 状态，NameNode2 当前为 Standby 状态。如果某一时刻 NameNode1 对应的 ZKFailoverController 进程发生了“假死”现象，那么 Zookeeper 服务端会认为 NameNode1 挂掉了，根据前面的主备切换逻辑，NameNode2 会替代 NameNode1 进入 Active 状态。但是此时 NameNode1 可能仍然处于 Active 状态正常运行，这样 NameNode1 和 NameNode2 都处于 Active 状态，都可以对外提供服务。这种情况称为脑裂

脑裂对于NameNode 这类对数据一致性要求非常高的系统来说是灾难性的，数据会发生错乱且无法恢复。Zookeeper 社区对这种问题的解决方法叫做 fencing，中文翻译为隔离，也就是想办法把旧的 Active NameNode 隔离起来，使它不能正常对外提供服务。

在进行 fencing 的时候，会执行以下的操作：

首先尝试调用这个旧 Active NameNode 的 HAServiceProtocol RPC 接口的 transitionToStandby 方法，看能不能把它转换为 Standby 状态。
如果 transitionToStandby 方法调用失败，那么就执行 Hadoop 配置文件之中预定义的隔离措施，Hadoop 目前主要提供两种隔离措施，通常会选择 sshfence：
(1) sshfence：通过 SSH 登录到目标机器上，执行命令 fuser 将对应的进程杀死
(2) shellfence：执行一个用户自定义的 shell 脚本来将对应的进程隔离
————————————————
版权声明：本文为CSDN博主「五分钟学大数据」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/helloHbulie/article/details/113555820

HDFS 读写流程 写 | client(DFS/FSDataOutputStream)，NN(鉴权、目录)，file-blcok粒度请求地址，dn多副本pipeline, pipline正向block-packet粒度发送，反向ack应答队列 读 | block粒度并行读取，距离近+状态非STALE优先，每个块都会做Checksum校验 发散 | 读写过程Datanode宕机、坏块、丢块等

HDFS写流程

1）client客户端发送上传请求，通过RPC与namenode建立通信，namenode检查该用户是否有上传权限，以及上传的文件是否在hdfs对应的目录下重名，如果这两者有任意一个不满足，则直接报错，如果两者都满足，则返回给客户端一个可以上传的信息

2）client根据文件的大小进行切分，默认128M一块，切分完成之后给namenode发送请求第一个block块上传到哪些服务器上

3）namenode收到请求之后，根据网络拓扑和机架感知以及副本机制进行文件分配，返回可用的DataNode的地址

注：Hadoop 在设计时考虑到数据的安全与高效, 数据文件默认在 HDFS 上存放三份, 存储策略为本地一份，同机架内其它某一节点上一份, 不同机架的某一节点上一份
4）客户端收到地址之后与服务器地址列表中的一个节点如A进行通信，本质上就是RPC调用，建立pipeline，A收到请求后会继续调用B，B在调用C，将整个pipeline建立完成，逐级返回client

5）client开始向A上发送第一个block（先从磁盘读取数据然后放到本地内存缓存），以packet（数据包，64kb）为单位，A收到一个packet就会发送给B，然后B发送给C，A每传完一个packet就会放入一个应答队列等待应答

6）数据被分割成一个个的packet数据包在pipeline上依次传输，在pipeline反向传输中，逐个发送ack（命令正确应答），最终由pipeline 中第一个 DataNode 节点 A 将 pipelineack 发送给 Client

7）当一个 block 传输完成之后, Client 再次请求 NameNode 上传第二个 block ，namenode重新选择三台DataNode给client

HDFS读流程

1）client向namenode发送RPC请求。请求文件block的位置

2）namenode收到请求之后会检查用户权限以及是否有这个文件，如果都符合，则会视情况返回部分或全部的block列表，对于每个block，NameNode 都会返回含有该 block 副本的 DataNode 地址； 这些返回的 DN 地址，会按照集群拓扑结构得出 DataNode 与客户端的距离，然后进行排序，排序两个规则：网络拓扑结构中距离 Client 近的排靠前；心跳机制中超时汇报的 DN 状态为 STALE，这样的排靠后

3）Client 选取排序靠前的 DataNode 来读取 block，如果客户端本身就是DataNode,那么将从本地直接获取数据(短路读取特性)

4）底层上本质是建立 Socket Stream（FSDataInputStream），重复的调用父类 DataInputStream 的 read 方法，直到这个块上的数据读取完毕

5）当读完列表的 block 后，若文件读取还没有结束，客户端会继续向NameNode 获取下一批的 block 列表

6）读取完一个 block 都会进行 checksum 验证，如果读取 DataNode 时出现错误，客户端会通知 NameNode，然后再从下一个拥有该 block 副本的DataNode 继续读

7）read 方法是并行的读取 block 信息，不是一块一块的读取；NameNode 只是返回Client请求包含块的DataNode地址，并不是返回请求块的数据

8） 最终读取来所有的 block 会合并成一个完整的最终文件
————————————————
版权声明：本文为CSDN博主「五分钟学大数据」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/helloHbulie/article/details/113555820

小文件 | NN内存，HDFS Compact压力， Spark读取Task过多 YARN YARN 组织结构 | 组成(RM/NM(AM,Container))，调度器(FIFO, Capacity, Fair)

15. yarn 集群的架构和工作原理知道多少
YARN的基本设计思想是将MapReduce V1中的JobTracker拆分为两个独立的服务：ResourceManager和ApplicationMaster。ResourceManager负责整个系统的资源管理和分配，ApplicationMaster负责单个应用程序的的管理。

ResourceManager：
RM是一个全局的资源管理器，负责整个系统的资源管理和分配，它主要由两个部分组成：调度器（Scheduler）和应用程序管理器（Application Manager）。
调度器根据容量、队列等限制条件，将系统中的资源分配给正在运行的应用程序，在保证容量、公平性和服务等级的前提下，优化集群资源利用率，让所有的资源都被充分利用应用程序管理器负责管理整个系统中的所有的应用程序，包括应用程序的提交、与调度器协商资源以启动ApplicationMaster、监控ApplicationMaster运行状态并在失败时重启它。

ApplicationMaster：
用户提交的一个应用程序会对应于一个ApplicationMaster，它的主要功能有：
a.与RM调度器协商以获得资源，资源以Container表示。
b.将得到的任务进一步分配给内部的任务。
c.与NM通信以启动/停止任务。
d.监控所有的内部任务状态，并在任务运行失败的时候重新为任务申请资源以重启任务。

nodeManager：
NodeManager是每个节点上的资源和任务管理器，一方面，它会定期地向RM汇报本节点上的资源使用情况和各个Container的运行状态；另一方面，他接收并处理来自AM的Container启动和停止请求。

container：
Container是YARN中的资源抽象，封装了各种资源。一个应用程序会分配一个Container，这个应用程序只能使用这个Container中描述的资源。
不同于MapReduceV1中槽位slot的资源封装，Container是一个动态资源的划分单位，更能充分利用资源。

16. yarn 的任务提交流程是怎样的
当jobclient向YARN提交一个应用程序后，YARN将分两个阶段运行这个应用程序：一是启动ApplicationMaster;第二个阶段是由ApplicationMaster创建应用程序，为它申请资源，监控运行直到结束。
具体步骤如下:

用户向YARN提交一个应用程序，并指定ApplicationMaster程序、启动ApplicationMaster的命令、用户程序。
RM为这个应用程序分配第一个Container，并与之对应的NM通讯，要求它在这个Container中启动应用程序ApplicationMaster。
ApplicationMaster向RM注册，然后拆分为内部各个子任务，为各个内部任务申请资源，并监控这些任务的运行，直到结束。
AM采用轮询的方式向RM申请和领取资源。
RM为AM分配资源，以Container形式返回
AM申请到资源后，便与之对应的NM通讯，要求NM启动任务。
NodeManager为任务设置好运行环境，将任务启动命令写到一个脚本中，并通过运行这个脚本启动任务
各个任务向AM汇报自己的状态和进度，以便当任务失败时可以重启任务。
应用程序完成后，ApplicationMaster向ResourceManager注销并关闭自己
17. yarn 的资源调度三种模型了解吗
在Yarn中有三种调度器可以选择：FIFO Scheduler ，Capacity Scheduler，Fair Scheduler

apache版本的hadoop默认使用的是capacity scheduler调度方式。CDH版本的默认使用的是fair scheduler调度方式

FIFO Scheduler（先来先服务）：

FIFO Scheduler把应用按提交的顺序排成一个队列，这是一个先进先出队列，在进行资源分配的时候，先给队列中最头上的应用进行分配资源，待最头上的应用需求满足后再给下一个分配，以此类推。

FIFO Scheduler是最简单也是最容易理解的调度器，也不需要任何配置，但它并不适用于共享集群。大的应用可能会占用所有集群资源，这就导致其它应用被阻塞，比如有个大任务在执行，占用了全部的资源，再提交一个小任务，则此小任务会一直被阻塞。

Capacity Scheduler（能力调度器）：

对于Capacity调度器，有一个专门的队列用来运行小任务，但是为小任务专门设置一个队列会预先占用一定的集群资源，这就导致大任务的执行时间会落后于使用FIFO调度器时的时间。

Fair Scheduler（公平调度器）：

在Fair调度器中，我们不需要预先占用一定的系统资源，Fair调度器会为所有运行的job动态的调整系统资源。

比如：当第一个大job提交时，只有这一个job在运行，此时它获得了所有集群资源；当第二个小任务提交后，Fair调度器会分配一半资源给这个小任务，让这两个任务公平的共享集群资源。

需要注意的是，在Fair调度器中，从第二个任务提交到获得资源会有一定的延迟，因为它需要等待第一个任务释放占用的Container。小任务执行完成之后也会释放自己占用的资源，大任务又获得了全部的系统资源。最终的效果就是Fair调度器即得到了高的资源利用率又能保证小任务及时完成。
————————————————
版权声明：本文为CSDN博主「五分钟学大数据」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/helloHbulie/article/details/113555820

Hive 常见的压缩算法 | 压缩率高-低： zstd > LZ4 > GZIP > Snappy 压缩解压吞吐量：LZ4 > Snappy > zstd 和 GZIP

压缩率高-低： zstd > LZ4 > GZIP > Snappy
压缩时间：LZ4 > Snappy > zstd 和 GZIP
REF https://tech.meituan.com/2021/01/07/pack-gzip-zstd-lz4.html

常见的列式存储及特点 | Parquet：嵌套结构支持, 查询和压缩性能稍逊orc. ORC：更好的查询性能和压缩比，复杂结构支持较弱

4. ORC、Parquet等列式存储的优点
ORC和Parquet都是高性能的存储方式，这两种存储格式总会带来存储和性能上的提升

Parquet:
Parquet支持嵌套的数据模型，类似于Protocol Buffers，每一个数据模型的schema包含多个字段，每一个字段有三个属性：重复次数、数据类型和字段名。
重复次数可以是以下三种：required(只出现1次)，repeated(出现0次或多次)，optional(出现0次或1次)。每一个字段的数据类型可以分成两种：
group(复杂类型)和primitive(基本类型)。

Parquet中没有Map、Array这样的复杂数据结构，但是可以通过repeated和group组合来实现的。

由于Parquet支持的数据模型比较松散，可能一条记录中存在比较深的嵌套关系，如果为每一条记录都维护一个类似的树状结可能会占用较大的存储空间，因此Dremel论文中提出了一种高效的对于嵌套数据格式的压缩算法：Striping/Assembly算法。通过Striping/Assembly算法，parquet可以使用较少的存储空间表示复杂的嵌套格式，并且通常Repetition level和Definition level都是较小的整数值，可以通过RLE算法对其进行压缩，进一步降低存储空间。

Parquet文件是以二进制方式存储的，是不可以直接读取和修改的，Parquet文件是自解析的，文件
中包括该文件的数据和元数据。

ORC:
ORC文件是自描述的，它的元数据使用Protocol Buffers序列化，并且文件中的数据尽可能的压缩以降低存储空间的消耗。

和Parquet类似，ORC文件也是以二进制方式存储的，所以是不可以直接读取，ORC文件也是自解析的，它包含许多的元数据，这些元数据都是同构ProtoBuffer进行序列化的。

ORC会尽可能合并多个离散的区间尽可能的减少I/O次数。

ORC中使用了更加精确的索引信息，使得在读取数据时可以指定从任意一行开始读取，更细粒度的统计信息使得读取ORC文件跳过整个row group，ORC默认会对任何一块数据和索引信息使用ZLIB压缩，因此ORC文件占用的存储空间也更小。

在新版本的ORC中也加入了对Bloom Filter的支持，它可以进一
步提升谓词下推的效率，在Hive 1.2.0版本以后也加入了对此的支
持。
————————————————
版权声明：本文为CSDN博主「五分钟学大数据」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/helloHbulie/article/details/113555820

Hbase Spark SparkOnYarn运行机制 | RM - NM(container(AM(sc, dagscheduler, taskshdueler))) AM-RM-NM-Container(CoarseGrainedExecutorBackend)

REF https://blog.csdn.net/fzlulee/article/details/100171561?spm=1001.2014.3001.5502
Spark yarn-cluster mode:
1. Spark Yarn Client向YARN中提交应用程序，包括ApplicationMaster程序、启动ApplicationMaster的命令、需要在Executor中运行的程序等
2. ResourceManager收到请求后，在集群中选择一个NodeManager，为该应用程序分配第一个Container，要求它在这个Container中启动应用程序的ApplicationMaster，其中ApplicationMaster进行SparkContext等的初始化
3. ApplicationMaster向ResourceManager注册，这样用户可以直接通过ResourceManage查看应用程序的运行状态，然后它将采用轮询的方式通过RPC协议为各个任务申请资源，并监控它们的运行状态直到运行结束
4. 一旦ApplicationMaster申请到资源（也就是Container）后，便与对应的NodeManager通信，要求它在获得的Container中启动CoarseGrainedExecutorBackend，CoarseGrainedExecutorBackend启动后会向ApplicationMaster中的SparkContext注册并申请Task。这一点和Standalone模式一样，只不过SparkContext在Spark Application中初始化时，使用CoarseGrainedSchedulerBackend配合YarnClusterScheduler进行任务的调度，其中YarnClusterScheduler只是对TaskSchedulerImpl的一个简单包装，增加了对Executor的等待逻辑等
5. ApplicationMaster中的SparkContext分配Task给CoarseGrainedExecutorBackend执行，CoarseGrainedExecutorBackend运行Task并向ApplicationMaster汇报运行的状态和进度，以让ApplicationMaster随时掌握各个任务的运行状态，从而可以在任务失败时重新启动任务
6. 应用程序运行完成后，ApplicationMaster向ResourceManager申请注销并关闭自己
————————————————
版权声明：本文为CSDN博主「HanseyLee」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/fzlulee/article/details/100171561


Spark Client 和 Spark Cluster的区别:
理解YARN-Client和YARN-Cluster深层次的区别之前先清楚一个概念：Application Master。在YARN中，每个Application实例都有一个ApplicationMaster进程，它是Application启动的第一个容器。它负责和ResourceManager打交道并请求资源，获取资源之后告诉NodeManager为其启动Container。从深层次的含义讲YARN-Cluster和YARN-Client模式的区别其实就是ApplicationMaster进程的区别
YARN-Cluster模式下，Driver运行在AM(Application Master)中，它负责向YARN申请资源，并监督作业的运行状况。当用户提交了作业之后，就可以关掉Client，作业会继续在YARN上运行，因而YARN-Cluster模式不适合运行交互类型的作业.
YARN-Client模式下，Application Master仅仅向YARN请求Executor，Client会和请求的Container通信来调度他们工作，也就是说Client不能离开
————————————————
版权声明：本文为CSDN博主「HanseyLee」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/fzlulee/article/details/100171561

DAG | RDD宽窄依赖，transform, action， checkpoint vs 持久化, lineage

RDD
本质： Immutable的弹性可伸缩分布式对象集合(Resilient Distributed DataSet)，可以分成多个区，每个分区为一个数据集片段，不同分区可以保存在集群不同节点上。Spark 计算操作的基本数据结构。
RDD的分区，是指Spark在计算过程中生成的数据在计算空间内最小单元，同一份数据（RDD）的partition 大小不一，数量不定，是根据application里的算子和最初读入的数据分块数量决定的，这也是为什么叫“弹性分布式”数据集的原因之一。

transform and action
两类操作：
转换 Transformation： RDD -> RDD 惰性操作，延迟计算，粗粒度操作，反映RDD之间的相互依赖关系
map, flatMap, filter, groupByKey, reduceByKey, union, join, …
行动 Action：RDD -> 输出结果， 立即计算
reduce, count, collect, foreach, saveAs…

Job 作业，DAG解析时遇到Action操作即分隔为job.
Stage 阶段或任务的集合， 1 job = n stage, 1 stage = m tasks.
DAG中进行反向解析，遇到宽依赖就断开，切分成stage，遇到窄依赖就把当前的RDD加入到当前的stage中；将窄依赖尽量划分在同一个stage中，可以实现流水线计算.
Task 任务
————————————————
版权声明：本文为CSDN博主「HanseyLee」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/fzlulee/article/details/100171587


宽窄依赖
如果父RDD的一个Partition被一个子RDD的Partition所使用就是窄依赖，否则的话就是宽依赖。如果父RDD的一个Partitio被多个下游子RDD依赖，即一般需要Partitioner shuffle数据， 父分区数据经过shuffle过程的hash分区器（也可自定义分区器）划分到子RDD。例如GroupByKey，reduceByKey，join，sortByKey等操作。


checkpoint vs 持久化
最主要的区别在于持久化只是将数据保存在BlockManager中，但是RDD的lineage(血缘关系，依赖关系)是不变的。但是checkpoint执行完之后，rdd已经没有之前所谓的依赖rdd了，而只有一个强行为其设置的checkpointRDD，checkpoint之后rdd的lineage就改变了。

持久化的数据丢失的可能性更大，因为节点的故障会导致磁盘、内存的数据丢失。但是checkpoint的数据通常是保存在高可用的文件系统中，比如HDFS中，所以数据丢失可能性比较低


————————————————
版权声明：本文为CSDN博主「五分钟学大数据」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/helloHbulie/article/details/113555820

Spark Vs MR | MR: 多进程单线程，Task进程级别隔离，单线程资源控制稳定。Spark 多进程多线程；内存密集型，迭代运算；RDD血缘容错；同一个executerJVM中共享内存和资源，资源控制上不容易控制。

MR:
优点：稳定，mr是多进程单线程模型，任务是进程级别的隔离，进程内单线程资源控制上更好。
缺点：MR的map/reduce任务是隔离的进程，启动时间较长。
mr应用程序由多个独立的Task进程组成，每个task相互独立，申请资源和申请数据，再到计算完成结果存储都是独立进行的；

spark on yarn:
优势：内存密集型、低延迟的任务；另外RDD可以cache到内存，中间数据不像MR那样必须落磁盘，迭代计算效率更高。通过弹性分布式数据集（分布式只读的对象集合）和宽窄依赖的血缘关系，checkpoint机制等，容错性更高。
缺点：节点中的多线程会存在资源争抢的现象，难以细粒度的控制每个任务所应用的资源，在资源控制上自然mr的单线程做的更好，毕竟它不存在争抢和控制。

 每个worker node有node manager, 对应机器上可能启动多个executor. 每个executor会启动一个jvm实例进程。spark.executor.cores 控制一个executor可以使用多少core，这里的core是线程的粒度。spark.vcore.boost.ratio 控制一个core可以执行多少task。这两个参数可以让jvm充分利用多核并发的优势，而且一个进程获取的数据可以被多个任务重复利用，适用于内存密集型、低延迟的任务。
 spark是多进程多线程模型。Spark应用程序的运行环境是由多个独立的executer进程构建的临时资源池构成的，而每个executer又分为多个task进程，而且同一个executerJVM中共享内存和资源，大大提高了数据和资源的利用率，节省了大量的频繁申请资源，调用数据所浪费的性能。

Spark 内存模型 | node manager 管理的内存 = executor.memoryOverhead + executor.memory(onheap, unified mem: storage+execution+other+reserved)

同一个node上一个NM,可能多个Container(Executor JVM)
node manager 管理的内存 = executor.memoryOverhead + executor.memory(onheap, unified mem: storage+execution+other+reserved)

REF https://blog.cloudera.com/how-to-tune-your-apache-spark-jobs-part-2/

Spark 参数调优 | driver(am, mem, core, resultsize), executor(num, mem, core, dynamic), AE, speculation, hdfs shuffle, file compact, compression

REF http://spark.apache.org/docs/2.3.0/configuration.html

AE: http://www.jasongj.com/spark/adaptive_execution/
本文介绍的 Adaptive Execution 将可以根据执行过程中的中间数据优化后续执行，从而提高整体执行效率。核心在于两点
1.执行计划可动态调整. 2.调整的依据是中间结果的精确统计信息

原Spark SQL 时，可通过 spark.sql.shuffle.partitions 指定 Shuffle 时 Partition 个数，也即 Reducer 个数. 该参数决定了一个 Spark SQL Job 中包含的所有 Shuffle 的 Partition 个数。
这种方法有如下问题

- Partition 个数不宜设置过大
Reducer（代指 Spark Shuffle 过程中执行 Shuffle Read 的 Task） 个数过多，每个 Reducer 处理的数据量过小。大量小 Task 造成不必要的 Task 调度开销与可能的资源调度开销（如果开启了 Dynamic Allocation）
Reducer 个数过大，如果 Reducer 直接写 HDFS 会生成大量小文件，从而造成大量 addBlock RPC，Name node 可能成为瓶颈，并影响其它使用 HDFS 的应用
过多 Reducer 写小文件，会造成后面读取这些小文件时产生大量 getBlock RPC，对 Name node 产生冲击
- Partition 个数不宜设置过小
每个 Reducer 处理的数据量太大，Spill 到磁盘开销增大
Reducer GC 时间增长
Reducer 如果写 HDFS，每个 Reducer 写入数据量较大，无法充分发挥并行处理优势
- 很难保证所有 Shuffle 都最优
不同的 Shuffle 对应的数据量不一样，因此最优的 Partition 个数也不一样。使用统一的 Partition 个数很难保证所有 Shuffle 都最优
定时任务不同时段数据量不一样，相同的 Partition 数设置无法保证所有时间段执行时都最优

Spark Join | BroadcastHashJoin, ShuffleHashJoin, ShffuleSortMergeJoin, Catersian Join, BroadcastNestLoopJoin

REF https://jiamaoxiang.top/2020/11/01/Spark%E7%9A%84%E4%BA%94%E7%A7%8DJOIN%E6%96%B9%E5%BC%8F%E8%A7%A3%E6%9E%90/
https://zhuanlan.zhihu.com/p/348333141

MR MR读写流程 | Map(split,hashpartition,circular-buffer,sort-combiner-spill,merge), Reduce(copy, buffer+disk merge, reduce) 发散 | map merege: 一个map任务产生的多个spill文件进行归并生成最终的一个已分区且已排序的大文件, map done - notify AM/JobTracker - Reducer fetch own partition

10. 请说下MR中Map Task的工作机制
简单概述：
inputFile通过split被切割为多个split文件，通过Record按行读取内容给map（自己写的处理逻辑的方法）
，数据被map处理完之后交给OutputCollect收集器，对其结果key进行分区（默认使用的hashPartitioner），然后写入buffer，每个map task 都有一个内存缓冲区（环形缓冲区），存放着map的输出结果，当缓冲区快满的时候需要将缓冲区的数据以一个临时文件的方式溢写到磁盘，当整个map task 结束后再对磁盘中这个maptask产生的所有临时文件做合并，生成最终的正式输出文件，然后等待reduce task的拉取

详细步骤：

读取数据组件 InputFormat (默认 TextInputFormat) 会通过 getSplits 方法对输入目录中的文件进行逻辑切片规划得到 block, 有多少个 block就对应启动多少个 MapTask.
将输入文件切分为 block 之后, 由 RecordReader 对象 (默认是LineRecordReader) 进行读取, 以 n 作为分隔符, 读取一行数据, 返回 . Key 表示每行首字符偏移值, Value 表示这一行文本内容
读取 block 返回 , 进入用户自己继承的 Mapper 类中，执行用户重写的 map 函数, RecordReader 读取一行这里调用一次
Mapper 逻辑结束之后, 将 Mapper 的每条结果通过 context.write 进行collect数据收集. 在 collect 中, 会先对其进行分区处理，默认使用 HashPartitioner
接下来, 会将数据写入内存, 内存中这片区域叫做环形缓冲区(默认100M), 缓冲区的作用是 批量收集 Mapper 结果, 减少磁盘 IO 的影响. 我们的 Key/Value 对以及 Partition 的结果都会被写入缓冲区. 当然, 写入之前，Key 与 Value 值都会被序列化成字节数组
当环形缓冲区的数据达到溢写比列(默认0.8)，也就是80M时，溢写线程启动, 需要对这 80MB 空间内的 Key 做排序 (Sort). 排序是 MapReduce 模型默认的行为, 这里的排序也是对序列化的字节做的排序
合并溢写文件, 每次溢写会在磁盘上生成一个临时文件 (写之前判断是否有 Combiner), 如果 Mapper 的输出结果真的很大, 有多次这样的溢写发生, 磁盘上相应的就会有多个临时文件存在. 当整个数据处理结束之后开始对磁盘中的临时文件进行 Merge 合并, 因为最终的文件只有一个, 写入磁盘, 并且为这个文件提供了一个索引文件, 以记录每个reduce对应数据的偏移量
11. 请说下MR中Reduce Task的工作机制
简单描述：
Reduce 大致分为 copy、sort、reduce 三个阶段，重点在前两个阶段。copy 阶段包含一个 eventFetcher 来获取已完成的 map 列表，由 Fetcher 线程去 copy 数据，在此过程中会启动两个 merge 线程，分别为 inMemoryMerger 和 onDiskMerger，分别将内存中的数据 merge 到磁盘和将磁盘中的数据进行 merge。待数据 copy 完成之后，copy 阶段就完成了，开始进行 sort 阶段，sort 阶段主要是执行 finalMerge 操作，纯粹的 sort 阶段，完成之后就是 reduce 阶段，调用用户定义的 reduce 函数进行处理
详细步骤：

Copy阶段：简单地拉取数据。Reduce进程启动一些数据copy线程(Fetcher)，通过HTTP方式请求maptask获取属于自己的文件（map task 的分区会标识每个map task属于哪个reduce task ，默认reduce task的标识从0开始）。

Merge阶段：这里的merge如map端的merge动作，只是数组中存放的是不同map端copy来的数值。Copy过来的数据会先放入内存缓冲区中，这里的缓冲区大小要比map端的更为灵活。merge有三种形式：内存到内存；内存到磁盘；磁盘到磁盘。默认情况下第一种形式不启用。当内存中的数据量到达一定阈值，就启动内存到磁盘的merge。与map 端类似，这也是溢写的过程，这个过程中如果你设置有Combiner，也是会启用的，然后在磁盘中生成了众多的溢写文件。第二种merge方式一直在运行，直到没有map端的数据时才结束，然后启动第三种磁盘到磁盘的merge方式生成最终的文件。

合并排序：把分散的数据合并成一个大的数据后，还会再对合并后的数据排序。

对排序后的键值对调用reduce方法，键相等的键值对调用一次reduce方法，每次调用会产生零个或者多个键值对，最后把这些输出的键值对写入到HDFS文件中。

12. 请说下MR中shuffle阶段
shuffle阶段分为四个步骤：依次为：分区，排序，规约，分组，其中前三个步骤在map阶段完成，最后一个步骤在reduce阶段完成
shuffle 是 Mapreduce 的核心，它分布在 Mapreduce 的 map 阶段和 reduce 阶段。一般把从 Map 产生输出开始到 Reduce 取得数据作为输入之前的过程称作 shuffle。

Collect阶段：将 MapTask 的结果输出到默认大小为 100M 的环形缓冲区，保存的是 key/value，Partition 分区信息等。
Spill阶段：当内存中的数据量达到一定的阀值的时候，就会将数据写入本地磁盘，在将数据写入磁盘之前需要对数据进行一次排序的操作，如果配置了 combiner，还会将有相同分区号和 key 的数据进行排序。
Merge阶段：把所有溢出的临时文件进行一次合并操作，以确保一个 MapTask 最终只产生一个中间数据文件
4.** Copy阶段**：ReduceTask 启动 Fetcher 线程到已经完成 MapTask 的节点上复制一份属于自己的数据，这些数据默认会保存在内存的缓冲区中，当内存的缓冲区达到一定的阀值的时候，就会将数据写到磁盘之上
Merge阶段：在 ReduceTask 远程复制数据的同时，会在后台开启两个线程对内存到本地的数据文件进行合并操作
Sort阶段：在对数据进行合并的同时，会进行排序操作，由于 MapTask 阶段已经对数据进行了局部的排序，ReduceTask 只需保证 Copy 的数据的最终整体有效性即可。
Shuffle 中的缓冲区大小会影响到 mapreduce 程序的执行效率，原则上说，缓冲区越大，磁盘io的次数越少，执行速度就越快
缓冲区的大小可以通过参数调整, 参数：mapreduce.task.io.sort.mb 默认100M

13. shuffle阶段的数据压缩机制了解吗
在shuffle阶段，可以看到数据通过大量的拷贝，从map阶段输出的数据，都要通过网络拷贝，发送到reduce阶段，这一过程中，涉及到大量的网络IO，如果数据能够进行压缩，那么数据的发送量就会少得多。
hadoop当中支持的压缩算法：
gzip、bzip2、LZO、LZ4、Snappy，这几种压缩算法综合压缩和解压缩的速率，谷歌的Snappy是最优的，一般都选择Snappy压缩。谷歌出品，必属精品

14. 在写MR时，什么情况下可以使用规约
规约（combiner）是不能够影响任务的运行结果的，局部汇总，适用于求和类，不适用于求平均值，如果reduce的输入参数类型和输出参数的类型是一样的，则规约的类可以使用reduce类，只需要在驱动类中指明规约的类即可
————————————————
版权声明：本文为CSDN博主「五分钟学大数据」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/helloHbulie/article/details/113555820



Ref 2. https://blog.csdn.net/ASN_forever/article/details/81233547?ops_request_misc=%257B%2522request%255Fid%2522%253A%2522163618091216780264054103%2522%252C%2522scm%2522%253A%252220140713.130102334..%2522%257D&request_id=163618091216780264054103&biz_id=0&utm_medium=distribute.pc_search_result.none-task-blog-2~all~sobaiduend~default-1-81233547.first_rank_v2_pc_rank_v29&utm_term=MapReduce%E7%9A%84shuffle%E8%BF%87%E7%A8%8B%E8%AF%A6%E8%A7%A3%EF%BC%88%E5%88%86%E7%89%87%E3%80%81%E5%88%86%E5%8C%BA%E3%80%81%E5%90%88%E5%B9%B6%E3%80%81%E5%BD%92%E5%B9%B6%E3%80%82%E3%80%82%E3%80%82%EF%BC%89&spm=1018.2226.3001.4187

Kafka what is kafka? and components? |

Kafka是什么？
答：

Kafka是一种高吞吐量、分布式、基于发布/订阅的消息系统，最初由linkedIn公司开发，使用Scala语言编写，目前是Apache的开源项目。

broker： Kafka服务器，负责消息存储和转发

topic：消息类别，Kafka按照topic来分类消息

partition： topic的分区，一个topic可以包含多个partition， topic 消息保存在各个partition上. offset,消息在日志中的位置，可以理解是消息在partition上的偏移量，也是代表该消息的唯一序号
partition的数据文件（offffset，MessageSize，data).
Producer：消息生产者

Consumer：消息消费者

Consumer Group：消费者分组，每个Consumer必须属于一个group. 每个分区只能由同一个消费组内的一个消费者(consumer)来消费，可以由不同的消费组的消费者来消费，同组的消费者则起到并发的效果。

Zookeeper：保存着集群 broker、 topic、 partition等meta 数据；另外，还负责broker故障发现， partition leader选举，负载均衡等功能

————————————————
版权声明：本文为CSDN博主「Java小叮当」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/m0_48795607/article/details/116659584

kafka producer ack 机制 | todo

ack=0：producer不等待broker同步完成的确认，继续发送下一条(批)信息。
ack=1（默认）：producer要等待leader成功收到数据并得到确认，才发送下一条message。
ack=-1：producer得到follwer确认，才发送下一条数据。

kafka file | 顺序写入，逻辑日志文件分段（每段一个文件，多个消息offset）, 稀疏索引+二分查找

每个分区 partiton 对应到一个逻辑日志，一个逻辑日志物理存储上是一组大小大致相同的分段文件。



Kafka为每个分段后的数据文件建立了索引文件，文件名与数据文件的名字是一样的，只是文件扩展名为index。 index文件中并没有为数据文件中的每条Message建立索引，而是采用了稀疏存储的方式，每隔一定字节的数据建立一条索引。这样避免了索引文件占用过多的空间，从而可以将索引文件保留在内存中。
————————————————
版权声明：本文为CSDN博主「Java小叮当」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/m0_48795607/article/details/116659584


速度快是因为：

顺序写入：因为硬盘是机械结构，每次读写都会寻址->写入，其中寻址是一个“机械动作”，它是耗时的。所以硬盘 “讨厌”随机I/O， 喜欢顺序I/O。为了提高读写硬盘的速度，Kafka就是使用顺序I/O。
Memory Mapped Files（内存映射文件）：64位操作系统中一般可以表示20G的数据文件，它的工作原理是直接利用操作系统的Page来实现文件到物理内存的直接映射。完成映射之后你对物理内存的操作会被同步到硬盘上。
Kafka高效文件存储设计： Kafka把topic中一个parition大文件分成多个小文件段，通过多个小文件段，就容易定期清除或删除已经消费完文件，减少磁盘占用。通过索引信息可以快速定位
message和确定response的 大 小。通过index元数据全部映射到memory（内存映射文件），
可以避免segment file的IO磁盘操作。通过索引文件稀疏存储，可以大幅降低index文件元数据占用空间大小。
注：

Kafka解决查询效率的手段之一是将数据文件分段，比如有100条Message，它们的offset是从0到99。假设将数据文件分成5段，第一段为0-19，第二段为20-39，以此类推，每段放在一个单独的数据文件里面，数据文件以该段中 小的offset命名。这样在查找指定offset的
Message的时候，用二分查找就可以定位到该Message在哪个段中。
为数据文件建 索引数据文件分段 使得可以在一个较小的数据文件中查找对应offset的Message 了，但是这依然需要顺序扫描才能找到对应offset的Message。
为了进一步提高查找的效率，Kafka为每个分段后的数据文件建立了索引文件，文件名与数据文件的名字是一样的，只是文件扩展名为.index。
————————————————
版权声明：本文为CSDN博主「五分钟学大数据」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/helloHbulie/article/details/113555820

顺序性 | produce, consume todoss

kafka分布式（不是单机）的情况下，如何保证消息的顺序消费？
答：

Kafka分布式的单位是partition，同一个partition用一个write ahead log组织，所以可以保证FIFO的顺序。不同partition之间不能保证顺序。但是绝大多数用户都可以通过message key来定义，因为同一个key的Message可以保证只发送到同一个partition。

Kafka中发送1条消息的时候，可以指定(topic, partition, key) 3个参数。partiton和key是可选的。如果你指定了partition，那就是所有消息发往同1个partition，就是有序的。

并且在消费端，Kafka保证，1个partition只能被1个consumer消费。或者你指定key（比如order id），具有同1个key的所有消息，会发往同1个partition。
————————————————
版权声明：本文为CSDN博主「Java小叮当」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/m0_48795607/article/details/116659584

如何保证数据不丢 | producer: ack=1/-1, consumer: 通过topic里记录的offset， broker: replication

Kafka数据怎么保障不丢失？
分三个点说，一个是生产者端，一个消费者端，一个broker端。

生产者数据的不丢失
kafka的ack机制：在kafka发送数据的时候，每次发送消息都会有一个确认反馈机制，确保消息正常的能够被收到，其中状态有0，1，-1。

如果是同步模式：
ack设置为0，风险很大，一般不建议设置为0。即使设置为1，也会随着leader宕机丢失数据。所以如果要严格保证生产端数据不丢失，可设置为-1。

如果是异步模式：
也会考虑ack的状态，除此之外，异步模式下的有个buffer，通过buffer来进行控制数据的发送，有两个值来进行控制，时间阈值与消息的数量阈值，如果buffer满了数据还没有发送出去，有个选项是配置是否立即清空buffer。可以设置为-1，永久阻塞，也就数据不再生产。异步模式下，即使设置为-1。也可能因为程序员的不科学操作，操作数据丢失，比如kill -9，但这是特别的例外情况。

注：
ack=0：producer不等待broker同步完成的确认，继续发送下一条(批)信息。
ack=1（默认）：producer要等待leader成功收到数据并得到确认，才发送下一条message。
ack=-1：producer得到follwer确认，才发送下一条数据。

消费者数据的不丢失
通过offset commit 来保证数据的不丢失，kafka自己记录了每次消费的offset数值，下次继续消费的时候，会接着上次的offset进行消费。

而offset的信息在kafka0.8版本之前保存在zookeeper中，在0.8版本之后保存到topic中，即使消费者在运行过程中挂掉了，再次启动的时候会找到offset的值，找到之前消费消息的位置，接着消费，由于 offset 的信息写入的时候并不是每条消息消费完成后都写入的，所以这种情况有可能会造成重复消费，但是不会丢失消息。

唯一例外的情况是，我们在程序中给原本做不同功能的两个consumer组设置
KafkaSpoutConfig.bulider.setGroupid的时候设置成了一样的groupid，这种情况会导致这两个组共享同一份数据，就会产生组A消费partition1，partition2中的消息，组B消费partition3的消息，这样每个组消费的消息都会丢失，都是不完整的。 为了保证每个组都独享一份消息数据，groupid一定不要重复才行。

kafka集群中的broker的数据不丢失
每个broker中的partition我们一般都会设置有replication（副本）的个数，生产者写入的时候首先根据分发策略（有partition按partition，有key按key，都没有轮询）写入到leader中，follower（副本）再跟leader同步数据，这样有了备份，也可以保证消息数据的不丢失。
————————————————
版权声明：本文为CSDN博主「五分钟学大数据」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/helloHbulie/article/details/113555820

Kafka消息数据积压，Kafka消费能力不足怎么处理？

如果是Kafka消费能力不足，则可以考虑增加Topic的分区数，并且同时提升消费组的消费者数量，消费者数=分区数。（两者缺一不可）

如果是下游的数据处理不及时：提高每批次拉取的数量。批次拉取数据过少（拉取数据/处理时间<生产速度），使处理的数据小于生产的数据，也会造成数据积压。
————————————————
版权声明：本文为CSDN博主「五分钟学大数据」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/helloHbulie/article/details/113555820

atleat/most/exactly once

保证 Exactly-once
3.1、依赖业务控制
对生产者：

每个分区只有一个生产者写入消息，当出现异常或超时，生产者查询此分区最后一个消息，用于决定后续操作时重传还是继续发送。
为每个消息增加唯一主键，生产者不做处理，由消费者根据主键去重。
对消费者：

关闭自动提交 offset 的功能，不使用 Offsets Topic 这个内部 Topic 记录其 offset，而是由消费者自动保存 offset。将 offset 和消息处理放在一个事务里面，事务执行成功认为消息被消费，否则事务回滚需要重新处理。当出现消费者重启或者 Rebalance 操作，可以从数据库找到对应的 offset，然后调用 KafkaConsumer.seek() 设置消费者位置，从此 offset 开始消费。
3.2、依赖 Kafka
3.2.1、幂等性：每个分区中精确一次且有序（Idempotence: Exactly-once in order semantics per partition）
Kafka 在0.11.0.0之前的版本中只支持 At Least once 和 At Most once 语义，尚不支持 Exactly once 语义。

Kafka 0.11.0.0版本引入了幂等语义。 一个幂等性的操作就是一种被执行多次造成的影响和只执行一次造成的影响一样的操作。

如果出现导致生产者重试的错误，同样的消息，仍由同样的生产者发送多次，将只被写到 Kafka broker 的日志中一次。


————————————————
版权声明：本文为CSDN博主「w1992wishes」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/w1992wishes/article/details/89502956

kafka的数据offset读取流程 | consumer-zk-partition/leader/broker offset - leader - segmentfile

连接ZK集群，从ZK中拿到对应topic的partition信息和partition的Leader的相关信息

连接到对应Leader对应的broker

consumer将⾃自⼰己保存的offset发送给Leader

Leader根据offset等信息定位到segment（索引⽂文件和⽇日志⽂文件）

根据索引⽂文件中的内容，定位到⽇日志⽂文件中该偏移量量对应的开始位置读取相应⻓长度的数据并返回给consumer
————————————————
版权声明：本文为CSDN博主「五分钟学大数据」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/helloHbulie/article/details/113555820

MQ 消息队列特点 | 解耦，冗余，异步，流量薛峰天谷，扩展

消息队列
解耦： 消息中间件，两边数据源只需实现中间件接口
冗余： 消息队列持久化消息, 提供数据冗余和可恢复性
异步机制：消息到达后，使用方可选择在特定时间处理消化消息，不需要立即处理
流量峰值应对能力： 由于冗余和异步机制，对峰值流量可做缓冲处理
扩展性：消息生产和消费可动态扩展，而不用变更系统结构
————————————————
版权声明：本文为CSDN博主「HanseyLee」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/fzlulee/article/details/100172979

Flink ClickHouse Redis Memcache 其他 ES Presto RockMQ Abase SQL 常用的HiveSQL/SparkSQL内建函数 | from_unixtime, unix_timestamp, datediff, date_sub, date_add

Temporal
from_unixtime
from_unixtime(unix_time, format) - Returns unix_time in the specified format.
Examples:
> SELECt from_unixtime(0, 'yyyy-MM-dd HH:mm:ss');
 1970-01-01 00:00:00
Since: 1.5.0

e.g.2  
if(FROM_UNIXTIME(create_time_unix, 'yyyyMMdd') = '${date}', 1, 0) as is_create,


from_utc_timestamp
from_utc_timestamp(timestamp, timezone) - Given a timestamp like '2017-07-14 02:40:00.0', interprets it as a time in UTC, and renders that time as a timestamp in the given time zone. For example, 'GMT+1' would yield '2017-07-14 03:40:00.0'.
Examples:
> SELECt from_utc_timestamp('2016-08-31', 'Asia/Seoul');
 2016-08-31 09:00:00
Since: 1.5.0

unix_timestamp
unix_timestamp([expr[, pattern]]) - Returns the UNIX timestamp of current or specified time.
Examples:
> SELECt unix_timestamp();
 1476884637
> SELECT unix_timestamp('2016-04-08', 'yyyy-MM-dd');
 1460041200

Since: 1.5.0

date_format
date_format(timestamp, fmt) - Converts timestamp to a value of string in the format specified by the date format fmt.
Examples:
> SELECT date_format('2016-04-08', 'y');
 2016
Since: 1.5.0

date_add
date_add(start_date, num_days) - Returns the date that is num_days after start_date.
Examples:
> SELECT date_add('2016-07-30', 1);
 2016-07-31
Since: 1.5.0

date_sub
date_sub(start_date, num_days) - Returns the date that is num_days before start_date.
Examples:
> SELECT date_sub('2016-07-30', 1);
 2016-07-29
Since: 1.5.0

datediff
datediff(endDate, startDate) - Returns the number of days from startDate to endDate.
Examples:
> SELECt datediff('2009-07-31', '2009-07-30');
 1

> SELECT datediff('2009-07-30', '2009-07-31');
 -1

Since: 1.5.0
获取某日期星期几？所在星期的星期一
select current_date() ,pmod(datediff(current_date(),'1970-01-05'),7)+1, date_sub(current_date(), pmod(datediff(current_date(),'1970-01-05'),7));

常见SQL题目 |

-- 1. 不用窗口实现排名
set hive.mapred.mode=nonstrict;
SELECT 
    a.f1,
    count(distinct b.f1) as rn
FROM db.tb as a , db.tb as b 
where  a.f1 <= b.f1
group by a.f1
order by a.f1 desc

数仓 什么是数仓 | 数据仓库是一个面向主题的、集成的、相对稳定的、反映历史变化的数据集合，沉淀数据资产，用于支持数据分析、推荐和管理决策。 维度建模 事实表 维度表 拉链表 原子指标/衍生指标 | todo guowen 分层和规范 | 为何分层：1. 统一数据标准和口径 2. 抽象加工逻辑，公共部分提取和复用，减少重复计算和存储 3.数据标准处理，屏蔽底层，便于使用 数仓从0到1的过程 | 调研（业务、需求和数据），主题域，维度建模，QA, DM门户，数据治理 数据治理 | todo mobile phone 计算治理 存储治理 任务治理 大数据理论 CAP 分布式一致性协议 | todo blog 2PC 3PC Paxos ZBS 拓扑结构 Master/Slave Primary/Backup ReplicaSet Java | todo blog Collections HashMap/HashTable/ConcurrentHashMap List/Map

https://blog.csdn.net/m0_48795607/article/details/115485109 java basic
https://blog.csdn.net/m0_48795607/article/details/115489616 多线程 TODO

JVM JVM内存结构 GC JVM内存模型 HappensBefore

https://blog.csdn.net/m0_48795607/article/details/115555086 JVM

OS 用户空间/内核空间 零拷贝 进程/线程

https://blog.csdn.net/m0_48795607/article/details/116798880 linux

HTTP/TCP 三次握手，四次挥手 长短链接 Security 加密