企业官网建设流程全解析

ClickHouse与Spark集成这件事，我踩了将近两年的坑，才把"怎么混着用"想明白。问个很现实的问题：你的数仓里到底是用ClickHouse扛报表，还是用Spark跑清洗？可能很多人第一反应是"都用"，但真正落地时就会发现——明明都是大数据处理界的明星工具，真让它们协作起来却总有说不出的别扭。这篇博文就是围绕ClickHouse和Spark的集成，把混合大数据处理方案讲透：它们各自擅长什么、什么场景才需要把它们拼在一起、拼的时候有哪些能直接照抄的方案和代码，以及我在生产环境里踩过的那些文档里查不到的坑。无论你是正在做技术选型的架构师，还是已经在跑Spark和ClickHouse但被衔接问题折磨的工程师，这篇文章都值得看完。

1. ClickHouse与Spark的能力边界：为什么选型摆错位置最容易翻车

1.1 一个真实的翻车案例

先说一个我亲历的案例，这也是促使我真正研究这俩工具集成的起点。2023年我们团队负责一个电商数据分析平台，最初架构很简单：业务库通过Canal同步到Kafka，然后一股脑灌进ClickHouse。白天还好，一到晚上跑全量分位数计算、多表关联、漏斗分析，ClickHouse的CPU就飙到90%以上，查询动不动几十秒甚至超时。后来有个同事提出"用Spark代替ClickHouse"，理由是Spark计算能力强。我们真把ETL和报表查询全迁到了Spark上，结果更惨——明细查询本来秒级出数，变成了十几秒起步，报表页面经常转圈转半天。

这个经历让我彻底明白了一个道理：ClickHouse和Spark根本不是替代关系，而是分属两个完全不同的生态位。选型摆错位置，比不选更可怕。

1.2 两个工具到底各自擅长什么

ClickHouse本质上是一个列式存储的OLAP数据库，它的DNA是"查询"——把千万行、上亿行数据放进内存里做聚合、过滤，利用向量化执行引擎和稀疏索引，在几毫秒到几秒内返回结果。它最舒服的场景是：大宽表、明细查询、多维聚合、漏斗分析、用户画像、实时报表。Redis是键值的存储，ClickHouse就是分析领域的"内存加速器"，而且它有完整的列式压缩，磁盘占用可以压到原始数据1/5甚至更低。

但ClickHouse天生不擅长什么？复杂的多表关联。虽然它支持JOIN，但一旦关联的表大了、关联次数多了，内存和临时文件的压力非常大，性能会断崖式下跌。它也不适合做高并发点查，毕竟不是为OLTP设计的。还有一个容易被忽略的点：ClickHouse的SQL表达能力有限，窗口函数、UDF虽然新版在补，但和Spark SQL、PySpark生态相比还是太单薄。

Spark则恰恰相反。Spark的核心是"计算"——它把数据分散到集群内存中，通过RDD/DataFrame做任意复杂的变换，能跑ETL、能算特征、能训练机器学习模型、能做流批一体处理。它的SQL语法完整度接近标准SQL，UDF、窗口函数、复杂JOIN都是家常便饭。

但Spark的问题也很突出：调度开销大，启动一个Task要几十毫秒到几百毫秒；查询结果返回的路径长，从Driver到Executor再到用户，想做低延迟交互查询基本没戏。说白了，Spark是"算得动"的批量计算器，不是"查得快"的搜索引擎。而且它处理小文件、小数据量时效率极低，1000万以下的数据量用Spark跑一次任务的时间，往往比ClickHouse直接查还要慢。

1.3 两个工具的正确分工

经过那一次翻车案例，我的准则变成了这样一句话：

数据清洗和计算交给Spark，数据存储和高频查询交给ClickHouse。也就是让Spark把数据"做熟"，再喂给ClickHouse去"上菜"。

举几个具体的分工场景。

场景一：日志清洗。原始日志往往有脏数据、嵌套JSON、重复记录，这种工作交给Spark，用DataFrame做格式转换、字段提取、去重，清洗完按天分区写出列存储格式，然后导入ClickHouse。若是直接把原始日志灌进ClickHouse，不仅字段数量膨胀、存储成本高，而且后续每个查询都要带上清洗逻辑，时间久了表结构都会失控。

