企业官网建设流程全解析

去年接了一个二手交易平台的数据分析项目，需求非常直接：把用户评论按照情感倾向分成正面、中性、负面三类，再做一个可视化大屏展示。合作方点名要用Hadoop+Spark+Django这套技术栈来做，后端语言锁定Python。当时第一反应是，这不就是一个文本分类加图表展示吗？后来真正动手才发现，二手交易场景的评论和普通电商评论完全是两码事——用户不是对着商家说话的，而是两个陌生人之间在做交易，措辞更野、情绪更冲、隐含信息更多。等到把采集、清洗、分布式存储、情感计算、Web展示整条链路跑通，前后花了将近一个月，其中一大半时间都耗在数据问题和环境问题上。今天把完整思路、技术选型逻辑、核心代码思路、踩过的坑都写出来，适合正在做大数据方向课程设计、毕业设计，或者想了解Hadoop+Spark+Django项目如何落地的同学参考。每一步都是实际跑过的，可信度有保障。

1. 二手交易评论的"江湖"：这个系统要解决的真实难题

1.1 二手评论和普通电商评论，差异比想象中大多了

做这个项目之前，我默认评论情感分析和网上常见的商品评论分析差不多，套一个现成模型就能出结果。结果拿到第一批真实评论数据后，立刻发现情况不对。

普通电商平台（比如某东、某宝）的评论对象是店铺和商品，用户吐槽点比较集中：物流慢、质量差、与描述不符、客服态度差。但二手交易平台的评论发生在两个真实用户之间，交易本身充满了协商、砍价、验货、改价这些环节，评论里经常出现"成色""掉电""到手刀"这类平台黑话，还有大量无法从字面判断情绪的反讽。

我举几个实际样本：

• "卖家是骗子，大家别买" —— 负面，非常明确
• "说好的九五新，到手一看至少八五，血亏" —— 负面，但"九五新""八五"是成色术语
• "捡漏了，这价格还要什么自行车" —— 正面，方言和反讽混合
• "真的是太好了，买回来一用就坏了" —— 表面正向词密集，实际是反讽差评

用通用情感词典跑一遍，第二条、第三条几乎全部判错，第四条模型直接给了正面。所以在设计整个系统之前，必须先承认一个事实：二手交易领域的评论，通用NLP工具搞不定，需要领域化的词典和定制训练数据。

另一个重要差异是数据规模。头部二手平台的日新增评论量可以达到百万级，而且平台方经常要分析历史三个月甚至半年的评论趋势来做运营决策，单机跑情感分析根本不现实。这也是项目必须引入Hadoop和Spark的根本原因，不是炫技，是被数据量倒逼的。

1.2 技术选型的取舍逻辑：为什么偏偏是Hadoop+Spark+Django

这个项目在选型上的讨论其实挺有意思。先说结论，最终确定的技术栈是：Python做数据处理和模型训练，Hadoop HDFS做评论数据的分布式存储，Spark做分布式情感计算和离线统计分析，Django做Web后端和可视化大屏的数据接口。

为什么不用MySQL直接存？因为评论数据是典型的文本海量数据，日增百万条、单条几KB到几十KB，存MySQL不仅占空间，查询历史趋势时也会把数据库拖垮。HDFS是为这种海量文件设计的，成本低、扩容简单，配上Parquet列式存储格式，后续Spark跑分析任务会明显快于直接从MySQL拉数据。这里的逻辑是：存储层解决"放得下"的问题，计算层解决"跑得动"的问题。

为什么用Spark而不是纯Python脚本？评论区里很多人觉得一两百万条数据用pandas也能跑。没错，一次性跑是能跑，但慢且不稳。用四节点的Spark集群，读写HDFS上的数据，跑情感分析模型预测加上各类统计聚合，100万条评论大约3到5分钟出结果，单机pandas可能要跑半小时以上，而且内存容易爆。Spark的另一个好处是自带MLlib机器学习库，训练逻辑回归、做特征抽取都可以在同一个Pipeline里完成，不用把数据搬来搬去。

