Hadoop+AI Agent:西藏旅游数据分析与智能规划系统实战 如果你正在准备大数据方向或 AI 方向的毕业设计又不想只做一个“调包展示型 Demo”那这次的系统应该很适合参考基于 Hadoop 与 AI Agent 的西藏旅游数据分析及智能规划系统。它不是单纯写一个爬虫也不是只调一个大模型接口而是把大数据采集、存储、清洗、分析、可视化再加上一层 AI Agent 对话式行程规划串成完整链路。从材料看这类系统在课设、毕设里非常典型数据源明确、技术栈偏工程、有可视化界面、有交互能力还能作为“大数据 AI Agent”复合型项目写进简历。硬件门槛也不算高伪分布式 Hadoop 集群在 8GB 内存的笔记本上就能跑后期可以平滑迁移到云服务器或 Docker 环境。整篇文章我会按“核心能力、场景边界、环境准备、部署启动、数据链路、Agent 规划、接口批量任务、资源观察、常见问题、最佳实践”来展开尽量把部署思路和验证方法写具体。1. 核心能力速览这个系统的核心定位是面向旅游领域的数据分析与智能规划平台。底层用 Hadoop 体系做数据存储与离线分析上层用 AI Agent 编排对话、检索、推荐和行程规划能力。下面用一张表快速概括。能力项说明系统类型大数据分析 AI 智能规划综合系统核心组件Hadoop HDFS、Hive、Spark可选、Python、FastAPI/Flask、大模型 API数据链路数据采集 - 数据清洗 - HDFS 存储 - Hive/Spark 分析 - 可视化 - Agent 推荐规划主要功能西藏旅游数据分析、景点热度分析、游客偏好分析、智能行程规划、多轮对话推荐部署方式Hadoop 伪分布式、Docker可选、本地 Python 服务和 Web 前端是否支持 API支持后端提供 REST API 供前端和第三方调用是否支持批量任务支持可批量导入数据和批量生成规划方案硬件门槛伪分布式建议 8GB 内存以上单机可跑通完整链路显存要求无硬性要求Agent 推理走云端或本地大模型 API不强制 GPU适合场景毕业设计、课程设计、大数据综合实训、旅游数据分析项目从功能结构看这个系统最大的价值不是“某一段代码有多难”而是把 Hadoop 生态、数据分析、可视化、AI 智能体这四个模块完整打通。读者拿到这套思路后可以快速替换数据源和技术组件迁移到其他行业场景。2. 适用场景与使用边界2.1 适合谁、能解决什么问题这类系统最适合以下三类读者大数据方向毕业生。项目覆盖 Hadoop、Hive、Spark、可视化等核心关键词适合写进简历。AI Agent 方向初学者。不需要从头训练大模型只需要把大模型 API、工具调用、业务规则编排起来。旅游行业数据从业者。如果手里有公开景区数据可以借鉴数据分析和行程规划模块。它能解决的问题也很明确把零散旅游数据统一存储到 HDFS解决“数据放在多个 Excel 和数据库里”的问题。用 Hive SQL 或 Spark 做离线分析得到景点热度、淡旺季分布、用户偏好等结论。用 AI Agent 把“用户提问 - 数据检索 - 景点推荐 - 行程编排”串起来比静态查询更接近真实需求。2.2 不适合做什么这个项目的定位是“毕业设计级工程”不是“生产级高并发平台”。如果目标是支撑千万级日活的旅游 App那需要换成实时计算框架、分布式数据库、微服务治理架构复杂度会高很多。另外如果只想做模型训练不想碰 Hadoop 部署那这套系统明显偏重工程集成不一定合适。2.3 数据合规与版权边界旅游数据可能涉及景区客流、用户评论、酒店价格等。做毕设时要注意三点尽量使用公开统计数据和模拟数据不要爬取包含个人隐私的评论和订单数据。如果数据集来自第三方平台需要确认授权范围不能直接用于商用。AI Agent 生成行程建议时只做信息聚合和推荐不要替代专业旅游机构做出风险承诺。3. 环境准备与前置条件3.1 操作系统与资源要求Hadoop 本身是跨平台的但伪分布式部署在 Linux 上最省心。如果你只有 Windows 笔记本优先用 WSL2 或 Docker 搭 Hadoop避免环境变量和权限问题。内存建议至少 8GB因为 NameNode、DataNode、ResourceManager 加在一起会占用不少内存。我建议的最小环境清单如下项目最低要求操作系统Ubuntu 20.04/22.04、CentOS 7、WSL2 均可内存8GB伪分布式最低建议磁盘至少 30GB 可用空间JDKJDK 8 或 JDK 11视 Hadoop 版本而定HadoopHadoop 3.xHiveHive 3.xPythonPython 3.8数据库MySQL 5.7 或 8.0存分析结果和用户信息大模型 API需要一个可调用的 LLM API 或本地模型服务3.2 端口规划Hadoop 和 Hive 默认占用的端口较多部署前先检查冲突组件默认端口NameNode WebUI9870Hadoop 3.xDataNode9864YARN ResourceManager8088Hive Metastore如需9083HiveServer210000Flask/FastAPI 后端8000 或 5000如果端口被占用可以手动改配置文件也可以用ss -lntp或netstat -lntp检查。3.3 SSH 免密登录伪分布式模式下建议配置本机 SSH 免密登录避免每次启动服务都卡在密码输入上。通用命令如下ssh-keygen -t rsa -P -f ~/.ssh/id_rsa cat ~/.ssh/id_rsa.pub ~/.ssh/authorized_keys chmod 600 ~/.ssh/authorized_keys4. 安装部署与启动方式4.1 Hadoop 伪分布式部署这里给出一套常见配置模板。实际路径和主机名需要按你的环境调整。先设置环境变量# ~/.bashrc 追加 export HADOOP_HOME/opt/hadoop export HADOOP_CONF_DIR$HADOOP_HOME/etc/hadoop export JAVA_HOME/usr/lib/jvm/java-8-openjdk-amd64 export PATH$PATH:$HADOOP_HOME/bin:$HADOOP_HOME/sbin修改core-site.xmlconfiguration property namefs.defaultFS/name valuehdfs://localhost:9000/value /property property namehadoop.tmp.dir/name value/data/hadoop/tmp/value /property /configuration修改hdfs-site.xmlconfiguration property namedfs.replication/name value1/value /property property namedfs.namenode.name.dir/name value/data/hadoop/namenode/value /property property namedfs.datanode.data.dir/name value/data/hadoop/datanode/value /property /configuration修改yarn-site.xmlconfiguration property nameyarn.nodemanager.aux-services/name valuemapreduce_shuffle/value /property /configuration配置完成后格式化文件系统。注意每次重新格式化前如果之间启动过集群最好先删除namenode和datanode对应目录再格式化。hdfs namenode -format start-dfs.sh start-yarn.sh启动后访问HDFS WebUIhttp://localhost:9870YARN WebUIhttp://localhost:8088看到两个页面正常打开说明 Hadoop 核心服务没问题。4.2 Hive 安装与初始化Hive 负责把 SQL 转换成 MapReduce 或 Spark 任务是离线分析的常用入口。下载二进制包后将 Hive 解压到/opt/hive。接着设置hive-site.xml中的 MySQL 连接信息configuration property namejavax.jdo.option.ConnectionURL/name valuejdbc:mysql://localhost:3306/hive_metastore?createDatabaseIfNotExisttrue/value /property property namejavax.jdo.option.ConnectionDriverName/name valuecom.mysql.cj.jdbc.Driver/value /property property namejavax.jdo.option.ConnectionUserName/name valuehive/value /property property namejavax.jdo.option.ConnectionPassword/name valueyour_password/value /property /configuration初始化 metastore schemaschematool -dbType mysql -initSchema然后启动 HiveServer2 和 metastorehive --service metastore hiveserver2 测试连接beeline -u jdbc:hive2://localhost:10000 -n hive4.3 系统中台服务启动后端服务建议用 FastAPI 或 Flask 实现主要聚合三类能力读取 Hive/MySQL 的分析结果。提供景点和线路查询接口。调用大模型 API 完成 Agent 对话和行程规划。先安装依赖pip install fastapi uvicorn requests pandas pymysql最小启动示例from fastapi import FastAPI app FastAPI() app.get(/api/health) def health(): return {status: ok}启动uvicorn main:app --host 0.0.0.0 --port 8000访问http://localhost:8000/api/health返回{status:ok}就说明系统台服务跑起来了。5. 数据链路从采集到可视化5.1 数据采集模块西藏旅游数据分析系统的数据源可以分成三类景区基础信息包含名称、地区、门票、开放时间、简介。客流与热度数据包含月度游客量、消费水平、停留时长。用户评论或问卷调查数据包含满意度、偏好标签、出行类型。如果做毕设最稳妥的方式是先用模拟数据生成一份 CSV再写爬虫爬取公开景区信息作为补充。要控制爬取频率遵守目标站点 robots 协议也不要抓取个人隐私数据。示例 CSV 结构attraction_id,attraction_name,city,ticket_price,month,visitor_count,satisfaction A001,布达拉宫,拉萨,200,202401,120000,4.8 A002,大昭寺,拉萨,85,202401,90000,4.65.2 数据清洗与上传 HDFS数据清洗是“大数据项目”的加分项。可以用 Python 的 pandas 做一次清洗再上传到 HDFShdfs dfs -mkdir -p /data/tourism/raw hdfs dfs -put ./tourism_data.csv /data/tourism/raw/查看文件hdfs dfs -ls /data/tourism/raw/Python 清洗示例import pandas as pd df pd.read_csv(tourism_data.csv) df df.drop_duplicates() df[visitor_count] df[visitor_count].fillna(0) df df[df[attraction_name].notnull()] df.to_csv(tourism_data_clean.csv, indexFalse)5.3 Hive 建表与分析 SQL在 Hive 中创建外部表直接映射 HDFS 文件CREATE EXTERNAL TABLE IF NOT EXISTS tourism_analysis ( attraction_id STRING, attraction_name STRING, city STRING, ticket_price DOUBLE, month STRING, visitor_count BIGINT, satisfaction DOUBLE ) ROW FORMAT DELIMITED FIELDS TERMINATED BY , STORED AS TEXTFILE LOCATION /data/tourism/raw;分析月度热度排行SELECT attraction_name, city, SUM(visitor_count) AS total_visitors FROM tourism_analysis GROUP BY attraction_name, city ORDER BY total_visitors DESC LIMIT 20;分析旺季月份分布SELECT month, AVG(satisfaction) AS avg_satisfaction, SUM(visitor_count) AS total_visitors FROM tourism_analysis GROUP BY month ORDER BY total_visitors DESC;运行完成后可以把结果写入 MySQL方便后端接口查询INSERT INTO tourism_stats SELECT attraction_name, city, SUM(visitor_count) FROM tourism_analysis GROUP BY attraction_name, city;5.4 可视化模块可视化可以使用 ECharts 或 Superset。最简单的方案是后端提供一个汇总查询接口前端用 ECharts 画柱状图、地图、折线图。关键统计指标包括西藏各城市景点数量。月度游客总量波动。热门景点 TOP10。满意度分布。门票价格区间分布。注意如果数据量很小“大数据”主要体现在全链路工程能力上分析结论的可信度要以数据来源和样本量说明为准不要在毕设答辩时硬把模拟数据描述成官方数据。6. AI Agent 智能规划模块6.1 Agent 的交互链路AI Agent 模块是这个系统区别于普通数据分析平台的核心。整体交互流程可以拆成五步用户输入自然语言诉求比如“想用 5 天时间玩拉萨和林芝带老人预算控制在 6000”。Agent 解析用户偏好提取天数、城市、预算、同行人标签。Agent 调用数据查询工具获取候选景点、酒店价格、线路距离。Agent 调用大模型生成多套行程方案。系统把行程与景点热度、满意度数据一起返回给前端。这套链路里Agent 不负责“编造天气和门票”它只是根据数据工具返回的信息进行编排可信度更高。6.2 工具调用设计在代码层面可以把工具函数注册成一个个方法大模型根据用户问题决定调用哪个工具。下面是一个简化示例def search_attractions(city: str, max_price: float 500): # 从 Hive/MySQL 查询景点 sql f SELECT attraction_name, ticket_price, satisfaction FROM tourism_stats WHERE city {city} AND ticket_price {max_price} ORDER BY satisfaction DESC return query_mysql(sql) def estimate_route(start: str, end: str): # 查询两地大概距离和耗时 return distance_map[(start, end)]大模型侧只需要在系统提示词里声明可用工具你是西藏旅游规划助手。用户提问后请先调用 search_attractions 获取景点信息 再调用 estimate_route 估算路线最后生成 5 日行程。 如果数据不足请明确告诉用户缺少哪些信息。6.3 行程推荐逻辑行程规划不能只靠大模型生成否则容易出现“景点合理但路线绕路”的问题。更稳妥的做法是后端先做过滤和排序按用户预算过滤景点。按游客满意度排序。按城市相邻关系合并线路。把同一城市景点打包成“上午 下午”。实现时可以把推荐规则和 Prompt 结果都写进plan_service.pydef build_plan(city_list, days, budget): candidate [] for city in city_list: attractions search_attractions(city, budget) candidate.extend(attractions[:3]) # 规则排序后再交给大模型润色文案 return candidate这样做好处很明显Agent 生成的内容永远建立在结构化查询结果之上不会因为大模型幻觉输出一个不存在的“错位景点”。6.4 多轮对话与追问现实中用户第一次提问往往信息不足。Agent 需要在缺少关键参数时主动追问def extract_requirements(user_input): if 天 not in user_input: return {ask: 请问您计划游玩几天} if 预算 not in user_input: return {ask: 请问预算大概是多少} return {is_complete: True}这个追问逻辑本身不复杂但能让系统在演示时显得更“智能”也便于毕设答辩时展示多轮对话效果。7. API 接口与批量任务7.1 后端接口概览为了让前端和第三方系统调用后端需要提供一组 REST API。基本接口可以这样设计接口方法说明/api/healthGET健康检查/api/attractionsGET景点列表查询/api/stats/overviewGET数据总览统计/api/agent/planPOST智能行程规划/api/agent/chatPOST多轮对话/api/batch/importPOST批量导入数据7.2 行程规划接口示例使用 FastAPI 实现/api/agent/planfrom fastapi import FastAPI, HTTPException from pydantic import BaseModel app FastAPI() class PlanRequest(BaseModel): days: int cities: list[str] budget: float tags: list[str] [] class PlanResponse(BaseModel): plan_id: str schedule: list[dict] app.post(/api/agent/plan, response_modelPlanResponse) def generate_plan(req: PlanRequest): try: schedule build_plan(req.cities, req.days, req.budget) return PlanResponse(plan_idP001, scheduleschedule) except Exception as e: raise HTTPException(status_code500, detailstr(e))调用示例curl -X POST http://localhost:8000/api/agent/plan \ -H Content-Type: application/json \ -d {days: 5, cities: [拉萨, 林芝], budget: 6000, tags: [老人, 慢节奏]}7.3 多轮对话接口示例对话接口实现时需要一个临时的会话记忆容器。毕设阶段可以用内存字典生产环境需要换成 Redissession_memory {} app.post(/api/agent/chat) def chat(data: dict): session_id data.get(session_id) user_msg data.get(message) if session_id not in session_memory: session_memory[session_id] [] session_memory[session_id].append({role: user, content: user_msg}) # 调用大模型 API reply call_llm_api(session_memory[session_id]) session_memory[session_id].append({role: assistant, content: reply}) return {session_id: session_id, reply: reply}7.4 批量任务设计批量任务主要用于两类场景批量导入历史月份数据。批量生成多个用户的行程方案。批量导入可以使用目录监听或手动上传导入后写入 HDFShdfs dfs -put ./import_batch/ /data/tourism/batch/批量生成路线时建议加日志和失败重试import time from loguru import logger task_queue [ {days: 3, cities: [拉萨], budget: 4000, user: U001}, {days: 4, cities: [拉萨, 林芝], budget: 5000, user: U002}, ] for task in task_queue: for retry in range(3): try: plan generate_plan(task[days], task[cities], task[budget]) save_plan(task[user], plan) logger.info(f用户 {task[user]} 规划成功) break except Exception: logger.warning(f用户 {task[user]} 失败重试 {retry 1} 次) time.sleep(2)8. 资源占用与性能观察8.1 Hadoop 服务内存观察Hadoop 伪分布式启动后最直观的问题是内存占用偏高。启动start-dfs.sh和start-yarn.sh后可以用jps查看进程再用top观察内存。常见情况是 NameNode、DataNode、ResourceManager、NodeManager 四个 Java 进程分别占用几百 MB 到 1GB 内存。如果机器只有 8GB 内存建议在hadoop-env.sh中调低 JVM 参数export HADOOP_HEAPSIZE512 export HADOOP_NAMENODE_OPTS-Xmx512m export HADOOP_DATANODE_OPTS-Xmx512m8.2 Hive 查询性能观察Hive 默认底层引擎可能是 MapReduce小数据量下查询也要等任务调度体感“比较慢”。如果希望查询响应更快可以用 Spark 作为 Hive 执行引擎也可以开启 Tez。毕设阶段如果数据量只有几千条不用太在意性能重点是把血缘和流程讲清楚。写 SQL 时注意尽量在分区字段上过滤避免全表扫描。减少嵌套子查询。分析结果可以预聚合写入 MySQL不要每次展示都重跑 Hive。8.3 Agent 接口延迟Agent 对话接口的延迟主要来自大模型 API。如果每次交互都调用一次大模型整体耗时可能在几秒到十几秒之间。优化思路有两个对常用景点和固定天数行程做缓存。把“数据查询”和“文案润色”拆开数据查询走本地库文案润色再调大模型。9. 常见问题与排查方法问题现象可能原因排查方式解决方案JAR does not exist or is not a normal fileHive 依赖目录配置错误检查 Hive 安装路径下的 lib JAR 是否存在重新设置HIVE_HOME和HIVE_AUX_JARS_PATHHDFS 启动后 NameNode 无法启动格式化路径或 tmp 目录权限错误查看/opt/hadoop/logs/hadoop-*-namenode-*.log删除hadoop.tmp.dir下残留目录后重新格式化端口被占用NameNode 或 ResourceManager 端口冲突ss -lntp修改配置文件中的端口或关闭冲突进程Hive 连接 MySQL 失败MySQL 驱动或账号权限问题测试 JDBC 连接下载对应mysql-connector-javaJAR 放入 Hive lib 目录并授权后端 API 调用超时Agent 调用大模型 API 时间过长查看后端日志和 API 耗时增加超时时间缓存常用请求批量任务卡住任务依赖 HDFS 文件未就绪查看日志中的任务 ID 和 HDFS 路径确保文件上传成功后再触发任务显存不足如果买了本地大模型推理显存可能不够nvidia-smi查看显存占用改用云端 API 或减小模型规格输出结果质量不稳定Agent 提示词不够明确或数据缺失调整 System Prompt增加结构化工具调用限制模型输出格式10. 最佳实践与使用建议第一条建议第一周不要追求“全功能完美”先打通“HDFS 上传 - Hive 建表 - 后端查询 - 前端展示”这条主链路。主链路通了剩下都是加分项。目录管理要提前规划好。建议把所有模块放在一个 repo 下按职责分目录tourism_agent_system/ ├── data/ # 原始数据和清洗后数据 ├── hdfs_utils/ # HDFS 上传与下载脚本 ├── hive_sql/ # 建表和分析 SQL ├── backend/ # FastAPI 后端 ├── agent/ # AI Agent 编排模块 ├── frontend/ # 可视化页面 └── docs/ # 设计文档和答辩材料批量任务一定要加日志。跑 1000 条批量生成任务时如果没有日志中途出错根本不知道哪条数据出了问题。用loguru或 Pythonlogging都可以重点是记录用户 ID、任务状态、失败原因。接口服务要注意访问范围。如果只是本地毕设演示后端服务绑定127.0.0.1就够了如果要部署到服务器需要加访问控制避免接口被外部任意调用。AI Agent 部分要守住合规边界。系统生成的行程只能算“参考建议”不能保证景点开放时间、门票价格和天气状况实时准确。前端页面应该加上“结果仅供参考”的说明避免用户误把模型输出当官方信息。数据准备阶段建议做一套“可复现数据集”。把爬虫脚本、数据清洗脚本、Hive SQL 都放在data/目录下这样答辩时评委随时可以复现比只看截图更有说服力。11. 总结这个系统最值得尝试的地方是把 Hadoop 大数据分析、可视化、AI Agent 三件事放在了一个完整项目里。对一个毕设来说它能覆盖的答辩点很多HDFS 存储、Hive SQL 分析、数据清洗、后端接口设计、Prompt 工程、工具调用、多轮对话、批量任务。对想进入大数据或 AI 应用方向的开发者来说也是一个可以快速改成简历项目的模板。建议拿到源码或参考思路后先做三件事第一在本地把 Hadoop 伪分布式跑起来确认 HDFS 和 YARN 页面能打开。第二用一份模拟的西藏旅游 CSV走通“上传 HDFS - Hive 建表 - SQL 统计”流程。第三调通 FastAPI 后端和/api/agent/plan接口验证 Agent 能否根据参数生成路线。最容易踩的坑集中在两个地方Hadoop 环境配置和 Agent 提示词。前端页面、可视化图表反而都是相对成熟的技术花不了太多时间。只要主链路通了后续就能按需加功能。比如把 Hive 换成 Spark SQL把模拟爬虫换成真实公开数据把对话接口接入企业微信机器人扩展空间很大。如果这篇内容对你有帮助建议收藏备用。后面我也会继续补 Hive 调优和 AI Agent 工具调用相关的实战记录。