豆瓣电子书推荐系统：Hadoop生态实战与优化经验

1. 豆瓣电子书推荐这个项目，为什么要用完整的Hadoop生态

我2024年初接过一个做豆瓣电子书推荐系统的活儿，调研阶段翻了一圈网上的推荐系统文章，发现大部分都在讲算法模型本身——协同过滤调个参、DeepFM拉个准确率、Attention再加一层，漂亮是漂亮，但真正落到生产环境，问题全都出在数据上。

豆瓣电子书的数据，说多不多，说少不少。图书元数据大概百万级，用户打分、收藏、想读、在读这类行为记录累积下来是亿级。单独一台机器用Pandas处理，慢到怀疑人生；直接上深度学习框架做特征工程，光洗数据就够你崩溃。这个项目的核心诉求，不是“推荐算法多花哨”，而是让数据从采集到加工到训练到服务，整条链路稳定跑起来。这也是我最终选择Spark + Hadoop + Hive + 机器学习 + 深度学习这套组合的根本原因。

有人说这是典型的大炮打蚊子——一个推荐系统而已，用得着Hadoop全家桶吗？我的答案是：如果你只做离线小规模实验，确实用不上；但如果你要做的是一套能持续更新、能回溯、能扩展用户量和图书量的系统，大数据生态的收益会随着数据规模滚雪球式放大。HDFS解决存储和扩容，Hive负责离线的清洗与特征加工，Spark负责高吞吐的分布式计算和后续的模型训练样本生成，最后深度学习负责排序精度的提升。每一层都有不可替代的价值。

这篇文章就把我在这个项目里踩过的坑、最终跑通的架构、模型选型的实际经验，完整写出来。希望给正在搭建类似推荐系统的朋友一点参考，尤其是那种“有一定数据量但又不是超大厂级别”的团队，很多经验可以直接抄作业。

2. 豆瓣电子书的数据底座：采集、落盘与分桶设计

2.1 数据源拆解：不只是“豆瓣评分”那么单薄

很多人提到豆瓣电子书，第一反应是“评分 + 短评”。但一个能训练出有效推荐模型的系统，只靠这些远远不够。我实际的采集清单比你想象的要宽得多：

• 图书元数据：书名、作者、出版社、出版年份、ISBN、页数、封面图URL、标签、简介
• 用户行为数据：打分（1-5星）、想读、在读、已读、收藏、关注标签
• 评论内容：短评、书评、笔记，用于后续做文本特征
• 用户画像数据：性别（豆瓣很多早期用户填过）、注册时间、常驻标签、活跃时段
• 社交关系数据：关注了谁、谁关注了我，隐含兴趣传导价值

采集层用的是Scrapy + Selenium的组合。豆瓣网页版的图书详情页、用户主页、标签页，结构比较规整，Scrapy够了；但登录态下的用户行为流页面，有些是动态渲染，需要Selenium兜底。这里有个细节我必须强调：爬虫采集非常容易产生脏数据，尤其是用户ID在页面不同位置的格式不一致、ISBN偶尔缺位、出版年份存在多版本等，这些都要在采集阶段就做合法性校验，而不是等到入库后靠Hive去清洗。能在源头拦截的脏数据，不要带到大数据流程里。

2.2 HDFS目录与文件格式：从第一天就按生产标准来

采集到的原始数据，我先落本地临时目录，再用定时任务上传到HDFS。HDFS目录设计看起来是件小事，但后期维护体验差别巨大，我最终的存储结构是这样分层的：

bash复制/data/douban/ods/                # 原始数据层（贴源层）
  book_meta/dt=2024-01-01/
  user_behavior/dt=2024-01-01/
/data/douban/dwd/                # 明细数据层（清洗后）
  book_info_clean/
  user_behavior_clean/
/data/douban/dws/                # 汇总数据层（特征宽表）
  user_book_features/

