大数据领域面试题（数据中台方向）

本文档整理了大数据应用开发岗位的核心面试题，涵盖Java基础、大数据技术栈、OLAP数据库、数据仓库、中间件、项目经验等多个维度。每个类别按照基础问题、一般问题、困难问题三个难度级别组织。

一、Java核心与后端框架

1.1 Java基础

1.1.1 集合框架

基础问题

Q1: ArrayList和LinkedList的区别？

A:

• ArrayList：基于动态数组，随机访问O(1)，插入删除O(n)
• LinkedList：基于双向链表，随机访问O(n)，插入删除O(1)
• ArrayList适合查询多、修改少的场景；LinkedList适合频繁插入删除的场景

Q2: HashMap和Hashtable的区别？

A:

• HashMap线程不安全，Hashtable线程安全（synchronized）
• HashMap允许null键值，Hashtable不允许
• HashMap效率更高，Hashtable已过时，推荐使用ConcurrentHashMap

Q3: HashSet的实现原理？

A:

• HashSet内部使用HashMap实现
• 元素作为HashMap的key，value使用固定的Object对象
• 利用HashMap的key唯一性保证元素不重复

一般问题

Q1: HashMap的实现原理？

A: HashMap基于哈希表实现，使用数组+链表+红黑树（JDK1.8）的结构：

• 初始容量16，负载因子0.75
• 通过key的hashCode计算数组索引位置
• 当链表长度超过8且数组长度>=64时，链表转为红黑树
• 扩容时容量翻倍，重新计算hash分布

Q2: HashMap的扩容机制？

A:

• 当元素数量超过容量×负载因子时触发扩容
• 扩容时容量翻倍（2的幂次）
• 重新计算每个元素的hash值，分配到新数组
• JDK1.8优化：扩容时保持链表顺序，减少重新hash的计算

Q3: ConcurrentHashMap如何保证线程安全？

A: JDK1.8采用分段锁+CAS机制：

• 使用Node数组+链表+红黑树结构
• 对数组元素加synchronized锁（只锁链表头或红黑树根节点）
• 使用CAS操作保证并发修改的安全性
• 支持并发读写，性能优于Hashtable

困难问题

Q1: ConcurrentHashMap在JDK1.7和JDK1.8的区别？

A:

• JDK1.7：使用Segment分段锁，每个Segment是一个独立的HashTable
• JDK1.8：取消Segment，使用CAS+synchronized，锁粒度更细
• 性能提升：JDK1.8的并发性能更好，锁竞争更少
• 实现简化：代码更简洁，维护更容易

Q2: HashMap为什么使用红黑树而不是AVL树？

A:

• 红黑树的插入删除操作更高效，旋转次数更少
• 红黑树对平衡性的要求更宽松，维护成本更低
• 在查找、插入、删除的综合性能上，红黑树更适合HashMap的场景
• AVL树更适合读多写少的场景

Q3: 如何设计一个线程安全的LRU缓存？

A:

• 使用LinkedHashMap + ReentrantReadWriteLock
• 或者使用ConcurrentHashMap + 双向链表 + 读写锁
• 需要考虑并发读写、缓存淘汰策略
• 可以使用Caffeine或Guava Cache等成熟方案

1.1.2 多线程与并发编程

基础问题

Q1: 创建线程的方式有哪些？

A:

1. 继承Thread类
2. 实现Runnable接口
3. 实现Callable接口（有返回值）
4. 使用线程池（推荐）

Q2: synchronized关键字的作用？

A:

• 修饰实例方法：锁对象是当前实例
• 修饰静态方法：锁对象是当前类的Class对象
• 修饰代码块：锁对象是指定的对象
• 保证同一时刻只有一个线程能访问被锁定的代码

Q3: volatile关键字的作用？

A:

• 保证可见性：修改后立即刷新到主内存
• 禁止指令重排序：通过内存屏障实现
• 不保证原子性：如i++操作需要配合synchronized或AtomicInteger

一般问题

Q1: synchronized和ReentrantLock的区别？

A:

• synchronized是JVM层面的锁，ReentrantLock是API层面的锁
• ReentrantLock支持公平锁、可中断、多条件变量
• synchronized发生异常自动释放锁，ReentrantLock需要在finally中手动释放
• ReentrantLock提供更灵活的锁机制，但synchronized性能在JDK1.6优化后已接近

Q2: 线程池的核心参数有哪些？

A:

• corePoolSize：核心线程数
• maximumPoolSize：最大线程数
• keepAliveTime：非核心线程空闲存活时间
• workQueue：任务队列（ArrayBlockingQueue、LinkedBlockingQueue等）
• threadFactory：线程工厂
• handler：拒绝策略（AbortPolicy、CallerRunsPolicy、DiscardPolicy、DiscardOldestPolicy）

Q3: 线程池的拒绝策略？

A:

• AbortPolicy：直接抛出异常（默认）
• CallerRunsPolicy：调用者线程执行任务
• DiscardPolicy：直接丢弃任务
• DiscardOldestPolicy：丢弃队列中最老的任务，然后提交新任务

困难问题

Q1: AQS（AbstractQueuedSynchronizer）的原理？

A:

• 使用CLH队列（虚拟双向队列）管理等待线程
• 通过volatile int state表示同步状态
• 使用CAS操作保证原子性
• 支持独占锁和共享锁两种模式
• ReentrantLock、CountDownLatch、Semaphore等都基于AQS实现

Q2: 如何实现一个自定义的线程池？

A:

• 需要实现任务队列、工作线程管理、任务提交、拒绝策略等
• 核心组件：BlockingQueue、Worker线程、ThreadFactory
• 需要考虑线程生命周期管理、异常处理、优雅关闭等

Q3: 死锁的产生条件和解决方案？

A:

• 产生条件：互斥、请求与保持、不剥夺、循环等待
• 解决方案：
  • 避免嵌套锁
  • 统一锁顺序
  • 使用超时锁（tryLock）
  • 死锁检测和恢复

Q4: CountDownLatch、CyclicBarrier、Semaphore的区别？

A:

CountDownLatch（倒计时门闩）：

• 一个或多个线程等待其他线程完成操作
• 计数器只能使用一次，不能重置
• 使用场景：等待多个线程完成后再执行后续操作

CyclicBarrier（循环屏障）：

• 多个线程互相等待，达到屏障点后继续执行
• 可以重复使用（cyclic）
• 使用场景：分阶段任务，需要所有线程到达某个阶段

Semaphore（信号量）：

• 控制同时访问资源的线程数量
• 可以设置许可数量
• 使用场景：限流、资源池管理

示例：

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

// CountDownLatch
CountDownLatch latch = new CountDownLatch(3);
// 3个线程完成后，主线程继续
latch.await();

// CyclicBarrier
CyclicBarrier barrier = new CyclicBarrier(3);
// 3个线程都到达后，一起继续
barrier.await();

// Semaphore
Semaphore semaphore = new Semaphore(5);
semaphore.acquire(); // 获取许可
semaphore.release(); // 释放许可

Q5: CompletableFuture的使用？

A:

CompletableFuture定义：

• Java 8引入的异步编程工具
• 支持链式调用和组合多个异步任务
• 比Future更强大，支持回调、组合等

常用方法：

• supplyAsync()：异步执行有返回值的任务
• runAsync()：异步执行无返回值的任务
• thenApply()：任务完成后执行，有返回值
• thenAccept()：任务完成后执行，无返回值
• thenCompose()：组合两个CompletableFuture
• thenCombine()：合并两个CompletableFuture的结果
• allOf()：等待所有任务完成
• anyOf()：等待任意一个任务完成

示例：

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

// 异步执行
CompletableFuture<String> future = CompletableFuture.supplyAsync(() -> {
    return "Hello";
});

// 链式调用
future.thenApply(s -> s + " World")
      .thenAccept(System.out::println);

// 组合多个任务
CompletableFuture<String> f1 = CompletableFuture.supplyAsync(() -> "Hello");
CompletableFuture<String> f2 = CompletableFuture.supplyAsync(() -> "World");
CompletableFuture<String> combined = f1.thenCombine(f2, (a, b) -> a + " " + b);

1.1.3 String与Object类

基础问题

Q1: String、StringBuilder、StringBuffer的区别？

A:

String：

• 不可变类，每次操作都创建新对象
• 线程安全（因为不可变）
• 适合字符串常量或少量字符串操作

StringBuilder：

• 可变类，内部使用char数组
• 线程不安全，性能高
• 适合单线程环境下的字符串拼接

StringBuffer：

• 可变类，内部使用char数组
• 线程安全（synchronized），性能略低于StringBuilder
• 适合多线程环境下的字符串拼接

性能对比：

• 大量字符串拼接：StringBuilder > StringBuffer > String
• 少量字符串操作：差异不大

Q2: String的intern()方法？

A:

intern()作用：

• 如果字符串常量池中存在该字符串，返回常量池中的引用
• 如果不存在，将字符串添加到常量池并返回引用
• 可以节省内存，但需要权衡性能

示例：

1
2
3
4
5

String s1 = new String("abc");
String s2 = s1.intern();
String s3 = "abc";
System.out.println(s1 == s2); // false
System.out.println(s2 == s3); // true

使用场景：

• 大量重复字符串的场景
• 需要字符串比较的场景

Q3: Object类的equals()和hashCode()方法？

A:

equals()方法：

• 默认比较对象引用（==）
• 需要重写以实现值比较
• 重写equals()必须重写hashCode()

hashCode()方法：

• 返回对象的哈希码
• 相等的对象必须有相同的hashCode
• 不等的对象尽量有不同的hashCode

重写规则：

• 自反性：x.equals(x) == true
• 对称性：x.equals(y) == y.equals(x)
• 传递性：x.equals(y) && y.equals(z) => x.equals(z)
• 一致性：多次调用结果相同
• 非空性：x.equals(null) == false

示例：

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

@Override
public boolean equals(Object obj) {
    if (this == obj) return true;
    if (obj == null || getClass() != obj.getClass()) return false;
    Person person = (Person) obj;
    return Objects.equals(name, person.name) && age == person.age;
}

@Override
public int hashCode() {
    return Objects.hash(name, age);
}

一般问题

Q1: String为什么是不可变的？

A:

不可变的原因：

• String类被final修饰，不能被继承
• 内部char数组被final修饰
• 没有提供修改char数组的方法

不可变的优势：

• 线程安全：多线程环境下可以安全共享
• 缓存优化：可以缓存hashCode，提高性能
• 安全性：作为参数传递时不会被修改
• 字符串常量池：可以复用字符串，节省内存

不可变的缺点：

• 大量字符串拼接性能差
• 需要使用StringBuilder或StringBuffer

Q2: ==和equals()的区别？

A:

==操作符：

• 基本类型：比较值
• 引用类型：比较引用地址

equals()方法：

• Object类中默认使用==比较
• 可以重写实现值比较
• String类重写了equals()，比较字符串内容

