问题出现的背景

目前在使用Hive查数据的时候，同事们更多的是选择Hue平台，但是也会有熟悉Hive的同事直接使用Hive Cli来完成数据的查询，来看具体的Running进度，但是遇到这种Hive Cli卡住的情况，我也是第一次遇到。

首先想到的则是 Hive 服务是否还健康，去Ambari看了下Hive服务，是正常的，并没有报警。

这里提一下，集群Hive中，计算引擎使用的是Tez，启动过程中，Tez会向yarn中申请资源。如果资源不足那么就会导致这种问题！

这时候看了下Yarn的使用情况

看到这里其实问题就差不多清楚了，接下来验证一下，新开一个窗口

1

hive -hiveconf hive.execution.engine=mr

这样计算引擎临时切换到MapReduce，就没有问题了。所以原因在于如果hive的engine是Tez的话,Tez在执行之前会判断yarn资源是否充足,如果资源一直不足,则无法执行,而mr则不会有这种问题!

将Hadoop源码下载到本地后，直接用Vs Code打开，起初我是想通过IDEA，一边Debug，一边看源码的执行流程，但是Maven依赖总出问题，后来索性还是直接用Vs Code生撸吧，我选择的版本是Hadoop 2.9.2

从提交任务开始

路径：hadoop-2.9.2-src/hadoop-mapreduce-project/hadoop-mapreduce-examples/src/main/java/org/apache/hadoop/examples/WordCount.java

Command + 左键， 点击光标选中的方法

接下来跳入submit**()方法**

**
进入submitJobInternal()，这坨代码有点长，我们先看writeSplits()

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130

JobStatus submitJobInternal(Job job, Cluster cluster) //向系统提交作业的内部方法。
  throws ClassNotFoundException, InterruptedException, IOException {

    //validate the jobs output specs，校验输出路径
    checkSpecs(job);

    Configuration conf = job.getConfiguration(); //获取Job配置信息
    addMRFrameworkToDistributedCache(conf);//配置信息添加到缓存

    Path jobStagingArea = JobSubmissionFiles.getStagingDir(cluster, conf);
    //configure the command line options correctly on the submitting dfs
    InetAddress ip = InetAddress.getLocalHost();
    if (ip != null) {
      submitHostAddress = ip.getHostAddress();
      submitHostName = ip.getHostName();
      conf.set(MRJobConfig.JOB_SUBMITHOST,submitHostName);
      conf.set(MRJobConfig.JOB_SUBMITHOSTADDR,submitHostAddress);
    }
    JobID jobId = submitClient.getNewJobID();
    job.setJobID(jobId);
    Path submitJobDir = new Path(jobStagingArea, jobId.toString());
    JobStatus status = null;
    try {
      conf.set(MRJobConfig.USER_NAME,
          UserGroupInformation.getCurrentUser().getShortUserName());
      conf.set("hadoop.http.filter.initializers", 
          "org.apache.hadoop.yarn.server.webproxy.amfilter.AmFilterInitializer");
      conf.set(MRJobConfig.MAPREDUCE_JOB_DIR, submitJobDir.toString());
      LOG.debug("Configuring job " + jobId + " with " + submitJobDir 
          + " as the submit dir");
      // get delegation token for the dir
      TokenCache.obtainTokensForNamenodes(job.getCredentials(),
          new Path[] { submitJobDir }, conf);
      
      populateTokenCache(conf, job.getCredentials());

      // generate a secret to authenticate shuffle transfers
      if (TokenCache.getShuffleSecretKey(job.getCredentials()) == null) {
        KeyGenerator keyGen;
        try {
          keyGen = KeyGenerator.getInstance(SHUFFLE_KEYGEN_ALGORITHM);
          keyGen.init(SHUFFLE_KEY_LENGTH);
        } catch (NoSuchAlgorithmException e) {
          throw new IOException("Error generating shuffle secret key", e);
        }
        SecretKey shuffleKey = keyGen.generateKey();
        TokenCache.setShuffleSecretKey(shuffleKey.getEncoded(),
            job.getCredentials());
      }
      if (CryptoUtils.isEncryptedSpillEnabled(conf)) {
        conf.setInt(MRJobConfig.MR_AM_MAX_ATTEMPTS, 1);
        LOG.warn("Max job attempts set to 1 since encrypted intermediate" +
                "data spill is enabled");
      }

      copyAndConfigureFiles(job, submitJobDir);//将可执行文件之类拷贝到HDFS中，默认的是保留10份，会存在不同的节点上

      Path submitJobFile = JobSubmissionFiles.getJobConfPath(submitJobDir);
      
      // Create the splits for the job
      LOG.debug("Creating splits at " + jtFs.makeQualified(submitJobDir));
      //计算map数量，所有的切片信息 提交到 submitJobDir 路径上
      int maps = writeSplits(job, submitJobDir);
      conf.setInt(MRJobConfig.NUM_MAPS, maps);
      LOG.info("number of splits:" + maps);

      int maxMaps = conf.getInt(MRJobConfig.JOB_MAX_MAP,
          MRJobConfig.DEFAULT_JOB_MAX_MAP);
      if (maxMaps >= 0 && maxMaps < maps) {
        throw new IllegalArgumentException("The number of map tasks " + maps +
            " exceeded limit " + maxMaps);
      }

      // write "queue admins of the queue to which job is being submitted"
      // to job file.
      String queue = conf.get(MRJobConfig.QUEUE_NAME,
          JobConf.DEFAULT_QUEUE_NAME);
      AccessControlList acl = submitClient.getQueueAdmins(queue);
      conf.set(toFullPropertyName(queue,
          QueueACL.ADMINISTER_JOBS.getAclName()), acl.getAclString());

      // removing jobtoken referrals before copying the jobconf to HDFS
      // as the tasks don't need this setting, actually they may break
      // because of it if present as the referral will point to a
      // different job.
      TokenCache.cleanUpTokenReferral(conf);//清除Token引用的缓存

      if (conf.getBoolean(
          MRJobConfig.JOB_TOKEN_TRACKING_IDS_ENABLED,
          MRJobConfig.DEFAULT_JOB_TOKEN_TRACKING_IDS_ENABLED)) {
        // Add HDFS tracking ids
        ArrayList<String> trackingIds = new ArrayList<String>();
        for (Token<? extends TokenIdentifier> t :
            job.getCredentials().getAllTokens()) {
          trackingIds.add(t.decodeIdentifier().getTrackingId());
        }
        conf.setStrings(MRJobConfig.JOB_TOKEN_TRACKING_IDS,
            trackingIds.toArray(new String[trackingIds.size()]));
      }

      // Set reservation info if it exists
      ReservationId reservationId = job.getReservationId();
      if (reservationId != null) {
        conf.set(MRJobConfig.RESERVATION_ID, reservationId.toString());
      }

      // Write job file to submit dir
      writeConf(conf, submitJobFile);
      
      //
      // Now, actually submit the job (using the submit name)
      // 这里，开始正式的提交任务了。
      //
      printTokens(jobId, job.getCredentials());
      status = submitClient.submitJob(
          jobId, submitJobDir.toString(), job.getCredentials());
      if (status != null) {
        return status;
      } else {
        throw new IOException("Could not launch job");
      }
    } finally {
      if (status == null) {
        LOG.info("Cleaning up the staging area " + submitJobDir);
        if (jtFs != null && submitJobDir != null)
          jtFs.delete(submitJobDir, true);

      }
    }
  }

writeSplits()，该方法是对输入的数据进行切片处理并且返回map任务数

跳进getSplit()

在看上面的代码中，其中有一块是我的盲区，就是while (((double) bytesRemaining)/splitSize > SPLIT_SLOP)
**
其中SPLIT_SLOP默认是1.1，这里所实现的功能就是，在一个文件不断的split的时候，如果当前的待切割容量/blockSize > 1.1，则会继续进行划分，如果小于1.1，则可以不用再继续split了，举例讲的话，也就是待划分大小不大于140.8M的话，就不用切割了。

现在跳出这个方法。继续看writeNewSplits()，这里只是对文件进行了区间划分，并没有进行实际的物理切割，那接下来经过一次按照分片大小的排序后，它将切片数据写入切片文件，并得到切片元数据信息SplitMetaInfo数组info，最后返回map数。一个 Job 的Map阶段并行度由客户端在提交Job时的切片数决定（有多少个切片就有多少个 MapTask）

继续跳回submitJobInternal()

submitJob()将任务提交到集群

最近公司大数据集群要迁移到腾讯云，由原来的HDP版本+物理机的模式，要切换到EMR+COS（对象存储）存算分离模式，那么存算分离到底是什么呢？

Hadoop一出生就是存储与计算在一起的，前几年面试题中都问，Hadoop怎么保证高性能呢？其中一个原因是数据不动，计算(code)动。如今，到了计算与存储分离的阶段。存储计算分离是一种分层架构思想，即将存储能力和计算能力分开，各自服务化，通过高速网络连接
**

对象存储（Cloud Object Storage，COS）是由腾讯云推出的无目录层次结构、无数据格式限制，可容纳海量数据且支持 HTTP/HTTPS 协议访问的分布式存储服务。腾讯云 COS 的存储桶空间无容量上限，无需分区管理，适用于 CDN 数据分发、数据万象处理或大数据计算与分析的数据湖等多种场景。COS 提供网页端管理界面、多种主流开发语言的 SDK、API 以及命令行和图形化工具，并且兼容 S3 的 API 接口，方便用户直接使用社区工具和插件。其底层采用腾讯自研存储引擎YottaStore，能够实现单集群理论管理百万级节点，并且做到真正的按需扩容，磁盘利用率达到 90% 以上

为什么要存算分离

以Hadoop为例说明，在传统Hadoop的使用中，存储与计算密不可分，而随着业务的发展，常常会因为为了扩存储而带来额外的计算扩容，这其实就是一种浪费；同理，只为了提升计算能力，也会带来一段时期的存储浪费，将计算和存储分离，可以更好地应对单方面的不足。

存储与计算分离的趋势

在2009年做大规模计算的核心词是“Locality”：让计算尽量靠近数据以提升效率。当时一个公认的模型是：构建一个足够大的资源池，把数据和计算融合在里面发挥规模效应。

但最近几年以来，生态和环境都悄然发生了一些变化：

• 计算模式：全量数据计算模式，逐步被Impala、Presto等更高效计算模式赶上
• 存储格式：ORC/Parquet/Kudu等列存、索引技术诞生，使得计算不需要Scan全量数据
• 网络架构：25G网络开始上线，FPGA等技术也加快了网络体验
• 存储介质：SSD、AliFlash、3D X-Point 大量混合技术使得存储可以“既快又猛”
• 计算平台：GPU、FGPA、甚至是未来的TPU等改变计算形态

从这些变化使得我们发现：
通过一款机型通吃存储+计算方案，已经演变成存储+计算各自服务化，通过高速网络进行连接的趋势

这种方式可以使得存储、计算不用再被”机型“，”机柜“，”电力“等方案束缚，在各自最擅长的领域进行创新。

注：关于25G网络，请看 https://cloud.tencent.com/developer/news/235145

基本架构

架构其实比较简单，OSS作为默认的存储（对象存储），Hadoop、Spark可以作为计算引擎直接分析OSS存储的数据。

以上比较了计算与存储分离的优缺点。
**
灵活：在《E-MapReduce(Hadoop)10大类问题之集群规划》 一文中分析了集群规划问题，关键是匹配计算量与存储量，如果把计算与存储分离后，则集群规划则变得简单很多，基本不需要估算未来业务的规模了，真正做到按需使用。
**
成本：存储与计算分离后,按照1 master 8cpu32g 6 slave 8cpu32g 10T数据量，大致成本下降一倍，在ecs自建的磁盘选择高效云盘。

**
**
性能：随着EMR和OSS的兼容做的越来越好和云计算网络环境的提升，OSS作为存储会越来越多得体现出其优势。对比两种方案，OSS方案最大的缺点是在读数据的时候性能低于HDFS，可以把数据的最初读取和最终的结果使用OSS，中间的临时计算变量放到HDFS上，可以一定程度上缓解这个问题。当然具体使用什么方案还需要根据实际情况选择最合适自己的才是最好的方案。性能大约下降10%以内，对于一般的应用是可以接受的

分析

我们可以看到，emr+oss后，成本节约了一半，但是性能下降基本可以忽略不计。从性能图上看，emr+oss对比ecs自建hadoop对比：

也就是整体来讲，emr+oss比自建使用更少的资源，如果提高emr+oss的并发度，则时间上有可能超过ecs自建hadoop集群的。

在实时计算的场景下，绝大多数的数据源都是消息系统，而 Kafka 从众多的消息中间件中脱颖而出，主要是因为高吞吐、低延迟的特点；同时也讲了 Flink 作为生产者像 Kafka 写入数据的方式和代码实现。将从以下几个方面介绍 Flink 消费 Kafka 中的数据方式和源码实现。

Kafka 连接 Flink

Flink 中支持了比较丰富的用来连接第三方的连接器，Kafka Connector 是 Flink 支持的各种各样的连接器中比较完善的之一。

Flink 提供了专门的 Kafka 连接器，向 Kafka Topic 中读取或者写入数据。Flink Kafka Consumer 集成了 Flink 的 Checkpoint 机制，可提供 exactly-once 的处理语义。为此，Flink 并不完全依赖于跟踪 Kafka 消费组的偏移量，而是在内部跟踪和检查偏移量。

同时也提过，我们在使用 Kafka 连接器时需要引用相对应的 Jar 包依赖。对于某些连接器比如 Kafka 是有版本要求的，一定要去官方网站找到对应的依赖版本。我在下表中给出了不同版本的 Kafka，以及对应的 Connector 关系：

Kafka 本地环境搭建

我们在本地环境搭建一个 Kafka_2.11-2.1.0 版本的 Kafka 单机环境，然后模拟一些数据写入到队列中。

我们可以在这里下载对应版本的 Kafka，把压缩包进行解压，然后使用下面的命令启动单机版本的 Kafka。

解压：

1
2

> tar -xzf kafka_2.11-2.1.0.tgz
> cd kafka_2.11-2.1.0

启动 ZooKeeper 和 Kafka Server：

1
2
3

启动ZK：nohup bin/zookeeper-server-start.sh config/zookeeper.properties  &
启动Server: 
nohup bin/kafka-server-start.sh config/server.properties &

创建一个名为 test 的 Topic：

1

bin/kafka-topics.sh --create --zookeeper localhost:2181 --replication-factor 1 --partitions 1 --topic test

Kafka Producer

首先我们需要新增一个依赖，然后向名为 test 的 Topic 中写入数据。新增 Maven 依赖：

1
2
3
4
5

<dependency>
   <groupId>org.apache.flink</groupId>
   <artifactId>flink-connector-kafka_2.11</artifactId>
   <version>1.10.0</version>
</dependency>

向Topic中写入数据：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

public class KafkaProducer {

    public static void main(String[] args) throws Exception{

        StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();

        env.getCheckpointConfig().setCheckpointingMode(CheckpointingMode.EXACTLY_ONCE);

        env.enableCheckpointing(5000);

        DataStreamSource<String> text = env.addSource(new MyNoParalleSource()).setParallelism(1);

        Properties properties = new Properties();

        properties.setProperty("bootstrap.servers", "127.0.0.1:9092");

        // 2.0 配置 KafkaProducer

        FlinkKafkaProducer<String> producer = new FlinkKafkaProducer<String>(

                "127.0.0.1:9092", //broker 列表

                "test",           //topic

                new SimpleStringSchema()); // 消息序列化

        //写入 Kafka 时附加记录的事件时间戳

        producer.setWriteTimestampToKafka(true);

        text.addSink(producer);

        env.execute();

    }

}

需要注意的是，我们这里使用了一个自定义的 MyNoParalleSource 类，该类使用了 Flink 提供的自定义 Source 方法，该方法会源源不断地产生一些测试数据，代码如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

public class MyNoParalleSource implements SourceFunction<String> {

    //private long count = 1L;

    private boolean isRunning = true;

    /**

     * 主要的方法

     * 启动一个source

     * 大部分情况下，都需要在这个run方法中实现一个循环，这样就可以循环产生数据了

     *

     * @param ctx

     * @throws Exception

     */

    @Override

    public void run(SourceContext<String> ctx) throws Exception {

        while(isRunning){

            //图书的排行榜

            List<String> books = new ArrayList<>();

            books.add("Pyhton从入门到放弃");//10

            books.add("Java从入门到放弃");//8

            books.add("Php从入门到放弃");//5

            books.add("C++从入门到放弃");//3

            books.add("Scala从入门到放弃");

            int i = new Random().nextInt(5);

            ctx.collect(books.get(i));

            //每2秒产生一条数据

            Thread.sleep(2000);

        }

    }

    //取消一个cancel的时候会调用的方法

    @Override

    public void cancel() {

        isRunning = false;

    }

}

Flink 如何消费 Kafka

Flink 在和 Kafka 对接的过程中，跟 Kafka 的版本是强相关的。我们在使用 Kafka 连接器时需要引用相对应的 Jar 包依赖，对于某些连接器比如 Kafka 是有版本要求的，一定要去官方网站找到对应的依赖版本。
我们本地的 Kafka 版本是 2.1.0，所以需要对应的类是 FlinkKafkaConsumer。首先需要在 pom.xml 中引入 jar 包依赖：
复制

1
2
3
4
5

<dependency>
  <groupId>org.apache.flink</groupId>
  <artifactId>flink-connector-kafka_2.11</artifactId>
  <version>1.10.0</version>
</dependency>

下面将对 Flink 消费 Kafka 数据的方式进行分类讲解。

消费单个 Topic

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

public static void main(String[] args) throws Exception {
    StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();
    env.getCheckpointConfig().setCheckpointingMode(CheckpointingMode.EXACTLY_ONCE);
    env.enableCheckpointing(5000);
    Properties properties = new Properties();
    properties.setProperty("bootstrap.servers", "127.0.0.1:9092");
    // 如果你是0.8版本的Kafka，需要配置
    //properties.setProperty("zookeeper.connect", "localhost:2181");
    //设置消费组
    properties.setProperty("group.id", "group_test");
    FlinkKafkaConsumer<String> consumer = new FlinkKafkaConsumer<>("test", new SimpleStringSchema(), properties);
    //设置从最早的ffset消费
    consumer.setStartFromEarliest();
    //还可以手动指定相应的 topic, partition，offset,然后从指定好的位置开始消费
    //HashMap<KafkaTopicPartition, Long> map = new HashMap<>();
    //map.put(new KafkaTopicPartition("test", 1), 10240L);
    //假如partition有多个，可以指定每个partition的消费位置
    //map.put(new KafkaTopicPartition("test", 2), 10560L);
    //然后各个partition从指定位置消费
    //consumer.setStartFromSpecificOffsets(map);
    env.addSource(consumer).flatMap(new FlatMapFunction<String, String>() {
        @Override
        public void flatMap(String value, Collector<String> out) throws Exception {
            System.out.println(value);
        }
    });
    env.execute("start consumer...");
}

在设置消费 Kafka 中的数据时，可以显示地指定从某个 Topic 的每一个 Partition 中进行消费。

消费多个 Topic

我们的业务中会有这样的情况，同样的数据根据类型不同发送到了不同的 Topic 中，比如线上的订单数据根据来源不同分别发往移动端和 PC 端两个 Topic 中。但是我们不想把同样的代码复制一份，需重新指定一个 Topic 进行消费，这时候应该怎么办呢？

1
2
3
4
5
6
7
8
9
10
11
12
13

Properties properties = new Properties();
properties.setProperty("bootstrap.servers", "127.0.0.1:9092");
// 如果你是0.8版本的Kafka，需要配置
//properties.setProperty("zookeeper.connect", "localhost:2181");
//设置消费组
properties.setProperty("group.id", "group_test");
FlinkKafkaConsumer<String> consumer = new FlinkKafkaConsumer<>("test", new SimpleStringSchema(), properties);
ArrayList<String> topics = new ArrayList<>();
        topics.add("test_A");
        topics.add("test_B");
// 传入一个 list，完美解决了这个问题
FlinkKafkaConsumer<Tuple2<String, String>> consumer = new FlinkKafkaConsumer<>(topics, new SimpleStringSchema(), properties);
...