文件格式我选了ORC，不是Parquet。原因很简单：这个项目以Hive为主要的离线查询引擎，ORC在Hive生态的适配度、压缩比、查询裁剪表现都更成熟。虽然Parquet在Spark SQL上可能略占优势，但我们的特征是离线加工为主，Hive的使用频率更高，ORC的收益更直观。数据量还没到需要极致调优的规模，选一个生态整合度更高的方案，省心很多。

另一个关键决策是分区策略。用户行为表按dt（日期）做一级分区，按user_id的哈希值做二级分区（分64个桶）。这样设计的好处是：每天的增量数据落盘时自动进当天分区，离线任务做T+1加工时只需扫描当天分区，不需要全表扫；哈希分桶则让后续Spark和Hive的join操作能做bucket join，规避了一个大坑——数据倾斜。

2.3 分桶键到底怎么选？我当时纠结了很久

分桶键的选取是这类系统里很容易被忽略、但影响深远的设计。我最终选了user_id的哈希作为分桶键，原因有两条：

第一，后续所有推荐模型相关的计算，无论是统计用户行为序列还是构造用户维度特征，几乎都要按用户粒度做聚合。把同一用户的全部行为放到同一个分桶，Spark做聚合时天然减少shuffle。

第二，图书侧的数据量远小于用户侧，图书元数据表不需要分桶，用小表广播即可。

这里有个反面教训：我一开始是有想过按book_id分桶的，理由是“用户买书/看书的行为都围绕book展开，按book分桶也合理”。但后来测试发现，热门图书的访问频次极高，一旦按book_id分桶，热点桶会成为整个任务的瓶颈节点，Spark的executor上会出现严重的负载不均。按user_id哈希分桶，因为用户分布天然均匀，各桶的负载也相对均衡。

2.4 存储层扩容的经验：HDFS节点是自己攒的

项目DataNode前期是3台，跑到数据量350G左右时，磁盘告警了。当时比较急，找了些现成的扩容方案，最后决定给HDFS加节点而不是简单加盘。普通机器加盘最容易，但NameNode压力会逐渐成为瓶颈；加DataNode节点能同时扩展存储和计算能力。新节点的数据均衡，我用的是HDFS自带的balancer命令，设了10M宽带上限跑了一天多，数据分布接近均衡。整个过程不复杂，但有一个细节踩了坑：新节点的dfs.datanode.data.dir目录权限没配对，导致DataNode进程起不来，报错还不明显，日志里只说“Failed to initialize”。后来查了才知道是目录的属主不是hdfs用户。如果你也在做HDFS扩容，先把目录的属主和权限一次配好，能省下不少排查时间。

3. Hive在整条链路里的真实角色：清洗、加工、特征落地

3.1 为什么清洗和特征加工的第一站是Hive而不是Spark？

很多人看到Spark之后会想：既然有了Spark，Hive是不是多余？这俩功能确实有重叠，但我经过这一轮实践，得出的结论是：在Hadoop生态里，Hive做离线SQL加工，Spark做计算密集型任务，两者是互补关系，不是替代关系。

原因有几点：一是Hive的SQL开发成本极低，团队成员不需要写Java或Scala，纯粹用类SQL就能快速完成ETL逻辑，开发效率高得不止一星半点。二是Hive底层的Tez执行引擎在跑多级JOIN、GROUP BY这类常规离线任务时，性能已经足够，而且更稳定，不容易出现Spark那种OOM问题。三是我们的大量特征、统计指标本身就是“用SQL描述比用代码描述更清晰”的东西，比如“统计每个用户过去30天阅读各类图书的数量”，SQL写出来一眼就能看懂，用Spark RDD写，别人接手还得先费劲理解逻辑。

3.2 清洗规则：从原始数据到可用的明细层

我用Hive做清洗时，核心规则有这几类：

