企业官网建设流程全解析

1. 这个题目为什么值得做：选题价值与技术选型逻辑

1.1 从“毕业设计要被pass”说起的选题思路

每年到了毕设选题的季节，很多同学来问我：老师给的题目要么是“XX管理系统”，要么是“A算法改进B算法”，前者工作量倒是够，但技术含量稀薄，答辩时很难讲出彩；后者理论性强但落地困难，代码跑不通、数据不知道怎么造。看到“基于Spark+Django的胆结石消化系统疾病数据分析系统”这个组合，我的第一反应是：这是一个把“大数据计算平台、数据分析、机器学习、Web可视化”串成一条完整流水线的好题目，而不是又一个普通的CRUD页面。

这个题目的核心价值在于：Spark负责海量离线数据的清洗、统计和模型训练，Django负责把分析结果以可视化看板的形式对外呈现，再配合机器学习挖掘胆结石发病的潜在风险因素。技术栈完整覆盖了计算机相关专业毕设应该展示的几条能力线：大数据处理、数据挖掘、Web应用开发、前端可视化。对于学生来说，单一技术学起来容易，真正难的是把几个不同层面的技术组合成一个能演示、能截图、能写进论文、能上答辩的系统，而这道题恰好每个环节都能落到实处。

我更建议的是把它当成一个真正的数据分析项目来做，而不是又一个“管理系统”。管理系统只是围绕数据的增删改查，数据分析系统则要求你从数据出发，回答一系列“是什么、为什么、怎么样”的问题。做完之后，你的收获不只是代码，而是建立了一整套数据处理项目的方法论。

1.2 技术组合选型的对比：Spark+Django赢在哪

很多同学在这道题上的第一反应是：为什么不用更常见的Hadoop全家桶？为什么不用Python的pandas加Flask？甚至有人会想，直接用Spring Boot不是更主流吗？我逐一说说对比下来的真实感受。

Hadoop的MapReduce写起来是真繁琐，完成同样一个groupBy统计，代码量可能是Spark的一倍还多。并且本地单机部署HDFS和YARN对Windows用户相当不友好，光环境就能磨掉你一个周末，对毕设节奏来说是巨大的损耗。Spark的优势在于内存计算、RDD/DataFrame抽象、丰富的MLlib算法库、统一的批处理能力，这些概念任何一个都能成为论文中的技术亮点；同时它在local模式下可以单机运行，不需要申请集群，演示时也不会因为资源问题翻车。

那为什么不直接用pandas加Flask？如果数据量控制在几万行，pandas确实够用，代码写起来可能还更快。但毕设的锻炼价值就不太够：论文集里写“分布式计算”“内存计算”根本没有技术支撑，答辩时老师一问“为什么用pandas直接处理”就很难接话。Spark能让你在同样的业务下，用分布式原语去组织计算逻辑，虽然小数据看不出性能优势，但整个工程思维是对的。

Django这边，优势是自带ORM、Admin后台、认证系统，做一个带用户管理的可视化平台非常成熟。相比Flask这种轻量框架，Django把用户系统、数据库迁移、后台管理这些重复劳动都替你准备好了，不用东拼西凑各种第三方库。用Django REST Framework写数据接口也很快。于是整个分工就变得非常清晰：Spark是计算引擎，Django是应用外壳，两者通过结果表和接口解耦。

还要考虑一个现实约束：很多学校要求毕设本地演示，学生手上没有企业级集群。Spark在local模式下跑，数据量也不需要真的到PB级，但“数据流水线”“分布式计算思维”是完整的。选技术栈不是越复杂越好，而是在可用性和亮点之间取平衡，这个组合性价比很高。

1.3 这个系统能交付什么：功能边界与使用场景

把使用场景说清楚，整个项目才不会做成“为了技术而技术的玩具”。可以设定系统面向公共卫生、医院信息科、健康管理中心，是一个疾病数据的分析辅助工具。使用者登录后看到的是：胆结石疾病的整体概览、不同年龄和性别的分布、地域与季节趋势、饮食习惯与发病关联的柱状图，以及基于历史病例构建的患病风险评估工具。

具体来说，评估工具就是让用户输入年龄、性别、BMI、是否有高脂饮食习惯、胆囊结石家族史、血脂指标这些特征，系统返回“是否属于高风险人群”以及对应的概率值。这一步把机器学习从训练演示变成真正可交互的应用，演示效果非常好。

