【新鲜出炉】7月广州某易数开面经

1、数据平台中，任务计算成本的计费维度？

1）计算资源：cpu使用量，内存使用量

  2）存储资源：存储空间，存储时间

  3）数据传输：数据传出，数据传入

  4）作业的执行时间

  5）服务类型：离线批处理还是在线流处理

2、Spark作业从哪些方面可以发现能够优化？Spark作业可以从哪些方面进行优化？从哪些配置入手 or 从哪些阶段入手？

3、数据冷备底层实现

一、异构存储是什么

HDFS异构存储的价值在于，根据数据热度采用不同的策略从而提升集群整体资源使用效率，对于频繁访问的数据，将其保存在更高访问性能的存储介质上；对于几乎不会访问的数据，保存在归档存储介质上，降低存储成本

对于HDFS异构存储的配置需要用户对目录指定相应的策略，用户需要预先知道文件的访问热度，然后后续相应的程序在对应分类目录下写数据，

一般的大部分数据都是冷数据或者极冷数据，对于该部分数据，读取请求很少，对访问延迟不敏感，可采用高压缩比，存储到普通的SATA大容量盘中去，极大节约成本

对于热数据和实时数据，读写请求较高，数据量很小，为了实现高并发低延迟，可将这部分数据保存到SSD中

二、HDFS异构存储类型和策略

HDFS异构存储支持四种：RAM_DISK SSD DISK（默认存储介质） ARCHIVE（不是某种存储介质，是高密度存储方式，用于存储极冷数据）

三、HDFS异构存储原理

https://www.cnblogs.com/caoweixiong/p/13578756.html

  1、在hdfs的配置文件hdfs-site.xml中配置对应的异构存储（后面配置部分有详细介绍）

  2、DataNode启动的时候从配置文件中读取对应的存储类型，以及容量情况，并通过心跳的形式不断的上报给ＮameNode。

  3、NameNode收到DataNode发送的关于存储类型、容量等内容的心跳包后，会进行处理，更新存储的相关内容。

  4、写请求发到NameNode后，NameNode根据写请求具体的目录对应的存储策略选择对应的存储类型的DataNode进行写入操作。

4、Hive表数据文件存储格式、压缩方式？

https://www.cnblogs.com/jimmy888/p/13551605.html

压缩方式：

存储格式：TEXTFILE（行式存储） 、SEQUENCEFILE(行式存储)、ORC（列式存储）、PARQUET（列式存储）。企业中使用orc较多。

5、StarRocks各个组件的作用

6、Hive数据推送至StarRocks，使用什么工具？底层实现？

7、Spark动态分区合并小文件的底层实现？

https://blog.csdn.net/syhiiu/article/details/140277490

1）底层原理概述

Spark动态分区合并是Spark SQL中自适应查询执行（Adaptive Query Execution，简称AQE）特性的一个重要组成部分，底层原理主要涉及到分区数据的优化处理和任务调度

在spark中，分区是组织数据的基本单位，分区数决定了并行计算的并发度，动态分区合并主要作用于shuffle阶段，针对shuffle后产生的小分区进行优化，通常是数据分布不均衡或者分区策略不当，shuffle后可能会产生大量的小分区，增加任务调度的开销，降低了作业的性能；

动态分区的底层原理是通过分许shuffle后的数据分布，将多个小分区合并成较大的分区，以减少任务数量，提高并行度，从而优化作业性能

2）动态分区合并实现方式

补充：spark动态分区合并的优点

1）通过合并小分区，减少任务数量，降低任务调度的开销

2）提高并行度，使得资源得到有效的利用，加快作业的执行速度

3）在大规模数据量时候，能显著减少IO操作次数，提高数据处理的效率

补充：spark动态分区合并的缺点

1）增加内存压力，在合并分区过程中，需要暂时将多个小分区的数据存储在内存中，会增加内存的使用量，如果内存资源不足，可能会导致数据溢写到磁盘上，从而影响性能

2）依赖AQE，动态分区合并时AQE的一个特性，如果配置不当，动态分区合并将无法正常工作