为什么用Django？团队熟悉Python，Django自带ORM、Admin后台、模板引擎和成熟的路由体系，做一个带可视化大屏的管理后台非常合适。而且Django的ORM可以直接映射Spark写回MySQL的分析结果表，省掉一层数据访问代码。整体下来，这套技术栈的分工是：Hadoop负责存，Spark负责算，Django负责展示，各管一段，边界清晰。

2. 评论数据入湖：从采集清洗到Hadoop分布式存储

2.1 数据采集与清洗：二手评论的脏数据比想象中还脏

这个项目的数据来源是合作方提供的历史评论导出文件，同时我写了增量采集脚本，对接平台的公开API拉取新评论。没有开放API的平台，可以用爬虫模拟登录后按商品ID抓取，但要注意频率控制和合规性，一般建议优先使用官方接口。

采集字段最关键的是这几个：评论ID、用户ID（脱敏）、商品ID、评论内容、发布时间、评分（如果有）。很多二手平台的评论没有评分，只有文字内容，所以情感分析必须完全依赖文本本身，这也是项目难度较高的一个原因。

拿到原始评论后，清洗流程我分了四步：

1. 去重。同一用户对同一商品短时间内重复评论，只保留第一条。真实数据里大量存在"手滑多发""补评语句"的情况，不先去重会污染统计结果。
2. 剥离HTML标签和URL。二手平台的评论经常附带商品跳转链接或图片说明，这些对情感判断没有意义，直接正则剔除。
3. 繁体转简体。二手平台用户活跃区域广，很多评论是繁体，统一转简体后再处理，避免同一个词因为字形不同被拆成两个特征。
4. 表情符号处理。这一步很关键。二手评论里emoji非常多，而且信息量极大，比如😊和🖤表达的情绪完全不同。我把常见emoji映射成两类：一类转成对应语义标签（pos/neg），另一类直接剔除，具体做法在后面情感词典部分细讲。

清洗之后，每条评论会生成一个标准JSON格式，包含清洗后的文本、长度、是否含链接、是否含emoji标记等元信息。

2.2 Hadoop伪分布式环境搭建与HDFS目录规划

数据处理链路的第一步是把清洗后的文本送进HDFS。项目初期在开发环境用的是Hadoop伪分布式模式，也就是在一台机器上同时运行NameNode、DataNode等服务，模拟完整集群。真到生产环境再平滑扩展成多节点集群，代码不需要改动。

伪分布式搭建有几个关键配置点，我直接贴我验证过的配置。

core-site.xml中指定文件系统地址：

<configuration> <property> <name>fs.defaultFS</name> <value>hdfs://localhost:9000</value> </property> <property> <name>hadoop.tmp.dir</name> <value>/home/hadoop/hdfs_tmp</value> </property> </configuration>

hdfs-site.xml中设置副本数和元数据路径：

<configuration> <property> <name>dfs.replication</name> <value>1</value> </property> <property> <name>dfs.namenode.name.dir</name> <value>/home/hadoop/hdfs_tmp/namenode</value> </property> <property> <name>dfs.datanode.data.dir</name> <value>/home/hadoop/hdfs_tmp/datanode</value> </property> </configuration>

注意副本数一定要设成1，因为伪分布式只有一个DataNode，默认副本3会导致文件一直处于Under Replicated状态，日志里刷警告。

启动之后，用jps命令确认NameNode、DataNode、SecondaryNameNode都活着，然后建目录：

hdfs dfs -mkdir -p /user/hadoop/comment/raw hdfs dfs -mkdir -p /user/hadoop/comment/clean hdfs dfs -mkdir -p /user/hadoop/comment/result

原始评论JSON按日期分区存放，比如raw/20240401/comment.json，这是为了后续Spark按时间范围做增量分析。目录结构这种细节看起来小，但实际项目里非常影响开发效率，建议一开始就规划好。

HDFS上的原始文件我直接用文本格式存储，因为采集阶段还要保证可读性。但清洗后的、用于Spark计算的数据，我会转换成Parquet列式存储，压缩率高，Spark读取分析列时只加载需要的字段，速度能提升不少。

2.3 用SparkSQL做数据分层：在建表之前先想好怎么查