示例：

1
2
3
4
5
6
7
8

String s1 = new String("abc");
String s2 = new String("abc");
System.out.println(s1 == s2);        // false，引用不同
System.out.println(s1.equals(s2));  // true，内容相同

String s3 = "abc";
String s4 = "abc";
System.out.println(s3 == s4);        // true，字符串常量池

困难问题

Q1: String的常量池机制？

A:

字符串常量池：

• JVM中专门存储字符串常量的区域
• 位于方法区（JDK1.7后移到堆）
• 可以复用字符串，节省内存

字符串创建方式：

1. 字面量：String s = "abc"，直接使用常量池
2. **new String()**：String s = new String("abc")，创建新对象
3. **intern()**：将字符串添加到常量池

内存优化：

• 相同字面量共享同一个对象
• 使用intern()可以复用字符串
• 但需要注意性能开销

Q2: 如何正确重写equals()和hashCode()？

A:

重写equals()的步骤：

1. 检查引用是否相同
2. 检查对象是否为null
3. 检查类型是否相同
4. 比较关键字段

重写hashCode()的原则：

• 使用相同的字段计算hashCode
• 使用Objects.hash()简化代码
• 确保相等的对象有相同的hashCode

完整示例：

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

public class Person {
    private String name;
    private int age;
    
    @Override
    public boolean equals(Object obj) {
        if (this == obj) return true;
        if (obj == null || getClass() != obj.getClass()) return false;
        Person person = (Person) obj;
        return age == person.age && Objects.equals(name, person.name);
    }
    
    @Override
    public int hashCode() {
        return Objects.hash(name, age);
    }
}

1.1.4 异常处理

基础问题

Q1: Java异常体系？

A:

Throwable：

• Error：系统错误，如OutOfMemoryError
• Exception：程序异常
  • RuntimeException：运行时异常，如NullPointerException
  • 检查异常：编译时检查，如IOException

异常分类：

• 检查异常：必须处理（try-catch或throws）
• 运行时异常：可以不处理
• 错误：系统级错误，通常无法恢复

Q2: try-catch-finally的执行顺序？

A:

执行顺序：

1. 执行try块
2. 如果发生异常，执行catch块
3. 无论是否异常，都执行finally块
4. 如果finally中有return，会覆盖try/catch中的return

示例：

1
2
3
4
5
6
7
8
9
10

try {
    // 可能抛出异常的代码
    return 1;
} catch (Exception e) {
    // 异常处理
    return 2;
} finally {
    // 清理资源
    return 3; // 最终返回3
}

Q3: throw和throws的区别？

A:

throw：

• 在方法内部抛出异常
• 抛出的是异常对象
• 可以抛出任何Throwable或其子类

throws：

• 在方法声明中声明可能抛出的异常
• 告诉调用者需要处理这些异常
• 可以声明多个异常

示例：

1
2
3
4
5

public void method() throws IOException {
    if (condition) {
        throw new IOException("错误信息");
    }
}

一般问题

Q1: 异常处理的最佳实践？

A:

实践原则：

1. 具体异常：捕获具体异常，避免捕获Exception
2. 不要忽略异常：至少记录日志
3. 资源管理：使用try-with-resources自动关闭资源
4. 异常转换：将底层异常转换为业务异常
5. 避免空的catch块：至少要记录日志

示例：

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

// 好的实践
try (FileInputStream fis = new FileInputStream("file.txt")) {
    // 使用资源
} catch (FileNotFoundException e) {
    logger.error("文件未找到", e);
    throw new BusinessException("文件不存在", e);
}

// 不好的实践
try {
    // 代码
} catch (Exception e) {
    // 空的catch块
}

Q2: 自定义异常？

A:

创建自定义异常：

• 继承Exception或RuntimeException
• 提供构造方法
• 可以添加自定义字段和方法

示例：

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

public class BusinessException extends RuntimeException {
    private String errorCode;
    
    public BusinessException(String message) {
        super(message);
    }
    
    public BusinessException(String errorCode, String message) {
        super(message);
        this.errorCode = errorCode;
    }
    
    public String getErrorCode() {
        return errorCode;
    }
}

1.1.5 Java 8+新特性

基础问题

Q1: Lambda表达式？

A:

Lambda定义：

• 函数式编程的语法糖
• 简化匿名内部类的写法
• 必须配合函数式接口使用

语法：

1
2
3
4
5
6

// 完整形式
(参数) -> { 方法体 }

// 简化形式
x -> x * 2
() -> System.out.println("Hello")

示例：

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

// 传统方式
List<String> list = Arrays.asList("a", "b", "c");
Collections.sort(list, new Comparator<String>() {
    @Override
    public int compare(String a, String b) {
        return a.compareTo(b);
    }
});

// Lambda方式
Collections.sort(list, (a, b) -> a.compareTo(b));
list.sort(String::compareTo); // 方法引用

Q2: Stream API的使用？

A:

Stream定义：

• 对集合进行函数式操作
• 支持链式调用
• 惰性求值，终端操作时才执行

常用操作：

• 中间操作：filter、map、sorted、distinct、limit
• 终端操作：forEach、collect、reduce、count、anyMatch

示例：

1
2
3
4
5

List<String> result = list.stream()
    .filter(s -> s.length() > 3)
    .map(String::toUpperCase)
    .sorted()
    .collect(Collectors.toList());

Q3: Optional的使用？

A:

Optional定义：

• 容器类，可能包含null值
• 避免NullPointerException
• 提供函数式编程风格

常用方法：

• of()：创建非空Optional
• ofNullable()：创建可能为空的Optional
• isPresent()：判断是否有值
• orElse()：有值返回，无值返回默认值
• orElseGet()：有值返回，无值执行Supplier
• map()：转换值
• flatMap()：扁平化转换

示例：

1
2
3

Optional<String> opt = Optional.ofNullable(str);
String result = opt.orElse("default");
opt.ifPresent(System.out::println);

一般问题

Q1: 函数式接口？

A:

函数式接口定义：

• 只有一个抽象方法的接口
• 可以用@FunctionalInterface注解标记
• 可以用Lambda表达式实现

常用函数式接口：

• Function<T, R>：接受T返回R
• Consumer<T>：接受T无返回值
• Supplier<T>：无参数返回T
• Predicate<T>：接受T返回boolean
• BiFunction<T, U, R>：接受T和U返回R

示例：

1
2
3
4

Function<String, Integer> func = s -> s.length();
Consumer<String> consumer = s -> System.out.println(s);
Supplier<String> supplier = () -> "Hello";
Predicate<String> predicate = s -> s.length() > 5;

Q2: 方法引用？

A:

方法引用类型：

• 静态方法引用：类名::静态方法
• 实例方法引用：对象::实例方法
• 类的实例方法引用：类名::实例方法
• 构造器引用：类名::new

示例：

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

// 静态方法引用
list.sort(String::compareTo);

// 实例方法引用
String str = "hello";
Supplier<Integer> len = str::length;

// 类的实例方法引用
Function<String, String> upper = String::toUpperCase;

// 构造器引用
Supplier<List<String>> listSupplier = ArrayList::new;

困难问题

Q1: Stream的并行流？

A:

并行流：

• 使用parallelStream()创建并行流
• 利用多核CPU提高性能
• 需要注意线程安全

使用场景：

• 数据量大
• 操作独立，无状态
• CPU密集型操作

注意事项：

• 并行流不保证顺序
• 需要线程安全的数据结构
• 小数据量可能性能更差（线程切换开销）

示例：

1
2
3
4

List<Integer> result = list.parallelStream()
    .filter(x -> x > 10)
    .map(x -> x * 2)
    .collect(Collectors.toList());

Q2: Java 8的时间API？

A:

新的时间API：

• LocalDate：日期（年月日）
• LocalTime：时间（时分秒）
• LocalDateTime：日期时间
• ZonedDateTime：带时区的日期时间
• Instant：时间戳
• Duration：时间间隔
• Period：日期间隔

优势：

• 不可变，线程安全
• API设计更清晰
• 支持时区处理

示例：

1
2
3
4

LocalDate date = LocalDate.now();
LocalDateTime dateTime = LocalDateTime.now();
Duration duration = Duration.between(start, end);
Period period = Period.between(startDate, endDate);

1.1.6 JVM内存模型与GC调优

基础问题

Q1: JVM内存结构？

A:

• 堆（Heap）：存放对象实例，分为新生代（Eden、Survivor0/1）和老年代
• 方法区（Method Area）：存储类信息、常量、静态变量
• 程序计数器（PC Register）：记录当前线程执行的字节码行号
• 虚拟机栈（VM Stack）：存储局部变量表、操作数栈、方法出口
• 本地方法栈（Native Method Stack）：为Native方法服务

Q2: 垃圾回收算法有哪些？

A:

• 标记-清除：标记需要回收的对象，统一清除；缺点：产生碎片
• 复制算法：将内存分为两块，每次使用一块，存活对象复制到另一块；适合新生代
• 标记-整理：标记后移动存活对象，避免碎片；适合老年代
• 分代收集：根据对象存活周期采用不同算法

Q3: 常见的垃圾回收器？

A:

• Serial/Serial Old：单线程，适合小应用
• ParNew：多线程版本的Serial，配合CMS使用
• Parallel Scavenge/Old：吞吐量优先，适合后台任务
• CMS：并发标记清除，低停顿，适合Web应用
• G1：分代收集，可预测停顿时间，适合大内存应用
• ZGC：超低延迟，适合超大堆内存

一般问题

Q1: 如何判断对象可以被回收？

A:

• 引用计数：每个对象有引用计数，为0时可回收；无法解决循环引用
• 可达性分析：从GC Roots开始，不可达的对象可回收
• GC Roots：虚拟机栈中的引用、方法区静态变量、方法区常量、本地方法栈引用

Q2: 如何排查内存溢出问题？

A:

1. 使用jmap生成堆转储文件：jmap -dump:format=b,file=heap.bin <pid>
2. 使用jstat查看GC情况：jstat -gcutil <pid> 1000
3. 使用MAT或VisualVM分析堆转储文件
4. 检查是否有内存泄漏（对象无法被GC回收）
5. 调整JVM参数：-Xmx、-Xms、-XX:NewRatio等

Q3: 新生代和老年代的比例？

A:

• 默认比例：新生代:老年代 = 1:2
• 新生代中Eden:Survivor0:Survivor1 = 8:1:1
• 可通过-XX:NewRatio调整比例
• 可通过-XX:SurvivorRatio调整Survivor比例

困难问题

Q1: G1垃圾回收器的工作原理？

A:

• 将堆内存划分为多个Region（1MB-32MB）
• 使用Remembered Set记录跨Region引用
• 并发标记阶段：标记存活对象
• 回收阶段：优先回收垃圾最多的Region
• 可预测停顿时间，适合大内存应用

Q2: 如何优化JVM参数？

A:

• 堆内存：-Xmx、-Xms设置为相同值，避免动态调整
• 新生代：根据对象生命周期调整-XX:NewRatio
• GC选择：根据应用特点选择G1、CMS等
• GC日志：开启-XX:+PrintGCDetails分析GC情况
• 内存泄漏：使用-XX:+HeapDumpOnOutOfMemoryError自动生成dump

Q3: 如何分析GC日志？

A:

• 关注Full GC频率和耗时
• 关注Young GC频率和耗时
• 分析GC前后内存变化
• 找出GC频繁的原因（内存分配过快、对象生命周期长等）
• 使用GCViewer等工具可视化分析

1.1.7 反射与注解

基础问题

Q1: 反射是什么？

A:

反射定义：

• 在运行时动态获取类的信息
• 可以创建对象、调用方法、访问字段
• 通过Class对象操作类

获取Class对象的方式：

1. Class.forName("类名")
2. 对象.getClass()
3. 类名.class

示例：

1
2
3
4

Class<?> clazz = Class.forName("com.example.Person");
Object obj = clazz.newInstance();
Method method = clazz.getMethod("getName");
String name = (String) method.invoke(obj);

Q2: 注解是什么？

A:

注解定义：

• 元数据，提供程序信息
• 不影响程序执行
• 可以通过反射读取

常用注解：

• @Override：重写方法
• @Deprecated：标记过时
• @SuppressWarnings：抑制警告
• @FunctionalInterface：函数式接口
• @Retention：注解保留策略
• @Target：注解作用目标

元注解：

• @Retention：SOURCE、CLASS、RUNTIME
• @Target：TYPE、METHOD、FIELD等
• @Documented：包含在JavaDoc中
• @Inherited：可以继承

Q3: 自定义注解？

A:

创建注解：

1
2
3
4
5
6

@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.METHOD)
public @interface MyAnnotation {
    String value() default "";
    int count() default 0;
}

使用注解：

1
2
3
4

@MyAnnotation(value = "test", count = 5)
public void method() {
    // 方法体
}

读取注解：

1
2
3

Method method = clazz.getMethod("method");
MyAnnotation annotation = method.getAnnotation(MyAnnotation.class);
String value = annotation.value();

一般问题

Q1: 反射的应用场景？

A:

应用场景：

• 框架开发：Spring的IoC、MyBatis的Mapper
• 动态代理：JDK动态代理、CGLIB
• 序列化：JSON序列化、XML解析
• 工具类：BeanUtils、ReflectionUtils

优缺点：

• 优点：灵活性高，可以实现动态功能
• 缺点：性能较低，代码可读性差，安全性问题

Q2: 注解的处理方式？

A:

处理方式：

1. 编译时处理：APT（Annotation Processing Tool）
2. 运行时处理：通过反射读取注解
3. 字节码处理：在字节码层面处理注解

示例：

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

// 运行时处理
@Retention(RetentionPolicy.RUNTIME)
public @interface MyAnnotation {
    String value();
}

// 读取注解
Class<?> clazz = MyClass.class;
if (clazz.isAnnotationPresent(MyAnnotation.class)) {
    MyAnnotation annotation = clazz.getAnnotation(MyAnnotation.class);
    String value = annotation.value();
}

困难问题

Q1: 反射的性能问题？

A:

性能问题：

• 反射调用比直接调用慢很多（约10-100倍）
• 原因：方法查找、参数检查、安全检查等

优化方法：

1. 缓存Class对象：避免重复获取
2. 缓存Method/Field：避免重复查找
3. 使用MethodHandle：JDK7+，性能更好
4. 避免频繁反射：在初始化时反射，运行时直接调用

示例：

1
2
3
4
5
6
7
8
9

// 缓存Method
private static final Method getNameMethod;
static {
    try {
        getNameMethod = Person.class.getMethod("getName");
    } catch (Exception e) {
        throw new RuntimeException(e);
    }
}

Q2: 动态代理的实现？

A:

JDK动态代理：

• 基于接口，使用Proxy.newProxyInstance
• 需要实现InvocationHandler
• 只能代理接口

CGLIB动态代理：

• 基于继承，使用Enhancer
• 需要实现MethodInterceptor
• 可以代理类

示例：

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

// JDK动态代理
InvocationHandler handler = (proxy, method, args) -> {
    // 前置处理
    Object result = method.invoke(target, args);
    // 后置处理
    return result;
};
Object proxy = Proxy.newProxyInstance(
    target.getClass().getClassLoader(),
    target.getClass().getInterfaces(),
    handler
);

// CGLIB动态代理
Enhancer enhancer = new Enhancer();
enhancer.setSuperclass(TargetClass.class);
enhancer.setCallback(new MethodInterceptor() {
    @Override
    public Object intercept(Object obj, Method method, Object[] args, MethodProxy proxy) {
        // 处理逻辑
        return proxy.invokeSuper(obj, args);
    }
});
TargetClass proxy = (TargetClass) enhancer.create();

1.1.8 IO流

基础问题

Q1: IO流的分类？

A:

按流向分类：

• 输入流：InputStream、Reader
• 输出流：OutputStream、Writer

按数据类型分类：

• 字节流：InputStream、OutputStream
• 字符流：Reader、Writer

常用流：

• FileInputStream/FileOutputStream：文件字节流
• FileReader/FileWriter：文件字符流
• BufferedInputStream/BufferedOutputStream：缓冲字节流
• BufferedReader/BufferedWriter：缓冲字符流
• ObjectInputStream/ObjectOutputStream：对象流

Q2: 字节流和字符流的区别？

A:

字节流：

• 以字节为单位读写
• 适合二进制文件（图片、视频等）
• InputStream/OutputStream

字符流：

• 以字符为单位读写
• 适合文本文件
• Reader/Writer
• 内部使用字节流+字符编码

选择原则：

• 文本文件：使用字符流
• 二进制文件：使用字节流
• 需要缓冲：使用Buffered系列

Q3: try-with-resources？

A:

try-with-resources：

• Java 7引入，自动关闭资源
• 资源必须实现AutoCloseable接口
• 比try-finally更简洁

示例：

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

// 传统方式
FileInputStream fis = null;
try {
    fis = new FileInputStream("file.txt");
    // 使用流
} finally {
    if (fis != null) {
        fis.close();
    }
}

// try-with-resources
try (FileInputStream fis = new FileInputStream("file.txt");
     BufferedInputStream bis = new BufferedInputStream(fis)) {
    // 使用流，自动关闭
}

一般问题

Q1: NIO是什么？

A:

NIO（New IO）：

• Java 4引入的非阻塞IO
• 核心组件：Channel、Buffer、Selector
• 支持非阻塞IO和选择器

NIO vs IO：

• IO：面向流，阻塞IO
• NIO：面向缓冲区，非阻塞IO，支持选择器

核心组件：

• Channel：通道，类似流但可以双向
• Buffer：缓冲区，数据容器
• Selector：选择器，多路复用

示例：

1
2
3
4

// NIO读取文件
FileChannel channel = FileChannel.open(Paths.get("file.txt"));
ByteBuffer buffer = ByteBuffer.allocate(1024);
int bytesRead = channel.read(buffer);

Q2: 序列化和反序列化？

A:

序列化：

• 将对象转换为字节流
• 实现Serializable接口
• 使用ObjectOutputStream

反序列化：

• 将字节流转换为对象
• 使用ObjectInputStream

注意事项：

• 需要serialVersionUID
• transient字段不序列化
• static字段不序列化
• 父类需要可序列化

示例：

1
2
3
4
5
6
7
8
9

// 序列化
ObjectOutputStream oos = new ObjectOutputStream(new FileOutputStream("obj.dat"));
oos.writeObject(obj);
oos.close();

// 反序列化
ObjectInputStream ois = new ObjectInputStream(new FileInputStream("obj.dat"));
Object obj = ois.readObject();
ois.close();

困难问题

Q1: 如何实现大文件的高效读写？

A:

优化方法：

1. 使用缓冲流：BufferedInputStream/BufferedOutputStream
2. 分块读取：不要一次性读取整个文件
3. 使用NIO：FileChannel + MappedByteBuffer（内存映射）
4. 多线程处理：分块并行处理

示例：

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

// 使用缓冲流
try (BufferedInputStream bis = new BufferedInputStream(
        new FileInputStream("large.txt"), 8192);
     BufferedOutputStream bos = new BufferedOutputStream(
        new FileOutputStream("output.txt"), 8192)) {
    byte[] buffer = new byte[8192];
    int len;
    while ((len = bis.read(buffer)) != -1) {
        bos.write(buffer, 0, len);
    }
}

// 使用NIO内存映射
FileChannel channel = FileChannel.open(Paths.get("large.txt"));
MappedByteBuffer buffer = channel.map(
    FileChannel.MapMode.READ_ONLY, 0, channel.size());

1.1.9 设计模式

基础问题

Q1: 设计模式的分类？

A:

• 创建型模式：单例、工厂、建造者、原型、抽象工厂
• 结构型模式：适配器、装饰器、代理、外观、桥接、组合、享元
• 行为型模式：策略、观察者、责任链、命令、状态、模板方法、迭代器、中介者、备忘录、访问者、解释器

Q2: 单例模式的实现方式？

A:

1. 饿汉式（线程安全）：

1
2
3
4
5
6
7

public class Singleton {
    private static final Singleton instance = new Singleton();
    private Singleton() {}
    public static Singleton getInstance() {
        return instance;
    }
}

2. 懒汉式（双重检查锁）：

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

public class Singleton {
    private static volatile Singleton instance;
    private Singleton() {}
    public static Singleton getInstance() {
        if (instance == null) {
            synchronized (Singleton.class) {
                if (instance == null) {
                    instance = new Singleton();
                }
            }
        }
        return instance;
    }
}

3. 静态内部类（推荐）：

1
2
3
4
5
6
7
8
9

public class Singleton {
    private Singleton() {}
    private static class Holder {
        private static final Singleton instance = new Singleton();
    }
    public static Singleton getInstance() {
        return Holder.instance;
    }
}

4. 枚举（推荐，防止反射和序列化破坏）：

1
2
3
4

public enum Singleton {
    INSTANCE;
    public void doSomething() {}
}

Q3: 工厂模式的使用场景？

A:

• 简单工厂：根据参数创建不同类型的对象
• 工厂方法：定义一个创建对象的接口，让子类决定实例化哪个类
• 抽象工厂：提供一个创建一系列相关或相互依赖对象的接口

示例（简单工厂）：

1
2
3
4
5
6
7
8
9
10

public class ProductFactory {
    public static Product createProduct(String type) {
        if ("A".equals(type)) {
            return new ProductA();
        } else if ("B".equals(type)) {
            return new ProductB();
        }
        return null;
    }
}

一般问题

Q1: 代理模式的实现方式？

A:

1. 静态代理：

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

interface Subject {
    void request();
}

class RealSubject implements Subject {
    public void request() {
        System.out.println("真实请求");
    }
}