我们可以传入一个 list 来解决消费多个 Topic 的问题，如果用户需要区分两个 Topic 中的数据，那么需要在发往 Kafka 中数据新增一个字段，用来区分来源。

消息序列化

我们在上述消费 Kafka 消息时，都默认指定了消息的序列化方式，即 SimpleStringSchema。这里需要注意的是，在我们使用 SimpleStringSchema 的时候，返回的结果中只有原数据，没有 topic、parition 等信息，这时候可以自定义序列化的方式来实现自定义返回数据的结构。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

public class CustomDeSerializationSchema implements KafkaDeserializationSchema<ConsumerRecord<String, String>> {
    //是否表示流的最后一条元素,设置为false，表示数据会源源不断地到来
    @Override
    public boolean isEndOfStream(ConsumerRecord<String, String> nextElement) {
        return false;
    }
    //这里返回一个ConsumerRecord<String,String>类型的数据，除了原数据还包括topic，offset，partition等信息
    @Override
    public ConsumerRecord<String, String> deserialize(ConsumerRecord<byte[], byte[]> record) throws Exception {
        return new ConsumerRecord<String, String>(
                record.topic(),
                record.partition(),
                record.offset(),
                new String(record.key()),
                new String(record.value())
        );
    }
    //指定数据的输入类型
    @Override
    public TypeInformation<ConsumerRecord<String, String>> getProducedType() {
        return TypeInformation.of(new TypeHint<ConsumerRecord<String, String>>(){});
    }
}

这里自定义了 CustomDeSerializationSchema 信息，就可以直接使用了。

Parition 和 Topic 动态发现

在很多场景下，随着业务的扩展，我们需要对 Kafka 的分区进行扩展，为了防止新增的分区没有被及时发现导致数据丢失，消费者必须要感知 Partition 的动态变化，可以使用 FlinkKafkaConsumer 的动态分区发现实现。

我们只需要指定下面的配置，即可打开动态分区发现功能：每隔 10ms 会动态获取 Topic 的元数据，对于新增的 Partition 会自动从最早的位点开始消费数据。

1

properties.setProperty(FlinkKafkaConsumerBase.KEY_PARTITION_DISCOVERY_INTERVAL_MILLIS, "10");

如果业务场景需要我们动态地发现 Topic，可以指定 Topic 的正则表达式：

1

FlinkKafkaConsumer<String> consumer = new FlinkKafkaConsumer<>(Pattern.compile("^test_([A-Za-z0-9]*)$"), new SimpleStringSchema(), properties);

Flink 消费 Kafka 设置 offset 的方法

Flink 消费 Kafka 需要指定消费的 offset，也就是偏移量。Flink 读取 Kafka 的消息有五种消费方式：

• 指定 Topic 和 Partition

• 从最早位点开始消费

• 从指定时间点开始消费

• 从最新的数据开始消费

• 从上次消费位点开始消费

复制

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

/**
* Flink从指定的topic和parition中指定的offset开始
*/
Map<KafkaTopicPartition, Long> offsets = new HashedMap();
offsets.put(new KafkaTopicPartition("test", 0), 10000L);
offsets.put(new KafkaTopicPartition("test", 1), 20000L);
offsets.put(new KafkaTopicPartition("test", 2), 30000L);
consumer.setStartFromSpecificOffsets(offsets);
/**
* Flink从topic中最早的offset消费
*/
consumer.setStartFromEarliest();
/**
* Flink从topic中指定的时间点开始消费
*/
consumer.setStartFromTimestamp(1559801580000l);
/**
* Flink从topic中最新的数据开始消费
*/
consumer.setStartFromLatest();
/**
* Flink从topic中指定的group上次消费的位置开始消费，所以必须配置group.id参数
*/
consumer.setStartFromGroupOffsets();

Offset提交

Flink Kafka Consumer允许配置offset提交回Kafka brokers(Kafka 0.8是写回Zookeeper)的行为，注意Flink Kafka Consumer 并不依赖于这个提交的offset来进行容错性保证，这个提交的offset仅仅作为监控consumer处理进度的一种手段。

配置offset提交行为的方式有多种，主要取决于Job的checkpoint机制是否启动。

1、checkpoint禁用:如果checkpoint禁用，Flink Kafka Consumer依赖于Kafka 客户端内部的自动周期性offset提交能力。因此，为了启用或者禁用offset提交，仅需在给定的Properties配置中设置enable.auto.commit / auto.commit.interval.ms，就会按固定的时间间隔定期 auto commit offset 到 kafka。

2、checkpoint启用:如果checkpoint启用，当checkpoint完成之后，Flink Kafka Consumer将会提交offset保存到checkpoint State中，这个时候作业消费的 offset 是 Flink 在 state 中自己管理和容错，保证了kafka broker中的committed offset与 checkpoint stata中的offset相一致。用户可以在Consumer中调用setCommitOffsetsOnCheckpoints(boolean) 方法来选择启用或者禁用offset committing，默认的情况下是setCommitOffsetsOnCheckpoints(true)，checkpoint成功后，将offset同步给kafka。注意，在这种情况下，配置在Properties中的自动周期性offset提交将会被完全忽略。

源码解析

从上面的类图可以看出，FlinkKafkaConsumer 继承了 FlinkKafkaConsumerBase，而 FlinkKafkaConsumerBase 最终是对 SourceFunction 进行了实现。

整体的流程：FlinkKafkaConsumer 首先创建了 KafkaFetcher 对象，然后 KafkaFetcher 创建了 KafkaConsumerThread 和 Handover，KafkaConsumerThread 负责直接从 Kafka 中读取 msg，并交给 Handover，然后 Handover 将 msg 传递给 KafkaFetcher.emitRecord 将消息发出。

因为 FlinkKafkaConsumerBase 实现了 RichFunction 接口，所以当程序启动的时候，会首先调用 FlinkKafkaConsumerBase.open 方法：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136

public void open(Configuration configuration) throws Exception {
   // 指定offset的提交方式
   this.offsetCommitMode = OffsetCommitModes.fromConfiguration(
         getIsAutoCommitEnabled(),
         enableCommitOnCheckpoints,
         ((StreamingRuntimeContext) getRuntimeContext()).isCheckpointingEnabled());
   // 创建分区发现器
   this.partitionDiscoverer = createPartitionDiscoverer(
         topicsDescriptor,
         getRuntimeContext().getIndexOfThisSubtask(),
         getRuntimeContext().getNumberOfParallelSubtasks());
   this.partitionDiscoverer.open();
   subscribedPartitionsToStartOffsets = new HashMap<>();
   final List<KafkaTopicPartition> allPartitions = partitionDiscoverer.discoverPartitions();
   if (restoredState != null) {
      for (KafkaTopicPartition partition : allPartitions) {
         if (!restoredState.containsKey(partition)) {
            restoredState.put(partition, KafkaTopicPartitionStateSentinel.EARLIEST_OFFSET);
         }
      }
      for (Map.Entry<KafkaTopicPartition, Long> restoredStateEntry : restoredState.entrySet()) {
         if (!restoredFromOldState) {
           
            if (KafkaTopicPartitionAssigner.assign(
               restoredStateEntry.getKey(), getRuntimeContext().getNumberOfParallelSubtasks())
                  == getRuntimeContext().getIndexOfThisSubtask()){
               subscribedPartitionsToStartOffsets.put(restoredStateEntry.getKey(), restoredStateEntry.getValue());
            }
         } else {
           subscribedPartitionsToStartOffsets.put(restoredStateEntry.getKey(), restoredStateEntry.getValue());
         }
      }
      if (filterRestoredPartitionsWithCurrentTopicsDescriptor) {
         subscribedPartitionsToStartOffsets.entrySet().removeIf(entry -> {
            if (!topicsDescriptor.isMatchingTopic(entry.getKey().getTopic())) {
               LOG.warn(
                  "{} is removed from subscribed partitions since it is no longer associated with topics descriptor of current execution.",
                  entry.getKey());
               return true;
            }
            return false;
         });
      }
      LOG.info("Consumer subtask {} will start reading {} partitions with offsets in restored state: {}",
         getRuntimeContext().getIndexOfThisSubtask(), subscribedPartitionsToStartOffsets.size(), subscribedPartitionsToStartOffsets);
   } else {
    
      switch (startupMode) {
         case SPECIFIC_OFFSETS:
            if (specificStartupOffsets == null) {
               throw new IllegalStateException(
                  "Startup mode for the consumer set to " + StartupMode.SPECIFIC_OFFSETS +
                     ", but no specific offsets were specified.");
            }
            for (KafkaTopicPartition seedPartition : allPartitions) {
               Long specificOffset = specificStartupOffsets.get(seedPartition);
               if (specificOffset != null) {
                                 subscribedPartitionsToStartOffsets.put(seedPartition, specificOffset - 1);
               } else {
               subscribedPartitionsToStartOffsets.put(seedPartition, KafkaTopicPartitionStateSentinel.GROUP_OFFSET);
               }
            }
            break;
         case TIMESTAMP:
            if (startupOffsetsTimestamp == null) {
               throw new IllegalStateException(
                  "Startup mode for the consumer set to " + StartupMode.TIMESTAMP +
                     ", but no startup timestamp was specified.");
            }
            for (Map.Entry<KafkaTopicPartition, Long> partitionToOffset
                  : fetchOffsetsWithTimestamp(allPartitions, startupOffsetsTimestamp).entrySet()) {
               subscribedPartitionsToStartOffsets.put(
                  partitionToOffset.getKey(),
                  (partitionToOffset.getValue() == null)
                      KafkaTopicPartitionStateSentinel.LATEST_OFFSET
                        : partitionToOffset.getValue() - 1);
            }
            break;
         default:
            for (KafkaTopicPartition seedPartition : allPartitions) {
               subscribedPartitionsToStartOffsets.put(seedPartition, startupMode.getStateSentinel());
            }
      }
      if (!subscribedPartitionsToStartOffsets.isEmpty()) {
         switch (startupMode) {
            case EARLIEST:
               LOG.info("Consumer subtask {} will start reading the following {} partitions from the earliest offsets: {}",
                  getRuntimeContext().getIndexOfThisSubtask(),
                  subscribedPartitionsToStartOffsets.size(),
                  subscribedPartitionsToStartOffsets.keySet());
               break;
            case LATEST:
               LOG.info("Consumer subtask {} will start reading the following {} partitions from the latest offsets: {}",
                  getRuntimeContext().getIndexOfThisSubtask(),
                  subscribedPartitionsToStartOffsets.size(),
                  subscribedPartitionsToStartOffsets.keySet());
               break;
            case TIMESTAMP:
               LOG.info("Consumer subtask {} will start reading the following {} partitions from timestamp {}: {}",
                  getRuntimeContext().getIndexOfThisSubtask(),
                  subscribedPartitionsToStartOffsets.size(),
                  startupOffsetsTimestamp,
                  subscribedPartitionsToStartOffsets.keySet());
               break;
            case SPECIFIC_OFFSETS:
               LOG.info("Consumer subtask {} will start reading the following {} partitions from the specified startup offsets {}: {}",
                  getRuntimeContext().getIndexOfThisSubtask(),
                  subscribedPartitionsToStartOffsets.size(),
                  specificStartupOffsets,
                  subscribedPartitionsToStartOffsets.keySet());
               List<KafkaTopicPartition> partitionsDefaultedToGroupOffsets = new ArrayList<>(subscribedPartitionsToStartOffsets.size());
               for (Map.Entry<KafkaTopicPartition, Long> subscribedPartition : subscribedPartitionsToStartOffsets.entrySet()) {
                  if (subscribedPartition.getValue() == KafkaTopicPartitionStateSentinel.GROUP_OFFSET) {
                     partitionsDefaultedToGroupOffsets.add(subscribedPartition.getKey());
                  }
               }
               if (partitionsDefaultedToGroupOffsets.size() > 0) {
                  LOG.warn("Consumer subtask {} cannot find offsets for the following {} partitions in the specified startup offsets: {}" +
                        "; their startup offsets will be defaulted to their committed group offsets in Kafka.",
                     getRuntimeContext().getIndexOfThisSubtask(),
                     partitionsDefaultedToGroupOffsets.size(),
                     partitionsDefaultedToGroupOffsets);
               }
               break;
            case GROUP_OFFSETS:
               LOG.info("Consumer subtask {} will start reading the following {} partitions from the committed group offsets in Kafka: {}",
                  getRuntimeContext().getIndexOfThisSubtask(),
                  subscribedPartitionsToStartOffsets.size(),
                  subscribedPartitionsToStartOffsets.keySet());
         }
      } else {
         LOG.info("Consumer subtask {} initially has no partitions to read from.",
            getRuntimeContext().getIndexOfThisSubtask());
      }
   }
}

对 Kafka 中的 Topic 和 Partition 的数据进行读取的核心逻辑都在 run 方法中：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42

public void run(SourceContext<T> sourceContext) throws Exception {
   if (subscribedPartitionsToStartOffsets == null) {
      throw new Exception("The partitions were not set for the consumer");
   }
   this.successfulCommits = this.getRuntimeContext().getMetricGroup().counter(COMMITS_SUCCEEDED_METRICS_COUNTER);
   this.failedCommits =  this.getRuntimeContext().getMetricGroup().counter(COMMITS_FAILED_METRICS_COUNTER);
   final int subtaskIndex = this.getRuntimeContext().getIndexOfThisSubtask();
   this.offsetCommitCallback = new KafkaCommitCallback() {
      @Override
      public void onSuccess() {
         successfulCommits.inc();
      }
      @Override
      public void onException(Throwable cause) {
         LOG.warn(String.format("Consumer subtask %d failed async Kafka commit.", subtaskIndex), cause);
         failedCommits.inc();
      }
   };
   if (subscribedPartitionsToStartOffsets.isEmpty()) {
      sourceContext.markAsTemporarilyIdle();
   }
   LOG.info("Consumer subtask {} creating fetcher with offsets {}.",
      getRuntimeContext().getIndexOfThisSubtask(), subscribedPartitionsToStartOffsets);
  
   this.kafkaFetcher = createFetcher(
         sourceContext,
         subscribedPartitionsToStartOffsets,
         periodicWatermarkAssigner,
         punctuatedWatermarkAssigner,
         (StreamingRuntimeContext) getRuntimeContext(),
         offsetCommitMode,
         getRuntimeContext().getMetricGroup().addGroup(KAFKA_CONSUMER_METRICS_GROUP),
         useMetrics);
   if (!running) {
      return;
   }
   if (discoveryIntervalMillis == PARTITION_DISCOVERY_DISABLED) {
      kafkaFetcher.runFetchLoop();
   } else {
      runWithPartitionDiscovery();
   }
}

Flink 消费 Kafka 数据代码

上面介绍了 Flink 消费 Kafka 的方式，以及消息序列化的方式，同时介绍了分区和 Topic 的动态发现方法，那么回到我们的项目中来，消费 Kafka 数据的完整代码如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

public class KafkaConsumer {
    public static void main(String[] args) throws Exception {
        StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();
        env.getCheckpointConfig().setCheckpointingMode(CheckpointingMode.EXACTLY_ONCE);
        env.enableCheckpointing(5000);
        Properties properties = new Properties();
        properties.setProperty("bootstrap.servers", "127.0.0.1:9092");
        //设置消费组
        properties.setProperty("group.id", "group_test");
        properties.setProperty(FlinkKafkaConsumerBase.KEY_PARTITION_DISCOVERY_INTERVAL_MILLIS, "10");
        FlinkKafkaConsumer<String> consumer = new FlinkKafkaConsumer<>("test", new SimpleStringSchema(), properties);
        //设置从最早的ffset消费
        consumer.setStartFromEarliest();
        env.addSource(consumer).flatMap(new FlatMapFunction<String, String>() {
            @Override
            public void flatMap(String value, Collector<String> out) throws Exception {
                System.out.println(value);
            }
        });
        env.execute("start consumer...");
    }
}

我们可以直接右键运行代码，在控制台中可以看到数据的正常打印，如下图所示：

通过代码可知，我们之前发往 Kafka 的消息被完整地打印出来了。

Q&A

如果checkpoint时间过长，offset未提交到kafka，此时节点宕机了，重启之后的重复消费如何保证呢？

首先开启checkpoint时offset是flink通过状态state管理和恢复的，并不是从kafka的offset位置恢复。在checkpoint机制下，作业从最近一次checkpoint恢复，本身是会回放部分历史数据，导致部分数据重复消费，Flink引擎仅保证计算状态的精准一次，要想做到端到端精准一次需要依赖一些幂等的存储系统或者事务操作。

最近公司的小伙伴基本上都在用Hive来查询数据，毕竟对于后端程序员来讲更为熟悉的还是像MySQL，Oracle这样的数据库，虽然Hive中的SQL标准和上面两者很相似了，但是还有些差别的，这也造成了同事们的水土不服，其中就有关于Hive判空的操作，那这里就记录一下Hive的Null

hive的使用中对null、‘’（空字符串）进行判断识别

1. 不同数据类型对空值的存储规则
   • int与string类型数据存储，null默认存储为 \N；
   • string类型的数据如果为””，存储则是””；
   • 另外往int类型的字段插入数据“”时，结果还是\N。

2. 不同数据类型，空值的查询
   • 对于int可以使用is null来判断空；
   • 而对于string类型，条件is null 查出来的是\N的数据；而条件 =’’，查询出来的是””的数据。

下面举例来说明：

上图 t_user_details，brent用户的register_date字段为NULL值，那这时候，我们应该怎样去根据register_date字段值去查询brent这个用户呢？

直接看结果：

对于上面的查询，register_date = ‘’ 是不能成功过滤的。根据上面所说的，也就是 对于string类型，条件is null 查出来的是\N的数据；而条件 =’’，查询出来的是””的数据

所以对于 cloumn = ‘’ 的查询，是针对这个cloumn字段，写入值的时候，是 ‘’ 空子串，所以此时，is null 的条件则不生效。

现在我们去HDFS底层存储中去求证一下

有图有真相，hive 中null实际在HDFS中默认存储为 \N

可以使用serialization.null.format来指定Hive中保存和标识NULL，可以设置为默认的\N，也可以为NULL或’’

eg : ALTER TABLE b SET SERDEPROPERTIES (‘serialization.null.format’=’’);

如果表中存在大量的NULL值，则在Hive的数据文件中会产生大量的\N数据，浪费存储空间，那我们可以将serialization.null.format设置为’’

那么对于上游系统写入的数据不清楚的情况下，我们怎么去方便的对空值进行判断呢？

给一个万金油的写法：

1

select * from t_user_details  where register_date is null or register_date  <> '';

DMP：数据管理平台

我们先来看一下什么是 DMP 系统。DMP 系统的全称叫作数据管理平台（Data Management Platform），目前广泛应用在互联网的广告定向（Ad Targeting）、个性化推荐（Recommendation）这些领域。

通常来说，DMP 系统会通过处理海量的互联网访问数据以及机器学习算法，给一个用户标注上各种各样的标签。然后，在我们做个性化推荐和广告投放的时候，再利用这些这些标签，去做实际的广告排序、推荐等工作。无论是 Google 的搜索广告、淘宝里千人千面的商品信息，还是抖音里面的信息流推荐，背后都会有一个 DMP 系统。

那么，一个 DMP 系统应该怎么搭建呢？对于外部使用 DMP 的系统或者用户来说，可以简单地把 DMP 看成是一个键 - 值对（Key-Value）数据库。我们的广告系统或者推荐系统，可以通过一个客户端输入用户的唯一标识（ID），然后拿到这个用户的各种信息。


这些信息中，有些是用户的人口属性信息（Demographic），比如性别、年龄；有些是非常具体的行为（Behavior），比如用户最近看过的商品是什么，用户的手机型号是什么；有一些是我们通过算法系统计算出来的兴趣（Interests），比如用户喜欢健身、听音乐；还有一些则是完全通过机器学习算法得出的用户向量，给后面的推荐算法或者广告算法作为数据输入。


基于此，对于这个 KV 数据库，我们的期望也很清楚，那就是：低响应时间（Low Response Time）、高可用性（High Availability）、高并发（High Concurrency）、海量数据（Big Data），同时我们需要付得起对应的成本（Affordable Cost）。如果用数字来衡量这些指标，那么我们的期望就会具体化成下面这样。

