苏盆栽1. 项目概述：当旅游遇上数据分析
去年帮朋友旅行社做数据化改造时，我亲手搭建过一个旅游推荐系统的原型。这个用Django+Migrations+MySQL构建的系统，上线三个月就让定制游转化率提升了27%。今天就把这套经过实战验证的技术方案拆解给大家，特别会重点讲解如何用Migrations优雅地管理旅游数据模型变更——这是大多数教程里不会告诉你的实战细节。
典型的旅游推荐系统需要处理三类核心数据：用户画像（年龄/偏好/消费习惯）、旅游产品库（线路/酒店/景点）以及行为日志（搜索/收藏/购买）。当这些数据量超过百万级时，MySQL的索引优化和Migrations的版本控制就变得至关重要。我曾见过一个没做好migration规划的团队，因为一次错误的schema变更导致整个推荐算法失效。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 技术架构设计
2.1 为什么选择MySQL
在对比MongoDB和PostgreSQL后，我们最终选择MySQL 8.0作为主数据库，主要基于三点考量：
- 旅游产品的关联查询复杂度（如"查找所有包含亲子酒店的海南线路"）需要成熟的JOIN优化
- ACID事务特性对订单处理至关重要
- GIS空间索引对景点距离计算的支持
配置示例：
sql复制CREATE TABLE `scenic_spots` (
`id` bigint NOT NULL AUTO_INCREMENT,
`name` varchar(100) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL,
`location` point NOT NULL SRID 4326,
`tags` json DEFAULT NULL,
PRIMARY KEY (`id`),
SPATIAL KEY `idx_location` (`location`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;
2.2 Migrations的实战技巧
Django的makemigrations命令虽然方便，但在旅游行业特有的数据变更场景下需要特别注意：
- 节假日季节性字段（如春节特别推荐标志）需要添加自定义迁移操作
- 景点开放时间这类范围字段的变更要用SeparateDatabaseAndState
- 永远避免在生产环境直接修改migrations文件
我曾用这个方案处理过景区临时闭园的数据变更：
python复制# migrations/0023_emergency_close.py
from django.db import migrations
def update_scenic_status(apps, schema_editor):
ScenicSpot = apps.get_model('tourism', 'ScenicSpot')
ScenicSpot.objects.filter(
id__in=[1023, 1567]
).update(
status='closed',
close_reason='typhoon'
)
class Migration(migrations.Migration):
dependencies = [
('tourism', '0022_scenicspot_status'),
]
operations = [
migrations.RunPython(update_scenic_status),
]
3. 核心数据模型设计
3.1 用户画像模型
旅游行业的用户模型需要特别关注时空特征：
python复制class UserProfile(models.Model):
TRAVEL_STYLE_CHOICES = [
('backpacker', '背包客'),
('family', '亲子游'),
('couple', '情侣游'),
]
user = models.OneToOneField(User, on_delete=models.CASCADE)
preferred_seasons = models.CharField(max_length=50) # 如"spring,autumn"
travel_style = models.CharField(max_length=20, choices=TRAVEL_STYLE_CHOICES)
budget_range = models.JSONField(default=dict) # {"min": 1000, "max": 5000}
last_modified = models.DateTimeField(auto_now=True)
class Meta:
indexes = [
models.Index(fields=['travel_style']),
models.Index(fields=['last_modified']),
]
3.2 旅游产品模型
采用继承式设计便于扩展不同产品类型：
python复制class TourismProduct(models.Model):
title = models.CharField(max_length=200)
base_price = models.DecimalField(max_digits=10, decimal_places=2)
tags = models.ManyToManyField('ProductTag')
class Hotel(TourismProduct):
STAR_CHOICES = [(i, f'{i}星') for i in range(1,6)]
star_level = models.PositiveSmallIntegerField(choices=STAR_CHOICES)
amenities = models.JSONField(default=list) # ["wifi","pool"]
class TourRoute(TourismProduct):
days = models.PositiveSmallIntegerField()
departure_city = models.ForeignKey(City, on_delete=models.PROTECT)
4. 推荐算法实现
4.1 混合推荐策略
我们采用基于内容+协同过滤的混合方案：
- 内容过滤：计算用户偏好标签与产品标签的余弦相似度
- 协同过滤：找出相似用户群体喜欢的产品
- 时空加权：对用户当前位置和当前季节的产品加权
核心计算逻辑：
python复制def calculate_similarity(user, product):
# 内容相似度
content_score = cosine_similarity(
user.preferred_tags_vector,
product.tags_vector
)
# 时空系数
time_coef = 1.0
if product.season == get_current_season():
time_coef = 1.3
# 最终得分
return content_score * time_coef * popularity_coef(product)
4.2 MySQL优化技巧
在千万级数据量下，这些优化手段使查询性能提升8倍：
- 为JSON字段添加生成列索引：
sql复制ALTER TABLE user_profile
ADD COLUMN budget_min INT AS (JSON_EXTRACT(budget_range, '$.min')) STORED,
ADD INDEX idx_budget_min (budget_min);
- 使用窗口函数处理排名：
sql复制SELECT
product_id,
DENSE_RANK() OVER (PARTITION BY category ORDER BY score DESC) as rank
FROM
recommendation_scores
WHERE
user_id = 123;
5. 性能监控与调优
5.1 关键指标监控
我们在生产环境配置了这些监控项：
- 推荐响应时间P99 < 300ms
- MySQL查询缓存命中率 > 85%
- 长事务数量 < 5/min
使用Prometheus的监控配置示例：
yaml复制- name: mysql_recommend
rules:
- alert: SlowRecommendQuery
expr: rate(mysql_query_time_seconds{query_type="recommend"}[5m]) > 0.3
for: 10m
5.2 常见问题排查
遇到过的典型问题及解决方案：
-
推荐结果重复率高
- 原因：协同过滤的邻域大小设置不当
- 修复：动态调整KNN的k值
python复制def dynamic_k(user): base_k = 50 if user.activity_level > 0.8: return base_k * 2 return base_k -
新旅游产品冷启动问题
- 解决方案：构建临时内容特征桥接
sql复制UPDATE new_products SET temp_features = ( SELECT AVG(features) FROM similar_products ) WHERE created_at > NOW() - INTERVAL 7 DAY;
6. 数据迁移实战案例
去年帮一个旅行社做系统升级时，需要在不中断服务的情况下将用户收藏数据从旧模式迁移到新模式。旧模式使用单独的收藏表，新模式改为JSON字段存储。
我们是这样操作的：
- 先创建允许为空的JSON字段
- 编写数据迁移脚本分批处理
- 最后才删除旧字段
关键迁移代码：
python复制def migrate_favorites(apps, schema_editor):
UserProfile = apps.get_model('tourism', 'UserProfile')
OldFavorite = apps.get_model('legacy', 'Favorite')
for profile in UserProfile.objects.all():
favorites = OldFavorite.objects.filter(user=profile.user)
profile.new_favorites_field = {
'products': [f.product_id for f in favorites],
'last_updated': timezone.now()
}
profile.save(update_fields=['new_favorites_field'])
这个方案实现了零停机迁移，期间系统始终可用。整个迁移过程处理了230万条收藏记录，耗时37分钟。
7. 安全防护措施
旅游系统尤其要注意这些安全实践：
-
SQL注入防护
- 永远使用ORM或参数化查询
- 对原生SQL进行静态分析
python复制# 错误示范 cursor.execute(f"SELECT * FROM products WHERE id = {user_input}") # 正确做法 Product.objects.raw('SELECT * FROM products WHERE id = %s', [user_input]) -
敏感数据加密
- 用户身份证号等PII数据使用MySQL加密函数
sql复制INSERT INTO users ( name, id_card ) VALUES ( '张三', AES_ENCRYPT('110101199003072234', 'encryption_key') ); -
迁移文件校验
- 在CI/CD流程中添加migration验证步骤
bash复制
python manage.py makemigrations --dry-run --check
8. 扩展思考
在实际运营中，我们发现旅游推荐系统还需要考虑：
-
实时个性化：用Redis存储用户最近浏览记录
python复制r = redis.Redis() r.zadd(f'user:{user_id}:recent_views', {product_id: time.time()} ) -
季节性调整：动态修改推荐权重
sql复制UPDATE recommendation_weights SET season_factor = CASE WHEN MONTH(NOW()) IN (12,1,2) THEN 1.5 WHEN MONTH(NOW()) IN (7,8) THEN 1.3 ELSE 1.0 END; -
A/B测试框架：验证推荐策略效果
python复制class RecommendationExperiment: VARIATIONS = { 'control': {'k': 50, 'mix_ratio': 0.5}, 'variant1': {'k': 75, 'mix_ratio': 0.6} } @classmethod def get_params(cls, user_id): bucket = user_id % 100 return cls.VARIATIONS['variant1'] if bucket < 50 else cls.VARIATIONS['control']
这套系统经过两年迭代，现在每天处理超过500万次推荐请求，MySQL实例稳定运行在60%负载以下。最关键的经验是：旅游行业的数据变化频繁，必须建立完善的migration机制来应对各种业务变更。