为什么不先申请全局锁再执行本地事务呢？

Seata会维护全局锁，如果一个全局事务需要进行本地提交，需要先获取全局锁。而对于select for update也会申请全局锁，用于保障事务隔离级别为read commit

组静态成员，避免瞬时的消费者不可用导致的rebalance

ReplicaManager主要负责日志的写入以及副本的同步，如果ack配置的不是0，则需要等待副本写入满足acks才会回复响应。同时ReplicaManager会定时检查ISR是否已经不再同步，主要是看当前副本的LEO与Leader的LEO是否相同，或者上次lag的时间是否超过replica.lag.time.max.ms，默认30s

分区读取状态一般是Leader的状态吧

就是当前副本的状态，是否可以去Fetch,如果当前在截断中，就不能Fetch,而如果被delay了同理

副本处于ISR中居然是lag为0

各副本已经同步的消息offset, HW leader节点从所有的副本中获取LEO,取最小的LEO做HW,HW为所有已经成功写入全部副本的消息的最新位置。Follower的HW则是他的LEO和leader的HW的较小值

LSO，最早的一个未提交事务前的位点，也就是read commit能读取的位置

副本对外提供读取服务

解决的问题

当多线程同时执行该方法进行检查的时候，拿到锁的线程complete失败，而没拿到锁的线程直接跳过，那么如果没有其他线程再去处理的话，就永远也不会complete。

如何解决？

如果第一个线程成功将retry设置为false，那么第二个线程就会进行重试，而如果本身retry就是true，那么说明被其他线程先一步设置了，该线程不重试。但是如果多个线程顺序执行，都完成不了，那不是一样？

相当于重新添加进时间轮，但是如果已经到了时间，那么就会执行。而且由于时间轮向后滚动，如果是最下面一级的bucket则所有元素都会过期，而上一级的bucket则会往下一级插入.

由于DelayQueue的存在，时间复杂度和直接使用DelayQueue有什么不同？

首先是以bucket为单位写入DelayQueue，bucket通过分层，使得每一层只有20个bucket，那么n层就只有n*20个bucket，大大减少了DelayQueue元素的数量，减小时间复杂度。

为什么这里有一个存储所有TimerTaskList的DelayQueue?那我为什么不直接把所有任务往队列里面塞？这样不还是O(logn)时间复杂度吗插入

内部会将list置空

我的回答: 在Controller启动、Broker启动、Broker下线等状态下，为NewPartition、OfflinePartition选举Leader

有误导性，对于NewPartition可以转变成OnlinePartition，在这个过程中进行初始化

给ISR发

NewPartition状态的分区，进行初始化（因为是初始化，所以数据都为空），会将存活副本设置为ISR,而将ISR第一个设置为Leader

Leader选举

心跳机制来确定broker的状态

AR(Assigned Replicas)与ISR的区别

AR表示分区的副本，而ISR表示与Leader同步的副本

Topic: xxc TopicId: HPo2q0gHRSC261VzemHlcw PartitionCount: 1 ReplicationFactor: 1 Configs: segment.bytes=1073741824 Topic: xxc Partition: 0 Leader: 1 Replicas: 1 Isr: 1

AR

实际上消息队列都是以分区为单位组织的。而一个topic拥有多个分区，客户端可以根据一定的规则(Partitioner)往这多个分区中写入数据，而消费者则通过一定规则或者随机分配到部分partition，从partition中顺序进行消费

PartitionStateMachine定义的是分区是否有Leader

什么时候会发生分区Leader选举？

Kafka如何保证请求发送后能够按预期执行？

通过重试兜底保证最终一致性？同时如果主从切换的话，会进行检查然后重新进行状态同步

Controller给Broker发送请求是否需要保证Broker变更成功

不需要，Controller发送请求后会异步的等待broker心跳中包含的响应。同时由于MQ本身的设计能够进行容错，即旧的状态如果不对，那么会进行重试，或者刷新缓存元数据

为什么不是NewReplica状态就可以直接让其他broker同步？

因为最前面判定了validReplicas,所以这些状态的变更都是允许的

为什么要以元数据缓存为准？

副本状态变更流程

按brokerId分组进行副本状态变更

具体看是否支持Online DDL

