大数据面试题以及知识点总结(不断更新)

有风入弦

已于 2023-06-04 09:54:58 修改

阅读量678

点赞数

文章标签：大数据 java spark 数据仓库

于 2023-05-26 17:01:06 首次发布

本文链接：https://blog.csdn.net/lx2wenhui/article/details/130889274

版权

对经常出现的面试题进行整理并根据自己以及对网上资料的整理

kafka如果创建大量的topic，对kafak会有什么影响？

谈谈你对spark Shuffle的理解？描述一下大表与大表join时的Shuffle机制或者过程？

spark内存管理

hive分区表中，单值分区和范围分区的区别

数仓采用了什么模型？为什么？

spark任务切分，怎么判断有没有执行shuffle

拉链表出错怎么办

建模的流程

空值key加随机数是一种数据倾斜解决方案，如果有单个key是热点值呢？又如果有多个key是热点值呢？用参数和代码分别怎么解决？

行存和和列存的区别？

拉链表有什么缺点？拉链表有哪些字段必须要有的？

数据和业务是怎么协作的？比如说数据对业务做一些反馈和支持？

Map端的环形缓冲区为什么设置成环形的

spark job提交流程

你们团队使用的是Spark3,那么Spark3相比spark2做的区别是什么?

数据仓库在数据处理过程出现小文件问题怎么解决

kafka优化?

orc,rc,parquet列式存储有什么区别，底层存储的内存是否是连续的？

Spark 任务是如何执行的，有哪些执行策略？

如何衡量 Spark 程序的性能，有哪些优化方法可以提高 Spark 程序的性能

Spark 中如何处理异常，如何避免程序中的各种故障？

如何优化 Spark 中的 I/O 操作，以便提高程序的效率？

Spark 中的 RDD 和 Dataframe 有什么区别，它们分别适用于哪些场景？

kafka如果创建大量的topic，对kafak会有什么影响？

Kafka可以支持创建大量的topic，但是如果创建了过多的topic，会对Kafka集群的性能和稳定性产生影响。主要表现在以下几个方面：

1. 内存占用：每个topic都需要占用一定的内存空间，如果创建了过多的topic，会导致内存占用过高，从而影响Kafka的性能。

2. 磁盘空间：每个topic都需要占用一定的磁盘空间，如果创建了过多的topic，会导致磁盘空间不足，从而影响Kafka的稳定性。

3. 元数据管理：Kafka需要维护每个topic的元数据信息，如果创建了过多的topic，会导致元数据管理变得复杂，从而影响Kafka的性能和稳定性。

因此，在创建topic时，需要根据实际需求进行规划和设计，避免创建过多的topic。同时，建议使用合适的分区数和副本数来提高Kafka的性能和可靠性。

谈谈你对spark Shuffle的理解？描述一下大表与大表join时的Shuffle机制或者过程？

Spark Shuffle是指在Spark中进行数据重分区的过程。在Spark中，Shuffle是一种非常耗费资源的操作，因为它需要将数据从各个节点上收集起来，然后进行重分区操作，最后再将数据发送回各个节点上进行计算。在大表与大表join时，Spark会将两个表的数据按照join条件进行分区，然后将相同分区的数据发送到同一台机器上进行join操作，这个过程就是Shuffle。具体的过程如下：

首先，Spark会将两个表按照join条件进行分区，每个分区内的数据都是相同的。
接着，Spark会将相同分区的数据发送到同一台机器上进行join操作。如果两个表的分区数量不同，那么Spark会将少的一方进行重分区，使得两个表的分区数量相同。
在进行join操作时，Spark会将相同key的数据放到同一个组中，然后对每个组进行join操作。这个过程需要进行大量的数据传输和计算，因此非常耗费资源。
最后，Spark会将join的结果进行合并，并将结果发送回各个节点上。

总之，Spark Shuffle是一种非常耗费资源的操作，因此在进行大表join时，需要尽可能地减少Shuffle的次数和数据量，以提高计算效率。

