企业官网建设流程全解析

本文还有配套的精品资源，点击获取

简介：一套开箱即用的招聘数据分析系统，完整覆盖数据获取、存储、处理到展示环节。用Shell脚本自动抓取并清洗拉勾、前程无忧等平台的职位数据（已打包在171265889347208773632.zip中），通过Hadoop HDFS做原始数据存储，YARN统一调度计算资源；Hive构建分层数据仓库，支持标准SQL完成ETL与多维分析；HBase单独管理高频更新的企业信息和岗位详情，满足毫秒级随机查询；Java后端服务对接双存储引擎，Web前端基于ECharts渲染10类图表——包括城市热力图、薪资分布直方图、岗位增长趋势线、技能关键词云、行业占比环形图等。所有配置文件（hadoop-env.sh、core-site.xml等）、调度脚本（如t3.sh）、建表语句、列族定义、接口代码、页面模板和截图（存于imgs目录）全部包含。project File.pdf详解整体架构、各模块依赖关系及字段含义，README.md提供三步启动指南，已在Mac、Windows 10/11、主流Linux发行版实测通过。适合用于课程设计、毕设选题或快速理解Hadoop生态组件如何协同完成真实业务场景。

1. 项目概述：为什么这个招聘数据项目值得你花时间啃透？

我带过六届大数据方向的毕业设计，每年都有学生在选题时卡在“有技术没场景”上——Hadoop装好了，Hive建表语句背熟了，HBase Shell命令敲得飞快，但一问“这些组件串起来到底能干啥”，就支吾半天。直到去年我把这套招聘数据全流程项目拆开揉碎讲给学生听，才真正看到他们眼睛亮起来。这不是一个拼凑出来的“Demo”，而是一个从真实招聘平台数据出发、每一步都踩在业务痛点上的闭环系统。它用最典型的互联网招聘场景，把Hadoop生态里那些听起来高大上的组件，变成了你能摸得着、改得动、跑得通的具体模块。

核心关键词“招聘数据分析、Hive数仓、HBase实时存储、ECharts可视化、Hadoop实战”，其实已经勾勒出一条清晰的技术主线：数据从哪来（爬虫原始包）、怎么存（HDFS原始层 + Hive数仓层 + HBase实时层）、怎么算（Hive SQL + Java服务逻辑）、怎么查（HBase随机读 + Hive聚合查询）、最后怎么让人一眼看懂（ECharts动态图表）。这五个环节环环相扣，缺一不可。比如，为什么不用Hive存所有数据？因为企业信息每天可能被HR更新几十次，Hive的批处理模式写一次要等几分钟，用户点开一个公司主页却要等三秒才加载出最新融资轮次和员工规模，体验直接崩盘；为什么不用MySQL扛全部？因为拉勾+前程无忧单日增量轻松破百万条职位记录，传统关系库的连接数、锁机制、主从同步延迟根本扛不住。HBase在这里不是炫技，而是解决“毫秒级响应企业详情页”这个具体问题的唯一合理选择。

这个项目特别适合两类人：一类是计算机专业学生，正为毕设或课程设计发愁，需要一个“不造轮子、只调参数”的完整骨架，填进自己学校的课程数据就能交差；另一类是刚转行大数据的开发者，想跳过“Hello World”式单点练习，直接理解组件间如何协同——比如Hive怎么把清洗后的数据灌进HBase，Java后端怎么同时连Hive JDBC和HBase Client，Shell脚本里的t3.sh究竟在哪个环节触发ETL调度。它不教你每个组件的源码，但教会你怎么让它们在一个真实业务里“好好说话”。我试过让学生先跑通整个流程，再让他们把“薪资趋势图”从折线图改成面积图，把“技能词云”从静态HTML换成支持鼠标悬停显示出现频次的交互版本，你会发现，所有技术细节突然都有了落脚点。这不是一个终点，而是一个极佳的起点。

2. 整体架构设计与组件选型逻辑：为什么是这套组合，而不是别的？

2.1 四层数据架构：原始层→数仓层→实时层→应用层