class Proxy implements Subject {
    private RealSubject realSubject;
    public void request() {
        if (realSubject == null) {
            realSubject = new RealSubject();
        }
        System.out.println("代理前处理");
        realSubject.request();
        System.out.println("代理后处理");
    }
}

2. JDK动态代理：

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

interface Subject {
    void request();
}

class RealSubject implements Subject {
    public void request() {
        System.out.println("真实请求");
    }
}

class ProxyHandler implements InvocationHandler {
    private Object target;
    public ProxyHandler(Object target) {
        this.target = target;
    }
    public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
        System.out.println("代理前处理");
        Object result = method.invoke(target, args);
        System.out.println("代理后处理");
        return result;
    }
}

// 使用
Subject proxy = (Subject) Proxy.newProxyInstance(
    RealSubject.class.getClassLoader(),
    new Class[]{Subject.class},
    new ProxyHandler(new RealSubject())
);

3. CGLIB动态代理：

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

class RealSubject {
    public void request() {
        System.out.println("真实请求");
    }
}

class ProxyInterceptor implements MethodInterceptor {
    public Object intercept(Object obj, Method method, Object[] args, MethodProxy proxy) throws Throwable {
        System.out.println("代理前处理");
        Object result = proxy.invokeSuper(obj, args);
        System.out.println("代理后处理");
        return result;
    }
}

// 使用
Enhancer enhancer = new Enhancer();
enhancer.setSuperclass(RealSubject.class);
enhancer.setCallback(new ProxyInterceptor());
RealSubject proxy = (RealSubject) enhancer.create();

Q2: 观察者模式的实现？

A:

定义：定义对象间一对多的依赖关系，当一个对象状态改变时，所有依赖它的对象都会收到通知。

实现：

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

// 观察者接口
interface Observer {
    void update(String message);
}

// 被观察者
class Subject {
    private List<Observer> observers = new ArrayList<>();
    private String state;
    
    public void attach(Observer observer) {
        observers.add(observer);
    }
    
    public void detach(Observer observer) {
        observers.remove(observer);
    }
    
    public void setState(String state) {
        this.state = state;
        notifyObservers();
    }
    
    private void notifyObservers() {
        for (Observer observer : observers) {
            observer.update(state);
        }
    }
}

// 具体观察者
class ConcreteObserver implements Observer {
    private String name;
    public ConcreteObserver(String name) {
        this.name = name;
    }
    public void update(String message) {
        System.out.println(name + "收到消息: " + message);
    }
}

应用场景：

• Java中的事件监听机制
• Spring的事件发布机制
• MVC架构中的模型-视图关系

Q3: 策略模式的使用？

A:

定义：定义一系列算法，把它们封装起来，并且使它们可以互相替换。

实现：

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

// 策略接口
interface Strategy {
    int execute(int a, int b);
}

// 具体策略
class AddStrategy implements Strategy {
    public int execute(int a, int b) {
        return a + b;
    }
}

class MultiplyStrategy implements Strategy {
    public int execute(int a, int b) {
        return a * b;
    }
}

// 上下文
class Context {
    private Strategy strategy;
    public Context(Strategy strategy) {
        this.strategy = strategy;
    }
    public int executeStrategy(int a, int b) {
        return strategy.execute(a, b);
    }
}

// 使用
Context context = new Context(new AddStrategy());
int result = context.executeStrategy(5, 3); // 8

优势：

• 算法可以自由切换
• 避免多重if-else判断
• 扩展性好，易于添加新策略

Q4: 适配器模式的应用？

A:

定义：将一个类的接口转换成客户希望的另一个接口，使原本不兼容的类可以一起工作。

类适配器：

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

// 目标接口
interface Target {
    void request();
}

// 被适配的类
class Adaptee {
    public void specificRequest() {
        System.out.println("特殊请求");
    }
}

// 适配器
class Adapter extends Adaptee implements Target {
    public void request() {
        specificRequest();
    }
}

对象适配器：

1
2
3
4
5
6
7
8
9

class Adapter implements Target {
    private Adaptee adaptee;
    public Adapter(Adaptee adaptee) {
        this.adaptee = adaptee;
    }
    public void request() {
        adaptee.specificRequest();
    }
}

应用场景：

• Java中的InputStreamReader（字节流适配字符流）
• Spring MVC中的HandlerAdapter
• 第三方库接口适配

困难问题

Q1: 责任链模式的实现和应用？

A:

定义：将请求沿着处理者链传递，直到有处理者处理它。

实现：

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

// 处理者接口
abstract class Handler {
    protected Handler next;
    public void setNext(Handler next) {
        this.next = next;
    }
    public abstract void handleRequest(Request request);
}

// 具体处理者
class ConcreteHandler1 extends Handler {
    public void handleRequest(Request request) {
        if (request.getType() == RequestType.TYPE1) {
            System.out.println("Handler1处理请求");
        } else if (next != null) {
            next.handleRequest(request);
        }
    }
}

class ConcreteHandler2 extends Handler {
    public void handleRequest(Request request) {
        if (request.getType() == RequestType.TYPE2) {
            System.out.println("Handler2处理请求");
        } else if (next != null) {
            next.handleRequest(request);
        }
    }
}

应用场景：

• Java中的异常处理机制
• Servlet中的Filter链
• Spring Security的过滤器链
• 审批流程

Q2: 装饰器模式与代理模式的区别？

A:

装饰器模式：

• 目的：动态地给对象添加额外的职责
• 关注点：增强功能
• 关系：装饰器和被装饰对象实现同一接口
• 示例：Java IO流（BufferedReader装饰InputStreamReader）

代理模式：

• 目的：控制对对象的访问
• 关注点：访问控制
• 关系：代理和被代理对象实现同一接口
• 示例：Spring AOP、RPC框架

代码对比：

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

// 装饰器：增强功能
class Decorator implements Component {
    private Component component;
    public Decorator(Component component) {
        this.component = component;
    }
    public void operation() {
        // 增强前
        component.operation();
        // 增强后
    }
}

// 代理：控制访问
class Proxy implements Subject {
    private RealSubject realSubject;
    public void request() {
        // 访问控制
        if (checkAccess()) {
            realSubject.request();
        }
    }
}

Q3: 模板方法模式的应用？

A:

定义：定义一个操作中算法的骨架，而将一些步骤延迟到子类中。

实现：

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

abstract class AbstractClass {
    // 模板方法
    public final void templateMethod() {
        step1();
        step2();
        step3();
    }
    
    // 具体步骤
    protected void step1() {
        System.out.println("步骤1");
    }
    
    // 抽象方法，子类实现
    protected abstract void step2();
    
    // 钩子方法，子类可选重写
    protected void step3() {
        System.out.println("步骤3");
    }
}

class ConcreteClass extends AbstractClass {
    protected void step2() {
        System.out.println("具体步骤2");
    }
}

应用场景：

• Spring中的JdbcTemplate
• 框架中的钩子方法
• 算法骨架固定，部分步骤可变

Q4: 建造者模式的使用场景？

A:

定义：将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。

实现：

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

class Product {
    private String part1;
    private String part2;
    private String part3;
    
    // 私有构造函数
    private Product(Builder builder) {
        this.part1 = builder.part1;
        this.part2 = builder.part2;
        this.part3 = builder.part3;
    }
    
    // 建造者
    public static class Builder {
        private String part1;
        private String part2;
        private String part3;
        
        public Builder part1(String part1) {
            this.part1 = part1;
            return this;
        }
        
        public Builder part2(String part2) {
            this.part2 = part2;
            return this;
        }
        
        public Builder part3(String part3) {
            this.part3 = part3;
            return this;
        }
        
        public Product build() {
            return new Product(this);
        }
    }
}

// 使用
Product product = new Product.Builder()
    .part1("部件1")
    .part2("部件2")
    .part3("部件3")
    .build();

应用场景：

• 创建复杂对象，参数多且可选
• 需要保证对象创建过程的完整性
• 链式调用，代码可读性好
• 示例：StringBuilder、OkHttp的Request.Builder

Q5: 设计模式在实际项目中的应用？

A:

Spring框架中的应用：

• 单例模式：Bean默认单例
• 工厂模式：BeanFactory、ApplicationContext
• 代理模式：AOP动态代理
• 模板方法：JdbcTemplate、RestTemplate
• 观察者模式：事件发布机制
• 适配器模式：HandlerAdapter

JDK中的应用：

• 迭代器模式：Iterator接口
• 适配器模式：InputStreamReader
• 装饰器模式：IO流装饰器
• 观察者模式：Observer接口（已废弃，但思想保留）
• 单例模式：Runtime类

实际开发建议：

• 不要过度设计，优先考虑简单方案
• 理解模式本质，而非死记硬背
• 结合业务场景选择合适的模式
• 注意模式之间的组合使用

1.2 Spring框架

基础问题

Q1: Spring IoC和AOP是什么？

A:

• IoC（控制反转）：对象的创建和依赖关系由Spring容器管理
• AOP（面向切面编程）：在不修改原有代码的情况下增强功能
• IoC通过依赖注入实现，AOP通过动态代理实现

Q2: Spring Bean的作用域？

A:

• singleton：单例（默认）
• prototype：每次创建新实例
• request：每个HTTP请求一个实例
• session：每个HTTP会话一个实例
• globalSession：全局HTTP会话

Q3: @Autowired和@Resource的区别？

A:

• @Autowired：Spring注解，按类型注入，可配合@Qualifier按名称
• @Resource：JSR-250注解，按名称注入，找不到再按类型
• @Autowired支持required=false，@Resource不支持

一般问题

Q1: Spring IoC和AOP的原理？

A:

• IoC（控制反转）：通过反射和工厂模式创建对象，管理对象生命周期和依赖关系
• AOP（面向切面编程）：基于动态代理（JDK动态代理或CGLIB）实现横切关注点
• JDK动态代理：基于接口，使用InvocationHandler
• CGLIB代理：基于继承，通过ASM字节码技术生成子类

Q2: Spring Boot自动配置原理？

A:

• 通过@EnableAutoConfiguration注解启用
• 扫描META-INF/spring.factories文件中的自动配置类
• 使用@ConditionalOnXxx条件注解判断是否生效
• 通过starter机制简化依赖管理

Q3: Spring事务传播机制？

A:

• REQUIRED（默认）：存在事务则加入，不存在则创建
• REQUIRES_NEW：总是创建新事务
• SUPPORTS：存在则加入，不存在则以非事务方式执行
• NOT_SUPPORTED：以非事务方式执行
• MANDATORY：必须在事务中执行，否则抛异常
• NEVER：不能在事务中执行
• NESTED：嵌套事务

困难问题

Q1: Spring如何解决循环依赖？

A:

• 三级缓存：
  • singletonObjects：完整Bean
  • earlySingletonObjects：早期Bean（未完成属性注入）
  • singletonFactories：Bean工厂