Online DDL是对于历史DDL的优化，默认对于支持的DDL操作生效。如果使用Copy算法，则会阻塞DML。

错误的io能力设置，导致mysql错估磁盘io，影响脏页的刷新效率

查询语句中即使存在索引没有的字段信息，也可能选中索引

比如索引是字段的前缀，如email(6)

如何解决选错索引？

无法从根上解决。 缓解的方法(仍然可能选错索引): - analyze table更新统计信息 - force index(索引可能变更，不灵活) - 删除错误的索引(很多时候，其他业务需要用到该索引) - 通过修改sql引导mysql优化器，让其觉得错的索引成本高（不通用）

子查询无法使用limit问题

在in中子查询不能使用limit，但是可以在from后面使用limit，因此可以在in的子查询中套一个子查询，如下: select *from cidy where id in(select id from(select id from cidy limit 0,10) as cd);

change buffer使用

主要是给同一页的随机写攒批 1. 只影响不存在唯一索引的插入 2. 如果插入后就需要读取，那么最好关闭change buffer

可是实际上是对随机写攒批呀。如果没有change buffer则会在页缺失的时候加载，当然change buffer延迟了加载的时间，只在需要的时候加载，但是如何保证数据存在呢？比如更新的时候需要返回影响行数的，那是否只能用于没有唯一索引的表插入？

索引是如何实现mvcc呢？

索引没有undolog，因此索引需要回表，通过回表得到数据的undolog，然后判定索引条目是否有效。但是如果索引本身不带事务id，那么如何知道其属于哪一个版本呢？如果每个索引条目都需要回表才能确定是否有效，那么全索引扫描不就是全表扫描了吗？如果主键变更索引又要如何处理？

https://dev.mysql.com/doc/refman/8.0/en/innodb-multi-versioning.html?open_in_browser=true

似乎是，二级索引的数据也是一样不删除，而是标记为删除，但是仍然存留在二级索引的b+树上，每个索引页会记录最近更新的事务id。而如何确定数据是否有效呢，回表,回表，回表，重要的事情说三遍，只有回表访问版本链才能知道readview是否能够看到这条记录的这个版本

If a secondary index record is marked for deletion or the secondary index page is updated by a newer transaction, the covering index technique is not used. Instead of returning values from the index structure, InnoDB looks up the record in the clustered index.

大量插入数据时，Auto-INC锁会阻塞其他事务的插入，如何解决？

使得innodb_autoinc_lock_mode设置为1或者2，默认0，使得在插入时申请到自增值后立即释放auto-inc锁。在不同值下的行为: - 若是1，则insert ... select from这种仍然会执行完成后释放锁 - 若是2，则获取到了自增值就立即释放，但会引起主从不一致，因此需要将binlog设置为mixed或者row格式。

如果更新的时候走的全表扫描，则会锁住扫描的所有数据，如何避免？

• 删除时查询出来通过id删除
• 开启sql_safe_updates，其要求sql能够击中索引或者通过limit限制了更新的行数

事务语句顺序优化

对于一个事务，应该将更容易被多个事务访问的锁放在后面加，比如说店铺，而比如用户的锁则先加，这样能够减少店铺的锁占用的时间

死锁检测以及相应开销

由于事务之间可能产生死锁，因此要么设置最大等待超时时间，要么设置死锁检测。

死锁检测

1. 维护等待图（Wait-for Graph）

InnoDB 内部维护一个有向图，图中的节点表示事务（Transaction），边表示锁的等待关系。

例如：事务A持有行X的锁，事务B请求行X的锁并被阻塞，则图中有一条边从B指向A（B→A，表示B在等待A释放锁）。

当某个事务请求锁时，如果锁已被其他事务持有，InnoDB 会更新等待图，添加一条新的边。

2. 检测环（Cycle）

每次有事务请求锁失败（进入等待状态）时，InnoDB 会触发死锁检测。

深度优先搜索（DFS）：InnoDB 通过DFS遍历等待图，检查是否存在环。如果发现环，则判定为死锁。

优化：为了减少性能开销，InnoDB 不会每次都全图遍历，而是从新加入的边出发，仅检查可能形成环的路径。

3. 选择牺牲者（Victim）

