个人总结,仅供参考,从复制来的文档上做点总结

客户端发出请求 hdfs dfs -put /etc/profile /qf/data namenode查看维护的目录结构，检查/qf/data是否存在，如不存在直接报错”no such file or directory“，如存在返回给客户端同意上传文件请求，将操作写入日志文件 客户端请求上传第一个块，询问namenode块的存储位置 namenode查看自己的datanode池，返回给客户端一个datanode列表 客户端发出请求建立pipeline 客户端先把文件写入缓存，达到一个块的大小时,会在客户端和第一个datanode建立连接开始流式的传输数据，这个datanode会一小部分一小部分（4K）的接收数据然后写入本地仓库，同时会把这些数据传输到第二个datanode，第二个datanode也同样一小部分一小部分的接收数据并写入本地仓库，同时传输给第三个datanode… (在流式复制时，逐级传输和响应采用响应队列来等待传输结果。队列响应完成后返回给客户端) 第一个数据块传输完成后会使用同样的方式传输下面的数据块直到整个文件上传完成。 整个文件完成，namenode更新内存元数据

读： 客户端向namenode发起RPC调用，请求读取文件数据。 namenode检查文件是否存在，如果存在则获取文件的元信息（blockid以及对应的datanode列表）。 客户端收到元信息后选取一个网络距离最近的datanode，依次请求读取每个数据块。客户端首先要校检文件是否损坏，如果损坏，客户端会选取另外的datanode请求。 datanode与客户端建立socket连接，传输对应的数据块，客户端收到数据缓存到本地，之后写入文件。 依次传输剩下的数据块，直到整个文件合并完成。

略

Hadoop RPC分为四个部分：

集群中半数以上机器存活，集群可用，所以Zookeeper适合安装奇数台服务器

内部选举步骤： 1. 选举阶段 Leader election 最大ZXID也就是节点本地的最新事务编号，包含epoch和计数两部分。epoch是纪元的意思，相当于Raft算法选主时候的term，标识当前leader周期，每次选举一个新的Leader服务器后，会生成一个新的epoch 所有节点处于Looking状态，各自依次发起投票，投票包含自己的服务器ID和最新事务ID（ZXID）。 如果发现别人的 ZXID比自己大，也就是数据比自己新，那么就重新发起投票，投票给目前已知最大的 ZXID所属节点。 每次投票后，服务器都会统计投票数量，判断是否有某个节点得到半数以上的投票。如果存在这样的节点，该节点将会成为准Leader，状态变为 Leading。其他节点的状态变为Following。 2. 发现阶段 Discovery 为了防止某些意外情况，比如因网络原因在上一阶段产生多个 Leader的情况。 Leader集思广益，接收所有 Follower发来各自的最新 epoch值。 Leader从中选出最大的 epoch，基于此值加1，生成新的 epoch分发给各个 Follower。 各个 Follower收到全新的 epoch后，返回 ACK给 Leader，带上各自最大的 ZXID和历史事务日志。 Leader选出最大的 ZXID，并更新自身历史日志。 3. 同步阶段 Synchronization Leader刚才收集得到的最新历史事务日志，同步给集群中所有的Follower。只有当半数Follower同步成功，这个准Leader才能成为正式的Leader。

略

HDFSSink、KafkaSink、HbaseSink、HiveSink、AvroSink等、

会数据丢失，如果使用内存channel就会有丢失风险，想要数据不丢失的话，要使用FileChannel，或者KafkaChannel来保存数据，也就是说将数据不要用内存传输，使用磁盘落地的方式来发送，这样就不会丢失数据

会数据重复，如果当数据传输sink的时候，集群宕机那么写入一半数据的话，数据后一半会回滚，前一半写入磁盘，再次发送就会重新发送这个批次数据，那么前一半数据就会重复

每次更新数据的时候，都会先把数据记录在提交日志(commit log)中，在 HBase 中，这叫做预写日志(WAL)，然后才会把这些数据写入内存的 Memstore 中。一旦内存保存的写入数据的累计大小超过了一个给定的最大值，系统就会把这些数据移出内存，作为 HFile 文件刷写到磁盘中。数据移出内存后，系统会丢弃对应的提交日志，大小有限，只保留未持久化到磁盘的提交日志。

检索habse的记录首先要通过row key来定位数据行。当大量的client访问hbase集群的一个或少数几个节点，造成少数region server的读/写请求过多、负载过大，而其他region server负载却很小，就造成了“热点”现象。 有大量连续编号的row key，大量row key相近的记录集中在个别region，client检索记录时,对个别region访问过多 ， 此region所在的主机过载，产生热点 加盐、哈希、反转、时间戳反转、尽量减少行和列的大小

