Spark/Hive/ClickHouse 大数据技术栈：从离线批处理到实时分析的选型与工程实践

Spark/Hive/ClickHouse 大数据技术栈：从离线批处理到实时分析的选型与工程实践

一、大数据分析的"三座大山"：慢、贵、乱

当数据量从百万行跨越到十亿行，传统单机分析工具开始力不从心。pandas 读取 10GB 的 CSV 文件直接 OOM，SQL 查询在千万行表上执行超过 30 分钟，实时看板的数据延迟从分钟级退化到小时级。更深层的问题是技术栈混乱------离线分析用 Hive，实时查询用 ClickHouse，数据同步用 Spark，三套系统各说各话，数据口径对不上，运维成本翻倍。

大数据技术栈的选型不是"哪个快选哪个"------Spark、Hive、ClickHouse 各有明确的能力边界和适用场景。选错技术栈的代价远大于"慢一点"：把实时查询需求放到 Hive 上跑，用户等 30 分钟才出结果；把离线批处理任务塞进 ClickHouse，集群资源被占满导致在线查询超时。理解每种计算引擎的底层执行模型，才能做出正确的架构决策。

二、三大引擎的底层执行模型

2.1 执行模型对比

graph TB subgraph "Hive 执行模型" HSQL[HiveQL] -->|编译| HPlan[执行计划] HPlan -->|生成| HMR[MapReduce/Tez 任务] HMR -->|中间结果| HDisk[磁盘落盘] HDisk -->|下一阶段| HMR2[MapReduce/Tez] end subgraph "Spark 执行模型" SSQL[SparkSQL] -->|Catalyst 优化| SPlan[逻辑计划] SPlan -->|物理优化| SExec[物理计划] SExec -->|DAG调度| STask[Task 集合] STask -->|内存迭代| SMem[内存缓存] SMem -->|下一阶段| STask2[Task 集合] end subgraph "ClickHouse 执行模型" CSQL[SQL] -->|解析| CPlan[查询计划] CPlan -->|向量化执行| CPipe[Pipeline] CPipe -->|SIMD 指令| CData[列式数据块] CData -->|流式处理| CResult[结果集] end

Hive：将 SQL 编译为 MapReduce 或 Tez 任务的 DAG。每个阶段之间的中间结果必须落盘（写入 HDFS），阶段间的数据传输通过磁盘 I/O 完成。这种设计保证了容错性------任何阶段失败都可以从磁盘重新读取中间结果重试。但代价是极高的延迟：一个简单的 GROUP BY 查询，即使数据量不大，也需要经历"Map → 写磁盘 → Reduce"的完整流程，启动开销至少 10 秒。

Spark：基于内存的 DAG 执行引擎。SparkSQL 通过 Catalyst 优化器对逻辑计划进行 RBO（基于规则）和 CBO（基于代价）优化，生成物理执行计划。关键区别在于：Spark 的 Shuffle 阶段优先将中间结果缓存在内存中（可配置落盘），避免了 Hive 的磁盘 I/O 瓶颈。对于多阶段迭代计算（如机器学习训练），Spark 的内存缓存机制可将性能提升 10-100 倍。

ClickHouse：面向 OLAP 场景的列式存储引擎，采用向量化执行模型。数据按列存储在 MergeTree 引擎中，查询时只读取需要的列，跳过无关数据。执行层使用 SIMD 指令对列数据做批量处理，单核每秒可处理数亿行数据。但 ClickHouse 不支持事务、不支持高并发更新，JOIN 能力有限------它为聚合查询而生，不是通用数据库。

2.2 存储模型差异

特性	Hive (HDFS)	Spark (Parquet/ORC)	ClickHouse (MergeTree)
存储格式	行式（Text/SequenceFile）或列式（ORC/Parquet）	列式（Parquet/ORC）	列式（自定义压缩）
数据更新	不支持（需重写分区）	不支持（需重写文件）	支持（MergeTree 异步合并）
索引	无（分区裁剪）	无（分区裁剪 + 文件统计）	主键索引 + 跳数索引
压缩率	中等（ORC 约 70%）	中等（Parquet 约 65%）	高（LZ4/ZSTD 约 80%）

三、生产级大数据分析方案实现

3.1 Spark 离线 ETL 管道