很多人一提到数据仓库就想到Hive，但在这个项目里我没有额外部署Hive，而是直接用SparkSQL承担了数据分层和查询的工作。理由是项目本身已经引入了Spark，SparkSQL能直接读HDFS上的Parquet文件，语法兼容Hive，省掉一个组件就少一套运维成本。

分层思路我参考了数仓的经典做法：

• ODS层：原始数据，对应comment/raw目录，只做最简单的格式校验。
• DWD层：清洗明细层，对应comment/clean目录，字段标准化，包括评论ID、商品ID、清洗后内容、内容长度、发布时间、日期分区。
• ADS层：应用汇总层，对应comment/result目录，存情感分析结果和各类统计聚合数据。

SparkSQL建表映射Parquet文件的示例：

CREATE TABLE IF NOT EXISTS comment_clean ( comment_id STRING, item_id STRING, content STRING, content_len INT, create_time TIMESTAMP, dt STRING ) USING PARQUET PARTITIONED BY (dt) LOCATION 'hdfs://localhost:9000/user/hadoop/comment/clean';

这样设计有个直接好处：每次新增数据只需要把当天数据写入对应分区，Spark分析任务可以只扫描dt='2024-04-01'的分区，不用全表跑。我实际测试过，加了分区和不加分区，同样跑一周趋势统计，耗时差了三倍以上，分区裁剪是实打实的优化，不是纸面功夫。

3. Spark情感引擎：词典打底、模型兜底的实战组合

3.1 情感分析路线之争：为什么不全靠深度学习

决定情感分析技术路线时，团队内部争论过一轮。市面上主流方案分三类：基于情感词典的规则方法、基于传统机器学习的分类方法、基于深度学习/预训练模型的方法。

纯深度学习路线（比如微调BERT）准确率确实最高，在标注充足的情况下能到90%以上，但代价是训练成本高、推理慢、依赖GPU。对于每天百万级评论的批处理场景，如果用BERT跑一遍，光推理时间就是几个小时，而且需要大规模GPU集群，明显不划算。

纯词典路线便宜快速，但二手交易平台的大量口语化表达和反讽会让词典法直接翻车。

最终采用"词典打底、模型兜底"的组合方案：先用构建好的领域情感词典给每条评论算出一组情感特征（正负情感得分、情绪词数量、emoji得分），再把特征和文本向量拼接在一起，输入Spark MLlib的逻辑回归分类器。这样既保留了词典方法对领域词汇的敏感度，又让模型能捕捉词汇组合的复杂模式，准确率远高于单一方案。

整体流程我用一句话概括：数据从HDFS读取 -> Spark执行中文分词 -> 词典特征计算 -> 文本向量化(HashingTF) -> 特征拼接 -> 逻辑回归预测 -> 结果写回HDFS和MySQL。

3.2 二手平台的特殊词典构建方法

词典是这套系统的地基。我花了整整三天做词表整理，最终形成四张表。

第一张是基础情感词典，直接使用公开的大连理工情感词汇本体库，约2.7万个情感词，每个词有词性和情感强度。这张表覆盖日常基本情感词，比如"喜欢""讨厌""满意""失望""快""慢"等。

第二张是二手交易领域黑话词典，这是整个项目最值钱的部分，大约整理出300多条。举几个真实的词条：

• "捡漏"（低价买到好货，正向）
• "传家宝"（卖家标价过高，负向）
• "刀一下"（砍价，中性偏负）
• "到手刀"（收货后恶意砍价，负向）
• "背刺"（刚买完就降价，负向）
• "血亏"（买贵了，负向）
• "骨折价"（价格极低，正向）
• "99新""九五新"（描述成色，需要结合上下文判断情感）

这批领域词条靠通用词典根本覆盖不到，但它们在二手评论里出现频率极高，直接影响判断结果。

第三张表是程度副词和否定词表。程度副词我要给权重，比如"极其"权重2.0、"非常"1.8、"有点"0.6；否定词包括"不""没""无""别""莫""不要"。计算规则是：遇到否定词时，把后续情感词的情感得分取反。比如"不划算"，"划算"是正向词，加否定词后整体情感翻转为负。

