Spark零碎知识点

RDD的概念：
RDD（Resilient Distributed Dataset）叫做分布式数据集，是Spark中最基本的数据抽象，它代表一个不可变、可分区、里面的元素可并行计算的集合。RDD具有数据流模型的特点：自动容错、位置感知性调度和可伸缩性。RDD允许用户在执行多个查询时显式地将工作集缓存在内存中，后续的查询能够重用工作集，这极大地提升了查询速度。

个人注释（非官方）：
自动容错：为了提高计算效率，在shuffle前实现容错只需要把丢失的分区对应的父RDD分区进行重新计算即可，但如果是shuffle后的分区数据丢失，此时就需要将整个父RDD分区调用shuffle算子进行重新计算。RDD的容错就是指的是RDD分区的恢复过程，和Worker宕机无关。
位置感知：就是把具体的计算逻辑传到对应的数据节点上进行计算，可以有效避免发生大量网络IO。
可伸缩性：即自动容错。

RDD的属性

1）一组分片（Partition），即数据集的基本组成单位。对于RDD来说，每个分片都会被一个计算任务处理，并决定并行计算的粒度。用户可以在创建RDD时指定RDD的分片个数，如果没有指定，那么就会采用默认值。默认值就是程序所分配到的CPU Core的数目。

2）一个计算每个分区的函数。Spark中RDD的计算是以分片为单位的，每个RDD都会实现compute函数以达到这个目的。compute函数会对迭代器进行复合，不需要保存每次计算的结果。

3）RDD之间的依赖关系。RDD的每次转换都会生成一个新的RDD，所以RDD之间就会形成类似于流水线一样的前后依赖关系。在部分分区数据丢失时，Spark可以通过这个依赖关系重新计算丢失的分区数据，而不是对RDD的所有分区进行重新计算。

4）一个Partitioner，即RDD的分片函数。当前Spark中实现了两种类型的分片函数，一个是基于哈希的HashPartitioner，另外一个是基于范围的RangePartitioner。只有对于key-value的RDD，才会有Partitioner，非key-value的RDD的Parititioner的值是None。Partitioner函数不但决定了RDD本身的分片数量，也决定了parent RDD Shuffle输出时的分片数量。

5）一个列表，存储存取每个Partition的优先位置（preferred location）。对于一个HDFS文件来说，这个列表保存的就是每个Partition所在的块的位置。按照“移动数据不如移动计算”的理念，Spark在进行任务调度的时候，会尽可能地将计算任务分配到其所要处理数据块的存储位置。

---

groupByKey和reduceByKey的区别
reduceByKey会先进行局部聚合，再进行全局聚合，这样会在全局聚合时减少网络IO，起到优化作用。所以，能用reduceByKey的情况，尽量用reduceByKey。

---

---

checkpoint的应用场景：
在应用程序执行过程中，有时候某些RDD的数据需要在其他地方多次用到（包括其他job中用到），
为了使得整个依赖链条不至于很长导致执行缓慢，可以用checkpoint来缩短依赖链条。
最好把数据checkpoint到HDFS，保证了数据的安全性，便于在用数据的时候进行拉取。

执行过程：
在代码层面是这样执行的，如果用到某个RDD的数据的时候，首先会检查是否做了缓存，如果做了缓存，会直接从缓存里面取数据，
如果没有做缓存，则判断是否做了checkpoint，如果做了checkpoint，则从checkpoint的指定路径下获取数据，
如果没有checkpoint，只能从新计算得到数据。