8、如何判断一张表存在小文件问题？

  1）文件数量和大小分布

  检查表所在目录的文件数量和每个文件的大小，如果目录中存在大量小文件，则可能存在小文件问题

  2）表的分区数量

  检查表的分区数量，如果表有很多分区，每个分区有很多小文件，则可能存在小文件问题

  3）文件元数据

  计算表的元数据大小，如果元数据大小相对于表的数据大小较大，则可能存在小文件问题

  4）查询性能

  执行查询性能，如果查询性能不佳且数据扫描时间较长，则可能存在小文件问题

9、小文件一般合并到多少合适？

HDFS中默认的大小块是256MB，理想情况下文件大小应该接近这个块大小，

如果是Spark，需要考虑框架的IO和并行处理能力；文件太小会导致任务过多，增加调度开销，文件太大则可能导致并行度不足

10、MySQL中 like关键字会命中索引嘛？

在mysql中使用like关键字时候，也会命中索引，不过是需要like在后面，才能命中

例如：

  SELECT * FROM user WHERE username LIKE '%ptd_%';没有命中索引，采用全表扫描

  SELECT * FROM user WHERE username LIKE 'ptd_%';命中索引

  SELECT * FROM user WHERE username LIKE '%ptd_';没有命中索引，全表扫描

11、怎么判断一个SQL查询是否命中了索引？

在select前面加一个关键字explain，查看执行计划，其中结果的type字段就是 是否命中索引以及使用的索引类型是什么，常用的类型有： ALL, index, range, ref, eq_ref, const, system, NULL（从左到右，性能从差到好）

12、介绍下MySQL中索引底层实现的数据结构：B+树索引、哈希索引

B+树索引：

B+树的非叶子节点的子树指针与关键字个数相同，非叶子节点只存储关键字信息，所有叶子节点之间都有指针相连，数据记录都存放在叶子节点中

哈希索引：

哈希作为索引，对索引的key进行一次hash计算就可以定位出数据存储的位置，仅能满足“=”和“IN”，不支持范围查询，也会存在hash冲突的问题

13、B+树和哈希的区别？ 什么情况下使用B+树索引、什么情况下使用哈希索引？

1. 结构和查找方式

• B+树:B+树是一种平衡树结构，所有的叶子节点在同一层，并且通过链表连接。每个节点包含多个键值和指向子节点的指针。B+树中的数据按顺序存储，可以进行范围查询、顺序遍历。查找过程是基于范围的，从根节点开始，通过比较键值逐层向下查找，直到找到对应的叶子节点。
• 哈希:哈希结构通过一个哈希函数将键值映射到特定的位置（桶）中，桶内可能存放一个或多个键值对（在发生哈希冲突时）。哈希索引支持精确查找，通过哈希函数直接定位到数据所在的桶中。哈希索引无法进行范围查询，也不支持有序遍历。

何时使用 B+树索引，何时使用哈希索引？

使用 B+树索引的场景

• 范围查询: 当你需要查找一个范围内的所有数据时，例如 SELECT * FROM table WHERE value BETWEEN 10 AND 20。
• 排序操作: 当查询结果需要排序时，B+树索引可以直接返回有序结果，例如 ORDER BY 操作。
• 前缀匹配: 对于字符串类型的前缀匹配查询，例如 LIKE 'abc%'，B+树索引非常适合。
• 多列索引: 当你创建复合索引（多列索引）并使用索引的前几列进行查询时，B+树索引能够有效利用这些索引。

使用哈希索引的场景

• 等值查询: 当你只需要精确查找某个值时，例如 SELECT * FROM table WHERE id = 123。
• 高并发精确查询: 哈希索引适合在高并发下执行大量的精确匹配查询。
• 简单主键查找: 如果你经常通过主键进行查询，并且不需要进行范围查询或排序，哈希索引是一个很好的选择。

14、like关键字可以命中哈希索引嘛？

  1、精确匹配，如果like关键字用于精确匹配，即like ‘一个精确的值’，在这种情况下，实际上等同于=。可以命中哈希索引

  2、前缀匹配；如果like用于前缀匹配，类似like ‘pre%’，哈希索引无法命中

15、like满足什么条件可以命中B+树索引？

1. 前缀匹配

  当 LIKE 模式是以固定字符串开头，并以 % 结尾时（即前缀匹配），可以利用 B+ 树索引。

  2. 精确匹配

  虽然这不是典型的 LIKE 模式，但如果 LIKE 模式是一个完全确定的字符串，它可以命中 B+ 树索引，因为它等同于使用 =。

