目录
一、项目背景：把健康数据真正用起来
二、数据处理：从原始表到可分析数据
三、可视化分析：让指标结果变成页面
四、风险预测：把模型接入实际页面
五、系统功能：用户端和管理端都保留下来
六、开发实现：从脚本到系统的落地过程
七、项目亮点与适合展示的方向
每文一语
有需要本项目的代码、文档、完整资源，或者需要部署调试的朋友，可以私信博主。
图 1 系统主题封面展示
一、项目背景
心脏病相关风险因素并不是单一指标能够解释清楚的。年龄、BMI、吸烟饮酒习惯、既往中风情况、身体和心理健康天数、睡眠时长、肾病、哮喘、皮肤癌等变量，都可能在不同人群中形成交叉影响。最开始做这个系统时，我希望它不只是一个“输入几个字段然后给出结果”的小工具，而是能把数据采集、清洗、分布式分析、可视化展示和机器学习预测完整串起来，形成一套能看、能管、能预测的健康数据应用。
项目围绕心脏病风险预测场景展开，数据来源采用公开健康调查类数据集，样本量约 31 万条，字段覆盖个人基本信息、生活习惯、一般健康状态以及是否被诊断为心脏病等内容。单独把这些数据放在表格中，价值并不直观；只有经过清洗、统计、建模和系统化展示，才能看到不同变量背后隐藏的规律，也才能把模型预测结果放到一个可交互的页面中使用。
所以我在设计时采用了“大数据处理 + 机器学习 + Web 可视化”的组合路线：前面用 Hadoop 生态完成数据上传、存储和指标分析，中间用 MySQL 承接分析结果和业务数据，后面用 Flask、Echarts、HTML、CSS、JavaScript 做系统页面，再把训练好的模型挂载到在线预测模块里。这样一来，系统既有数据分析展示，也有可操作的后台管理，还能支持用户根据个人健康信息进行风险评估。
图 2 系统技术路线与数据流转
二、数据处理
原始数据并不能直接进入分析和建模流程。项目首先对字段名称、字段类型、重复记录、缺失情况进行了统一处理，将原始英文变量整理为更适合后续 Hive 分析和模型训练的结构化数据。清洗后的数据保留了心脏病状态、BMI、吸烟、饮酒、中风、身体健康天数、心理健康天数、行走困难、性别、年龄段、种族、糖尿病、体育活动、一般健康状况、睡眠时长、哮喘、肾病、皮肤癌等核心字段。
在数据预处理部分，我没有把处理逻辑做成一次性的手工操作，而是通过 notebook 和脚本把流程记录下来，方便后续复现。数据经过清洗后，再通过 Flume 监听目录的方式流入 HDFS，避免一次性 load 大文件带来的内存压力。进入 Hadoop 后，Hive 负责按主题进行统计分析，例如心脏病数量分布、不同状态下 BMI 均值、吸烟饮酒与心脏病比例、中风或行走困难与心脏病的关联等。
Hive 分析结果最终通过 Sqoop 导出到 MySQL。这样设计的好处是前端系统不需要直接面对 Hadoop 复杂环境，只要读取 MySQL 中已经整理好的指标结果，就能完成页面展示和数据管理。整个流程把离线分析和在线系统解耦，既保留了大数据处理能力，也让 Web 端的响应更加轻量。
图 3 项目资源结构概览
图 4 清洗后数据字段与样例记录
三、可视化分析
可视化部分主要围绕用户真正关心的问题展开：样本中心脏病诊断状态占比如何，不同心脏病状态下的 BMI 是否存在差异，吸烟人群和非吸烟人群中心脏病比例有什么变化，中风经历与心脏病状态之间是否呈现明显差别。这些内容如果只用 SQL 结果表呈现，阅读门槛较高；通过柱状图、饼图、堆叠图等方式展示后，趋势会更清楚。
项目中将 EDA 分析结果拆成多个单页可视化文件，并在系统左侧菜单中按照“心脏病相关分析、吸烟相关分析、饮酒相关分析、行走困难相关分析、中风相关分析”等主题进行组织。用户进入主界面后，可以通过导航切换不同图表，页面展示效果更接近一个完整的数据分析看板，而不是孤立的几张图片。
从展示结果看，数据中未诊断心脏病的样本占比较高，类别分布存在明显不均衡；已诊断心脏病样本的平均 BMI 略高；吸烟、中风等变量在比例图中也呈现出值得关注的差异。这些结果并不是直接作为医学结论使用，而是为后续风险预测模型提供特征理解和页面展示依据。
图 5 心脏病相关可视化指标展示
图 6 系统可视化工作台展示
四、风险预测
预测模块是这个系统比较核心的部分。清洗后的数据具备典型的二分类建模条件，目标变量为是否诊断为心脏病，输入变量则来自个人健康状态和生活习惯字段。建模阶段尝试了 CatBoost、LightGBM 等集成学习模型，并针对类别不平衡问题对直接训练、上采样、SMOTENC 过采样、欠采样等策略进行了对比。
在原始数据分布下，模型整体准确率较高，但少数类召回偏弱，这也是医疗风险预测场景中很常见的问题：大多数样本属于低风险或未诊断状态，模型容易倾向于预测多数类。为了提高对潜在风险样本的识别能力，项目引入了数据平衡处理，并对模型效果进行对比。展示层面只保留关键指标和模型思路，完整训练过程、参数细节和源代码没有放在页面中展开。
在线预测页面采用表单输入方式，用户可以填写 BMI、身体不健康天数、心理不健康天数、睡眠时长等数值字段，也可以通过下拉框选择吸烟、饮酒、中风、性别、年龄段、一般健康状况、肾病等类别字段。提交后，后端会把输入内容组装成模型需要的 DataFrame，再调用保存好的模型文件进行预测，最后返回“是否可能患心脏病”和对应置信度。
图 7 模型训练效果与类别不平衡处理思路
图 8 CatBoost 与 LightGBM 特征重要性展示
图 9 在线风险预测页面与结果展示
五、系统功能
前端页面没有只做单一预测表单，而是保留了一个较完整的 Web 系统结构。用户侧包含登录、注册、个人信息查看与修改、密码修改、主题切换、便签、全屏展示、左侧导航切换等功能。进入系统后，用户可以在可视化分析页面和在线预测页面之间切换，整体体验更接近一个完整的健康数据分析平台。
管理端主要负责用户管理和源数据管理。管理员可以查看用户列表，对用户信息进行增删改查，也可以将普通用户升级为管理员；在源数据管理页面，可以按心脏病状态、吸烟情况、皮肤癌情况等条件筛选数据，并对记录进行维护。虽然这些功能在实际上线时还需要进一步补充权限校验、日志审计和安全加固，但对于毕业设计和项目展示来说，已经能体现完整的业务闭环。
为了避免公开页面中出现真实账号、邮箱、电话、服务器地址、数据库密码等敏感内容，展示图中均使用演示账号或遮挡信息。项目源码中的数据库连接、接口地址等内容适合在部署交付时单独配置，不建议直接出现在公开文章或截图中。
图 10 登录与注册入口展示
图 11 管理后台与源数据管理展示
六、开发实现
这个项目的实现过程大致可以分成四步。第一步是数据准备，通过数据预处理脚本完成字段规范化、重复值处理和结构整理；第二步是 Hadoop 分析，配置 HDFS、Hive、Flume、Sqoop 等组件，把数据从本地文件流入分布式存储，再通过 Hive SQL 生成分析结果；第三步是模型训练，用清洗后的数据进行特征工程和模型对比，保存可供后端调用的模型文件；第四步是 Web 系统整合，把可视化页面、模型预测接口和后台管理功能接入 Flask。
页面层面使用的是较常见的前后端组合：后端路由负责登录、注册、用户信息、数据管理、预测接口等请求处理；前端使用 Layui、Echarts、HTML、CSS 和 JavaScript 实现页面布局、表格交互和图表展示。对于可视化页面，项目提前生成单页 HTML 文件，再嵌入系统菜单；对于模型预测，前端收集字段后提交到接口，由后端读取模型并返回 JSON 结果。
从资源完整性来看，压缩包中同时包含原始数据、清洗后数据、Hadoop 脚本、Flume 配置、Hive 相关文件、模型文件、notebook、Flask 项目、前端静态资源、SQL 文件和可视化结果。后续如果继续完善，可以把配置项统一迁移到环境变量中，把接口改成更规范的 REST 风格，再增加模型版本管理、预测记录留存、异常输入校验和可解释性展示。
七、项目亮点与适合展示的方向
这套系统最值得展示的地方，是它没有停留在单一算法实验，而是把数据处理、指标分析、模型训练、在线预测、后台管理都串联起来。对学习大数据和机器学习应用开发的同学来说，它覆盖了一个完整项目中常见的关键环节：数据从哪里来，如何清洗，如何进入 Hadoop，如何通过 Hive 统计指标，如何把结果落入数据库，如何做可视化，如何训练模型，又如何让模型在页面中真正跑起来。
文章中展示的是可公开部分，重点放在系统效果、技术路线和功能模块。完整资源中还包括数据处理脚本、模型训练 notebook、数据库脚本、后端接口、前端页面以及可视化文件，适合继续做课程设计、毕业设计、项目二次开发和部署演示。实际使用时，只需要根据本地环境重新配置数据库、Python 依赖和 Hadoop 组件，就可以进一步调试。
如果后续扩展，我会优先补三块内容：一是增加预测记录和用户历史评估功能，让用户能看到多次评估变化；二是加入 SHAP 或特征贡献解释，把模型结果解释得更清楚；三是做一个更集中的综合大屏，把所有主题分析统一到一个页面中。这样系统不仅能完成展示，也能进一步向实际健康数据分析平台靠近。
每文一语
把一个想法做成能运行、能展示、能复用的系统，本身就是最好的成长记录。
)