场景二：多表关联加工。假设要做用户生命周期分析，需要把订单表、用户表、商品表、退款表四张表关联。这四张表各有几千万到几亿行，在ClickHouse里做一次四表大JOIN，内存压力大得能让你彻夜难眠。正确做法是在Spark里做一轮关联加工成宽表，输出用户ID+行为标签+金额等关键字段，最后进ClickHouse。之后查询都变成单表聚合，ClickHouse几乎不费吹灰之力。

场景三：离线统计与近实时查询的分层。日活、GMV这类指标每天由Spark跑批任务计算好，结果存入ClickHouse的报表表；而点击流这种需要实时查看的明细，直接写入ClickHouse。前者是"离线算好、实时查询"，后者是"实时摄入、实时查询"，两条链路都合理，但永远不要让Spark去承接用户的交互式查询请求，也不要让ClickHouse承担超过其能力上限的重型计算。

注意：这里说的"交给Spark"不是指Spark分布式集群跑一天一夜，而是要清楚它适合跑那些分批、批量的复杂计算任务。真正的优化不是删掉某一个工具，而是让每个工具在自己的位置上干活。

2. 按业务场景选型：五条ClickHouse + Spark集成链路

当我明确了两个工具的分工后，接下来就是怎么把两者连起来。网上资料大多是单点演示，真正能指导生产选择的很少。我一共总结了五条集成链路，每条都有明确的适用前提和代价，你可以直接对照自己业务选型。

2.1 轻量集成：JDBC直连，适合小流量场景

这是最直觉、最简单的集成方式——Spark作为客户端，通过JDBC驱动直接读取ClickHouse中的数据表，或者把计算结果写入ClickHouse。前提是数据量不大，单次拉取控制在百万行以内，或者只是做维度表补全等小规模关联。

具体来说，在Spark的DataFrame API里配置jdbc数据源，指定ClickHouse的连接地址和表名，Spark会生成一个RDD，把ClickHouse表当成一个分布式数据集来用。我们早期做的一个用户标签补全任务就是这么干的：Spark读取订单明细，每行数据需要关联用户的基础属性，用户表一共200万行，存放在ClickHouse里，Spark在启动时通过JDBC拉取这张表广播出去，然后在map阶段补全字段。整个任务跑完不到5分钟，代码量很小，也不用额外维护同步链路。

JDBC直连的底细，说穿了就是Spark把SQL推给ClickHouse执行，然后拉结果。所以它适合"小数据量的读取"，不适合"大数据量的全量同步"。

2.2 离线批量：Spark算完，ClickHouse承接加速

这是我目前最推崇的一条链路，也是混合大数据处理方案里最能体现价值的部分。整体流程如下：

• Spark从HDFS/Hive/数据湖中读取大规模原始数据，进行复杂的清洗与关联加工；
• 加工好的结果数据以Parquet/ORC等列式格式写出到临时目录或对象存储；
• ClickHouse通过表函数或clickhouse-client将数据批量导入自身的MergeTree表。

这条链路的精髓在于"Spark负责算，ClickHouse负责查"。计算量再大也是Spark承担的，ClickHouse得到的永远是干净的、可索引的、低冗余的结果数据。查询时，ClickHouse利用稀疏索引和列式存储秒级返回，BI前端和即席查询都轻松应对。

我们做过一个典型的离线报表平台：Spark每天晚上从ODS层读取全天的订单、流量、行为明细，经过近十步关联和清洗，生成一张维度宽表，大概每天5000万行，然后导入ClickHouse。下次查询日活、GMV、转化率这些指标时，ClickHouse响应时间基本在200毫秒以内。换成之前直接用Spark跑，查询一次至少等半分钟，业务方完全无法接受。

2.3 准实时链路：Kafka + Spark Structured Streaming + ClickHouse

当数据需要"秒级到分钟级"的时效性时，JDBC直连和离线批量都不够，得引入消息队列和流计算。

链路是：业务数据通过Canal/Debezium捕获变更，或直接由应用发送埋点日志到Kafka；Spark Structured Streaming从Kafka消费，在流上进行轻量的过滤、补全、聚合，然后以微批的方式写入ClickHouse。

