大数据推荐系统架构设计与Spark优化实践

1. 项目背景与核心需求

在当前的房地产市场中，购房者面临着海量房源信息筛选的难题。传统推荐方式往往基于简单规则（如价格区间、地理位置）进行匹配，难以满足用户的个性化需求。我们设计的大数据商品房推荐系统，正是为了解决这一痛点。

系统需要处理的核心数据包括：

• 房源基础信息（面积、户型、楼层等结构化数据）
• 用户浏览行为（点击、收藏、停留时长等时序数据）
• 市场动态数据（周边配套设施、学区政策等半结构化数据）

这些数据具有典型的"4V"特征：

1. Volume：单个城市日增房源数据约5-10GB
2. Variety：包含文本、图像、时空坐标等多模态数据
3. Velocity：用户行为数据要求秒级响应
4. Veracity：中介发布信息存在20%左右的噪声数据

2. 技术架构设计

2.1 整体架构方案

采用Lambda架构实现批流一体化处理：

code复制[数据源] -> [Kafka] -> 
    -> [Spark Streaming] -> [Redis] -> [API服务] (实时路径)
    -> [HDFS] -> [Spark批处理] -> [HBase] -> [API服务] (离线路径)

选择该架构的三大理由：

1. 容错性：离线层可修正实时层的计算误差
2. 灵活性：批处理适合复杂算法，流处理保证时效性
3. 扩展性：各组件均可水平扩展

2.2 核心组件选型对比

3. 推荐算法实现

3.1 特征工程处理流程

1. 数值特征标准化：

python复制from pyspark.ml.feature import StandardScaler
scaler = StandardScaler(inputCol="price", 
                       outputCol="scaledPrice",
                       withStd=True,
                       withMean=True)
model = scaler.fit(df)
scaled_data = model.transform(df)

2. 文本特征提取（房源描述处理）：

python复制from pyspark.ml.feature import Word2Vec
word2vec = Word2Vec(vectorSize=100, minCount=3,
                   inputCol="description_words", 
                   outputCol="description_vector")

3. 时空特征编码：

• 使用H3 Uber的六边形网格系统对地理位置进行编码
• 时间特征分解为[工作日/周末, 时段标签]

3.2 混合推荐模型

采用加权混合策略：

1. 协同过滤（30%权重）：

   • Item-CF：基于房源相似度
   • User-CF：基于用户行为相似度

2. 内容过滤（25%权重）：

   • 使用房源特征构建余弦相似度矩阵

3. 深度学习模型（45%权重）：

python复制from tensorflow.keras.layers import Concatenate, Dense

def build_tower(input_dim):
    inputs = Input(shape=(input_dim,))
    x = Dense(256, activation='relu')(inputs)
    x = Dense(128, activation='relu')(x)
    return Model(inputs, x)

user_tower = build_tower(user_dim)
item_tower = build_tower(item_dim)

merged = Concatenate()([user_tower.output, item_tower.output])
outputs = Dense(1, activation='sigmoid')(merged)

4. 性能优化实践

4.1 数据倾斜解决方案

问题现象：

• 热门小区房源引发数据倾斜
• 某些Task处理时间是平均值的50倍

优化方案：

1. 预处理阶段：

python复制# 识别倾斜key
skew_keys = df.groupBy("community_id").count()
            .orderBy("count", ascending=False)
            .limit(5).collect()

# 添加随机前缀
from pyspark.sql.functions import when, rand
df = df.withColumn("salt", 
    when(col("community_id").isin([k[0] for k in skew_keys]),
         (rand()*10).cast("int")).otherwise(0))

2. 聚合阶段：

python复制# 先局部聚合
partial_agg = df.groupBy("salt", "community_id").agg(...)

# 最终聚合
final_agg = partial_agg.groupBy("community_id").agg(...)

4.2 Spark参数调优

关键配置示例：

bash复制spark-submit --master yarn \
--executor-memory 16G \
--executor-cores 4 \
--num-executors 20 \
--conf spark.sql.shuffle.partitions=200 \
--conf spark.default.parallelism=200 \
--conf spark.serializer=org.apache.spark.serializer.KryoSerializer \
--conf spark.memory.fraction=0.8

实测效果对比：

5. 生产环境部署

5.1 集群配置建议

硬件配置方案：

• Master节点：32核/128GB内存/2TB SSD ×3（HA部署）
• Worker节点：16核/64GB内存/10TB HDD ×20
• 网络要求：10Gbps以上互联带宽

软件版本组合：

• Hadoop 3.3.4
• Spark 3.3.2
• Python 3.8.12
• JDK 1.8_352

5.2 监控指标设计

关键监控项：

1. 实时流水线：

   • Kafka Lag（消费延迟）
   • Spark Streaming批次处理时间
   • Redis命中率

2. 离线流水线：

   • HDFS存储增长率
   • Spark作业失败率
   • 特征更新时效性

使用Grafana配置的监控看板示例：

code复制CPU利用率 < 70%
Executor内存使用率 < 85%
Shuffle读写延迟 < 500ms

6. 踩坑与解决方案

6.1 序列化问题排查

问题现象：

code复制Serialization stack:
- object not serializable (class: org.apache.spark.sql.Dataset)

根因分析：
在UDF中引用了不可序列化的Dataset对象

正确做法：

python复制# 错误示范
broadcast_df = df.filter(...)
spark.udf.register("my_udf", lambda x: process(x, broadcast_df))

# 正确做法
broadcast_dict = {row.id:row.value for row in df.collect()}
broadcast_var = sc.broadcast(broadcast_dict)
spark.udf.register("my_udf", lambda x: broadcast_var.value.get(x))

6.2 小文件问题治理

问题现象：

• HDFS存在数百万个小文件
• Spark作业启动缓慢

优化方案：

1. 写入时合并：

python复制df.repartition(20).write.parquet(...)

2. 定期合并：

bash复制hadoop fs -getmerge /input/* /tmp/merged-file
hadoop fs -put /tmp/merged-file /output/merged

3. 使用Hive合并：

sql复制ALTER TABLE table_name CONCATENATE;

7. 效果评估与迭代

7.1 A/B测试方案

测试指标设计：

分流策略：

• 用户哈希分桶（50%对照组，50%实验组）
• 新用户默认进入实验组
• 特殊用户（VIP）保持原有策略

7.2 模型迭代周期

持续交付流水线：

1. 日级更新：

   • 用户行为特征
   • 实时排序模型

2. 周级更新：

   • 协同过滤矩阵
   • 深度学习embedding

3. 月级更新：

   • 模型结构重构
   • 特征工程优化

在实际运行中，我们发现三个关键经验：

1. 离线特征更新需要与线上服务解耦，通过版本号控制
2. 模型灰度发布时，新旧版本需要共享特征存储
3. 用户冷启动问题通过迁移学习缓解效果最佳