功能边界上，我建议做成一个范围可控的系统：登录注册、数据看板、筛选条件、风险预测、历史记录管理。这个范围不大不小，每个模块都能做出东西，又不至于让人在毕业前熬出黑眼圈。特别要注意的是，系统定位是辅助分析和科研演示，不是临床诊断工具。这个定位不仅是伦理要求，答辩时也能体现出你的工程谨慎度。

2. 系统整体架构与数据流转

2.1 三层架构：数据、服务、展示各管一段

设计这个系统时，我建议坚持经典的三层架构，虽然听起来不新鲜，但它确实让分工最干净。数据层用MySQL或PostgreSQL存Django的业务数据，同时Spark读取并处理疾病原始数据。计算层是Spark作业，负责ETL、统计分析和机器学习模型训练。应用层是Django，通过REST接口把数据返回给前端展示。

前端有两种选择：一种是Django模板直接渲染加ECharts，另一种是Vue或者React完全前后端分离。我推荐前者，理由很实际：模板渲染不用处理跨域，也不用维护两套工程，对毕设体量来说体验差异不大，但复杂度能降不少。ECharts作为图表库仍然是首选，社区资料多，示例改一改就能用，柱状图、折线图、饼图、热力图的运维成本都很低。

架构里有一个必须提前想清楚的约定：Spark的统计结果不要让Django现场去算。如果用户每点一次筛选就提交一个Spark作业，接口响应可能要到几十秒，演示的时候很容易翻车。更合理的模式是：先离线跑完Spark作业把结果写入MySQL或者Redis缓存，Web层只是读这些现成的统计结果。用户刷新页面时，看到的是最近一次Spark作业的产出。在大数据可视化平台中这也是常见模式，跟“数仓分层加工、应用层取数”是一个思路。

2.2 核心模块拆解：从可视化看板到风险预测

一个能落地的模块清单大致如下。

用户管理模块：基于Django自带的User模型，完成注册登录、密码修改和简单的角色区分，达到“有用户概念、有权限保护”这个程度就够了，不要在这里过度设计。

数据概览模块：展示样本总量、男女比例、年龄均值、患病人数与比例、病例覆盖的省份数量等核心指标卡片，用几个大数字配合趋势图，第一眼就很专业。

疾病分布分析模块：从胆结石部位（胆囊结石、胆总管结石、肝内胆管结石）、结石数量（单发/多发）、是否合并胆囊炎等维度做统计，让分析不是笼统的“患病率”，而是能深入看结构。

因素关联模块：统计年龄、性别、BMI、饮食习惯、家族史、血脂等变量与患病率的交叉关系，用堆积柱状图、饼图和热力图呈现，这是数据挖掘最常见的表达方式。

时间趋势模块：按年份或季度观察发病率变化，设置折线图，同时展示发病的季节分布，给系统增加时间维度的纵深。

智能评估模块：用户录入个人基本信息，后端加载训练好的Spark评估模型，返回风险等级和概率值，同时列出主要影响因子。这是机器学习的落地出口，也是答辩时最亮的功能。

这个模块分布保证系统不是空架子。每张图背后都有一个明确的Spark统计逻辑，每个模块在论文里都能独立成节。

2.3 全链路数据流转：从原始数据到图表显示

把数据流转串起来理解，整条流水线是：原始数据文件以CSV或JSON格式存在磁盘中；Spark读取后执行清洗标准化，得到干净的数据表；Spark继续做统计分析，把聚合结果写入MySQL统计表；同时Spark用历史病例训练分类模型，把模型保存到本地模型文件；Django接收前端请求，从统计表读取数据生成JSON返回给页面；最后ECharts绘图展示。用户在预测页面提交特征后，Django加载已保存的模型文件做预测返回。

这条链路每一步都清晰独立，出现问题也好排查：原始数据脏了看清洗环节，统计对不上看聚合逻辑，接口报错看Django查询语句，图表不显示看前端字段名是否匹配。论文里画数据流图的时候，依照这个顺序梳理，条理自然就出来了，老师看你的逻辑也会觉得舒服。

我实际带过身边的人做这类系统，最容易翻车的是中间对接环节：Spark算出的结果不知道存到哪个表，前端拿到的字段名和Spark输出对不上。建议一开始就约定好统计表的维度和指标字段命名，再写代码，能省下大量联调时间。

3. 数据准备与预处理：工程量的百分之四十在这

3.1 胆结石数据从哪来：公开统计、脱敏样本与模拟生成