1. 低响应时间：一般的广告系统留给整个广告投放决策的时间也就是 10ms 左右，所以对于访问 DMP 获取用户数据，预期的响应时间都在 1ms 之内。
2. 高可用性：DMP 常常用在广告系统里面。DMP 系统出问题，往往就意味着我们整个的广告收入在不可用的时间就没了，所以我们对于可用性的追求可谓是没有上限的。Google 2018 年的广告收入是 1160 亿美元，折合到每一分钟的收入是 22 万美元。即使我们做到 99.99% 的可用性，也意味着每个月我们都会损失 100 万美元。
3. 高并发：还是以广告系统为例，如果每天我们需要响应 100 亿次的广告请求，那么我们每秒的并发请求数就在 100 亿 / (86400) ~= 12K 次左右，所以我们的 DMP 需要支持高并发。
4. 数据量：如果我们的产品针对中国市场，那么我们需要有 10 亿个 Key，对应的假设每个用户有 500 个标签，标签有对应的分数。标签和分数都用一个 4 字节（Bytes）的整数来表示，那么一共我们需要 10 亿 x 500 x (4 + 4) Bytes = 4 TB 的数据了。
5. 低成本：我们还是从广告系统的角度来考虑。广告系统的收入通常用 CPM（Cost Per Mille），也就是千次曝光来统计。如果千次曝光的利润是 0.10，那么每天100亿次的曝光就是100万美元的利润。这个利润听起来非常高了。但是反过来算一下，你会发现，DMP每1000次的请求的成本不能超过0.10。最好只有 $0.01，甚至更低，我们才能尽可能多赚到一点广告利润。

这五个因素一结合，听起来是不是就不那么简单了？不过，更复杂的还在后面呢。虽然从外部看起来，DMP 特别简单，就是一个 KV 数据库，但是生成这个数据库需要做的事情更多。我们下面一起来看一看。





为了能够生成这个 KV 数据库，我们需要有一个在客户端或者 Web 端的数据采集模块，不断采集用户的行为，向后端的服务器发送数据。服务器端接收到数据，就要把这份数据放到一个数据管道（Data Pipeline）里面。数据管道的下游，需要实际将数据落地到数据仓库（Data Warehouse），把所有的这些数据结构化地存储起来。后续，我们就可以通过程序去分析这部分日志，生成报表或者或者利用数据运行各种机器学习算法。


除了这个数据仓库之外，我们还会有一个实时数据处理模块（Realtime Data Processing），也放在数据管道的下游。它同样会读取数据管道里面的数据，去进行各种实时计算，然后把需要的结果写入到 DMP 的 KV 数据库里面去。

MongoDB 真的万能吗？

面对这里的 KV 数据库、数据管道以及数据仓库，这三个不同的数据存储的需求，最合理的技术方案是什么呢？你可以先自己思考一下，我这里先卖个关子。我共事过的不少不错的 Web 程序员，面对这个问题的时候，常常会说：“这有什么难的，用 MongoDB 就好了呀！”如果你也选择了 MongoDB，那最终的结果一定是一场灾难。


我为什么这么说呢？MongoDB 的设计听起来特别厉害，不需要预先数据 Schema，访问速度很快，还能够无限水平扩展。作为 KV 数据库，我们可以把 MongoDB 当作 DMP 里面的 KV 数据库；除此之外，MongoDB 还能水平扩展、跑 MQL，我们可以把它当作数据仓库来用。


至于数据管道，只要我们能够不断往 MongoDB 里面，插入新的数据就好了。从运维的角度来说，我们只需要维护一种数据库，技术栈也变得简单了。看起来，MongoDB 这个选择真是相当完美！但是，作为一个老程序员，第一次听到 MongoDB 这样“万能”的解决方案，我的第一反应是，“天底下哪有这样的好事”。所有的软件系统，都有它的适用场景，想通过一种解决方案适用三个差异非常大的应用场景，显然既不合理，又不现实。接下来，我们就来仔细看一下，这个“不合理”“不现实”在什么地方。上面我们已经讲过 DMP 的 KV 数据库期望的应用场景和性能要求了，这里我们就来看一下数据管道和数据仓库的性能取舍。


对于数据管道来说，我们需要的是高吞吐量，它的并发量虽然和 KV 数据库差不多，但是在响应时间上，要求就没有那么严格了，1-2 秒甚至再多几秒的延时都是可以接受的。而且，和 KV 数据库不太一样，数据管道的数据读写都是顺序读写，没有大量的随机读写的需求。


数据仓库就更不一样了，数据仓库的数据读取的量要比管道大得多。管道的数据读取就是我们当时写入的数据，一天有 10TB 日志数据，管道只会写入 10TB。下游的数据仓库存放数据和实时数据模块读取的数据，再加上个 2 倍的 10TB，也就是 20TB 也就够了。


但是，数据仓库的数据分析任务要读取的数据量就大多了。一方面，我们可能要分析一周、一个月乃至一个季度的数据。这一次分析要读取的数据可不是 10TB，而是 100TB 乃至 1PB。我们一天在数据仓库上跑的分析任务也不是 1 个，而是成千上万个，所以数据的读取量是巨大的。另一方面，我们存储在数据仓库里面的数据，也不像数据管道一样，存放几个小时、最多一天的数据，而是往往要存上 3 个月甚至是 1 年的数据。所以，我们需要的是 1PB 乃至 5PB 这样的存储空间。我把 KV 数据库、数据管道和数据仓库的应用场景，总结成了一个表格，放在这里。你可以对照着看一下，想想为什么 MongoDB 在这三个应用场景都不合适。



在 KV 数据库的场景下，需要支持高并发。那么 MongoDB 需要把更多的数据放在内存里面，但是这样我们的存储成本就会特别高了。


在数据管道的场景下，我们需要的是大量的顺序读写，而 MongoDB 则是一个文档数据库系统，并没有为顺序写入和吞吐量做过优化，看起来也不太适用。


而在数据仓库的场景下，主要的数据读取时顺序读取，并且需要海量的存储。MongoDB 这样的文档式数据库也没有为海量的顺序读做过优化，仍然不是一个最佳的解决方案。而且文档数据库里总是会有很多冗余的字段的元数据，还会浪费更多的存储空间。

那我们该选择什么样的解决方案呢？

拿着我们的应用场景去找方案，其实并不难找。对于 KV 数据库，最佳的选择方案自然是使用 SSD 硬盘，选择 AeroSpike 这样的 KV 数据库。高并发的随机访问并不适合 HDD 的机械硬盘，而 400TB 的数据，如果用内存的话，成本又会显得太高。


对于数据管道，最佳选择自然是 Kafka。因为我们追求的是吞吐率，采用了 Zero-Copy 和 DMA 机制的 Kafka 最大化了作为数据管道的吞吐率。而且，数据管道的读写都是顺序读写，所以我们也不需要对随机读写提供支持，用上 HDD 硬盘就好了。


到了数据仓库，存放的数据量更大了。在硬件层面使用 HDD 硬盘成了一个必选项。否则，我们的存储成本就会差上 10 倍。这么大量的数据，在存储上我们需要定义清楚 Schema，使得每个字段都不需要额外存储元数据，能够通过 Avro/Thrift/ProtoBuffer 这样的二进制序列化的方存储下来，或者干脆直接使用 Hive 这样明确了字段定义的数据仓库产品。很明显，MongoDB 那样不限制 Schema 的数据结构，在这个情况下并不好用。

总结

好了，相信到这里，你应该对怎么从最基本的原理出发，来选择技术栈有些感觉了。你应该更多地从底层的存储系统的特性和原理去考虑问题。一旦能够从这个角度去考虑问题，那么你对各类新的技术项目和产品的公关稿，自然会有一定的免疫力了，而不会轻易根据商业公司的宣传来做技术选型了。


因为低延时、高并发、写少读多的 DMP 的 KV 数据库，最适合用 SSD 硬盘，并且采用专门的 KV 数据库是最合适的。可以选择AeroSpike，也可以用开源的 Cassandra 来提供服务。


对于数据管道，因为主要是顺序读和顺序写，所以我们不一定要选用 SSD 硬盘，而可以用 HDD 硬盘。不过，对于最大化吞吐量的需求，使用 zero-copy 和 DMA 是必不可少的，所以现在的数据管道的标准解决方案就是 Kafka 了。


对于数据仓库，我们通常是一次写入、多次读取。并且，由于存储的数据量很大，我们还要考虑成本问题。于是，一方面，我们会用 HDD 硬盘而不是 SSD 硬盘；另一方面，我们往往会预先给数据规定好 Schema，使得单条数据的序列化，不需要像存 JSON 或者 MongoDB 的 BSON 那样，存储冗余的字段名称这样的元数据。


所以，最常用的解决方案是，用 Hadoop 这样的集群，采用 Hive 这样的数据仓库系统，或者采用 Avro/Thrift/ProtoBuffer 这样的二进制序列化方案。在大型的 DMP 系统设计当中，我们需要根据各个应用场景面临的实际情况，选择不同的硬件和软件的组合，来作为整个系统中的不同组件。

思考

这一讲里，我们讲到了数据管道通常所使用的开源系统 Kafka，并且选择了使用机械硬盘。在 Kafka 的使用上，我们有没有必要使用 SSD 硬盘呢？如果用了 SSD 硬盘，又会带来哪些好处和坏处呢？

从应用场景来看，SSD的确还没有太大必要。从数据量的角度，搞很多块HDD已经可以满足目前的高并发的需求了，kafka频繁擦写 ssd的寿命是一个问题，从成本上和使用寿命也比SSD更划算了。

但是SSD和几年前比已经便宜了很多了，而且在PCI-E接口普及的情况下，顺序读写速度比起HDD也能拉开差距了，所以逐步我们也看到业界开始直接用SSD来部署Kafka也变得比较常见了。

Bloom filter最优的大小计算

Bloom过滤器对插入到其中的元素的数量非常敏感。对于HBase来说，条目的数量取决于存储在列中的数据的大小。当前默认区域大小为256MB，因此条目计数~=256MB/（列的平均值大小）。尽管有这个经验法则，但是由于压缩，我们并没有有效的方法来计算压缩后的条目计数。因此，通常使用动态bloom过滤器来添加额外的空间，而不是允许错误率增长。


