大数据基础
大数据带来的思维转变
- 全样而非抽样
- 效率而非精确
- 相关而非因果
大数据特征
- Value（价值密度低）
- Velocity（快速化）
- Volume（量大）
- Variety（多样化）
数据度量
- b：比特，一个二进制数字
- B：字节，8比特组成一个字节
- KB：10的3次方
- MB：10的6次方
- GB：10的9次方
大数据的产生阶段
- 运营式系统阶段（数据被动产生）
- 用户原创内容阶段（数据主动产生）
- 感知式系统阶段
科学研究四范式
- 实验
- 理论
- 计算
- 数据探索
大数据计算模式
| 大数据计算模式 | 解决问题 | 代表产品 |
| ——————— | ——————————————— | ———————————- |
| 批处理计算 | 针对大规模数据的批量处理 | Map Reduce、Spark等 |
| 流计算 | 针对流数据的实时计算 | Flume、Storm、Streams等 |
| 图计算 | 针对大规模图结构数据的处理 | Pregel、Graphx等 |
| 查询分析计算 | 大规模数据的存储管理和查询分析 | Hive等 |
按数据响应时间升序排列：
流计算、查询分析计算、批处理计算、图计算大数据技术框架（重要）
- 数据收集：从数据源收集数据
- 数据存储：存储海量结构化与非结构化数据的存储
- 资源管理与服务协调：管理计算资源和协调不同服务之间的交互
- 计算引擎：处理数据集
- 数据分析：从数据中提取有价值的信息洞察
- 数据可视化：将分析结果转换为图表、图形等形式
Hadoop与Spark开源大数据技术栈
数据收集
结构化数据收集-Sqoop
非结构化数据收集-Flume
Flume基本构成
- Flume的数据流是通过一系列称为Agent的组件构成的，一个Agent可从客户端或前一个Agent 接收数据，经过过滤、路由等操作后，传递给下一个或多个Agent(完全分布式)，直到抵达指定的目标系统，用户可根据需要拼接任意多个Agent构成一个数据流水线；
- Flume将数据流水线中传递的数据称为“Event”，每个Event由头部和字节数组(数据内容)两部 分构成；其中，头部由一系列key/value对构成，可用于数据路由，字节数组封装了实际要传 递的数据内容。
Flume Agent基本构成
- Source：Flume数据流中接收Event的组件，通常从Client程序或上一个Agent接收数据，并写入一 个或多个Channel。
- Sink：Sink负责从Channel中读取数据，并发送给下一个Agent。
- Channel：Channel是一个缓存区，它暂存Source写入的Event，直到被Sink发送出去。
多路复用和多路合并（要了解）
分布式消息队列-Kafka
Kafka设计动机（要了解）
存在问题： - 数据生产者和消费者耦合度过高：需要增加一种新的消费者时，所有数据生产者均需要被改动，扩展性非常差。
- 生产者和消费者间数据处理速率不对等
- 大量并发的网络连接对后端消费者不够友好
Kafka设计架构
Kafka是一个分布式消息队列，它将数据分区保存，并将每个分区保存成多份以提高数据可靠性。 - Kafka架构由Producer、Broker和Consumer三类组件构成，其中Producer将数据写入Broker，Consumer则从Broker上读取数据进行处理；Broker构成了连接Producer和Consumer的”缓冲区”，Broker和Consumer通过ZooKeeper做协调和服务发现。
- Kafka架构采用Push-Pull架构（生产者将消息推送到队列中，但消费者不会立即接收消息。相反，消费者在自己的节奏下拉（pull）消息），即Producer将数据直接”push”给Broker，而Consumer从Broker端”pull”数据，这种架构优势主要体现在以下两点:
- ELK Stack是三个开源产品的集合 - Elasticsearch， Logstash和Kibana。它们都由Elastic公司开发，管理和 维护。
- E代表ElasticSearch：是 ELK Stack 的核心组件，负责在数据上执行复杂的查询操作。
- L代表LogStash：数据采集和传输工具。
- K代表Kibana：是一个用于Elasticsearch数据的可视化工具。
网络爬虫抓取策略
- 宽度优先策略：将新下载的网页包含的URL追加到待抓取队列的末尾。
- 反向链接数策略： 反向链接数是指一个网页被其他网页链接指向的数量。反向链接数表示的是一个网页的内容受到其他人推荐的程度。因此，很多时候搜索引擎的抓取系统会使用这个指标来评价网页的重要程度，从而决定不同网页的抓取顺序。
- PartialPageRank策略：借鉴了PageRank策略的思想：对于已经下载的网页，连同待抓取URL队列中的URL，形成网页集合， 计算每个页面的PageRank值;计算完成后，将待抓取URL队列中的URL按照PageRank值的大小排列,并 照该顺序抓取页面。
- OPIC策略（Online page importance calculation）：该策略实际上也是对页面进行重要性进行评分。初始时给所有页面一个相同的初始现金（cash）。当 下载了某个页面P后，将P的现金分摊给所有从P中分析出的链接，并且将P的现金清空。然后对于待抓取URL队列中的所有页面，按照现金数进行排列。
- 大站优先策略：对于待抓取URL列表中的所有网页，根据所属的网站进行分类；对于待下载页面较多的网站，则优先下载。
数据存储
数据序列化
数据序列化：将数据对象转化为字节流。文件存储格式
常见的存储格式包括行式存储和列式存储两种：行式存储以文本格式Text File、key/value，二进制存储格式Sequence File为典型代表；列式存储以ORC、Parquet和Carbon Data三种文件格式为代 表。行存储与列存储的区别（重要）
行存储以行为单位进行存储，读写过程是一致的，都是连续读取或写入同一行的所有列；列存储写数据时将数据拆分成列，并以列为单位存储（相同列存储在一起），读数据时，分别读取对应的列，并拼装成行。下表是行列存储优缺点对比：
分布式文件系统
横向扩展和纵向扩展
- 纵向扩展(scale-up)：利用现有的存储系统，通过不断增加存储容量来满足数据增长的需求
- 简单，低延迟
- 无法无限扩展，成本较高，容错性较低
- 横向扩展(scale-out)：以网络互连的节点为单位扩大存储容量(集群)
- HDFS属于块级别的分布式文件系统
- HDFS采用了主从架构，如图所示，主节点被称为NameNode，只有一个，管理元信息和所有从节点；从节点称为DataNode，通常存在多个，存储实际的数据块。
- 数据的分块操作在client上完成
HDFS容错性设计
- NameNode故障： NameNode内存中记录了文件系统的元信息，这些元信息一旦丢失，将导致整个文件系统数据不可用。HDFS允许为每个Active NameNode分配一个Standby NameNode ，以防止单个 NameNode宕机后导致元信息丢失和整个集群不可访问。
- DataNode故障：每个DataNode保存了实际的数据块，这些数据块在其他DataNode上存在相同的副本。 DataNode 能通过心跳机制向NameNode汇报状态信息，当某个DataNode宕机后，NameNode可在其他节点上重构该DataNode上的数据块，以保证每个文件的副本数在正常水平线上。
- 数据块损坏： DataNode保存数据块时，会同时生成一个校验码。当存取数据块时，如果发现校验码不一致则认为该数据块已经损坏，NameNode会通过其他节点上的正常副本重构受损的数据块。
NoSQL数据库
| 比较标准 | 关系型数据库 | NoSQL |
| —— | —— | —— |
| 查询方式 | SQL | UnQL |
| 数据完整性 | 容易实现 | 很难实现 |
| 一致性 | 强一致性 | 弱一致性 |CAP
C（Consistency）：一致性，任何一个读操作总是能读到之前完成的写操作的结果。
A（Availability）：可用性，是指快速获取数据，可以再确定的时间内返回操作结果，保证每个请求不管成功或者失败都有相应。
P（Partition Tolerance）：分区容错性，是指当出现网络分区的情况时（即系统中的一部分节点无法和其他节点进行通信），分离的系统也能够正常运行，也就是说，系统中任意信息的丢失或失败不会影响系统的继续运作。
CAP理论的核心是：一个分布式系统不可能同时很好的满足一致性，可用性和分区容错性这三个需求，最多只能同时较好的满足两个。
根据CAP原理，将NoSQL数据库分成满足CA原则、CP原则和AP原则三大类： - CA ：单点集群，满足一致性，可用性的系统，通常在可扩展性上不太强大。（传统数据库）
- CP ：满足一致性，分区容错性的系统，通常性能不是特别高。（Redis、MongoDB）
- AP ：满足可用性，分区容错性的系统，通常可能对一致性要求低一些。（大多数的选择）
BASE模型
关系型数据库（如MySQL、Oracle）通过了严格的ACID测试。 - 原子性（Atomicity）：单个事务为一个不可分割的最小工作单元
- 一致性（Consistency）
- 隔离性（Isolation）：一个事务所做的修改在最终提交以前，对其他事务是不可见的
- 持久性（Durability）：一旦事务提交，所作的修改就会永久保存到数据库中。
BASE模型反ACID模型，基本含义是本基本可用（Basically Availability）、软状态（Softstate）和最终一致性（Eventual consistency）。
最终一致性
对于关系型数据库，强一致性要求更新过的数据能被后续的访问都能看到。如果能容忍后续的部分或者全部访问不到，则是弱一致性。如果经过一段时间后要求能访问到更新后的数据，则是最终一致性。
NoSQL数据库类型
- Key-Value型（Redis:开源、基于内存、可持久化）
- Key-Column型（BigTable、HBase）
- Key-Document模型（MongoDB）
- 图模型（Neo4j:基本概念包含节点、属性、关系、标签）
HBase
- 列簇式存储引擎：同一列簇中的数据会单独存储，但列簇内数据是行式存储的。
- 每个列簇包含了一组相关的列，这些列通常一起被查询。
- 列簇式存储提供了高效的读写性能，灵活的数据模型，有效的数据压缩，以及优化的查询性能。
HBase逻辑数据模型
HBase物理数据存储
HBase基本架构
HBase采用了经典的master/slave架构，与HDFS不同的是，它的master与slave不直接互连，而是通过 引入ZooKeeper让两类服务解耦。 - HMaster：HMaster可以存在多个，主HMaster由ZooKeeper动态选举产生，当主HMaster出现故障后， 系统可由ZooKeeper动态选举出的新HMaster接管。
- 协调RegionSever
- 元信息管理
- RegionServer：
- 单个Region的存储和管理（比如Region切分）
- 与Client交互， 处理读写请求。
- ZooKeeper：
- 保证任何时候，集群中只有一个HMaster
- 存储所有Region的寻址入口
- 实时监控RegionServer的上线和下线信息，并实时通知给HMaster
- 存储HBase的schema和table元数据
- Client：
- 提供HBase访问接口
- 与RegionServer交互读写数据
- 维护cache加快对HBase的访问速度
Region定位
RegionServer内部关键组件
为什么需要WAL？（其实就是说一下WAL的功能）
为什么HBase要存储多版本的数据？
数据本身有时效性，但历史数据也有价值。多版本数据按照TimeStamp降序排列（新的数据在前）分布式列式存储系统Kudu
Kudu是一个强类型的纯列式存储数据库。
完全的列式存储引擎，表中的每一列数据都是存放在一起，列与列之间都是分开的。资源管理与服务协调
ZooKeepr
Zookeeper提供基于类似于文件系统的目录节点树方式的数据存储，主要是用来维护和监控你存储的数据的状态变化。通过监控这些数据状态的变化，从而可以达到基于数据的集群管理。
ZooKeeper服务通常由奇数个ZooKeeper实例构成，其中一个实例为leader角色，其他为follower角色，它们同时维护了层级目录结构的一个副本，并通过ZAB ( ZooKeeper Atomic Broadcast)协议维持副本之间的一致性。
为什么zookeeper通常由奇数个实例构成？
2n+1个节点和2n+2个节点的容错数均为n个节点：该协议规定，只要多数ZooKeeper实例写成功，就认为本次写是成功的。这意味着，如果一个集群中存在2N+1个ZooKeeper实例，只要其中N+1个实例写成功，则本次写操作是成功的，从容错性角度看，这种情况下，集群的最大容忍失败实例数目为N。由于ZAB协议要求多数写成功即可返回，因此2N+1和2N+2个节点的集群具备的容错能力是相同的(最大容忍失败实例数均为N)，这是建议ZooKeeper部署奇数个实例的最主要原因。
- 当leader出现故障时，ZooKeeper会通过ZAB协议发起新一轮的leader投票选举，保证集群中始终有一个可用的leader。
- ZooKeeper中多个实例中的内存数据并不是强一致的，它采用的ZAB协议只能保证，同一时刻至少多数节点中的数据是强一致的。为了让客户端读到最新的数据，需给对应的ZooKeeper实例发送同步指令（可通过调用sync接口实现），强制其与leader同步数据。
- 为了解决集群扩展性导致写性能下降的问题，ZooKeeper引入了第三个角色：Observer。
- Observer并不参与投票过程，除此之外，它的功能与follower类似：它可以接入正常的ZooKeeper集群，接收并处理客户端读请求，或将写请求进一步转发给leader处理。由于Observer自身能够保存一份数据提供读服务，因此可通过增加Observer实例数提高系统的读吞吐率。由于Observer不参与投票过程，因此它出现故障并不会影响ZooKeeper集群的可用性。
负载均衡是对?的负载均衡
Kafka中的负载均衡是对leader partition的负载均衡Yarn
MapReduce1.0的局限性
无法支持多种计算框架；JobTracker处理作业调度和资源管理，在大规模集群环境中成为性能瓶颈。
- Yarn总体上采用master/slave架构，其中，ResourceManager为master，NodeManager为slave, ResourceManager负责对各个NodeManager上的资源进行统一管理和调度。
- 当用户提交一个应用程序时，需要提供一个用以跟踪和管理这个程序的ApplicationMaster，它负责向ResourceManager申请资源，并要求NodeManager启动可以占用一定资源的任务，由于不同的ApplicationMaster被分布到不同的节点上，因此它们之间不会相互影响。
Yarn各组件
ResourceManager (RM) ：是一个全局的资源管理器，负责整个系统的资源管理和分配。由两个组件构成：调度器(Scheduler) 和应用管理器(Applications Manager, ASM) - a)调度器： 主要功能是根据资源容量，队列等方面的限制条件，将系统中的资源分配给各个应用程序。
- b)应用管理器：负责管理整个系统中的所有应用程序。
ApplicationMaster (AM) ：用户提交的每个应用程序均包含一个独立的AM,其主要功能包括： - 与RM调度器协商以获取资源（用Container表示）。
- 将得到的资源进一步分配给内部的任务。
- 与NodeManager通信以启动/停止任务。
- 监控所有任务的运行状态，并在任务运行失败时重新为任务申请资源以重启任务。
NodeManager (NM) ： NM是每个节点上的资源管理器。 - 会定时地向RM汇报本节点上的资源使用情况和各个Container的运行状态。
- 接收并处理来自AM的任务启动/停止等各种请求。在一个集群中，NM通常存在多个，由于YARN内置了容错机制，单个NM的故障不会对集群中的应用程序运行产生严重影响。
Container ： 是Yarn中的基本资源分配单位，是对应用程序运行环境的抽象，并为应用程序提供资源隔离环境。Yarn高可用性
YARN提供了恢复机制，这使得YARN在服务出现故障或人工重启时，不会对正在运行的应用程序产生任何影响。
a)ResourceManager HA（High Availability）
• 为了避免ResourceManager故障导致整个集群不可用，YARN引入了Active/Standby ResourceManager ，通过冗余方式解决ResourceManager单点故障。
• 当Active ResourceManager 出现故障时，Standby ResourceManager 可通过ZooKeeper选举成为Active ResourceManager并通过ResourceManager Recovery机制恢复状态。
b)ResourceManager Recovery
•ResourceManager内置了重启恢复功能，当ResourceManager就地重启，或发生Active/Standby切换时，不会影响正在运行的应用程序运行。主要流程为：保存元信息、加载元信息、重构状态信息。Yarn工作流程
YARN的工作流程分为以下几个步骤：
1）提交应用程序：用户通过客户端与YARN ResourceManager通信，以提交应用程序，应用程序中需包含ApplicationMaster可执行代码、启动命令和资源需求、应用程序可执行代码和资源需求、优先级、提交到的队列等信息。
2）启动ApplicationMaster： ResourceManager为该应用程序分配第一个Container,并与对应的NodeManager通信，要求它在这个Container中启动应用程序的ApplicationMaster之后ApplicationMaster的生命周期直接被ResourceManager管理。
3） ApplicationMaster注册： ApplicationMaster启动后，首先，向ResourceManager注册，这样，用户可以直接通过ResourceManage查看应用程序的运行状态，然后，它将初始化应用程序，并按照一定的策略为内部任务申请资源，监控它们的运行状态，直到运行结束，即重复步骤4~7。
4） 资源获取: ApplicationMaster采用轮询的方式通过RPC协议向ResourceManager申请和领取资源。
5） 请求启动Container ：一旦ApplicationMaster申请到资源后，则与对应的NodeManager通信，请求为其启动任务（NodeManager会将任务放到Container中）。
6）启动Container：NodeManager为任务设置好运行环境(包括环境变量、jar包、二进制程序等)后，将任务启动命令写到一个脚本中，并通过ContainerExecutor运行该脚本启动任务。
7） Container监控：ApplicationMaster可通过两种方式获取各个Container的运行状态，以便在任务失败时重新启动任务。
•ApplicationMaster与ResourceManager间维护了周期性心跳信息，每次通信可获取自己分管的Container的运行状态。
•各个Container可通过某个RPC协议向ApplicationMaster汇报自己的状态和进度。
8）注销ApplicationMaster：应用程序运行完成后，ApplicationMaster 向ResourceManager注销，并退出执行。资源管理系统结构演化
- 中央式调度器架构（类似于Hadoop JobTracker，但是支持多种类型作业调度）：一个中央调度器负责所有的资源管理和任务调度决策。
- 双层调度器架构（类似于Mesos和YARN）：首先由一个全局调度器进行资源分配，然后由每个框架的内部调度器进行具体的任务调度。
- 共享状态架构（Omega）：所有调度决策都基于共享的资源状态信息，多个调度器可以并行工作，都可以访问共享的资源状态信息。
计算引擎
批处理引擎MapReduce
MapReduce编程模型
MapReduce模型的目的是为了简化分布式数据处理，它是对大量分布式处理问题的总结和抽象，核心思想是分而治之，即将一个分布式计算过程拆解成两个阶段：
- 第一阶段：Map阶段，由多个可并行执行的Map Task构成，主要功能是，将待处理数据集按照数据量大小切分成等大的数据分片，每个分片交由一个任务处理。
- 第二阶段：Reduce阶段，由多个可并行执行的Reduce Task构成，主要功能是，对前一阶段中各任务产生的结果进行规约，得到最终结果。
编程组件
Hadoop MapReducer对外提供了5个可编程组件，分别是InputFormat、Mapper、Partitioner、Reducer和OutputFormat，其中Mapper和Reducer跟应用程序逻辑相关，因此必须由用户编写。InputFormat
InputFormat主要用于描述输入数据的格式，它提供以下两个功能： - 数据切分：按照某个策略将输入数据切分成若干个split，以便确定Map Task个数以及对应的split。
- 为Mapper提供输入数据：给定某个split，能将其解析成一系列
Mapper
Mapper中封装了应用程序的数据处理逻辑，为了简化接口，MapReduce要求所有存储在底层分布式文件系统上的数据均要解释成Partitioner
Partitioner的作用是对Mapper产生的中间结果进行分片，以便将同一组的数据交给同一个Reducer处理，它直接影响Reduce阶段的负载均衡。Reducer
Reducer主要作用是，基于Mapper产生的结果进行规约操作，产生最终结果。OutputFormat
OutputFormat主要用于描述输出数据的格式，它能够将用户提供key/value对写入特定格式的文件中。Combiner
Combiner是一个可选的性能优化组件，可看作Map端的local reducer。它通常跟Reducer的逻辑是一样的，运行在Map Task中，主要作用是，对Mapper输出结果做一个局部聚集，以减少本地磁盘写入量和网络数据传输量，并减少Reducer计算压力。关键技术
- 数据本地性，即MRAppMaster会尽量将Map Task调度到它所处理的数据所在的节点，减少网络传输开销。
- 推测执行，根据一定的法则推测出“拖后腿”的任务，并为这样的任务启动一个备份任务，让该任务与原始任务同时运行，最终选用最先成功运行完成任务的计算结果作为最终结果。
DAG计算引擎Spark
Spark是一个高性能DAG（Directed Acyclic Graph）计算引擎，它通过引入RDD（Resili-ent Distributed Datasets，弹性分布式数据集）模型，使得Spark具备类似MapReduce等数据流模型的容错特性，并且允许开发人员在大型集群上执行基于内存的分布式计算。Spark产生背景（MapReduce局限性）
- MapReduce一个最大的问题是在很多应用场景中速度非常慢，只适合离线的计算任务。
- 仅支持Map和Reduce两种操作：MapReduce提供的编程接口过于低层次，这意味着，开发者即使仅完成一些常用功能，仍需编写大量代码，且可能需要实现多个Mapper和Reducer并进行组装，这大大增加了开发工作量。
- 处理效率低效：任务调度和启动开销大、无法充分利用内存、Map端和Reduce端均需要排序和复杂功能磁盘IO开销大等。
- 不适合迭代式和交互式计算：MapReduce是一种基于磁盘的分布式计算框架，它追求的是高吞吐率，而性能较为低效，这使得它不适合迭代式和交互式计算。
Spark中有两个核心概念：RDD（Resilient Distributed Datasets）和DAG（Directed Acyclic Graph）。RDD
RDD：Spark提出了一个数据集抽象概念RDD，即弹性分布式数据集，它是一个只读的、带分区的数据集合，并支持多种分布式算子。
作用在RDD上的操作（或称为“算子”）主要分为两类：transformation和action，他们的作用如下： - transformation：即“转换”，其主要作用是将一种RDD转换为另外一类RDD，比如通过“增加1”的转换方式将一个RDD[Int]转换成一个新的RDD[Int]。常用的transformatin操作包括map，filter，groupByKey等。
- action：即“行动”，其主要作用是通过处理RDD得到一个或一组结果，比如将一个RDD[Int]中所有元素值加起来，得到一个全局和。常用的action包括saveAsTextFile，reduce，count等。
DAG
Spark是一个通用DAG引擎，这使得用户能够在一个应用程序中描述复杂的逻辑，以便于优化整个数据流（比如避免重复计算等），并让不同计算阶段直接通过本地磁盘或内存交换数据（而不是像MapReduce那样通过HDFS）。
如图展示同一SQL语句分别翻译成MapReduce和Spark后产生的DAG数据流。如果翻译成MapReduce，则会对应四个有依赖关系的作业，它们之间通过HDFS交换数据；而翻译成Spark则简单很多，只需要一个应用程序，其内部不同计算单元通过本地磁盘或内存交换数据（读写HDFS要比读写本地磁盘和内存慢很多），这使得磁盘和网络IO消耗更小，性能更加高效。
Spark运行基本流程
Spark程序基本框架
- 每个Spark应用程序的运行时环境是由一个Driver进程和多个Executor进程构成的，它们运行在不同机器上（也可能其中几个运行在同一个机器上，具体取决于资源调度器的调度算法），并通过网络相互通信。
- Driver进程运行用户程序（main函数），并依次经历逻辑计划生成、物理计划生成、任务调度等阶段后，将任务分配到各个Executor上执行。
- Executor进程是拥有独立计算资源的JVM实例，其内部以线程方式运行Driver分配的任务。
如图展示了一个Spark应用程序的运行时环境，该应用程序由1个Driver和3个Executor（可能分布到不同节点上）构成，每个Executor内部可同时运行4个任务：
Spark作业生命周期
- 生成逻辑计划：将用户程序直接翻译成DAG。
- 生成物理计划：根据前一阶段生成的DAG，按照一定的规则进一步将之划分成若干Stage，其中 每个Stage由若干个可并行计算的任务构成。
- 调度并执行任务：按照依赖关系，调度并计算每个Stage。对于给定的Stage，将其对应的任务调度给多个Executor同时计算。
Spark生态系统
流计算引擎Storm
目前常用的流式实时计算引擎分为两类：面向行和面向微批处理。
• 面向行的流式实时计算引擎的代表是Apache Storm，其典型特点是延迟低，但吞吐率也低。
• 面向微批处理的流式实时计算引擎的代表是Spark Streaming， 其典型特点是延迟高，但吞吐率也高。
可靠性机制
Spark Streaming
Flink
窗口类型（5种）
- 会话窗口
- 翻滚计数窗口
- 翻滚时间窗口
- 滑动计数窗口
- 滑动时间窗口
图计算Pregel
Pregel计算过程
- 在Pregel计算过程中，一个算法什么时候可以结束，是由所有顶点的状态决定的
- 在第0个超步，所有顶点处于活跃状态，都会参与该超步的计算过程
- 当一个顶点不需要继续执行进一步的计算时，就会把自己的状态设置为 “停机”，进入非活跃状态
- 一旦一个顶点进入非活跃状态，后续超步中就不会再在该顶点上执行计算，除非其他顶点给该顶点发送消息把它再次激活
- 当一个处于非活跃状态的顶点收到来自其他顶点的消息时，Pregel计算框架必须根据条件判断来决定是否将其显式唤醒进入活跃状态
- 当图中所有的顶点都已经标识其自身达到“非活跃（inactive）”状态，并且没有消息在传送的时候，算法就可以停止运行