checkpoint的具体实现步骤：
1、设置一个checkpoint的目录
sc.setCheckpointDir(“hdfs://node01:9000/cp-20190105-1”)
2、把要checkpoint的RDD的数据进行cache
rdd.persist
3、checkpoint
rdd.checkpoint

最后在调用action算子的时候才会统一地进行cache和checkpoint，
而且该实现步骤是用于离线实现过程中的

查看是否做了checkpoint：rdd.isCheckpointed
查看checkpoint的存储目录：rdd.getCheckpointFile

---

map和mapPartitions的区别：
map是处理RDD里的每个元素，mapPartitions是用于处理RDD的每个分区的

map和foreach的区别：
1、map是有返回值的，foreach没有返回值
2、map常用于将某个RDD做元素的处理，而foreach常用于作为结果的输出到其他的存储系统中
3、map是属于transformation，foreach属于action

foreach和foreachPartition区别：
foreach是针对于RDD的每个元素来操作的，foreachPartition是针对于RDD的每个分区进行操作的
从优化层面讲：foreachPartition用于存储大量结果数据的场景，可以一个分区对应一个数据库的连接，这样就可以减少很多数据库的连接
rdd.foreachPartition(partition => {
val conn = … // 数据库连接
partition.foreach( // 进行存储)
})

---

stage划分过程

---

广播变量：
如果需要将Driver端的某个变量的值在Executor端多次使用，
可以将Driver端的某个变量的值以广播的方式传给多个Executor端，
Exeutor端在使用该值的时候就可以不经过网络IO从Driver端获取，而是直接从本地的缓存读取该值即可
这样既可以减少网络IO，又可以节省缓存（因为一个Executor只存一份广播变量就可以了），

广播过来的值会保存到Executor端的BlockManager

注意：
广播变量不可以广播RDD，因为RDD不会封装具体的值，而广播变量只能广播确切的值。
广播变量的值不易太大，如果太大，会把Executor端的缓存占用太多而导致计算时的内存太少而导致计算速度太慢或出现oom。
广播变量只能在Driver端定义，不能再Executor端定义。

---

Spark的Shuffle过程：
shuffle操作，是在Spark操作中调用了一些特殊的算子才会触发的一种操作，
shuffle操作，会导致大量的数据在不同的节点之间进行传输，
因此，shuffle过程是Spark中最复杂、最消耗性能的一种操作

比如：reduceByKey算子会将上一个RDD中的每个key对应的所有value都聚合成一个value，然后生成一个新的RDD，
新的RDD的元素类型就是的格式，每个key对应一个聚合起来的value，
在这里，最大的问题在于，对于上一个RDD来说，并不是一个key对应的所有的value都在一个partition中的，
更不太可能key的所有value都在一个节点上，
对于这种情况，就必须在集群中将各个节点上同一个key对应的values统一传输到一个节点上进行聚合处理，
这个过程势必会发生大量的网络IO。

shuffle过程中会发生shuffle write和shuffle read，
shuffle write：在map task端会发生shuffle write，把要shuffle的数据写到磁盘的过程，为什么要写到磁盘？
主要是为了避免shuffle的数据太大而占用内存太大导致oom，其次把数据存储到磁盘保证了数据的安全性
shuffle read：在reduce task端发生shuffle read，是指下游RDD读取上游RDD的过程，也就是reduce task读取并合并的过程

在进行一个key对应的values的聚合时，
首先，上一个stage的每个map task就必须保证将自己处理的当前分区中的数据相同key写入一个分区文件中，
可能会多个不同的分区文件，
接着下一个stage的reduce task就必须从上一个stage的所有task所在的节点上，
将各个task写入的多个分区文件中找到属于自己的分区文件，
然后将属于自己的分区数据拉取过来，
这样就可以保证每个key对应的所有values都汇聚到一个节点上进行处理和聚合，
这个过程就称之为shuffle！！！

shuffle过程中的分区排序问题
默认情况下，shuffle操作是不会对每个分区中的数据进行排序的

如果想要对每个分区中的数据进行排序，可以使用三种方法：
1、使用mapPartitions算子把每个partition取出来进行排序
2、使用repartitionAndSortWithinPartitions（该算子是对RDD进行重分区的算子），在重分区的过程中同时就进行分区内数据的排序
3、使用sortByKey对所有分区的数据进行全局排序

以上三种方法，mapPartitions代价比较小，因为不需要进行额外的shuffle操作，
repartitionAndSortWithinPartitions和sortByKey可能会进行额外的shuffle操作，因此性能并不是很高

会导致shuffle的算子
1、byKey类的算子：比如reduceByKey、groupByKey、sortByKey、aggregateByKey、combineByKey
2、repartition类的算子：比如repartition（少量分区变成多个分区会发生shuffle）、repartitionAndSortWithinPartitions、coalesce（需要指定是否发生shuffle）、partitionBy
3、join类的算子：比如join（先groupByKey后再join就不会发生shuffle）、cogroup
注意：首先对于上述操作，能不用shuffle操作，就尽量不用，尽量使用不发生shuffle的操作。
其次，如果使用了shuffle操作，那么肯定要进行shuffle的调优，甚至是解决遇到的数据倾斜问题。

shuffle操作是spark中唯一最消耗性能的过程
因此也就成了最需要进行性能调优的地方，最需要解决线上报错的地方，也就是唯一可能出现数据倾斜的地方

为了实时shuffle操作，spark才有stage的概念，在发生shuffle操作的算子中，需要进行stage的划分
shuffle操作的前半部分，属于上一个stage的范围，通常称之为map task，
shuffle操作的后半部分，属于下一个stage的范围，通常称之为reduce task，
其中map task负责数据的组织，也就是将同一个key对应的value都写入同一个下游task对应的分区文件中，
其中reduce task负责数据的聚合，也就是将上一个stage的task所在的节点上，将属于自己的各个分区文件都拉取过来进行聚合

map task会将数据先保存在内存中，如果内存不够时，就溢写到磁盘文件中，
reduce task会读取各个节点上属于自己的分区磁盘文件到自己节点的内存中进行聚合。

由此可见，shuffle操作会消耗大量的内存，因为无论是网络传输数据之前还是之后，
都会使用大量内存中数据结构来实施聚合操作，
在聚合过程中，如果内存不够，只能溢写到磁盘文件中去，
此时就会发生大量的网络IO，降低性能。

此外，shuffle过程中，会产生大量的中间文件，也就是map side写入的大量分区文件，
这些文件会一直保留着，直到RDD不再被使用，而且被gc回收掉了，才会去清理中间文件，
这主要是为了：如果要重新计算shuffle后RDD，那么map side不需要重新再做一次磁盘写操作，
但是这种情况下，如果在应用程序中一直保留着对RDD的引用，
导致很长的时间以后才会进行回收操作，
保存中间文件的目录，由spark.local.dir属性指定

所以，spark性能的消耗体现在：内存的消耗、磁盘IO、网络的IO

task的生成，一定是在stage范围内，不会跨越stage
task的数量可以这样计算：RDD分区的数量乘以stage的数量（必须是没有重分区的操作）

---

spark shuffle的参数优化
主要考虑在map task和reduce task上，以及它们之间数据传输上进行优化。
比如：
spark.reducer.maxSizeInFlight=48m，reduce task的buffer缓冲，代表了每个reduce task每次能够拉取的map side数据最大大小，如果内存充足，可以考虑加大，从而减少网络传输次数，提升性能。
spark.shuffle.file.buffer=32k，map side task的内存buffer大小，写数据到磁盘文件之前，会先保存在缓冲中，如果内存充足，可以适当加大，从而减少map side磁盘IO次数，提升性能。

spark.shuffle.spill=true，当reduce side的聚合内存使用量超过了spark.shuffle.memoryFraction指定的比例时，就进行磁盘的溢写操作。
spark.shuffle.memoryFraction=0.2，如果spark.shuffle.spill属性为true，那么该选项生效，代表了executor内存中，用于进行shuffle reduce side聚合的内存比例，默认是20%，如果内存充足，建议调高这个比例，给reduce聚合更多内存，避免内存不足频繁读写磁盘。
spark.shuffle.spill.compress=true，同上，进行磁盘溢写时，是否进行文件压缩，使用spark.io.compression.codec属性指定的压缩器，默认是snappy，速度优先。

spark.shuffle.io.retryWait=5s，每次重试拉取数据的等待间隔，默认是5s，建议加大时长，理由同上，保证shuffle操作的稳定性。

spark.shuffle.io.numConnectionsPerPeer=1，机器之间的可以重用的网络连接，主要用于在大型集群中减小网络连接的建立开销，如果一个集群的机器并不多，可以考虑增加这个值。

spark.shuffle.io.preferDirectBufs=true，启用堆外内存，可以避免shuffle过程的频繁gc，如果堆外内存非常紧张，则可以考虑关闭这个选项。
等等。

---

Accumulator累加器:
比如需要对Driver端的某个变量做累加操作，累加说的是，数值的相加或字符串的拼接。
如果直接用foreach是实现不了的，因为该算子无法把executor累加的结果聚合到Driver端的。
可以用Accumulator累加器来实现累加的操作。

注意：
1、Accumulator只能实现累加，而且只能实现为Driver端的变量做累加。
2、Executor端是无法读取累加的值的，只能Driver端读取。

调用上下文中的accumulator方法可以实现累加（sc.accumulator(0)），但该方法在spark2.0版本后是过期方法。
2.0之后需要我们自定义Accumulator，必须继承AccumulatorV2，重写几个方法。

---

spark sql：
spark2.0以后，我们操作的sql的对象为DataSet，
DataFrame只是DataSet [Row] (Row类型是弱类型的)
DataSet有弱类型（untyped）和强类型（typed）

SparkSession作为新版本的上下文，可以用在sql和streaming中，
SparkSession把SQLContext和HiveContext整合到了一起

spark2.0之前的sql是不支持开窗函数和子查询的，2.0之后实现了sql2003标准，开始支持了
如果在2.0之前需要实现开窗函数和子查询，需要用Hive-On-Spark来实现

spark2.0可以支持csv格式数据的输入和输出

spark sql生成的默认数据格式为parquet（列式存储）

DataSet[Row]—DataFrame是包含RDD+schema信息（用来描述数据的数据）

sparksql在编程的时候，可以用DSL语言风格或SQL语句风格来操作

DataSet和DataFrame之间可以互相转换，用as方法

sparksql在获取json数据时，里面的数值数据会解析成long类型

sparksql是无法对数据做增删改的，只能做查询

启用hive：
1、在配置信息时加入config(“spark.sql.warehouse.dir”, “d://spark-warehouse”)
2、在gerOrCreate方法之前调用enableHiveSupport()方法启动hive支持

---

kafka的重要组件（重要）

Producer:
生产者负责将数据传入Kafka，比如flume、java后台服务、logstash
生产者可以有多个，并且可以同时往一个topic中写数据，也可以同时往一个partition中传入数据。
每个生产者都是一个独立的进程，而且单个生产者就具有分发数据的能力。
一个生产者可以同时往多个topic中分发数据。（一般不会这么操作）

Kafka cluster：
Kafka由多个broker组成，一个broker作为一个实例（节点）
Kafka集群可以保存多种类型的数据，是由多个topic进行分类的
一个topic其实就是一个队列
每个topic可以创建一个或多个partition，partition的数量是可以更改的
每个partition是由多个segment组成的，segment的大小是相同的，默认的是1G
topic中的数据是有多副本机制的，原始数据和副本数据不会在同一个节点上（所以若只有一个节点，副本数为3，也并不会在同一个节点上存3份）

Consumer group：
消费者负责拉取数据，比如：streaming、storm、java服务
消费者组中可以存在多个consumer，在stream中，一个consumer作为一个线程
新增或减少consumer数量会触发负载均衡，目的是减少部分broker压力，提高Kafka的吞吐量
一个consumer group可以消费多个分区的数据
一个分区的数据最多在同一个时刻被一个consumer消费
在同一个consumer group中，数据是不可以重复消费（若想要重复消费，可以修改group名，或者设置Kafka集群映射，或者手动调整已经变化了的偏移量）

关于Kafka的几个问题：
Kafka数据的存储机制（Kafka是怎么存储数据的）？
1、broker先接受到producer传过来的数据，将数据写入到操作系统（Linux）的缓存（pagecache）里，pagecache会尽可能的使用空闲内存来存储数据
2、使用sendfile技术尽可能多的减少操作系统和应用程序之间的重复缓存，写数据时是顺序写入（顺序写入的速度可达到600m/s）

consumer是怎么解决负载均衡的？
1、获取consumer消费的起始分区号
2、计算出consumer消费的分区数量
3、用分区号的hash值%分区数

segment是什么？
1、一个分区被分为多个相同大小的segment，默认是1G，
2、每个segment是由多个index和log文件组成的，index存储数据对应的索引，实际的数据是存储在log文件中。
3、segment是有生命周期的，默认是168小时（七天）

数据是怎么分发的（数据的分发策略）？
1、Kafka接收到数据后会根据创建的topic指定的副本来存储，多副本之间会有选举的过程，即有leader和follower，数据会首先写到leader，然后再同步到follower
2、Kafka会调用分区器来进行分发数据，默认分区器是DefaultPartitioner（分区的逻辑是key的hash值%分区数），也可以自定义分区器，需要实现Partitioner特质，实现partition方法

Kafka存储数据能做到全局有序吗？
不能。只能做到分区内有序。
如果就想做到topic的全局有序，只声明一个分区，但会影响吞吐量。（1秒20MB数据，一天也是1.7T的数据）

更多关于Kafka的内容挪步另一篇Kafka博客。

---

Spark Streaming


Spark Streaming类似于Apache Storm，用于流式数据的处理。根据其官方文档介绍，Spark Streaming有高吞吐量和容错能力强等特点。Spark Streaming支持的数据输入源很多，例如：Kafka、Flume、Twitter、ZeroMQ和简单的TCP套接字等等。数据输入后可以用Spark的高度抽象原语如：map、reduce、join、window等进行运算。而结果也能保存在很多地方，如HDFS，数据库等。另外Spark Streaming也能和MLlib（机器学习）以及Graphx完美融合。

DStream
Discretized Stream是Spark Streaming的基础抽象，代表持续性的数据流和经过各种Spark原语操作后的结果数据流。在内部实现上，DStreams是一系列连续的RDD来表示。每个RDD含有一段时间间隔内的数据。

DStream的三个特殊原语的理解和练习–updateStateByKey、transform、window operations
挪步另一篇博客

Kafka的消息传递语义（重要，若问Kafka基本必问），换种问法，Kafka怎么保持数据的一致性（怎么保证数据0丢失）？
1.幂等写入（ idempotent writes）
需要设置好唯一主键等，比如用redis、mysql
再比如每次往一个目录覆盖写数据，这样主键不容易获取。
一次语义：幂等写入
当获取到数据后，先写到mysql，再保存offset，如果在写到mysql数据后，在保存offset之前宕机，重启作业后也不会影响一次语义，因为会在mysql重复更新。
注：在软件开发领域，幂等写入即为同样的请求被执行一次与连续执行多次的效果是一样的，服务器的状态也是一样的，实际上就是接口的可重复调用（包括时间和空间上两个维度）。
2.事务控制
保证数据和offset在同一个事务里面，比如用mysql，这样需要事务存储的支持。
3.自己实现Exactly-once，offset和数据绑定保存等。
代码详情请挪步此篇博客末尾 消息传递语义

streaming消费kafka的两种方式的优缺点的总结
Receiver方式：
Receiver从Kafka中获取数据都是存储在Spark Executor内存中的，然后Spark Streaming启动的job会去处理那些数据。
优点：操作简单方便，不用自己管理offset。
缺点：各方面都不如Direct方式。
Direct方式：
它会周期性的查询kafka，来获取每个topic + partition的最新offset，从而定义每一个batch的offset的范围。当处理数据的job启动时，就会使用kafka简单的消费者API来获取kafka指定offset的范围的数据。
优点：
1）它简化了并行读取：如果要读取多个partition，不需要创建多个输入DStream然后对他们进行union操作。Spark会创建跟kafka partition一样多的RDD partition，并且会并行从kafka中读取数据。所以在kafka partition和RDD partition之间有一个一一对应的映射关系。
2）高性能：如果要保证数据零丢失，基于Receiver的机制需要开启WAL机制，这种方式其实很低效，因为数据实际上被copy了2分，kafka自己本身就有可靠的机制，会对数据复制一份，而这里又复制一份到WAL中。基于Direct的方式，不依赖于Receiver，不需要开启WAL机制,只要kafka中做了数据的复制，那么就可以通过kafka的副本进行恢复。
3）一次仅且一次的事务机制
基于Receiver的方式，是使用Kafka High Level的API在zookeeper中保存消费过的offset的。这是消费kafka数据的传统方式，这种方式配合这WAL机制可以保证数据零丢失，但是无法保证数据只被处理一次的且仅且一次，可能会两次或者更多，因为spark和zookeeper可能是不同步的。
4）降低资源
Direct不需要Receivers，其申请的Executors全部参与到计算任务中；而Receiver-based则需要专门的Receivers来读取Kafka数据且不参与计算。因此相同的资源申请，Direct 能够支持更大的业务。
5）降低内存
Receiver-based的Receiver与其他Exectuor是异步的，并持续不断接收数据，对于小业务量的场景还好，如果遇到大业务量时，需要提高Receiver的内存，但是参与计算的Executor并无需那么多的内存。而Direct 因为没有Receiver，而是在计算时读取数据，然后直接计算，所以对内存的要求很低。实际应用中我们可以把原先的10G降至现在的2-4G左右。
6）不会出现数据堆积
Receiver-based方法需要Receivers来异步持续不断的读取数据，因此遇到网络、存储负载等因素，导致实时任务出现堆积，但Receivers却还在持续读取数据，此种情况很容易导致计算崩溃。Direct 则没有这种顾虑，其Driver在触发batch 计算任务时，才会读取数据并计算。队列出现堆积并不会引起程序的失败。
缺点：需要自己管理offset，相对更麻烦复杂。

---

资源调度模式：
local模式（本地）
standalone模式
on-yarn模式
messos模式
docker
cloud

这么多资源调度模式，到底用哪种比较好？需要通过公司需求和运行速度来综合衡量

哪种调度模式速度快呢？standalone模式

为什么有很多企业在用spark-on-yarn模式？
考虑到尽量用一个统一的资源调度模式来运行多种任务，
这样可以减轻运维的工作压力，
同时也可以减少资源调度之间的配合（基于集群考虑）

spark-on-yarn
Yarn的任务调度流程
1、client向ResourceManager注册并提交任务
2、ResourceManager向NodeManager进行通信，开始在某个NodeManager启动AppMaster
3、AppMaster启动后开始向ResourceManager申请资源
4、ApplicationManager开始资源调度，开始通知NodeManager启动YarnChild
5、YarnChild开始和AppMaster进行通信，AppMaster对所有YarnChild进行监控
6、MR执行完成以后，YarnChild被AppMaster回收，AppMaster把自己回收掉
源码分析，SparkSubmit、SparkContext、stage划分过程以及任务提交的大致过程（待完善）
或者记住降龙十八掌。
Spark任务生成和提交过程（1.6版本）

---

Redis
Redis是用C语言开发的一个开源的高性能键值对（key-value）数据库。
Redis应用场景：
缓存（数据查询、短连接、新闻内容、商品内容等等）。（最多使用）
分布式集群架构中的session分离。
聊天室的在线好友列表。
任务队列。（秒杀、抢购、12306等等）
应用排行榜。
网站访问统计。
数据过期处理（可以精确到毫秒）
redis的特性
1、redis数据访问速度快（数据在内存中）
2、redis有数据持久化机制（持久化机制有两种：1、RDB方式，定期将内存数据dump到磁盘；2、aof(append only file)持久化机制——用记日志的方式记录每一条数据更新操作，一旦出现灾难事件，可以通过日志重放来恢复整个数据库。默认rdb方式，可能会造成数据损失，需手动设置aof方式。）
3、redis支持集群模式（容量可以线性扩展），从3.0.0版本开始支持集群模式。
4、redis相比其他缓存工具（ehcach/memcached），有一个鲜明的优势：支持丰富的数据结构
Redis数据类型及其应用场景
String类型：string为最简单类型，一个key对应一个value。
Hash类型：当一个对象有多个属性时，如果用string存储，更新属性需要更新整个对象（例如User对象有id，username、password、age、name等属性，存储/更新过程为User对象 ==> json(string) ==>redis）,造成资源浪费。此时用Hash类型存储，结构为 键-字段-字段值，其中字段值只能是字符串类型。
List类型：list是一个链表结构，主要功能是push、pop以及获取一个范围的所有值等。
使用list结构，可以轻松实现最新消息排行，另一个应用是消息队列，可以利用list的push操作，将任务存在list中，然后工作线程再用pop操作将任务取出进行执行。（先进后出）
Set类型：set是集合，对集合操作有添加删除元素，有对多个集合求交并差等操作。在微博应用中，可以将一个用户关注的所有人放在一个集合里，将所有粉丝放在一个集合里，因为redis为集合提供了求交集、并集、差集等操作，就可以方便的实现如共同关注、共同喜好等功能。
SortedSet类型：sorted set是有序集合，比set多了一个权重参数score，使得集合元素能够按score进行有序排列。
例如存储一个班级同学的成绩，其集合value可以是同学的学号，而score可以是其考试的得分，这样在数据插入集合的时候就进行了排序。
此外，
redis还有主从复制机制（HA），
redis集群模式：
1.集群通信是通过“ping-pong”机制进行通信。
2.客户端不需要将所有的节点都连接上，只需要连接其中一个节点即可。
3.集群中存储数据是存储到一个个的槽中，集群中槽的个数是固定的：16384，槽的编号是【0-16383】。在集群中存储数据时，会根据key进行计算，计算出一个结果，然后将这个结果和16384取余，余数就是这个key将要存储的槽的编号。
注意：槽的编号之间不能断开。
补充：较少使用，因为redis一般只是用来缓存数据，数据不会保存太久，一般用不上集群模式）

---

elk技术栈
elk是指elastic公司的3个产品
e: elasticsearch: 分布式文件存储系统，集成了lucene，具有相当丰富的检索功能。
开源免费的，用java语言实现的
l: logstash: 数据采集工具，类似于flume，也是开源免费的，JRuby语言实现的
k: kibana: 结果数据展示工具，是用javascript+一小部分java语言实现的

es提供了两种api：restful接口风格的api和java api

es中，有索引（index）、文档（document）、类型（type）、id的概念、映射（mapping）

index：相当于数据库中的database
document：相当于一行数据
type：相当于数据库中的table
id：相当于数据库中的id
mapping：相当于数据库中的schema信息

在插入数据的时候，指定顺序为url/index/type/id/field， 比如：
curl -XPUT “http://localhost:9200/blog01/article/1” -d “{”"“id”"": “”“1"”", “”“title”"": “”“Whatiselasticsearch”""}"

es有分片的概念

es也实现了多副本机制保证数据的安全性，副本的数量是不包括源数据的，这点和hdfs是不一样的

es提供了多种查询方式，比如：bool查询、id查询、range查询、term查询等等
其中bool查询中有几个关键字：
must:相当于关系型数据库中的and
should:相当于关系型数据库中的or
must_not：相当于关系型数据库中的not

---