• 去重：同一用户同一天对同一本书的重复打分记录，保留最新一条
• 过滤：用户行为表中，对未登录用户的匿名行为直接过滤；评分不在1-5范围的记录删除
• 格式统一：日期统一成yyyy-MM-dd，ISBN统一成纯数字格式，书名的全角半角统一
• 空值策略：用户性别空值填“unknown”，出版社空值填“unknown_press”，评分空值直接删行
• 异常值剔除：注册时间早于1970年、阅读页数大于全书页数这类明显逻辑矛盾的数据，直接删

下面这段是我在Hive里做用户行为清洗的简化示例，保留了核心逻辑：

sql复制INSERT OVERWRITE TABLE dwd.user_behavior_clean
PARTITION (dt = '${hivevar:dt}')
SELECT
  user_id,
  book_id,
  rating,
  action_type,
  NVL(sex, 'unknown') AS sex,
  NVL(press, 'unknown_press') AS press,
  CAST(REGEXP_REPLACE(ISBN, '[^0-9]', '') AS STRING) AS isbn,
  action_time
FROM (
  SELECT *,
         ROW_NUMBER() OVER (
           PARTITION BY user_id, book_id, action_type, TO_DATE(action_time)
           ORDER BY action_time DESC
         ) AS rn
  FROM ods.user_behavior
  WHERE dt = '${hivevar:dt}'
) t
WHERE rn = 1
  AND rating IS NOT NULL
  AND rating BETWEEN 1 AND 5
  AND action_time IS NOT NULL;

ROW_NUMBER()窗口函数在Hive里去掉重非常好用，但要注意分区键的设计（这里是user_id + book_id + action_type + 日期），分得太粗会把不同行为的记录误删，分得太细则去重效果不理想，需要结合实际数据反复调试。

3.3 从明细到特征宽表：该窄表就窄表，别被“宽表崇拜”裹挟

特征工程阶段，网上几乎所有人都在强调“宽表”，把几十上百个特征拼成一张大宽表。我一开始也这么干，把所有用户特征、图书特征、交互特征全部拉到一张表里，最后造成的结果是：Hive跑一次JOIN要十几分钟，Spark读一张表经常OOM，而且绝大多数特征在训练时根本用不到。

后来我重构了特征存储，拆成了三张窄表：

• 用户特征表：用户ID、性别、注册天数、活跃天数、偏好top标签、行为统计等
• 图书特征表：图书ID、作者、出版年份、平均评分、评论数、字数区间、一级分类、二级分类
• 用户-图书交互特征表：用户ID、图书ID、历史评分、阅读时长占比、是否收藏、最近交互时间

训练时按需求实时JOIN，模型需要哪些特征就取哪些。这个调整让Hive任务耗时下降了七成，Spark读数据时的内存压力也大幅减轻。窄表的好处不只是快，更重要的是迭代效率高——增加一个新特征，只需要改一张小表，而不用重建整张大宽表。总结一句：特征宽表是给查询优化的，不是给训练效率优化的。训练侧的痛点是数据冗余导致的内存与IO，窄表反而更对症。

3.4 Hive性能优化：我最常用的四板斧

这个项目Hive跑多了之后，我总结出四个最有效的优化手段，按照见效程度排序：

第一，分区裁剪。所有的明细层和汇总层表，都按日期做一级分区，任务只扫描需要的分区。这个大家都会做，但这里有个不容易注意到的地方：如果分区列参与JOIN或者WHERE的条件里用了函数包裹（比如WHERE dt = date_sub(current_date,1)），Hive的谓词下推有时会失效，导致全表扫描。写法上尽量把日期计算拿出来，用变量传入。

第二，数据倾斜处理。用户行为数据天然倾斜，一小部分重度用户贡献了大量行为记录。GROUP BY user_id时，少数几个hot user所在的reduce会处理海量数据，其他reduce空闲。我的折中方案是把倾斜key单独拎出来，先过滤再聚合，最后union回去。代码稍长，但效率提升明显。

第三，小文件合并。每天增量入库后，HDFS上会积压大量小文件（尤其是采集脚本写得太碎的时候）。小文件多，NameNode内存压力大，Spark读数据时也会因为task太多而调度开销飙升。我加了定时脚本，每天凌晨对前一天的分区做一次小文件合并，把文件数量控制在一个合理的区间。

