快手有海量短视频，如何设计视频存储与检索系统？考虑存储成本、检索效率，以及如何支持视频搜索（如按内容、标签、时间）。
答案
1) 【一句话结论】采用动态冷热分离的分层存储架构，结合多级索引（元数据+内容特征向量），通过分布式系统平衡存储成本与检索效率，支持按内容、标签、时间等多维度搜索。
2) 【原理/概念讲解】存储成本与检索效率的平衡核心是动态冷热分离：热门视频（访问频率高、用户行为活跃、视频属性（标签热度、时长）显示潜力）存SSD（如Ceph SSD池），冷视频（访问少、新上传但可能成为热门）存HDD或对象存储（如MinIO），降低存储成本。检索效率上，元数据（标签、时间、用户信息）用数据库（如MongoDB）或搜索引擎（如Elasticsearch）索引，内容检索用视频特征（关键帧、视觉/音频特征）存向量数据库（如FAISS），通过向量相似度匹配。类比：就像图书馆，热书（热门视频）放在书架（SSD），冷书（冷视频）放在书库（HDD），检索时先查书名（元数据）或内容摘要（特征），快速定位。
3) 【对比与适用场景】
存储方案对比：
| 方案 | 定义 | 特性 | 使用场景 | 注意点 |
|---|---|---|---|---|
| 分布式文件系统（如Ceph） | 分布式存储，统一命名空间 | 高可扩展，数据冗余（如3副本），写入延迟较高 | 大规模冷热数据存储 | 管理复杂，需配置CRUSH算法 |
| 对象存储（如MinIO） | 对象存储，键值对 | 弹性扩展，按需付费，读取延迟较高 | 冷数据、备份、归档 | 适合不频繁访问，写入性能一般 |
| 关系/NoSQL数据库（如MongoDB） | 结构化/半结构化存储 | 支持复杂查询，写入性能高 | 元数据（标签、时间、用户信息） | 存储成本较高，不适合海量冷数据 |
索引方案对比：
| 方案 | 定义 | 特性 | 使用场景 | 注意点 |
|---|---|---|---|---|
| 倒排索引（如Elasticsearch） | 元数据索引 | 查询速度快，支持多条件（标签、时间、用户） | 标签、时间、用户搜索 | 向量检索支持弱，需结合内容索引 |
| 向量数据库（如FAISS） | 视频特征向量索引 | 高效向量相似度匹配（如L2距离），计算资源消耗大 | 视频内容搜索（如相似视频推荐） | 维度高，需分布式部署（如FAISS on GPU） |
4) 【示例】（伪代码存储与检索流程）：
# 视频上传处理（含分布式存储分片、副本、向量索引更新）
def upload_video(video_file, metadata):
# 分布式存储分片（Ceph RBD分片数=10）
video_id = store_video_blocks(video_file, shards=10) # 分块存Ceph RBD
# 副本同步（3副本）
sync_replicas(video_id, replicas=3) # Ceph的CRUSH算法确保数据冗余
# 元数据存储（MongoDB）
store_metadata(video_id, metadata)
# 视频特征提取（关键帧、视觉特征）
features = extract_video_features(video_file)
# 向量数据库索引更新（每日凌晨批量更新）
update_vector_index(video_id, features, timestamp=datetime.now())
return video_id
# 视频检索（按标签+时间，含缓存预热）
def search_videos(query):
# 缓存预热（每天凌晨将热门视频特征加载到Redis）
if not is_cache_preheated():
preheat_cache() # 调用定时任务加载热门视频特征
# 元数据查询（Elasticsearch）
meta_res = query_metadata(query.tags, query.time_range)
# 内容查询（FAISS，查询缓存+实时索引）
vec_res = query_vector_features(query.features, top_k=10, use_cache=True)
# 合并结果（去重排序）
return merge_results(meta_res, vec_res)
# 定时任务（每日凌晨）
def preheat_cache():
hot_videos = get_hot_videos() # 根据冷热分离动态判断的热视频
for vid in hot_videos:
features = get_video_features(vid) # 从向量数据库获取
set_redis_cache(vid, features) # 加载到Redis缓存
5) 【面试口播版答案】（约90秒）：
“面试官您好，针对快手海量短视频的存储与检索，核心思路是动态冷热分离的分层存储架构，结合多级索引（元数据+内容特征向量）。首先，存储成本方面，我们采用冷热分离：热门视频（访问频率高、用户行为活跃、视频属性显示潜力）存SSD（如Ceph SSD池），冷视频（访问少、新上传但可能成为热门）存HDD或对象存储（如MinIO），降低存储成本。检索效率上，元数据（标签、时间、用户信息）用Elasticsearch索引，内容检索用视频特征（关键帧、视觉/音频特征）存FAISS向量数据库，通过向量相似度匹配。这样既能平衡成本，又能支持按内容、标签、时间搜索。具体来说，视频上传时，分块存储（Ceph RBD分片数10），元数据写入索引，特征存向量库；检索时，先查元数据（Elasticsearch），再查内容（FAISS，查询Redis缓存减少延迟），合并结果返回。另外，冷热分离的判断结合机器学习模型（如梯度提升树），综合访问次数、用户行为（分享数、点赞数、评论数）、视频属性（标签热度、时长），动态调整阈值，确保潜在热门视频及时迁移至SSD。”
6) 【追问清单】
- 问：冷热分离的具体动态判断机制？
答：结合访问次数、用户行为（分享数、点赞数、评论数），同时引入机器学习模型（如基于历史数据训练的回归模型），当预测热度高于阈值（如7天内访问次数+预测评分>0.8）时，即使访问次数低也归为“热数据”。 - 问：内容检索的实时性如何保证？
答：特征提取离线处理，索引采用每日凌晨批量更新（增量更新），检索时查询Redis缓存（热门视频特征缓存命中率≥90%），减少实时计算压力。 - 问：如何处理视频搜索的冷启动问题？
答：结合元数据（标签、时间）和用户行为（历史观看），推荐相似视频；新视频上传后，先存HDD，若短期内有高访问量，自动迁移至SSD。
7) 【常见坑/雷区】
- 冷热分离判断标准单一：仅考虑访问次数，未结合用户行为和视频属性，导致潜在热门视频遗漏。
- 内容检索实时性不足：未采用增量更新和缓存预热，导致搜索结果延迟。
- 技术选型错误：用传统文本索引处理视频内容，无法匹配视觉/音频特征，影响检索准确率。
- 索引维护成本高：未考虑索引更新延迟，导致检索结果过时。
- 分布式系统扩展性不足：分片策略不合理（如Ceph分片数过少），导致写入或查询瓶颈。