spark内存管理

Spark 的内存管理主要分为两部分：JVM 堆内存管理和 Spark 内存管理。

JVM 堆内存管理 :
1. JVM 堆内存管理主要是由 Java 虚拟机来完成的，它包括了新生代和老年代两个部分。
2. 在 Spark 中，JVM 堆内存主要用来存储 Java 对象和运行时数据结构，如线程栈、方法区等。
Spark 内存管理:
1. Spark 内存管理主要是由 Spark 自己来完成的，它包括了堆内存和堆外内存两个部分。
2. 堆内存：Spark 内存管理器会将 JVM 堆内存划分为多个不同的内存池，如存储内存池（storage memory pool）、执行内存池（execution memory pool）等。其中，存储内存池主要用来存储缓存数据和持久化数据，而执行内存池主要用来存储计算过程中的中间结果和数据结构。
3. 堆外内存：Spark 内存管理器还可以使用堆外内存来存储一些大对象，如序列化后的数据、广播变量等。堆外内存的好处是可以减少 GC 的频率，提高程序的性能。

在 Spark 中，内存管理器会根据任务的需求来动态地分配和释放内存，以保证程序的运行效率和稳定性。同时，内存管理器还会根据内存使用情况来触发 GC 操作，以及根据内存使用率来控制任务的并发度，以避免内存溢出和性能下降的问题。需要注意的是，Spark 内存管理器的默认配置并不一定适合所有的应用场景，因此在实际使用中，需要根据任务的需求来调整内存管理器的配置，以获得更好的性能和稳定性。

hive分区表中，单值分区和范围分区的区别

在Hive中，分区表是指将数据按照一定规则分成多个部分存储的表。分区表可以提高查询效率，减少数据扫描量，提高查询性能。在分区表中，单值分区和范围分区是两种常见的分区方式。

单值分区:

单值分区是指按照某个字段的值进行分区，每个分区只包含该字段值相同的数据。例如，按照年份对订单表进行分区，每个分区只包含该年份的订单数据。单值分区的优点是查询效率高，缺点是分区数量较多，容易导致元数据过大。

范围分区:

范围分区是指按照某个字段的值范围进行分区，每个分区包含该字段值在一定范围内的数据。例如，按照价格区间对商品表进行分区，每个分区包含价格在该区间内的商品数据。范围分区的优点是分区数量较少，元数据较小，缺点是查询效率相对较低。

总之，单值分区适用于分区字段值离散的场景，范围分区适用于分区字段值连续的场景。在实际使用中，需要根据数据特点和查询需求来选择合适的分区方式。

数仓采用了什么模型？为什么？

这里直接讨论三个模型的优缺点,自行讨论

在数据仓库设计中，有多种不同的数据模型可供选择。常见的数据模型有星型模型、雪花模型、多维模型等，它们各有优缺点，适用于不同的场景。

星型模型:

星型模型是最常见的数据仓库模型之一，它将事实表和维度表之间建立起了一对多的关系，事实表是中心表，维度表围绕着事实表建立。星型模型的优点是结构简单，易于理解和维护，查询性能高，适用于数据量较小、查询频繁的场景。缺点是不够灵活，难以应对复杂的查询需求。

雪花模型:

雪花模型在星型模型的基础上，将维度表进一步拆分成多个维度表，形成了多级维度结构。雪花模型的优点是能够更好地处理复杂的查询需求，适用于数据量较大、查询复杂的场景。缺点是结构复杂，维护成本高，查询性能相对较低。

多维模型:

多维模型是一种基于OLAP（联机分析处理）的数据仓库模型，它将数据以多维度的形式进行组织和存储。多维模型的优点是能够更好地支持复杂的多维分析和数据挖掘，适用于数据量较大、查询复杂的场景。缺点是结构复杂，建模和维护成本高，查询性能相对较低。

总之，不同的数据仓库模型各有优缺点，需要根据业务需求和数据特点来选择合适的模型。在实际应用中，通常会根据具体情况采用不同的模型进行组合和优化，以达到最佳的性能和效果。

