hive 、spark 、flink之想一想

hive 、spark 、flink之想一想

hive

1：hive是怎么产生的？

Hive是由Facebook开发的，目的是让拥有SQL知识的分析师能够在Hadoop上进行数据查询。Hive提供了类SQL的查询语言HiveQL，通过将HiveQL查询转换为MapReduce任务来在Hadoop上处理大规模数据。

2：hive的框架是怎么样的？

• 用户接口： 支持HiveQL查询的命令行工具和其他客户端。
• 驱动器： 处理用户请求，执行查询解析、计划制定、任务执行等。
• 编译器： 将HiveQL查询转换为可执行的计划。
• 元数据存储： 存储表、列、分区等元数据信息。
• 执行引擎： 负责执行计划中的任务，通常是MapReduce任务。

3：hive 执行流程是什么？

1. 用户提交HiveQL查询。
2. 驱动器接收查询并调用编译器进行解析和编译。
3. 编译器生成执行计划，转换为一系列的MapReduce任务。
4. 执行引擎负责执行这些MapReduce任务。
5. 结果返回给用户。

4：hive sql是如何把sql语句一步一步到最后执行的？

Hive SQL的执行过程主要包括解析、编译、优化、执行四个阶段。在解析阶段，Hive将SQL语句解析成抽象语法树；在编译阶段，将抽象语法树转换成逻辑计划；在优化阶段，对逻辑计划进行优化；在执行阶段，将优化后的逻辑计划转换成物理计划，最终转换为MapReduce任务进行执行。

5：hive sql任务常用参数调优做过什么？

• mapreduce.job.reduces：设置Reduce任务的数量。
• hive.exec.reducers.bytes.per.reducer：设置每个Reducer处理的数据量。
• hive.exec.parallel：开启或关闭查询并行执行。
• hive.optimize.skewjoin：开启倾斜数据处理。等等。调优的具体参数和策略会根据实际的数据和查询需求而有所不同。

spark

6：spark 是怎么产生的？

Spark是在加州大学伯克利分校的AMPLab开发的，旨在解决MapReduce计算模型在迭代计算和交互式数据分析方面的不足。Spark提供了一个更高效、更通用的数据处理框架。

7：spark 框架是怎么样的？

• RDD（弹性分布式数据集）： Spark的基本抽象，代表一个不可变、分布式的数据集合。
• DAG调度器： 将用户的操作转换为DAG图，并进行任务调度。
• 执行引擎： 负责任务的执行和资源管理。

8: spark的DAG是什么？

DAG是指向无环图，是Spark中表示任务依赖关系的图。在Spark中，每个操作（如map、filter等）都会生成一个新的RDD，操作之间的依赖关系构成了一个DAG。Spark会根据DAG来进行任务的调度和优化。

9：spark中的app，job,stage,task是什么？有什么好处？

• App（Application）： 用户提交给Spark的整个应用程序。
• Job： 由一次Action操作触发的一系列计算任务，比如一个RDD的count()操作会触发一个Job。
• Stage： Job会被分为一个或多个Stage，每个Stage由一组并行执行的任务组成。Stage之间的划分是根据Shuffle操作（如reduceByKey）来进行的，每个Shuffle操作会产生一个新的Stage。
• Task： Stage中的每个任务称为Task，是Spark中最小的执行单元，每个Task对应于处理RDD的一个分区。

这种划分有助于Spark进行更细粒度的任务调度和容错处理。

10：spark的RDD是什么？与dataframe有什么区别？

• RDD（Resilient Distributed Dataset）： 是Spark的一个基础抽象，代表一个不可变、分布式的数据集合。RDD提供了底层的功能，如分区、持久化等，但不提供高级的查询优化。
• DataFrame： 是Spark SQL的一个抽象，类似于关系型数据库中的表，提供了丰富的数据操作API，并且可以进行优化的查询执行。DataFrame是基于RDD构建的，但提供了更高层次的抽象，使得操作更加简便，并且能够利用Catalyst优化器进行查询优化。

11：spark 执行流程是什么？

• 用户编写Spark应用并提交。
• SparkContext启动并创建DAGScheduler和TaskScheduler。
• DAGScheduler将逻辑执行计划划分为多个Stage。
• TaskScheduler将每个Stage划分为多个Task并分配给Executor执行。
• Executor执行Task，并将结果返回给Driver。

12：spark sql是如何把sql语句一步一步到最后执行的？

• 用户提交SQL查询。
• SQL解析器将SQL语句解析为逻辑计划。
• Catalyst优化器对逻辑计划进行优化，生成物理计划。
• 物理计划被转换为RDD操作，并提交给Spark引擎执行。
• 执行结果返回给用户。

13：spark 与mapreduce的区别是什么？