整套系统严格遵循大数据分层治理思想，划分为四个物理隔离、逻辑贯通的层级。这种分层不是为了显得“高大上”，而是为了解决不同数据特性的天然矛盾。我见过太多项目把所有数据一股脑塞进Hive，结果ETL任务越跑越慢，临时查个昨天的岗位新增量都要等五分钟；也见过把HBase当万能钥匙，连用户登录日志都往里写，最后RegionServer频繁GC崩溃。这个项目的分层，是踩过坑之后的理性选择。

• 原始层（Raw Layer）：数据源头是171265889347208773632.zip这个压缩包，里面是已清洗过的JSON格式招聘数据样本，字段包括job_title、salary_min、salary_max、city、company_name、skills（数组）、publish_date等。这些文件被解压后，通过shell/t3.sh脚本中的hdfs dfs -put命令，原封不动上传到HDFS的/raw/jobs/目录下。这里的关键是“不做任何转换”，保留原始时间戳、原始字段名、原始编码格式。为什么？因为后续任何ETL逻辑出错，你都能回溯到这份“数字化石”，而不是面对一堆被错误清洗过的脏数据抓瞎。HDFS在这里扮演的是“数据保险柜”，利用其高容错、高吞吐特性，确保百万级小文件安全落地。

• 数仓层（Warehouse Layer）：这是Hive大展拳脚的地方。project File.pdf里明确给出了分层建表方案：ods_job_raw（贴源层，直接映射HDFS原始JSON）、dwd_job_clean（明细层，做字段标准化、空值填充、薪资单位统一换算成“月薪元”）、dws_city_salary_stats（汇总层，按城市+岗位类型聚合平均薪资、岗位数）。Hive之所以成为首选，核心在于它把MapReduce的复杂性封装成了标准SQL。学生不需要写一行Java MapReduce代码，就能用INSERT OVERWRITE TABLE dws_city_salary_stats SELECT city, job_type, AVG((salary_min+salary_max)/2) AS avg_salary, COUNT(*) AS job_cnt FROM dwd_job_clean GROUP BY city, job_type;完成多维分析。YARN在这里是隐形的指挥官——当这条SQL提交，Hive会自动将其编译成DAG作业，由YARN分配Container资源给Mapper和Reducer，你只需关注业务逻辑，不用操心资源争抢。

• 实时层（Real-time Layer）：HBase负责这一层，对应project File.pdf中定义的company_info表，列族为cf:basic（公司基础信息）和cf:hr（HR联系信息）。它的存在，纯粹是为了应对“高频、低延时、单点更新”场景。比如，某互联网公司官网更新了办公地址，HR在后台管理系统点一下“同步至招聘页”，Java后端服务就调用Put操作，100毫秒内完成对company_info表中rowkey=company_id那行数据的cf:basic:address列的更新。HBase的LSM树结构决定了它写入极快，且RowKey设计（如company_id哈希后取模分片）保证了数据均匀分布，避免热点Region。这里绝不能用Hive替代，因为Hive的INSERT是追加写，无法实现“覆盖更新”；也不能用MySQL，因为单表百万QPS的随机写入会直接压垮主库。

• 应用层（Application Layer）：Java后端（Java/src/main/java/com/bigdata/）是承上启下的枢纽。它不直接暴露HDFS或HBase接口给前端，而是提供RESTful API，如GET /api/v1/stats/city-salary?city=shanghai。这个API内部做了两件事：一是用JDBC连接HiveServer2，执行预编译的聚合SQL；二是用HBase Client连接ZooKeeper，根据company_id快速Get单条企业详情。前端ECharts只跟这个Java服务对话，完全屏蔽了底层存储差异。这种设计让前端开发可以专注图表交互，后端开发可以独立优化数据查询逻辑，互不干扰。

2.2 组件协同的关键纽带：Shell脚本与Java服务

很多人以为大数据项目就是堆砌组件，其实真正的难点在于“粘合”。这个项目里，shell/t3.sh和Java服务就是最关键的两个粘合剂。

