Jweilai

一步一个脚印，一天一道大数据面试题祝你身体健康，事事顺心！近期和线下同事领导们聊天，感受到自己的博客有可以升级，变得，变得。和各位分享一下打算升级的背景，原因。

一步一个脚印，一天一道大数据面试题祝你身体健康，事事顺心！Doris 是当下大热的 MPP 数据库，下面来聊聊它如何保证高性能的部分。

一步一个脚印，一天一道大数据面试题祝你身体健康，事事顺心！

一步一个脚印，一天一道大数据面试。上次梳理了Spark优化，最近想了想通用的优化方法。就是不管优化哪种语言哪种框架都通用的优化思路。分享就是收获，我们开始吧！

一步一个脚印，一天一道大数据面试题祝你身体健康，事事顺心！Spark 如何做优化一直是面试过程中常问的问题。那么这次也仅以此篇文章总结梳理，希望对大家有帮助。

一步一个脚印，一天一道大数据面试题祝你身体健康，事事顺心！我们来看看Flink SQL。

一步一个脚印，一天一道面试题 简单写几个Flink SQL的优化。

Checkpoint是Flink的另一种状态快照机制，它比Savepoint更为频繁，提供了细粒度的状态恢复点。通过配置Checkpoint，Flink会周期性地自动保存作业的状态。如果作业失败，Flink可以根据最后一个成功的Checkpoint自动重启并恢复状态，从而达到“恰好一次”或“至少一次”的处理语义。要启用Checkpoint，需要在作业配置中开启Checkpoint并设置Checkpoint的参数，如间隔时间、模式等。类似，是拿来保存当时状态的一个机制。以便后续可以从这个状态恢复执行。

一步一个脚印，一天一道面试题。我是近未来，祝你变得更强！首先，为什么要读过的。

数据可靠性一直是各个技术都需要的一个特性。不能在使用过程中数据被错误消费，多消费少消费，或者直接漏了数据。那就来看看热门消息队列 Kafka 在数据可靠性方面做了些什么。

Kafka是热门的消息队列组件，在大数据中十分常见。Kafka的是其成为热门组件的重要原因。那么就来聊聊，Kafka为什么那么快。

一步一个脚印，一天一道面试题。搞点简单的。

物化视图，顾名思义，是将一个查询的结果预先计算并存储为物理表的形式。这意味着，原本需要在运行时动态执行的复杂查询，现在变成了直接从已经计算好的结果表中读取数据，极大地提升了查询速度。它是一种典型的“空间换时间”的策略，牺牲一定的存储空间来换取查询性能的显著提升。

数据湖（Data Lake）是一种集中存储企业所有原始数据的体系结构，它允许数据以原始、未经过加工的格式被收集并存储。这种存储方式通常不预先定义数据的结构，而是保留数据的原始形态，包括结构化数据（如关系数据库中的表格数据）、半结构化数据（如CSV、日志文件、XML、JSON）和非结构化数据（如文本文件、图像、音频、视频等）。数据湖的核心价值在于它提供了一个灵活的环境，让企业能够在需要时对数据进行分析、处理和转化，适应各种不同的业务需求和分析场景。

Doris 能很好地与Hadoop、Spark等大数据生态系统集成，也支持与各类BI工具对接，便于数据可视化和报告生成。：MPP 架构和列式存储设计让 Doris 能够处理高并发的查询请求，即使在数据量庞大的情况下也能保持查询的高效性。其定位更倾向于提供一种统一的分析平台，兼顾实时性和大规模数据处理能力，满足企业多样化的数据分析需求。Doris 既可以作为实时数仓使用，支持企业对数据的实时监控和决策需求，也可以作为离线分析的数据仓库，处理历史数据的深度分析和挖掘。，也就是说，对实时导入的数据会更友好。

一步一个脚印，一天一道面试题近期工作时有用到 Spark 2 升级 Spark 3，解决问题的情况。任务原本是运行小时后，升级到Spark 3后，任务运行小时，并且。平时用 Spark 3 用的也多，就当记录一下。

