全球酒店预订数据分析实战：从数据清洗到预测建模全流程

开头

“全球酒店预订数据分析”，听起来像是一个入门项目，但它真正做起来之后，你会发现它比想象中复杂得多。作为一门面向数据分析和Python学习的实操课程，这类项目通常包含完整的设计源文件、一份万字报告以及配套讲解，我前前后后带过几个朋友做过类似的项目，也亲眼见过不少人在数据处理环节翻了车。这篇博文我想站在一个做过的过来人角度，把这个项目的里里外外拆给你看——它到底在分析什么、数据长什么样、分析主线怎么搭、建模和报告该如何组织，以及整个过程中最容易踩的坑。

不管你是正在找课程设计灵感的学生，还是想积累一个可用于简历的数据分析作品，又或者是想快速掌握“数据清洗+可视化+建模+报告落地”全流程的Python学习者，这篇文章都适配，按这条主线走完，你大概能对一个完整的数据分析项目建立起整体的手感。

1. 项目整体拆解：先搞清楚酒店预订数据到底能分析什么

1.1 这个项目背后真实的业务场景

酒店预订数据，本质上是一个典型的“订单级”业务数据。每一行代表一条预订记录，里面包含顾客在哪个时间预订、计划何时入住、住几晚、住几个人、是否需要停车位、是否曾经取消过订单，以及最终这条预订有没有被取消。

为什么这个场景值得做？因为取消预订是酒店行业里一个真实且营收影响巨大的问题。客人预订了房间，酒店会预留库存，如果客人临期取消，那间房很可能就空置了，造成直接收益损失。所以数据分析的核心诉求很直接——能不能从历史订单里找到规律，提前识别出哪些订单有较大可能被取消，这样运营人员可以提前做超售策略、定金策略或挽留措施。

这个项目之所以成为课程设计、毕业设计里的“常客”，还有一个原因是数据集字段适中：没有海量特征，但也足够做出一套像样的分析流程。从我经手的几个类似项目来看，行业里常用的公开酒店订单数据一般包含以下这些核心字段：

1.2 用这些字段能回答哪些业务问题

很多初学者拿到的可视化任务只是“把每个字段画一遍图”，这也是很多项目做完但看起来很空洞的原因。真正好的分析必须从一个业务问题出发，我的建议是围绕三条主线来组织分析思路：

第一条主线是取消率画像。“哪类酒店、哪类客户、哪个渠道的订单更容易被取消？”这是所有后续分析的主心骨。

第二条主线是预订周期规律。“客人提前多久预订？提前多久取消？淡旺季和取消率有没有关系？”这一条需要通过对日期字段做加工得到“提前预订天数”“距离到店天数”这类衍生变量。

第三条主线是可预测性验证。“基于这些历史特征，能否训练一个模型来预测某个订单会不会被取消？”这一条对应的是机器学习建模环节，也是项目体现“含金量”的地方。

在写项目报告或者准备讲解的时候，整条故事线就可以是：先说业务痛点，再说数据处理，接着做统计分析与可视化，然后进入建模预测，最后落到业务建议和可执行方案。这样整份报告的叙事是完整的，而不会沦为一堆图表的堆砌。

2. 数据清洗与预处理：八成工作量都花在这里

2.1 看着“干净”的数据，实际上全是暗坑

我见过不少第一次做数据分析的人拿到源文件之后，兴奋地直接跑df.describe()然后开始画图，结果后面所有分析都建立在一堆脏数据上，结论全偏。这类酒店预订数据的清洗工作，远比想象中繁琐。我踩过的典型坑包括：

第一个坑是缺失值处理。比如客源地国家字段在超过百条记录里是空值，城市酒店里婴儿数量大量为0，这些都要有意识地统计和处理。处理方式不是简简单单地填充，而是要先判断字段缺失是不是有业务含义，比如婴儿数量为0可能就是“没有婴儿”，而不是数据缺失。

第二个坑是异常值。比如有一类预订记录，总住宿天数（住几晚）和总居住人数算出来是0，客人没入住但有后续的餐食消费记录，明显不正常。这类记录不能直接丢，也不能直接留，我通常的做法是先做一层“业务合理性过滤”，把它标记出来单独处理。

第三个坑是重复行。因为订单可能被多次修改或同步异常，数据集中会存在完全相同的重复记录。如果不提前去重，后面计算的所有汇总指标都会偏大，尤其是总量统计时影响非常直观。

第四个坑是日期格式不统一。有的源文件里日期是字符串有的是时间戳，有的带时分秒有的不带。如果直接拿来算间隔、算星期几，得到的结果很可能是一堆错误值。

2.2 一份可以照抄的清洗流程