t3.sh脚本不是简单的“启动命令集合”，而是一个轻量级的ETL调度引擎。它内部逻辑是：先检查HDFS/raw/jobs/目录下是否有新文件（hdfs dfs -ls /raw/jobs/ | wc -l），如果有，则触发Hive的LOAD DATA INPATH将新数据导入ods_job_raw；接着执行HiveQL脚本hive -f dwd_job_clean.hql进行清洗；最后调用hbase shell执行put命令，将清洗后的企业信息批量写入HBase。整个过程用&&串联，任一环节失败则中断，并记录日志到/logs/t3.log。我建议你在实操时，把t3.sh里的hive -f命令替换成hive -S -f（静默模式），这样日志更干净，方便排查。

Java服务则是另一个维度的协同。Java/src/main/java/com/bigdata/controller/StatsController.java里，一个getCitySalaryStats()方法背后，是双重数据源的优雅整合：HiveJdbcUtil.executeQuery(sql)获取城市薪资统计，HBaseUtil.getCompanyInfo(companyId)获取企业详情，最终合并成一个JSON对象返回。这里有个极易忽略的细节：Hive JDBC连接池和HBase ConnectionPool必须分开管理，因为Hive连接是短连接（每次查询新建），而HBase Connection是长连接（需复用，否则频繁创建Connection会耗尽ZK连接数）。project File.pdf的“配置说明”章节提到了这点，但很多初学者会直接复制粘贴，导致服务启动后内存飙升。我的经验是，HBase ConnectionPool大小设为5-10足够，而Hive JDBC连接池（如Druid）最大活跃连接数设为20即可，再多反而增加YARN调度压力。

3. 核心模块深度解析与实操要点：从配置到代码，手把手拆解

3.1 Hadoop环境准备：避开Mac/Linux/Windows三大坑

虽然README.md写着“多环境验证可直接启动”，但实际部署时，三个系统的坑各有不同。我整理了一份避坑清单，这是学生反复踩过之后总结的：

• Mac系统（M1/M2芯片）：最大的雷是Hadoop 3.x官方二进制包不支持ARM64架构。直接下载会报Illegal instruction: 4。正确做法是：去Apache官网找hadoop-3.3.6-src.tar.gz源码包，用mvn clean package -Pdist,native -DskipTests -Dtar命令本地编译，生成的hadoop-3.3.6.tar.gz才能在M1上跑。hadoop-env.sh里JAVA_HOME必须指向ARM版JDK（如/opt/homebrew/opt/openjdk@17/libexec/openjdk.jdk/Contents/Home），而非Intel版。core-site.xml的fs.defaultFS务必写成hdfs://localhost:9000，如果写成hdfs://127.0.0.1:9000，Mac的/etc/hosts解析有时会失效。

• Windows 10/11：别信网上那些“修改winutils.exe”的教程，太折腾。最稳方案是用WSL2（Windows Subsystem for Linux）。在Microsoft Store安装Ubuntu 22.04，然后在WSL里按Linux步骤部署。关键点：WSL2的IP是动态的，所以yarn-site.xml里的yarn.resourcemanager.hostname不能写localhost，而要写hostname -I | awk '{print $1}'输出的IP（如172.28.16.1），并确保Windows防火墙放行9000、8088等端口。shell/t3.sh在Windows下要用Git Bash运行，别用PowerShell，否则hdfs dfs命令会报错。

• Linux（CentOS 7/8, Ubuntu 20.04+）：看似最简单，实则暗藏杀机。CentOS 7默认Python是2.7，而Hadoop某些脚本依赖Python3。解决方案：sudo alternatives --config python切换默认Python版本，或在hadoop-env.sh顶部显式声明export PYTHON=/usr/bin/python3。Ubuntu 22.04的systemd服务管理方式与旧版不同，启动HDFS时要用sudo systemctl start hadoop-hdfs-namenode而非start-dfs.sh。project File.pdf的“部署步骤”第3步提到“关闭防火墙”，在生产环境当然不行，但学习阶段，sudo ufw disable能省掉90%的端口不通问题。