spark任务切分，怎么判断有没有执行shuffle

Spark任务的切分和判断是否执行shuffle是Spark调度和执行过程中的两个重要环节。

Spark任务的切分:

Spark任务的切分是指将一个大的任务拆分成多个小任务，以便并行执行。Spark的任务切分是基于RDD（弹性分布式数据集）的，每个RDD都可以被切分成多个分区，每个分区可以在不同的节点上并行执行。Spark的任务切分过程中，会根据RDD的依赖关系进行划分，将DAG（有向无环图）上的节点划分为不同的阶段（stage），每个阶段包含一组可以并行执行的任务。Spark会根据数据的分布情况和集群资源的状况，动态地决定每个阶段的任务切分和调度方式，以达到最优的性能和效率。

2. 判断是否执行shuffle:

Spark中的shuffle是指将数据按照某个字段进行重新分区和排序的过程。由于shuffle需要进行网络传输和磁盘读写等操作，因此会带来较大的性能开销。因此，需要尽量避免不必要的shuffle操作，以提高任务执行效率。在Spark任务中，可以通过以下几种方式来判断是否执行shuffle操作：

操作类型：一些操作（如map、filter、union等）不会导致shuffle，而一些操作（如groupByKey、reduceByKey、join等）会导致shuffle。
是否调用了shuffle操作：通过查看代码中是否调用了shuffle操作，可以判断是否会执行shuffle。
数据分区：如果数据已经按照某个字段进行了分区，那么在进行一些聚合操作时，可以避免shuffle，以提高性能。

总之，在Spark任务的调度和执行过程中，需要进行任务切分和shuffle优化，以达到最优的性能和效率。

拉链表出错怎么办

拉链表是一种常用的数据结构，用于记录历史数据的变化。在实际应用中，可能会出现拉链表出错的情况，这时需要进行相应的处理。

1. 找出问题原因

首先，需要找出拉链表出错的原因。可能的原因包括：插入数据时出现错误、数据被误删除、更新数据时出现错误等等。通过分析错误日志和数据变化情况，可以找出拉链表出错的原因。

2. 恢复数据

找出问题原因后，需要对拉链表进行相应的修复。如果是数据被误删除，可以通过备份数据或者其他方式恢复数据；如果是插入或更新数据时出现错误，可以通过重新插入或更新数据来修复拉链表。

3. 避免类似问题

为了避免类似问题的出现，可以采取以下措施：

数据备份：定期备份数据，以便在出现问题时进行数据恢复。
数据验证：在插入、更新或删除数据时，进行数据验证，确保数据的正确性和完整性。
错误处理：在程序中加入错误处理机制，及时发现和处理错误，避免错误扩散和影响。

总之，拉链表出错是常见的问题，需要及时发现和处理。在实际应用中，需要采取相应的措施来避免类似问题的出现，确保数据的正确性和完整性。

建模的流程

数仓建模是将业务数据进行抽象、分类、整合和优化，形成适合决策和分析的数据模型的过程。数仓建模的流程一般包括以下几个步骤：

确定业务需求

首先需要明确业务需求，包括需要哪些数据、数据的来源和数据的用途等。在确定业务需求时，需要和业务部门进行沟通和协商，以确保数据模型能够满足业务需求。

设计维度模型

维度模型是数仓中最常用的数据模型，它是以业务过程为基础，将事实数据和维度数据组合起来的模型。在设计维度模型时，需要确定事实表和维度表，以及它们之间的关系。同时，需要确定每个表中包含哪些字段，以及字段之间的关系。

设计ETL流程

ETL（抽取、转换和加载）是将源系统中的数据抽取到数仓中的过程。在设计ETL流程时，需要确定数据抽取的方式、数据转换的方式、数据加载的方式以及数据质量控制的方式等。

实现数据模型

在实现数据模型时，需要根据设计的维度模型和ETL流程，建立数据仓库、数据集市、数据域等数据存储结构，并将数据从源系统中抽取到数仓中。