基于我用Python处理这类数据的经验，清洗阶段的代码思路可以分为以下几个步骤，你可以直接参考：

import pandas as pd import numpy as np # 读入原始数据 df = pd.read_csv('hotel_bookings_data.csv', encoding='utf-8') # 1. 查看数据结构与初步缺失情况 print(df.shape) print(df.isnull().sum()) # 2. 去除完全重复的记录 df = df.drop_duplicates() # 3. 日期字段统一转换为 datetime date_cols = ['reservation_date', 'arrival_date', 'departure_date'] for col in date_cols: df[col] = pd.to_datetime(df[col], errors='coerce') # 4. 衍生字段：提前预订天数 df['lead_days'] = (df['arrival_date'] - df['reservation_date']).dt.days # 5. 处理异常值：住宿晚数或人数不为正数且状态为入住的记录 df = df[(df['stays_weeks'] >= 0) | (df['is_canceled'] == 0)] # 6. 对缺失字段做业务化处理 # 国家缺失可作为单独一档保留，不直接填充平均值 df['country'] = df['country'].fillna('unknown') # 7. 清洗后的数据单独保存 df.to_csv('hotel_bookings_clean.csv', index=False)

注意一点：清洗不是越狠越好。比如有的同学想把所有包含缺失值的行都直接删除，结果数据集少了一半，后面的分析完全没有统计意义了。正确做法是：先看缺失比例、再判断缺失原因、最后选择填充或删除方案。同时把所有处理步骤都记录在报告代码注释里，讲解的时候也可以说清楚“我为什么这样处理”。

我还想多说一句关于“清洗日志”的习惯。建议你顺手维护一个简单的清洗说明表，把每一步处理前、处理后的数据量都记下来。这不仅让报告显得严谨，排查问题时也方便回溯，还能在答辩或讲解时直接展示你的数据质量意识——这一点比很多花哨图表更能加分。

3. 探索性分析与可视化：让数据开口说话

3.1 第一刀先切“取消率”

探索性分析不要眉毛胡子一把抓。我的建议是先把“取消率”这个核心指标立起来，然后再不断切分维度对比。

总体取消率是一个非常直观的数字，比如数据集中总体取消率约在37%左右，这意味着每三笔订单就有一笔左右最终没入住。这个数字本身就能作为报告的引子，让人意识到问题的严重性。

接着按酒店类型切。通常城市酒店和度假酒店的取消率有明显差异，度假酒店因为更偏休闲预订、价格策略也更敏感，取消率往往更高。这种差异完全可以做成一张柱状图或分组箱线图，是报告里容易给人留下印象的第一张图。

还可以按照预订渠道切，看看直营渠道、中介渠道、公司协议渠道的取消率差异，从中引出“不同客源质量”的讨论。这个维度数据在源文件里通常比较齐全，直接用groupby聚合就能出结果。

3.2 时间节奏里的规律藏得最深

时间维度的分析是这个项目最容易做出亮点的地方。我建议至少做以下三张图：

第一张是按月份的预订量与取消量趋势图。你大概率会看到比较明显的季节性：暑期、年末是预订高峰，而取消量也会随之上升。这张折线图可以让报告瞬间脱离“堆砌图表”的层次，因为它是能直接导出业务建议的。

第二张是提前预订天数的分布与取消率关系图。通常提前很多天预订的订单，变更和取消的概率更大；临期预订的订单反而更“靠谱”。你可以画一个分箱柱状图，把提前0-7天、8-14天、15-30天、31-60天、60天以上的取消率都列出来，基本可以看到一条非常有解释力的上升曲线。

第三张是客源地国家的订单量与取消率散点/柱状图。不同客源地客户的消费习惯差异很大，比如有些国家区域的平均单价高、取消率也高，有些相对稳定。这种跨国对比在“全球酒店预订”这个标题下非常应景。

可视化的工具层面，我的个人习惯是用matplotlib+seaborn。核心代码大致长这样：

import matplotlib.pyplot as plt import seaborn as sns # 设置中文字体，避免乱码 plt.rcParams['font.sans-serif'] = ['SimHei'] plt.rcParams['axes.unicode_minus'] = False # 按月取消率趋势 df['arrival_month'] = df['arrival_date'].dt.month monthly_cancel = df.groupby('arrival_month')['is_canceled'].mean().reset_index() plt.figure(figsize=(10, 5)) sns.lineplot(data=monthly_cancel, x='arrival_month', y='is_canceled', marker='o') plt.title('各到达月份的取消率趋势') plt.xlabel('到达月份') plt.ylabel('取消率') plt.xticks(range(1, 13)) plt.tight_layout() plt.savefig('monthly_cancel_trend.png', dpi=150)