第四张表是emoji情感映射表。我统计了二手评论中出现频率最高的60个emoji，给每个打上正向、负向或中性标签。像😊、👍、🥰算正向，🤬、😤、💢算负向。计算时把emoji得分累加到整体情感特征里。

有了这四张表之后，每条评论可以算出一组词典特征。核心计算逻辑是：

def compute_lexicon_features(text): words = jieba.lcut(text) pos_score = 0.0 neg_score = 0.0 emoji_score = 0.0 neg_flag = 1 for w in words: if w in neg_words: neg_flag = -1 elif w in degree_words: neg_flag *= degree_weight[w] elif w in pos_dict: pos_score += pos_dict[w] * neg_flag neg_flag = 1 elif w in neg_dict: neg_score += neg_dict[w] * neg_flag neg_flag = 1 # emoji单独统计 for e in emoji_list(text): emoji_score += emoji_map.get(e, 0) return pos_score, neg_score, emoji_score

这里的neg_flag处理否定词和程度副词的连用，实际效果比简单的词频统计好很多。

3.3 特征设计、模型训练与准确率提升记录

特征方面，我试了两种向量化方案。端到端试下来，最稳的组合是三类特征拼接：

1. 文本特征：jieba分词后用Spark MLlib的HashingTF生成哈希向量，numFeatures设为10000。相比TF-IDF，HashingTF不需要维护全局词表，在分布式环境里更友好，效果差异很小。
2. 词典情感特征：上一步算出的pos_score、neg_score、emoji_score三个数值。
3. 文本统计特征：评论长度、感叹号数量、问号数量、大写字母占比（英文内容）、是否含链接。这些看似简陋的特征对情感分类有不错的区分度，尤其是感叹号频繁出现时，负面概率会明显上升。

模型训练数据来自三部分：人工标注的5000条评论、合作方提供的历史投诉和售后记录（天然负面样本）、通过同义词替换做轻度增强后的样本，总计约2万条。标签分三类：0中性、1负面、2正面。

模型我选了逻辑回归，原因有两个：一是Spark MLlib里逻辑回归分布式训练成熟稳定，二分类扩展成三分类也很自然；二是模型可解释性强，后续排查误判时能够通过特征权重定位问题。

在Spark MLlib里用Pipeline串联特征工程和训练：

from pyspark.sql import SparkSession from pyspark.ml.feature import HashingTF, Tokenizer, VectorAssembler from pyspark.ml.classification import LogisticRegression from pyspark.ml import Pipeline spark = SparkSession.builder.appName("comment_sentiment").getOrCreate() df = spark.read.parquet("hdfs://localhost:9000/user/hadoop/comment/clean") tokenizer = Tokenizer(inputCol="seg_content", outputCol="words") hashingTF = HashingTF(inputCol="words", outputCol="tf_features", numFeatures=10000) assembler = VectorAssembler( inputCols=["tf_features", "pos_score", "neg_score", "emoji_score", "content_len", "exclamation_cnt"], outputCol="features" ) lr = LogisticRegression(featuresCol="features", labelCol="label", maxIter=200) pipeline = Pipeline(stages=[tokenizer, hashingTF, assembler, lr]) model = pipeline.fit(train_df)

关于准确率的提升过程，我记录得很清楚。第一版直接用通用工具和朴素贝叶斯，准确率只有68%，负面评论召回率勉强到60%，基本不可用。后来逐步加入领域词典特征，换成逻辑回归，准确率到了79%。再把否定词处理、emoji映射、文本统计特征全部加上，最终在5000条人工标注的测试集上准确率稳定在87%，其中负面评论召回率89.1%。这个指标对业务是有意义的，因为平台最关心的是差评能不能被及时发现。

4. Django后端与可视化大屏：Spark的结果怎么端到用户面前

4.1 Django项目布局与核心接口设计

Spark计算完成之后，结果会写回HDFS的result目录，同时把汇总统计写入MySQL。Django这一层不直接读Hadoop，而是通过MySQL获取分析结果，这样Web查询的响应速度才有保障。如果每次打开大屏都去HDFS拉数据，用户会等到崩溃。

Django项目划分了四个核心App：

• comments：处理评论详情、评论列表的展示和检索
• analysis：处理情感分析结果、统计指标
• dashboard：负责可视化大屏数据接口
• users：后台用户登录和权限控制