3. 复合索引的前缀列

  如果你在多列上创建了复合索引，并且 LIKE 查询只针对复合索引中的第一列进行前缀匹配，那么该查询也可以命中索引。

补充：like不能命中B+树索引的情况？

1. 通配符 % 在开头

如果 LIKE 模式以 % 开头（例如 '%suffix' 或 '%substring%'），B+ 树索引无法使用，因为这种查询无法利用索引的有序性来快速定位数据。

2. 通配符 _

如果 LIKE 使用了 _ 来表示单个字符的匹配，B+ 树索引通常也无法被有效利用，因为 _ 可能匹配任意位置的字符，无法充分利用索引的有序性。

16、介绍最左前缀原则？

简单而言就是 最左优先，在创建多列索引时候，要根据业务需求，where语句中使用最频繁的一列放在最左边

对于索引中的字段，myql会一直向右匹配知道遇到范围查询><between like就停止匹配，后面的字段不再使用索引

通常使用explain查看索引类型：

1.type：联接类型。下面给出各种联接类型,按照从最佳类型到最坏类型进行排序:（重点看ref,rang,index）

　　　　system：表只有一行记录（等于系统表），这是const类型的特例，平时不会出现，可以忽略不计　　　　const：表示通过索引一次就找到了，const用于比较primary key 或者 unique索引。因为只需匹配一行数据，所有很快。如果将主键置于where列表中，mysql就能将该查询转换为一个const　　　　eq_ref：唯一性索引扫描，对于每个索引键，表中只有一条记录与之匹配。常见于主键 或 唯一索引扫描。　　　　注意：ALL全表扫描的表记录最少的表如t1表　　　　ref：非唯一性索引扫描，返回匹配某个单独值的所有行。本质是也是一种索引访问，它返回所有匹配某个单独值的行，然而他可能会找到多个符合条件的行，所以它应该属于查找和扫描的混合体。　　　　range：只检索给定范围的行，使用一个索引来选择行。key列显示使用了那个索引。一般就是在where语句中出现了bettween、<、>、in等的查询。这种索引列上的范围扫描比全索引扫描要好。只需要开始于某个点，结束于另一个点，不用扫描全部索引。index：Full Index Scan，index与ALL区别为index类型只遍历索引树。这通常为ALL块，应为索引文件通常比数据文件小。（Index与ALL虽然都是读全表，但index是从索引中读取，而ALL是从硬盘读取）　　　　ALL：Full Table Scan，遍历全表以找到匹配的行

where后面的查询条件，不论是使用（id，cid，name）（name，id，cid）还是（cid，name，id）顺序，在查询时都使用到了联合索引；为什么底下两个的搜索条件明明没有按照联合索引从左到右进行匹配，却也使用到了联合索引？是因为MySQL中有查询优化器explain，所以sql语句中字段的顺序不需要和联合索引定义的字段顺序相同，查询优化器会判断纠正这条SQL语句以什么样的顺序执行效率高，最后才能生成真正的执行计划，所以不论以何种顺序都可使用到联合索引。

17、最左前缀是对于联合索引来说的，如果只有一个索引，使用like什么情况下索引会失效？

1）对索引使用左或者左右模糊匹配的时候，索引会失效

类比：where name like '%李%'，where name like '李%'

2）如果查询条件中对索引字段使用函数，就会导致索引失效

  因为索引保存的是索引字段的原始值，而不是经过函数计算过后的值，自然就无法走索引

3）对索引进行表达式计算

  原因和函数失效道理一样，索引保存的是字段的原始值，而不是处理过后的值

4）对索引进行隐式类型转换

  5）联合索引非最左匹配

  多个普通字段组合在一起创建的索引就叫做联合索引，联合索引（a,b,c）和（ b,c,a）在使用时候会有区别

6）where子句中的or

  如果在or前的条件是索引列，而在or后面的条件列不是索引列，那么涉及到的索引都会失效。

  7）字符串没有加引号的情况使用索引，索引将会失效；

  8）若mysql评估，全表扫描比索引查找快，则使用全表索引