需要注意，ClickHouse官方也提供了Kafka引擎表，可以直接用CREATE TABLE ... ENGINE = Kafka消费Kafka数据，不需要Spark也行。那什么时候要引入Spark呢？答案是当Kafka里的原始格式需要复杂转换时——比如嵌套JSON展开、多流join、字段加密脱敏、去重。Kafka引擎表只能做简单的SQL转换，稍微复杂一点就撑不住了。

用Spark Streaming的好处是，流任务和离线批任务可以共用同一套数据处理逻辑，维护成本低。而且Spark对checkpoint、exactly-once语义支持比直接消费Kafka靠谱得多。

2.4 加速层方案：ClickHouse为数据湖/数仓加速

这一条实际上是2.2的进阶变体。很多团队已经引入Iceberg、Hudi、Delta Lake这类数据湖技术，用Spark读写湖表，构建开放的湖仓架构。但湖表查询性能始终是个痛点，尤其BI工具直接查Hive/Iceberg表，往往需要跑MapReduce或Spark任务，延迟根本压不下来。

我的做法是把数据湖当"全量存储"，把ClickHouse当"热数据加速层"。Spark负责将湖表的最新分区数据做增量计算，输出到ClickHouse；当用户要查明细或聚合时，请求优先打到ClickHouse，只有当ClickHouse里没有该粒度的数据时，才回退到Spark查询湖表。这样既保留湖的开放性和低成本存储，又获得ClickHouse的秒级查询体验。

2.5 迁移场景怎么做

还要单独提一类场景，就是ClickHouse数据库整体迁移。热门搜索里这个词曝光很高，说明踩过坑的人不少。ClickHouse迁移有两条路：一是用官方Backup/Restore，适合停机窗口内做物理备份恢复；二是如果你需要跨版本、跨集群甚至异构环境迁移，同时要做数据转换，那就用Spark：读旧ClickHouse全量数据，写Parquet到对象存储，再通过2.2的导入方式灌入新ClickHouse集群。

优点是可以顺便做数据清洗、类型转换、分区分桶重排，缺点是要考虑双跑期间的增量对齐。我们当时做跨机房迁移，就是Backup/Restore处理全量、Kafka链路处理增量、最后用Spark补数校对，三箭齐发才做到数据零丢失。

2.6 五条链路的选型对照

为了方便选择，我把五条链路的适用场景和关键参数整理成了一个表。

3. Spark读写ClickHouse的落地细节与三个典型坑

方案看着很多，但真正动手写Spark和ClickHouse的连接代码时，细节问题层出不穷。下面这部分是我在实际业务中踩过坑后总结出来的几个关键点，建议照着做。

3.1 版本与驱动：注意包名变化这个大坑

第一个坑来自ClickHouse JDBC驱动的包名。

旧版本（0.3.x及之前）的驱动类名是ru.yandex.clickhouse.ClickHouseDriver，很多老博客、老教程都在用这个。但新版本（0.4.x之后）官方把包名改成了com.clickhouse.jdbc.ClickHouseDriver。如果你引用的jar包升级了，代码里还写着旧的类名，会直接报ClassNotFoundException。

我的建议是统一采用新版驱动。Maven坐标如下：

<dependency> <groupId>com.clickhouse</groupId> <artifactId>clickhouse-jdbc</artifactId> <version>0.6.5</version> <classifier>all</classifier> </dependency>

注意<classifier>all</classifier>很关键，新版驱动如果不用这个分类器，可能缺少一些HTTP客户端依赖。

连接URL的基本格式是：

jdbc:clickhouse://ch-host:8123/default?connectTimeout=30000&socketTimeout=600000

ClickHouse的HTTP端口是8123，如果你写9000端口，那是native协议，新版驱动也支持，但建议默认走8123。

3.2 读链路：把过滤条件推给ClickHouse

用Spark JDBC读ClickHouse时，很多人直接写dbtable为表名，然后让Spark全表扫描。如果你这么干，大概率会遇到两个问题：一是Spark会把整张表拉回来，二是在ClickHouse端造成全表扫描。正确姿势是把过滤下沉到SQL里，让ClickHouse充分利用稀疏索引。

推荐写法是dbtable填一个子查询，而不是直接填表名：