如果检测到死锁，InnoDB 会选择一个事务作为牺牲者（通常选择回滚成本更低的事务，例如修改数据量较小的事务），强制回滚该事务，并释放其持有的锁。

回滚后，等待图中对应的边被移除，其他被阻塞的事务可以继续执行。

死锁的开销

问题

因此由于事务的不断加入，图会变得越来越大，进行环检测是O(n)的操作，若n很大则cpu大量消耗。

解决

可以通过中间件对操作相同key的事务限流，这样事务虽然也在等待，但是没有增加死锁检测的负担。

当索引值相同时，按照主键排序，因此索引最后的字段是主键的话，可以去掉该索引

MySQL有哪些锁？

1. 全局锁

元数据锁

2. 表级锁

• 元数据锁
• 插入意向锁
• 自增锁

3. 行级锁

• 间隙锁
• 行锁

全库只读，最好使用flush table with read lock，其比设置readonly的好处是: 1. 能够自动释放 2. 可能其他系统会使用readonly做主备逻辑

重建主键

删除主键相当于重建整个表，mysql内部会使用一个隐式的自增字段存储记录。而创建主键则再次进行更改，将其从隐式转成显示的字段。因此如果需要重建主键索引则可以直接使用alter table T engine=InnoDB。

删除自增主键

如果要删除自增主键，那么主键列必须将自增删除掉，因为隐式的主键也是自增的，一个表只能有一个自增字段

尽量使用自增主键，能够避免页分裂，同时减少普通索引叶子节点的占用空间

删除或创建主键会重建表

索引主要优化手段。尽量避免回表从而提高查询性能

物理备份(热备)

Percona XtraBackup 8.0.30-23引入了--register-redo-log-consumer参数。--register-redo-log-consumer参数默认为禁用状态。当启用时，此参数允许Percona XtraBackup在备份开始时注册为一个重做日志消费者。服务器不会移除Percona XtraBackup（消费者）尚未复制的重做日志。消费者读取重做日志并手动提升日志序列号（LSN）。在此过程中，服务器阻止写入操作。基于重做日志的消耗，服务器决定何时可以清理日志。

为什么需要定期全量备份？

因为备库会很快同步主库的数据，如果发生误删数据，备库无法保证数据的恢复。而全量备份则可以留存定期的快照，当出现问题时能够回滚

预防和发现

1. 通过innodb_schema追踪innodb的事务状态，发现长事务，予以告警
2. 连接初始时需要显示的设置autocommit或者显式启动连接，关闭或归还连接池的时候应显式重置连接（目前spring、mybatis会自动做）

查找长事务

由于当前系统中没有比undolog更早的readview才能删除undolog。因此应当避免长事务来防止undolog大量占用磁盘和buffer pool。

undolog使得记录能够往回回滚，使得mvcc读取到历史版本的数据

目前有团队在做基于redolog来做归档，从而去除binlog的依赖

redolog是innodb引入保证crash-safe的。而binlog则是mysql的归档日志，可以提供备份、从节点复制等功能。为了保证redolog与binlog的一致性，通常需要两阶段提交，从而防止mysql的数据与binlog数据不一致。主要在于需要保证事务的redolog状态至少为prepare状态，且binlog完整(如果当前redolog处于提交状态，则事务直接是有效的)

redolog是循环写的，只需要读取需要修改的数据(页)然后根据页的状态生成物理修改日志。使用redolog则无需直接去随机写修改磁盘页，而转变为了“顺序写redolog”

正常情况下的WAL或者说日志基本都是逻辑日志，而在mysql中redolog是物理日志，mysql如何知道要将数据写到物理磁盘上的那一个位置呢? Buffer Pool中为物理页的映射，由此知道如何在物理上进行数据的修改。

row_examined表示在执行器扫描的数据行数，不代表执行引擎扫描的数据行数

连接使用的一些内存资源只有在连接断开时释放。因此对于大查询或者长期使用的连接可以定期释放或者在5.7+执行mysql_reset_connection

时间戳的存储和传递建议使用Instant，其使用UTC时间，不绑定时区，可以根据需要转换为其他时区的展示。

日志是如何清理的呢？

