一、前言：数据架构的演进之路

你可能遇到过这些场景：

本文将回答的核心问题：

如何设计一个既能支持离线分析，又能支持实时查询的数据架构？

二、传统批处理架构的困境

2.1 经典批处理架构

2.2 批处理的痛点

三、Lambda 架构：双轨并行

3.1 Lambda 架构全景

3.2 三层架构详解

3.3 Lambda 架构实现示例

代码示例：查询合并逻辑

def get_user_stats(user_id, date):
    """
    Lambda架构查询示例
    合并批处理结果和实时结果
    """
    # 1. 从批处理视图获取截止昨天的统计
    batch_result = hive_client.query(f"""
        SELECT total_orders, total_amount
        FROM user_stats_batch
        WHERE user_id = '{user_id}' AND date = '{yesterday}'
    """)
    
    # 2. 从实时视图获取今天的增量
    realtime_result = redis_client.hgetall(f"user_stats_rt:{user_id}:{today}")
    
    # 3. 合并结果
    total_orders = batch_result['total_orders'] + int(realtime_result.get('orders', 0))
    total_amount = batch_result['total_amount'] + float(realtime_result.get('amount', 0))
    
    return {
        'user_id': user_id,
        'total_orders': total_orders,
        'total_amount': total_amount,
        'data_freshness': 'realtime'
    }

3.4 Lambda 架构的问题

痛点案例：

// ========== 批处理代码 (Spark) ==========
val dailyStats = orders
    .filter(col("date") === "2024-01-15")
    .groupBy("user_id")
    .agg(
        count("order_id").as("order_count"),
        sum("amount").as("total_amount")
    )

// ========== 实时代码 (Flink) ==========
DataStream<UserStats> realtimeStats = orders
    .keyBy(Order::getUserId)
    .window(TumblingEventTimeWindows.of(Time.days(1)))
    .aggregate(new OrderAggregator());

// 两套代码逻辑相同，但框架不同，语法不同
// 改一个逻辑，两边都要改，还要保证结果一致
// 🤯 维护噩梦

四、Kappa 架构：一切皆流

4.1 Kappa 架构全景

4.2 Kappa 核心理念

Jay Kreps 的洞见：

"为什么要维护两套系统？如果流处理足够强大，我们只需要一套系统。"

4.3 Kappa 架构实现

4.4 重处理机制

Kappa 重处理的关键：

# Kafka 配置：保留足够长的历史数据
log.retention.hours=168  # 保留7天
log.retention.bytes=-1   # 不限制大小

# 或者更长
log.retention.hours=720  # 保留30天

4.5 Kappa 的局限性

五、Lambda vs Kappa：深度对比

5.1 架构对比图

5.2 维度对比表

5.3 场景选择

六、实战：架构选型案例

6.1 案例一：电商实时大屏

需求：

• 实时 GMV、订单数、UV
• 数据延迟 < 5秒
• 支持小时/天/周对比

理由：

• 实时性要求高
• 计算逻辑相对简单（聚合）
• 数据时间跨度短

6.2 案例二：用户行为分析平台

需求：

• 用户漏斗分析
• 留存分析（7日/30日）
• 用户路径分析
• 支持历史回溯

理由：

• 需要历史数据分析
• 计算逻辑复杂（路径分析、漏斗）
• 批处理更擅长这类分析

6.3 案例三：实时风控系统

需求：

• 毫秒级响应
• 实时规则匹配
• 特征实时计算

理由：

• 极致实时性
• 流处理天然适合
• CEP 模式匹配

七、现代演进：实时湖仓

7.1 架构融合趋势

7.2 实时湖仓架构

7.3 流批一体：超越 Lambda 和 Kappa

Flink 流批一体示例：

-- 同一份 SQL，既能流处理也能批处理
-- Flink 1.14+ 支持

-- 创建 Kafka 源表（流）
CREATE TABLE orders_kafka (
    order_id BIGINT,
    user_id BIGINT,
    amount DECIMAL(10,2),
    order_time TIMESTAMP(3),
    WATERMARK FOR order_time AS order_time - INTERVAL '5' SECOND
) WITH (
    'connector' = 'kafka',
    'topic' = 'orders',
    'properties.bootstrap.servers' = 'kafka:9092',
    'format' = 'json'
);

-- 创建 Hudi 表（湖仓）
CREATE TABLE orders_hudi (
    order_id BIGINT,
    user_id BIGINT,
    amount DECIMAL(10,2),
    order_time TIMESTAMP(3),
    PRIMARY KEY (order_id) NOT ENFORCED
) WITH (
    'connector' = 'hudi',
    'path' = 's3://bucket/orders',
    'table.type' = 'MERGE_ON_READ'
);

-- 流模式：实时写入
SET 'execution.runtime-mode' = 'streaming';
INSERT INTO orders_hudi SELECT * FROM orders_kafka;

-- 批模式：全量重算
SET 'execution.runtime-mode' = 'batch';
INSERT OVERWRITE orders_hudi 
SELECT * FROM orders_kafka 
WHERE order_time >= '2024-01-01';

八、架构选型决策框架

8.1 决策矩阵

8.2 最终决策流程

九、总结

9.1 三种架构定位

9.2 核心要点

9.3 一句话总结

Lambda：稳妥之选，批处理兜底，适合复杂场景

Kappa：极简之选，一套系统搞定，适合实时场景

湖仓一体：未来之选，流批融合，正在成为新标准