这里有个很容易被忽视的细节：中文乱码。在Windows上设置SimHei基本能解决，但换到Linux服务器或某些在线环境下，需要改用其他字体文件，甚至用英文标签兜底。讲解时候提到这个设置，能体现你对实际部署环境的考虑。

我在做这类项目时，还有一个习惯是把图和数据编号对齐。每张图的文件名、图里的数据范围、图背后的结论，都记录在一张Excel清单里。因为最后写万字报告的时候，你绝对不想一张图一张图重新找数据来源，这个过程会非常痛苦。

4. 建模与业务结论：预测谁会成为“放鸽子”的客人

4.1 特征工程与算法选型

当统计分析和可视化部分完成之后，项目就可以自然过渡到建模环节。这里要处理几个核心问题：

目标变量很明确，就是is_canceled字段，二分类问题。

特征选择上，我建议把重点放在几类特征上：预订渠道、历史取消次数、历史预订次数、提前预订天数、是否包含周末、餐食计划、停车位需求等。这些特征既有强业务含义，又基本不需要额外造假字段。另外，为了满足大多数模型对数值特征的要求，类别字段需要做编码处理，比如用pd.get_dummies或者LabelEncoder处理。

训练集和测试集一定要按时间切分，不要随机打乱切分。因为这是订单类数据，存在明显的时序属性，用后一段时间的数据做测试更能反映模型的真实泛化能力。很多初学者在这里喜欢用train_test_split(random_state=42)一刀切，看起来简单，但面试官或老师一问就会发现这个处理不够严谨。

模型选型上，我通常用三个模型做对比：逻辑回归作为可解释的baseline，随机森林作为默认效果benchmark，条件允许再加一个XGBoost或LightGBM看上限。这里给出一个非常简单的随机森林训练逻辑：

from sklearn.model_selection import TimeSeriesSplit from sklearn.ensemble import RandomForestClassifier from sklearn.metrics import classification_report, roc_auc_score features = ['lead_days', 'previous_cancellations', 'previous_bookings_not_canceled', 'adults', 'children', 'babies', 'parking_spaces'] X = df_encoded[features] y = df_encoded['is_canceled'] tscv = TimeSeriesSplit(n_splits=5) for train_index, test_index in tscv.split(X): X_train, X_test = X.iloc[train_index], X.iloc[test_index] y_train, y_test = y.iloc[train_index], y.iloc[test_index] model = RandomForestClassifier(n_estimators=200, max_depth=10, random_state=42) model.fit(X_train, y_train) y_pred = model.predict(X_test) print(classification_report(y_test, y_pred)) print('AUC:', roc_auc_score(y_test, y_pred))

我建议报告里放一张各模型效果对比表，包含准确率、精确率、召回率、AUC四个指标。不要只挑准确率来吹，因为对于这种正负样本比例大概在3:7的数据，准确率很容易虚高。真正重要的是AUC和召回率，尤其是你希望模型能帮酒店“尽量找出可能取消的订单”时，召回率的意义要比准确率大得多。

4.2 结果解读如何反哺业务

模型训练完不是终点，讲解和报告里最出彩的部分是“解释结果”。

首先可以从随机森林的特征重要性输出里，挑出排名前五的特征做解释。比如“提前预订天数”再次成为最重要的特征之一，说明决策逻辑和前面分析的时间规律完全吻合；历史取消次数排名靠前，说明客户行为惯性真实存在。这种“统计分析结论”和“模型特征重要性”互相印证的写法，能让整份报告的逻辑非常严密。

接着可以模拟一个业务场景：假设酒店每周收到1000个新订单，通过模型圈出预测取消概率最高的20%订单，并提前对这类订单采取“提高定金比例”或“电话确认”策略。按历史取消率估算，这部分订单里有一半以上最终会取消，如果能挽回其中一部分，直接收益就是每天多卖出几间原本会空置的房间。把这个量化逻辑算出来，报告的落点会非常实在。

提示：建模部分不要追高复杂度模型，关键是特征可解释性和业务落地思路。说服力来自于“为什么这个特征重要”，而不是“我的准确率有98%”。

5. 万字报告与配套讲解：如何呈现一份能打的分析报告

5.1 报告结构设计与图表规范

很多同学把报告写成“代码注释加截图”，这完全失去了报告的独立价值。一份高质量的万字报告，结构一般遵循以下节奏：

第一部分是项目概述，讲清楚数据分析的背景、数据来源、分析目标和主要结论。第二部分是数据说明，字段含义、数据量、清洗原则。第三部分是探索性分析，按时间、渠道、客源等维度给出图表与解读。第四部分是建模与评估，写清楚特征、模型、指标、结果解释。第五部分是总结与业务建议，把前面的分析收拢成可操作的三到五条建议。