• 解决过程：A依赖B，B依赖A时，先创建A的早期对象放入缓存，再创建B，B注入A的早期对象，最后完成A的属性注入

Q2: Spring AOP的实现原理？

A:

• JDK动态代理：基于接口，使用Proxy.newProxyInstance创建代理对象
• CGLIB代理：基于继承，生成目标类的子类作为代理类
• 选择规则：有接口用JDK，无接口用CGLIB
• 织入时机：编译期、类加载期、运行期（Spring使用运行期）

Q3: Spring事务失效的场景？

A:

• 方法非public
• 方法被final或static修饰
• 同一类内部方法调用（未通过代理）
• 异常被捕获未抛出
• 数据库不支持事务
• 事务传播行为设置不当

1.3 MyBatis

基础问题

Q1: MyBatis的缓存机制？

A:

• 一级缓存：SqlSession级别，默认开启，同一SqlSession中相同查询会缓存
• 二级缓存：Mapper级别，需要手动开启，跨SqlSession共享
• 缓存更新策略：insert/update/delete会清空相关缓存

Q2: MyBatis如何防止SQL注入？

A:

• 使用#{}占位符，MyBatis会进行预编译，参数作为字符串处理
• 避免使用${}，会直接拼接SQL，存在注入风险
• 对用户输入进行校验和转义

一般问题

Q1: MyBatis的执行流程？

A:

1. 加载配置文件，创建SqlSessionFactory
2. 创建SqlSession
3. 通过SqlSession获取Mapper代理对象
4. 执行SQL（解析SQL、设置参数、执行、结果映射）
5. 提交事务，关闭SqlSession

Q2: #{}和${}的区别？

A:

• #{}：预编译，参数作为字符串处理，防止SQL注入
• ${}：字符串替换，直接拼接SQL，存在SQL注入风险
• #{}适用于参数值，${}适用于表名、列名等动态部分

困难问题

Q1: MyBatis的插件机制？

A:

• 基于拦截器（Interceptor）实现
• 可以拦截Executor、StatementHandler、ParameterHandler、ResultSetHandler
• 实现Interceptor接口，使用@Intercepts注解指定拦截的方法
• 常见应用：分页插件、性能监控插件

Q2: MyBatis如何实现延迟加载？

A:

• 通过动态代理实现
• 配置lazyLoadingEnabled=true开启延迟加载
• 关联对象只有在真正访问时才会加载
• 可以设置aggressiveLazyLoading控制加载行为

二、大数据技术栈

2.1 Flink

基础问题

Q1: Flink的核心概念？

A:

• 流批一体：同一套API支持流处理和批处理
• 时间语义：
  • Event Time：事件产生的时间
  • Processing Time：处理时间
  • Ingestion Time：数据进入Flink的时间
• 状态（State）：KeyedState和OperatorState，支持状态后端（Memory、RocksDB）
• 检查点（Checkpoint）：基于Chandy-Lamport算法实现分布式快照
• 水印（Watermark）：用于处理乱序数据，表示事件时间的进度

Q2: Flink与Spark Streaming的区别？

A:

• Flink是真正的流处理，延迟更低（毫秒级）
• Spark Streaming是微批处理，延迟较高（秒级）
• Flink支持事件时间，Spark Streaming主要支持处理时间
• Flink的状态管理更完善

Q3: Flink的并行度如何设置？

A:

• 可以在代码中设置：env.setParallelism(4)
• 可以在算子级别设置：dataStream.map(...).setParallelism(2)
• 可以在配置文件中设置全局并行度
• 并行度应该根据数据量和资源情况设置

一般问题

Q1: Flink如何保证Exactly-Once语义？

A:

1. Checkpoint机制：定期创建全局一致性快照
2. 两阶段提交：配合支持事务的外部系统（如Kafka）
3. 状态后端：RocksDB支持大状态持久化
4. 端到端一致性：Source和Sink都支持事务

Q2: Flink如何处理数据倾斜？

A:

1. KeyBy前加随机前缀：打散热点key
2. 使用LocalKeyBy：在数据量大的key上先做本地聚合
3. 调整并行度：增加下游算子并行度
4. 使用Rebalance：强制数据重新分布
5. 自定义分区器：根据业务特点自定义分区策略

Q3: Flink与Kafka的集成？

A:

• FlinkKafkaConsumer：支持从Kafka消费数据
• FlinkKafkaProducer：支持写入Kafka
• 支持Kafka事务，保证Exactly-Once
• 支持从指定offset开始消费
• 支持动态发现新分区

困难问题

Q1: Flink的Checkpoint机制原理？

A:

• 基于Chandy-Lamport分布式快照算法
• JobManager触发Checkpoint，向所有Source发送barrier
• Source收到barrier后做快照，然后向下游发送barrier
• 算子收到所有输入的barrier后做快照
• 所有算子完成快照后，Checkpoint完成
• 失败时从最近的Checkpoint恢复

Q2: Flink的背压（Backpressure）机制？

A:

• 当下游处理速度慢于上游时，上游会减慢发送速度
• 通过TCP流控机制实现
• 可以通过监控反压指标定位性能瓶颈
• 解决方案：增加并行度、优化算子逻辑、调整缓冲区大小

Q3: Flink的状态后端选择？

A:

• MemoryStateBackend：状态存储在内存，适合小状态、测试
• FsStateBackend：状态存储在文件系统，适合中等状态
• RocksDBStateBackend：状态存储在RocksDB，适合大状态、生产环境
• 选择原则：根据状态大小和性能要求选择

2.2 Spark

基础问题

Q1: Spark的核心概念（RDD、DAG、Stage）？

A:

• RDD（弹性分布式数据集）：不可变的分布式数据集合，支持容错
• DAG（有向无环图）：表示RDD之间的依赖关系
• Stage（阶段）：根据shuffle依赖划分，分为ShuffleMapStage和ResultStage
• Task：Stage中的最小执行单元

Q2: RDD的五大特性？

A:

1. 分区列表：RDD由多个分区组成
2. 计算函数：每个分区都有计算函数
3. 依赖关系：RDD之间存在依赖关系
4. 分区器：可选，用于shuffle
5. 优先位置：可选，用于数据本地性

Q3: Spark的宽依赖和窄依赖？

A:

• 窄依赖：父RDD的每个分区最多被一个子RDD分区使用（map、filter）
• 宽依赖：父RDD的每个分区被多个子RDD分区使用（groupBy、join）
• 宽依赖会触发shuffle，是Stage划分的依据

一般问题

Q1: Spark的Shuffle过程？

A:

1. Map端：
   • 数据写入环形缓冲区（默认100MB）
   • 达到阈值后spill到磁盘，按key排序
   • 合并多个spill文件
   • 生成索引文件，记录每个分区的数据位置
2. Reduce端：
   • 通过网络拉取Map端的数据
   • 合并排序后交给reduce处理

Q2: Spark Shuffle优化？

A:

1. 调整shuffle分区数：spark.sql.shuffle.partitions
2. 使用Kryo序列化：减少序列化开销
3. 启用map端聚合：spark.sql.mapSideJoin
4. 调整缓冲区大小：spark.shuffle.file.buffer
5. 使用Sort Shuffle：默认算法，性能更好

Q3: Spark SQL优化？

A:

1. 使用列式存储：Parquet、ORC格式
2. 分区裁剪：只读取需要的分区
3. 谓词下推：在数据源层面过滤数据
4. 列裁剪：只读取需要的列
5. 广播Join：小表广播到所有节点
6. 调整并行度：根据数据量设置合理的分区数

困难问题

Q1: Spark的内存管理？

A:

• 堆内存划分：
  • Storage Memory：缓存RDD和广播变量
  • Execution Memory：shuffle、join等操作
  • User Memory：用户代码和数据结构
  • Reserved Memory：系统保留
• 动态占用：Execution和Storage可以互相借用
• 溢出机制：内存不足时spill到磁盘

Q2: 如何通过Spark UI定位性能瓶颈？

A:

1. 查看Stage执行时间：找出耗时最长的Stage
2. 查看Task分布：检查是否有数据倾斜（某些Task执行时间过长）
3. 查看Shuffle读写：检查Shuffle数据量是否过大
4. 查看GC时间：检查是否有GC问题
5. 查看数据倾斜：通过Task执行时间分布判断

Q3: Spark的容错机制？

A:

• RDD容错：通过Lineage（血缘）重建丢失的分区
• Checkpoint：将RDD持久化到可靠存储，避免长血缘链
• Shuffle容错：通过MapOutputTracker记录shuffle输出位置
• Executor容错：失败时重新调度Task到其他Executor

2.3 Kafka

基础问题

Q1: Kafka的架构和核心概念？

A:

• Producer：消息生产者
• Broker：Kafka服务器节点
• Topic：消息主题，逻辑概念
• Partition：分区，物理存储单元
• Consumer：消息消费者
• Consumer Group：消费者组，实现负载均衡
• Replica：副本，保证高可用
• Leader/Follower：主副本和从副本

Q2: Kafka为什么这么快？

A:

• 顺序写入：磁盘顺序写入性能接近内存随机写入
• 零拷贝：使用sendfile系统调用，减少数据拷贝
• 批量发送：批量发送消息，减少网络开销
• 分区并行：多个分区并行处理
• 页缓存：利用操作系统页缓存

Q3: Kafka的消费方式（Pull vs Push）？

A:

• Kafka采用Pull模式：Consumer主动拉取消息
• 优点：
  • Consumer可以控制消费速率
  • 可以批量消费，提高吞吐量
  • 简化Broker设计
• Push模式的问题：
  • 难以适应不同消费速率的Consumer
  • 可能导致Consumer过载

一般问题

Q1: Kafka如何保证消息不丢失？

A:

1. Producer端：
   • 设置acks=all（或-1），等待所有ISR副本确认
   • 设置retries重试机制
   • 使用同步发送或回调确认
2. Broker端：
   • 设置replication.factor>=2，多副本
   • 设置min.insync.replicas>=2，保证ISR中有足够副本
   • 设置unclean.leader.election.enable=false，禁止非ISR副本成为Leader
3. Consumer端：
   • 关闭自动提交：enable.auto.commit=false
   • 处理完消息后再手动提交offset

Q2: Kafka如何保证消息顺序性？

A:

• 单分区内有序：Kafka保证单个分区内消息有序
• Producer端：使用相同的key，消息会发送到同一分区
• Consumer端：单线程消费或使用单线程处理同一key的消息
• 注意：如果开启重试，可能破坏顺序性，需要设置max.in.flight.requests.per.connection=1

Q3: Kafka的副本机制？

A:

• 每个Partition有多个副本（replica）
• 一个副本作为Leader，负责读写
• 其他副本作为Follower，从Leader同步数据
• ISR（In-Sync Replicas）：与Leader同步的副本集合
• Leader选举：当Leader失效时，从ISR中选择新Leader

困难问题

Q1: Kafka的Consumer Rebalance？

A:

• 触发条件：Consumer加入/退出、Partition数量变化
• 过程：
  1. 所有Consumer停止消费
  2. 重新分配Partition
  3. 恢复消费
• 问题：Rebalance期间无法消费，影响可用性
• 优化：使用增量Rebalance（StickyAssignor）

Q2: Kafka的幂等性？

A:

• Producer端幂等：设置enable.idempotence=true
• 通过Producer ID（PID）和序列号（Sequence Number）实现
• 保证单会话、单分区内的幂等性
• 配合事务可以实现跨分区、跨会话的幂等性

Q3: Kafka的事务机制？

A:

• 支持跨分区、跨会话的事务
• 使用事务协调器（TransactionCoordinator）管理事务
• Producer发送事务消息，提交或回滚事务
• Consumer可以读取已提交的事务消息
• 配合幂等性保证Exactly-Once语义

Q4: Kafka vs RocketMQ的对比？

A:

架构对比：

性能对比：

存储机制对比：

Kafka：

• 基于日志文件（Log Segment）
• 顺序写入，性能高
• 使用零拷贝技术
• 消息按时间或大小切分Segment

RocketMQ：

• CommitLog：所有消息顺序写入
• ConsumeQueue：按Topic和Queue索引，提高查询性能
• 支持消息刷盘策略（同步/异步）
• 支持消息压缩

使用场景对比：

Kafka适合：

• 大数据流处理：日志收集、实时数据管道
• 事件溯源：事件驱动架构
• 流式计算：配合Flink、Spark Streaming
• 高吞吐场景：需要极高吞吐量
• 多语言生态：需要多语言客户端支持

RocketMQ适合：

• 业务消息：订单、支付等业务消息
• 事务消息：需要强一致性的事务场景
• 顺序消息：需要保证消息顺序
• 延迟消息：需要延迟投递
• 消息过滤：需要复杂的消息过滤
• Java生态：主要使用Java技术栈

运维对比：

选择建议：

选择Kafka：

• 需要极高的吞吐量
• 大数据流处理场景
• 需要多语言客户端支持
• 事件驱动架构
• 配合流式计算框架（Flink、Spark）

选择RocketMQ：

• 业务消息场景
• 需要事务消息
• 需要延迟消息
• 需要消息过滤
• 主要使用Java技术栈
• 需要更好的中文支持和文档

总结：

• Kafka：更适合大数据、流处理场景，追求极致性能
• RocketMQ：更适合业务消息场景，功能更丰富，更适合Java生态

Q5: Kafka vs RabbitMQ的对比？

A:

架构对比：

性能对比：

存储机制对比：

Kafka：

• 基于日志文件（Log Segment）
• 顺序写入磁盘，性能高
• 使用零拷贝技术
• 消息持久化到磁盘，支持海量存储
• 消息按时间或大小切分Segment

RabbitMQ：

• 内存 + 磁盘混合存储
• 消息可以存储在内存或磁盘
• 支持消息持久化（durable）
• 内存模式性能高，但受内存限制
• 磁盘模式性能较低，但更可靠

消息路由机制对比：

Kafka：

• 基于Partition路由
• Producer指定key，相同key路由到同一Partition
• 简单直接，适合流式处理

RabbitMQ：

• 基于Exchange和Routing Key
• Exchange类型：
  • Direct：精确匹配Routing Key
  • Topic：模式匹配Routing Key
  • Fanout：广播到所有队列
  • Headers：基于消息头匹配
• 灵活的路由机制，适合复杂业务场景

可靠性对比：

使用场景对比：

Kafka适合：

• 大数据流处理：日志收集、实时数据管道
• 事件溯源：事件驱动架构
• 流式计算：配合Flink、Spark Streaming
• 高吞吐场景：需要极高吞吐量
• 消息堆积：需要支持海量消息堆积
• 数据管道：作为数据管道连接不同系统

RabbitMQ适合：

• 业务消息：订单、支付等业务消息
• 复杂路由：需要灵活的消息路由
• 低延迟：需要微秒级延迟（内存模式）
• 任务队列：异步任务处理
• RPC调用：请求/响应模式
• 消息确认：需要精确的消息确认机制

运维对比：

协议支持对比：

Kafka：

• 自定义协议
• 支持多种语言客户端
• 协议简单高效

RabbitMQ：

• AMQP：标准消息队列协议
• MQTT：物联网协议（通过插件）
• STOMP：简单文本协议（通过插件）
• HTTP：REST API
• 协议丰富，兼容性好

选择建议：

选择Kafka：

• 需要极高的吞吐量（百万级TPS）
• 大数据流处理场景
• 需要支持海量消息堆积
• 事件驱动架构
• 配合流式计算框架（Flink、Spark）
• 作为数据管道

选择RabbitMQ：

• 业务消息场景
• 需要灵活的消息路由
• 需要低延迟（微秒级）
• 需要复杂的消息确认机制
• 需要标准协议支持（AMQP）
• 任务队列、异步处理
• 需要请求/响应模式（RPC）

总结：

• Kafka：更适合大数据、流处理场景，追求极致吞吐量和消息堆积能力
• RabbitMQ：更适合业务消息场景，提供灵活的路由和丰富的协议支持，适合复杂的业务逻辑

三种消息中间件对比总结：

2.4 Hadoop生态

2.4.1 HDFS

基础问题

Q1: HDFS的架构？

A:

• NameNode：管理文件系统命名空间，存储元数据
• DataNode：存储实际数据块
• Secondary NameNode：辅助NameNode，定期合并fsimage和edits
• Block：默认128MB，是数据存储和复制的单位

Q2: HDFS的读写流程？

A:

• 写流程：
  1. Client向NameNode请求写入文件
  2. NameNode返回DataNode列表
  3. Client将数据写入第一个DataNode
  4. DataNode之间流水线复制数据
  5. 所有副本写入成功后返回确认
• 读流程：
  1. Client向NameNode请求读取文件
  2. NameNode返回DataNode列表和Block位置
  3. Client从最近的DataNode读取数据

一般问题

Q1: HDFS的高可用（HA）？

A:

• 使用ZooKeeper实现NameNode的HA
• Active NameNode和Standby NameNode
• 通过JournalNode同步元数据变更
• 自动故障转移，保证服务可用性

Q2: HDFS的Block大小为什么是128MB？

A:

• 减少NameNode的元数据量
• 减少网络传输开销
• 平衡寻址时间和传输时间
• 适合MapReduce等大数据处理框架

困难问题

Q1: HDFS的元数据管理？

A:

• fsimage：文件系统镜像，存储完整的命名空间
• edits：编辑日志，记录文件系统的变更
• Secondary NameNode定期合并fsimage和edits
• NameNode启动时加载fsimage并重放edits

Q2: HDFS的副本放置策略？

A:

• 第一个副本：放在Client所在的节点
• 第二个副本：放在不同机架的节点
• 第三个副本：放在第二个副本相同机架的不同节点
• 目的：提高可靠性和读取性能

2.4.2 YARN

基础问题

Q1: YARN的架构和工作流程？

A:

• ResourceManager：资源管理器，包含Scheduler和ApplicationsManager
• NodeManager：节点管理器，管理单个节点的资源
• ApplicationMaster：应用主控程序，管理应用生命周期
• Container：资源抽象，封装CPU、内存等资源

工作流程：

1. Client提交应用
2. RM分配Container启动AM
3. AM向RM申请资源
4. RM分配Container给AM
5. AM与NM通信启动Task
6. Task运行并汇报状态
7. 应用完成后AM注销

一般问题

Q1: YARN的调度算法？

A:

• FIFO：先进先出，简单但不适合多用户
• Capacity Scheduler：容量调度器，按队列分配资源
• Fair Scheduler：公平调度器，公平分配资源
• DRF（Dominant Resource Fairness）：主资源公平调度

困难问题

Q1: YARN的资源分配机制？

A:

• 使用Container抽象资源（CPU、内存）
• Scheduler根据策略分配Container
• 支持资源抢占（Preemption）
• 支持资源预留（Reservation）

2.4.3 Hive

基础问题

Q1: Hive的执行流程？

A:

1. Parser：将HQL转换为AST（抽象语法树）
2. Semantic Analyzer：语义分析，转换为查询块
3. Logic Plan Generator：生成逻辑执行计划
4. Logic Optimizer：逻辑优化（谓词下推、分区裁剪等）
5. Physical Plan Generator：生成物理执行计划（MapReduce Jobs）
6. Physical Optimizer：物理优化（选择Join策略等）

Q2: Hive的数据倾斜问题？

A:

• 原因：key分布不均匀、业务数据特性、建表考虑不周
• 解决方案：
  1. 参数调节：hive.map.aggr=true、hive.groupby.skewindata=true
  2. MapJoin：小表join大表使用MapJoin
  3. 空值处理：给空值赋予随机key
  4. 不同数据类型关联：统一数据类型
  5. 特殊情况单独处理：倾斜数据单独处理再union

一般问题

Q1: Hive的优化手段？

A:

1. 合理使用分区和分桶
2. 使用列式存储：ORC、Parquet格式
3. Map端聚合：hive.map.aggr=true
4. 小文件合并：减少小文件数量
5. 合理设置Map和Reduce数量
6. 使用压缩：减少I/O开销
7. Join优化：小表放左边，使用MapJoin

Q2: Hive的窗口函数？

A:

• 聚合型：SUM、AVG、COUNT等配合OVER使用
• 分析型：ROW_NUMBER、RANK、DENSE_RANK
• 取值型：LAG、LEAD、FIRST_VALUE、LAST_VALUE
• 窗口大小：ROWS BETWEEN … AND …

困难问题

Q1: Hive的Join优化策略？

A:

• MapJoin：小表加载到内存，避免shuffle
• Bucket Join：两个表都分桶，相同bucket的join
• SMB Join：Sort Merge Bucket Join，两个表都分桶且排序
• Skew Join：处理数据倾斜的join

Q2: Hive的元数据管理？

A:

• 元数据存储在关系型数据库（MySQL、PostgreSQL等）
• 包括表结构、分区信息、存储位置等
• Metastore服务管理元数据访问
• 支持多版本Metastore

三、OLAP与数据存储

3.0 LSM Tree存储引擎基础

基础问题

Q1: LSM Tree的基本原理？

A:

LSM Tree定义：

• Log-Structured Merge Tree，日志结构合并树
• 由O’Neil等人在1996年提出
• 专为写密集型场景设计的高性能存储结构

核心思想：

• 写入优化：数据先写入内存（MemTable），顺序写入磁盘
• 批量合并：后台线程定期合并多个数据文件
• 分层存储：数据按时间顺序分层存储，新数据在高层，老数据在低层

基本结构：

• MemTable：内存中的有序数据结构（如跳表、B+树）
• Immutable MemTable：MemTable写满后变为只读，等待刷盘
• SSTable（Sorted String Table）：磁盘上的有序数据文件
• 多个Level：SSTable按大小和时间分层存储