所有环境的共性配置，在bigData-master/conf/目录下。hadoop-env.sh里HADOOP_HEAPSIZE_MAX=2048（2G）是底线，低于此值NameNode极易OOM；yarn-site.xml中yarn.nodemanager.resource.memory-mb设为3072，确保单节点能跑起Hive和HBase的多个进程；hdfs-site.xml的dfs.replication设为1（单机学习模式），别照搬生产环境的3，否则HDFS会因找不到2个其他DataNode而拒绝写入。

3.2 Hive数仓构建：从建表到ETL，每一步都是业务逻辑

Hive建表不是语法练习，而是对业务数据的理解。project File.pdf的“表结构说明”给出了dwd_job_clean表的DDL，但没告诉你为什么这么设计。我们来深挖：

CREATE EXTERNAL TABLE IF NOT EXISTS dwd_job_clean ( job_id STRING, job_title STRING, salary_min INT, salary_max INT, city STRING, district STRING, company_name STRING, company_id STRING, skills ARRAY<STRING>, publish_date STRING, crawl_time STRING ) PARTITIONED BY (dt STRING) STORED AS PARQUET LOCATION '/warehouse/dwd/job_clean/';

• EXTERNAL TABLE（外部表）：这是关键！意味着Hive只管理元数据（表结构、分区信息），不管理数据本身。数据物理位置在HDFS的/warehouse/dwd/job_clean/，即使你DROP TABLE dwd_job_clean，HDFS上的Parquet文件也不会被删。这极大降低了误操作风险，也方便其他工具（如Spark）直接读取同一份数据。

• PARTITIONED BY (dt STRING)：分区字段dt对应日期，如dt='20231025'。所有ETL脚本（如t3.sh调用的dwd_job_clean.hql）都会在INSERT时指定PARTITION (dt='20231025')。好处是查询时加WHERE dt='20231025'，Hive只会扫描当天的分区目录，而不是全表扫描，性能提升百倍。project File.pdf里没提，但实际dwd_job_clean.hql脚本里，dt值是用date +%Y%m%d动态获取的，确保每天生成新分区。

• STORED AS PARQUET：Parquet是列式存储格式，比TextFile节省70%空间，且查询只读取所需列。比如查SELECT city, AVG(salary_min) FROM dwd_job_clean WHERE dt='20231025'，Hive只读city和salaray_min两列的Parquet文件，skills数组列完全不加载。project File.pdf的“Hive建表语句”部分只给了语法，但没强调Parquet对后续ECharts图表加载速度的影响——当城市热力图需要实时聚合全国数据时，Parquet的IO效率就是生命线。

ETL清洗逻辑集中在dwd_job_clean.hql。核心清洗点有三处：
1.薪资标准化：原始数据中，salary_min可能是“15k”，也可能是“20000”，还可能是“面议”。脚本里用regexp_replace(salary_min, '[^0-9]', '')提取纯数字，再根据上下文判断单位（如含“k”则乘以1000），最后统一为“月薪元”。project File.pdf的“字段含义”表里，“薪资范围”字段注明了“已换算为月薪整数”，这就是清洗的结果。
2.城市归一化：city字段原始值有“上海”、“上海市”、“shanghai”、“SH”等。脚本里建了一个city_mapping维表（dwd_city_map），用LEFT JOIN关联，将所有变体映射到标准城市编码（如SHANGHAI），确保后续按城市聚合时不会把“上海”和“shanghai”算作两个城市。
3.技能数组展开：skills是JSON数组，如["Java", "Spring Boot", "MySQL"]。Hive不支持直接对ARRAY字段GROUP BY，所以脚本里用LATERAL VIEW explode(skills) t AS skill将其炸开成多行，每行一个技能，为后续“技能词云”图表提供原子数据。

3.3 HBase实时存储：RowKey设计与Java API调用精髓

HBase的威力不在“快”，而在“可控的快”。project File.pdf的“HBase列族定义”只写了cf:basic和cf:hr，但没告诉你RowKey怎么设计。这才是决定性能的核心。