第四，避免过度动态分区。我最早用动态分区写数据时，直接点了“允许所有动态分区”，结果某天一个任务一口气生成了几千个分区，元数据服务直接报警。后来就不用动态分区了，改成显式指定分区键，稳定很多。

4. 推荐模型的两条路线：从Spark MLlib到深度学习排序

4.1 第一阶段：Spark MLlib中的ALS做召回

这个项目里，召回阶段最终选的是Alternating Least Squares（ALS）协同过滤，这也是Spark MLlib里最成熟的推荐算法之一。为什么是ALS而不是SVD或矩阵分解的朴素实现？ALS在Spark里做了分布式优化，能把用户-物品评分矩阵分解成两个低维因子矩阵，在亿级行为数据上训练也能接受。SVD对稀疏矩阵的处理不友好，豆瓣图书数据稀疏度极高，至少95%以上的用户-图书对没有交互记录，SVD在这种情况下的表现远不如ALS。

用Spark跑ALS的训练代码非常简洁，核心就几行：

python复制from pyspark.ml.recommendation import ALS
from pyspark.ml.evaluation import RegressionEvaluator

als = ALS(
    userCol="user_id",
    itemCol="book_id",
    ratingCol="rating",
    rank=50,
    maxIter=15,
    regParam=0.05,
    coldStartStrategy="drop"
)
model = als.fit(train_df)

参数上，rank=50是因子向量维度，这个值决定模型的表达能力和训练开销，我先用10做粗调再逐步增加到50；regParam=0.05是正则化系数，防止因子矩阵过拟合。这里的coldStartStrategy="drop"必须设置，否则预测时遇到新用户或新图书，Spark会直接返回空值，导致评估流程崩溃。

ALS的评估不能只看RMSE，因为推荐场景更关心排序质量。我同时用Recall@20、Precision@20、NDCG@20评估召回效果。经验值是：ALS在这个数据集上Recall@20大概能做到0.18到0.25，看起来不高，但对召回阶段来说足够用，因为召回的目标是“不要漏掉可能感兴趣的”，精排才是真正决定用户看到什么的地方。

4.2 第二阶段：用LR和GBDT做精排

召回拿到候选集之后，精排阶段我先用了两套传统机器学习模型——逻辑回归（LR）和梯度提升树（GBDT）。这个阶段的意义是先建立一个强baseline，后面深度学习模型再跟它做对比，才能知道深度学习到底带来了多少提升，而不是靠感觉说话。

精排特征工程上，我分为三类：

• 用户侧特征：用户对候选图书的历史评分均值、该用户活跃度、该用户阅读量
• 图书侧特征：候选图书的平均评分、评论数、所属分类在该用户历史行为中的占比
• 交互侧特征：用户与候选图书的相似度分数（来自ALS的用户因子与图书因子余弦相似度）

LR的训练用Spark MLlib的LogisticRegression，权重用L2正则。GBDT则直接用了XGBoost4J的Spark版本，这个在分类特征处理、缺失值处理和训练速度上都很顺手。整体流程我先用LR做了个快速版本，AUC大概0.61，然后用GBDT替换LR，AUC涨到0.67左右。说明特征交互的建模对这个场景是有效的，GBDT能捕捉到LR学不到的非线性关系。

4.3 第三阶段：深度学习模型DeepFM的落地

传统模型跑通之后，我开始把精排模型换成深度学习方案。这里选了DeepFM而不是更复杂的DIN、DIEN这类序列模型，原因是：第一，DeepFM在特征交叉上的表现已经足够覆盖这个项目的需求；第二，我们当时的训练数据量级，使用过于复杂的模型容易过拟合；第三，DeepFM工程落地成熟，训练和推理都算简单，不需要专门的推理框架。

