基于Hadoop的餐饮大数据分析系统的设计与实现

有需要本项目的代码或文档以及全部资源，或者部署调试可以私信博主

项目介绍

本项目旨在构建一个从数据采集、存储、清洗、分析到可视化的一体化餐饮大数据分析系统。系统以爬取知名美食网站【豆果美食】的菜谱数据为数据源，通过多种大数据技术实现对菜谱信息的高效存储与分析，最终借助可视化工具为用户提供直观的数据洞察，支持餐饮行业的数据决策。

项目的第一步是数据采集。我们使用 Python 结合 Requests 库、lxml 库，对豆果美食网站进行了网页爬虫开发。爬虫采用模拟登录与持久会话的方式，通过设置 Cookie、Header，避开简单的反爬虫机制。爬虫主要采集了菜谱的标题、链接、配料、评分、收藏人数、发布用户、图片链接等字段。针对不同菜系（如西葫芦、家常菜、川菜等），爬虫遍历多页结果，形成菜谱信息的完整数据集，并将结果保存为本地 CSV 文件。

数据爬取完成后，我们利用 Pandas 对采集到的 CSV 数据进行清洗和处理。首先，通过正则表达式提取如评分、收藏人数等包含单位的字段信息，将“万”、“千”等汉字单位统一换算为数值，确保数据在后续分析中的可用性。其次，对文本数据进行了规范化处理，比如替换字符串中的逗号、空格、特殊字符，确保字段统一、规范。此外，我们还对菜谱的配料字段进行了处理，统计每道菜谱的配料数量，并生成二值化特征“是否包含肉类”，为后续分析奠定基础。

清洗后的数据首先被存储至本地 Excel 和 CSV 文件，并进一步导入到 MySQL 数据库，方便后续数据查询和可视化。数据库设计中，我们建立了菜谱信息表、菜谱统计表、用户统计表等多张表，用于记录菜谱出现次数、平均收藏、平均评分、配料数量等多维度指标。

然而，为了支撑更大规模的数据分析和挖掘，本项目不局限于单机的数据库操作，而是引入了大数据处理技术。首先，通过 Hadoop 生态的 Flume，我们实现了对本地 CSV 数据的实时采集，将数据流式传输至 Hive 数据仓库。Hive 提供了类 SQL 的查询能力，使我们能够基于 HDFS 上的大数据进行快速统计、分组、筛选等操作，同时 HiveSQL 底层调用 MapReduce 实现分布式计算，显著提高了处理效率。对于数据体量较大的多维分析场景，Hive 能够轻松完成如菜系分布、菜谱收藏数分布、用户活跃度分析等任务。

完成在 Hive 中的数据分析后，我们借助 Sqoop，将 Hive 分析得到的结果表批量导出至 MySQL 数据库。这不仅保证了数据分析的高效，也为可视化展示提供了便利的数据接口。

在可视化层面，我们选用了 Python 的 Pyecharts 库，结合生成的 MySQL 数据，设计了丰富的图表。包括柱状图、折线图、饼图、词云等多种类型，全面展现了菜谱出现次数、平均收藏数、平均评分、用户活跃度、配料数量分布等多维信息。可视化结果被渲染为 HTML 文件，并通过 Draggable Page Layout 布局构建多个可交互的大屏可视化页面。用户可以根据需求，自由拖拽、排布各类图表，以直观、灵活的方式探索数据背后的规律与趋势。

例如，通过柱状图展示了不同菜系的出现频次，帮助理解市场上用户的偏好；通过折线图分析不同菜系的平均收藏数及评分，辅助判断菜系的受欢迎程度和品质；词云分析了菜谱配料，洞察热门食材和烹饪趋势；饼图展示了是否包含肉类的菜谱占比，便于针对素食或肉食市场做出分析。这些可视化成果不仅提升了数据解读的效率，也为餐饮行业提供了数据驱动的决策参考。

总体而言，本项目从爬虫到数据清洗，从大数据分析到可视化，实现了餐饮行业数据的全流程处理与价值挖掘。它不仅积累了丰富的美食数据资源，也为后续开展菜谱推荐、用户画像分析、市场趋势预测等更深入的业务分析提供了坚实的技术基础。

项目展示

通过Hadoop分析出的结果，将其传输存储在关系型数据库MySQL中进行可视化数据准备。

数仓的结构介绍

在这里需要给大家普及一下数据仓库的几个层：

下面介绍一下数据仓库的几个层次，以及你提到的数据存储层（常常也叫数据仓库分层或者分区存储层次），这是数据仓库设计中非常重要的概念。

---

数据仓库的几层结构

在现代数据仓库架构中，数据通常不是直接从数据源写入到用于分析的最终表，而是分层存储、逐步加工。这种分层的目的是：

• 解耦数据结构（避免数据源变动影响分析层）
• 提升性能
• 提高数据质量
• 便于管理和维护