val df = spark.read .format("jdbc") .option("url", "jdbc:clickhouse://ch-host:8123/default") .option("dbtable", "(SELECT event_date, uid, amount FROM app.orders WHERE event_date = '2024-06-18') t") .option("user", "readonly") .option("password", "xxxxx") .option("driver", "com.clickhouse.jdbc.ClickHouseDriver") .option("fetchSize", "50000") .load()

原理是：Spark JDBC DataSource支持谓词下推，event_date = '2024-06-18'这类等值条件会被下推成SQL的WHERE子句，由ClickHouse执行。但你要小心日期类型、Decimal类型的下推，如果字段映射不对，Spark无法把这个条件转成SQL字面量，就会退化为全表扫描。所以最稳妥的办法是在子查询里就把分区条件写死，别指望Spark的filter一定下推成功。

另外，读取ClickHouse时，dbtable子查询里尽量只select需要的列。ClickHouse是列存，少选一列，IO就少一列，这是基本素养。

3.3 写链路：别把JDBC当大批量导入工具

这是我在生产环境踩过最深的坑之一。一开始我用Spark的write.format("jdbc")直接写ClickHouse，结果每天跑完任务，ClickHouse的system.parts表里冒出几万个part，merge线程告警，查询性能从秒级变成分钟级。

原因很简单：MergeTree引擎每次INSERT都会生成一个新的data part，后台线程再异步合并。如果Spark端一条一条insert，或者批次太小，就会产生海量小part。所以写ClickHouse有一条硬性准则：宁可攒大包，不要频繁小写。

Spark JDBC写入虽然可以配置batchsize参数，但底层对ClickHouse驱动而言，跟原生的批量写入协议还是有差距。我的建议是，超过千万级的数据量不要用write.format("jdbc")，改用文件导入模式。

3.4 文件导入模式：Parquet + clickhouse-client / s3表函数

这是目前生产环境里我验证过最稳定的Spark写ClickHouse方案，流程如下：

第一步，Spark把结果写成Parquet列式文件到HDFS、本地临时目录或者S3对象存储。Parquet本身就是列存，和ClickHouse的列式存储更匹配，导入效率比CSV高很多，还保留了数据类型信息。

resultDF.write .mode("overwrite") .parquet("/tmp/spark-ch-export/20240618")

第二步，把Parquet导入ClickHouse。

如果ClickHouse和Spark共用的同一个HDFS集群，可以在ClickHouse节点上用clickhouse-client执行：

clickhouse-client --host ch-node1 --query "INSERT INTO app.dws_result FORMAT Parquet" < /data/parquet/20240618/part-00000-xxx.snappy.parquet

不过更现代化的做法是用ClickHouse的s3表函数，让ClickHouse自己读取S3中的Parquet完成导入。Spark写S3，ClickHouse从S3读取，中间不用传文件。

INSERT INTO app.dws_result SELECT * FROM s3('https://s3.amazonaws.com/bucket/path/20240618/*.parquet', 'AWS_ACCESS_KEY_ID', 'AWS_SECRET_ACCESS_KEY', 'Parquet')

这种方式的好处是：Spark和ClickHouse完全解耦，S3作为中间缓冲，导入速度由ClickHouse侧读取决定，而且不占用Spark集群到ClickHouse的网络带宽。如果只是临时导入一次，用clickhouse-client和文件形式最快；如果每天定时批量导入，走S3或者HDFS表函数更长久。

第三步，验证数据量和关键字段。导入完成后，最好在Spark端和ClickHouse端对一下行数和SUM值，避免数据重复或丢失。

3.5 数据类型的映射坑

Spark和ClickHouse的类型系统不完全一致，字段映射经常出问题，我简单列几个高频坑：

• Spark的DecimalType映射到ClickHouse的Decimal64/Decimal128，精度长度不一致时可能截断或报错。我建议导入前统一转成Decimal(38, 18)，两边都留足空间。
• 时间字段：Spark的Timestamp映射到ClickHouse的DateTime或DateTime64。注意时区问题，Spark默认UTC，ClickHouse默认服务器时区，差8小时是常事。规范做法是统一采用DateTime64(3, 'UTC')，展示层再做时区转换。
• 字符串空值：Parquet里的空字符串和null，在ClickHouse里都变成空字符串，除非字段设置为Nullable(String)。如果业务上要区分空字符串和NULL，记得在导入前清洗一次，避免语义错乱。
• ClickHouse的数组类型（Array(Int32)）在Spark里映射成ArrayType，Parquet支持，但要注意嵌套层级不能太深，太深会出现Spark和ClickHouse都不太能处理的状况。