数据质量控制

数据质量控制是保证数仓数据质量的关键步骤。在数据质量控制时，需要对数据进行清洗、去重、校验、补全等处理，以确保数据的正确性和完整性。

数据分析和应用

最后，需要通过数据分析和应用，将数仓中的数据转化为有价值的信息，为业务决策和分析提供支持。

总之，数仓建模是一个复杂的过程，需要在业务需求、数据模型、ETL流程、数据质量控制、数据分析和应用等方面进行全面考虑

空值key加随机数是一种数据倾斜解决方案，如果有单个key是热点值呢？又如果有多个key是热点值呢？用参数和代码分别怎么解决？

如果出现单个热点值，可以采用以下两种解决方案：

增加reducer数量：将reducer数量增加到热点值数量的两倍以上，这样可以将热点值均匀地分配到多个reducer中，从而避免数据倾斜。在Hadoop中，可以通过设置参数mapreduce.job.reduces来控制reducer数量。
采用二次聚合：在map端对热点值进行局部聚合，然后将结果发送到reducer端进行全局聚合。这样可以减少热点值的数量，从而避免数据倾斜。在Hadoop中，可以通过编写自定义的Combiner类来实现二次聚合。

如果出现多个热点值，可以采用以下两种解决方案：

采用多级聚合：将热点值按照某种规则进行分组，然后对每组进行局部聚合，最后将结果发送到reducer端进行全局聚合。这样可以将热点值均匀地分配到多个reducer中，从而避免数据倾斜。在Hadoop中，可以通过编写自定义的Partitioner类来实现多级聚合。
采用随机分区：在map端对所有key进行hash，然后将hash值与一个随机数相加，再对reducer数量取模，将结果作为分区号。这样可以将所有key均匀地分配到多个reducer中，从而避免数据倾斜。在Hadoop中，可以通过设置参数mapreduce.job.maps来控制map数量，从而影响随机分区的效果。

以下是使用Java代码实现二次聚合的示例：

public class WordCount {

    public static class MyMapper extends Mapper<LongWritable, Text, Text, IntWritable> {

        private final static IntWritable one = new IntWritable(1);
        private Text word = new Text();

        public void map(LongWritable key, Text value, Context context) throws IOException, InterruptedException {
            String line = value.toString();
            StringTokenizer tokenizer = new StringTokenizer(line);
            while (tokenizer.hasMoreTokens()) {
                word.set(tokenizer.nextToken());
                context.write(word, one);
            }
        }
    }

    public static class MyReducer extends Reducer<Text, IntWritable, Text, IntWritable> {

        private IntWritable result = new IntWritable();

        public void reduce(Text key, Iterable<IntWritable> values, Context context) throws IOException, InterruptedException {
            int sum = 0;
            for (IntWritable val : values) {
                sum += val.get();
            }
            result.set(sum);
            context.write(key, result);
        }
    }

    public static class MyCombiner extends Reducer<Text, IntWritable, Text, IntWritable> {

        private IntWritable result = new IntWritable();

        public void reduce(Text key, Iterable<IntWritable> values, Context context) throws IOException, InterruptedException {
            int sum = 0;
            for (IntWritable val : values) {
                sum += val.get();
            }
            result.set(sum);
            context.write(key, result);
        }
    }

    public static void main(String[] args) throws Exception {
        Configuration conf = new Configuration();
        Job job = Job.getInstance(conf, "word count");
        job.setJarByClass(WordCount.class);
        job.setMapperClass(MyMapper.class);
        job.setCombinerClass(MyCombiner.class);
        job.setReducerClass(MyReducer.class);
        job.setOutputKeyClass(Text.class);
        job.setOutputValueClass(IntWritable.class);
        FileInputFormat.addInputPath(job, new Path(args[0]));
        FileOutputFormat.setOutputPath(job, new Path(args[1]));
        System.exit(job.waitForCompletion(true) ? 0 : 1);
    }
}