"""
Spark 离线 ETL 管道：从 ODS 到 DWS 的分层加工
核心设计：分区裁剪 + 动态分区覆写 + 数据质量校验
"""
from pyspark.sql import SparkSession, DataFrame
from pyspark.sql import functions as F
from pyspark.sql.types import StructType, StructField, StringType, DoubleType, IntegerType
import logging

logger = logging.getLogger(__name__)


class SparkETLPipeline:
    """Spark 离线 ETL 管道"""

    def __init__(self, spark: SparkSession, source_db: str, target_db: str):
        self.spark = spark
        self.source_db = source_db
        self.target_db = target_db

    def run_daily_etl(self, dt: str) -> dict[str, int]:
        """
        执行每日 ETL 任务
        dt: 业务日期，格式 YYYY-MM-DD
        返回各层级处理的记录数
        """
        stats = {}

        # 第一层：ODS → DWD（明细数据清洗）
        dwd_count = self._ods_to_dwd(dt)
        stats["dwd"] = dwd_count

        # 第二层：DWD → DWS（轻度汇总）
        dws_count = self._dwd_to_dws(dt)
        stats["dws"] = dws_count

        # 第三层：数据质量校验
        quality_report = self._quality_check(dt)
        stats["quality"] = quality_report

        return stats

    def _ods_to_dwd(self, dt: str) -> int:
        """ODS → DWD：数据清洗与标准化"""
        # 分区裁剪：只读取当天分区，避免全表扫描
        ods_df = (
            self.spark.table(f"{self.source_db}.ods_order")
            .filter(F.col("dt") == dt)
        )

        # 数据清洗：去重、空值处理、格式标准化
        dwd_df = (
            ods_df
            # 按订单号去重，保留最新记录
            .dropDuplicates(["order_id"])
            # 过滤无效订单
            .filter(
                F.col("order_amount") > 0
                & F.col("user_id").isNotNull()
            )
            # 标准化字段格式
            .withColumn(
                "order_amount",
                F.round(F.col("order_amount"), 2)
            )
            .withColumn(
                "pay_channel",
                F.upper(F.trim(F.col("pay_channel")))
            )
        )

        # 动态分区覆写：只覆盖当天分区，不影响历史数据
        (
            dwd_df.write
            .mode("overwrite")
            .partitionBy("dt")
            .saveAsTable(f"{self.target_db}.dwd_order_detail")
        )

        return dwd_df.count()

    def _dwd_to_dws(self, dt: str) -> int:
        """DWD → DWS：按维度轻度汇总"""
        dwd_df = (
            self.spark.table(f"{self.target_db}.dwd_order_detail")
            .filter(F.col("dt") == dt)
        )

        # 按渠道和品类维度汇总
        dws_df = (
            dwd_df
            .groupBy("dt", "channel", "category")
            .agg(
                F.count("order_id").alias("order_count"),
                F.sum("order_amount").alias("gmv"),
                F.countDistinct("user_id").alias("user_count"),
                F.avg("order_amount").alias("avg_order_amount"),
            )
        )

        (
            dws_df.write
            .mode("overwrite")
            .partitionBy("dt")
            .saveAsTable(f"{self.target_db}.dws_channel_category_daily")
        )

        return dws_df.count()

    def _quality_check(self, dt: str) -> dict:
        """数据质量校验：行数波动、空值率、数值范围"""
        dwd_df = (
            self.spark.table(f"{self.target_db}.dwd_order_detail")
            .filter(F.col("dt") == dt)
        )

        total = dwd_df.count()
        null_user = dwd_df.filter(F.col("user_id").isNull()).count()
        amount_outlier = dwd_df.filter(F.col("order_amount") > 100000).count()

        report = {
            "total_rows": total,
            "null_user_rate": round(null_user / max(total, 1), 4),
            "amount_outlier_count": amount_outlier,
        }

        # 行数波动超过50%时告警
        if total < 1000:
            logger.warning(f"日期 {dt} DWD 行数异常偏低: {total}")

        return report

3.2 ClickHouse 实时查询方案

-- ClickHouse 建表：实时分析场景的 MergeTree 引擎设计
-- 核心设计：主键索引 + 分区 + 跳数索引，平衡查询性能与写入吞吐