数据库表设计上，我的核心表是sentiment_result，字段包括：统计日期、总评论数、正面评论数、负面评论数、中性评论数、正面占比、负面占比、情感得分均值，以及更新时间。另外有一张negative_top_item表，用于存储负面评论最多的Top商品和对应的典型评论。

对外接口设计得尽量精简，大屏页面只需要三个接口：

# dashboard/views.py from django.http import JsonResponse from .models import SentimentResult def summary_api(request): latest = SentimentResult.objects.order_by('-stat_date').first() return JsonResponse({ "status": 0, "data": { "total": latest.total_count, "positive_ratio": latest.positive_ratio, "negative_ratio": latest.negative_ratio, "neutral_ratio": latest.neutral_ratio, "sentiment_score": latest.sentiment_score, } }) def trend_api(request): days = int(request.GET.get("days", 30)) rows = SentimentResult.objects.order_by('-stat_date')[:days] data = { "dates": [r.stat_date.strftime("%m-%d") for r in rows][::-1], "positive": [r.positive_ratio for r in rows][::-1], "negative": [r.negative_ratio for r in rows][::-1], "neutral": [r.neutral_ratio for r in rows][::-1], } return JsonResponse({"status": 0, "data": data})

注意我在返回数据时做了倒序处理，因为数据库里最新日期在最前面，而图表希望日期从左到右递增。这种细节很容易被忽视，但直接影响大屏展示效果。

4.2 ECharts大屏的数据绑定与刷新机制

可视化大屏我用了ECharts 5.x自研方案，没有用Grafana。理由是Grafana虽然开箱即用，但定制业务模块（比如负面商品Top10、词云、运营建议面板）时限制比较大，不如直接写HTML+JS灵活。

大屏整体布局分成四个区域：

1. 顶部核心KPI条：总评论量、正面占比、中性占比、负面占比、综合情感得分，数字从summary_api接口读取。
2. 中部左侧：30天情感趋势折线图，三根线分别代表正面占比、负面占比、中性占比。
3. 中部右侧：情感占比环形图，用绿、红、灰三色表示正、负、中性。
4. 下部：负面商品Top10横向条形图，加上一个评论词云，词云里负面词用红色突出。

ECharts核心绑定代码大概是这样的：

$.getJSON('/api/dashboard/trend', function (res) { if (res.status !== 0) return; var data = res.data; var chart = echarts.init(document.getElementById('trendChart')); chart.setOption({ tooltip: { trigger: 'axis' }, legend: { data: ['正面', '负面', '中性'] }, xAxis: { type: 'category', data: data.dates }, yAxis: { type: 'value', max: 100, axisLabel: { formatter: '{value}%' } }, series: [ { name: '正面', type: 'line', data: data.positive, smooth: true }, { name: '负面', type: 'line', data: data.negative, smooth: true }, { name: '中性', type: 'line', data: data.neutral, smooth: true } ] }); });

刷新机制我选择了30秒定时轮询，而不是WebSocket。虽然Django Channels可以做后端到前端的实时推送，但考虑到情感分析结果是每天更新一次，30秒的轮询完全够用，实现简单并且不会因为WebSocket断连增加运维负担。如果是新浪微博热搜情感这种秒级更新场景，我才会考虑上WebSocket。

4.3 让Spark任务自动跑：crontab+spark-submit

大屏上的数据不会自己出现，必须有一个机制让Spark任务每天定时运行。我最终的方案是Linux crontab调用一个Shell脚本，脚本里执行spark-submit。没有用Celery，原因很简单：项目没有复杂任务队列，Celery引入Redis和Worker反而多两个不稳定点。定时任务越简单越可靠。

Shell脚本大致长这样：

#!/bin/bash source /etc/profile cd /home/hadoop/sentiment_project spark-submit \ --master yarn \ --deploy-mode client \ --driver-memory 2g \ --executor-memory 4g \ --num-executors 4 \ --executor-cores 2 \ --py-files dependencies.zip \ sentiment_analysis.py \ --date $(date -d "yesterday" +%Y%m%d)

Crontab配置每天凌晨2点执行：