在这个示例中，我们使用了自定义的Combiner类来实现二次聚合。在MyCombiner类中，我们对每个key进行局部聚合，然后将结果发送到reducer端进行全局聚合。

行存和和列存的区别？

行存和列存是指在计算机中存储矩阵的方式。

行存是指将矩阵的每一行连续地存储在内存中，即先存储第一行，再存储第二行，以此类推。这种方式可以使得在进行行操作时效率较高，例如矩阵的行求和、行乘法等操作。

列存则是将矩阵的每一列连续地存储在内存中，即先存储第一列，再存储第二列，以此类推。这种方式可以使得在进行列操作时效率较高，例如矩阵的列求和、列乘法等操作。

选择行存或列存取决于具体的应用场景和需要进行的操作。但是需要注意的是，由于计算机内存的存储方式是连续的，因此在进行矩阵运算时，行存和列存的效率可能会有很大的差别。

拉链表有什么缺点？拉链表有哪些字段必须要有的？

拉链表是一种常见的哈希表实现方式，它的主要缺点是在进行查找操作时需要遍历链表，当哈希表中的元素过多时，链表的长度会变得很长，导致查找效率降低，甚至会退化成链表。此外，由于拉链表需要额外的指针来维护链表结构，因此需要更多的内存空间。

拉链表中必须要有的字段包括：

哈希桶数组：用于存储哈希表中的元素，每个桶中存储一个链表的头指针。
链表节点：存储哈希表中的元素，包括键值对等信息。
指针：用于连接链表节点，包括每个节点的 next 指针和哈希桶数组中的指针。

除此之外，还可以在链表节点中添加其他字段，如计数器、时间戳等，以支持更多的应用场景。

数据和业务是怎么协作的？比如说数据对业务做一些反馈和支持？

数据和业务之间是相互支持和反馈的关系。

首先，数据可以为业务提供支持。通过对数据进行分析和挖掘，可以得到有关业务的一些重要信息，例如用户的需求、行为模式、偏好等。这些信息可以被用于制定业务策略、优化产品设计、改进用户体验等方面，从而提高业务的效益和竞争力。

其次，业务也可以为数据提供反馈。在业务的运营过程中，会产生大量的数据，这些数据可以用于验证和优化数据分析的模型和算法，从而提高数据的质量和价值。例如，在电商平台中，通过对用户的购买行为进行分析，可以得到有关商品的销售趋势、用户的购买偏好等信息，这些信息可以被用于优化商品推荐算法，提高用户的购买转化率和满意度。

综上所述，数据和业务之间是相互支持和反馈的关系，只有通过有效的协作和互动，才能实现数据和业务的最大化价值。

Map端的环形缓冲区为什么设置成环形的

MapReduce 中的环形缓冲区是为了解决数据处理过程中的数据读写瓶颈而设计的。在 Map 阶段中，每个 Map 任务会将处理结果写入到环形缓冲区中，然后再由 Reduce 任务读取缓冲区的数据进行处理。由于 Map 任务和 Reduce 任务的速度不同，如果采用普通的缓冲区，那么当 Map 任务的速度快于 Reduce 任务时，缓冲区会很快被写满，导致 Reduce 任务无法读取到数据，从而降低整个 MapReduce 任务的处理速度。

因此，为了解决这个问题，环形缓冲区被设计成环形的，即当缓冲区的末尾被写满时，它会从缓冲区的开头开始继续写入数据，这样就可以实现循环利用缓冲区，避免了数据写满后的浪费，同时也保证了 Reduce 任务能够在任何时候都能够读取到数据。

此外，环形缓冲区还具有一些其他的优点，例如可以减少数据拷贝的次数，提高数据读写的效率，同时也可以避免数据写入时的冲突问题。

spark job提交流程

Spark 作业提交的流程如下：