是整个 Spark 的基础，核心概念。是我们用Spark 时的基础数据单位。这个概念是为了让我们少去考虑数据的大数据量下的并行计算问题。简化我们需要的操作量。：在下面的示例代码中，rdd1 是不会变的，而我们 rdd.map 后，会得到一个。：由于是分布式的，所以可以做到每个节点都计算一部分数据，最后分别输出或汇总输出。： Spark 有多个节点，往往不是单节点运行，是集群中多个节点里都有数据。一步一个脚印，一天一道面试题。我是近未来，祝你变得更强！首先，RDD 全称是。

我觉得简单的又有些不想写，复杂的又懒得写，所以拖延下来了。但完成比完美更重要，草草发一个也比迟迟不开始好很多。一步一个脚印，一天一道面试题。我是 及未来，祝你变得更强！

1.看是否数据倾斜单独优化；2.调整到资源充裕的时间段 3.增加资源；时有些 excutor，网络等问题导致失败。一般数据倾斜的概率不高。日常遇到挺多，但没文字记录下来，临时就想到这些，欢迎留言补充。读取还不会报错，但如果用这张表里读的数据去进行下一步的。（程序）被外部应用干掉了，听起来挺奇葩的，但大多就是。这种是因为那个表的那个分区里有脏数据。报错也是一个不错的帮助，来总结一下吧。清理错误数据，可以考虑删除文件，或。一步一个脚印，一天一道面试题。我是近未来，祝你变得更强。写入，就会发生报错。

一步一个脚印，一天一道面试题。因为大数据早已脱离了当初只要搭建 集群就算成功的蛮荒时代。为了各个大数据组件使用方便，国内的大企业都用上了大数据平台，这些平台会集成，图形化管理，升级各类组件。比如你可以图表的形式去了解集群状态，存储使用等。非常方便。然后现在的面试也很多会问有没有使用到公司在用的大数据平台。那这次也就简单说说咱们国内相对常见的大数据平台吧。简单总结：免费的，Apache 开源的大数据平台，2022年1月停止维护。实际使用：Ambari作为一款开源的集群管理工具，在Hadoop生态系统中被广

一步一个脚印，一天一道面试题。首先，？是表的属性数据。比如建表语句，是哪个数据库下的，有哪些字段，数据存放到哪个位置。这些元数据很重要，但相对较碎，较小，不太适合存放在HDFS上。所以一般。

数据仓库是我们大数据十分重要的组成部分，也能在这套规范里找到处理海量数据的智慧。（虽然很多公司即使用了数据仓库后还是有很多效率，浪费之类的问题，但那就是数据治理的后话了）我是 jiweilai，祝你变的更强！

如果是下游的数据处理不及时：提高每批次拉取的数量。批次拉取数据过少（拉取数据/处理时间<生产速度），使处理的数据小于生产的数据，也会造成数据积压。如果是Kafka消费能力不足，则可以考虑增加Topic的分区数，并且同时提升消费组的消费者数量，消费者数=分区数。许多时候，Kafka消费积压是消费的不及时。可能需要看看消费者组件，比如。我是 Jiweilai，祝你变得更强！一步一个脚印，一天一道面试题。2.增加每批次拉取数量。3.优化消费者代码。

所以讨论下来减少分区真是费力不讨好的事，而且忽然在想，好像没什么场景是一定要减少分区的。，原因想想也挺简单的，减少了分区数后，被减少的分区的数据应该怎么处理？命令对 Kafka 增加 Kafka 的分区数据。是一个主流的分布式消息队列。我是 Jiweilai，祝你变得更强！偏移量，记录数据消费到哪个位置了。一天一个脚印，一天一道面试题。

Kafka 作为一个天生支持分布式的消息队列，为了数据的可靠性，很自然支持了** 备份 Replica**。而消息队列的备份需要及时的跟leader副本保持一致，否则数据不是最新的，对数据队列来说也是不能用的。

一步一个脚印，一天一道面试题。

对小型查询和交互式分析的性能可能不如专门的查询引擎；：Presto采用内存计算和并行执行机制，能够快速处理大规模数据查询，适合高性能的交互式查询。：支持多种数据源和 ANSI SQL 标准，可以进行跨源的复杂查询和分析操作。：采用分布式共享无状态计算模型，具备高可伸缩性和容错性，适合大规模数据处理。：具备动态优化器功能，能够根据查询特性选择最佳执行计划，提升查询性能。：由于内存计算和并行执行，可能消耗较多的资源，需要合理规划和管理资源。：管理和配置相对复杂，需要一定的专业知识和经验。

