1. 这个毕设选题为什么值得做大数据和 AI Agent 是目前计算机专业毕业设计的两个热点方向但很多同学在选题时会陷入两个极端。要么只做 Hadoop 数据分析从头到尾跑 WordCount、写 Hive SQL、出几张可视化图表技术栈完整但缺少亮点要么只做 AI Agent调用大模型接口做一个聊天机器人演示效果不错但算法和工程含量不足答辩时容易被问住。这个题目“基于 Hadoop 与 AI Agent 的西藏旅游数据分析及智能规划系统”本质上是把两个热点叠加成了一个复合型项目用 Hadoop 生态解决旅游数据的存储、清洗、分析和挖掘用 AI Agent 解决基于分析结果的智能行程规划。它不是简单的“Hadoop 大模型接口”拼接而是让 Agent 的规划逻辑建立在数据分析结果之上形成完整的数据闭环。从实际执行角度看这个项目最大的优势是好落地、可展示、有故事线。你可以在论文里写“基于 HDFS 的旅游数据存储设计”“基于 Hive/Spark 的游客行为分析”“基于大模型与检索增强的智能行程生成”每一章都有真实的技术内容支撑。答辩时可以从数据层、计算层、应用层三层展开比单一技术栈的题目有更多可讲的东西。这篇文章会直接给出一个可行的 7 天开发方案包括技术选型、系统架构、数据建模、Agent 设计思路、核心代码示例和常见问题排查。无论你最终选择 Hadoop 还是 Spark 作为计算引擎都可以按照这套思路落地。2. 技术选型先判断哪些组件是必须的毕业设计和企业项目不一样。企业项目追求稳定、可扩展、多人协作毕业设计追求的是完整跑通、技术点覆盖、逻辑自洽。所以选型的第一原则不是“用的组件越多越好”而是“每个组件都能解释清楚为什么存在”。2.1 必须保留的核心组件这个项目的核心链路是数据采集 - 数据存储 - 数据清洗 - 数据分析 - Agent 规划 - 结果展示。围绕这条链路建议保留以下组件层组件解决的问题是否必须存储层HDFS海量旅游数据的分布式存储是计算层MapReduce 或 Spark离线批处理分析二选一数据仓库HiveSQL 化分析降低开发成本建议保留检索层Elasticsearch为 Agent 提供结构化检索建议保留Agent 层大模型 API Python生成智能旅游规划是展示层Flask/FastAPI EChartsWeb 可视化与交互是2.2 选 Hadoop 还是 Spark这是很多同学第一个纠结的问题。如果题目要求里明确写了 Hadoop那就用 Hive MapReduce 完成离线分析。MapReduce 写起来确实繁琐但正因为繁琐反而更容易在论文里体现你对分布式计算原理的理解。Hive 用来写类 SQL 分析语句MapReduce 用来处理 Hive 不方便表达的逻辑。如果题目只写了“大数据”那更推荐 Spark。Spark 的 DataFrame API 写起来比 MapReduce 舒服很多而且天然支持 Python不需要额外学 Java。在数据量不大的毕业设计场景下Spark 的部署成本也不比 Hadoop 高多少。从热搜词来看“hadoop和zookeeper整合实战”“hadoop伪分布式搭建”“hadoop hive hdfs安装”是高频搜索内容说明 Hadoop 环境的搭建确实是多数人的痛点。这篇文章后面会用专门章节说清楚伪分布式环境的搭建思路。2.3 为什么需要 Elasticsearch很多人会问数据都在 Hive 里直接用 SQL 查不就行了为什么还要引入 Elasticsearch这里的关键在于 Agent 的使用方式不同。Hive 擅长的是批量统计比如“计算每个景点每月的游客量”但 Agent 在生成行程规划时需要的是实时、灵活的检索。比如用户说“我想去拉萨和林芝喜欢自然风光只有四天时间”Agent 需要快速检索出拉萨和林芝的景点列表、推荐游玩时长、最佳出行月份、附近住宿分布。这些信息如果每次都在 Hive 里跑一个 SQL响应时间不可接受。合理的做法是离线数据分析结果写入 ElasticsearchAgent 通过 ES 的 REST API 做实时检索。这也对应了热搜词里“ai agent 通过 es rest api 智能分析日志”的方向本质上是检索增强生成RAG的简化实现。2.4 大模型 API 的选择Agent 的规划能力需要依赖大模型。国内可用的大模型 API 选择比较多从开发便利角度建议选支持 OpenAI 兼容接口的模型服务这样代码可以复用同一套调用逻辑。需要注意毕业设计中使用外部 API 有两个风险一是可能产生费用二是答辩现场可能会断网。建议在代码设计上做一个模型服务抽象层支持本地规则模式和大模型模式切换。如果现场网络不稳定可以切换到基于规则和检索的简化版本保证演示不翻车。3. 系统架构与数据流设计一个清晰的项目必须先有清晰的架构而不是一上来就写代码。这个项目的架构图可以用文字先描述清楚画图时再用对应工具的图例表达。3.1 整体分层架构系统分为五层数据源层西藏旅游公开数据、景点 POI 数据、游客评论数据、天气数据。毕业设计不要求实时数据可以下载公开数据集或用脚本模拟生成。存储与分析层原始数据上传 HDFSHive 建外表进行 SQL 分析分析结果导出到 MySQL 或 Elasticsearch。服务层Python Web 后端Flask/FastAPI提供数据分析查询接口、用户交互接口、Agent 规划接口。Agent 层接收用户需求进行意图解析调用 ES 检索景点/住宿/交通信息组装 Prompt调用大模型生成行程规划。展示层前端页面用 ECharts 展示景点热度分析、游客画像、时间趋势用聊天交互界面展示智能规划结果。3.2 数据流向说明完整的数据流向是这样的数据采集脚本 - HDFS - Hive 清洗/分析 - MySQL/Elasticsearch ^ | 用户输入需求 - Agent 规划器 - ES 检索 LLM 生成 - 前端展示这里最容易被忽视的是“数据血缘”。建议在论文和项目中明确标注每个数据文件从哪个来源采集、经过了哪些清洗步骤、最终被哪个模块消费。Hive 表命名建议带上时间分区方便增量更新。3.3 为什么这个架构是合理的从材料看大数据毕业设计最常见的扣分点有三个一是“只有 Hive SQL没有自己的代码”二是“代码只是调用接口没有工程含量”三是“各个模块之间没有数据关联”。这套架构恰好能规避这三个问题。第一数据采集和清洗是 Python 代码分析层是 Hive/Spark SQL服务层是 Web 接口Agent 层是自定义规划逻辑每层都有代码量而且都是你亲手写的。第二Agent 的检索依赖于 ES 中的分析结果不是凭空生成。比如系统先统计出“旺季热门景点 TOP10”Agent 在规划路线时就会优先安排这些景点并提示用户错峰出行。第三数据从 HDFS 到 Hive 到 ES 到 Agent 再到前端是一条完整链路答辩时可以顺着数据流讲完整个项目逻辑非常清晰。4. 数据模型设计旅游数据应该怎么组织4.1 数据来源说明西藏旅游数据没有统一的公开数据集实际开发时需要组合多个来源景点基础信息包括景点名称、所在城市、经纬度、门票价格、建议游玩时长、景点类型自然/人文/宗教/徒步等可以从旅游平台公开信息整理。游客评论与评分从社交媒体或旅游平台抓取公开评论数据或者使用模拟数据。月度游客量数据文旅部门公开的统计数据或者基于公开报道整理。交通与住宿信息城市间距离、车程估算、住宿点位分布。需要注意爬取数据时只使用公开可访问的信息遵守平台规则不要碰需要登录权限的数据。如果实在找不到合适数据源可以写一个模拟数据生成脚本在论文中说明数据为模拟数据。4.2 Hive 表结构设计建议在 Hive 中建立如下核心表-- 景点基础信息表 CREATE EXTERNAL TABLE IF NOT EXISTS tourism.tb_attraction ( attraction_id STRING COMMENT 景点ID, attraction_name STRING COMMENT 景点名称, city STRING COMMENT 所在城市, attraction_type STRING COMMENT 景点类型, longitude DOUBLE COMMENT 经度, latitude DOUBLE COMMENT 纬度, ticket_price DOUBLE COMMENT 门票价格, suggest_hours DOUBLE COMMENT 建议游玩时长(小时), description STRING COMMENT 景点介绍 ) COMMENT 西藏旅游景点基础信息表 ROW FORMAT DELIMITED FIELDS TERMINATED BY \t STORED AS TEXTFILE LOCATION /user/hive/warehouse/tourism.db/tb_attraction;-- 游客访问行为事实表 CREATE EXTERNAL TABLE IF NOT EXISTS tourism.tb_visit_log ( visit_id STRING COMMENT 访问记录ID, user_id STRING COMMENT 游客ID, attraction_id STRING COMMENT 景点ID, visit_date STRING COMMENT 访问日期 yyyy-MM-dd, stay_hours DOUBLE COMMENT 停留时长(小时), rating INT COMMENT 评分 1-5, comment_content STRING COMMENT 评论内容 ) COMMENT 游客访问行为事实表 PARTITIONED BY (dt STRING COMMENT 分区字段) ROW FORMAT DELIMITED FIELDS TERMINATED BY \t STORED AS TEXTFILE LOCATION /user/hive/warehouse/tourism.db/tb_visit_log;为什么用外部表因为外部表删除表结构时不会删除 HDFS 上的数据对毕业设计来说更安全。如果 Hive 建表语句写错了只需要删表重建不需要重新上传数据。4.3 数据结构设计的三个关键点第一数据类型要符合实际数据。比如经纬度必须是 DOUBLE评分用 INT如果使用 STRING 会导致后续分析函数报错或结果失真。第二必须有分区字段。旅游数据是按天增长的分区字段让 Hive 可以只扫描指定日期的数据避免全表扫描。很多同学在这个地方漏掉分区设计数据量一大就会明显变慢。第三存放格式建议 TEXTFILE 起步。毕业设计数据集不大TEXTFILE 简单直观可以直接在 HDFS 上查看。如果追求性能可以后续改成 Parquet但这部分不是必选项。5. 环境搭建Hadoop 伪分布式与 Hive 安装5.1 伪分布式还是集群很多同学一看到“Hadoop 集群搭建”就慌觉得自己没有多台服务器。实际上毕业设计完全可以使用伪分布式模式。伪分布式意味着你的 Hadoop 各进程NameNode、DataNode、ResourceManager、NodeManager都运行在同一台机器上但配置和原理与集群模式完全一致。从热搜词“hadoop伪分布式搭建”“hadoop和zookeeper整合实战”“hadoop的docker镜像”来看大多数人都是从伪分布式开始的。如果机器配置不足也可以直接用 Docker 启动 Hadoop 镜像但要注意掌握 Docker 和 Hadoop 两层技术的排错能力。5.2 Hadoop 伪分布式搭建步骤以 Linux 环境为例通用步骤如下# 1. 创建 Hadoop 用户 sudo useradd -m hadoop sudo passwd hadoop # 2. 配置 SSH 免密登录 su - hadoop ssh-keygen -t rsa -P -f ~/.ssh/id_rsa cat ~/.ssh/id_rsa.pub ~/.ssh/authorized_keys chmod 600 ~/.ssh/authorized_keys ssh localhost # 3. 下载并解压 Hadoop cd /usr/local sudo tar -zxf hadoop-x.x.x.tar.gz sudo mv hadoop-x.x.x /usr/local/hadoop sudo chown -R hadoop:hadoop /usr/local/hadoop # 4. 配置环境变量~/.bashrc export HADOOP_HOME/usr/local/hadoop export HADOOP_INSTALL$HADOOP_HOME export PATH$PATH:$HADOOP_HOME/bin:$HADOOP_HOME/sbin source ~/.bashrc核心配置文件有两个。文件路径为$HADOOP_HOME/etc/hadoop/core-site.xmlconfiguration property namefs.defaultFS/name valuehdfs://localhost:9000/value /property property namehadoop.tmp.dir/name value/usr/local/hadoop/tmp/value /property /configuration文件路径为$HADOOP_HOME/etc/hadoop/hdfs-site.xmlconfiguration property namedfs.replication/name value1/value /property property namedfs.namenode.name.dir/name value/usr/local/hadoop/tmp/name/value /property property namedfs.datanode.data.dir/name value/usr/local/hadoop/tmp/data/value /property /configuration伪分布式模式下副本数必须设置为 1否则 DataNode 会一直处于副本缺失状态日志里会刷 Under-Replicated Blocks 的告警。5.3 格式化和启动首次启动需要格式化 NameNodehdfs namenode -format start-dfs.sh start-yarn.sh jpsjps命令输出中应该出现NameNode、DataNode、SecondaryNameNode、ResourceManager、NodeManager这五个进程。如果缺少某个进程重点查看对应日志目录下的*.log文件。然后创建 Hive 需要的 HDFS 目录hdfs dfs -mkdir -p /user/hive/warehouse hdfs dfs -mkdir -p /user/hive/tmp hdfs dfs -mkdir -p /user/hive/logs hdfs dfs -chmod -R 777 /user/hive5.4 安装 Hive 时的常见坑Hive 安装最常见的报错是jar does not exist or is not a normal file: /usr/local/hadoop/share/hadoop/m。这个报错的原因是在hive-env.sh中配置HADOOP_HOME时路径末尾多了内容或者 Hadoop 安装路径本来就缺失相关目录。解决方法是检查HADOOP_HOME环境变量是否指向正确的 Hadoop 根目录且 Hadoop 安装目录下确实存在share/hadoop/mapreduce等目录。另一个高频问题是 Hive 元数据初始化失败。Hive 3.x 默认使用内置的 Derby 数据库并发访问能力很弱。建议安装 MySQL 作为元数据库并执行schematool -dbType mysql -initSchema如果之前初始化过但中途失败需要先清空 MySQL 中的 metastore 库再重新初始化否则会报Table CTLGS doesnt exist之类的错误。6. 数据采集与清洗脚本实现环境搭好之后第一步先把数据跑通。建议先准备一份模拟数据把 HDFS 上传、Hive 建表、SQL 分析整条链路跑通再考虑补充真实数据。6.1 模拟数据生成脚本文件路径scripts/generate_data.pyimport csv import hashlib import random from datetime import datetime, timedelta attractions [ (A001, 布达拉宫, 拉萨, 人文, 91.117, 29.657, 200.0, 3.0), (A002, 大昭寺, 拉萨, 人文, 91.131, 29.653, 85.0, 1.5), (A003, 纳木错, 拉萨, 自然, 90.716, 30.706, 120.0, 6.0), (A004, 巴松措, 林芝, 自然, 93.917, 30.005, 120.0, 4.0), (A005, 雅鲁藏布大峡谷, 林芝, 自然, 94.213, 29.485, 150.0, 8.0), (A006, 扎什伦布寺, 日喀则, 人文, 88.881, 29.267, 80.0, 2.5), (A007, 珠穆朗玛峰大本营, 日喀则, 自然, 86.925, 28.352, 180.0, 10.0), (A008, 岗仁波齐, 阿里, 宗教, 81.298, 31.074, 150.0, 12.0), ] def generate_visit_logs(days180, daily_visits200): with open(/tmp/visit_logs.tsv, w, encodingutf-8) as f: writer csv.writer(f, delimiter\t) start datetime(2024, 1, 1) for i in range(days): current start timedelta(daysi) # 5-10月为旺季生成更多访问记录 month_factor 1.5 if 5 current.month 10 else 0.6 for _ in range(int(daily_visits * month_factor)): attr random.choice(attractions) user_id hashlib.md5(str(random.random()).encode()).hexdigest()[:8] stay round(random.uniform(attr[7] * 0.7, attr[7] * 1.3), 1) rating random.choices([1, 2, 3, 4, 5], weights[2, 4, 10, 30, 54])[0] writer.writerow([ user_id, attr[0], current.strftime(%Y-%m-%d), stay, rating, f评论内容{random.randint(1, 1000)} ]) if __name__ __main__: generate_visit_logs()这段代码生成 180 天、每天约几百条访问记录的 TSV 文件。字段顺序与前面的 Hive 表结构完全一致可以直接上传。6.2 数据上传 HDFS# 生成数据 python3 scripts/generate_data.py # 上传 HDFS hdfs dfs -mkdir -p /user/hive/warehouse/tourism.db/tb_visit_log hdfs dfs -put /tmp/visit_logs.tsv /user/hive/warehouse/tourism.db/tb_visit_log/dt20241231/6.3 清洗脚本的关键逻辑真实数据比模拟数据脏得多主要包含空值、重复记录、非法字段这三种情况。清洗建议用 Python 做一层预处理核心逻辑如下def clean_visit_log(raw_row): # 字段完整性校验 if not raw_row or len(raw_row) ! 6: return None user_id, attraction_id, visit_date, stay, rating, comment raw_row # 日期格式校验 try: datetime.strptime(visit_date, %Y-%m-%d) except ValueError: return None # 数值范围校验 if not (0 float(stay) 24): return None if not (1 int(rating) 5): return None return raw_row清洗逻辑不复杂但在论文里一定要写清楚“清洗规则”的定义比如空值率高于多少的字段直接丢弃、重复记录按哪个字段去重、异常值按什么标准替换。这些规则是答辩时展示工程能力的重要素材。7. 数据分析以热门景点趋势分析为例数据进入 Hive 后就可以开始做分析了。这里给出两个最核心的分析案例。7.1 按月统计热门景点访问量USE tourism; SELECT t.attraction_name, substr(v.visit_date, 1, 7) AS year_month, COUNT(*) AS visit_cnt, ROUND(AVG(v.stay_hours), 1) AS avg_stay_hours, ROUND(AVG(v.rating), 2) AS avg_rating FROM tb_visit_log v JOIN tb_attraction t ON v.attraction_id t.attraction_id WHERE v.dt 20241231 GROUP BY t.attraction_name, substr(v.visit_date, 1, 7) ORDER BY visit_cnt DESC;这个 SQL 的结果可以直接用于前端柱状图、折线图和热力图的展示。7.2 分析结果导出到 Elasticsearch分析结果要供 Agent 检索需要写入 ES。这里直接用 Python 的elasticsearch客户端from elasticsearch import Elasticsearch es Elasticsearch([http://localhost:9200]) # 创建索引 index_mapping { mappings: { properties: { attraction_name: {type: keyword}, city: {type: keyword}, attraction_type: {type: keyword}, ticket_price: {type: double}, suggest_hours: {type: double}, month: {type: keyword}, visit_cnt: {type: integer}, avg_rating: {type: double} } } } es.indices.create(indexattraction_stats, bodyindex_mapping, ignore400)写入数据时要注意 ES 的字段类型和 Hive 的保持一致特别是数值类型。如果字段类型不一致会导致 ES 端聚合查询报错。8. AI Agent 规划模块设计8.1 Agent 架构设计这个项目的 Agent 不应该是“一问一答”的聊天机器人而是一个有固定处理流程的规划器。建议拆成四个模块意图解析器解析用户的出发地、目的地、游玩天数、偏好类型、预算等关键信息。这里既可以用大模型也可以用正则或者简单的关键词匹配。检索器从 Elasticsearch 检索匹配的景点、住宿、交通信息。规划生成器把检索结果组装成结构化 Prompt调用大模型生成行程。校验与格式化检查生成结果是否包含必要字段格式化输出。8.2 规划器核心代码文件路径agent/travel_planner.pyimport json import re from elasticsearch import Elasticsearch class TravelPlanner: def __init__(self, es_hosthttp://localhost:9200, llm_funcNone): self.es Elasticsearch([es_host]) self.llm_func llm_func # 大模型调用函数可替换 def parse_intent(self, user_input): 解析用户需求返回结构化查询条件 days re.search(r(\d)天, user_input) city_names [拉萨, 林芝, 日喀则, 阿里, 山南, 那曲, 昌都] cities [c for c in city_names if c in user_input] type_map {自然: 自然, 人文: 人文, 宗教: 宗教, 徒步: 徒步} intent { days: int(days.group(1)) if days else 3, cities: cities, prefer_types: [t for k, t in type_map.items() if k in user_input], budget: None, } return intent def search_attractions(self, intent): 根据条件到 ES 检索景点 must_conditions [] if intent[cities]: must_conditions.append({terms: {city: intent[cities]}}) if intent[prefer_types]: must_conditions.append({terms: {attraction_type: intent[prefer_types]}}) if not must_conditions: must_conditions.append({match_all: {}}) body { query: {bool: {must: must_conditions}}, sort: [{visit_cnt: {order: desc}}], size: 10 } resp self.es.search(indexattraction_stats, bodybody) return [hit[_source] for hit in resp[hits][hits]] def generate_plan(self, user_input): 完整规划流程 intent self.parse_intent(user_input) attractions self.search_attractions(intent) if self.llm_func: prompt self._build_prompt(intent, attractions) plan_text self.llm_func(prompt) return self._format_output(plan_text) else: return self._rule_based_plan(intent, attractions) def _build_prompt(self, intent, attractions): return json.dumps({ 用户需求: intent, 可安排景点: attractions, 任务: 根据用户游玩天数和偏好生成一份每日行程规划包含景点、交通时长和建议出发时间 }, ensure_asciiFalse) def _rule_based_plan(self, intent, attractions): 无大模型时的降级方案 days intent[days] per_day max(1, len(attractions) // days) plan {} for d in range(1, days 1): plan[f第{d}天] [a[attraction_name] for a in attractions[(d-1)*per_day:d*per_day]] return plan def _format_output(self, plan_text): 格式化输出 return plan_text这段代码有一个非常关键的工程设计llm_func是一个可注入的函数有模型时走大模型生成没模型时自动降级到规则规划。这个降级方案在答辩演示时可以救你一命。8.3 为什么 Agent 依赖 ES 而不是直接查 Hive从交互角度看用户发起一个规划请求到返回结果应该在秒级完成。Hive SQL 每次执行都需要启动 YARN 任务冷启动可能需要几十秒完全无法支撑交互式请求。ES 的检索响应通常在毫秒到几十毫秒而且支持复杂的条件组合、排序和聚合。这就是“数据分析”和“智能规划”衔接的关键设计离线批量计算交给 Hive在线实时检索交给 ElasticsearchAgent 做衔接层。9. 七天开发计划与进度安排很多人看到 7 天会觉得时间紧张实际上如果按下面这个节奏推进是完全来得及的。第 1 天环境搭建安装 Hadoop、Hive、Elasticsearch、Python Web 框架跑通jps验证 Hadoop 进程。这一步是纯环境问题卡住就用日志排查不要在一个问题上耗太久。第 2 天数据准备与存储写模拟数据生成脚本把数据上传 HDFS创建 Hive 外部表验证 SELECT 语句能否正常执行。第 3 天数据分析完成核心的 Hive SQL 分析任务包括分月统计、热门景点排行、游客停留时长分析、评分分布等把结果导出到 ES。第 4 天ES 检索验证与后端开发验证 ES 索引和查询接口搭建 Flask/FastAPI 项目实现数据查询接口。第 5 天Agent 规划模块实现意图解析、ES 检索、Prompt 组装、降级方案加上 Web 接口。第 6 天前端展示与联调用 ECharts 做数据可视化页面把 Agent 规划结果嵌入聊天式界面联调完整流程。第 7 天测试、修复与文档完整走一遍演示流程修复小 Bug写论文项目实现章节录制演示视频。注意这 7 天计划不包含论文撰写的大部分时间。如果论文还没开始写建议多预留 3 到 5 天专门写论文和整理答辩 PPT。10. 常见问题与排查方法问题现象可能原因排查方式解决方案jps没有 DataNode 进程NameNode 格式化后 DataNode 的 clusterID 不一致查看$HADOOP_HOME/logs下 datanode 日志停止进程删除hadoop.tmp.dir重新格式化并启动Hive 执行 SQL 报Table not found建表时数据库名写错或外部表 LOCATION 路径不对执行SHOW TABLES;和DESCRIBE TABLE;确认当前数据库检查 HDFS 路径是否存在jar does not exist or is not a normal file: /usr/local/hadoop/share/hadoop/mHADOOP_HOME配置错误或 Hadoop 目录结构不完整检查echo $HADOOP_HOME和ls $HADOOP_HOME/share/hadoop修正环境变量重新解压完整 HadoopElasticsearch 写入失败typestrict_dynamic_mapping_exception文档中出现了索引映射中未定义的字段查看报错中的字段名在 mapping 中加入对应字段定义或删除该字段ES 聚合查询结果类型不匹配Hive 导出的数值字段被 ES 识别为 text查询_mapping确认字段类型重建索引并设置正确的数值类型Agent 调用大模型接口超时网络不稳定或 Prompt 过长设置超时时间打印请求日志增加超时重试缩短 Prompt或切换降级方案前端图表空白后端接口返回为空或字段名不一致用浏览器 F12 查看接口返回校准前后端字段命名统一 camelCase 或 snake_case11. 答辩要点与扩展方向11.1 答辩时重点讲什么答辩时间通常只有 10 到 15 分钟不要从头到尾讲代码。建议按三个亮点组织第一个亮点是“数据链路完整性”。强调系统不是单纯调用大模型而是“真实的数据分析结果”驱动 Agent 规划。可以拿出一个具体的分析结果比如“纳木错在 7-9 月访问量最高平均停留 6 小时”然后展示 Agent 在规划那曲线路时把这个信息纳入行程考虑。第二个亮点是“工程降级设计”。说明 Agent 模块做了模型服务抽象断网时可以用规则模式兜底。这能体现你对系统可用性的思考。第三个亮点是“技术选型的理由”。解释为什么用 ES 做在线检索、用 Hive 做离线分析让老师看到你理解每种工具的适用边界。11.2 可扩展方向如果时间充裕可以考虑做这些扩展在 HDFS 上做数据分层管理引入 ODS/DWD/ADS 分层让数据仓库设计更规范。在 Agent 中使用 LangChain 或其他框架增加工具调用和记忆功能。前端接入地图组件把规划的行程显示在地图上。增加用户登录和行程收藏功能让系统更完整。但需要提醒的是扩展功能不要贪多。毕业设计的评分重点永远是“完整度”和“逻辑自洽”。一个跑通的完整系统比一个半成品的复杂系统得分更高。11.3 写在最后的话这个题目能覆盖的考点很多HDFS 存储原理、Hive SQL 分析、大模型 Prompt 设计、RAG 检索、Web 开发、前后端联调。整个项目做完你的简历上可以写“基于 Hadoop 生态构建旅游数据分析平台通过 Elasticsearch 检索增强实现 AI 旅游规划 Agent”这句话在找大数据开发或 AI 应用开发岗位时是有含金量的。建议先把环境搭好、跑通一条最小链路再逐步加功能。每一步都做验证不要等到最后一天才联调。把这篇文档的章节拆成任务清单每天完成一项7 天下来一个能演示、能答辩、能写进论文的完整项目就落地了。 基于Hadoop与AI Agent的西藏旅游数据分析及智能规划系统
1. 这个毕设选题为什么值得做大数据和 AI Agent 是目前计算机专业毕业设计的两个热点方向但很多同学在选题时会陷入两个极端。要么只做 Hadoop 数据分析从头到尾跑 WordCount、写 Hive SQL、出几张可视化图表技术栈完整但缺少亮点要么只做 AI Agent调用大模型接口做一个聊天机器人演示效果不错但算法和工程含量不足答辩时容易被问住。这个题目“基于 Hadoop 与 AI Agent 的西藏旅游数据分析及智能规划系统”本质上是把两个热点叠加成了一个复合型项目用 Hadoop 生态解决旅游数据的存储、清洗、分析和挖掘用 AI Agent 解决基于分析结果的智能行程规划。它不是简单的“Hadoop 大模型接口”拼接而是让 Agent 的规划逻辑建立在数据分析结果之上形成完整的数据闭环。从实际执行角度看这个项目最大的优势是好落地、可展示、有故事线。你可以在论文里写“基于 HDFS 的旅游数据存储设计”“基于 Hive/Spark 的游客行为分析”“基于大模型与检索增强的智能行程生成”每一章都有真实的技术内容支撑。答辩时可以从数据层、计算层、应用层三层展开比单一技术栈的题目有更多可讲的东西。这篇文章会直接给出一个可行的 7 天开发方案包括技术选型、系统架构、数据建模、Agent 设计思路、核心代码示例和常见问题排查。无论你最终选择 Hadoop 还是 Spark 作为计算引擎都可以按照这套思路落地。2. 技术选型先判断哪些组件是必须的毕业设计和企业项目不一样。企业项目追求稳定、可扩展、多人协作毕业设计追求的是完整跑通、技术点覆盖、逻辑自洽。所以选型的第一原则不是“用的组件越多越好”而是“每个组件都能解释清楚为什么存在”。2.1 必须保留的核心组件这个项目的核心链路是数据采集 - 数据存储 - 数据清洗 - 数据分析 - Agent 规划 - 结果展示。围绕这条链路建议保留以下组件层组件解决的问题是否必须存储层HDFS海量旅游数据的分布式存储是计算层MapReduce 或 Spark离线批处理分析二选一数据仓库HiveSQL 化分析降低开发成本建议保留检索层Elasticsearch为 Agent 提供结构化检索建议保留Agent 层大模型 API Python生成智能旅游规划是展示层Flask/FastAPI EChartsWeb 可视化与交互是2.2 选 Hadoop 还是 Spark这是很多同学第一个纠结的问题。如果题目要求里明确写了 Hadoop那就用 Hive MapReduce 完成离线分析。MapReduce 写起来确实繁琐但正因为繁琐反而更容易在论文里体现你对分布式计算原理的理解。Hive 用来写类 SQL 分析语句MapReduce 用来处理 Hive 不方便表达的逻辑。如果题目只写了“大数据”那更推荐 Spark。Spark 的 DataFrame API 写起来比 MapReduce 舒服很多而且天然支持 Python不需要额外学 Java。在数据量不大的毕业设计场景下Spark 的部署成本也不比 Hadoop 高多少。从热搜词来看“hadoop和zookeeper整合实战”“hadoop伪分布式搭建”“hadoop hive hdfs安装”是高频搜索内容说明 Hadoop 环境的搭建确实是多数人的痛点。这篇文章后面会用专门章节说清楚伪分布式环境的搭建思路。2.3 为什么需要 Elasticsearch很多人会问数据都在 Hive 里直接用 SQL 查不就行了为什么还要引入 Elasticsearch这里的关键在于 Agent 的使用方式不同。Hive 擅长的是批量统计比如“计算每个景点每月的游客量”但 Agent 在生成行程规划时需要的是实时、灵活的检索。比如用户说“我想去拉萨和林芝喜欢自然风光只有四天时间”Agent 需要快速检索出拉萨和林芝的景点列表、推荐游玩时长、最佳出行月份、附近住宿分布。这些信息如果每次都在 Hive 里跑一个 SQL响应时间不可接受。合理的做法是离线数据分析结果写入 ElasticsearchAgent 通过 ES 的 REST API 做实时检索。这也对应了热搜词里“ai agent 通过 es rest api 智能分析日志”的方向本质上是检索增强生成RAG的简化实现。2.4 大模型 API 的选择Agent 的规划能力需要依赖大模型。国内可用的大模型 API 选择比较多从开发便利角度建议选支持 OpenAI 兼容接口的模型服务这样代码可以复用同一套调用逻辑。需要注意毕业设计中使用外部 API 有两个风险一是可能产生费用二是答辩现场可能会断网。建议在代码设计上做一个模型服务抽象层支持本地规则模式和大模型模式切换。如果现场网络不稳定可以切换到基于规则和检索的简化版本保证演示不翻车。3. 系统架构与数据流设计一个清晰的项目必须先有清晰的架构而不是一上来就写代码。这个项目的架构图可以用文字先描述清楚画图时再用对应工具的图例表达。3.1 整体分层架构系统分为五层数据源层西藏旅游公开数据、景点 POI 数据、游客评论数据、天气数据。毕业设计不要求实时数据可以下载公开数据集或用脚本模拟生成。存储与分析层原始数据上传 HDFSHive 建外表进行 SQL 分析分析结果导出到 MySQL 或 Elasticsearch。服务层Python Web 后端Flask/FastAPI提供数据分析查询接口、用户交互接口、Agent 规划接口。Agent 层接收用户需求进行意图解析调用 ES 检索景点/住宿/交通信息组装 Prompt调用大模型生成行程规划。展示层前端页面用 ECharts 展示景点热度分析、游客画像、时间趋势用聊天交互界面展示智能规划结果。3.2 数据流向说明完整的数据流向是这样的数据采集脚本 - HDFS - Hive 清洗/分析 - MySQL/Elasticsearch ^ | 用户输入需求 - Agent 规划器 - ES 检索 LLM 生成 - 前端展示这里最容易被忽视的是“数据血缘”。建议在论文和项目中明确标注每个数据文件从哪个来源采集、经过了哪些清洗步骤、最终被哪个模块消费。Hive 表命名建议带上时间分区方便增量更新。3.3 为什么这个架构是合理的从材料看大数据毕业设计最常见的扣分点有三个一是“只有 Hive SQL没有自己的代码”二是“代码只是调用接口没有工程含量”三是“各个模块之间没有数据关联”。这套架构恰好能规避这三个问题。第一数据采集和清洗是 Python 代码分析层是 Hive/Spark SQL服务层是 Web 接口Agent 层是自定义规划逻辑每层都有代码量而且都是你亲手写的。第二Agent 的检索依赖于 ES 中的分析结果不是凭空生成。比如系统先统计出“旺季热门景点 TOP10”Agent 在规划路线时就会优先安排这些景点并提示用户错峰出行。第三数据从 HDFS 到 Hive 到 ES 到 Agent 再到前端是一条完整链路答辩时可以顺着数据流讲完整个项目逻辑非常清晰。4. 数据模型设计旅游数据应该怎么组织4.1 数据来源说明西藏旅游数据没有统一的公开数据集实际开发时需要组合多个来源景点基础信息包括景点名称、所在城市、经纬度、门票价格、建议游玩时长、景点类型自然/人文/宗教/徒步等可以从旅游平台公开信息整理。游客评论与评分从社交媒体或旅游平台抓取公开评论数据或者使用模拟数据。月度游客量数据文旅部门公开的统计数据或者基于公开报道整理。交通与住宿信息城市间距离、车程估算、住宿点位分布。需要注意爬取数据时只使用公开可访问的信息遵守平台规则不要碰需要登录权限的数据。如果实在找不到合适数据源可以写一个模拟数据生成脚本在论文中说明数据为模拟数据。4.2 Hive 表结构设计建议在 Hive 中建立如下核心表-- 景点基础信息表 CREATE EXTERNAL TABLE IF NOT EXISTS tourism.tb_attraction ( attraction_id STRING COMMENT 景点ID, attraction_name STRING COMMENT 景点名称, city STRING COMMENT 所在城市, attraction_type STRING COMMENT 景点类型, longitude DOUBLE COMMENT 经度, latitude DOUBLE COMMENT 纬度, ticket_price DOUBLE COMMENT 门票价格, suggest_hours DOUBLE COMMENT 建议游玩时长(小时), description STRING COMMENT 景点介绍 ) COMMENT 西藏旅游景点基础信息表 ROW FORMAT DELIMITED FIELDS TERMINATED BY \t STORED AS TEXTFILE LOCATION /user/hive/warehouse/tourism.db/tb_attraction;-- 游客访问行为事实表 CREATE EXTERNAL TABLE IF NOT EXISTS tourism.tb_visit_log ( visit_id STRING COMMENT 访问记录ID, user_id STRING COMMENT 游客ID, attraction_id STRING COMMENT 景点ID, visit_date STRING COMMENT 访问日期 yyyy-MM-dd, stay_hours DOUBLE COMMENT 停留时长(小时), rating INT COMMENT 评分 1-5, comment_content STRING COMMENT 评论内容 ) COMMENT 游客访问行为事实表 PARTITIONED BY (dt STRING COMMENT 分区字段) ROW FORMAT DELIMITED FIELDS TERMINATED BY \t STORED AS TEXTFILE LOCATION /user/hive/warehouse/tourism.db/tb_visit_log;为什么用外部表因为外部表删除表结构时不会删除 HDFS 上的数据对毕业设计来说更安全。如果 Hive 建表语句写错了只需要删表重建不需要重新上传数据。4.3 数据结构设计的三个关键点第一数据类型要符合实际数据。比如经纬度必须是 DOUBLE评分用 INT如果使用 STRING 会导致后续分析函数报错或结果失真。第二必须有分区字段。旅游数据是按天增长的分区字段让 Hive 可以只扫描指定日期的数据避免全表扫描。很多同学在这个地方漏掉分区设计数据量一大就会明显变慢。第三存放格式建议 TEXTFILE 起步。毕业设计数据集不大TEXTFILE 简单直观可以直接在 HDFS 上查看。如果追求性能可以后续改成 Parquet但这部分不是必选项。5. 环境搭建Hadoop 伪分布式与 Hive 安装5.1 伪分布式还是集群很多同学一看到“Hadoop 集群搭建”就慌觉得自己没有多台服务器。实际上毕业设计完全可以使用伪分布式模式。伪分布式意味着你的 Hadoop 各进程NameNode、DataNode、ResourceManager、NodeManager都运行在同一台机器上但配置和原理与集群模式完全一致。从热搜词“hadoop伪分布式搭建”“hadoop和zookeeper整合实战”“hadoop的docker镜像”来看大多数人都是从伪分布式开始的。如果机器配置不足也可以直接用 Docker 启动 Hadoop 镜像但要注意掌握 Docker 和 Hadoop 两层技术的排错能力。5.2 Hadoop 伪分布式搭建步骤以 Linux 环境为例通用步骤如下# 1. 创建 Hadoop 用户 sudo useradd -m hadoop sudo passwd hadoop # 2. 配置 SSH 免密登录 su - hadoop ssh-keygen -t rsa -P -f ~/.ssh/id_rsa cat ~/.ssh/id_rsa.pub ~/.ssh/authorized_keys chmod 600 ~/.ssh/authorized_keys ssh localhost # 3. 下载并解压 Hadoop cd /usr/local sudo tar -zxf hadoop-x.x.x.tar.gz sudo mv hadoop-x.x.x /usr/local/hadoop sudo chown -R hadoop:hadoop /usr/local/hadoop # 4. 配置环境变量~/.bashrc export HADOOP_HOME/usr/local/hadoop export HADOOP_INSTALL$HADOOP_HOME export PATH$PATH:$HADOOP_HOME/bin:$HADOOP_HOME/sbin source ~/.bashrc核心配置文件有两个。文件路径为$HADOOP_HOME/etc/hadoop/core-site.xmlconfiguration property namefs.defaultFS/name valuehdfs://localhost:9000/value /property property namehadoop.tmp.dir/name value/usr/local/hadoop/tmp/value /property /configuration文件路径为$HADOOP_HOME/etc/hadoop/hdfs-site.xmlconfiguration property namedfs.replication/name value1/value /property property namedfs.namenode.name.dir/name value/usr/local/hadoop/tmp/name/value /property property namedfs.datanode.data.dir/name value/usr/local/hadoop/tmp/data/value /property /configuration伪分布式模式下副本数必须设置为 1否则 DataNode 会一直处于副本缺失状态日志里会刷 Under-Replicated Blocks 的告警。5.3 格式化和启动首次启动需要格式化 NameNodehdfs namenode -format start-dfs.sh start-yarn.sh jpsjps命令输出中应该出现NameNode、DataNode、SecondaryNameNode、ResourceManager、NodeManager这五个进程。如果缺少某个进程重点查看对应日志目录下的*.log文件。然后创建 Hive 需要的 HDFS 目录hdfs dfs -mkdir -p /user/hive/warehouse hdfs dfs -mkdir -p /user/hive/tmp hdfs dfs -mkdir -p /user/hive/logs hdfs dfs -chmod -R 777 /user/hive5.4 安装 Hive 时的常见坑Hive 安装最常见的报错是jar does not exist or is not a normal file: /usr/local/hadoop/share/hadoop/m。这个报错的原因是在hive-env.sh中配置HADOOP_HOME时路径末尾多了内容或者 Hadoop 安装路径本来就缺失相关目录。解决方法是检查HADOOP_HOME环境变量是否指向正确的 Hadoop 根目录且 Hadoop 安装目录下确实存在share/hadoop/mapreduce等目录。另一个高频问题是 Hive 元数据初始化失败。Hive 3.x 默认使用内置的 Derby 数据库并发访问能力很弱。建议安装 MySQL 作为元数据库并执行schematool -dbType mysql -initSchema如果之前初始化过但中途失败需要先清空 MySQL 中的 metastore 库再重新初始化否则会报Table CTLGS doesnt exist之类的错误。6. 数据采集与清洗脚本实现环境搭好之后第一步先把数据跑通。建议先准备一份模拟数据把 HDFS 上传、Hive 建表、SQL 分析整条链路跑通再考虑补充真实数据。6.1 模拟数据生成脚本文件路径scripts/generate_data.pyimport csv import hashlib import random from datetime import datetime, timedelta attractions [ (A001, 布达拉宫, 拉萨, 人文, 91.117, 29.657, 200.0, 3.0), (A002, 大昭寺, 拉萨, 人文, 91.131, 29.653, 85.0, 1.5), (A003, 纳木错, 拉萨, 自然, 90.716, 30.706, 120.0, 6.0), (A004, 巴松措, 林芝, 自然, 93.917, 30.005, 120.0, 4.0), (A005, 雅鲁藏布大峡谷, 林芝, 自然, 94.213, 29.485, 150.0, 8.0), (A006, 扎什伦布寺, 日喀则, 人文, 88.881, 29.267, 80.0, 2.5), (A007, 珠穆朗玛峰大本营, 日喀则, 自然, 86.925, 28.352, 180.0, 10.0), (A008, 岗仁波齐, 阿里, 宗教, 81.298, 31.074, 150.0, 12.0), ] def generate_visit_logs(days180, daily_visits200): with open(/tmp/visit_logs.tsv, w, encodingutf-8) as f: writer csv.writer(f, delimiter\t) start datetime(2024, 1, 1) for i in range(days): current start timedelta(daysi) # 5-10月为旺季生成更多访问记录 month_factor 1.5 if 5 current.month 10 else 0.6 for _ in range(int(daily_visits * month_factor)): attr random.choice(attractions) user_id hashlib.md5(str(random.random()).encode()).hexdigest()[:8] stay round(random.uniform(attr[7] * 0.7, attr[7] * 1.3), 1) rating random.choices([1, 2, 3, 4, 5], weights[2, 4, 10, 30, 54])[0] writer.writerow([ user_id, attr[0], current.strftime(%Y-%m-%d), stay, rating, f评论内容{random.randint(1, 1000)} ]) if __name__ __main__: generate_visit_logs()这段代码生成 180 天、每天约几百条访问记录的 TSV 文件。字段顺序与前面的 Hive 表结构完全一致可以直接上传。6.2 数据上传 HDFS# 生成数据 python3 scripts/generate_data.py # 上传 HDFS hdfs dfs -mkdir -p /user/hive/warehouse/tourism.db/tb_visit_log hdfs dfs -put /tmp/visit_logs.tsv /user/hive/warehouse/tourism.db/tb_visit_log/dt20241231/6.3 清洗脚本的关键逻辑真实数据比模拟数据脏得多主要包含空值、重复记录、非法字段这三种情况。清洗建议用 Python 做一层预处理核心逻辑如下def clean_visit_log(raw_row): # 字段完整性校验 if not raw_row or len(raw_row) ! 6: return None user_id, attraction_id, visit_date, stay, rating, comment raw_row # 日期格式校验 try: datetime.strptime(visit_date, %Y-%m-%d) except ValueError: return None # 数值范围校验 if not (0 float(stay) 24): return None if not (1 int(rating) 5): return None return raw_row清洗逻辑不复杂但在论文里一定要写清楚“清洗规则”的定义比如空值率高于多少的字段直接丢弃、重复记录按哪个字段去重、异常值按什么标准替换。这些规则是答辩时展示工程能力的重要素材。7. 数据分析以热门景点趋势分析为例数据进入 Hive 后就可以开始做分析了。这里给出两个最核心的分析案例。7.1 按月统计热门景点访问量USE tourism; SELECT t.attraction_name, substr(v.visit_date, 1, 7) AS year_month, COUNT(*) AS visit_cnt, ROUND(AVG(v.stay_hours), 1) AS avg_stay_hours, ROUND(AVG(v.rating), 2) AS avg_rating FROM tb_visit_log v JOIN tb_attraction t ON v.attraction_id t.attraction_id WHERE v.dt 20241231 GROUP BY t.attraction_name, substr(v.visit_date, 1, 7) ORDER BY visit_cnt DESC;这个 SQL 的结果可以直接用于前端柱状图、折线图和热力图的展示。7.2 分析结果导出到 Elasticsearch分析结果要供 Agent 检索需要写入 ES。这里直接用 Python 的elasticsearch客户端from elasticsearch import Elasticsearch es Elasticsearch([http://localhost:9200]) # 创建索引 index_mapping { mappings: { properties: { attraction_name: {type: keyword}, city: {type: keyword}, attraction_type: {type: keyword}, ticket_price: {type: double}, suggest_hours: {type: double}, month: {type: keyword}, visit_cnt: {type: integer}, avg_rating: {type: double} } } } es.indices.create(indexattraction_stats, bodyindex_mapping, ignore400)写入数据时要注意 ES 的字段类型和 Hive 的保持一致特别是数值类型。如果字段类型不一致会导致 ES 端聚合查询报错。8. AI Agent 规划模块设计8.1 Agent 架构设计这个项目的 Agent 不应该是“一问一答”的聊天机器人而是一个有固定处理流程的规划器。建议拆成四个模块意图解析器解析用户的出发地、目的地、游玩天数、偏好类型、预算等关键信息。这里既可以用大模型也可以用正则或者简单的关键词匹配。检索器从 Elasticsearch 检索匹配的景点、住宿、交通信息。规划生成器把检索结果组装成结构化 Prompt调用大模型生成行程。校验与格式化检查生成结果是否包含必要字段格式化输出。8.2 规划器核心代码文件路径agent/travel_planner.pyimport json import re from elasticsearch import Elasticsearch class TravelPlanner: def __init__(self, es_hosthttp://localhost:9200, llm_funcNone): self.es Elasticsearch([es_host]) self.llm_func llm_func # 大模型调用函数可替换 def parse_intent(self, user_input): 解析用户需求返回结构化查询条件 days re.search(r(\d)天, user_input) city_names [拉萨, 林芝, 日喀则, 阿里, 山南, 那曲, 昌都] cities [c for c in city_names if c in user_input] type_map {自然: 自然, 人文: 人文, 宗教: 宗教, 徒步: 徒步} intent { days: int(days.group(1)) if days else 3, cities: cities, prefer_types: [t for k, t in type_map.items() if k in user_input], budget: None, } return intent def search_attractions(self, intent): 根据条件到 ES 检索景点 must_conditions [] if intent[cities]: must_conditions.append({terms: {city: intent[cities]}}) if intent[prefer_types]: must_conditions.append({terms: {attraction_type: intent[prefer_types]}}) if not must_conditions: must_conditions.append({match_all: {}}) body { query: {bool: {must: must_conditions}}, sort: [{visit_cnt: {order: desc}}], size: 10 } resp self.es.search(indexattraction_stats, bodybody) return [hit[_source] for hit in resp[hits][hits]] def generate_plan(self, user_input): 完整规划流程 intent self.parse_intent(user_input) attractions self.search_attractions(intent) if self.llm_func: prompt self._build_prompt(intent, attractions) plan_text self.llm_func(prompt) return self._format_output(plan_text) else: return self._rule_based_plan(intent, attractions) def _build_prompt(self, intent, attractions): return json.dumps({ 用户需求: intent, 可安排景点: attractions, 任务: 根据用户游玩天数和偏好生成一份每日行程规划包含景点、交通时长和建议出发时间 }, ensure_asciiFalse) def _rule_based_plan(self, intent, attractions): 无大模型时的降级方案 days intent[days] per_day max(1, len(attractions) // days) plan {} for d in range(1, days 1): plan[f第{d}天] [a[attraction_name] for a in attractions[(d-1)*per_day:d*per_day]] return plan def _format_output(self, plan_text): 格式化输出 return plan_text这段代码有一个非常关键的工程设计llm_func是一个可注入的函数有模型时走大模型生成没模型时自动降级到规则规划。这个降级方案在答辩演示时可以救你一命。8.3 为什么 Agent 依赖 ES 而不是直接查 Hive从交互角度看用户发起一个规划请求到返回结果应该在秒级完成。Hive SQL 每次执行都需要启动 YARN 任务冷启动可能需要几十秒完全无法支撑交互式请求。ES 的检索响应通常在毫秒到几十毫秒而且支持复杂的条件组合、排序和聚合。这就是“数据分析”和“智能规划”衔接的关键设计离线批量计算交给 Hive在线实时检索交给 ElasticsearchAgent 做衔接层。9. 七天开发计划与进度安排很多人看到 7 天会觉得时间紧张实际上如果按下面这个节奏推进是完全来得及的。第 1 天环境搭建安装 Hadoop、Hive、Elasticsearch、Python Web 框架跑通jps验证 Hadoop 进程。这一步是纯环境问题卡住就用日志排查不要在一个问题上耗太久。第 2 天数据准备与存储写模拟数据生成脚本把数据上传 HDFS创建 Hive 外部表验证 SELECT 语句能否正常执行。第 3 天数据分析完成核心的 Hive SQL 分析任务包括分月统计、热门景点排行、游客停留时长分析、评分分布等把结果导出到 ES。第 4 天ES 检索验证与后端开发验证 ES 索引和查询接口搭建 Flask/FastAPI 项目实现数据查询接口。第 5 天Agent 规划模块实现意图解析、ES 检索、Prompt 组装、降级方案加上 Web 接口。第 6 天前端展示与联调用 ECharts 做数据可视化页面把 Agent 规划结果嵌入聊天式界面联调完整流程。第 7 天测试、修复与文档完整走一遍演示流程修复小 Bug写论文项目实现章节录制演示视频。注意这 7 天计划不包含论文撰写的大部分时间。如果论文还没开始写建议多预留 3 到 5 天专门写论文和整理答辩 PPT。10. 常见问题与排查方法问题现象可能原因排查方式解决方案jps没有 DataNode 进程NameNode 格式化后 DataNode 的 clusterID 不一致查看$HADOOP_HOME/logs下 datanode 日志停止进程删除hadoop.tmp.dir重新格式化并启动Hive 执行 SQL 报Table not found建表时数据库名写错或外部表 LOCATION 路径不对执行SHOW TABLES;和DESCRIBE TABLE;确认当前数据库检查 HDFS 路径是否存在jar does not exist or is not a normal file: /usr/local/hadoop/share/hadoop/mHADOOP_HOME配置错误或 Hadoop 目录结构不完整检查echo $HADOOP_HOME和ls $HADOOP_HOME/share/hadoop修正环境变量重新解压完整 HadoopElasticsearch 写入失败typestrict_dynamic_mapping_exception文档中出现了索引映射中未定义的字段查看报错中的字段名在 mapping 中加入对应字段定义或删除该字段ES 聚合查询结果类型不匹配Hive 导出的数值字段被 ES 识别为 text查询_mapping确认字段类型重建索引并设置正确的数值类型Agent 调用大模型接口超时网络不稳定或 Prompt 过长设置超时时间打印请求日志增加超时重试缩短 Prompt或切换降级方案前端图表空白后端接口返回为空或字段名不一致用浏览器 F12 查看接口返回校准前后端字段命名统一 camelCase 或 snake_case11. 答辩要点与扩展方向11.1 答辩时重点讲什么答辩时间通常只有 10 到 15 分钟不要从头到尾讲代码。建议按三个亮点组织第一个亮点是“数据链路完整性”。强调系统不是单纯调用大模型而是“真实的数据分析结果”驱动 Agent 规划。可以拿出一个具体的分析结果比如“纳木错在 7-9 月访问量最高平均停留 6 小时”然后展示 Agent 在规划那曲线路时把这个信息纳入行程考虑。第二个亮点是“工程降级设计”。说明 Agent 模块做了模型服务抽象断网时可以用规则模式兜底。这能体现你对系统可用性的思考。第三个亮点是“技术选型的理由”。解释为什么用 ES 做在线检索、用 Hive 做离线分析让老师看到你理解每种工具的适用边界。11.2 可扩展方向如果时间充裕可以考虑做这些扩展在 HDFS 上做数据分层管理引入 ODS/DWD/ADS 分层让数据仓库设计更规范。在 Agent 中使用 LangChain 或其他框架增加工具调用和记忆功能。前端接入地图组件把规划的行程显示在地图上。增加用户登录和行程收藏功能让系统更完整。但需要提醒的是扩展功能不要贪多。毕业设计的评分重点永远是“完整度”和“逻辑自洽”。一个跑通的完整系统比一个半成品的复杂系统得分更高。11.3 写在最后的话这个题目能覆盖的考点很多HDFS 存储原理、Hive SQL 分析、大模型 Prompt 设计、RAG 检索、Web 开发、前后端联调。整个项目做完你的简历上可以写“基于 Hadoop 生态构建旅游数据分析平台通过 Elasticsearch 检索增强实现 AI 旅游规划 Agent”这句话在找大数据开发或 AI 应用开发岗位时是有含金量的。建议先把环境搭好、跑通一条最小链路再逐步加功能。每一步都做验证不要等到最后一天才联调。把这篇文档的章节拆成任务清单每天完成一项7 天下来一个能演示、能答辩、能写进论文的完整项目就落地了。