用户编写 Spark 应用程序，并将其打包成 Jar 包。
用户使用 Spark 提供的命令行工具或者 API，将打包好的应用程序提交到集群中。
Spark 驱动程序接收到提交请求后，会启动一个应用程序上下文（Application Context），并向集群管理器（如 YARN 或 Mesos）请求资源。
集群管理器为 Spark 应用程序分配资源，并启动 Executor 进程。
Spark 驱动程序将应用程序的任务分发给 Executor 进程，Executor 进程开始执行任务。
Executor 进程将任务的执行结果返回给 Spark 驱动程序。
Spark 驱动程序收集并汇总所有任务的执行结果，并将结果写回到外部存储系统（如 HDFS 或数据库）或者将结果返回给用户。
Spark 应用程序执行完成，资源被释放。

需要注意的是，Spark 应用程序的提交方式和具体的集群管理器有关，例如在 YARN 上提交应用程序需要使用 yarn-client 或 yarn-cluster 模式，而在 Mesos 上提交应用程序则需要使用 mesos:// URL。

你们团队使用的是Spark3,那么Spark3相比spark2做的区别是什么?

Spark 3 相比于 Spark 2，在性能优化方面做了很多改进，主要包括以下几个方面：

优化了内存管理机制：Spark 3 引入了新的内存管理机制，名为 Off-Heap Memory Mode，可以将部分内存数据存储在堆外内存中，减少了 GC 的开销，提高了任务的执行效率。
改进了查询优化器：Spark 3 引入了新的查询优化器，名为 Adaptive Query Execution，可以根据数据的特征和查询的复杂度，动态地选择最优的执行计划，提高了查询的执行效率。
改进了 Shuffle 算法：Spark 3 改进了 Shuffle 算法，引入了新的 Shuffle Service，可以将 Shuffle 数据存储在独立的 Shuffle 存储器中，减少了网络传输的开销，提高了 Shuffle 的性能。
引入了新的数据源 API：Spark 3 引入了新的数据源 API，名为 DataSourceV2，可以更好地支持新的数据源类型，如 Delta Lake、Kafka 等，提高了数据读写的性能和可扩展性。
改进了 SQL 引擎：Spark 3 改进了 SQL 引擎，引入了新的 SQL 函数和语法，如 ANSI SQL 标准、新的窗口函数、新的聚合函数等，提高了 SQL 查询的性能和灵活性。
改进了 Python API：Spark 3 改进了 Python API，提高了 Python 代码的执行效率和可读性，同时也增加了对 Python 3 的支持。

需要注意的是，Spark 3 的性能优化不仅仅局限于以上几个方面，还包括了很多其他的改进和优化，可以根据具体的应用场景和需求选择合适的版本。

数据仓库在数据处理过程出现小文件问题怎么解决

数仓的小文件问题主要是由于数据采集、处理和存储过程中出现的一些问题导致的，具体表现为：

数据采集阶段：在数据采集阶段，如果数据源中存在大量小文件，或者采集脚本没有经过优化，就会导致采集到大量小文件，进而导致后续的数据处理和存储过程中出现小文件问题。
数据处理阶段：在数据处理阶段，如果处理任务的并行度不够，或者处理脚本没有经过优化，就会导致处理结果生成大量小文件，进而导致后续的数据存储过程中出现小文件问题。
数据存储阶段：在数据存储阶段，如果存储格式不合适，或者存储引擎没有进行优化，就会导致数据存储为大量小文件，进而导致查询性能下降。

为了解决数仓的小文件问题，可以采取以下措施：

数据采集阶段：在数据采集阶段，可以通过合理的分区策略、采集脚本的优化等方式来避免采集到大量小文件。
数据处理阶段：在数据处理阶段，可以通过增加处理任务的并行度、使用合适的处理算法、优化处理脚本等方式来避免生成大量小文件。
数据存储阶段：在数据存储阶段，可以通过合理的存储格式、存储引擎的优化等方式来避免存储为大量小文件。

此外，还可以通过合并小文件、压缩存储、分区合并等方式来减少小文件数量，提高查询性能。另外，也可以通过使用 Hive、Spark 等分布式计算框架来处理数据，以提高处理效率和减少小文件数量。