Flink 支持将任务管理器（TaskManager）配置为高可用模式。当任务管理器发生故障时，会有另一个备份任务管理器接管其职责，从而保证应用程序的持续执行。：Flink 提供了多种容错恢复策略，可以根据具体的需求进行配置。例如，可以设置重启策略来确定在发生故障时是否重新启动任务，并设置重试次数和重试间隔等参数。

合理的并行度设置可以更好的利用集群性能，否则可能会“有力使不出”或“杀鸡用牛刀”的情况。：尽量在本地节点做更多的操作，减少网络传输等开销，比如使用 mapjoin；：Parquet，ORC 是可以减少 I/O ，网络传输速率等的。收集表的信息，可以让优化器更可能做出更好的查询计划；：一般不要使用 SELECT *，只获取真正需要的列。：合适的分区和分桶能减少数据量的输入。可以减少小文件数量，提高效率。一步一个脚印，一天一道面试题。

2.共享性：多个不同表可以共用同一份数据源进行不同的ETL逻辑处理。3.灵活性：当对表结构进行调整时，无需额外备份数据。1.安全性：避免误操作导致数据丢失。

这几天生病了，每天只睡2到4小时，吃药恢复了，就先来点简单的题。这是一个挺简单的题，不过有时一问我，我还真只结结巴巴说出。

Slot 是 Flink 的最小资源管理单位。目前 Slot 可以隔离内存，但不能隔离 CPU，CPU 是 TaskManager 共享的。Flink 的每个算子都可以单独设置并行度。一般来说，并行度越大，处理能力越大，处理的就越快。，尽量每个 task 都有 slot，避免 task 出现等待资源的情况。可以在 Flink 的 web 中找到。该文章有较多引用文章。

在流式处理框架中，如果下游的处理速度，比上游的输入数据小，就会导致程序处理慢，不稳定，甚至出现崩溃等问题。

在 Hadoop, Spark, Presto, Python 等都支持，所以 Parquet 文件可以在不同系统和语言通用。同一列的数据是同一种数据类型，所以压缩比例可以更高。同时一般查询使用时不会使用所有列，而是只用到几列，所以查询速度会更快。因为是列式存储，所以可以对同一类型的一段做压缩，压缩比例高。

在实时处理任务时，由于网络延迟，人工异常，各种问题，数据往往会出现乱序，不按照我们的预期到达处理框架。话不多说，直接给个 Watermark 水印样例代码。一步一个脚印，一天一道面试题。WaterMark 水印，就是。

将状态存储在 FileSystem，如本地文件系统，或 HDFS 文件系统。写入到文件后，如果遇到程序中断停止，能够正常恢复。生产环境中， FsStateBackend 是个不错的选择。所以如果需要更高的性能，可以使用这个状态后端。那作为最热门的实时处理框架，Flink对状态管理是有一套的。那就是状态后端，拿来管理，储存 Flink 里状态的东西，默认是用 MemoryBackend。很不稳定，如果程序中断停止，存在内存中的状态就会消失，重启不能正常恢复，处理状态。那就需要记录到之前的状态，数值。

一步一个脚印，一天一道大数据面试题。

最后，在数据消费端，需要确保消费者能够支持“事务性”提交，比如使用支持事务的数据库（如 MySQL）进行数据写入。这样，在发生故障时，Flink 可以回滚未完成的事务，并重新执行已提交的事务，从而保证数据的一致性和准确性。尽管在程序正常运行、资源充足的情况下实现 Exactly-Once 语义并不难，但实际生产环境中存在各种复杂情况和突发状况，因此为了可靠地实现 Exactly-Once，需要以下容错机制。这样，如果程序重启，可以准确地从未被消费的第一条数据开始读取，既不会多读也不会少读。

一步一个脚印，一天一道大数据面试题。Flink 是大数据实时处理计算框架。实时框架对检查点，错误恢复的功能要比离线的更复杂，所以一起来了解 Flink 的 Checkpoint 机制吧。