第一件让人头疼的事就是数据。“我没有医疗数据怎么办”是这个问题最常见的开场白。千万不要想着去碰真实医院数据，学生拿不到，也最好不要碰，这里面有隐私和合规风险，一旦出事不是小事。可行的路径有三条：一是公开的疾病统计资料和健康年报，可以手工整理成结构化表格；二是健康医疗类的公开数据集平台和科研模拟数据；三是根据胆结石流行病学特征，自己写模拟数据生成器。

模拟生成数据是很多人的实际选择，这里要遵循已知的医学分布规律：年龄越大发病率总体越高，女性发病率高于男性，肥胖人群和高脂饮食人群偏高，合并糖尿病、高血压的人群风险更大。按照这些规律加一点随机扰动，就能生成3万到10万条看起来比较真实的数据。字段要覆盖十五个以上，这样Spark的处理能力和机器学习样本量都说得过去。

论文里必须诚实标注数据来源和合成方式，比如“模拟数据+公开统计特征生成，不对应任何真实个体”。很多同学怕承认是模拟数据会扣分，实际上不会，老师反而觉得你处理隐私的意识到位了。真实数据造假、数据来源说不清楚才是最致命的。

3.2 字段怎么设计才够建模用：可以直接照抄的数据字典

字段的医学意义直接决定后续分析角度和模型效果。我建议基础字段这样设计。

• patient_id：病例唯一标识，去重用
• gender：性别，男/女
• age：年龄，数值型
• bmi：体重指数，数值型
• diet_high_fat：是否高脂饮食习惯，是/否
• exercise_freq：每周锻炼次数，数值型
• smoking_status：是否吸烟，是/否
• drinking_status：是否饮酒，是/否
• family_history：胆囊结石家族史，是/否
• hypertension：是否合并高血压，是/否
• diabetes：是否合并糖尿病，是/否
• triglyceride：甘油三酯，mmol/L数值型
• total_cholesterol：总胆固醇，mmol/L数值型
• stone_location：结石部位，胆囊/胆总管/肝内胆管
• stone_count：结石数量，单发/多发
• is_symptomatic：是否有症状，是/否
• diagnosis：是否患胆结石，是/否，这就是监督学习的标签

每一个字段都能派上用场。连续字段用于统计和模型输入，分类字段用于交叉分析和哑变量编码。我还建议加一个diagnosis_year字段，因为按年份统计发病趋势几乎必用。有了这套数据字典，清洗、统计、建模才谈得上有依据，而不是拿到什么算什么。

3.3 Spark清洗与特征工程：DataFrame API实操代码

原始数据拿到手之后，清洗是第一关。如果用PySpark来清洗，可以这样起手。初始化SparkSession时注意设置local运行参数，避免在Windows下不断崩溃。

from pyspark.sql import SparkSession from pyspark.sql.functions import col spark = SparkSession.builder \ .appName("gallstone_etl") \ .master("local[*]") \ .config("spark.sql.shuffle.partitions", "10") \ .getOrCreate() df = spark.read.option("header", True).csv("data/gallstone_raw.csv") df = df.dropDuplicates(["patient_id"]) median_age = df.approxQuantile("age", [0.5], 0.01)[0] df = df.fillna({"age": median_age}) df = df.fillna({"family_history": "未知", "smoking_status": "未知"}) df = df.filter((col("bmi") >= 10) & (col("bmi") <= 50)) df.write.mode("overwrite").parquet("data/gallstone_clean.parquet")

有人会问：这些操作用pandas几行就能完成，为什么非要用Spark？关键在于你写的是分布式的transform算子，不是对内存里的数据直接循环，这个思维方式正是Spark的核心。当数据量从几万行扩大到百万、千万行时，pandas读入内存可能直接OOM，Spark可以分批处理。毕设系统设计里写明这个技术选型理由，深度就体现出来了，不是白上框架。

另外，清洗阶段一定要把输出的parquet文件统一管理好。后续所有统计和模型训练都从parquet读取，不要每次重复读原始CSV再清洗一遍，效率差而且容易让数据口径不一致。

3.4 特征分箱与编码：让模型真正读懂医学变量

胆结石发病和年龄之间通常不是简单的线性关系。如果把age直接丢给模型，模型只能学到一个粗糙的线性趋势，分箱处理会更合适：小于30岁、30到39岁、40到49岁、50到59岁、60岁及以上，每个年龄段作为一个特征维度。BMI也按偏瘦、正常、超重、肥胖分箱。分箱后的变量模型更容易学到趋势，做图表统计时也天然形成分组。