Bloom filter最优的大小计算公示为：bloom size m = -(n * ln(err) / (ln(2)^2) ~= n * ln(err) / ln(0.6185)

• m表示Bloom filter中的位数（bitSize）
• n表示插入bloomfilter中的元素数（maxKeys）
• k表示使用的哈希函数数（nbHash）
• e表示Bloom所需的误报率（err）

但且仅当k=m/n ln（2）时，误报概率最小。

Hbase中Bloom filter的设置是在创建列族时通过setBloomFilterType方法设定，Hbase支持ROW、ROWCOL、ROWPREFIX_FIXED_LENGTH三种类型的Bloom filter，创建列族时默认设置为ROW，对所有插入数据的rowkey写入到Bloom filter中。**

HBase中布隆过滤器的实现

Bloom filter接口实现

Hbase的布隆过滤器由父接口BloomFilterBase类定义，包含2个子继承接口BloomFilter和BloomFilterWriter。
BloomFilter负责读取、判断，BloomFilterWriter负责将数据写入布隆过滤器。

read类

BloomFilter负责数据的读取判断其中定义了三个方法

1
2
3
4
5
6

//检查所定义的keyCell是否包含
boolean contains(Cell keyCell, ByteBuff bloom, BloomType type);
boolean contains(byte[] buf, int offset, int length, ByteBuff bloom);
 
//是否允许Bloom filter自动load数据，默认实现为true
boolean supportsAutoLoading();

BloomFilter最终的实现类是CompoundBloomFilter类，CompoundBloomFilter的核心方法是contains方法。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

public boolean contains(Cell keyCell, ByteBuff bloom, BloomType type) {
  
  //如果根索引不包含keyCell，返回false，根索引在Hfile创建时构建，不是对所有rowkey
  int block = index.rootBlockContainingKey(keyCell);
  if (block < 0) {
    return false; // This key is not in the file.
  }
  boolean result;
 
  //获得Bloom的Block
  HFileBlock bloomBlock = getBloomBlock(block);
  try {
    ByteBuff bloomBuf = bloomBlock.getBufferReadOnly();
   
  //通过BloomFilterUtil的contains方法判断
 
    result = BloomFilterUtil.contains(keyCell, bloomBuf, bloomBlock.headerSize(),
        bloomBlock.getUncompressedSizeWithoutHeader(), hash, hashCount, type);
  } finally {
    // After the use return back the block if it was served from a cache.
    reader.returnBlock(bloomBlock);
  }
  if (numPositivesPerChunk != null && result) {
    // Update statistics. Only used in unit tests.
    ++numPositivesPerChunk[block];
  }
  return result;
}

BloomFilterUtil.contains方法中，通过不同的 BloomType，构建不同的BloomHashKey，然后读取bloomBuf中的bitvals，计算cell
对应类型的HashKey，判断在bitvals中是否为1.

1
2
3
4
5
6
7
8

public static boolean contains(Cell cell, ByteBuff bloomBuf, int bloomOffset, int bloomSize,
    Hash hash, int hashCount, BloomType type) {
  HashKey<Cell> hashKey = type == BloomType.ROWCOL ? new RowColBloomHashKey(cell)
      : new RowBloomHashKey(cell);

//最终的判断方法，实现还是比较简单
  return contains(bloomBuf, bloomOffset, bloomSize, hash, hashCount, hashKey);
}

write类

BloomFilterWriter类定义了一些写入方法

1
2
3
4
5
6
7
8
9
10
11
12

 
//在数据写入磁盘之前，压缩Bloom filter  
void compactBloom();
 
//获得一个meta data 的Writer，写入Bloom TYpe 、数据大小等
Writable getMetaWriter();
 
//获取一个 Bloom bits 的Writer
Writable getDataWriter();
 
// previous cell written
Cell getPrevCell();

BloomFilterWriter的最终实现类为CompoundBloomFilterWriter。子类CompoundBloomFilterWriter的核心方法是append方法，负责将添加的数据写入到BloomFilter

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

@Override
public void append(Cell cell) throws IOException {
  if (cell == null)
    throw new NullPointerException();
 
  enqueueReadyChunk(false);
 
  if (chunk == null) {
    if (firstKeyInChunk != null) {
      throw new IllegalStateException("First key in chunk already set: "
          + Bytes.toStringBinary(firstKeyInChunk));
    }
 
   //第一添加时需要allocateNewChunk，Chunk动态添加，完成hash等
    // This will be done only once per chunk
    if (bloomType == BloomType.ROWCOL) {
      firstKeyInChunk =
          PrivateCellUtil
              .getCellKeySerializedAsKeyValueKey(PrivateCellUtil.createFirstOnRowCol(cell));
    } else {
      firstKeyInChunk = CellUtil.copyRow(cell);
    }
    allocateNewChunk();
  }
 
  //Chunk 实现具体的hash计算，和bit置位
  chunk.add(cell);
  this.prevCell = cell;
  ++totalKeyCount;
}

BloomFilterChunk继承自BloomFilterBase，实现了BloomFilter的读写，其中add方法实现写入

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

  public void add(Cell cell) {
    /*
     * For faster hashing, use combinatorial generation
     * http://www.eecs.harvard.edu/~kirsch/pubs/bbbf/esa06.pdf
     */
    int hash1;
    int hash2;
    HashKey<Cell> hashKey;
    
// 计算2次hash 写入位
 
  if (this.bloomType == BloomType.ROWCOL) {
      hashKey = new RowColBloomHashKey(cell);
      hash1 = this.hash.hash(hashKey, 0);
      hash2 = this.hash.hash(hashKey, hash1);
    } else {
      hashKey = new RowBloomHashKey(cell);
      hash1 = this.hash.hash(hashKey, 0);
      hash2 = this.hash.hash(hashKey, hash1);
    }
    setHashLoc(hash1, hash2);
  }

get方法完成数据查询，和之前BloomFilterUtil.contains方法一致

1
2
3
4
5
6
7
8
9
10

static boolean get(int pos, ByteBuffer bloomBuf, int bloomOffset) {
  
  //实现位查找
  int bytePos = pos >> 3; //pos / 8
  int bitPos = pos & 0x7; //pos % 8
  // TODO access this via Util API which can do Unsafe access if possible(?)
  byte curByte = bloomBuf.get(bloomOffset + bytePos);
  curByte &= BloomFilterUtil.bitvals[bitPos];
  return (curByte != 0);
}

布隆过滤器的使用

对于之前创建的布隆过滤器的使用，hbase中体现在两个地方，一个是构建scannner时，判断scanner的是否包含所需要的数据列或者列族


在构建StoreFileScanner时，会通过shouldUseScanner方法判断，时都用到当前Scanner，其中用到了reader.passesBloomFilter的方法。

1
2
3
4
5
6
7
8
9
10
11
12

public boolean shouldUseScanner(Scan scan, HStore store, long oldestUnexpiredTS) {
  // if the file has no entries, no need to validate or create a scanner.
  byte[] cf = store.getColumnFamilyDescriptor().getName();
  TimeRange timeRange = scan.getColumnFamilyTimeRange().get(cf);
  if (timeRange == null) {
    timeRange = scan.getTimeRange();
  }
 
 //从时间范围、startkey和endkey范围、bloomfilter判断
  return reader.passesTimerangeFilter(timeRange, oldestUnexpiredTS) && reader
      .passesKeyRangeFilter(scan) && reader.passesBloomFilter(scan, scan.getFamilyMap().get(cf));
}

StoreFileReader在创建StoreFileScanner的时候创建，主要用来读取hfile文件。 passesBloomFilter方法当前Hfile的bloomFilter的类型，构建具体的bloomFilter。bloomFilter的类型是创建表时，列族中定义的。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

boolean passesBloomFilter(Scan scan, final SortedSet<byte[]> columns) {
  byte[] row = scan.getStartRow();
  switch (this.bloomFilterType) {
    case ROW:
      if (!scan.isGetScan()) {
        return true;
      }
      return passesGeneralRowBloomFilter(row, 0, row.length);
 
    case ROWCOL:
      if (!scan.isGetScan()) {
        return true;
      }
      if (columns != null && columns.size() == 1) {
        byte[] column = columns.first();
        // create the required fake key
        Cell kvKey = PrivateCellUtil.createFirstOnRow(row, HConstants.EMPTY_BYTE_ARRAY, column);
        return passesGeneralRowColBloomFilter(kvKey);
      }
 
      // For multi-column queries the Bloom filter is checked from the
      // seekExact operation.
      return true;
    case ROWPREFIX_FIXED_LENGTH:
      return passesGeneralRowPrefixBloomFilter(scan);
    default:
      return true;
  }
}

passesGeneralRowBloomFilter方法中this.generalBloomFilter是创建reader时构建的BloomFilter。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

private boolean passesGeneralRowBloomFilter(byte[] row, int rowOffset, int rowLen) {
  BloomFilter bloomFilter = this.generalBloomFilter;
  if (bloomFilter == null) {
    return true;
  }
 
  // Used in ROW bloom
  byte[] key = null;
  if (rowOffset != 0 || rowLen != row.length) {
    throw new AssertionError(
        "For row-only Bloom filters the row must occupy the whole array");
  }
  key = row;
 
 //判断row是否在本hfile中
  return checkGeneralBloomFilter(key, null, bloomFilter);
}

checkGeneralBloomFilter方法中调用contains完成最终的判断。

布隆过滤器在HBase中的应用

块索引机制

在讨论布隆过滤器在HBase中的应用之前，先介绍一下HBase的块索引机制。块索引是HBase固有的一个特性，因为HBase的底层数据是存储在HFile中的，而每个HFile中存储的是有序的<key, value>键值对，HFile文件内部由连续的块组成，每个块中存储的第一行数据的行键组成了这个文件的块索引，这些块索引信息存储在文件尾部。当HBase打开一个HFile时，块索引信息会优先加载到内存；HBase首先在内存的块索引中进行二分查找，确定可能包含给定键的块，然后读取磁盘块找到实际想要的键。

注意这里的块不是HDFS的块，HBase块的默认大小是64KB。可以根据需要配置不同的大小，对于顺序访问较多的表，建议使用较大的块；随机访问较多的表，建议使用较小的块。

但实际应用中，仅仅只有块索引满足不了需求，这是因为，块索引能帮助我们更快地在一个文件中找到想要的数据，但是我们可能依然需要扫描很多文件。而布隆过滤器就是为解决这个问题而生。因为布隆过滤器的作用是，用户可以立即判断一个文件是否包含特定的行键，从而帮我们过滤掉一些不需要扫描的文件。如下图所示，块索引显示每个文件中都可能包含对应的行键，而布隆过滤器能帮我们跳过一些明显不包含对应行键的文件。

如上图所示，布隆过滤器不能明确指出哪一个文件一定包含所查找的行键，布隆过滤器的结果有误差存在。当布隆过滤器判断文件中不包含对应的行时，这个答案是绝对正确的；但是，当布隆过滤器判断得到文件中包含对应行时，这个答案却有可能是错的。也就是说，HBase还是有可能加载了不必要的块。尽管如此，布隆过滤器还是可以帮助我们跳过一些明显不需要扫描的文件。另外，错误率可以通过调整布隆过滤器所占空间的大小来调整，通常设置错误率为1%。


需要注意的是，使用布隆过滤器，并不一定能立即提升个别的get操作性能，因为同一时间可能有多个客户端向HBase发送请求，当负载过大时，HBase的性能受限于读磁盘的效率。但是，使用了布隆过滤器之后，可以减少不必要的块加载，从而可以提高整个集群的吞吐率。并且，因为HBase加载的块数量少了，缓存波动也降低了，进而提高了读缓存的命中率。


然而，相比与布隆过滤器的优点，它的缺点显得如此微不足道，就是需要占用少量的存储空间。在使用布隆过滤器时，需要注意两个问题

什么时候应该使用布隆过滤器

根据上面的描述，布隆过滤器的主要作用，是帮助HBase跳过那些显然不包括所查找数据的底层文件。那么，当所查找的数据均匀分布在所有文件中（当用户定期更新所有行时，就可能导致这种情况），布隆过滤器的作用就微乎其微，反而浪费了存储空间。相反，如果我们查找的数据只包含在少部分的文件中，就应该果断使用布隆过滤器。

选择行级还是行加列级布隆过滤器

布隆过滤器是hbase中的高级功能，它能够减少特定访问模式（get/scan）下的查询时间。不过由于这种模式增加了内存和存储的负担，所以被默认为关闭状态。

hbase支持如下类型的布隆过滤器：
1、NONE 不使用布隆过滤器
2、ROW 行键使用布隆过滤器
3、ROWCOL 列键使用布隆过滤器
其中ROWCOL是粒度更细的模式。

很显然，行加列级因为粒度更细，占用的存储空间也就越多。因此，如果用户总是读取整行的数据，行级布隆过滤器就够用了。在可以选择的情形下，尽可能使用行级布隆过滤器，因为它在额外的空间开销和利用过滤存储文件提升性能之间取得了更好的平衡。

例如：ROW 使用场景，假设有2个Hfile文件hf1和hf2， hf1包含kv1（r1 cf:q1 v）、kv2（r2 cf:q1 v） hf2包含kv3（r3 cf:q1 v）、kv4（r4 cf:q1 v） 如果设置了CF属性中的bloomfilter（布隆过滤器）为ROW，那么get(r1)时就会过滤hf2，get(r3)就会过滤hf1 。

ROWCOL使用场景，假设有2个Hfile文件hf1和hf2， hf1包含kv1（r1 cf:q1 v）、kv2（r2 cf:q1 v） hf2包含kv3（r1 cf:q2 v）、kv4（r2 cf:q2 v） 如果设置了CF属性中的bloomfilter为ROW，无论get(r1,q1)还是get(r1,q2)，都会读取hf1+hf2；而如果设置了CF属性中的bloomfilter为ROWCOL，那么get(r1,q1)就会过滤hf2，get(r1,q2)就会过滤hf1。
注意：ROW和ROWCOL只是名字上有联系，但是ROWCOL并不是ROW的扩展，也不能取代ROW

布隆过滤器的存储在哪

对于hbase而言，当我们选择采用布隆过滤器之后，HBase会在生成StoreFile（HFile）时包含一份布隆过滤器结构的数据，称其为MetaBlock；MetaBlock与DataBlock（真实的KeyValue数据）一起由LRUBlockCache维护。所以，开启bloomfilter会有一定的存储及内存cache开销。但是在大多数情况下，这些负担相对于布隆过滤器带来的好处是可以接受的。

采用布隆过滤器后，hbase如何get数据

在读取数据时，hbase会首先在布隆过滤器中查询，根据布隆过滤器的结果，再在MemStore中查询，最后再在对应的HFile中查询。

采用布隆过滤器后，hbase如何Scan数据

get操作会enable bloomfilter帮助剔除掉不会用到的Storefile,在scan初始化时（get会包装为scan）对于每个storefile会做shouldSeek的检查，如果返回false，则表明该storefile里没有要找的内容，直接跳过

1
2
3
4

if (memOnly == false    
            && ((StoreFileScanner) kvs).shouldSeek(scan, columns)) {    
          scanners.add(kvs);    
}

shouldSeek方法：如果是scan直接返回true表明不能跳过，然后根据bloomfilter类型检查。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

if (!scan.isGetScan()) {    
        return true;    
}    
byte[] row = scan.getStartRow();    
switch (this.bloomFilterType) {    
  case ROW:    
    return passesBloomFilter(row, 0, row.length, null, 0, 0);    
   
  case ROWCOL:    
    if (columns != null && columns.size() == 1) {    
      byte[] column = columns.first();    
      return passesBloomFilter(row, 0, row.length, column, 0, column.length);    
    }    
    // For multi-column queries the Bloom filter is checked from the    
    // seekExact operation.    
    return true;    
   
  default:    
    return true;  
}

指明qualified的scan在配了rowcol的情况下会剔除不会用掉的StoreFile。
对指明了qualify的scan或者get进行检查：seekExactly

1
2
3
4
5
6
7
8
9

// Seek all scanners to the start of the Row (or if the exact matching row    
// key does not exist, then to the start of the next matching Row).    
if (matcher.isExactColumnQuery()) {    
  for (KeyValueScanner scanner : scanners)    
  scanner.seekExactly(matcher.getStartKey(), false);    
} else {    
  for (KeyValueScanner scanner : scanners)    
  scanner.seek(matcher.getStartKey());    
}

如果bloomfilter没命中，则创建一个很大的假的keyvalue，表明该storefile不需要实际的scan

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

public boolean seekExactly(KeyValue kv, boolean forward)    
      throws IOException {    
    if (reader.getBloomFilterType() != StoreFile.BloomType.ROWCOL ||    
        kv.getRowLength() == 0 || kv.getQualifierLength() == 0) {    
      return forward ? reseek(kv) : seek(kv);    
    }    
    
    boolean isInBloom = reader.passesBloomFilter(kv.getBuffer(),    
        kv.getRowOffset(), kv.getRowLength(), kv.getBuffer(),    
        kv.getQualifierOffset(), kv.getQualifierLength());    
    if (isInBloom) {    
      // This row/column might be in this store file. Do a normal seek.    
      return forward ? reseek(kv) : seek(kv);    
    }    
    
    // Create a fake key/value, so that this scanner only bubbles up to the top    
    // of the KeyValueHeap in StoreScanner after we scanned this row/column in    
    // all other store files. The query matcher will then just skip this fake    
    // key/value and the store scanner will progress to the next column.    
    cur = kv.createLastOnRowCol();    
    return true;    
}

这边为什么是rowcol才能剔除storefile纳，很简单，scan是一个范围，如果是row的bloomfilter不命中只能说明该rowkey不在此storefile中，但next rowkey可能在。


而rowcol的bloomfilter就不一样了，如果rowcol的bloomfilter没有命中表明该qualifiy不在这个storefile中，因此这次scan就不需要scan此storefile了！


1.任何类型的get（基于rowkey和基于row+col）bloomfilter都能生效，关键是get的类型要匹配bloomfilter的类型
2.基于row的scan是没办法优化的
3.row+col+qualify的scan可以去掉不存在此qualify的storefile，也算是不错的优化了，而且指明qualify也能减少流量，因此scan尽量指明qualify。

今天来了解下关系型数据库MySQL和NoSQL存储引擎HBase的底层存储机制。对于一个数据库的性能来说，其数据的组织方式至关重要。众所周知，数据库的数据大多存储在磁盘上，而磁盘的访问相对内存的访问来说是一项很耗时的操作，对比如下。因此，提高数据库数据的查找速度的关键点之一便是尽量减少磁盘的访问次数。

为了加速数据库数据的访问，大多传统的关系型数据库都会使用特殊的数据结构来帮助查找数据，这种数据结构叫作索引（ Index）。对于传统的关系型数据库，考虑到经常需要范围查找某一批数据，因此其索引一般不使用 Hash算法，而使用树（ Tree）结构。然而，树结构的种类很多，却不一定都适合用于做数据库索引。

二叉查找树与平衡二叉树

最常见的树结构是二叉查找树（ Binary Search Tree），它就是一棵二叉有序树：保证左子树上所有节点的值都小于根节点的值，而右子树上所有节点的值都大于根节点的值。其优点在于实现简单，并且树在平衡的状态下查找效率能达到 O(log n)；缺点是在极端非平衡情况下查找效率会退化到 O(n)，因此很难保证索引的效率。



针对上述二叉查找树的缺点，人们很自然就想到是否能用平衡二叉树（ Balanced Binary Tree）来解决这个问题。但是平衡二叉树依然有个比较大的问题：它的树高为 log n——对于索引树来说，树的高度越高，意味着查找所要花费的访问次数越多，查询效率越低。


况且，主存从磁盘读数据一般以页为单位，因此每次访问磁盘都会读取多个扇区的数据（比如 4KB大小的数据），远大于单个二叉树节点的值（字节级别），这也是造成二叉树相对索引树效率低下的原因。正因如此，人们就想到了通过增加每个树节点的度来提高访问效率，而 B+树（B+-tree）便受到了更多的关注。


B+树
在传统的关系型数据库里， B+树（ B+-tree）及其衍生树是被用得比较多的索引树。

B+树的主要特点如下。

• 每个树节点只存放键值，不存放数值，而由叶子节点存放数值。这样会使树节点的度比较大，而树的高度就比较低，从而有利于提高查询效率。
  
• 叶子节点存放数值，并按照值大小顺序排序，且带指向相邻节点的指针，以便高效地进行区间数据查询；并且所有叶子节点与根节点的距离相同，因此任何查询的效率都很相似。
• 与二叉树不同， B+树的数据更新操作不从根节点开始，而从叶子节点开始，并且在更新过程中树能以比较小的代价实现自平衡。
  

正是由于 B+树的上述优点，它成了传统关系型数据库的宠儿。当然，它也并非无懈可击，我们总在讨论B+树的有点，下面来说说缺点，它的主要缺点在于随着数据插入的不断发生，叶子节点会慢慢分裂——这可能会导致逻辑上原本连续的数据实际上存放在不同的物理磁盘块位置上，在做范围查询的时候会导致较高的磁盘 IO，以致严重影响到性能。

日志结构合并树

众所周知，数据库的数据大多存储在磁盘上，而无论是传统的机械硬盘（ HardDiskDrive, HDD）还是固态硬盘（ Solid State Drive, SSD），对磁盘数据的顺序读写速度都远高于随机读写。



然而，基于 B+树的索引结构是违背上述磁盘基本特点的——它会需要较多的磁盘随机读写，于是， 1992年，名为日志结构（ Log-Structured）的新型索引结构方法便应运而生。日志结构方法的主要思想是将磁盘看作一个大的日志，每次都将新的数据及其索引结构添加到日志的最末端，以实现对磁盘的顺序操作，从而提高索引性能。不过，日志结构方法也有明显的缺点，随机读取数据时效率很低。


1996年，一篇名为 Thelog-structured merge-tree（LSM-tree）的论文创造性地提出了日志结构合并树（ Log-Structured Merge-Tree）的概念，该方法既吸收了日志结构方法的优点，又通过将数据文件预排序克服了日志结构方法随机读性能较差的问题。尽管当时 LSM-tree新颖且优势鲜明，但它真正声名鹊起却是在 10年之后的 2006年，那年谷歌的一篇使用了 LSM-tree技术的论文 Bigtable: A Distributed Storage System for Structured Data横空出世，在分布式数据处理领域掀起了一阵旋风，随后两个声名赫赫的大数据开源组件（ 2007年的 HBase与 2008年的 Cassandra，目前两者同为 Apache顶级项目）直接在其思想基础上破茧而出，彻底改变了大数据基础组件的格局，同时也极大地推广了 LSM-tree技术。


LSM-tree最大的特点是同时使用了两部分类树的数据结构来存储数据，并同时提供查询。其中一部分数据结构（ C0树）存在于内存缓存（通常叫作 memtable）中，负责接受新的数据插入更新以及读请求，并直接在内存中对数据进行排序；另一部分数据结构（ C1树）存在于硬盘上 (这部分通常叫作 sstable)，它们是由存在于内存缓存中的 C0树冲写到磁盘而成的，主要负责提供读操作，特点是有序且不可被更改。


LSM-tree的另一大特点是除了使用两部分类树的数据结构外，还会使用日志文件（通常叫作 commit log）来为数据恢复做保障。这三类数据结构的协作顺序一般是：所有的新插入与更新操作都首先被记录到 commit log中——该操作叫作 WAL（Write Ahead Log），然后再写到 memtable，最后当达到一定条件时数据会从 memtable冲写到 sstable，并抛弃相关的 log数据；memtable与 sstable可同时供查询；当 memtable出问题时，可从 commit log与 sstable中将 memtable的数据恢复。


我们可以参考 HBase的架构来体会其架构中基于 LSM-tree的部分特点。按照 WAL的原则，数据首先会写到 HBase的 HLog(相当于 commit log)里，然后再写到 MemStore（相当于 memtable）里，最后会冲写到磁盘 StoreFile（相当于 sstable）中。这样 HBase的 HRegionServer就通过 LSM-tree实现了数据文件的生成。HBase LSM-tree架构示意图如下图。

LSM-tree的这种结构非常有利于数据的快速写入（理论上可以接近磁盘顺序写速度），但是不利于读——因为理论上读的时候可能需要同时从 memtable和所有硬盘上的 sstable中查询数据，这样显然会对性能造成较大的影响。为了解决这个问题， LSM-tree采取了以下主要的相关措施。

• 定期将硬盘上小的 sstable合并（通常叫作 Merge或 Compaction操作）成大的 sstable，以减少 sstable的数量。而且，平时的数据更新删除操作并不会更新原有的数据文件，只会将更新删除操作加到当前的数据文件末端，只有在 sstable合并的时候才会真正将重复的操作或更新去重、合并。
  
• 对每个 sstable使用布隆过滤器（ Bloom Filter），以加速对数据在该 sstable的存在性进行判定，从而减少数据的总查询时间。
  

总结

LSM树和B+树的差异主要在于读性能和写性能进行权衡，在牺牲的同时寻找其余补救方案。B+树存储引擎，不仅支持单条记录的增、删、读、改操作，还支持顺序扫描（B+树的叶子节点之间的指针），对应的存储系统就是关系数据库。但随着写入操作增多，为了维护B+树结构，节点分裂，读磁盘的随机读写概率会变大，性能会逐渐减弱。LSM树（Log-Structured MergeTree）存储引擎和B+树存储引擎一样，同样支持增、删、读、改、顺序扫描操作。而且通过批量存储技术规避磁盘随机写入问题。当然凡事有利有弊，LSM树和B+树相比，LSM树牺牲了部分读性能，用来大幅提高写性能。

压缩（compression），我相信你一定不会感到陌生。它秉承了用时间去换空间的经典 trade-off 思想，具体来说就是用 CPU 时间去换磁盘空间或网络 I/O 传输量，希望以较小的 CPU 开销带来更少的磁盘占用或更少的网络 I/O 传输。在 Kafka 中，压缩也是用来做这件事的。

怎么压缩？

Kafka 是如何压缩消息的呢？要弄清楚这个问题，就要从 Kafka 的消息格式说起了。目前 Kafka 共有两大类消息格式，社区分别称之为 V1 版本和 V2 版本。V2 版本是 Kafka 0.11.0.0 中正式引入的。不论是哪个版本，Kafka 的消息层次都分为两层：消息集合（message set）以及消息（message）。一个消息集合中包含若干条日志项（record item），而日志项才是真正封装消息的地方。


Kafka 底层的消息日志由一系列消息集合日志项组成。Kafka 通常不会直接操作具体的一条条消息，它总是在消息集合这个层面上进行写入操作。那么社区引入 V2 版本的目的是什么呢？V2 版本主要是针对 V1 版本的一些弊端做了修正，和我们今天讨论的主题相关的修正有哪些呢？


先介绍一个，就是把消息的公共部分抽取出来放到外层消息集合里面，这样就不用每条消息都保存这些信息了。我来举个例子。原来在 V1 版本中，每条消息都需要执行 CRC 校验，但有些情况下消息的 CRC 值是会发生变化的。比如在 Broker 端可能会对消息时间戳字段进行更新，那么重新计算之后的 CRC 值也会相应更新；再比如 Broker 端在执行消息格式转换时（主要是为了兼容老版本客户端程序），也会带来 CRC 值的变化。鉴于这些情况，再对每条消息都执行 CRC 校验就有点没必要了，不仅浪费空间还耽误 CPU 时间，因此在 V2 版本中，消息的 CRC 校验工作就被移到了消息集合这一层。


校验的目的是防止因为网络传输出现问题导致broker端接收了受损的消息，所以应该放在作为server broker端进行，而不是在作为client端的producer。


V2 版本还有一个和压缩息息相关的改进，就是保存压缩消息的方法发生了变化。之前 V1 版本中保存压缩消息的方法是把多条消息进行压缩然后保存到外层消息的消息体字段中；而 V2 版本的做法是对整个消息集合进行压缩。显然后者应该比前者有更好的压缩效果。我对两个版本分别做了一个简单的测试，结果显示，在相同条件下，不论是否启用压缩，V2 版本都比 V1 版本节省磁盘空间。当启用压缩时，这种节省空间的效果更加明显，就像下面这两张图展示的那样：

何时压缩？

在 Kafka 中，压缩可能发生在两个地方：生产者端和 Broker 端。生产者程序中配置 compression.type 参数即表示启用指定类型的压缩算法。比如下面这段程序代码展示了如何构建一个开启 GZIP 的 Producer 对象：

1
2
3
4
5
6
7
8
9
10

Properties props = new Properties();
props.put("bootstrap.servers", "localhost:9092");
props.put("acks", "all");
props.put("key.serializer", "org.apache.kafka.common.serialization.StringSerializer");
props.put("value.serializer", "org.apache.kafka.common.serialization.StringSerializer");
// 开启GZIP压缩
props.put("compression.type", "gzip");

Producer<String, String> producer = new KafkaProducer<>(props);

这里比较关键的代码行是 props.put(“compression.type”, “gzip”)，它表明该 Producer 的压缩算法使用的是 GZIP。这样 Producer 启动后生产的每个消息集合都是经 GZIP 压缩过的，故而能很好地节省网络传输带宽以及 Kafka Broker 端的磁盘占用。


在生产者端启用压缩是很自然的想法，那为什么我说在 Broker 端也可能进行压缩呢？其实大部分情况下 Broker 从 Producer 端接收到消息后仅仅是原封不动地保存而不会对其进行任何修改，但这里的“大部分情况”也是要满足一定条件的。有两种例外情况就可能让 Broker 重新压缩消息。


情况一：Broker 端指定了和 Producer 端不同的压缩算法。


先看一个例子。想象这样一个对话。


Producer 说：“我要使用 GZIP 进行压缩。”
Broker 说：“不好意思，我这边接收的消息必须使用 Snappy 算法进行压缩。”


你看，这种情况下 Broker 接收到 GZIP 压缩消息后，只能解压缩然后使用 Snappy 重新压缩一遍。如果你翻开 Kafka 官网，你会发现 Broker 端也有一个参数叫 compression.type，和上面那个例子中的同名。但是这个参数的默认值是 producer，这表示 Broker 端会“尊重”Producer 端使用的压缩算法。可一旦你在 Broker 端设置了不同的 compression.type 值，就一定要小心了，因为可能会发生预料之外的压缩 / 解压缩操作，通常表现为 Broker 端 CPU 使用率飙升。


情况二：Broker 端发生了消息格式转换。所谓的消息格式转换主要是为了兼容老版本的消费者程序。还记得之前说过的 V1、V2 版本吧？在一个生产环境中，Kafka 集群中同时保存多种版本的消息格式非常常见。为了兼容老版本的格式，Broker 端会对新版本消息执行向老版本格式的转换。这个过程中会涉及消息的解压缩和重新压缩。一般情况下这种消息格式转换对性能是有很大影响的，除了这里的压缩之外，它还让 Kafka 丧失了引以为豪的 Zero Copy 特性。


所谓“Zero Copy”就是“零拷贝”，说的是当数据在磁盘和网络进行传输时避免昂贵的内核态数据拷贝，从而实现快速的数据传输。因此如果 Kafka 享受不到这个特性的话，性能必然有所损失，所以尽量保证消息格式的统一吧，这样不仅可以避免不必要的解压缩 / 重新压缩，对提升其他方面的性能也大有裨益。如果有兴趣你可以深入地了解下 Zero Copy 的原理。

何时解压缩？

有压缩必有解压缩！通常来说解压缩发生在消费者程序中，也就是说 Producer 发送压缩消息到 Broker 后，Broker 照单全收并原样保存起来。当 Consumer 程序请求这部分消息时，Broker 依然原样发送出去，当消息到达 Consumer 端后，由 Consumer 自行解压缩还原成之前的消息。那么现在问题来了，Consumer 怎么知道这些消息是用何种压缩算法压缩的呢？


其实答案就在消息中。Kafka 会将启用了哪种压缩算法封装进消息集合中，这样当 Consumer 读取到消息集合时，它自然就知道了这些消息使用的是哪种压缩算法。如果用一句话总结一下压缩和解压缩，那么我希望你记住这句话：Producer 端压缩、Broker 端保持、Consumer 端解压缩。


除了在 Consumer 端解压缩，Broker 端也会进行解压缩。注意了，这和前面提到消息格式转换时发生的解压缩是不同的场景。每个压缩过的消息集合在** Broker 端写入时都要发生解压缩操作，目的就是为了对消息执行各种验证。**我们必须承认这种解压缩对 Broker 端性能是有一定影响的，特别是对 CPU 的使用率而言。


事实上，最近国内京东的小伙伴们刚刚向社区提出了一个 bugfix，建议去掉因为做消息校验而引入的解压缩。据他们称，去掉了解压缩之后，Broker 端的 CPU 使用率至少降低了 50%。不过有些遗憾的是，目前社区并未采纳这个建议，原因就是这种消息校验是非常重要的，不可盲目去之。毕竟先把事情做对是最重要的，在做对的基础上，再考虑把事情做好做快。针对这个使用场景，你也可以思考一下，是否有一个两全其美的方案，既能避免消息解压缩也能对消息执行校验。

各种压缩算法对比

那么我们来谈谈压缩算法。这可是重头戏！之前说了这么多，我们还是要比较一下各个压缩算法的优劣，这样我们才能有针对性地配置适合我们业务的压缩策略。在 Kafka 2.1.0 版本之前，Kafka 支持 3 种压缩算法：GZIP、Snappy 和 LZ4。


从 2.1.0 开始，Kafka 正式支持 Zstandard 算法（简写为 zstd）。它是 Facebook 开源的一个压缩算法，能够提供超高的压缩比（compression ratio）。对了，看一个压缩算法的优劣，有两个重要的指标：一个指标是压缩比，原先占 100 份空间的东西经压缩之后变成了占 20 份空间，那么压缩比就是 5，显然压缩比越高越好；另一个指标就是压缩 / 解压缩吞吐量，比如每秒能压缩或解压缩多少 MB 的数据。同样地，吞吐量也是越高越好。下面这张表是 Facebook Zstandard 官网提供的一份压缩算法 benchmark 比较结果：



从表中我们可以发现 zstd 算法有着最高的压缩比，而在吞吐量上的表现只能说中规中矩。反观 LZ4 算法，它在吞吐量方面则是毫无疑问的执牛耳者。当然对于表格中数据的权威性我不做过多解读，只想用它来说明一下当前各种压缩算法的大致表现。


在实际使用中，GZIP、Snappy、LZ4 甚至是 zstd 的表现各有千秋。但对于 Kafka 而言，它们的性能测试结果却出奇得一致，即在吞吐量方面：LZ4 > Snappy > zstd 和 GZIP；而在压缩比方面，zstd > LZ4 > GZIP > Snappy。具体到物理资源，使用 Snappy 算法占用的网络带宽最多，zstd 最少，这是合理的，毕竟 zstd 就是要提供超高的压缩比；在 CPU 使用率方面，各个算法表现得差不多，只是在压缩时 Snappy 算法使用的 CPU 较多一些，而在解压缩时 GZIP 算法则可能使用更多的 CPU。

最佳实践

了解了这些算法对比，我们就能根据自身的实际情况有针对性地启用合适的压缩算法。首先来说压缩。何时启用压缩是比较合适的时机呢？你现在已经知道 Producer 端完成的压缩，那么启用压缩的一个条件就是 Producer 程序运行机器上的 CPU 资源要很充足。如果 Producer 运行机器本身 CPU 已经消耗殆尽了，那么启用消息压缩无疑是雪上加霜，只会适得其反。


除了 CPU 资源充足这一条件，如果你的环境中带宽资源有限，那么我也建议你开启压缩。事实上我见过的很多 Kafka 生产环境都遭遇过带宽被打满的情况。这年头，带宽可是比 CPU 和内存还要珍贵的稀缺资源，毕竟万兆网络还不是普通公司的标配，因此千兆网络中 Kafka 集群带宽资源耗尽这件事情就特别容易出现。如果你的客户端机器 CPU 资源有很多富余，我强烈建议你开启 zstd 压缩，这样能极大地节省网络资源消耗。


其次说说解压缩。其实也没什么可说的。一旦启用压缩，解压缩是不可避免的事情。这里只想强调一点：我们对不可抗拒的解压缩无能为力，但至少能规避掉那些意料之外的解压缩。就像我前面说的，因为要兼容老版本而引入的解压缩操作就属于这类。有条件的话尽量保证不要出现消息格式转换的情况。

序列化在Spark中的用处

• 在算子函数中使用到外部变量时，该变量会被序列化后进行网络传输

• 将自定义的类型作为RDD的泛型类型时（比如JavaRDD，Student是自定义类型），所有自定义类型对象，都会进行序列化。因此这种情况下，也要求自定义的类必须实现Serializable接口。
  

• 使用可序列化的持久化策略时（比如MEMORY_ONLY_SER），Spark会将RDD中的每个partition都序列化成一个大的字节数组。
  
  

  Java序列化与Kryo序列化对比

• Java序列化：采用objectOutputStream对象进行序列化，任何的类实现一个 java.io.Serializable接口都可以进行序列化，尽管Java序列化操作十分灵活，但是却十分缓慢，会产生更大的序列化类

• Kryo序列化：kryo序列化更快且比Java占用空间更小。但是并不支持所有序列化类，需要事先在应用程序中注册类
  
  

  kryo启动方式

  在conf中配置：

  1	"spark.serializer="org.apache.spark.serializer.KryoSerializer"

调优

• spark.kryoserializer.buffer 这个是core中kryo缓存的大小，每个core一个，默认64K
  
• spark.kryoserializer.buffer.max 这个是缓存的最大大小，默认为64M，序列化的类最大不可超过2G
  

测试

普通不序列化的MEMORY_ONLY

1
2
3
4
5
6
7
8

val persons=new ArrayBuffer[Person]
for(i<-1 to 1000000)
{
persons+=(Person("name"+i,10+i,"male","haerbin"))
}
val personrdd=sc.parallelize(persons)
personrdd.persist(StorageLevel.MEMORY_ONLY)
personrdd.count()

结果：95.3M


使用Java序列化的MEMORY_ONLY_SER

1
2
3
4
5
6
7
8

val persons=new ArrayBuffer[Person]
for(i<-1 to 1000000)
{
persons+=(Person("name"+i,10+i,"male","haerbin"))
}
val personrdd=sc.parallelize(persons)
personrdd.persist(StorageLevel.MEMORY_ONLY_SER)
personrdd.count()

结果：39.8M


kryo的未注册类的MEMORY_ONLY_SER

1
2
3
4
5
6
7
8

val persons=new ArrayBuffer[Person]
for(i<-1 to 1000000)
{
persons+=(Person("name"+i,10+i,"male","haerbin"))
}
val personrdd=sc.parallelize(persons)
personrdd.persist(StorageLevel.MEMORY_ONLY_SER)
personrdd.count()

结果：119.1M，之所以会发生这种情况，是因为没有注册类，所以kryo就将所有的类进行操作，所有导致占用很大内存


使用kryo注册类，然后打包到集群运行（这种方式命令行看不到效果）

1
2
3
4
5
6
7
8
9
10
11
12
13

sc.getConf.registerKryoClasses(Array(classOf[Person]))
val persons=new ArrayBuffer[Person]
for(i<-1 to 1000000)
{
persons+=(Person("name"+i,10+i,"male","haerbin"))
}
val personrdd=sc.parallelize(persons)
personrdd.persist(StorageLevel.MEMORY_ONLY_SER)
使用submit提交jar包
--class sparkcore.SerializerApp \
--name SerializerApp \
--master yarn \
 /home/hadoop/lib2/scala6-1.0.jar

结果 ：27.5M，结果显而易见，kryo效果更好

序列化时间

实体类

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44

import java.io.Serializable;
import java.util.Map;

public class Simple  implements Serializable
{  
     private static final long serialVersionUID = -4914434736682797743L;  
     private String name;  
     private int age;  
     private Map<String,Integer> map;  
     public Simple(){  
  
     }  
     public Simple(String name,int age,Map<String,Integer> map){  
         this.name = name;  
         this.age = age;  
         this.map = map;  
     }  
  
     public String getName() {  
       return name;  
     }  
  
     public void setName(String name) {  
        this.name = name;  
     }  
  
     public int getAge() {  
        return age;  
     }  
  
     public void setAge(int age) {  
        this.age = age;  
     }  
  
     public Map<String, Integer> getMap() {  
        return map;  
     }  
  
     public void setMap(Map<String, Integer> map) {  
        this.map = map;  
     }  
  
  
}

java原生序列化 OriginalSerializable.java

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61

import java.io.FileInputStream;
import java.io.FileNotFoundException;
import java.io.FileOutputStream;
import java.io.IOException;
import java.io.ObjectInputStream;
import java.io.ObjectOutputStream;
import java.util.HashMap;
import java.util.Map;

import bhz.entity.Simple;

public class OriginalSerializable {  
      
    public static void main(String[] args) throws IOException, ClassNotFoundException {  
        long start =  System.currentTimeMillis();  
        setSerializableObject();  
        System.out.println("java原生序列化时间:" + (System.currentTimeMillis() - start) + " ms" );    
        start =  System.currentTimeMillis();  
        getSerializableObject();  
        System.out.println("java原生反序列化时间:" + (System.currentTimeMillis() - start) + " ms");  
    }  
  
    public static void setSerializableObject() throws IOException{  
  
        FileOutputStream fo = new FileOutputStream("D:/file2.bin");  
  
        ObjectOutputStream so = new ObjectOutputStream(fo);  
  
        for (int i = 0; i < 100000; i++) {  
            Map<String,Integer> map = new HashMap<String, Integer>(2);  
            map.put("zhang0", i);  
            map.put("zhang1", i);  
            so.writeObject(new Simple("zhang"+i,(i+1),map));  
        }  
        so.flush();  
        so.close();  
    }  
  
    public static void getSerializableObject(){  
         FileInputStream fi;  
        try {  
            fi = new FileInputStream("D:/file2.bin");  
            ObjectInputStream si = new ObjectInputStream(fi);  
  
            Simple simple =null;  
            while((simple=(Simple)si.readObject()) != null){  
                //System.out.println(simple.getAge() + "  " + simple.getName());  
            }  
            fi.close();  
            si.close();  
        } catch (FileNotFoundException e) {  
            e.printStackTrace();  
        } catch (IOException e) {  
            //e.printStackTrace();  
        } catch (ClassNotFoundException e) {  
            e.printStackTrace();  
        }  

    }  
  
}

kyro序列化 KyroSerializable.java

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69

import java.io.FileInputStream;
import java.io.FileNotFoundException;
import java.io.FileOutputStream;
import java.io.IOException;
import java.util.HashMap;
import java.util.Map;

import org.objenesis.strategy.StdInstantiatorStrategy;

import bhz.entity.Simple;

import com.esotericsoftware.kryo.Kryo;
import com.esotericsoftware.kryo.KryoException;
import com.esotericsoftware.kryo.io.Input;
import com.esotericsoftware.kryo.io.Output;

public class KyroSerializable {  
      
    public static void main(String[] args) throws IOException {  
        long start =  System.currentTimeMillis();  
        setSerializableObject();  
        System.out.println("Kryo 序列化时间:" + (System.currentTimeMillis() - start) + " ms" );  
        start =  System.currentTimeMillis();  
        getSerializableObject();  
        System.out.println("Kryo 反序列化时间:" + (System.currentTimeMillis() - start) + " ms");  
  
    }  
  
    public static void setSerializableObject() throws FileNotFoundException{  
  
        Kryo kryo = new Kryo();  
        kryo.setReferences(false);  
        kryo.setRegistrationRequired(false);  
        kryo.setInstantiatorStrategy(new StdInstantiatorStrategy());  
        kryo.register(Simple.class);  
        Output output = new Output(new FileOutputStream("D:/file1.bin"));  
        for (int i = 0; i < 100000; i++) {  
            Map<String,Integer> map = new HashMap<String, Integer>(2);  
            map.put("zhang0", i);  
            map.put("zhang1", i);  
            kryo.writeObject(output, new Simple("zhang"+i,(i+1),map));  
        }  
        output.flush();  
        output.close();  
    }  
  
  
    public static void getSerializableObject(){  
        Kryo kryo = new Kryo();  
        kryo.setReferences(false);  
        kryo.setRegistrationRequired(false);  
        kryo.setInstantiatorStrategy(new StdInstantiatorStrategy());  
        Input input;  
        try {  
            input = new Input(new FileInputStream("D:/file1.bin"));  
            Simple simple =null;  
            while((simple=kryo.readObject(input, Simple.class)) != null){  
                //System.out.println(simple.getAge() + "  " + simple.getName() + "  " + simple.getMap().toString());  
            }  
  
            input.close();  
        } catch (FileNotFoundException e) {  
            e.printStackTrace();  
        } catch(KryoException e){  
  
        }  
    }  
  
}

**

java原生序列化时间:8281 ms
java原生反序列化时间:5899 ms

Kryo 序列化时间:630 ms
Kryo 反序列化时间:15 ms

经过对比，可以发现kryo是java原生序列化性能十几倍


官方也推荐尽量使用Kryo的序列化库（版本2）。官文介绍，Kryo序列化机制比Java序列化机制性能提高10倍左右，Spark之所以没有默认使用Kryo作为序列化类库，是因为它不支持所有对象的序列化，同时Kryo需要用户在使用前注册需要序列化的类型，不够方便。

经典数据库 Redis 中的常用数据类型，底层都是用哪种数据结构实现的？

Redis 数据库介绍

Redis 是一种键值（Key-Value）数据库。相对于关系型数据库（比如 MySQL），Redis 也被叫作非关系型数据库。像 MySQL 这样的关系型数据库，表的结构比较复杂，会包含很多字段，可以通过 SQL 语句，来实现非常复杂的查询需求。而 Redis 中只包含“键”和“值”两部分，只能通过“键”来查询“值”。


正是因为这样简单的存储结构，也让 Redis 的读写效率非常高。除此之外，Redis 主要是作为内存数据库来使用，也就是说，数据是存储在内存中的。尽管它经常被用作内存数据库，但是，它也支持将数据存储在硬盘中。


这一点，我们后面会介绍。Redis 中，键的数据类型是字符串，但是为了丰富数据存储的方式，方便开发者使用，值的数据类型有很多，常用的数据类型有这样几种，它们分别是字符串、列表、字典、集合、有序集合。


“字符串（string）”这种数据类型非常简单，对应到数据结构里，就是字符串。你应该非常熟悉，这里我就不多介绍了。我们着重看下，其他四种比较复杂点的数据类型，看看它们底层都依赖了哪些数据结构。

列表（list）

我们先来看列表。列表这种数据类型支持存储一组数据。这种数据类型对应两种实现方法，一种是压缩列表（ziplist），另一种是双向循环链表。


当列表中存储的数据量比较小的时候，列表就可以采用压缩列表的方式实现。具体需要同时满足下面两个条件：列表中保存的单个数据（有可能是字符串类型的）小于 64 字节；列表中数据个数少于 512 个。


关于压缩列表，我这里稍微解释一下。它并不是基础数据结构，而是 Redis 自己设计的一种数据存储结构。它有点儿类似数组，通过一片连续的内存空间，来存储数据，压缩列表不支持随机访问，Redis一般都是通过key获取整个value的值，也就是整个压缩列表的数据，并不需要随机访问。不过，它跟数组不同的一点是，它允许存储的数据大小不同。具体的存储结构也非常简单，你可以看我下面画的这幅图。



现在，我们来看看，压缩列表中的“压缩”两个字该如何理解？听到“压缩”两个字，直观的反应就是节省内存。之所以说这种存储结构节省内存，是相较于数组的存储思路而言的。我们知道，数组要求每个元素的大小相同，如果我们要存储不同长度的字符串，那我们就需要用最大长度的字符串大小作为元素的大小（假设是 20 个字节）。那当我们存储小于 20 个字节长度的字符串的时候，便会浪费部分存储空间。听起来有点儿拗口，我画个图解释一下。

压缩列表这种存储结构，一方面比较节省内存，另一方面可以支持不同类型数据的存储。


而且，因为数据存储在一片连续的内存空间，通过键来获取值为列表类型的数据，读取的效率也非常高。当列表中存储的数据量比较大的时候，也就是不能同时满足刚刚讲的两个条件的时候，列表就要通过双向循环链表来实现了。


在链表里，我们已经讲过双向循环链表这种数据结构了。这里我们着重看一下 Redis 中双向链表的编码实现方式。Redis 的这种双向链表的实现方式，非常值得借鉴。它额外定义一个 list 结构体，来组织链表的首、尾指针，还有长度等信息。这样，在使用的时候就会非常方便。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

// 以下是C语言代码，因为Redis是用C语言实现的。
typedef struct listnode {
  struct listNode *prev;
  struct listNode *next;
  void *value;
} listNode;


typedef struct list {
  listNode *head;
  listNode *tail;
  unsigned long len;
  // ....省略其他定义
} list;

字典（hash）

字典类型用来存储一组数据对。每个数据对又包含键值两部分。字典类型也有两种实现方式。一种是我们刚刚讲到的压缩列表，另一种是散列表。


同样，只有当存储的数据量比较小的情况下，Redis 才使用压缩列表来实现字典类型。具体需要满足两个条件：字典中保存的键和值的大小都要小于 64 字节；字典中键值对的个数要小于 512 个。


当不能同时满足上面两个条件的时候，Redis 就使用散列表来实现字典类型。Redis 使用MurmurHash2这种运行速度快、随机性好的哈希算法作为哈希函数。对于哈希冲突问题，Redis 使用链表法来解决。


除此之外，Redis 还支持散列表的动态扩容、缩容。当数据动态增加之后，散列表的装载因子会不停地变大。为了避免散列表性能的下降，当装载因子大于 1 的时候，Redis 会触发扩容，将散列表扩大为原来大小的 2 倍左右（具体值需要计算才能得到，如果感兴趣，你可以去阅读源码）。


当数据动态减少之后，为了节省内存，当装载因子小于 0.1 的时候，Redis 就会触发缩容，缩小为字典中数据个数的大约 2 倍大小（这个值也是计算得到的，如果感兴趣，你也可以去阅读源码）。我们前面讲过，扩容缩容要做大量的数据搬移和哈希值的重新计算，所以比较耗时。针对这个问题，Redis 使用我们在散列表（中）讲的渐进式扩容缩容策略，将数据的搬移分批进行，避免了大量数据一次性搬移导致的服务停顿。

集合（set）

集合这种数据类型用来存储一组不重复的数据。这种数据类型也有两种实现方法，一种是基于有序数组，另一种是基于散列表。


当要存储的数据，同时满足下面这样两个条件的时候，Redis 就采用有序数组，来实现集合这种数据类型。存储的数据都是整数；存储的数据元素个数不超过 512 个。当不能同时满足这两个条件的时候，Redis 就使用散列表来存储集合中的数据。

有序集合（sortedset）

有序集合这种数据类型，我们在跳表里已经详细讲过了。它用来存储一组数据，并且每个数据会附带一个得分。通过得分的大小，我们将数据组织成跳表这样的数据结构，以支持快速地按照得分值、得分区间获取数据。


实际上，跟 Redis 的其他数据类型一样，有序集合也并不仅仅只有跳表这一种实现方式。当数据量比较小的时候，Redis 会用压缩列表来实现有序集合。具体点说就是，使用压缩列表来实现有序集合的前提，有这样两个：所有数据的大小都要小于 64 字节；元素个数要小于 128 个。

数据结构持久化

尽管 Redis 经常会被用作内存数据库，但是，它也支持数据落盘，也就是将内存中的数据存储到硬盘中。这样，当机器断电的时候，存储在 Redis 中的数据也不会丢失。在机器重新启动之后，Redis 只需要再将存储在硬盘中的数据，重新读取到内存，就可以继续工作了。


刚刚我们讲到，Redis 的数据格式由“键”和“值”两部分组成。而“值”又支持很多数据类型，比如字符串、列表、字典、集合、有序集合。像字典、集合等类型，底层用到了散列表，散列表中有指针的概念，而指针指向的是内存中的存储地址。 那 Redis 是如何将这样一个跟具体内存地址有关的数据结构存储到磁盘中的呢？


实际上，Redis 遇到的这个问题并不特殊，很多场景中都会遇到。我们把它叫作数据结构的持久化问题，或者对象的持久化问题。这里的“持久化”，你可以笼统地理解为“存储到磁盘”。如何将数据结构持久化到硬盘？我们主要有两种解决思路。第一种是清除原有的存储结构，只将数据存储到磁盘中。当我们需要从磁盘还原数据到内存的时候，再重新将数据组织成原来的数据结构。


实际上，Redis 采用的就是这种持久化思路。不过，这种方式也有一定的弊端。那就是数据从硬盘还原到内存的过程，会耗用比较多的时间。比如，我们现在要将散列表中的数据存储到磁盘。当我们从磁盘中，取出数据重新构建散列表的时候，需要重新计算每个数据的哈希值。如果磁盘中存储的是几 GB 的数据，那重构数据结构的耗时就不可忽视了。


第二种方式是保留原来的存储格式，将数据按照原有的格式存储在磁盘中。我们拿散列表这样的数据结构来举例。我们可以将散列表的大小、每个数据被散列到的槽的编号等信息，都保存在磁盘中。有了这些信息，我们从磁盘中将数据还原到内存中的时候，就可以避免重新计算哈希值。

总结

今天，我们学习了 Redis 中常用数据类型底层依赖的数据结构，总结一下大概有这五种：

• 压缩列表（可以看作一种特殊的数组）
• 有序数组
• 链表
• 散列表
• 跳表

Q&A

Q:为什么redis没有使用B+树而选择跳表？
A:跳表更灵活 更容易实现

Paxos是共识算法，不是一致性协议

Basic Paxos 只能就单个值（Value）达成共识，一旦遇到为一系列的值实现共识的时候，它就不管用了。虽然兰伯特提到可以通过多次执行 Basic Paxos 实例（比如每接收到一个值时，就执行一次 Basic Paxos 算法）实现一系列值的共识。但是，很多同学读完论文后，应该还是两眼摸黑，虽然每个英文单词都能读懂，但还是不理解兰伯特提到的 Multi-Paxos，为什么 Multi-Paxos 这么难理解呢？


在我看来，兰伯特并没有把 Multi-Paxos 讲清楚，只是介绍了大概的思想，缺少算法过程的细节和编程所必须的细节（比如缺少选举领导者的细节）。这也就导致每个人实现的 Multi-Paxos 都不一样。不过从本质上看，大家都是在兰伯特提到的 Multi-Paxos 思想上补充细节，设计自己的 Multi-Paxos 算法，然后实现它（比如 Chubby 的 Multi-Paxos 实现、Raft 算法等）。


所以在这里，我补充一下：兰伯特提到的 Multi-Paxos 是一种思想，不是算法。而 Multi-Paxos 算法是一个统称，它是指基于 Multi-Paxos 思想，通过多个 Basic Paxos 实例实现一系列值的共识的算法（比如 Chubby 的 Multi-Paxos 实现、Raft 算法等）。 这一点尤其需要你注意。


为了帮你掌握 Multi-Paxos 思想，我会先带你了解，对于 Multi-Paxos 兰伯特是如何思考的，也就是说，如何解决 Basic Paxos 的痛点问题；然后我再以 Chubby 的 Multi-Paxos 实现为例，具体讲解一下。为啥选它呢？因为 Chubby 的 Multi-Paxos 实现，代表了 Multi-Paxos 思想在生产环境中的真正落地，它将一种思想变成了代码实现。贴一段6年前的代码🐂

兰伯特关于 Multi-Paxos 的思考

熟悉 Basic Paxos 的同学可能还记得，Basic Paxos 是通过二阶段提交来达成共识的。在第一阶段，也就是准备阶段，接收到大多数准备响应的提议者，才能发起接受请求进入第二阶段（也就是接受阶段）：

而如果我们直接通过多次执行 Basic Paxos 实例，来实现一系列值的共识，就会存在这样几个问题：如果多个提议者同时提交提案，可能出现因为提案编号冲突，在准备阶段没有提议者接收到大多数准备响应，协商失败，需要重新协商。


你想象一下，一个 5 节点的集群，如果 3 个节点作为提议者同时提案，就可能发生因为没有提议者接收大多数响应（比如 1 个提议者接收到 1 个准备响应，另外 2 个提议者分别接收到 2 个准备响应）而准备失败，需要重新协商。2 轮 RPC 通讯（准备阶段和接受阶段）往返消息多、耗性能、延迟大。


你要知道，分布式系统的运行是建立在 RPC 通讯的基础之上的，因此，延迟一直是分布式系统的痛点，是需要我们在开发分布式系统时认真考虑和优化的。那么如何解决上面的 2 个问题呢？可以通过引入领导者和优化 Basic Paxos 执行来解决，咱们首先聊一聊领导者。

领导者（Leader）

我们可以通过引入领导者节点，也就是说，领导者节点作为唯一提议者，这样就不存在多个提议者同时提交提案的情况，也就不存在提案冲突的情况了：

在这里，我补充一点：在论文中，兰伯特没有说如何选举领导者，需要我们在实现 Multi-Paxos 算法的时候自己实现。 比如在 Chubby 中，主节点（也就是领导者节点）是通过执行 Basic Paxos 算法，进行投票选举产生的。那么，如何解决第二个问题，也就是如何优化 Basic Paxos 执行呢？

优化 Basic Paxos 执行

我们可以采用“当领导者处于稳定状态时，省掉准备阶段，直接进入接受阶段”这个优化机制，优化 Basic Paxos 执行。也就是说，领导者节点上，序列中的命令是最新的，不再需要通过准备请求来发现之前被大多数节点通过的提案，领导者可以独立指定提案中的值。这时，领导者在提交命令时，可以省掉准备阶段，直接进入到接受阶段：

你看，和重复执行 Basic Paxos 相比，Multi-Paxos 引入领导者节点之后，因为只有领导者节点一个提议者，只有它说了算，所以就不存在提案冲突。另外，当主节点处于稳定状态时，就省掉准备阶段，直接进入接受阶段，所以在很大程度上减少了往返的消息数，提升了性能，降低了延迟。讲到这儿，你可能会问了：在实际系统中，该如何实现 Multi-Paxos 呢？接下来，我以 Chubby 的 Multi-Paxos 实现为例，具体讲解一下。

Chubby 的 Multi-Paxos 实现

既然兰伯特只是大概的介绍了 Multi-Paxos 思想，那么 Chubby 是如何补充细节，实现 Multi-Paxos 算法的呢？首先，它通过引入主节点，实现了兰伯特提到的领导者（Leader）节点的特性。也就是说，主节点作为唯一提议者，这样就不存在多个提议者同时提交提案的情况，也就不存在提案冲突的情况了。


另外，在 Chubby 中，主节点是通过执行 Basic Paxos 算法，进行投票选举产生的，并且在运行过程中，主节点会通过不断续租的方式来延长租期（Lease）。比如在实际场景中，几天内都是同一个节点作为主节点。如果主节点故障了，那么其他的节点又会投票选举出新的主节点，也就是说主节点是一直存在的，而且是唯一的。其次，在 Chubby 中实现了兰伯特提到的，“当领导者处于稳定状态时，省掉准备阶段，直接进入接受阶段”这个优化机制。


最后，在 Chubby 中，实现了成员变更（Group membership），以此保证节点变更的时候集群的平稳运行。最后，我想补充一点：在 Chubby 中，为了实现了强一致性，读操作也只能在主节点上执行。 也就是说，只要数据写入成功，之后所有的客户端读到的数据都是一致的。具体的过程，就是下面的样子。


所有的读请求和写请求都由主节点来处理。当主节点从客户端接收到写请求后，作为提议者，执行 Basic Paxos 实例，将数据发送给所有的节点，并且在大多数的服务器接受了这个写请求之后，再响应给客户端成功：

当主节点接收到读请求后，处理就比较简单了，主节点只需要查询本地数据，然后返回给客户端就可以了：


Chubby 的 Multi-Paxos 实现，尽管是一个闭源的实现，但这是 Multi-Paxos 思想在实际场景中的真正落地，Chubby 团队不仅编程实现了理论，还探索了如何补充细节。其中的思考和设计非常具有参考价值，不仅能帮助我们理解 Multi-Paxos 思想，还能帮助我们理解其他的 Multi-Paxos 算法（比如 Raft 算法）。

内容小结

重点如下：

• 兰伯特提到的 Multi-Paxos 是一种思想，不是算法，而且还缺少算法过程的细节和编程所必须的细节，比如如何选举领导者等，这也就导致了每个人实现的 Multi-Paxos 都不一样。而 Multi-Paxos 算法是一个统称，它是指基于 Multi-Paxos 思想，通过多个 Basic Paxos 实例实现一系列数据的共识的算法（比如 Chubby 的 Multi-Paxos 实现、Raft 算法等）。
• Chubby 实现了主节点（也就是兰伯特提到的领导者），也实现了兰伯特提到的 “当领导者处于稳定状态时，省掉准备阶段，直接进入接受阶段” 这个优化机制，省掉 Basic Paxos 的准备阶段，提升了数据的提交效率，但是所有写请求都在主节点处理，限制了集群处理写请求的并发能力，约等于单机。
• 因为在 Chubby 的 Multi-Paxos 实现中，也约定了“大多数原则”，也就是说，只要大多数节点正常运行时，集群就能正常工作，所以 Chubby 能容错（n - 1）/2 个节点的故障。
• 本质上而言，“当领导者处于稳定状态时，省掉准备阶段，直接进入接受阶段”这个优化机制，是通过减少非必须的协商步骤来提升性能的。这种方法非常常用，也很有效。比如，Google 设计的 QUIC 协议，是通过减少 TCP、TLS 的协商步骤，优化 HTTPS 性能。我希望你能掌握这种性能优化思路，后续在需要时，可以通过减少非必须的步骤，优化系统性能。

最后，我想说的是，我个人比较喜欢 Paxos 算法（兰伯特的 Basic Paxos 和 Multi-Paxos），虽然 Multi-Paxos 缺失算法细节，但这反而给我们提供了思考空间，让我们可以反复思考和考据缺失的细节，比如在 Multi-Paxos 中到底需不需要选举领导者，再比如如何实现提案编号等等。

生有涯知无涯，只有掌握了最核心的“道”，才能以不变应万变。

Paxos 算法

提到分布式算法，就不得不提 Paxos 算法，在过去几十年里，它基本上是分布式共识的代名词，因为当前最常用的一批共识算法都是基于它改进的。比如，Fast Paxos 算法、Cheap Paxos 算法、Raft 算法等等。而很多同学都会在准确和系统理解 Paxos 算法上踩坑，比如，只知道它可以用来达成共识，但不知道它是如何达成共识的。


这其实侧面说明了 Paxos 算法有一定的难度，可分布式算法本身就很复杂，Paxos 算法自然也不会例外，当然了，除了这一点，还跟兰伯特有关。兰伯特提出的 Paxos 算法包含 2 个部分：

• 一个是 Basic Paxos 算法，描述的是多节点之间如何就某个值（提案 Value）达成共识；
• 另一个是 Multi-Paxos 思想，描述的是执行多个 Basic Paxos 实例，就一系列值达成共识。

可因为兰伯特提到的 Multi-Paxos 思想，缺少代码实现的必要细节（比如怎么选举领导者），这里举一段十年前的代码🐂，接下来分别以 Basic Paxos 和 Multi-Paxos 为核心，带你了解 Basic Paxos 如何达成共识，以及针对 Basic Paxos 的局限性 Multi-Paxos 又是如何改进的。今天咱们先来聊聊 Basic Paxos。


在我看来，Basic Paxos 是 Multi-Paxos 思想的核心，说白了，Multi-Paxos 就是多执行几次 Basic Paxos。所以掌握它之后，你能更好地理解后几讲基于 Multi-Paxos 思想的共识算法（比如 Raft 算法），还能掌握分布式共识算法的最核心内容，当现在的算法不能满足业务需求，进行权衡折中，设计自己的算法。


假设我们要实现一个分布式集群，这个集群是由节点 A、B、C 组成，提供只读 KV 存储服务。你应该知道，创建只读变量的时候，必须要对它进行赋值，而且这个值后续没办法修改。因此一个节点创建只读变量后就不能再修改它了，所以所有节点必须要先对只读变量的值达成共识，然后所有节点再一起创建这个只读变量。


那么，当有多个客户端（比如客户端 1、2）访问这个系统，试图创建同一个只读变量（比如 X），客户端 1 试图创建值为 3 的 X，客户端 2 试图创建值为 7 的 X，这样要如何达成共识，实现各节点上 X 值的一致呢？带着这个问题，我们进入今天的学习。

在一些经典的算法中，你会看到一些既形象又独有的概念（比如二阶段提交协议中的协调者），Basic Paxos 算法也不例外。为了帮助人们更好地理解 Basic Paxos 算法，兰伯特在讲解时，也使用了一些独有而且比较重要的概念，提案、准备（Prepare）请求、接受（Accept）请求、角色等等，其中最重要的就是“角色”。因为角色是对 Basic Paxos 中最核心的三个功能的抽象，比如，由接受者（Acceptor）对提议的值进行投票，并存储接受的值。

你需要了解的三种角色

在 Basic Paxos 中，有提议者（Proposer）、接受者（Acceptor）、学习者（Learner）三种角色，他们之间的关系如下：

看着是不是有些复杂，其实并不难理解：

• 提议者（Proposer）：提议一个值，用于投票表决。为了方便演示，你可以把图 1 中的客户端 1 和 2 看作是提议者。但在绝大多数场景中，集群中收到客户端请求的节点，才是提议者（图 1 这个架构，是为了方便演示算法原理）。这样做的好处是，对业务代码没有入侵性，也就是说，我们不需要在业务代码中实现算法逻辑，就可以像使用数据库一样访问后端的数据。
• 接受者（Acceptor）：对每个提议的值进行投票，并存储接受的值，比如 A、B、C 三个节点。 一般来说，集群中的所有节点都在扮演接受者的角色，参与共识协商，并接受和存储数据。

讲到这儿，你可能会有疑惑：前面不是说接收客户端请求的节点是提议者吗？这里怎么又是接受者呢？这是因为一个节点（或进程）可以身兼多个角色。想象一下，一个 3 节点的集群，1 个节点收到了请求，那么该节点将作为提议者发起二阶段提交，然后这个节点和另外 2 个节点一起作为接受者进行共识协商，就像下图的样子：

• 学习者（Learner）：被告知投票的结果，接受达成共识的值，存储保存，不参与投票的过程。

一般来说，学习者是数据备份节点，比如“Master-Slave”模型中的 Slave，被动地接受数据，容灾备份。其实，这三种角色，在本质上代表的是三种功能：

• 提议者代表的是接入和协调功能，收到客户端请求后，发起二阶段提交，进行共识协商；
• 接受者代表投票协商和存储数据，对提议的值进行投票，并接受达成共识的值，存储保存；
• 学习者代表存储数据，不参与共识协商，只接受达成共识的值，存储保存。

因为一个完整的算法过程是由这三种角色对应的功能组成的，所以理解这三种角色，是你理解 Basic Paxos 如何就提议的值达成共识的基础。

如何达成共识？

想象这样一个场景，现在疫情这么严重，每个村的路都封得差不多了，就你的村委会不作为，迟迟没有什么防疫的措施。你决定给村委会提交个提案，提一些防疫的建议，除了建议之外，为了和其他村民的提案做区分，你的提案还得包含一个提案编号，来起到唯一标识的作用。与你的做法类似，在 Basic Paxos 中，兰伯特也使用提案代表一个提议。不过在提案中，除了提案编号，还包含了提议值。


为了方便演示，我使用[n, v]表示一个提案，其中 n 为提案编号，v 为提议值。我想强调一下，整个共识协商是分 2 个阶段进行的。


那么具体要如何协商呢？我们假设客户端 1 的提案编号为 1，客户端 2 的提案编号为 5，并假设节点 A、B 先收到来自客户端 1 的准备请求，节点 C 先收到来自客户端 2 的准备请求。

准备（Prepare）阶段

• 先来看第一个阶段，首先客户端 1、2 作为提议者，分别向所有接受者发送包含提案编号的准备请求：

你要注意，在准备请求中是不需要指定提议的值的，只需要携带提案编号就可以了，这是很多同学容易产生误解的地方。


接着，当节点 A、B 收到提案编号为 1 的准备请求，节点 C 收到提案编号为 5 的准备请求后，将进行这样的处理：

• 由于之前没有通过任何提案，所以节点 A、B 将返回一个 “尚无提案”的响应。也就是说节点 A 和 B 在告诉提议者，我之前没有通过任何提案呢，并承诺以后不再响应提案编号小于等于 1 的准备请求，不会通过编号小于 1 的提案。
• 节点 C 也是如此，它将返回一个 “尚无提案”的响应，并承诺以后不再响应提案编号小于等于 5 的准备请求，不会通过编号小于 5 的提案。

另外，当节点 A、B 收到提案编号为 5 的准备请求，和节点 C 收到提案编号为 1 的准备请求的时候，将进行这样的处理过程：

• 当节点 A、B 收到提案编号为 5 的准备请求的时候，因为提案编号 5 大于它们之前响应的准备请求的提案编号 1，而且两个节点都没有通过任何提案，所以它将返回一个 “尚无提案”的响应，并承诺以后不再响应提案编号小于等于 5 的准备请求，不会通过编号小于 5 的提案。
• 当节点 C 收到提案编号为 1 的准备请求的时候，由于提案编号 1 小于它之前响应的准备请求的提案编号 5，所以丢弃该准备请求，不做响应。

接受（Accept）阶段

第二个阶段也就是接受阶段，首先客户端 1、2 在收到大多数节点的准备响应之后，会分别发送接受请求：

• 当客户端 1 收到大多数的接受者（节点 A、B）的准备响应后，根据响应中提案编号最大的提案的值，设置接受请求中的值。因为该值在来自节点 A、B 的准备响应中都为空（也就是图 5 中的“尚无提案”），所以就把自己的提议值 3 作为提案的值，发送接受请求[1, 3]。
• 当客户端 2 收到大多数的接受者的准备响应后（节点 A、B 和节点 C），根据响应中提案编号最大的提案的值，来设置接受请求中的值。因为该值在来自节点 A、B、C 的准备响应中都为空（也就是图 5 和图 6 中的“尚无提案”），所以就把自己的提议值 7 作为提案的值，发送接受请求[5, 7]。

当三个节点收到 2 个客户端的接受请求时，会进行这样的处理：

• 当节点 A、B、C 收到接受请求[1, 3]的时候，由于提案的提案编号 1 小于三个节点承诺能通过的提案的最小提案编号 5，所以提案[1, 3]将被拒绝。
• 当节点 A、B、C 收到接受请求[5, 7]的时候，由于提案的提案编号 5 不小于三个节点承诺能通过的提案的最小提案编号 5，所以就通过提案[5, 7]，也就是接受了值 7，三个节点就 X 值为 7 达成了共识。

讲到这儿我想补充一下，如果集群中有学习者，当接受者通过了一个提案时，就通知给所有的学习者。当学习者发现大多数的接受者都通过了某个提案，那么它也通过该提案，接受该提案的值。


通过上面的演示过程，你可以看到，最终各节点就 X 的值达成了共识。那么在这里我还想强调一下，Basic Paxos 的容错能力，源自“大多数”的约定，你可以这么理解：当少于一半的节点出现故障的时候，共识协商仍然在正常工作。

内容小结

本节课我主要带你了解了 Basic Paxos 的原理和一些特点，我希望你明确这样几个重点。你可以看到，Basic Paxos 是通过二阶段提交的方式来达成共识的。二阶段提交是达成共识的常用方式，如果你需要设计新的共识算法的时候，也可以考虑这个方式。


除了共识，Basic Paxos 还实现了容错，在少于一半的节点出现故障时，集群也能工作。它不像分布式事务算法那样，必须要所有节点都同意后才提交操作，因为“所有节点都同意”这个原则，在出现节点故障的时候会导致整个集群不可用。也就是说，“大多数节点都同意”的原则，赋予了 Basic Paxos 容错的能力，让它能够容忍少于一半的节点的故障。


本质上而言，提案编号的大小代表着优先级，你可以这么理解，根据提案编号的大小，接受者保证三个承诺，具体来说：

• 如果准备请求的提案编号，小于等于接受者已经响应的准备请求的提案编号，那么接受者将承诺不响应这个准备请求；
• 如果接受请求中的提案的提案编号，小于接受者已经响应的准备请求的提案编号，那么接受者将承诺不通过这个提案；
• 如果接受者之前有通过提案，那么接受者将承诺，会在准备请求的响应中，包含已经通过的最大编号的提案信息。

Basic Paxos 算法解决的问题是一个分布式系统如何就某个值X（决议）达成一致。一个典型的场景是，在一个分布式数据库存储中，如果各节点的初始状态一致，每个节点执行相同的操作序列（例如上面是每个节点都要执行SET(X, 3)操作和SET(X, 7)操作，其中SET(X, 3)指令是客户端1向每个节点发出，SET(X, 7)指令是客户端2向每个节点发出），那么他们最后肯定能达到一个一致的状态。例如A、B、C三个节点执行的指令按照顺序都是 SET(X,3)–>SET(X, 7)的话，则A、B、C三个节点最终X的值都是7.


但是网络的不可靠性导致实际上最后每个节点执行的指令顺序并不一样，如果A节点、B节点执行顺序是SET(X,3)–>SET(X,7)，则A、B节点上最后的值就是X=7，而C节点上可能因为网络原因执行的顺序是 SET(X,7)–>SET(X,3), 结果最后C节点上的X值就是3了. 这种情况可能导致客户端发送相同执行指令，但是最终节点上的值不完全相同. 我们当然不希望看到这种情况的发生. 于是 Basic paxos算法横空出世.
basic paxos算法需要在每一条指令上执行一个“一致性算法”以保证每个节点看到的指令一致。

状态是Flink中的一个重要特征，不论是存储在内存中，还是在rockdb中，但是我们有时候需要对状态进行清查，不需要保存太久的状态，否则这个状态会太大，这个时候就会用到Flink的清除。

为什么需要清理状态

其一是Flink中的状态是有时效性的，也就是在一定的实际内，是有效的，一旦过了某个时间点，它就没有什么价值了，其二是需要控制flink的状态大小，能够有效的管理不断增长的state的规模大小。


从flink的1.6中，就引入了关于状态时效性方面的特性，在1.8中，引入了基于TTL的对过去state的清理，让我们可以通过程序的 方式，对state进行清理，否则还的依赖其他额外的操作，来对state清理，这样会容易导致出错，并且不容易控制。


Apache Flink的1.6.0版本引入了State TTL功能。它使流处理应用程序的开发人员配置过期时间，并在定义时间超时（Time to Live）之后进行清理。在Flink 1.8.0中，该功能得到了扩展，包括对RocksDB和堆状态后端（FSStateBackend和MemoryStateBackend）的历史数据进行持续清理，从而实现旧条目的连续清理过程（根据TTL设置）。


Flink程序中的状态，是通过状态描述符来定义的，所以我们定义ttl，是通过flink程序中的StateTtlConfiguration对象，传递给状态描述符，来实现状态的清理。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74

public class StateDemo {
    public static void main(String[] args) throws Exception {
        LocalStreamEnvironment env = StreamExecutionEnvironment.createLocalEnvironment();
        // this can be used in a streaming program like this (assuming we have a StreamExecutionEnvironment env)
        env.fromElements(Tuple2.of(1L, 3L), Tuple2.of(1L, 5L), Tuple2.of(1L, 10L), Tuple2.of(1L, 4L), Tuple2.of(1L, 2L))
                .keyBy(0)
                .flatMap(new MyFlatMapFunction())
                .print();

        // the printed output will be (1,4) and (1,5)
        env.execute();
    }
}

class MyFlatMapFunction extends RichFlatMapFunction<Tuple2<Long, Long>, Tuple2<Long, Long>> {

    private static final long serialVersionUID = 1808329479322205953L;
    /**
     * The ValueState handle. The first field is the count, the second field a running sum.
     */
    private transient ValueState<Tuple2<Long, Long>> sum;

    // 状态过期清除
    // flink 的状态清理是惰性策略，也就是我们访问的状态，可能已经过期了，但是还没有删除状态数据，我们可以配置
    // 是否返回过期状态的数据，不论是否返回过期数据，数据被访问后会立即清除过期状态。并且截止1.8.0 的版本
    // 状态的清除针对的是process time ，还不支持event time，可能在后期的版本中会支持。

    // flink的内部，状态ttl 功能是通过上次相关状态访问的附加时间戳和实际状态值来实现的，这样的方案会增加存储
    // 上的开销，但是会允许flink程序在查询数据，cp的时候访问数据的过期状态
    StateTtlConfig ttlConfig =
            StateTtlConfig.newBuilder(Time.days(1)) //它是生存时间值
                    .setUpdateType(StateTtlConfig.UpdateType.OnCreateAndWrite)
                    //状态可见性配置是否在读取访问时返回过期值
//            .setStateVisibility(StateTtlConfig.StateVisibility.NeverReturnExpired)
                    .cleanupFullSnapshot() // 在快照的时候进行删除
                    .build();


    @Override
    public void flatMap(Tuple2<Long, Long> input, Collector<Tuple2<Long, Long>> out) throws Exception {

        // access the state value
        Tuple2<Long, Long> currentSum = sum.value();

        // update the count
        currentSum.f0 += 1;

        // add the second field of the input value
        currentSum.f1 += input.f1;

        // update the state
        sum.update(currentSum);

        // if the count reaches 2, emit the average and clear the state
        if (currentSum.f0 >= 2) {
            out.collect(new Tuple2<>(input.f0, currentSum.f1 / currentSum.f0));
            sum.clear();
        }
    }

    @Override
    public void open(Configuration config) {
        ValueStateDescriptor<Tuple2<Long, Long>> descriptor =
                new ValueStateDescriptor<>(
                        "average", // the state name
                        TypeInformation.of(new TypeHint<Tuple2<Long, Long>>() {
                        }), // type information
                        Tuple2.of(0L, 0L)); // default value of the state, if nothing was set

        //设置stage过期时间
        descriptor.enableTimeToLive(ttlConfig);
        sum = getRuntimeContext().getState(descriptor);
    }
}

上面是定义了StateTtlConfig ，用于描述状态清除的配置信息，这个类是状态清除的核心配置类。Flink提供了多个选项来配置TTL功能的行为。

状态的时间什么被修改？

默认情况下，是当我们的数据状态修改会更新数据的ttl时间，当然我们也可以在读取数据时候对它进行更新，这样做会出现额外写入操作来更新时间戳操作。

过去的状态数据是否可以访问？

state ttl采用惰性策略来清理过期状态。这可能导致我们的应用程序会去尝试读取已过期但处于尚未删除状态的数据。我们可以观察此类读取请求是否返回了过期状态。无论哪种情况，数据被访问后会立即清除过期状态

注意**
使用Flink 1.8.0，用户只能根据处理时间（Processing Time）定义状态TTL。未来的Apache Flink版本中计划支持事件时间（Event Time）
Flink内部，状态TTL功能是通过存储上次相关状态访问的附加时间戳以及实际状态值来实现的。虽然这种方法增加了一些存储开销，但它允许Flink程序在查询数据、checkpointing，数据恢复的时候访问数据的过期状态。

如何避免读取过期数据？

在读取操作中访问状态对象时，Flink将检查其时间戳并清除状态是否已过期（取决于配置的状态可见性，是否返回过期状态）。由于这种延迟删除的特性，永远不会再次访问的过期状态数据将永远占用存储空间，除非被垃圾回收。


那么如何在没有应用程序逻辑明确的处理它的情况下删除过期的状态呢？通常，我们可以配置不同的策略进行后台删除。

完整快照自动删除过期状态

当获取检查点或保存点的完整快照时，Flink 1.6.0已经支持自动删除过期状态。大家注意，过期状态删除不适用于增量检查点。必须明确启用完全快照的状态删除

1
2
3
4
5
6
7
8
9
10
11

StateTtlConfig ttlConfig =
            StateTtlConfig.newBuilder(Time.days(1)) //它是生存时间值
                    .setUpdateType(StateTtlConfig.UpdateType.OnCreateAndWrite)
                    .cleanupFullSnapshot() // 在快照的时候进行删除
                    .build();
/** Cleanup expired state in full snapshot on checkpoint. */
@Nonnull
public Builder cleanupFullSnapshot() {
cleanupStrategies.activate(CleanupStrategies.Strategies.FULL_STATE_SCAN_SNAPSHOT);
return this;
}

堆状态后端的增量清理**
此方法特定于堆状态后端（FSStateBackend和MemoryStateBackend）。它的实现方法是存储后端在所有状态条目上维护一个惰性全局迭代器。某些事件（例如状态访问）会触发增量清理。每次触发增量清理时，迭代器都会向前迭代删除已遍历的过期数据。以下代码示例演示如何启用增量清理

1
2
3
4
5

StateTtlConfig ttlConfig =
            StateTtlConfig.newBuilder(Time.days(1)) //它是生存时间值
                    .setUpdateType(StateTtlConfig.UpdateType.OnCreateAndWrite)
                    .cleanupIncrementally(15,false)//
                    .build();

如果启用，则每次进行状态访问都会触发清理步骤。对于每个清理步骤，都会检查一定数量的数据是否过期。
参数说明：
第一个参数是检查每个清理步骤的状态条目数。
第二个参数是一个标志，用于数据处理后触发清理步骤，此外对于每次状态访问同样有效。

注意**
第一个是增量清理所花费的时间增加了数据处理延迟。
第二个应该可以忽略不计，但仍然值得一提：如果没有状态访问或没有数据处理记录，则不会删除过期状态

RocksDB后台压缩可以过滤掉过期状态

如果你的Flink应用程序使用RocksDB作为状态后端存储，则可以启用另一个基于Flink特定压缩过滤器的清理策略。RocksDB定期运行异步压缩以合并状态更新并减少存储。Flink压缩过滤器使用TTL检查状态条目的到期时间戳，并丢弃所有过期值。


激活此功能的第一步是通过设置以下Flink配置选项来配置RocksDB状态后端

1

state.backend.rocksdb.ttl.compaction.filter.enabled

配置RocksDB状态后端后，将为状态启用压缩清理策略，如以下代码示例所示

1
2
3
4
5

StateTtlConfig ttlConfig =
            StateTtlConfig.newBuilder(Time.days(1)) //它是生存时间值
                    .setUpdateType(StateTtlConfig.UpdateType.OnCreateAndWrite)
                    .cleanupInRocksdbCompactFilter() // 基于rocksdb的定期压缩合并进行清理
                    .build();

使用定时器删除（Timers）
手动清除状态的另一种方法是基于Flink定时器。这是社区目前正在评估未来版本的想法。通过这种方法，为每个状态访问注册清理定时器。这种方法更容易预测，因为状态一旦到期就会被删除。但是，这种方法代价很大，因为定时器消耗存储资源，并且会频繁读取状态信息。

StateTtlConfig
这个类用于配置state TTL 的逻辑
UpdateType 这个枚举类表示此选项值配置何时更新上次访问时间戳记，以延长状态TTL

1
2
3
4
5

public enum UpdateType {
Disabled,//禁用过期，状态不过期
OnCreateAndWrite,// 创建并且写时候
OnReadAndWrite// 读然后写
}

StateVisibility 这个枚举类表示是否可以返回过期的用户值

1
2
3
4

public enum StateVisibility {
ReturnExpiredIfNotCleanedUp,// 如果还没有清除，那么返回
NeverReturnExpired// 不返回过期的值
}

CleanupStrategies 这个抽象类是定义TTL 清除策略的类，里面有个枚举类Strategies ,用于定义清除策略

1
2
3
4
5

enum Strategies {
FULL_STATE_SCAN_SNAPSHOT,// 快照扫描时候
INCREMENTAL_CLEANUP,//增量清理
ROCKSDB_COMPACTION_FILTER// rocksdb 压缩过滤
}

CleanupStrategy接口
这是一个空接口，用于定义各个清除策略的实现类，有三个实现类，分别是：
EmptyCleanupStrategy：这个类没有任何内容，是个空类
IncrementalCleanupStrategy：增量清理策略的配置实现类
RocksdbCompactFilterCleanupStrategy：基于rocksdb 压缩过滤策略的配置实现类


StateTtlConfig 的核心属性：

1
2
3
4
5

private UpdateType updateType = OnCreateAndWrite;
private StateVisibility stateVisibility = NeverReturnExpired;
private TimeCharacteristic timeCharacteristic = ProcessingTime;
private Time ttl;
private CleanupStrategies cleanupStrategies = new CleanupStrategies();

说明：
StateTtlConfig 这个类主要有上面5个属性
updateType ：代表什么时候更新上次的时间戳
stateVisibility ：表示状态过期后是否给用户返回相关值
timeCharacteristic ：表示时间特征，现在只支持process time上的状态ttl定义
ttl：表示时间频率
cleanupStrategies ：代表清除策略,有三种，EmptyCleanupStrategy，IncrementalCleanupStrategy和RocksdbCompactFilterCleanupStrategy

自动故障恢复是 Flink 提供的一个强大的功能，在实际运行环境中，我们会遇到各种各样的问题从而导致应用挂掉，比如我们经常遇到的非法数据、网络抖动等。Flink 提供了强大的可配置故障恢复和重启策略来进行自动恢复。

故障恢复

Flink 的配置文件，其中有一个参数 jobmanager.execution.failover-strategy: region。


Flink 支持了不同级别的故障恢复策略，jobmanager.execution.failover-strategy 的可配置项有两种：full 和 region。


当我们配置的故障恢复策略为 full 时，集群中的 Task 发生故障，那么该任务的所有 Task 都会发生重启。而在实际生产环境中，我们的大作业可能有几百个 Task，出现一次异常如果进行整个任务重启，那么经常会导致长时间任务不能正常工作，导致数据延迟。


根据图论知识，如果我们的ExecutionGraph是一个非连通图（即可以划分为多个独立的依赖pipeline），那么当某个Task失败时，就可以只回溯到该Task所在的连通分量的Source，并重启该连通分量涉及到的所有Task，而其他Task不受影响，如下图所示。此时一个连通分量就是一个Region。

这个思路很容易理解，但是对于ExecutionGraph本身就是连通图的情况就不高效了，因为还是要重启所有Task，如下图所示。

所以Flink对这种情况又做了一个优化：在发生一对多依赖的Task后面缓存计算出来的中间结果（intermediate result）。当下游的Task失败重启时，就可以不必回溯到Source，而是回溯到中间结果就行了，重启的Task数进一步减少。此时从中间结果缓存起计的所有下游Task形成一个Region。用语言描述可能有些不直观，一张图就能说明白了。

注意B1、B2后面的黑框框
当然，如果是靠近Source一端的Task出了问题，或者中间结果缓存失效，这种方法就行不通了，老老实实从Source重启吧。


所以集群中某一个或几个 Task 发生了故障，只需要重启有问题的一部分即可，这就是 Flink 基于 Region 的局部重启策略。在这个策略下，Flink 会把我们的任务分成不同的 Region，当某一个 Task 发生故障时，Flink 会计算需要故障恢复的最小 Region。


Flink 在判断需要重启的 Region 时，采用了以下的判断逻辑：

• 发生错误的 Task 所在的 Region 需要重启；
• 如果当前 Region 的依赖数据出现损坏或者部分丢失，那么生产数据的 Region 也需要重启；
• 为了保证数据一致性，当前 Region 的下游 Region 也需要重启。

Job重启策略的相关源码

Task重启策略的相关源码

重启策略

Flink 提供了多种类型和级别的重启策略，常用的重启策略包括：

• 固定延迟重启策略模式
  
• 失败率重启策略模式
  
• 无重启策略模式

Flink 在判断使用的哪种重启策略时做了默认约定，如果用户配置了 checkpoint，但没有设置重启策略，那么会按照固定延迟重启策略模式进行重启；如果用户没有配置 checkpoint，那么默认不会重启。


下面我们分别对这三种模式进行详细讲解。
**

无重启策略模式

在这种情况下，如果我们的作业发生错误，任务会直接退出。
我们可以在 flink-conf.yaml 中配置：

1

restart-strategy: none

也可以在程序中使用代码指定：

1
2

final ExecutionEnvironment env = ExecutionEnvironment.getExecutionEnvironment();
env.setRestartStrategy(RestartStrategies.noRestart());

**

固定延迟重启策略模式

固定延迟重启策略会通过在 flink-conf.yaml 中设置如下配置参数，来启用此策略：

1

restart-strategy: fixed-delay

固定延迟重启策略模式需要指定两个参数，首先 Flink 会根据用户配置的重试次数进行重试，每次重试之间根据配置的时间间隔进行重试，如下表所示：

举个例子，假如我们需要任务重试 3 次，每次重试间隔 5 秒，那么需要进行一下配置：

1
2

restart-strategy.fixed-delay.attempts: 3
restart-strategy.fixed-delay.delay: 5 s

当前我们也可以在代码中进行设置：

1
2
3
4

env.setRestartStrategy(RestartStrategies.fixedDelayRestart(
        3, // 重启次数
        Time.of(5, TimeUnit.SECONDS) // 时间间隔
));

失败率重启策略模式

首先我们在 flink-conf.yaml 中指定如下配置：

1

restart-strategy: failure-rate

这种重启模式需要指定三个参数，如下表所示。失败率重启策略在 Job 失败后会重启，但是超过失败率后，Job 会最终被认定失败。在两个连续的重启尝试之间，重启策略会等待一个固定的时间。

这种策略的配置理解较为困难，我们举个例子，假如 5 分钟内若失败了 3 次，则认为该任务失败，每次失败的重试间隔为 5 秒。


那么我们的配置应该是：

1
2
3

restart-strategy.failure-rate.max-failures-per-interval: 3
restart-strategy.failure-rate.failure-rate-interval: 5 min
restart-strategy.failure-rate.delay: 5 s

当然，也可以在代码中直接指定：

1
2
3
4
5

env.setRestartStrategy(RestartStrategies.failureRateRestart(
        3, // 每个时间间隔的最大故障次数
        Time.of(5, TimeUnit.MINUTES), // 测量故障率的时间间隔
        Time.of(5, TimeUnit.SECONDS) //  每次任务失败时间间隔
));

最后，需要注意的是，在实际生产环境中由于每个任务的负载和资源消耗不一样，我们推荐在代码中指定每个任务的重试机制和重启策略。

为什么高效？

1. redis是非关系型内存数据库 数据存储于内存中，内存读取速度非常快，如果只是简单的 key-value，内存不是瓶颈。一般情况下，hash 查找可以达到每秒数百万次的数量级。

2. 采用单线程，避免了不必要的上下文切换和竞争条件

3. 内部实现采用epoll，采用了epoll+自己实现的简单的事件框架。epoll中的读、写、关闭、连接都转化成了事件，然后利用epoll的多路复用特性，绝不在io上浪费一点时间

4. 因为Redis的操作都非常快速——它的数据全部在内存里，完全不需要访问磁盘。至于并发，Redis 使用多路 I/O 复用技术，本身的并发效率不成问题。

当然，单个 Redis 进程没办法使用多核（任一时刻只能跑在一个 CPU 核心上），但是它本来就不是非常计算密集型的服务。如果单核性能不够用，可以多开几个进程。


Redis采用了单线程的模型，保证了每个操作的原子性，也减少了线程的上下文切换和竞争。


另外，数据结构也帮了不少忙，Redis全程使用hash结构，读取速度快，还有一些特殊的数据结构，对数据存储进行了优化，如压缩表，对短数据进行压缩存储，再如，跳表，使用有序的数据结构加快读取的速度。


还有一点，Redis采用自己实现的事件分离器，效率比较高，内部采用非阻塞的执行方式，吞吐能力比较大。

Q&A

Q: 为什么redis需要把所有数据放到内存中？
A: Redis为了达到最快的读写速度将数据都读到内存中，并通过异步的方式将数据写入磁盘。所以redis具有快速和数据持久化的特征。如果不将数据放在内存中，磁盘I/O速度为严重影响redis的性能。在内存越来越便宜的今天，redis将会越来越受欢迎。如果设置了最大使用的内存，则数据已有记录数达到内存限值后不能继续插入新值。


Q:使用Redis有哪些好处？
A: **
(1) 速度快，因为数据存在内存中，类似于HashMap，HashMap的优势就是查找和操作的时间复杂度都是O(1)
(2) 支持丰富数据类型，支持string，list，set，sorted set，hash
(3) 支持事务，操作都是原子性，所谓的原子性就是对数据的更改要么全部执行，要么全部不执行
(4) 丰富的特性：可用于缓存，消息，按key设置过期时间，过期后将会自动删除


Q: 为什么redis使用单线程？
A: 官方表示，因为Redis是基于内存的操作，CPU不是Redis的瓶颈，Redis的瓶颈最有可能是机器内存的大小或者网络带宽。既然单线程容易实现，多线程会更复杂，而且CPU不会成为瓶颈，那就顺理成章地采用单线程的方案了


注：这里我们一直在强调的单线程，只是在处理我们的网络请求的时候只有一个线程来处理，一个正式的Redis Server运行的时候肯定是不止一个线程的，这里需要大家明确的注意一下！例如Redis进行持久化的时候会以子进程或者子线程的方式执行（具体是子线程还是子进程待读者深入研究）**

分布式缓存

Flink提供了一个分布式缓存，类似于hadoop，可以使用户在并行函数中很方便的读取本地文件，并把它放在taskmanager节点中，防止task重复拉取。

此缓存的工作机制如下：程序注册一个文件或者目录(本地或者远程文件系统，例如hdfs或者s3)，通过ExecutionEnvironment注册缓存文件并为它起一个名称。


当程序执行，Flink自动将文件或者目录复制到所有taskmanager节点的本地文件系统，仅会执行一次。**用户可以通过这个指定的名称查找文件或者目录，然后从taskmanager节点的本地文件系统访问它。

Broadcast 广播变量

一句话解释，可以理解为是一个公共的共享变量，我们可以把一个dataset 数据集广播出去，然后不同的任务在节点上都能够获取到，这个数据在每个节点上只会存在一份。如果不使用broadcast，则在每个节点中的每个任务中都需要拷贝一份dataset数据集，比较浪费内存(也就是一个节点中可能会存在多份dataset数据)。
注意：
1：广播出去的变量存在于每个节点的内存中，所以这个数据集不能太大，避免发生OOM。因为广播出去的数据，会常驻内存，除非程序执行结束。
2：广播变量在初始化广播出去以后不支持修改，这样才能保证每个节点的数据都是一致的。
个人建议：如果数据集在几十兆或者百兆的时候，可以选择进行广播，如果数据集的大小上G的话，就不建议进行广播了。

区别

1.广播变量是基于内存的,是将变量分发到各个worker节点的内存上（避免多次复制，节省内存）
2.分布式缓存是基于磁盘的,将文件copy到各个节点上,当函数运行时可以在本地文件系统检索该文件（避免多次复制，提高执行效率）

Code

接下来我们来看一下简单的使用方式

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54

import org.apache.commons.io.FileUtils;
import org.apache.flink.api.common.functions.MapFunction;
import org.apache.flink.api.common.functions.RichMapFunction;
import org.apache.flink.api.java.DataSet;
import org.apache.flink.api.java.ExecutionEnvironment;
import org.apache.flink.api.java.operators.DataSource;
import org.apache.flink.configuration.Configuration;
import java.io.File;
import java.util.ArrayList;
import java.util.List;

/**
 * 分布式缓存
 *  第一步：首先需要在 env 环境中注册一个文件，该文件可以来源于本地，也可以来源于 HDFS ，并且为该文件取一个名字。
 *  第二步：在使用分布式缓存时，可根据注册的名字直接获取。
 */

public class DistributeCache {
    public static void main(String[] args) throws Exception {

        final ExecutionEnvironment env = ExecutionEnvironment.getExecutionEnvironment();
        env.registerCachedFile("/Users/cpeixin/cache/distributedcache.txt", "distributedCache");
        //1：注册一个文件,可以使用hdfs上的文件 也可以是本地文件进行测试
        DataSource<String> data = env.fromElements("Linea", "Lineb", "Linec", "Lined");

        // RichFuction除了提供原来MapFuction的方法之外，还提供open, close, getRuntimeContext 和setRuntimeContext方法，
        // 这些功能可用于参数化函数（传递参数），创建和完成本地状态，访问广播变量以及访问运行时信息以及有关迭代中的信息。
        DataSet<String> result = data.map(new RichMapFunction<String, String>() {
            private ArrayList<String> dataList = new ArrayList<String>();

            @Override
            public void open(Configuration parameters) throws Exception {
                super.open(parameters);
                //2：使用该缓存文件
                File myFile = getRuntimeContext().getDistributedCache().getFile("distributedCache");
                List<String> lines = FileUtils.readLines(myFile);
                for (String line : lines) {
                    dataList.add(line);
                    System.err.println("分布式缓存为:" + line);
                }
            }

            @Override
            public String map(String value) throws Exception {
                //在这里就可以使用dataList
                System.err.println("使用datalist：" + dataList + "-------" +value);
                //业务逻辑
                return dataList +"：" +  value;
            }
        });
        result.printToErr();
    }

}

下面给出一个更加贴合生产场景下的需求实现，在流计算中使用DistributedCache来完成我们的计算，整个过程其实有些像与维度数据的join

1
2
3
4
5
6
7

 1. Prepare resources on hdfs
[robin@node01 ~]$ hdfs dfs -mkdir /flink/cache
[robin@node01 ~]$ vi gender.txt
 1, male
 2, female
[robin@node01 ~]$ hdfs dfs -put gender.txt /flink/cache
 2. Turn on the source (socket)

代码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66

package distributeCache

import java.io.File
import org.apache.flink.api.common.functions.RichMapFunction
import org.apache.flink.streaming.api.scala.StreamExecutionEnvironment
import org.apache.flink.api.scala._
import org.apache.flink.configuration.Configuration
import scala.collection.mutable
import scala.io.{BufferedSource, Source}

object DistrubutedCacheTest {
  def main(args: Array[String]): Unit = {
    //1. Environment
    val env: StreamExecutionEnvironment = StreamExecutionEnvironment.getExecutionEnvironment

    //2. Read the resources on hdfs and set them in the distributed cache
    env.registerCachedFile("hdfs://node01:9000/flink/cache/gender.txt","hdfsGenderInfo")

    //3. Read the student information sent by the socket in real time, calculate it, and output the result
    //(101,"jackson",1,"Shanghai")
    env.socketTextStream("node01",8888)
      .filter((_: String).trim.nonEmpty)
      .map(new RichMapFunction[String,(Int,String,Char,String)] {

        //Used to store student information read from the distributed cache
        val map:mutable.Map[Int,Char]= mutable.HashMap()
        var bs: BufferedSource = _

        override def open(parameters: Configuration): Unit = {
          //1. Read the data stored in the distributed cache
          var file:File = getRuntimeContext.getDistributedCache.getFile("hdfsGenderInfo")

          //2. Encapsulate the read information into a map instance for storage
          bs = Source.fromFile(file)
          val lst: List[String] = bs.getLines().toList
          for(perLine <-lst){
            val arr: Array[String] = perLine.split(",")
            val genderFlg: Int = arr(0).trim.toInt
            val genderName: Char = arr(1).trim.toCharArray()(0)
            map.put(genderFlg,genderName)
          }
        }

        override def map(perStudentInfo: String): (Int, String, Char, String) = {
          //Get student details
          val arr: Array[String] = perStudentInfo.split(",")
          val id: Int = arr(0).trim.toInt
          val name: String = arr(1).trim
          val genderFlg: Int = arr(2).trim.toInt
          val address: String = arr(3).trim
          //According to the data in the distributed cache stored in the container Map, replace the gender identifier in the student information with the real gender
          var genderName: Char = map.getOrElse(genderFlg, 'x')
          (id, name, genderName, address)
        }

        override def close(): Unit = {
          if(bs != null){
            bs.close()
          }
        }
      }).print("The information completed by the student is ->")

    //4. Start
    env.execute(this.getClass.getSimpleName)
  }
}

结果

RowKey的作用

RowKey在查询中的作用

HBase中RowKey可以唯一标识一行记录，在HBase中检索数据有以下三种方式：

• 通过 get 方式，指定 RowKey 获取唯一一条记录
  
• 通过 scan 方式，设置 startRow 和 stopRow 参数进行范围匹配
  
• 全表扫描，即直接扫描整张表中所有行记录

当大量请求访问HBase集群的一个或少数几个节点，造成少数RegionServer的读写请求过多、负载过大，而其他RegionServer负载却很小，这样就造成热点现象。


大量访问会使热点Region所在的主机负载过大，引起性能下降，甚至导致Region不可用。所以我们在向HBase中插入数据的时候，应尽量均衡地把记录分散到不同的Region里去，平衡每个Region的压力。


下面根据一个例子分别介绍下根据RowKey进行查询的时候支持的情况。
如果我们RowKey设计为uid+phone+name，那么这种设计可以很好的支持一下的场景:

1

uid=873969725 AND phone=18900000000 AND name=zhangsanuid= 873969725 AND phone=18900000000uid= 873969725 AND phone=189?uid= 873969725复制代码

难以支持的场景：

1

phone=18900000000 AND name = zhangsanphone=18900000000 name=zhangsan复制代码

从上面的例子中可以看出，在进行查询的时候，根据RowKey从前向后匹配，所以我们在设计RowKey的时候选择好字段之后，还应该结合我们的实际的高频的查询场景来组合选择的字段，越高频的查询字段排列越靠左。

RowKey在Region中的作用

在 HBase 中，Region 相当于一个数据的分片，每个 Region 都有StartRowKey和StopRowKey，这是表示 Region 存储的 RowKey 的范围，HBase 表的数据时按照 RowKey 来分散到不同的 Region，要想将数据记录均衡的分散到不同的Region中去，因此需要 RowKey 满足这种散列的特点。


此外，在数据读写过程中也是与RowKey 密切相关，RowKey在读写过程中的作用：

• 读写数据时通过 RowKey 找到对应的 Region；
  
• MemStore 中的数据是按照 RowKey 的字典序排序；
  
• HFile 中的数据是按照 RowKey 的字典序排序。
  

RowKey的设计

在HBase中RowKey在数据检索和数据存储方面都有重要的作用，一个好的RowKey设计会影响到数据在HBase中的分布，还会影响我们查询效率，所以一个好的RowKey的设计方案是多么重要。首先我们先来了解下RowKey的设计原则。

RowKey设计原则

长度原则
RowKey是一个二进制码流，可以是任意字符串，最大长度为64kb，实际应用中一般为10-100byte，以byte[]形式保存，一般设计成定长。建议越短越好，不要超过16个字节，原因如下：

• 数据的持久化文件HFile中时按照Key-Value存储的，如果RowKey过长，例如超过100byte，那么1000w行的记录，仅RowKey就需占用近1GB的空间。这样会极大影响HFile的存储效率。
  
• MemStore会缓存部分数据到内存中，若RowKey字段过长，内存的有效利用率就会降低，就不能缓存更多的数据，从而降低检索效率。
  
• 目前操作系统都是64位系统，内存8字节对齐，控制在16字节，8字节的整数倍利用了操作系统的最佳特性。
  

唯一原则
必须在设计上保证RowKey的唯一性。由于在HBase中数据存储是Key-Value形式，若向HBase中同一张表插入相同RowKey的数据，则原先存在的数据会被新的数据覆盖。

排序原则
HBase的RowKey是按照ASCII有序排序的，因此我们在设计RowKey的时候要充分利用这点。

散列原则**
设计的RowKey应均匀的分布在各个HBase节点上。

RowKey字段选择

RowKey字段的选择，遵循的最基本原则是唯一性，RowKey必须能够唯一的识别一行数据。无论应用的负载特点是什么样，RowKey字段都应该参考最高频的查询场景。


数据库通常都是以如何高效的读取和消费数据为目的，而不是数据存储本身。然后，结合具体的负载特点，再对选取的RowKey字段值进行改造，组合字段场景下需要重点考虑字段的顺序。

避免数据热点的方法

在对HBase的读写过程中，如何避免热点现象呢？主要有以下几种方法：

Reversing
如果经初步设计出的RowKey在数据分布上不均匀，但RowKey尾部的数据却呈现出了良好的随机性，此时，可以考虑将RowKey的信息翻转，或者直接将尾部的bytes提前到RowKey的开头。Reversing可以有效的使RowKey随机分布，但是牺牲了RowKey的有序性。
缺点：利于Get操作，但不利于Scan操作，因为数据在原RowKey上的自然顺序已经被打乱。

Salting
Salting（加盐）的原理是在原RowKey的前面添加固定长度的随机数，也就是给RowKey分配一个随机前缀使它和之间的RowKey的开头不同。随机数能保障数据在所有Regions间的负载均衡。
缺点：因为添加的是随机数，基于原RowKey查询时无法知道随机数是什么，那样在查询的时候就需要去各个可能的Regions中查找，Salting对于读取是利空的。并且加盐这种方式增加了读写时的吞吐量。

Hashing**
基于 RowKey 的完整或部分数据进行 Hash，而后将Hashing后的值完整替换或部分替换原RowKey的前缀部分。这里说的 hash 包含 MD5、sha1、sha256 或 sha512 等算法。
缺点：与 Reversing 类似，Hashing 也不利于 Scan，因为打乱了原RowKey的自然顺序。

RowKey设计案例剖析

1. 查询某用户在某应用中的操作记录

reverse(userid) + appid + timestamp

2. 查询某用户在某应用中的操作记录（优先展现最近的数据）

reverse(userid) + appid + (Long.Max_Value - timestamp)

3. 查询某用户在某段时间内所有应用的操作记录

reverse(userid) + timestamp + appid

4. 查询某用户的基本信息

reverse(userid)

5. 查询某eventid记录信息

salt + eventid + timestamp

如果 userid是按数字递增的，并且长度不一，可以先预估 userid 最大长度，然后将userid进行翻转，再在翻转之后的字符串后面补0（至最大长度）；如果长度固定，直接进行翻转即可（如手机号码）。
在第5个例子中，加盐的目的是为了增加查询的并发性，加入Slat的范围是0~n，可以将数据分为n个split同时做scan操作，有利于提高查询效率。

总结

在HBase的使用过程，设计RowKey是一个很重要的一个环节。我们在进行RowKey设计的时候可参照如下步骤：

• 结合业务场景特点，选择合适的字段来做为RowKey，并且按照查询频次来放置字段顺序
  
• 通过设计的RowKey能尽可能的将数据打散到整个集群中，均衡负载，避免热点问题
  
• 设计的RowKey应尽量简短
  

以下这篇博客转载自数据仓库案例，巨详细👍👍👍👍👍

离线数据仓库

数据仓库（Data WareHouse）是为企业所有决策制定过程，提供所有系统数据支持的战略集合
通过对数据仓库中数据的分析，可以帮助企业，改进业务流程、控制、成本、提高产品质量等
数据仓库，并不是数据最终目的地，而是为数据最终的目的地做好准备：清洗、转义、分类、重组、合并、拆分、统计等等

1 项目简介

1.1 项目需求

1. 用户行为数据采集平台搭建
2. 业务数据采集平台搭建
3. 数据仓库维度建模
4. 分析：用户、流量、会员、商品、销售、地区、活动等主题
5. 采用即席查询工具，随时进行指标分析
6. 对集群性能进行监控，发生异常需要报警
7. 元数据管理
8. 质量监控
   

   1.2 技术选型

• 数据采集功能如何技术选型

  采集框架名称	主要功能
  Sqoop	大数据平台和关系型数据库的导入导出
  Datax	大数据平台和关系型数据库的导入导出
  flume	擅长日志数据的采集和解析
  logstash	擅长日志数据的采集和解析
  maxwell	常用作实时解析mysql的binlog数据
  canal	常用作实时解析mysql的binlog数据
  waterDrop	数据导入导出工具

• 消息中间件的技术选型

  开源MQ	概述
  RabbitMQ	LShift 用Erlang实现，支持多协议，broker架构，重量级
  ZeroMQ	AMQP最初设计者iMatix公司实现，轻量消息内核，无broker设计。C++实现
  Kafka	LinkedIn用Scala语言实现，支持hadoop数据并行加载
  ActiveMQ	Apach的一种JMS具体实现，支持代理和p2p部署。支持多协议。Java实现
  Redis	Key-value NoSQL数据库，有MQ的功能
  MemcacheQ	国人利用memcache缓冲队列协议开发的消息队列,C/C++实现

• 数据永久存储技术框架选型

  框架名称	主要用途
  HDFS	分布式文件存储系统
  Hbase	Key，value对的nosql数据库
  Kudu	Cloudera公司开源提供的类似于Hbase的数据存储
  Hive	基于MR的数据仓库工具

• 数据离线计算框架技术选型(hive引擎)

  框架名称	基本介绍
  MapReduce	最早期的分布式文件计算系统
  Spark	基于spark，一站式解决批流处理问题
  Flink	基于flink，一站式解决批流处理问题

• 分析数据库选型

  对比项目	Druid	Kylin	Presto	Impala	ES
  亚秒级响应	√	√	×	×	×
  百亿数据集	√	√	√	√	√
  SQL支持	√	√	√	√	√(需插件)
  离线	√	√	√	√	√
  实时	√	√	×	×	×
  精确去重	×	√	√	√	×
  多表Join	×	√	√	√	×
  JDBC for BI	×	√	√	√	×

• 其他选型

  • 任务调度：DolphinScheduler
  • 集群监控：CM+CDH
  • 元数据管理：Atlas
  • BI工具：Zeppelin、Superset
    

    1.3 架构

    
    

    1.4 集群资源规划

• 如何确认集群规模（假设每台服务器8T磁盘，128G内存）

  1. 每天日活跃用户100万，每人一天平均100条：100万 * 100条 = 1亿条
  2. 每条日志1K左右，每天1一条：1亿 / 1024 /1024 = 约100G
  3. 半年内不扩容服务器来算：100G * 180天 = 约18T
  4. 保存3个副本：18T * 3 = 54T
  5. 预留20% ~ 30%BUF：54T / 0.7 = 77T
  6. 总结：约10台服务器

     由于资源有限，采用3台进行制作