Hive和Hbase是两种基于Hadoop的不同技术–Hive是一种类SQL的引擎，并且运行MapReduce任务，HBase是一种在Hadoop之上的NoSQL 的Key/value数据库。当然，这两种工具是可以同时使用的。Hive可以用来进行统计查询，HBase可以用来进行实时查询，数据也可以从Hive写到Hbase，设置再从Hbase写回Hive。

预分区：提前划分region，避免单节点region一次性写入大量数据频繁分裂 二级索引：主要是为了提高查询效率达到秒级查询的目的

增量导入要维护last_value的值,否则怎么知道上次导入的位置呢? 当然,如果注册为job,这个值是可以自动维护的.

可以使用Sqoop中import命令的–as-textfile参数明确指定此文件格式。 Sqoop没有任何内置代码来执行文件压缩。 它依赖Hadoop的压缩设置。

静态分区手动指定,动态分区可以根据数据自动判断.

静态分区 SP（static partition）   1、静态分区是在编译期间指定的指定分区名   2、支持load和insert两种插入方式     2.1load方式       1）会将分区字段的值全部修改为指定的内容       2）一般是确定该分区内容是一致的时候才会使用     2.2insert方式       1）必须先将数据放在一个没有设置分区的普通表中       2）该方式可以在一个分区内存储一个范围的内容       3）从普通表中选出的字段不能包含分区字段   3、适用于分区数少，分区名可以明确的数据 动态分区 DP（dynamic partition）     1、根据分区字段的实际值，动态进行分区   2、是在sql执行的时候进行分区   3、需要先将动态分区设置打开（set hive.exec.dynamic.partition.mode=nonstrict ）   4、只能用insert方式   5、通过普通表选出的字段包含分区字段，分区字段放置在最后，多个分区字段按照分区顺序放置 静态分区与动态分区的主要区别在于静态分区是手动指定，而动态分区是通过数据来进行判断。

分桶是相对分区进行更细粒度的划分。 分桶将整个数据内容安装某列属性值得hash值进行区分，如要按照name属性分为3个桶，就是对name属性值的hash值对3取摸，按照取模结果对数据分桶。 如取模结果为0的数据记录存放到一个文件，取模为1的数据存放到一个文件，取模为2的数据存放到一个文件

•Hive采用了类SQL的查询语言HQL（hive query language）。除了HQL之外，其余无任何相似的地方。Hive是为了数据仓库设计的。 • 存储位置：Hive在Hadoop上；Mysql将数据存储在设备或本地系统中； • 数据更新：Hive不支持数据的改写和添加，是在加载的时候就已经确定好了；数据库可以CRUD； • 索引：Hive无索引，每次扫描所有数据，底层是MR，并行计算，适用于大数据量；MySQL有索引，适合在线查询数据； • 执行：Hive底层是MarReduce；MySQL底层是执行引擎；

创建表时：创建内部表时，会将数据移动到数据仓库指向的路径；若创建外部表，仅记录数据所在的路径， 不对数据的位置做任何改变。 删除表时：在删除表的时候，内部表的元数据和数据会被一起删除， 而外部表只删除元数据，不删除数据。这样外部表相对来说更加安全些，数据组织也更加灵活，方便共享源数据。

• textfile 存储空间消耗比较大，并且压缩的text 无法分割和合并 查询的效率最低,可以直接存储，加载数据的速度最高； • sequencefile 存储空间消耗最大,压缩的文件可以分割和合并 查询效率高，需要通过text文件转化来加载； • orcfile, rcfile存储空间最小，查询的效率最高 ，需要通过text文件转化来加载，加载的速度最低； • parquet格式是列式存储，有很好的压缩性能和表扫描功能

Hive支持的压缩格式为Gzip、Bzip2、lzo、snappy

聚合函数

分析函数 Analytics functions

字符串连接函数

其他函数

等

User-Defined-Function 自定义函数 、一进一出； 自定义udaf函数self_count，实现系统udaf count的功能 User-Defined Table-Generating Functions，要解决一行输入多行输出的问题，用udtf解决一行输入多行输出的不多，往往被lateral view explode+udf等替代实现，比直接用udtf会更简单、直接一些

Group By聚合倾斜：分组的维度过少，每个维度的值过多，导致处理某值的reduce耗时很久；对一些类型统计的时候某种类型的数据量特别多，其他的数据类型特别少。当按照类型进行group by的时候，会将相同的group by字段的reduce任务需要的数据拉取到同一个节点进行聚合，而当其中每一组的数据量过大时，会出现其他组的计算已经完成而这个reduce还没有计算完成，其他的节点一直等待这个节点的任务执行完成，所以会一直看到map 100% reduce99%的情况； 解决办法：