分类字段的编码同样重要。性别直接映射为0和1；高脂饮食、吸烟、饮酒、家族史这些二分类字段全部映射为0和1；结石部位这种多分类字段可以采用独热编码。Spark里可以用StringIndexer配合OneHotEncoder，也可以为了方便，直接用UDF映射。

训练之前最后一步，是把处理好的特征全部组装成一个向量。Spark MLlib的惯例是用VectorAssembler把所有特征列合成一个features列，标签列单独存放。这一步看着简单，但非常容易因为特征列类型不一致而报错，建议组装前先确认每个字段的类型都是数值型，字符串字段全部完成编码。

4. 核心功能实现：Django、Spark结果落库与可视化接口

4.1 项目结构规划与数据模型

Django项目结构建议这样规划，后续维护起来不混乱：

analysis_system/ manage.py config/ # Django项目配置，settings/urls/wsgi system/ # 主业务应用 models.py # 数据模型 views.py # 视图函数 urls.py # 路由 services.py # 业务逻辑，读取统计表 data_loader/ # Spark作业脚本目录 templates/ static/

models.py里需要建立的业务表主要包括用户扩展表、分析结果表、预测记录表。用户扩展表跟Django自带的User做一对一关联即可。分析结果表是Spark与Django衔接的关键，它不用设计得很复杂，只要有维度、分类、指标名、指标值和年份这几个字段，前端要柱状图还是饼图都能从这个表查出数据。预测记录表用来记录用户每次风险预测的输入特征和模型输出，加上时间戳，用来展示系统实际的预测历史。

这里要慎重考虑的是：业务表和分析结果表分开，不要把Spark统计结果硬塞到和业务表耦合的模型里。各管各的，重构时才不会互相踩脚。

4.2 Spark统计结果如何落到Django能用

设计一个简单的统计作业：统计不同性别与患病率的关系。Spark端使用groupBy做聚合，再转换为Python列表，通过数据库连接写入MySQL结果表。

gender_stats = clean_df.groupBy("gender").agg( count("patient_id").alias("total_count"), avg("diagnosis").alias("rate") ).collect() for row in gender_stats: # 将统计结果写入 analysis_result 表 insert_sql = f""" INSERT INTO analysis_result(dimension, category, metric_name, metric_value) VALUES ('gender', '{row['gender']}', 'total_count', {row['total_count']}) """

实际开发时，可以写一个独立的Python脚本跑这类Spark作业，Django完全不参与运算过程。这个模式的好处非常明显：Django对Spark没有强依赖，Spark作业可以离线跑，跑完再刷新结果；如果未来需要每天更新数据，只要做一个定时调度触发器，业务代码不用改。演示时，内存压力也小得多，因为Web进程里不常驻Spark环境。

有些同学会想，是不是可以用Spark连接器把结果直接写到Redis，Django读Redis更快。如果可以搞定Redis，当然更好，但MySQL一张结果表对毕设来说已经足够，而且答辩时讲数据库设计更讨喜，简单可靠优先。

4.3 可视化看板接口与ECharts联动

Django写数据接口非常顺手。一个趋势图接口可以做成这样：

from django.http import JsonResponse from .models import AnalysisResult def trend_data(request): records = AnalysisResult.objects.filter(dimension="year").order_by("category") categories = [r.category for r in records] values = [float(r.metric_value) for r in records] return JsonResponse({"categories": categories, "values": values})

前端模板引入ECharts，然后用fetch请求这个接口，把categories和values放进option里渲染折线图。为了支持筛选，可以加dimension、gender、age_group这些查询参数，前端做下拉联动，每次选择后重新请求接口，图表能实现交互式下钻。

这里有个容易忽略的坑：尽可能不要把全部维度数据一股脑塞给前端。页面首次加载时只请求当前屏幕需要展示的图表数据，其他图表在需要时再异步请求。毕竟一次展示十几张图，每张图几千个数据点，前端渲染会有明显卡顿。可以在ECharts配置中加dataZoom，对超长的时间序列做缩放展示，体验立刻提升。

4.4 机器学习预测模块：Spark MLlib建模全流程

这部分是整个系统的技术高潮，也是答辩时最值得讲的模块。用Spark训练一个胆结石风险模型，标准流程是：准备特征向量与标签、划分训练集和测试集、选择算法、训练、评估、保存模型、在Django里加载并预测。

以逻辑回归为例，训练代码大致如下：