0 2 * * * /home/hadoop/sentiment_project/run_sentiment.sh >> /home/hadoop/sentiment_project/logs/cron.log 2>&1

选凌晨2点是因为这个时段平台访问量低，Spark任务资源充足，而且昨天的评论数据已经全部落库，不会漏数据。脚本跑完后会自动把结果写入MySQL，第二天早上打开大屏就是最新数据。

在实际运行过程中，我还加了一个很小的容错逻辑：Spark任务成功后会写一个_SUCCESS标记文件到HDFS结果目录，Shell脚本每次先检查这个文件是否存在，存在才执行MySQL更新，避免数据重复写入或半成品写入。

5. 部署与调试实录：伪分布式环境里的五个经典大坑

5.1 Hadoop起不来的常见原因：从端口占用到ssh免密

Hadoop伪分布式搭建过程我踩的第一个坑就是DataNode起不来。当时start-dfs.sh执行完，NameNode进程正常，DataNode却一直闪退，日志里报java.io.IOException: Incompatible clusterIDs。查下来原因是之前初始化NameNode时生成过旧的clusterID， DataNode目录里记录的是旧ID，两边对不上就会拒绝启动。解决方法是把hdfs_tmp目录下的namenode和datanode数据清空，重新执行hdfs namenode -format。这个坑非常经典，几乎每个搭Hadoop的人都会遇到。

第二个坑是ssh免密登录没配置好，导致start-dfs.sh在执行远程启动脚本时卡住。伪分布式模式虽然只有一台机器，Hadoop脚本仍然会尝试通过ssh localhost执行命令，如果没做免密登录，每次都要输密码，脚本就一直等。解决办法是执行ssh-keygen -t rsa然后ssh-copy-id localhost。

第三个坑是端口冲突。Hadoop 3.x 的NameNode Web UI默认端口是9870，如果机器上已经跑了别的服务占用这个端口，页面就起不来。建议搭环境前先确认netstat -tlnp | grep 9870和9000端口没有被占用。我在这上面浪费了半个多小时，最后发现是一个测试用的Nginx占了端口。

配置Hadoop还有一个容易被忽略的问题：JAVA_HOME。很多Linux服务器上java命令能用，但JAVA_HOME环境变量没写进/etc/profile，导致Hadoop启动脚本找不到JDK路径。建议在hadoop-env.sh里强制指定：

export JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64

5.2 Spark任务为什么老是ExecutorLost：内存与资源调优

Spark跑情感分析模型时，遇到过最多的报错是ExecutorLostFailure，这通常不是代码逻辑错，而是executor内存不够导致进程被系统杀掉。

我一开始在spark-submit里把--executor-memory设成8g，想着内存越大越好。但伪分布式或小型集群总内存有限，YARN在资源分配时会发现申请的容器数超出实际可用内存，于是反复尝试重启executor，最终表现为任务卡死或者频繁的Container killed。

后来我的调参思路是：先看YARN可用资源总量，再决定executor数量和内存。比如单机伪分布式总内存16g，给YARN分配12g，那么executor内存设4g、数量设2个比较稳妥；如果是四节点集群，每个节点16g，可以设置executor内存4g、数量4个。关键点是executor内存 × executor数量必须小于YARN可用内存，不能盲目堆参数。

另一个和Python相关的坑是Spark版本和Python版本匹配问题。Spark 3.x要求Python 3.8以上，如果服务器默认python命令指向Python 2.7，spark-submit启动PySpark时会直接报Python in worker has different version 2.7 than that in driver 3.8。解决方式是在spark-env.sh里配置：

export PYSPARK_PYTHON=/usr/bin/python3 export PYSPARK_DRIVER_PYTHON=/usr/bin/python3

务必保证driver和executor用的是同一个Python解释器路径，否则同步py-files后worker端的库会加载不全。

5.3 中文编码与跨环境协同：开发机Windows，服务器Linux

我的开发机是Windows，服务器是Linux，这个组合在Python大数据项目里最容易出幺蛾子，主要问题都出在编码上。