CREATE TABLE IF NOT EXISTS analytics.event_stream
(
    event_id       UUID DEFAULT generateUUIDv4(),
    event_time     DateTime64(3),       -- 毫秒精度事件时间
    event_date     Date MATERIALIZED toDate(event_time),  -- 物化列，用于分区
    user_id        UInt64,
    event_type     LowCardinality(String),  -- 低基数枚举，压缩率极高
    page_url       String,
    referrer       String,
    device_type    LowCardinality(String),
    duration_ms    UInt32 DEFAULT 0,
    payload        String DEFAULT ''        -- JSON 格式扩展字段
)
ENGINE = MergeTree()
PARTITION BY toYYYYMM(event_date)          -- 按月分区，查询时分区裁剪
ORDER BY (event_date, event_type, user_id) -- 主键排序，决定查询加速维度
TTL event_date + INTERVAL 6 MONTH          -- 自动过期，控制存储成本
SETTINGS
    index_granularity = 8192,              -- 索引粒度，默认值适合大多数场景
    min_bytes_for_wide_part = '10M';       -- 超过10MB使用宽格式存储，提升压缩率

-- 跳数索引：加速特定条件的过滤查询
ALTER TABLE analytics.event_stream
    ADD INDEX idx_duration_minmax duration_ms TYPE minmax GRANULARITY 4;

ALTER TABLE analytics.event_stream
    ADD INDEX idx_payload_token payload TYPE tokenbf_v1(10240, 3, 0) GRANULARITY 4;

-- 典型查询：按事件类型统计，利用主键索引加速
SELECT
    event_type,
    count() AS event_count,
    countDistinct(user_id) AS uv,
    avg(duration_ms) AS avg_duration,
    quantile(0.95)(duration_ms) AS p95_duration
FROM analytics.event_stream
WHERE event_date BETWEEN '2026-05-01' AND '2026-05-31'
    AND event_type IN ('page_view', 'click', 'scroll')
GROUP BY event_type
ORDER BY event_count DESC;

四、技术栈选型的 Trade-offs 分析

场景匹配矩阵：

场景	推荐引擎	原因
T+1 离线报表	Hive/Spark	容错性强，资源利用率高，延迟可接受
复杂 ETL 管道	Spark	内存迭代计算，多阶段 DAG 高效
实时看板查询	ClickHouse	向量化执行，毫秒级聚合响应
机器学习特征工程	Spark	MLlib 生态 + 内存缓存
日志全文检索	不推荐 ClickHouse	字符串匹配性能差，应选 Elasticsearch

关键边界条件：

• ClickHouse 的 JOIN 性能是公认的短板。当关联表超过千万行时，JOIN 查询可能退化到分钟级。解决方案是"大表宽表化"------在 ETL 阶段提前完成 JOIN，将结果写入 ClickHouse 的宽表中，查询时只做单表聚合
• Spark 的内存消耗是隐形成本。一个处理 1TB 数据的 Spark 任务，配置不当可能需要 500GB+ 的集群内存。Executor 内存配置需要根据数据量和 Shuffle 量精确计算，而非简单设置 spark.executor.memory=8g
• Hive on Tez 比 Hive on MapReduce 快 3-5 倍，但 Tez 的容器复用机制在集群负载高时可能导致资源死锁。生产环境需要配置 Tez Session 的超时回收策略

数据一致性风险：

Lambda 架构下，同一份数据同时流经批处理层（Spark）和速度层（ClickHouse），两条链路的数据口径可能不一致------批处理用全量重算，速度层用增量更新，窗口对齐的时机差异导致结果偏差。解决路径是向 Kappa 架构演进，统一用流处理引擎（如 Flink）完成实时和离线计算，但这对团队的流计算能力要求更高。

五、总结

大数据技术栈的选型没有"万能方案"，核心是匹配场景。离线批处理选 Spark，利用内存迭代和 Catalyst 优化器处理复杂 ETL；实时查询选 ClickHouse，利用向量化执行和列式存储实现毫秒级聚合。避免用一种引擎打天下------Spark 做实时查询延迟太高，ClickHouse 做复杂 ETL 灵活性不足。

落地建议：先明确业务场景的延迟要求和数据量级，再选择引擎。对于中小规模（日增 < 1 亿行），ClickHouse 单集群即可覆盖大部分分析需求；对于大规模（日增 > 10 亿行），需要 Spark + ClickHouse 的分层架构，Spark 负责离线加工，ClickHouse 负责在线查询。数据口径一致性是长期挑战，建议从架构设计阶段就统一指标定义层，避免"同指标不同数"的治理困境。