kafka优化?

Kafka 是一个高性能、高可靠性的分布式消息队列，常用于大数据处理场景中的数据传输和存储。为了提高 Kafka 的性能和可靠性，可以采取以下优化措施：

合理设置分区数量：Kafka 的性能与分区数量直接相关，分区数量越多，Kafka 的吞吐量就越大。但是，分区数量过多也会导致 Kafka 的管理和维护变得复杂，因此需要根据具体的业务场景和需求来合理设置分区数量。
合理设置副本数量：Kafka 的可靠性与副本数量直接相关，副本数量越多，Kafka 的可靠性就越高。但是，副本数量过多也会影响 Kafka 的性能，因此需要根据具体的业务场景和需求来合理设置副本数量。
合理设置消息大小：Kafka 的性能与消息大小直接相关，消息大小越小，Kafka 的吞吐量就越大。但是，消息大小过小也会导致 Kafka 的管理和维护变得复杂，因此需要根据具体的业务场景和需求来合理设置消息大小。
合理设置 Kafka 参数：Kafka 提供了很多参数可以进行调优，如消息压缩、缓存大小、日志清理策略等。需要根据具体的业务场景和需求来合理设置这些参数，以提高 Kafka 的性能和可靠性。
使用 Kafka Connect：Kafka Connect 是 Kafka 提供的一个工具，可以用于将 Kafka 与其他数据源（如数据库、文件系统等）进行集成。使用 Kafka Connect 可以简化数据集成的过程，提高数据传输的效率和可靠性。
使用 Kafka Streams：Kafka Streams 是 Kafka 提供的一个流处理框架，可以用于实时处理数据流。使用 Kafka Streams 可以将数据处理和数据传输集成在一起，提高数据处理的效率和可靠性。

需要注意的是，Kafka 的优化需要根据具体的业务场景和需求来进行，不同的业务场景和需求可能需要不同的优化策略。

orc,rc,parquet列式存储有什么区别，底层存储的内存是否是连续的？

ORC、RC、Parquet 都是列式存储格式，相比于传统的行式存储格式，它们在存储和查询性能上都有很大的提升。它们的主要区别如下：

ORC（Optimized Row Columnar）：ORC 是由 Apache Hive 开发的一种列式存储格式，它支持高度压缩和快速读取，适合于大规模数据仓库和数据分析场景。ORC 的压缩率比较高，适合于存储大量的历史数据。
RC（Record Columnar）：RC 是由 Facebook 开发的一种列式存储格式，它支持快速读取和写入，适合于实时数据处理和分析场景。RC 的压缩率比较低，适合于存储实时生成的数据。
Parquet：Parquet 是由 Apache 开发的一种列式存储格式，它支持高度压缩和快速读取，适合于大规模数据仓库和数据分析场景。Parquet 的压缩率比较高，适合于存储大量的历史数据。

这些列式存储格式底层存储的内存并不是连续的，而是按照列组织的。列式存储格式将同一列的数据存储在一起，可以大大提高数据的压缩率和查询效率。在查询时，列式存储格式只需要读取需要的列数据，可以减少不必要的数据读取和处理，提高查询效率。此外，列式存储格式还支持向量化处理，可以进一步提高查询效率。

Spark 任务是如何执行的，有哪些执行策略？

Spark 任务的执行可以分为两个阶段：作业的构建和作业的执行。在作业的构建阶段，Spark 会根据作业的依赖关系生成一个 DAG（有向无环图），并且根据 DAG 中的任务依赖关系将作业划分为多个阶段。在作业的执行阶段，Spark 会将每个任务分配到可用的节点上，并通过内存和磁盘 IO 来执行这些任务。

Spark 的执行策略有多种，包括本地模式、独立部署模式、YARN 模式、Mesos 模式等。每种执行策略都有不同的优缺点，应该根据具体的业务需求和场景来选择适合的执行策略。