DeepFM的核心思想是端到端地把FM部分和Deep部分融合在一起，FM负责低阶特征组合，Deep部分负责高阶非线性特征挖掘。整个模型结构可以看作是把“LR + 特征交叉”升级成“FM + 深度网络”的并联结构。

训练过程中我用了Adam优化器，初始学习率0.001，batch size 1024，训练轮数控制在15轮以内。为什么不超过15轮？因为我在第8版实验时发现，超过15轮后验证集AUC不仅不涨，还会轻微下降，这是典型的过拟合信号。这时early stopping策略就很有用了，patience设成3轮，在验证集上连续3轮没有提升就停止训练，既省时间又避免过拟合。

DeepFM最终把精排AUC从GBDT的0.67拉到了0.72，CTR预估的相对提升大概7个百分点。落地到线上AB测试后，用户点击率提升约6.2%，收藏转化率提升约4.8%。这个幅度可能没有论文里写的那么夸张，但考虑到我们用的是一个中等规模的数据集，这个收益已经非常扎实了。

4.4 模型部署的精度选择：FP32、FP16、BF16、TF32，别再凭感觉选了

深度学习模型部署阶段，网上最容易被忽略但又极其影响线上性能的，是浮点格式的选择。这个项目里我专门做了一轮浮点格式的实验对比，因为之前团队里总有人在推理时直接用FP16，但他根本说不清为什么这么选。

先简单解释一下这几种格式的适用范围。FP32是单精度浮点，通用性最好，但显存占用高、计算速度偏慢。FP16是半精度浮点，显存减半，计算提速明显，但FP16的数值范围有限，在训练时容易出现梯度下溢；推理时风险相对小，但要注意不能有极端值。BF16是Brain Floating Point，Google为深度学习设计的，它的指数范围跟FP32完全一样，只是尾数精度少了，所以动态范围比FP16大得多，非常稳。TF32是NVIDIA Ampere架构引入的，专门用在Tensor Core上，它能用19位精度做矩阵运算，实际效果接近FP32，但吞吐量是FP32的8倍。

在DeepFM推理任务上，我做的实验结果是：FP32作为baseline，TF32和BF16的AUC损失都小于0.1%，完全可以忽略；FP16损失大约0.4%，也是可以接受的范围。但从数值稳定性角度，BF16和TF32更好，因为它们的动态范围足够大，不会出现数值溢出的情况。所以我最终在GPU推理服务里用了BF16做加速，在CPU上用TF32（如果GPU支持）或FP32兜底。

这一轮实验的教训是：不要在模型部署时盲选FP16，先分析自己模型中的数值分布范围。特别是GBDT类的模型，如果用于特征数值很大（比如“阅读时长秒数”），FP16很可能直接overflow。而神经网络里的embedding向量和输出层，数值范围通常比较温和，FP16风险相对可控。

5. Spark在训练与推理中间件里的三个关键职责

5.1 样本生成与特征拼接：Spark的分布式能力在这里体现得淋漓尽致

深度学习训练要用的正负样本，我先在Spark里做分布式生成。从Hive里读出用户行为表和图书特征表，用Spark SQL做JOIN和过滤，把用户最近30天的行为作为标签样本，用户当前时刻之前的数据作为特征。这里必须做严格的“时间切分”，防止特征穿越——如果用未来数据预测过去行为，模型的评估结果会好得不真实，上线后直接崩。

Spark SQL写法可以直接复用Hive的SQL逻辑，这也是我前面强调Hive和Spark互补的原因。两套引擎的SQL语法高度兼容，同一套特征逻辑可以无缝迁移。

5.2 批量预测：Spark跑离线推荐列表

用户打开App或者Web端，推荐列表的生成有两种方式：实时计算和离线预计算。这个项目的体量，实时计算成本高、收益低，最终用了Spark离线批量预测。每天凌晨，Spark读取用户的特征向量和候选图书特征，调用训练好的DeepFM模型做批量预测，给每个用户生成Top 100的推荐列表，写入Redis和HBase。白天用户请求时，直接从Redis里取列表，响应速度毫秒级。