Q2: LSM Tree的写入流程？

A:

写入过程：

1. 数据写入MemTable（内存，有序结构）
2. 写入WAL（Write-Ahead Log）保证持久化
3. MemTable写满后，转换为Immutable MemTable
4. 后台线程将Immutable MemTable刷盘为SSTable（Level 0）
5. 后台线程定期合并Level i的SSTable到Level i+1

写入优势：

• 顺序写入：MemTable刷盘是顺序写入，性能高
• 无随机写：避免B+树的随机写放大问题
• 高吞吐：适合写密集型场景

Q3: LSM Tree的读取流程？

A:

读取过程：

1. 先查询MemTable（最新数据）
2. 如果未找到，查询Immutable MemTable
3. 如果仍未找到，从Level 0开始逐层查询SSTable
4. 使用Bloom Filter快速过滤不存在的key
5. 合并多个SSTable的查询结果

读取特点：

• 可能需要查询多个SSTable：读放大问题
• 使用Bloom Filter：快速判断key是否存在
• 范围查询：需要合并多个SSTable的结果

一般问题

Q1: LSM Tree的Compaction机制？

A:

Compaction目的：

• 合并多个SSTable，减少文件数量
• 删除过期和重复的数据
• 优化数据布局，提高查询性能

Compaction策略：

1. Size-Tiered Compaction（STCS）：

• 相同大小的SSTable合并
• 合并后大小翻倍
• 适合写密集型场景
• 问题：空间放大，需要更多存储空间

2. Leveled Compaction（LCS）：

• 每层SSTable大小相近
• Level i的SSTable合并到Level i+1
• 每层大小限制：Level i+1是Level i的10倍
• 优势：空间放大小，查询性能好
• 问题：写放大较大

3. Time-Windowed Compaction（TWCS）：

• 按时间窗口合并
• 适合时序数据
• 可以设置TTL自动删除过期数据

Compaction触发条件：

• SSTable数量达到阈值
• 数据量达到阈值
• 手动触发

Q2: LSM Tree的优缺点？

A:

优点：

• 写入性能高：顺序写入，无随机写
• 高吞吐：适合写密集型场景
• 压缩率高：SSTable可以压缩存储
• 支持范围查询：数据有序存储

缺点：

• 读放大：可能需要查询多个SSTable
• 写放大：Compaction会重写数据
• 空间放大：同一数据可能存在于多个SSTable
• 删除延迟：删除操作需要Compaction才能真正删除

Q3: LSM Tree的优化技术？

A:

1. Bloom Filter：

• 快速判断key是否存在
• 减少不必要的SSTable查询
• 内存占用小，误判率低

2. 索引优化：

• SSTable内使用稀疏索引
• 快速定位数据在SSTable中的位置

3. 缓存策略：

• Block Cache：缓存SSTable的数据块
• Table Cache：缓存SSTable的元数据

4. Compaction优化：

• 选择合适的Compaction策略
• 控制Compaction频率
• 使用多线程并行Compaction

困难问题

Q1: LSM Tree的写放大和读放大？

A:

写放大（Write Amplification）：

• 定义：实际写入磁盘的数据量 / 用户写入的数据量
• 原因：
  • Compaction会重写数据
  • 数据可能被写入多个Level
• Leveled Compaction：写放大较大（约10-50倍）
• Size-Tiered Compaction：写放大较小（约2-5倍）
• 优化：
  • 选择合适的Compaction策略
  • 增大SSTable大小
  • 减少Compaction频率

读放大（Read Amplification）：

• 定义：实际读取的数据量 / 用户需要的数据量
• 原因：
  • 需要查询多个SSTable
  • 需要读取整个SSTable的块
• 优化：
  • 使用Bloom Filter快速过滤
  • 优化索引结构
  • 使用缓存减少I/O

Q2: LSM Tree的Compaction策略选择？

A:

选择原则：

• 写密集型：选择Size-Tiered Compaction，写放大小
• 读密集型：选择Leveled Compaction，读放大小
• 时序数据：选择Time-Windowed Compaction
• 混合场景：根据实际负载调整

Leveled Compaction特点：

• 每层大小固定，数据分布均匀
• 查询时最多查询一层
• 空间放大小（约1.1倍）
• 写放大大（约10-50倍）

Size-Tiered Compaction特点：

• 相同大小的SSTable合并
• 空间放大大（约2倍）
• 写放大小（约2-5倍）
• 适合写密集型场景

Q3: LSM Tree vs B+ Tree的对比？

A:

B+ Tree特点：

• 写入：随机写入，需要维护树结构
• 读取：O(log n)时间复杂度，查询路径固定
• 适用场景：读多写少，需要事务支持

LSM Tree特点：

• 写入：顺序写入，高吞吐
• 读取：可能需要查询多个SSTable
• 适用场景：写多读少，高吞吐写入

对比：

3.1 Doris/StarRocks

基础问题

Q1: Doris的核心特性？

A:

• MPP架构：大规模并行处理
• 列式存储：高效压缩和查询
• 向量化执行：SIMD指令加速
• 物化视图：预计算加速查询
• 实时更新：支持流式导入和更新
• MySQL协议兼容：易于使用

Q2: Doris的表模型？

A:

• Aggregate模型：预聚合，适合汇总类查询
• Unique模型：主键唯一，支持更新
• Duplicate模型：明细数据，适合分析查询
• 选择原则：根据查询场景选择合适模型

Q3: Doris/StarRocks的列式存储结构？

A:

列式存储原理：

• 数据按列存储，而非按行存储
• 同一列的数据在物理上连续存储
• 查询时只读取需要的列，减少I/O

存储文件结构：

• 数据文件：按列存储，每列一个文件
• 索引文件：前缀索引、Bloom Filter、ZoneMap等
• 元数据文件：表结构、分区信息、统计信息

列式存储优势：

• 压缩率高：同类型数据连续存储，压缩效果好
• 查询高效：只读取需要的列，减少I/O
• 向量化执行：SIMD指令并行处理列数据
• 适合分析：OLAP场景下优势明显

一般问题

Q1: Doris的物化视图？

A:

• 预计算的聚合结果，加速查询
• 自动路由：查询自动匹配物化视图
• 支持多物化视图：一个表可以有多个物化视图
• 增量更新：只更新变更数据

Q2: Doris的索引优化？

A:

• 前缀索引：基于前36字节构建
• Bloom Filter：快速判断数据是否存在
• ZoneMap：Min/Max索引，用于范围查询
• 倒排索引：用于文本搜索

Q3: Doris/StarRocks的数据文件组织？

A:

Rowset（行集）：

• 数据导入时生成Rowset，包含多个Segment
• Rowset是不可变的，写入后不能修改
• 多个Rowset可以合并（Compaction）

Segment结构：

• 列数据文件：每列一个文件，列式存储
• 索引文件：
  • Short Key Index：前缀索引，基于前36字节
  • Bloom Filter：快速判断数据是否存在
  • ZoneMap：Min/Max索引，用于范围查询
• Footer：元数据信息，包括索引位置、统计信息等

数据压缩：

• 支持多种压缩算法：LZ4、ZSTD、ZLIB等
• 列式存储压缩率高
• 可以设置压缩级别平衡压缩率和性能

分区和分桶：

• 分区（Partition）：按时间或其他维度分区，减少扫描范围
• 分桶（Bucket）：数据分桶存储，提高并行度
• 分区和分桶的组合使用，优化查询性能

困难问题

Q1: Doris的查询优化？

A:

• 谓词下推：在存储层过滤数据
• 列裁剪：只读取需要的列
• 分区裁剪：只扫描相关分区
• Join优化：Broadcast Join、Shuffle Join、Colocate Join
• 物化视图路由：自动选择最优物化视图

Q2: Doris的导入性能优化？

A:

• 使用Stream Load批量导入
• 调整batch size和并发度
• 使用列式存储格式（Parquet、ORC）
• 合理设置分区和分桶
• 避免小文件问题

Q3: Doris/StarRocks的Compaction机制？

A:

Compaction目的：

• 合并多个Rowset，减少文件数量
• 删除标记为删除的数据
• 优化数据布局，提高查询性能

Compaction策略：

• Base Compaction：合并Base数据和增量数据
• Cumulative Compaction：合并增量数据
• Full Compaction：全量合并，优化数据分布

Compaction触发条件：

• Rowset数量达到阈值
• 数据量达到阈值
• 手动触发

Compaction优化：

• 选择合适的Compaction策略
• 控制Compaction频率，避免影响查询
• 监控Compaction进度和资源使用

3.2 ClickHouse

基础问题

Q1: ClickHouse的核心特性？

A:

• 列式存储：高效压缩，只读取需要的列
• 向量化执行：SIMD指令并行处理
• MPP架构：分布式并行查询
• 数据压缩：多种压缩算法
• 实时写入：支持高并发写入
• 丰富的数据类型和函数

Q2: ClickHouse的表引擎？

A:

• MergeTree：最强大的引擎，支持分区、索引、副本
• ReplacingMergeTree：去重，适合upsert场景
• SummingMergeTree：预聚合，自动求和
• AggregatingMergeTree：预聚合，支持多种聚合函数
• CollapsingMergeTree：支持删除和更新
• Distributed：分布式表，不存储数据

Q3: ClickHouse的存储组织结构？

A:

分区目录结构：

• 目录命名：PartitionId_MinBlockNum_MaxBlockNum_Level
• PartitionID：分区ID，如20210301
• MinBlockNum/MaxBlockNum：分区块编号，合并时更新
• Level：合并层级，合并次数越多层级越高

数据文件结构：

• primary.idx：主键索引文件，稀疏索引，每8192行一个索引项
• [Column].bin：列数据文件，使用LZ4压缩
• [Column].mrk2：标记文件，记录bin文件中数据的偏移信息
• minmax_[Column].idx：Min/Max索引，记录分区字段的最小最大值
• partition.dat：分区文件，保存分区表达式生成的值
• columns.txt：列信息文件
• count.txt：计数文件，记录数据行数
• checksums.txt：校验文件，校验文件完整性

索引查找过程：

1. 通过primary.idx定位到可能包含数据的索引粒度
2. 通过.mrk2文件找到对应的数据块在.bin文件中的位置
3. 读取.bin文件中的数据块
4. 解压数据块，查找具体数据

一般问题

Q1: ClickHouse的索引机制？

A:

• 主键索引：稀疏索引，每8192行一个索引项
• 二级索引（跳数索引）：
  • minmax：记录Min/Max值
  • set：记录去重值
  • ngrambf_v1：布隆过滤器
• 分区索引：基于分区键的Min/Max索引

Q2: ClickHouse vs Doris的对比？

A:

• ClickHouse优势：
  • 单表查询性能更好
  • 导入速度更快
  • 功能更丰富（更多表引擎、函数）
  • 多租户管理更完善