• 性能： Spark基于内存计算，通常比MapReduce更快。
• 易用性： Spark提供了丰富的API，支持多种编程语言，易于开发。
• 通用性： Spark支持批处理、流处理、机器学习和图计算等多种计算模型。
• 容错性： Spark和MapReduce都提供了容错机制，但实现方式不同。Spark通过RDD的线性依赖关系进行容错，而MapReduce通过数据重复执行进行容错。

14： spark的反压原理是什么？主动还是被动？

• 反压是指在流处理中，当下游处理速度不足以跟上上游数据生成速度时，自动调整上游数据输入速度的机制。
• Spark中的反压是主动的（Proactive）。Spark Streaming会根据处理速度动态调整接收数据的速率，以防止系统被过载。

flink

14：flink是怎么产生的？

Flink起源于柏林工业大学的Stratosphere项目，后来成为Apache顶级项目。Flink是为了解决流处理和批处理的统一而设计的，它旨在提供低延迟、高吞吐量的数据处理能力。

15：flink的框架是怎么样的？

• Client： 用户编写Flink程序并提交到JobManager的组件。
• JobManager： 负责管理作业的生命周期、调度任务、协调故障恢复等。
• TaskManager： 执行任务的工作节点，每个TaskManager可以运行多个任务。
• Dispatcher： 提供REST接口，用于提交和管理作业。
• ResourceManager： 负责资源管理和分配，支持多种资源提供者，如YARN、Kubernetes等。
• State Backends： 管理状态的存储和访问，支持RocksDB、FsStateBackend等。

16：flink 的内存模型说一说？

• 任务堆内存（Task Heap Memory）： 存储用户任务的数据和对象。
• 网络缓冲内存（Network Buffer Memory）： 用于数据交换和通信的缓冲区。
• 托管内存（Managed Memory）： Flink管理的内存，用于算子状态、数据缓冲等。
• JVM堆外内存（Off-Heap Memory）： 直接在JVM堆外分配的内存，如RocksDB状态后端使用的内存。

17：flink的cp ,sp说一说原理，有什么区别？你们是怎么设置cp的相关参数？

• Checkpointing（CP）原理： Flink通过定期捕获状态快照（Checkpoint）来实现故障恢复。在Checkpoint过程中，Flink会暂停数据处理，确保所有任务的状态一致性，并将状态信息存储到配置的状态后端（如RocksDB、HDFS等）中。当发生故障时，Flink可以从最近的Checkpoint恢复，保证精准一次处理语义。
• Savepoint（SP）： 类似于Checkpoint，但通常用于手动触发的场景，如版本升级、作业迁移等。Savepoint提供了更灵活的状态管理，允许用户在需要时创建快照，并从特定点恢复作业或更改作业的并行度。
• 区别： 主要区别在于用途和触发方式。Checkpoint主要用于故障恢复，自动触发；Savepoint用于状态管理和作业调整，手动触发。
• 设置CP参数：常见的Checkpoint参数设置包括：- checkpoint.interval：设置Checkpoint间隔时间。- checkpoint.timeout：设置Checkpoint超时时间。- state.backend：设置状态后端存储。- checkpointing.mode：设置Checkpoint模式（EXACTLY_ONCE或AT_LEAST_ONCE）。等等。具体参数设置根据作业需求和系统资源进行调整。

18：flink的四个图是什么？分别都是什么环节对应什么图？

• 抽象语法树（AST）： 表示用户程序的初始结构。
• 逻辑计划： 对AST进行优化后的结果，描述了操作之间的逻辑关系。
• 优化计划： 对逻辑计划进一步优化，选择最佳的执行策略。
• 执行图（Execution Graph）： 最终的执行计划，包含了任务的并行性信息和物理执行细节。

19：flink反压机制，你是如何理解的？你是如何定位、并有什么方案解决？与spark的反压有什么区别？

• 理解： Flink的反压机制用于处理任务之间速度不匹配的情况。当下游任务处理速度慢于上游任务时，上游任务的输出缓冲区会积累数据，导致反压。Flink通过监控缓冲区的使用情况来检测反压，并动态调整任务的处理速度。
• 定位与解决： 可以通过Flink的Web UI监控界面查看反压情况，定位哪些任务或操作符产生了反压。解决方案包括增加下游任务的并行度、优化慢速任务的处理逻辑、调整网络缓冲区大小等。
• 与Spark的区别： Flink的反压是基于每个任务实例的，可以提供更细粒度的控制；而Spark的反压是基于整个阶段的，当反压发生时，整个阶段的速度会被调整。

20：flink的barrier对齐和非对齐是怎么理解的？