from pyspark.ml.feature import VectorAssembler from pyspark.ml.classification import LogisticRegression from pyspark.ml.evaluation import BinaryClassificationEvaluator feature_cols = ["gender_int", "age", "bmi", "diet_high_fat", "family_history", "exercise_freq", "triglyceride", "total_cholesterol"] assembler = VectorAssembler(inputCols=feature_cols, outputCol="features") data_vec = assembler.transform(clean_df).select("features", "diagnosis") train, test = data_vec.randomSplit([0.8, 0.2], seed=42) lr = LogisticRegression(featuresCol="features", labelCol="diagnosis", regParam=0.1) model = lr.fit(train) pred = model.transform(test) evaluator = BinaryClassificationEvaluator(labelCol="diagnosis") print("AUC:", evaluator.evaluate(pred)) model.write().overwrite().save("models/gallstone_lr_model")

模型要接到Django里，有几种做法。直接把PySpark引入Django进程通常不是好主意，启动Java虚拟机比较重，和Django线程一起容易出现冲突。推荐方式是写一个独立脚本加载模型，接收前端传来的特征做预测，预测结果再返回到视图层。也可以把MLlib模型导出成PMML格式，用更轻量的工具加载。毕设阶段，独立调用脚本已经足够，答辩时把这个设计思路讲清楚，老师只会觉得你考虑得周到。

5. 模型训练与调优：从“能跑”到“能讲”

5.1 选逻辑回归还是随机森林：医疗数据的模型对比

胆结石风险预测是一个典型的二分类问题。逻辑回归训练快、可解释性强，能给每个特征一个明确的系数，用来展示“哪个因素对发病贡献大”这种结论非常好用。随机森林则能处理非线性关系和特征交互，数据量足够时精度通常更高，缺点是可解释性弱一些。

如果毕设里只做一种模型，答辩压力会比较大。我建议至少训练三个模型做对比：逻辑回归、随机森林、梯度提升树。对比实验是论文里非常加分的部分，用一张表格列出AUC、准确率、召回率、F1分数，并解释差异的来源。

在模拟数据场景下，逻辑回归AUC能到0.8左右比较正常，随机森林能到0.85以上也合理。如果AUC直接超过0.98，反而要怀疑数据模拟是不是过度理想化，因为真实世界的疾病风险因素不可能有这么强的判别能力。答辩时被问到这一点，提前有准备会加分。

5.2 三个参数决定模型质量：调优实操

新手最常见的做法是拿到模型直接fit，然后用默认参数宣称训练完成。这样做不是不可以，但论文里的“模型优化”章节会显得很空。我建议每个模型重点调几个核心参数：逻辑回归看regParam正则化系数和maxIter迭代次数；随机森林看numTrees树的数量和maxDepth最大深度；梯度提升树看maxIter和stepSize学习率。

调参用交叉验证最正规。Spark的CrossValidator配合ParamGridBuilder可以自动搜索参数网格。训练时设置numFolds为5，从一个较小的网格开始，比如随机森林numTrees取50和100，maxDepth取6和10。跑完之后打印最优参数，再到测试集评估。这段代码量不大，但论文里的“模型优化”章节就有实际内容了。

实操提醒一句：不要一上来就搞大网格。本地机器上一个包含几十组参数的交叉验证可能要跑几个小时，得不偿失。先用部分数据做参数预演，确定稳定性后，再用全量数据训练。

5.3 评估指标怎么选：不要只看准确率

医疗数据场景有一个经典误区：如果正样本只占总体的20%甚至更低，模型只预测“不患病”，准确率也可能有80%以上，看起来不错，实际没有任何筛查价值。所以评估时至少要拿出混淆矩阵来看。

对胆结石筛查来说，漏掉一个高风险患者的代价远大于一次误报，所以相比准确率，召回率更重要，AUC更能反映模型把患病样本排在前面、健康样本排在后面的能力。论文中可以同时列出五折交叉验证后的平均AUC和召回率，并解释：我们希望把真正可能患胆结石的群体尽量识别出来，再进一步分析风险因素，而不是追求一个全对但没用的结果。

另一个容易踩的坑是训练集和测试集划分。直接用randomSplit可能导致测试集中正负样本比例和整体不一致，评估值波动很大。可以用分层抽样保证正负比例一致，或者用CrossValidator自带的分层能力。这是模型可靠性的一大关键点。

5.4 特征重要性解释：让答辩老师眼前一亮

随机森林模型可以直接输出featureImportances，这对系统是一个很有价值的产出。在模拟数据场景下，通常bmi、age、diet_high_fat、family_history会排在前列，这与医学常识相符。把这些特征重要性做横向条形图，放在系统的“模型分析”页面上，再配一段描述文字，说明这个结果仅反映数据层面的统计相关性，不构成因果结论。