这个方案有一个必须考虑的问题：模型每天更新一次，用户在当天凌晨看到的推荐会刷新。如果你的业务希望用户每次刷新都看到新内容，那要考虑多版本列表和一定的随机扰动。我在生成推荐列表时，会给预测分数加了一点高斯噪声，再按加噪后的分数排序。这样用户每次下拉刷新，看到的Top列表内容会略有变化，不会永远是一个固定顺序，体验好不少。

5.3 Spark集群配置和排错：一次OOM的完整排查过程

Spark集群在项目运行中，最头疼的问题是OOM。我第一次遇到Executor OOM时，日志只给了几句没头没尾的报错，一眼看不出原因。

排查过程是这样的：

第一步，先看Spark UI的Event Timeline，哪个Stage耗时最长，发现是shuffle阶段。第二步，看某个Task的输入数据量，发现某个Task读取的数据量比其他Task多两个数量级，明显是数据倾斜。第三步，定位倾斜原因是JOIN键分布不均，部分key数据量过大。第四步，加了一轮salting处理，给hot key加随机后缀，把数据打散到多个Task，再聚合。

还有一种场景是OOM发生在读取大表做collect()操作时，有些数据科学家写代码喜欢df.collect()把数据拉到本地再处理，这个在Spark里是绝对的性能杀手。我定的规矩是：任何超过100万行的DataFrame，禁止collect()，要么用write落盘，要么用foreachPartition做分区内处理。这个规则立竿见影，OOM次数少了八成。

5.4 Zookeeper在Spark/Hadoop生态里到底负责什么

关于Zookeeper，很多人学过但一直搞不清楚它到底管什么。我在这套系统里，Zookeeper主要协调两件事：

一是HDFS高可用。Active NameNode和Standby NameNode之间，需要通过Zookeeper来协调故障切换。当Active节点挂掉，Zookeeper里的临时节点会超时删除，触发Standby节点自动提升为Active。

二是HiveServer2的高可用。Hive跑批的时候，如果只有一个HiveServer2实例，它挂了所有任务都瘫了。我用Zookeeper注册多个HiveServer2实例，客户端通过Zookeeper做服务发现，任一个实例挂了，另一个能继续接管。

Zookeeper集群本身建议3台（最小高可用配置），如果有条件就5台。它的压力不大，不要把它和HDFS、YARN混布在同一批机器上，尽量独立部署，避免资源争抢影响其写盘性能。

6. 端到端联调时踩过的坑：整整一周的排查经验

6.1 JOIN导致的数据倾斜：热门图书成了慢任务制造机

这个坑发生在特征拼接阶段，用户行为表和图书元数据表JOIN时，热门图书（比如《三体》）的book_id在行为表里出现频率极高，导致单个Task处理的数据量远远超过其他Task。这个Task跑一小时，其他Task早就跑完等着，整个Stage卡在一个节点上。

解决办法有几种，我最终选的是“手动拆分热点key”。先把出现次数超过阈值（比如10万次）的book_id单独查出来，对这部分数据做随机加盐处理后JOIN，最后把结果里的盐值去掉。非热点数据走正常JOIN路径，最后合并结果。改造之后，这个Stage的执行时间从70分钟降到了12分钟。

6.2 ORC小文件爆炸：NameNode内存报警

某次数据回填任务，因为上游Spark写文件时分区过多，产生了几万个小文件，每个几十KB到几百KB不等。HDFS上文件数激增，NameNode直接内存告警，整个集群响应变慢。

处理办法是两步走：第一步，用Hive的ALTER TABLE ... CONCATENATE对小文件做合并；第二步，给Spark的写入设置更好的文件控制参数，比如coalesce(1)控制单分区写文件数量，或者repartition(分区数, 分桶键)让数据按分桶键落盘，避免碎文件。从那之后，我立了一条规矩：所有写入HDFS的任务，必须预估产出文件数和大小，防止小文件失控。