company_info表的RowKey是MD5(company_id) + '_' + company_id，例如company_id="LG2023001"，计算MD5("LG2023001")得到a1b2c3d4...，最终RowKey为a1b2c3d4_LG2023001。为什么要加MD5前缀？因为原始company_id可能是自增数字（如1,2,3…），直接当RowKey会导致所有新数据写入同一个Region（热点问题）。MD5打散后，数据均匀分布在16个Region上，写入吞吐量翻倍。project File.pdf里没提这点，但Java/src/main/java/com/bigdata/util/HBaseUtil.java的generateRowKey()方法实现了这个逻辑，这是必须读懂的代码。

Java调用HBase的API，重点在Put和Get的用法。HBaseUtil.putCompanyInfo()方法里：

Put put = new Put(Bytes.toBytes(rowKey)); put.addColumn(Bytes.toBytes("cf"), Bytes.toBytes("basic:name"), Bytes.toBytes(company.getName())); put.addColumn(Bytes.toBytes("cf"), Bytes.toBytes("basic:address"), Bytes.toBytes(company.getAddress())); // ... 其他列 table.put(put); // 一次put操作，原子写入整行

注意addColumn的第三个参数是byte[]，所以必须用Bytes.toBytes()转换。很多初学者直接传String，导致HBase里存的是乱码。project File.pdf的“列族定义”表格里，“列名”列写的是basic:name，但Java代码里必须拆成"cf"（列族名）和"basic:name"（限定符），这是HBase API的硬性要求。

Get操作同样有门道。HBaseUtil.getCompanyInfo()里：

Get get = new Get(Bytes.toBytes(rowKey)); get.addColumn(Bytes.toBytes("cf"), Bytes.toBytes("basic:name")); get.addColumn(Bytes.toBytes("cf"), Bytes.toBytes("basic:address")); Result result = table.get(get); String name = Bytes.toString(result.getValue(Bytes.toBytes("cf"), Bytes.toBytes("basic:name")));

关键点：get.addColumn()指定了只读取name和address两列，而不是整行。这对前端加载企业详情页至关重要——用户只想看公司名字和地址，没必要把hr_phone、hr_email等所有列都拉过来，网络IO和序列化开销直降50%。project File.pdf的“ECharts配置逻辑”部分提到“企业详情接口响应时间<200ms”，这个精细的Get控制就是保障。

4. ECharts可视化实现与前端集成：不只是画图，更是数据叙事

4.1 图表选型背后的业务意图：每一个图表都在回答一个问题

ECharts不是炫技工具，而是业务问题的可视化答案。web/目录下的10+图表，每个都对应一个招聘业务方的真实疑问。理解这个意图，才能调好参数、选对图表类型。