逻辑回归的系数也能提供另一种解释视角：正系数代表风险因素，负系数代表保护性因素。两种解释相互印证，论文的模型分析章节深度立刻就不一样。答辩时如果老师问“你的模型发现了什么”，你就可以从容地从特征重要性讲起，再联系到疾病预防手段，比如控制体重、调整饮食结构、关注家族史人群，体现分析和业务结合的能力。

6. 实操排坑与答辩准备：我踩过的坑希望你别踩

6.1 环境版本问题：Java、Spark、Python三件套怎么配

这个组合最大的坑在环境。PySpark对Java版本和Spark版本有严格的兼容关系，很多同学照着教程装完，一跑就报Java版本不支持。建议选择比较稳的版本组合：Java 8或Java 11配合Spark 3.x系列，Python 3.8以上，尽量用Anaconda建独立环境，不要直接装系统Python里。Windows本机跑Spark还需要设置HADOOP_HOME和winutils文件，否则会报缺少本地库，这个问题要提前处理。

Django和PySpark可以在同一个虚拟环境里，但调试时最好分开：Spark作业单独跑，Django单独启动。不要试图在Django进程里现场创建SparkSession，很容易出现线程冲突和内存问题。项目规模不大时，两边独立反而更清晰。

6.2 本地跑不动大数据集怎么办

很多人用的是16G内存的笔记本，如果Spark作业直接读取几百万行数据做全量操作，很容易内存溢出。应对技巧是先用sample数据验证整个流程，再把全量数据处理分成阶段执行，每个中间结果持久化到磁盘。

SparkSession的内存参数不要盲目调大，要结合物理机内存设置。比如机器内存16G，可以设置spark.driver.memory=4g、spark.executor.memory=4g，再留一部分给系统和其他进程。如果数据量仍然太大，论文里主动写清楚“考虑到演示环境资源限制，使用抽样数据验证全链路，算法可扩展至集群环境”，这话在毕设里完全说得过去，老师也明白真实集群资源有限。

我还建议所有清洗后的中间结果都先落成parquet文件，因为parquet列式存储比CSV小不少，而且Spark读它速度更快。不要在内存里反复计算，那是本地小数据留下的坏习惯。

6.3 接口超时与图表卡顿的优化方案

演示时最怕出现的场景是：老师点了一个筛选按钮，页面转圈半天没反应。除了前面提到的预先计算模式，还可以从三个方向做优化。

第一，ECharts图表不要一次渲染几千个点。时间序列一定要加dataZoom，或者只展示TopN的数据聚合结果。第二，Django返回JSON时不要直接序列化QuerySet，先把数据转成列表和字典再序列化，能省下不少时间。第三，增加维度的时候用前端联动，下拉选择后才请求接口，不要把所有维度一次性塞进页面里。这三个优化做完，页面流畅度会有明显提升，演示效果也更稳妥。

还有一个容易忽略的小细节：图表数据请求失败时要有兜底提示。演示现场网络或数据库偶发抖动很正常，一个不报错、自动重试的接口比什么都重要。

6.4 答辩高频问题与应答思路

整理几个高频答辩问题和建议的应答思路。

第一个，“为什么选择Spark而不是Hadoop？”。可以从开发效率、内存计算、MLlib集成三方面回答，再补充Hadoop生态可以把HDFS保留为存储层的选型说明。

第二个，“你的数据是真实的吗？”。务必如实说明是公开统计与模拟数据结合，并强调隐私合规。坦白说比试图含糊回答要好得多。

第三个，“模型如何在线上使用？”。核心回答是离线训练、模型持久化、在线加载预测。把整条链路说明白，老师就知道你确实理解部署环节。

第四个，“如果换成真实临床数据，系统需要做什么改造？”。从数据脱敏、字段映射、重新训练模型三个角度回答。这表现出你具备把项目延伸到真实场景的思考能力，而不是只在玩具数据上跑了一圈。

我个人做完这类项目的体会是：硬啃框架版本兼容问题是最不值得的损耗，但也是最容易卡住人的环节；选题的真正难度其实不在技术，而在能不能把数据、模型、业务逻辑讲成一个完整的故事。最后再分享一个小技巧：别急着写前端，先把所有Spark统计结果在浏览器里用最简单的表格输出来，确认数据没问题再开始画图，能帮你省下至少一周的返工时间。