3.6 一个完整的Spark写ClickHouse示例

以Spark 3.4 + Scala 2.12 + ClickHouse 24.x为例，一个标准的离线导入任务长这样：

// 1. 读取Hive/数据湖 val sourceDF = spark.sql(""" SELECT user_id, order_amount, order_time, channel FROM dwd_order_detail WHERE dt = '2024-06-18' """) // 2. 在Spark里完成清洗加工 val resultDF = sourceDF .filter(col("order_amount") > 0) .withColumn("order_date", to_date(col("order_time"))) .groupBy("user_id", "order_date", "channel") .agg( sum("order_amount").as("total_amount"), count("*").as("order_cnt") ) // 3. 写出Parquet到对象存储 resultDF .repartition(10) .write .mode("overwrite") .parquet("s3a://data-lake/dws_daily_user/2024-06-18") // 4. 触发ClickHouse侧的s3表函数导入，或者等待调度系统调用clickhouse-client

这段代码看起来平平无奇，但每一步都有讲究：先过滤再聚合、写出前repartition控制文件数量、Parquet目录按日期分区。这些都是长期跑稳定任务的经验。

4. 让两个系统和平相处的调优与保护策略

Spark和ClickHouse一旦真正集成到同一套生产环境，你还需要从治理层面保证它们不互相伤害。这个章节我会谈一些关键参数和实践心得。

4.1 并发连接与连接数控制

最典型的问题：Spark读取ClickHouse时，Spark可能生成几百个Task，每个Task都会建立JDBC连接。如果并发打到ClickHouse上，clickhouse-server的连接线程池会被打满，其他业务查询直接卡死。这把火我点过。

控制手段有两层。

第一层，Spark端限制读取并行度。Spark JDBC读取时，分区数由partitionColumn、lowerBound、upperBound、numPartitions控制。对于ClickHouse这种OLAP库，不需要那么多分区，设置为8~16个就足够了，并发太高只会徒增负担。

.option("partitionColumn", "user_id") .option("lowerBound", "1") .option("upperBound", "100000000") .option("numPartitions", "12")

第二层，ClickHouse端限制单用户并发查询数。给Spark用的账号设置一个较低的max_concurrent_queries_for_user，或者通过chproxy这类网关做队列和限流，防止突发流量压垮实例。

4.2 批量写入与part管理

写ClickHouse时，批次的粒度直接决定merge的健康状况。ClickHouse官方建议：单次INSERT至少1000行，推荐1万行~100万行。如果一次INSERT数据量太大，内存压力高；太小，part碎片多。Spark写入时，控制好batchsize和写入并行度，别让几十个Task同时往同一张表灌小批数据。

另外，每个MergeTree表建表时一定要设计好PARTITION BY和ORDER BY。比如按天分区用toYYYYMMDD(event_date)，排序键选最常用的查询条件字段，比如ORDER BY (event_date, user_id)。这样导入的每个part内部有序，查询时能直接跳过大量数据，也能减少后台merge压力。

4.3 慢查询保护与内存限制

ClickHouse一个让人爱恨交加的特性是，查询太慢时它会死磕到底，把所有CPU和内存吃光。这一点在Spark集成的场景里尤其危险——刚才提到，Spark可能推来一个没下推过滤条件的查询，ClickHouse会全表扫描，然后整个查询把机器拖垮。

所以生产环境必须给ClickHouse设置查询护栏。关键参数如下：

• max_execution_time：单位秒，设置为300，超过即中断查询，防止SQL失控。
• max_memory_usage：单查询最大内存，默认是10GB，你可以根据机器配置适当调低或保持。
• max_bytes_to_read：单查询最多读取的数据量，适合在BI账号上设置。
• readonly：给Spark/BI的读账号设置readonly=1，禁止修改类的危险操作。

我建议为Spark单独建一个低权限账号，只允许SELECT，并限制资源配额。这样哪怕Spark端误写一个全表扫描，ClickHouse也能自保。