不同公司或项目叫法略有差异，但典型的数据仓库分层一般包括以下几层：

---

① 数据源层（ODS：Operational Data Store）

• 全称：操作数据存储层

• 作用：原始数据的存放区，是对业务系统数据的“原样搬运”

• 特点：

  • 存储最原始、最详细、未加工的数据
  • 一般保留数据的原始字段名和格式
  • 用于备份、恢复，也用于数据溯源

• 常见数据：

  • 日志数据
  • 交易明细
  • 系统表快照

举例：

从 MySQL、CSV、日志文件采集过来的原始菜谱爬虫数据，就属于 ODS 层。

---

② 数据清洗层 / 数据整合层（DWD：Data Warehouse Detail）

• 全称：数据仓库明细层

• 作用：对 ODS 层原始数据进行清洗、转换、规范化

• 特点：

  • 去重、去噪、空值处理
  • 格式转换（如时间格式统一、金额单位换算）
  • 标准化字段命名
  • 保留明细粒度的数据

• 常见用途：

  • 为后续宽表建模、主题建模提供干净、标准化的数据

举例：

将爬虫中爬取的“收藏人数”字段，从“1.5万”统一转换成整数 15000，并将菜谱 ID、用户 ID 统一成整型，这就是 DWD 层的任务。

---

③ 数据汇总层 / 轻度加工层（DWS：Data Warehouse Summary）

• 全称：数据仓库汇总层（或者宽表层）

• 作用：基于 DWD 层，做轻度的统计、聚合

• 特点：

  • 产生宽表，方便查询
  • 减少 Join 操作，提高查询效率
  • 存储业务常用维度组合的结果

• 常见用途：

  • 日志明细汇总到用户粒度
  • 交易明细按天、按月做聚合

举例：

统计每种菜系的平均收藏次数、平均评分，这类业务常用统计表就是 DWS 层。

---

④ 数据应用层（ADS：Application Data Store）

• 全称：应用数据层

• 作用：面向具体业务需求、报表、可视化的最终数据层

• 特点：

  • 粒度更粗
  • 面向特定分析场景
  • 表结构相对稳定

• 常见用途：

  • BI 报表
  • 大屏可视化
  • API 接口
  • 数据导出到第三方系统（如 MySQL）

举例：

在项目里，通过 HiveSQL 分析得到“收藏次数最多的10道菜谱”，再通过 Sqoop 导出到 MySQL，用 Pyecharts 制作柱状图，这就是典型的 ADS 层数据。

---

数据存储层

你提到的“数据存储层”，通常指的是整个数据仓库的物理落地存储方案。这并不是一层，而是所有层的数据都需要“落地存储”。它包含：

• 存储介质

  • HDFS（Hadoop 分布式文件系统）
  • 云对象存储（例如阿里云 OSS、Amazon S3）
  • 关系型数据库（MySQL、PostgreSQL）
  • 列式存储（如 ClickHouse）

• 数据格式

  • Text、CSV、JSON（最原始的）
  • ORC、Parquet、Avro（大数据常用，高压缩率，高效查询）

• 分区与分桶

  • 分区（Partition）：按日期、地区等划分目录，加速查询
  • 分桶（Bucket）：对分区内数据做哈希分散，优化 join 性能

例如：

• 你采集的爬虫 CSV 文件 → 存在本地磁盘
• Flume 采集后 → 存到 HDFS（可能是 Parquet 格式）
• Hive 建表时 → 用 ORC 或 Parquet 存储，并按 caipu、日期分区
• Sqoop 把分析结果导出 → 存到 MySQL，用于 Pyecharts 可视化

因此，数据仓库的“存储层”并不是单独的一层，而是贯穿 ODS → DWD → DWS → ADS 全流程的存储设计。

---

项目中的数据仓库分层示意

结合你的项目，流程可以这样看：

爬虫数据（CSV文件）↓
Flume采集 → ODS层（HDFS原始表）↓
HiveSQL清洗 → DWD层（标准化、格式化数据）↓
HiveSQL汇总 → DWS层（统计表）↓
HiveSQL分析结果 → ADS层（面向可视化）↓
Sqoop导出 → MySQL↓
Pyecharts 可视化

---

总结

数据仓库分层设计，是数据工程中非常核心的思想。它帮助我们：

• 保证数据质量
• 降低耦合
• 提高分析效率
• 为不同需求（报表、分析、机器学习）提供合适的数据形态

系统展示

项目总结

本项目是一个标准且复杂的大数据项目，适合做毕业设计类的项目，从数据采集、数据清洗、以及在Hadoop进行全流程的大数据分析步骤，包含可视化应用，以及系统搭建，设计到多用户的管理和展示，具有较强的可塑造性。

每文一语

好记性不如烂笔头、多回顾、多记忆、时间是经验的老师