1. deletion策略，正常情况下，根据日志的配置，自动进行最大留存时间、最大留存大小的清理，以segment为单位,具体看kafka-log-retention任务
2. compaction策略，topic可以设置compaction策略为compaction、delete + compaction，这样的话LogCleaner会定时进行compaction。优化策略，segments氛围cleaned和uncleaned，从uncleaned中遍历消息(在逻辑中可以根据需求读取需要的大小以节省内存)构建offsetMap来存储这一段中最新的key的offset，而从头遍历segments，清理掉offsetMap中已有的已有的消息(也就是最新消息)

todo

recover过程中会重置索引，然后遍历每个batch来添加索引项，这样就能避免掉原本写入消息时，一次性写入的多batch的消息最多只写入一次索引导致查询效率低的问题

什么时候recover？

kafka在shutdown的时候会将segment刷盘并维护checkpoint和.kafka_cleanshutdown文件，每个partition一份.重启的时候会进行判定

配置topic的segment.jitter.ms或者segment.ms让segment根据时间自动滚动时错峰，避免io压力过大

即使segment的数据量不大，超过固定时间(默认一周)没写入数据，也会滚动segment，那如果很多segment都没写入的话，那么就会同时创建segment导致大量的io占用 rollJitterMs则是一个随机的扰动值,来源于{@link LogConfig#randomSegmentJitter()}， 通过这个值可以将segment滚动的时间错开，缓解物理磁盘的 I/O 负载瓶颈

indexIntervalBytes控制时间和offset索引写入的频率，减少日志大小

segment的区间是左闭右开

4.0已经没有对于becomeLeaderOrFollower的调用以及对ISR的广播，那现在是怎么进行Leader和Follower的变更呢？

防抖

由于定时检查是配置的一半时间，因此lag超过1.5倍配置的isr仍然可能存在

如果没有累积到一定数据，那么这部分数据被读取后就被丢弃了，这就比较浪费，能不能先计算一下是否能够到达阈值呢

不需要顾及acks，直接写入副本即可

用户还可能手动删除消息？这种情况kafka也考虑了。。。

TODO

当leader变更时，follower需要truncate自己的日志来保证与leader一致，而leader切换的时候，自身也需要truncate到HW来保持数据的一致性，但是这样会丢消息，当然如果没有到HW，那么需要所有节点同步的消息应该收不到回复

对于出错的partition，将其丢到LinkedHashMap的尾部，并且更新PartitionFetchState的delay信息，等到delay的时间再重新fetch

同步数据是通过一个线程批量从一个broker获取的，如果多个partiton的leader都在一个broker上，会一起拉取

LSO,和事务相关，当前如果有事务的话，没有提交的事务的消息对用户是不可见的，因此LSO在这个事务消息的前面来进行标记

Leader如何知道当前的同步进度？

partition的高水位线表示当前已同步的offset，这些消息是安全的，可以被consumer消费，因此通过这个可以看到消息的同步进度 参考

类型别名

如果Leader挂了，follower要达到什么标准才能成为leader？是否可能丢失数据？

副本同步的时候，谁主动进行同步？

这三个看起来都是在删除的时候超时导致的broken status

看起来似乎是application id为空字符，也就是没拿到application id,然后尝试kill,获取job的application id是通过bash命令获取的，那意味着可能job会执行完毕

所以程序员总是想着用代码解决问题

用户故事，边界

想办法告知 dev design，尽量对齐理解

太形象了

如果宽依赖前面的节点数据丢失或者故障，那么后面所有执行都会受到影响

存算分离，动态调度

由于数据格式可能存在嵌套和 repeat，基于列存，那么某行的该列的值是哪些很难判定，因此通过 dremel 的 repetition level 和 definition level 的方式进行编码后就能重组数据

当前字段本身可能是 null，也可能由于上一级是 null 导致当前字段是 null，所以需要 definition level

同一区间的行的多个列存放在同一个服务器上

可能希望一行的一些列存在一起，避免网络传输

对于列存这种不便于写入的情况，可以先利用 wal 暂存数据，最后批量写

拆分多个文件之后，就不再是顺序读取了

https://tech.meituan.com/2014/02/12/hive-sql-to-mapreduce.html

分区可以减少数据的扫描量，而分桶则能够便于进行采样，以及数据负载均衡 https://www.51cto.com/article/753462.html

看论文的关注点

系统的简单性

**如果raft 的客户端网络波动没收到成功响应而重试岂不是会多次执行操作？ **

对于这个问题，Raft协议中有一种机制管理这种网络不稳定的情况。

在Raft协议中，客户端请求是通过集群的领导者节点来处理的。当一个客户端提交一个请求，领导者节点将这个请求作为一个新的日志条目添加到自己的日志中。然后领导者向其他节点复制这个条目。当这个条目被大多数节点保存到日志中之后，然后领导者就执行这个请求并向客户端返回结果。

为了解决客户端因网络问题接收不到结果而重试的问题，Raft设计了client interaction的机制。也就是说，客户端在发送请求时会附加一个唯一的请求ID。这样，即使一个请求由于网络问题重复发送，由于请求ID相同，领导者能识别出这个重复的请求并且忽略它。

在这个机制下，即使客户端因为网络问题重试请求，由于有请求ID作为标识，整个操作仍然只会执行一次。另外，即使返回结果因网络问题没有送达客户端，领导者也能根据请求ID重新发送应答而不会重复执行操作。

因此，虽然在网络不稳定的情况下客户端可能会重试，但是通过Raft协议的设计，这个操作不会被重复执行多次。

accept 阶段之后，并没有所有节点都同步数据，那么这些数据将在什么时候进行同步呢？如果新的请求到来，那么有旧数据的节点能否接受请求呢？<br /> 似乎数据持久化是在其他节点上，比如 learner 节点上，当获得了大多数的 accept 就相当于拿到了整个集群锁，然后往 learner 中写数据

https://www.bilibili.com/video/BV1TW411M7Fx/?spm_id_from=333.337.search-card.all.click&vd_source=014617305bb0e21aa434e6ff50b5cf67

如果数据依赖于当前的数据，那 paxos 算法的重试不就没用了吗？需要重新读取数据并自己进行重试

不确定是否是正确的，正确的做法不应该是 rollback 吗？

两阶段提交也没法保证一致性，一旦在决定提交事务时部分节点宕机那么只有一部分节点成功 commit，就出现数据的不一致

三阶段提交相比两阶段提交会先检查各节点资源是否可用<br /> 同时在提交执行阶段，如果参与者等待协调者超时了，那么参与者会继续完成事务的执行 (回滚或者提交)，因此不同节点数据会存在不一致<br /> 更多请看这里

变长编码存储数据

通过存储编号间的差值Delta Encoding，减少存储编号需要的空间。只需要一个字节即可存储编号和类型

如果需要废弃字段，那么需要保证不再需要向前兼容了，当前所有的相关程序都已经切换到了不需要这个字段的版本

数据兼容主要处理两种情况:<br /> 向前兼容: 旧代码解析新数据<br /> 向后兼容: 新代码解析就数据

布隆过滤器还是很适合 LSM Tree 的

是否可以理解为内存中是最新的数据，而磁盘上的日志则是整个修改过程，如果用户需要获取历史版本，那么就从磁盘数据上恢复得到

合并的是同一行数据多个版本，不需要的版本可以删除

布隆过滤器无法支持删除操作，同时每次启动都需要加载，或者需要持久化

同一行的数据连续存储，所以单行事务还是好实现的，并没有分布式问题

由于一张表会存在大量的列，但是可能会是不同的业务的数据，因此通过列族进行标识切分。<br /> 不同的列族物理上也是连续的，只是是否是一个整体而已，比如压缩缓存的时候。同一列族的数据连续存储

在Google Cloud Bigtable中，列族有以下几个主要作用：

数据组织：列族被用来组织、分组一系列有相关性的列。这样的结构不仅提供了更高效的查询方式，也使得对于业务上有关联的数据能够更好地进行管理。 数据存储和压缩优化：同一列族中的数据在物理存储上相互靠近，这样可以确保相同类型的数据一起被读取、写入或者压缩，从而提高效率。 读写性能：通过将相关的数据存储在同一个列族中，可以提高读写性能，因为只需要访问一个列族而不是多个列。 安全性和权限控制：列族能够为权限管理提供边界，比如可以对不同的列族设置不同的访问权限。 灵活性和扩展性：Bigtable的列族模型允许动态地向每一行添加或删除列，使得Bigtable非常适应变化多端的需求。 垃圾回收：在Bigtable中，基于时间的垃圾回收策略是按列族来设定的，可以指定保存特定列族中某一时间段之内的数据版本。 总的来说，列族在Bigtable中发挥着重要的角色，它在数据管理、性能优化、安全控制以及灵活性等多个方面都起着关键的作用。

Each random read involves the transfer of a 64 KB SSTable block over the network from GFS to a tablet server, out of which only a single 1000-byte value is used…… Random and sequential writes perform better than random reads since each tablet server appends all incoming writes to a single commit log and uses group commit to stream these writes efficiently to GFS.

随机写和顺序写的性能旗鼓相当，不仅在单台tablet server上表现类似，在tablet server集群上表现也几乎一样。原因是它们都会先写commit log，同步修改内存中的数据，异步修改SSTable中的数据。随机写和顺序写的差异在于SSTable的变更，由于这个操作被异步执行，所以它们的性能没有差异。 如果SSTable的不缓存在tablet server上，随机读的性能非常差，比写入操作几乎慢一个数量级。原因是不管要实际需要多小的数据，都需要从GFS上加载64k的SSTable块数据。它的瓶颈不在于tablet server的多少，而在于从GFS上读取数据。

BigTable 通过 Chubby paxos 协议来保证全局只有一个 master，同时存储一些全局数据，比如 Root Tablet 的位置信息

Master 负载均衡，动态重分区

存算分离的鼻祖

这么早，google 就已经在存算分离了

类似于一致性 hash ，只是这里是直接对按 key 排好序的数据进行均匀切分，如果插入或删除导致不均衡则进行合并或分裂

如果前期不合理考虑，岂不是给后面增加技术债？

列有多个版本，而不是行

分区建的选择可能导致数据倾斜，从而导致整体翻倍扩容部分倾斜度低的服务器资源过剩

常规分库分表策略需要进行翻倍扩容，且扩容后缩容同样麻烦，原本想要加部分服务器也不得不翻倍进行 如果换成一致性 hash 确实能改善翻倍扩容问题

map 函数并不能减少数据量，因此通过 combiner 可以在同一个 map 节点进行 reduce 合并数据来减少传输数据

编程原则

5400转或者 7200 转的硬盘只有 70iops

追加写时，在写入数据的时候带上时间戳，数据最终的顺序按照时间戳排序去重能够一定程度上保证数据的正确性

数据写入可能存在部分写入的脏数据，通过校验和排除

gfs 的至少一次保证并不适用于常规应用，只是对于谷歌搜索引擎的业务比较适合

考虑两个客户端 A、B往一个 hdfs 文件上随机写入，分别写 chunk1 和 chunk2，但 chunk1 主副本定序为A、B,而 chunk2 的主副本定序为 B、A，那么 chunk1 中的数据是 B 覆盖 A,而 chunk2 中是 A 覆盖 B,因此不能得到一份完整的 A或者 B

当需要复制一份数据进行追加写的时候性能好，数据复制不需要经过网络，而是通过控制指令直接在 chunserver 上进行

kafka也有这个，元信息的读写和文件的读写分开，文件的读写不需要经过 master

对于同一个 chunk 来说，主、次副本是固定的，当多个客户端并发写chunk 时，需要主副本确定写入的顺序，从而保持各个副本之间的一致性

shadow master 相当于读副本

在客户端进行数据校验、去重

mit

论文资料

扩展阅读和交叉阅读

思考自己如何做

Spark与hive的集成分为两种，spark with hive和hive on spark

spark cli需要与hive部署在一起，但生产环境hive都是独立部署，因此spark cli的方式一般不使用

当多个rdd的数据进行交互的时候，rdd前一步的计算会进行shuffle，并shuffle到对应的executor上

将倾斜分区拆分成多个分区

AQE需要获取数据的统计信息来决定是否将数据进行广播

由于 Shuffle 会对分区内的数据进行排序，因此 SMJ性能和 HJ 一样，那 Shuffle HJ 就没有优势了

那如果是非等值条件关联查询呢？

非等值的连表关联还得使用 NLJ

使用 Hash算法做关联似乎在大数据领域比较好用

使用 Java对象会存在大量的存储开销，因此使用本地内存加 byte数组进行存储

DataFrame 使用的 Spark SQL 进行解析执行，因此其也存在逻辑计划、物理计划

通过blockId能够获取需要的数据，无论在内存还是磁盘中

spark内存数据存储结构

spark存储服务的对象

广播变量与累加器的区别在于一个是共享读取，一个是共享写入

Executor是进行干活的工人，而task是spark计算的最小粒度，工人不断地执行task来完成每一阶段的task然后转向下一阶段，直到所有的阶段执行完毕

如果使用广播变量，那么数据只会在driver和executor上都存一份，task在executor上执行，如果使用到广播变量则直接从executor上获取即可

如果在任务执行的过程中引用了外部的变量，那么driver需要将变量传输给每一个相关的task，因此传输开销很大

https://stackoverflow.com/questions/31610971/spark-repartition-vs-coalesce

收集数据会导致Driver的内存占用

内存划分配置，Reserved Memory为300M，总内存量为M，剩余内存M - 300,然后划分为User Memory(1 - mf)和共享内存[Execution Memory+ Storage Memory(mf * sf)]

Cache并不是自动的，而是人手动添加的，将RDD物化到内存中

Execution Memory在共享内存中的优先级更高，如果Storage Memory抢占了EM的内存且EM的内存需要则必须归还

内存共享

排序算子与其他聚合算子不同https://blog.csdn.net/raintungli/article/details/73663733

在Map端聚合后，在Reduce端基于Map端的聚合结果再进行聚合，从而实现在Map端减少传输的数据量，而在Reduce端又能实现目的

指定Map、Reduce端的聚合函数

Map端聚合能够减少数据的分发数量(原本需要传输原数据，而聚合后则可以将多条数据合并为聚合数据)

shuffle过程并不是Map阶段的节点将数据发送给Reduce阶段的节点，而是Reduce节点主动去Map阶段的节点上拉取数据，根据index文件来获取自己需要的数据

基于这个逐渐可以将相同分区相同key的数据进行合并

基于溢出机制，在受限内存中处理大量数据，将处理过程中的部分结果进行排序写入临时文件，最终将所有文件进行归并排序得到任务最终的data文件和index文件

shuffle过程不需要直接进行排序，而只需要基于key进行hash分区然后分发。而分发完成后，在进行排序聚合是合理的

在Shuffle的时候，Map阶段可以进行局部聚合，而局部聚合后可以确定第一轮数据分发的节点，基于hash或者什么算法进行分区后，再一次进行全局聚合，从而将相同key的数据进行聚合

在不同的工地上有不同类型的砖块，需要将相同类型的砖块分发给对应的节点，因此需要砖头在集群范围内跨节点、跨进程的数据分发

数据在不同节点上处理之后，需要基于key进行分发

SchedulerBackend通过Executor上的agent ExecutorBackend获取机器上的计算资源信息.ExecutorBackend还负责执行代码

本地倾向性，包括机架感知、节点感知、进程感知，进程感知最高

构建DAG时，会将shuffle之间的一系列RDD操作划分为一个TaskSets，他们之间是有依赖关系的，但是并不需要进行shuffle

TaskScheduler对任务进行调度和分配资源，资源信息WorkOffer来源于SchedulerBackend，任务信息TaskSets来源于TaskScheduler

static变量也是

如果父节点没人引用了，而子节点还有人引用，这时候可能父节点就会直接销毁掉，看起来挺奇怪的

一个地方修改每个引用可见

• 要么一个可变引用
• 要么0个可变引用 + 1或多个不可变引用

这里的drop方法是用于提前清理Drop Trait的

那Box是如何销毁掉堆上的对象的呢？

对于枚举其实和union类似，取需要最大空间的一个类型的空间即可

Box感觉可以理解为Reference

支持上转型？

转移所有权并不会被拷贝，拷贝也不会转移所有权，所以这里是一大堆的数据相互关联，然后通过转移或者拷贝栈上的引用来转移所有权？

由于栈上的数据是需要知道确切大小的，因此如果大小不确定则只能放在堆上，而栈上使用引用

看不懂

由于r和w都超过半数，因此是能够保证写入和读取是最新的