• 城市热力图（echarts-city-heatmap.html）：回答“哪些城市岗位最密集？”。用geo坐标系+scatter系列，数据源是/api/v1/stats/city-count接口返回的[{name: '上海', value: 12500}, {name: '北京', value: 9800}]。关键配置是visualMap：
  javascript visualMap: { min: 0, max: 20000, text: ['高', '低'], realtime: false, // 关键！设为false，避免拖拽时实时重绘卡顿 calculable: true, inRange: { color: ['#e0ffff', '#006edd'] // 从浅蓝到深蓝渐变 } }
realtime: false是性能开关，学生常忽略这点，导致地图缩放时卡成PPT。project File.pdf的“ECharts配置逻辑”只写了“使用热力图”，但没提这个救命参数。

• 薪资分布直方图（echarts-salary-hist.html）：回答“目标岗位的薪资集中在哪个区间？”。用histogram系列，但数据预处理在后端。/api/v1/stats/salary-hist?job_type=Java接口返回的不是原始薪资数组，而是已分桶的统计结果：[{range: '10k-15k', count: 3200}, {range: '15k-20k', count: 4100}]。前端直接用xAxis.data和series[0].data绑定，避免前端JS做大量计算。project File.pdf的“部署步骤”说“前端渲染图表”，但没强调后端必须做分桶聚合，这是前后端协作的隐性契约。

• 技能关键词云（echarts-skill-cloud.html）：回答“哪些技术栈最被企业青睐？”。用wordCloud系列，数据源是/api/v1/stats/skill-top10。这里有个精妙设计：后端返回的value不是出现次数，而是TF-IDF权重。比如“Java”在所有职位中出现10000次，但在“Java工程师”岗位中出现9000次，IDF值就低，权重不如“Spring Cloud”（出现频次低但区分度高）。project File.pdf的“字段含义”表里，“技能权重”字段注明了“基于TF-IDF算法计算”，但没给出公式。实际代码在Java/src/main/java/com/bigdata/service/StatsService.java的calculateSkillTfIdf()方法里，用HashMap<String, Double>存词频，再遍历所有岗位计算逆文档频率。

• 行业占比环形图（echarts-industry-pie.html）：回答“IT招聘中，互联网、金融、制造业各自占比多少？”。用pie系列，radius设为['40%', '70%']形成环形。关键交互是emphasis高亮：
  javascript emphasis: { itemStyle: { shadowBlur: 10, shadowOffsetX: 0, shadowColor: 'rgba(0, 0, 0, 0.5)' } }
  鼠标悬停时，扇形区域投下阴影，视觉层次立刻拉开。project File.pdf的“ECharts配置逻辑”只写了“支持交互”，但这个阴影效果是提升专业感的细节。

4.2 前后端联调与性能优化：让图表“秒开”的实战技巧

图表“能显示”和“秒开”是两回事。我在指导学生时，发现90%的性能问题出在三个地方：

1. 接口响应瓶颈：ECharts图表初始化时，会并发请求多个API（如城市热力图、薪资直方图、技能词云）。如果后端Java服务没做连接池优化，每个HTTP请求都新建Hive JDBC连接，10个并发就可能耗尽YARN资源。解决方案：在Java/src/main/resources/application.properties里，把spring.datasource.hikari.maximum-pool-size=20（Hive连接池），hbase.connection.pool.size=8（HBase连接池）。project File.pdf的“部署步骤”没提这个，但README.md的“高级配置”章节有暗示。

2. 前端数据缓存：web/js/main.js里，所有$.ajax请求都加了cache: true，且url里拼接了时间戳?t=${Date.now()}。这是典型错误！导致浏览器无法缓存，每次刷新都重新拉数据。正确做法：移除时间戳，让ECharts图表首次加载后，把返回的JSON存到sessionStorage，下次进入页面先读缓存，再用setTimeout异步刷新。project File.pdf的“ECharts配置逻辑”没涉及前端缓存，但这对用户体验至关重要。

3. 图表懒加载：web/index.html里，10个图表tab页默认全部渲染，但用户一次只看一个。用v-show（Vue）或display:none（原生JS）隐藏非活动tab，只在用户点击时，才执行echarts.init()和setOption()。project File.pdf的“架构设计图”里，Web模块画得很漂亮，但没体现这个前端工程实践。

5. 实操过程与核心环节实现：从零开始，一步步跑通全流程

5.1 环境搭建与一键启动：三步走通，拒绝玄学

README.md的“快速上手指引”写得简洁，但实操中每一步都有坑。我把它拆解成可验证的三步：

第一步：解压与目录准备

# 解压主包（假设下载到Downloads） cd ~/Downloads unzip bigData-master.zip # 进入项目根目录 cd bigData-master # 创建HDFS必需目录（Hadoop首次启动会报错，提前建好） hdfs dfs -mkdir -p /raw/jobs /warehouse/ods /warehouse/dwd /warehouse/dws # 解压原始数据包到HDFS hdfs dfs -put 171265889347208773632.zip /raw/ # 在HDFS里解压（用Hadoop自带的jar命令） hadoop jar $HADOOP_HOME/share/hadoop/tools/lib/hadoop-archives-*.jar har -archiveName jobs.har -src /raw/171265889347208773632.zip -dest /raw/

提示：hadoop jar ... har命令是关键，它把ZIP包在HDFS里解压成HAR归档，避免海量小文件拖垮NameNode。project File.pdf的“部署步骤”没提这步，但shell/t3.sh脚本里hdfs dfs -ls /raw/jobs/能列出文件，正是因为用了HAR。

第二步：启动核心服务

# 启动HDFS（NameNode + DataNode） start-dfs.sh # 启动YARN（ResourceManager + NodeManager） start-yarn.sh # 启动Hive Metastore（Hive元数据服务） hive --service metastore & # 启动HBase（ZooKeeper + HMaster + HRegionServer） start-hbase.sh # 启动Java后端服务（Spring Boot） cd Java && mvn spring-boot:run # 启动前端（静态服务器） cd ../web && python3 -m http.server 8080

注意：hive --service metastore &必须在start-yarn.sh之后执行，因为Metastore依赖YARN。project File.pdf的“部署步骤”顺序是正确的，但没强调这个依赖关系。

第三步：执行ETL与验证

# 运行调度脚本（在bigData-master目录下） chmod +x shell/t3.sh ./shell/t3.sh # 验证Hive数据（进入Hive CLI） hive hive> SHOW DATABASES; hive> USE default; hive> SELECT COUNT(*) FROM dwd_job_clean WHERE dt='20231025'; # 验证HBase数据（进入HBase Shell） hbase shell hbase(main):001:0> scan 'company_info', {LIMIT=>5}

提示：./shell/t3.sh执行后，检查/logs/t3.log，最后一行应为[INFO] ETL completed successfully。如果报错，90%是HDFS路径权限问题，用hdfs dfs -chmod -R 777 /raw临时解决（学习环境）。

5.2 动态看板访问与图表调试：像业务方一样使用系统

服务全部启动后，在浏览器访问http://localhost:8080（前端）或http://localhost:8080/index.html（如果web目录是根）。首页是导航栏，点击任意图表，如“城市热力图”。

调试图表的黄金三步法：
1.看Network：打开浏览器开发者工具（F12），切到Network标签，刷新页面，找到/api/v1/stats/city-count请求，看Status是否200，Response是否返回了[{name:'上海',value:12500},...]。如果不是，问题在后端Java服务或Hive查询。
2.看Console：如果Network正常但图表空白，看Console是否有echarts is not defined错误。这意味着echarts.min.js没加载成功，检查web/index.html里<script src="js/echarts.min.js">路径是否正确（应为web/js/echarts.min.js）。
3.看图表配置：如果数据返回了但图表显示异常（如热力图全是灰色），检查web/js/city-heatmap.js里的geoCoordMap是否包含“上海”的经纬度。project File.pdf的“ECharts配置逻辑”提到“内置中国城市坐标”，但实际坐标数据在web/js/china-cities.js里，必须确保该文件被正确引入。

6. 常见问题与排查技巧实录：那些让我熬夜到三点的坑

6.1 Hadoop相关问题速查

6.2 Hive与HBase协同问题

问题：Hive能查到数据，但Java服务调用getCitySalaryStats()返回空数组
-排查思路：Hive和Java服务连接的是同一个HiveServer2吗？检查Java/src/main/resources/application.properties里的spring.datasource.url=jdbc:hive2://localhost:10000/default，确认10000端口是HiveServer2的Thrift端口（不是Metastore的9083）。
-实操心得：HiveServer2必须在start-yarn.sh之后启动。用hive --service hiveserver2 &启动后，用netstat -tuln | grep 10000确认端口监听。如果端口没起来，看$HIVE_HOME/logs/hiveserver2.log，常见错误是java.lang.OutOfMemoryError: Metaspace，需在$HIVE_HOME/conf/hive-env.sh里加export HADOOP_HEAPSIZE=2048。

问题：HBasescan 'company_info'能查到数据，但JavagetCompanyInfo()返回null
-排查思路：RowKey是否一致？HBase Shell里scan看到的RowKey是a1b2c3d4_LG2023001，但Java代码里generateRowKey()算出来的是b4c5d6e7_LG2023001。这是因为MD5算法对输入字符串的编码敏感。
-实操心得：HBaseUtil.generateRowKey(String companyId)方法里，MessageDigest.getInstance("MD5").digest(companyId.getBytes("UTF-8"))必须指定"UTF-8"，否则Mac和Linux默认编码不同，MD5结果天差地别。project File.pdf没提编码，这是血泪教训。

6.3 ECharts前端问题

问题：城市热力图显示“undefined”而非城市名
-原因：echarts.min.js版本兼容性。项目用的是ECharts 4.x，但如果你不小心引入了5.x的CDN，geoCoordMap的注册方式变了。
-解决方案：严格使用web/js/echarts.min.js（项目自带），不要替换为CDN。检查web/index.html里<script>标签的src属性，确保是相对路径。

问题：技能词云文字重叠、挤在一起
-原因：wordCloud系列的sizeRange设置不合理。默认[12, 60]，但数据权重跨度太大。
-解决方案：在web/js/skill-cloud.js里，调整sizeRange为[20, 80]，并增加rotationRange: [-45, 45]让文字旋转角度更大，减少重叠。project File.pdf的“ECharts配置逻辑”没提这个微调项。

7. 拓展与进阶：把这个项目变成你的个人作品集亮点

跑通这个项目只是起点。我建议你至少做一项拓展，让它真正属于你：

• 接入实时流（Kafka + Flink）：把shell/t3.sh的定时批量采集，升级为实时流。用Python写一个Kafka Producer，模拟招聘网站新职位发布事件，发送到jobs-topic；用Flink SQL消费，实时清洗后写入HBase的job_realtime表；Java服务新增/api/v1/realtime/job-new接口，ECharts用setInterval每5秒轮询，实现“新职位上架实时推送”。这一步把项目从“T+1报表”升级为“实时作战室”，是简历上最亮眼的一笔。

• 增加智能推荐模块：在Java服务里，用spark-mllib训练一个协同过滤模型。用户浏览了“Java工程师”岗位，系统推荐相似技能（如“Spring Boot”、“分布式”）的其他岗位。模型训练数据来自dwd_job_clean表的用户行为日志（需自己模拟添加user_id,job_id,click_time字段）。project File.pdf的架构图里没有推荐模块，但加上它，项目就从“分析”跃升为“决策支持”。

• 容器化部署（Docker）：为每个组件写Dockerfile：hadoop-base镜像（含HDFS/YARN）、hive-server2镜像、hbase-master镜像、java-backend镜像、nginx-web镜像。用docker-compose.yml一键启动整个集群。README.md里可以加一节“Docker部署”，写明docker-compose up -d后，所有服务自动互联。这展示了你的工程化能力，远超单纯写SQL。

我个人在实际教学中发现，学生做完基础部署后，花2小时做一项拓展，带来的收获远大于再调试2天环境。因为拓展迫使你深入理解组件原理，而不仅仅是复制粘贴配置。这个项目的价值，不在于它本身有多完美，而在于它为你提供了一个坚实、可触摸、可修改的“技术沙盒”。你可以在这里试验任何想法，失败了重来，成功了就是你的勋章。当你能把“城市热力图”的颜色渐变从蓝色改成公司VI色，能把“薪资趋势图”的时间粒度从“月”精确到“周”，你就已经超越了90%的初学者。技术没有捷径，但有一个好项目，真的能让你少走三年弯路。

本文还有配套的精品资源，点击获取

简介：一套开箱即用的招聘数据分析系统，完整覆盖数据获取、存储、处理到展示环节。用Shell脚本自动抓取并清洗拉勾、前程无忧等平台的职位数据（已打包在171265889347208773632.zip中），通过Hadoop HDFS做原始数据存储，YARN统一调度计算资源；Hive构建分层数据仓库，支持标准SQL完成ETL与多维分析；HBase单独管理高频更新的企业信息和岗位详情，满足毫秒级随机查询；Java后端服务对接双存储引擎，Web前端基于ECharts渲染10类图表——包括城市热力图、薪资分布直方图、岗位增长趋势线、技能关键词云、行业占比环形图等。所有配置文件（hadoop-env.sh、core-site.xml等）、调度脚本（如t3.sh）、建表语句、列族定义、接口代码、页面模板和截图（存于imgs目录）全部包含。project File.pdf详解整体架构、各模块依赖关系及字段含义，README.md提供三步启动指南，已在Mac、Windows 10/11、主流Linux发行版实测通过。适合用于课程设计、毕设选题或快速理解Hadoop生态组件如何协同完成真实业务场景。

本文还有配套的精品资源，点击获取