• Doris优势：
  • 使用更简单（SQL标准支持更好）
  • Join性能更好（多表查询）
  • 运维更简单（扩缩容、故障恢复）
  • 点查能力更强
  • 对数据湖支持更好

Q3: ClickHouse的列式存储实现？

A:

列式存储原理：

• 每列数据单独存储在一个文件中
• 同一列的数据在物理上连续
• 查询时只读取需要的列文件

数据压缩：

• 默认使用LZ4压缩
• 支持多种压缩算法：ZSTD、ZLIB、Brotli等
• 列式存储压缩率高（同类型数据连续）

标记文件（.mrk2）作用：

• 建立primary.idx和.bin文件之间的映射
• 包含三个信息：
  • Offset in compressed file：压缩数据块在bin文件中的偏移量
  • Offset in decompressed block：数据在解压块中的偏移量
  • Rows count：行数，通常等于index_granularity

数据文件（.bin）结构：

• Checksum（16字节）：数据校验
• Compression algorithm（1字节）：压缩算法编号
• Compressed size（4字节）：压缩后大小
• Decompressed size（4字节）：解压后大小
• Compressed data：压缩数据

困难问题

Q1: ClickHouse的MergeTree合并机制？

A:

• 后台线程定期合并小的数据块
• 合并时按主键排序，去重（ReplacingMergeTree）
• 合并策略：根据数据块大小和数量决定
• 可以通过OPTIMIZE手动触发合并

Q2: ClickHouse的分布式查询？

A:

• 使用Distributed表引擎
• 查询自动分发到各个分片
• 结果自动聚合
• 支持本地表和分布式表

Q3: ClickHouse的Distributed表引擎？

A:

Distributed表定义：

• 分布式表是逻辑表，本身不存储数据
• 是本地表的访问代理，类似分库中间件
• 通过Distributed表可以访问多个数据分片

创建分布式表：

1
2
3
4
5
6

CREATE TABLE distributed_table ON CLUSTER 'cluster_name'
(
    id UInt32,
    name String,
    date Date
) ENGINE = Distributed(cluster_name, database_name, local_table_name, sharding_key)

参数说明：

• cluster_name：集群名称
• database_name：数据库名
• local_table_name：本地表名
• sharding_key：分片键（可选），用于数据分片

工作原理：

1. 写入时：根据sharding_key将数据分发到对应的分片
2. 查询时：自动分发查询到各个分片，然后聚合结果
3. 支持本地优先：可以设置prefer_localhost_replica优先查询本地副本

Q4: ClickHouse的ReplicatedMergeTree副本机制？

A:

ReplicatedMergeTree：

• 支持数据副本的表引擎
• 副本之间通过ZooKeeper实现数据一致性
• 提供高可用性和数据冗余

创建副本表：

1
2
3
4
5
6
7
8

CREATE TABLE replicated_table ON CLUSTER 'cluster_name'
(
    id UInt32,
    name String,
    date Date
) ENGINE = ReplicatedMergeTree('/clickhouse/tables/{shard}/table_name', '{replica}')
PARTITION BY date
ORDER BY id

参数说明：

• 第一个参数：ZooKeeper路径，{shard}会被替换为分片ID
• 第二个参数：副本标识，{replica}会被替换为副本名称

副本同步机制：

• 通过ZooKeeper协调副本之间的数据同步
• 写入操作会同步到所有副本
• 合并操作由主副本执行，其他副本复制
• 支持自动故障恢复

ZooKeeper的作用：

• 存储元数据（表结构、分区信息等）
• 协调副本之间的操作
• 实现分布式锁
• 监控副本状态

Q5: ClickHouse的ON CLUSTER语法？

A:

ON CLUSTER作用：

• 在集群的所有节点上执行DDL操作
• 简化集群管理，无需在每个节点单独执行
• SELECT语句也可以使用ON CLUSTER达到分布式查询的效果

支持的DDL操作：

• CREATE TABLE：创建表
• DROP TABLE：删除表
• ALTER TABLE：修改表结构
• RENAME TABLE：重命名表
• TRUNCATE TABLE：清空表

DDL示例：

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

-- 创建分布式表
CREATE TABLE test_table ON CLUSTER 'my_cluster'
(
    id UInt32,
    name String
) ENGINE = MergeTree()
ORDER BY id;

-- 创建副本表
CREATE TABLE replicated_table ON CLUSTER 'my_cluster'
(
    id UInt32,
    name String
) ENGINE = ReplicatedMergeTree('/clickhouse/tables/{shard}/replicated_table', '{replica}')
ORDER BY id;

-- 删除表
DROP TABLE test_table ON CLUSTER 'my_cluster';

-- 修改表结构
ALTER TABLE test_table ON CLUSTER 'my_cluster' ADD COLUMN age UInt8;

SELECT … ON CLUSTER：

• SELECT语句也可以使用ON CLUSTER在集群所有节点上执行
• 相当于查询分布式表，但不需要创建Distributed表引擎
• 查询会自动分发到各个分片，结果自动聚合

SELECT示例：

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

-- 在集群所有节点上查询本地表
SELECT * FROM local_table ON CLUSTER 'my_cluster' WHERE id = 1;

-- 聚合查询
SELECT 
    date,
    count(*) as cnt
FROM local_table ON CLUSTER 'my_cluster'
WHERE date >= '2024-01-01'
GROUP BY date
ORDER BY date;

-- 与分布式表查询效果相同，但不需要创建Distributed表
-- 等价于：
SELECT * FROM distributed_table WHERE id = 1;

ON CLUSTER的优势：

• 灵活性：不需要创建Distributed表，直接查询本地表
• 简化管理：避免维护分布式表定义
• 动态查询：可以临时查询任意本地表

注意事项：

• 需要配置集群信息（在config.xml或metrika.xml中）
• 确保所有节点都能访问ZooKeeper（如果使用副本）
• DDL操作会在所有节点上执行，需要等待完成
• SELECT … ON CLUSTER要求所有节点都有相同的表结构
• 查询性能与使用Distributed表类似

Q6: ClickHouse集群的数据分片策略？

A:

分片键（Sharding Key）：

• 在创建Distributed表时指定
• 用于决定数据写入哪个分片
• 可以使用hash函数、取模等方式

分片策略：

1. 随机分片：

   • 不指定sharding_key
   • 数据随机分发到各个分片
   • 适合数据均匀分布的场景

2. Hash分片：

   • 使用sharding_key = hash(id)
   • 相同key的数据写入同一分片
   • 适合需要按key聚合的场景

3. 取模分片：

   • 使用sharding_key = id % shard_count
   • 简单直接，但扩展性差

分片选择原则：

• 数据均匀分布：避免数据倾斜
• 查询本地化：尽量让查询在本地完成
• 扩展性：支持动态添加分片

示例：

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

-- 使用hash分片
CREATE TABLE distributed_table ON CLUSTER 'cluster_name'
(
    id UInt32,
    name String
) ENGINE = Distributed(cluster_name, database_name, local_table, intHash32(id))

-- 使用随机分片
CREATE TABLE distributed_table ON CLUSTER 'cluster_name'
(
    id UInt32,
    name String
) ENGINE = Distributed(cluster_name, database_name, local_table, rand())

Q7: ClickHouse MergeTree的合并策略详解？

A:

Tiered合并策略：

• 相同大小的分区目录合并
• 合并后大小翻倍
• 类似LSM Tree的Size-Tiered Compaction
• 适合写密集型场景
• 问题：空间放大，需要更多存储空间

合并触发条件：

• 分区目录数量达到阈值（默认10个）
• 分区目录大小达到阈值
• 手动触发：OPTIMIZE TABLE

合并过程：

1. 选择多个小的分区目录
2. 按主键排序合并数据
3. 生成新的分区目录，Level+1
4. 删除旧的分区目录

优化：

• 控制合并频率，避免影响写入
• 监控合并进度
• 合理设置分区策略，减少合并压力
• 使用max_bytes_to_merge_at_max_space_in_pool控制合并大小

Q8: ClickHouse集群的配置？

A:

集群配置方式：

• 在config.xml或metrika.xml中配置
• 支持多个集群配置

配置示例（metrika.xml）：

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

<yandex>
    <clickhouse_remote_servers>
        <my_cluster>
            <shard>
                <replica>
                    <host>node1</host>
                    <port>9000</port>
                </replica>
                <replica>
                    <host>node2</host>
                    <port>9000</port>
                </replica>
            </shard>
            <shard>
                <replica>
                    <host>node3</host>
                    <port>9000</port>
                </replica>
                <replica>
                    <host>node4</host>
                    <port>9000</port>
                </replica>
            </shard>
        </my_cluster>
    </clickhouse_remote_servers>
</yandex>

配置说明：

• <shard>：定义一个分片
• <replica>：定义分片的副本
• 每个分片可以有多个副本
• 副本之间通过ZooKeeper同步

ZooKeeper配置：

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

<zookeeper>
    <node>
        <host>zk1</host>
        <port>2181</port>
    </node>
    <node>
        <host>zk2</host>
        <port>2181</port>
    </node>
    <node>
        <host>zk3</host>
        <port>2181</port>
    </node>
</zookeeper>

Q9: ClickHouse集群的查询优化？

A:

查询分发策略：

• 查询自动分发到各个分片
• 每个分片并行执行查询
• 结果自动聚合返回

本地优先查询：

• 设置prefer_localhost_replica=1
• 优先查询本地副本，减少网络开销
• 适合副本查询场景

查询优化技巧：

1. 使用本地表：

   • 如果知道数据在哪个分片，直接查询本地表
   • 避免分布式表的查询开销

2. 使用SELECT … ON CLUSTER：

   • 不需要创建Distributed表，直接查询本地表
   • 查询会自动分发到所有节点并聚合结果
   • 适合临时查询或不需要长期维护分布式表的场景

3. 合理使用分片键：

   • 查询条件包含分片键，可以只查询对应分片
   • 减少查询范围

4. 避免跨分片JOIN：

   • 尽量在同一个分片内JOIN
   • 跨分片JOIN性能较差

5. 使用物化视图：

   • 在本地表上创建物化视图
   • 减少跨分片查询

示例：

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

-- 方式1：查询分布式表（需要先创建Distributed表）
SELECT * FROM distributed_table WHERE id = 1;

-- 方式2：使用SELECT ... ON CLUSTER（不需要创建Distributed表）
SELECT * FROM local_table ON CLUSTER 'my_cluster' WHERE id = 1;

-- 方式3：查询本地表（只查询当前节点）
SELECT * FROM local_table WHERE id = 1;

-- 设置本地优先
SET prefer_localhost_replica = 1;
SELECT * FROM distributed_table WHERE id = 1;

-- SELECT ... ON CLUSTER聚合查询
SELECT 
    date,
    count(*) as cnt,
    sum(amount) as total
FROM local_table ON CLUSTER 'my_cluster'
WHERE date >= '2024-01-01'
GROUP BY date
ORDER BY date;

SELECT … ON CLUSTER vs Distributed表：