6.3 Hive随机抽样的坑：为什么取到的样本总是不均衡

项目初期做模型验证时，需要从全量用户行为里随机抽取样本。我当时直接用ORDER BY RAND()，结果这个查询在几亿行数据上跑了快半小时，因为ORDER BY是全局排序，必须把所有数据shuffle到一个Reducer里。这是一个极其低效的写法。

正确的做法是用TABLESAMPLE。Hive的TABLESAMPLE(BUCKET 3 OUT OF 100 ON RAND())，可以直接做随机抽样，虽然有一定偏差（大分区会多抽一点），但对模型训练影响不大。后来我干脆在Spark里用df.sample(withReplacement=False, fraction=0.05, seed=42)做抽样，生成训练集和验证集。效果好、速度快，也比Hive的TABLESAMPLE更好控制随机种子，便于实验复现。

6.4 深度学习训练轮数和精度的实战经验

DeepFM刚训练时，我总担心欠拟合，一口气跑30轮，结果验证集AUC反而比15轮的低。后来专门做了一组实验，把训练轮数从1到30逐个跑，观察验证集AUC曲线：

• 前5轮：AUC从0.55快速涨到0.70，这是模型在快速学习特征交互的阶段
• 5-15轮：AUC缓慢爬升到0.72，并在第12轮左右达到峰值
• 15轮以后：AUC开始波动下降，过拟合信号明显

结论是：对于这个量级的数据集，15轮是上限。如果你的学习率调小了，可以将max_epoch适当增大，但不要无脑增加轮数，用early stopping监控验证集，比凭经验拍脑袋强得多。

6.5 Hive执行流程中的一个小问题：为什么查个字段这么慢

项目后期有同事反馈，说Hive里明明有专门的字段，想根据某个已有字符去匹配另一个字段的字符，结果查询特别慢。这其实涉及Hive执行流程中的分桶、分区和文件裁剪机制。Hive查询慢，很多时候不是因为字段本身的类型或者内容，而是它没法利用分区裁剪或者分桶裁剪，导致全表扫描。

解决办法有几个方向：如果字段是分区字段，查询条件里直接带上分区过滤；如果字段非分区，但常用于过滤和JOIN，考虑对该字段做二级排序和分桶；如果是要根据已有字符模糊匹配另一字段，尽量避免LIKE '%xxx%'这种全表扫的写法，看能不能用倒排表或预先提取好的关键词字段替代。本质上，Hive不是为实时查询设计的，如果你的查询频繁到要秒级响应，就不要硬用Hive，把数据同步到ClickHouse或者ES里。

7. 系统全景：这些组件最终是怎么配合的

从全局视角看，整个推荐系统的数据流是这样的：

1. 采集层：Scrapy + Selenium定时抓取豆瓣数据，写入HDFS原始目录
2. 存储层：HDFS + ORC格式 + 日期分区 + 用户哈希分桶
3. 离线加工层：Hive做清洗、去重、特征加工，产出DWD和DWS层
4. 特征与样本层：Spark读取Hive表，生成训练样本，时间切分防止穿越
5. 召回层：Spark MLlib的ALS生成候选集
6. 精排层：DeepFM模型离线批量预测，生成Top 100推荐列表
7. 服务层：Redis存推荐列表，用户请求毫秒级响应

这套架构的伸缩性很好，数据量涨10倍，只需加DataNode和Spark节点，不需要重构代码。模型层面的迭代也很干净，想换新的精排模型，只需要改训练和预测两个环节，存储和特征层完全复用。

最后补充一个我在这套系统上受益最多的工具选择心得：不要被“技术潮流”绑架。市面上永远有更新、更炫的组件，但一个工程项目的本质是“稳定地解决业务问题”。Spark + Hadoop + Hive这套组合，虽然每个单点都不是最“潮”的，但它们的整合成熟度、社区广度、坑位文档数量，是这个项目能顺利落地的最大保障。