这里有一条我个人反复强调的原则：图和表必须是“自解释”的。每张图都要有清晰的坐标轴标签、标题和数据说明；每张表都要有表头注释。因为报告会被打印出来阅读，如果图模糊或表头缺失，阅读体验会断崖式下降。

报告写作时还有一个容易被忽略的点：段落之间的衔接要像讲故事一样。比如你刚分析完取消率，下一段应该自然过渡到“为什么取消率这么高”，再引出对提前预订天数的分析，而不是冷冰冰地列出一堆图表编号。

5.2 讲解稿的关键逻辑

配套讲解视频或文稿是整个课程资料包里的重要组成部分。讲解和报告不一样，它更偏口语化、强调推导过程。

我建议的讲解主线是：从“酒店每天都有订单被取消，钱就这样白白流失”切入，然后逐层递进，先给数据概览，再讲清洗过程，接着带出可视化的核心发现，最后进入模型预测的思路和落地建议。

讲解稿里最忌讳的是对着PPT念代码。真正有效的讲解应该多问“为什么”——为什么提前12个月的预订容易取消？为什么历史取消次数多的客户再次取消概率高？为什么这里用随机森林而不是深度学习？每个“为什么”都能让讲解的含金量明显上一个台阶。

配合讲解的还有设计源文件的管理习惯。把你的Python脚本、清洗后数据集、可视化图片、报告文档、讲解稿按文件夹分类归档，形成一个自洽的资料包，既方便自己维护，也方便别人按图索骥地复现。

6. 常见问题与排查技巧实录

6.1 高频报错与处理方案

做数据分析项目最上头的时候，往往是深夜对着一个报错干瞪眼。我把这类酒店预订项目中最高频的几个问题整理成了一张速查表，希望你能少走弯路：

6.2 数据清洗与建模环节的避坑要点

除了报错本身，还有一些策略层面的坑值得单独讲。

第一，不要在原始文件上直接改数据。我见过有人动不动就跑df.dropna(inplace=True)把数据改得面目全非，最后找不回原始记录。我习惯的做法是永远保留原始数据文件，所有的清洗和衍生变量都只在副本上操作。

第二，不要为了追求准确率而过度处理标签。有人发现“取消”和“未取消”数据不平衡，就自作聪明做了一堆重采样，结果模型倒是看起来漂亮，但业务上根本解释不通。在处理不平衡问题之前，先想清楚目标到底是什么：是预测准确还是识别高风险订单？这两者对应的处理策略完全不同。

第三，报告里的数字要有来源。每一处关键的统计数字，最好都能对应到代码或图表，这样讲解时被追问也能从容应对。顺便说一句，在报告末尾放一个“数据字典附注”或“代码文件清单”，会让整体专业度提升很多。

第四，图片要统一风格。整套报告的图表，尽量使用一致的配色、字体大小、图例位置，这是很多初版报告看起来“业余”的最直接原因。实际上，只需要在matplotlib里设置一回全局参数，全篇图片的观感就立刻统一了。

6.3 项目后续还能怎么扩展

如果你的时间充裕，这个项目还可以在现有基础上做几层扩展。比如：把酒店类型、客户类型、渠道类型各自的取消概率做成一个简单的业务评分卡；把预测结果和房价数据结合，模拟一个超售决策；或者引入更多外部数据，比如当地节假日、天气事件，看它们对取消率的影响。这些扩展方向不需要大改现有代码，但会让报告的分析深度明显拉开档次。

结尾

我记得自己第一次完整做完这个项目的时候，最大的感受是“数据清洗怎么比建模还累”。当时为了把日期字段处理好，反复折腾了快两天，后来才意识到这个看似枯燥的步骤，恰恰决定了后面所有图表和分析结论的可靠性。我后来也帮别人看项目，发现大多数问题不是出在算法不够高级，而是在数据清洗和业务解释的环节，数据没弄干净、图没做规范，报告讲起来就处处露怯。

所以如果你也正在啃这个项目，我的建议就是：把重心先放在“把数据弄明白”这件事上，真正理解每一列是怎么来的、存在什么异常、分析时要注意什么，再谈可视化和建模。等这套流程走完一遍，你会明显感觉到自己对数据分析项目的整体掌控力上了一个台阶。

最后分享一个小技巧：报告里所有图表，建议统一保存为高分辨率的PNG或PDF格式，嵌入文档时按统一尺寸缩放宽高比。这个小细节看着不起眼，但排版出来的成品观感会清爽非常多。