4.4 任务调度与失败重试

混合架构里，Spark任务和ClickHouse导入任务是强依赖关系。Spark生成的数据文件没准备好就触发ClickHouse导入，必然失败。所以调度策略要设计好。

我们用的是Apache DolphinScheduler，Spark任务成功后再触发ClickHouse导入任务。每层任务都设置失败重试，重试间隔2分钟、最多3次。还有一个容易被忽略的点：导入任务完成之后，必须加一个数据校验步骤，对比Spark结果的行数和ClickHouse导入后的行数是否一致。别看它土，很多线上数据事故都是栽在没有校验这一步上。

5. 生产级混合大数据处理架构的长什么样

讲了这么多，最后落一个完整的架构图。这是我现在管理的线上平台正在跑的方案，各模块都有明确职责，基本能覆盖"离线+实时+即席分析"三类需求。

5.1 数据分层与链路设计

整体分四层：

• ODS层：原始数据落到HDFS/数据湖里，用Hive/Iceberg管理，保留全量、不做清洗，成本最低、最安全；
• DWD层：Spark负责从ODS读取，做清洗、去重、规范化、维度退化，产出明细宽表，依然存放在HDFS/数据湖；
• DWS层：Spark按业务主题做聚合，产出汇总指标，同时把需要高频查询的明细和聚合结果导入ClickHouse；
• ADS层：BI报表、即席查询、用户画像服务直接读ClickHouse，个别需要复杂关联的旁路任务继续走Spark。

链路流转一般是两条：

离线链路：ODS → Spark每日批处理 → DWD/DWS → Parquet → ClickHouse导入 → BI查询。

实时链路：业务数据/埋点 → Kafka → Spark Structured Streaming清洗 → 批量攒批 → ClickHouse导入 → 实时大屏/告警。

5.2 各组件资源规划参考

资源上有一个建议：Spark和ClickHouse不要混布在同一批物理机上。两者都是CPU和内存大户，混在一起极易互相干扰。我们最早图省事混布过，结果Spark跑大任务的时候，ClickHouse查询P99直接从100毫秒涨到3秒，后来拆开才好。

5.3 性能收益与实际表现

这套架构上线后，我们做了几组对比，效果是可以量化的。

• 原来直接用Spark跑报表查询，日活报表需要45秒；现在Spark只负责计算和写入，查询走ClickHouse，响应时间在300毫秒以内。
• 原来ClickHouse承担全部ETL加工时，CPU经常90%以上；现在ETL全部交给Spark，ClickHouse CPU稳定在20%以下，查询并发承载能力明显提升。
• 全量订单宽表约2.3亿行，导入ClickHouse后，单次查询按用户维度过滤加聚合，响应时间稳定在400毫秒左右。

另一个隐性收益是团队开发效率。数据开发只需要维护Spark的ETL逻辑和ClickHouse的建表语句，责任边界清晰：Spark管"怎么算得对"，ClickHouse管"怎么查得快"，出了问题排查范围也小。

5.4 什么情况下其实不需要这套混合方案

说句公道话，混合大数据处理方案不是银弹。如果你的数据量还不到千万级，查询压力也不大，用ClickHouse单机版或者直接用MySQL+索引就够用了，引入Spark和ClickHouse两套系统纯粹是给自己找运维麻烦。

另外，如果你的查询主要是多层大表JOIN，而且对灵活建模要求极高，那ClickHouse未必合适。这种场景应该考虑Doris、StarRocks这类MPP分析型数据库，它们对多表JOIN的支持比ClickHouse强不少，而且本身可以融合导入链路，未必需要Spark介入。反过来，如果你的业务全是单表单聚类的报表，用ClickHouse就足够了，集成Spark反而是画蛇添足。

我个人的体会是，混合方案的真正价值在于"计算与查询分离"这个架构思想，而不是非要把两个明星工具凑到一起。ClickHouse负责最后一公里的查询体验，Spark负责前面几十公里的数据加工，两者各司其职，再用文件、消息队列、调度系统把它们衔接起来，这就是目前我见过的最可靠、也最容易维护的大数据处理组合。如果你也在从纯离线数仓向实时化、服务化演进，不妨沿着这条路线一步步搭起来。