当选项设定为true，生成的查询计划会有两个MR Job。当第一个MR Job中，Map的输出结果结合会随机分布到Reduce中，每个Reduce做部分聚合操作，并输出结果 如果数据量非常大，执行如select a,count(distinct b) from t group by a;类型的sql时，会出现数据倾斜的问题 解决办法： 使用sum…group by代替。如：select a,sum(1) from(select a,b from t group by a,b) group by a; Join问题：当遇到一个大表和一个小表进行join操作时。 解决办法： 使用mapjoin将小表加载到内存中。 如：select /*+ MAPJOIN(a) */ a.c1, b.c1 ,b.c2 from a join b where a.c1 = b.c1;

其他通用配置： • 1-hive.fetch.task.conversion=more;将hive拉取的模式设置为more模式 • 2-hive.exec.mode.local.auto 决定 Hive 是否应该自动地根据输入文件大小，在本地运行（在GateWay运行） ; • 3-hive.auto.convert.join ：是否根据输入小表的大小，自动将 Reduce 端的 Common Join 转化为 Map Join，从而加快大表关联小表的 Join 速度。 默认：false。 • 4-mapred.reduce.tasks ：所提交 Job 的 reduer 的个数，使用 Hadoop Client 的配置。 默认是-1，表示Job执行的个数交由Hive来分配； mapred.map.tasks:设置提交Job的map端个数； • 5-hive.merge.mapredfiles ：是否开启合并 Map/Reduce 小文件，对于 Hadoop 0.20 以前的版本，起一首新的 Map/Reduce Job，对于 0.20 以后的版本，则是起使用 CombineInputFormat 的 MapOnly Job。 默认是：false； • 6-hive.mapred.mode ：Map/Redure 模式，如果设置为 strict，将不允许笛卡尔积。 默认是：‘nonstrict’； • 7-hive.exec.parallel ：是否开启 map/reduce job的并发提交。 默认Map/Reduce job是顺序执行的，默认并发数量是8，可以配置。默认是：false； 8-JVM重用：需要在Hadoop的mapred-site.xml文件中进行配置mapreduce.job.jvm.numtasks的个数即可 9-行列过滤：列处理：在SELECT中，只拿需要的列，如果有，尽量使用分区过滤，少用SELECT *。 行处理：在分区剪裁中，当使用外关联时，如果将副表的过滤条件写在Where后面，那么就会先全表关联，之后再过滤

星型架构是一种非正规化的结构，多维数据集的每一个维度都直接与事实表相连接，不存在渐变维度，所以数据有一定的冗余. 当有一个或多个维表没有直接连接到事实表上，而是通过其他维表连接到事实表上时，雪花模型是对星型模型的扩展。它对星型模型的维表进一步层次化，原有的各维表可能被扩展为小的事实表，形成一些局部的 "层次 " 区域，这些被分解的表都连接到主维度表而不是事实表。通过最大限度地减少数据存储量以及联合较小的维表来改善查询性能。雪花型结构去除了数据冗余。

数据库：传统的关系型数据库的主要应用，主要是基本的、日常的事务处理，例如银行交易。 数据仓库：数据仓库系统的主要应用主要是OLAP（On-Line Analytical Processing），支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。

inmon架构 自上而下的开发模式，从多个数据源出发，根据需求将不同数据源的数据经过ETL过程获取到各个主题需求的数据集成到数仓中，完成了数据治理后再进行统计业务，将统计结果存入数据集市。 kimball架构 自下而上的开发模式，往往已经存在某个关系明确的业务数据库，架构师需要根据数据库中的数据寻找出有价值的分析指标，然后根据这些指标建立数据集市，再从数据集市出发向下建设需要的数据仓库表。

分层作用：复杂问题简单化、减少重复计算、血缘追踪、架构更清晰 ODS：源始数据层；操作型数据层，存放的是从不同来源进入数仓的原始数据，ods层往往只存放少量加工的原始数据，因此这里的数据不是集成的。 DWD：数据细节层。将ods层的数据统一整合后，依照各主题需要将数据拆分存储，常见的星型模型和雪花模型就是在这一层。 DWS：数据服务层。按照范式存储的数据在分析时往往需要进行多表join，这样的分析效率很低，因此需要将dwd层的数据按照分析需求提前进行整合。由于主题之间的重合，该层的设计是反三范式的，存在数据冗余。 DM： 存放使用DW层数据进行业务统计的结果，它们可能被用于线上可视化的指标分析，也可能用于进一步的数据挖掘使用。 DIM: 维度层。有些数仓会将dwd层中的维度表单独抽离出来维护。