• Barrier对齐（Aligned Checkpointing）： 所有输入流必须等待检查点屏障到达，才能继续处理。这种方式简化了状态的管理，但可能会导致较高的延迟，因为所有流都必须同步等待。
• 非对齐（Unaligned Checkpointing）： 允许输入流在等待检查点屏障时继续处理数据。这可以减少延迟，但需要更复杂的状态管理机制。非对齐检查点在Flink 1.11及更高版本中引入，用于改善反压下的性能。

21：flink的精准一次和至少一次是怎么理解的？

• 精准一次（Exactly-Once）： 每条数据在整个数据流处理过程中只被处理一次，即使在发生故障的情况下也能保持这一点。Flink通过检查点机制实现精准一次的状态一致性，以及与外部系统（如Kafka）集成时的端到端精准一次语义。
• 至少一次（At-Least-Once）： 每条数据至少被处理一次，但在某些情况下可能会被处理多次，例如，在故障恢复过程中。这种一致性级别通常有更低的延迟，但可能会导致数据重复。

22：flink任务消费或者写入kafka时，并行度不一致有什么问题？

当Flink任务的并行度与Kafka分区数不一致时，可能会导致数据分配不均或资源利用率不高。例如，如果Flink任务的并行度大于Kafka分区数，那么某些任务实例可能不会接收到数据。为了避免这种情况，通常建议将Flink任务的并行度设置为Kafka分区数的整数倍。

23：flink如何保证数据一致性？

Flink通过检查点（Checkpointing）机制保证数据的一致性。在检查点过程中，Flink会保存所有任务的状态快照，并确保在故障恢复时能够从检查点恢复到一致的状态。此外，Flink还支持端到端的精准一次处理，通过与外部系统（如Kafka）的集成来保证整个数据流的一致性。

24：flink对于kafka新增分区时，消费有什么问题吗？

当Kafka主题的分区数增加时，Flink需要重新平衡消费者以适应新的分区。Flink提供了动态分区检测功能，可以自动识别并开始消费新的分区。但是，这可能会导致数据分配不均或处理延迟。因此，建议在Flink任务运行时避免频繁调整Kafka分区数。

25：flink消费kafka的offset是怎么维护的？自动提交？

Flink消费Kafka时，通常会将消费的Offset保存在Flink的状态中，并通过检查点机制进行持久化。这样可以确保在任务故障恢复时能够从正确的位置继续消费。Flink通常不使用Kafka的自动提交机制，而是通过自己的状态管理和检查点机制来维护Offset。

26：flink任务如何设置TM，JM的并行度？

• TaskManager（TM）并行度： 通过配置taskmanager.numberOfTaskSlots参数来设置。每个TaskManager可以有多个任务槽，每个槽可以运行一个并行任务。因此，TaskManager的并行度决定了它可以同时运行的任务数量。
• JobManager（JM）并行度： 实际上是由提交作业时指定的并行度参数决定的，并不直接设置JobManager的并行度。JobManager负责协调作业的执行，包括任务调度、故障恢复等，但它本身不执行具体的任务。作业的并行度决定了作业中任务的并行实例数。

27：flink任务做过什么调优？

• 调整并行度和任务槽数以提高资源利用率。
• 优化状态管理，选择合适的状态后端和状态存储位置。
• 调整缓冲区大小和网络参数以减少延迟和提高吞吐量。
• 使用异步I/O操作来提高外部数据存储的访问性能。等等。具体的调优策略会根据作业的特点和运行环境而有所不同。

28：flink任务大状态时做过什么优化？

• 增加状态后端的缓存和写入效率： 选择合适的状态后端（如RocksDB）并优化其配置，可以提高大状态处理的效率。
• 使用增量检查点（Incremental Checkpointing）： 对于大状态，增量检查点可以减少检查点的数据量，提高检查点的速度。
• 状态分区和分布式存储： 将大状态分散存储在多个TaskManager或外部存储系统中，可以减少单个节点的压力。
• 调整并行度： 增加作业的并行度，可以将大状态分散到更多的TaskManager上，减轻单个节点的负担。

29：你们用flink做过实时数仓吗？你们的上下游的环境都是什么？全链路时效是多少？

• 应用场景： 使用Flink构建实时数仓，处理来自各种数据源的实时数据流，并将处理后的数据存储到Doris中用于实时分析和查询。
• 上游环境： 包括Kafka作为实时数据流的来源，日志文件、数据库变更日志等作为数据源。
• 下游环境： 数据处理后存储到Doris中。Doris是一个MPP（Massively Parallel Processing）架构的分析型数据库，适用于实时数据仓库场景。
• 全链路时效： 在Flink和Doris搭建的实时数仓中，全链路时效指的是从数据生成、采集、处理到存储到Doris并可查询的整个过程所需的时间。根据具体的业务需求和系统设计，全链路时效可以做到秒级或分钟级。