Windows下Python默认读写文件是GBK编码，Linux是UTF-8。我在Windows上本地清洗评论数据时，导出的CSV用Excel打开正常，但传到Linux上Spark读入后全是乱码，中文变成了"锟斤拷"。排查方法其实很简单：在IDE里强制指定文件读取编码为UTF-8。另外，我在代码里所有打开文件的地方都显式传encoding='utf-8'，不依赖系统默认编码。

第二个环境问题是路径分隔符。Windows用反斜杠，Linux用正斜杠，如果代码里写死了\，上传到Linux可能直接找不到文件。建议所有HDFS路径和本地临时路径都用os.path.join或正斜杠拼接。

第三个环境问题是依赖库版本不一致。Windows上jieba、pandas等库版本是和模型训练时一致的，但Linux服务器上的版本可能不同，导致分词结果和模型预测出现差异。后来我用conda env export > environment.yml在开发机导出了完整依赖，在服务器上用conda env create -f environment.yml重建环境，再通过--py-files dependencies.zip把定制依赖打进Spark任务，这个问题才彻底解决。

6. 效果复盘与架构迁移：这套系统真的只能用来做二手评论吗

6.1 准确率从68%到87%的关键动作清单

整个项目做完，我最想分享的其实是这个从68%到87%的优化过程，它代表了一条完全可复制的路径。

第一个关键动作是引入领域词典。通用情感词典在二手评论上的覆盖率不到60%，大量平台黑话识别不了。加入300多条领域词条后，负面评论召回率从60%升到了73%，提升非常明显。

第二个关键动作是处理否定词和程度副词。一开始词典打分是把所有情感词简单相加，遇到"不划算""不太满意"这类表达会把情感完全判反。用了否定词翻转之后，模型对负面评论的识别能力又上一个台阶。

第三个关键动作是emoji映射。二手评论里用户特别喜欢用表情来表达情绪，单独统计emoji情感得分，让中性-负面边界上的样本判断准确了不少。

第四个关键动作是模型升级。从朴素贝叶斯换成逻辑回归，并加入文本长度、感叹号数量等统计特征后，准确率从79%一路提到了87%。在Spark MLlib里，这套Pipeline跑100万条评论约3分钟，速度完全可接受。

我把几个版本的指标整理成了一个表格，方便大家对比参考：

6.2 同理迁移：外卖评论、视频弹幕、电商评论都能套这套架构

这个项目的架构并不是只能用在二手交易评论上。情感分析的数据链路，本质上是"海量文本 -> 分布式存储 -> 分布式计算 -> Web展示"这套模式，把它抽出来，可以快速迁移到其他场景。

比如外卖平台的评论分析。外卖评论的特点是"出餐速度""骑手态度""包装"这类领域词特别多，只要把二手领域的黑话词典替换成外卖领域词表，再标注一批外卖评论数据重新训练模型，其余代码几乎不用改。

再比如视频弹幕的情感分析。弹幕数据的最大区别是实时性强，如果要做秒级情感趋势，就不能等到第二天跑批，要把Spark批处理换成Spark Streaming或者Flink流处理，Web大屏改成WebSocket实时推送。但底层的情感词典、特征工程、Django接口设计完全可以复用。

还有新闻舆论监测这类场景，核心同样是"抓取文本 -> 情感判断 -> 趋势展示"，区别在于需要加入更严谨的时间戳管理和敏感词过滤。对刚接触Hadoop+Spark的同学来说，把二手评论这个项目吃透，后面再去做其他文本分析类项目会顺手很多，因为最容易踩的环境坑、数据坑、模型坑，在这个项目里基本都能遇到一遍。

最后再分享一点体会。做完这个项目，我最大的感受是：情感分析项目的核心瓶颈从来不在模型，而在数据和词典。模型选型来回试了两天就搞定了，但领域词典和清洗规则前后磨了一周。如果你也想做类似项目，建议把精力重点放在数据理解和领域词条上，模型用成熟的逻辑回归或者朴素贝叶斯就足够上线。另外一个心得是Hadoop+Spark这套重架构不要为了用而用，日新增评论量没有到几十万条、没有历史数据做趋势分析的需求，老老实实用MySQL加scikit-learn会更实在。但一旦数据量上来，这就是一套值得投入的稳定方案。