Leader：主要是负责进行生产者和消费者的数据接收发送，不管同步操作 Follower：主要是负责同步Leader，还用于leader选举（leader挂了才能选举）

RDB持久化 符合一定条件时redis会将内存中所有数据以二进制方式生成一份副本存储到硬盘上（快照），redis重启时可以通过该副本恢复数据，生成快照时redis进入阻塞状态。 AOF持久化 redis将日志追加到磁盘文件中，redis启动时优先选择从AOF文件恢复数据。由于每次写操作都会记录日志，因此AOF会降低性能，但比起RDB的一次性阻塞式备份数据，AOF消耗的内存和资源更少。 AOF文件达到阀值时（或执行bgrewriteaof命令），会重写一次AOF文件，将每个Key只保留最新的value的日志

1. 内存分为两种：堆内和堆外内存 堆内：指的是我们启动程序后，指的的参数列表就是堆内内存（–executor-memory） 堆内内存分为：存储内存、执行内存、其他内存 堆外：指的是不在我们的分配范围内，需要开启才能使用（spark.memory.offHeap.enabled=true，设置大小spark.memory.offHeap.size=1G） 堆外内存分为：存储内存、执行内存 2. Spark版本划分1.6和2.X以上版本将内存管理分为两大类 静态内存管理模型（1.6）： 如果当程序启动后，我们所分配的内存区域大小不可改变，并且也不可以动态占用对方未使用的内存空间。 堆内： 存储内存：内存空间占用60%，在内部内存当中，会预留出百分之10防止OOM内存溢出 执行内存：内存空间占用20%，在内部内存当中，会预留出百分之20防止OOM内存溢出 其他内存：内存空间占用20% 堆外： 存储内存：占用总的内存的50% 执行内存：占用总的内存的50% 统一内存管理模型（2.0以上）： 与静态内存管理的区别在于存储内存和执行内存共享同一块空间叫做统一内存，可以动态占用对方的空闲区域（动态占用机制） 堆内： 统一内存：占用总内存的60%，内部分为存储内存和执行内存，各占用50% 其他内存：占用总内存的40% 预留内存：固定大小300M 堆外： 统一内存：50% 其他内存：50% 动态占用机制：如果存储内存和执行内存的内存空间都不足了，此时会将数据落盘，如果当我们的执行内存空间有剩余，此时存储空间不足，就会占用执行内存空间，那么如果发生计算，使用执行内存空间，存储内存占用的空间要归还给执行内存，那么这一部分归还的内存存储的数据就会淘汰（当我们的缓存级别设置为内存存储的话，这部分数据就被删除，如果是内存加磁盘的话，就落盘），如果执行内存占用了存储内存，当存储内存空间不足后，有新的存储数据进来，此时执行内存也不会归还内存，这部分数据就要启动淘汰机制（将老的数据删除或者落盘，取决于你的存储级别），总结来说，执行内存级别高于存储内存级别。

Spark Yarn Client向YARN的ResourceManager申请启动Application Master。同时在SparkContent初始化中将创建DAGScheduler和TASKScheduler等，由于我们选择的是Yarn-Client模式，程序会选择YarnClientClusterScheduler和YarnClientSchedulerBackend ResourceManager收到请求后，在集群中选择一个NodeManager，为该应用程序分配第一个Container，要求它在这个Container中启动应用程序的ApplicationMaster，与YARN-Cluster区别的是在该ApplicationMaster不运行SparkContext，只与SparkContext进行联系进行资源的分派 Client中的SparkContext初始化完毕后，与ApplicationMaster建立通讯，向ResourceManager注册，根据任务信息向ResourceManager申请资源（Container） 一旦ApplicationMaster申请到资源（也就是Container）后，便与对应的NodeManager通信，要求它在获得的Container中启动CoarseGrainedExecutorBackend，CoarseGrainedExecutorBackend启动后会向Client中的SparkContext注册并申请Task client中的SparkContext分配Task给CoarseGrainedExecutorBackend执行，CoarseGrainedExecutorBackend运行Task并向Driver汇报运行的状态和进度，以让Client随时掌握各个任务的运行状态，从而可以在任务失败时重新启动任务 应用程序运行完成后，Client的SparkContext向ResourceManager申请注销并关闭自己

Cache持久化操作，主要是用于内存式缓存操作，如果内存充足，可以使用其缓存操作，但是最好设置磁盘加内存，如果程序停止或者宕机，这种方式就失效了 Checkpoint是检查点，用于缓存操作，不过存储的时候磁盘，主要适用于大数据量的数据缓存，如果机器一旦宕机，那么可以通过检查点来恢复数据，相比较缓存性能会低一些，但是比持久化的数据保存更久。

Hash碰撞说白了就是数据倾斜，因为数据使用的是Hash的分区方式，如果将Key转换为HashCode值，那么就有可能有一大批Hash值取余的时候回分配到同一分区，导致这个分区数据过大，那么就会发生数据倾斜 解决办法：使用自定义分区器，不要用默认的HashPartition分区器，自己按照自己的规则去定义分区器，将数据分配到不同的分区即可

第一种设置背压机制，保证程序动态的实时感知数据量大小和资源情况，按照现有的资源进行拉去数据，保证每个批次数据处理不会太大。 第二种增大处理里并行度，提高执行效率和处理速度，这样可以有效解决数据积压问题 第三种进行硬件调整，可以动态的扩容Kafka集群，增加消费节点，保证消费者消费的并行度更大。

HashShuffle：特点是复用缓冲区和本地文件，不需要进行合并小文件操作，而且默认也不用排序，但是这种Shuffle已经退出历史舞台，在1.2以后已经不是默认的shuffle操作了 SortShuffle：分为两种方式（普通机制会默认的排序操作，bypass机制不会排序操作），内部进行shuffle操作的时候和MR的内部shuffle有些类型，也要进行合并小文件的，不使用复用操作，在合并小文件的时候，会根据每一个文件创建对应的索引信息，主要是为了reduce拉去数据的时候找到元数据。

~~使用了receivers来接收数据，利用的是Kafka高层次的消费者api，对于所有的receivers接收到的数据将会保存在spark executors中，然后通过Spark Streaming启动job来处理这些数据，默认会丢失，可启用WAL日志，该日志存储在HDFS上

区别Receiver接收数据，这种方式定期地从kafka的topic+partition中查询最新的偏移量，再根据偏移量范围在每个batch里面处理数据，使用的是kafka的简单消费者api 优点: 简化并行，不需要多个kafka输入流，该方法将会创建和kafka分区一样的rdd个数，而且会从kafka并行读取。 高效，这种方式并不需要WAL，WAL模式需要对数据复制两次，第一次是被kafka复制，另一次是写到wal中 恰好一次语义(Exactly-once-semantics)，传统的读取kafka数据是通过kafka高层次api把偏移量写入zookeeper中，存在数据丢失的可能性是zookeeper中和ssc的偏移量不一致。EOS通过实现kafka低层次api，偏移量仅仅被ssc保存在checkpoint中，消除了zk和ssc偏移量不一致的问题~~

DF:SparkSQL在1.2以后推出的新的特性，它是对RDD的又一次封装，不过使用了SQL解析器，和优化器，然后转换Spark可识别的代码进行运行，其实就是SparkSQL的抽象 DS:是在Spark的1.6以后才推出的新特性，它封装了DF和RDD的特性，Dataframe=DataSet[Row]，也代表了在DS的返回值类型中可以使用任意的类来封装数据，整合了RDD与DF的各个有点，在2.0以后全部是使用的DS来实现 RDD:弹性分布式数据集，是一个不可变，可分区，并行计算的集合，RDD之间存在依赖关系（血缘），有高容错性，并且可以进行持久化。

Foreach：Action算子，进行输出操作，按照每条输出 ForeachPartition：Action算子，进行输出操作，是按照每个分区输出 Map：转换算子，主要是对数据进行转换操作，是对每条数据操作 ForeachRDD：是Dstream的算子，主要是对流进行转换输出操作，将流转换成RDD进行输出

Task是任务，是任务的最小单位，在Job提交后，内部的所有分区都是一个Task，所以Task用来进行计算和保存数据 Job是任务：是任务的最大单位，主要是提交整个任务的程序，也就内部包含了多个Task

弹性分布式数据集，是Spark中的最基本的数据抽象，代表着一个不可变可分区并行计算的集合，相当于一个代理，本身没有数据，代理着元数据信息

Transformation属于转换算子，不进行数据加载

Action是属于执行算子，是触发Job算子，一个Action触发一个Job，并且转换算子需要执行算子来触发任务执行

有向无环图,是Spark的整体的执行程序，内部会进行Stage的划分，分为ShuffleMapStage和ResultStage，并且内部划分Task，Task也分为两种Task，ShuffleMapTask和ResultTask，所有的任务的阶段划分和Task任务划分都在内部执行，是整个程序的核心

参考Spark内核调优文档即可