在公共安全系统中，佳都科技需要构建视频大数据分析平台，处理海量视频流（如城市监控摄像头数据）。请设计数据库架构，包括数据存储（结构化/非结构化）、查询优化策略（如索引设计、分库分表），以及如何应对数据量爆发式增长。

佳都科技解决方案工程师/售前工程师等难度：中等

答案

1) 【一句话结论】：针对公共安全视频大数据分析平台，采用“结构化元数据+视频流混合存储”架构，结合时间+摄像头ID的Sharding Key分库分表、多级索引（B+树+倒排索引）、Flink实时处理与Redis缓存，以及多区域容灾（RPO≤5分钟，RTO≤30分钟），支撑海量视频流的存储、查询与实时分析需求。

2) 【原理/概念讲解】：

数据存储分类：
- 结构化数据（如摄像头ID、时间戳、事件标签）：选择关系型数据库（如MySQL），因需强事务性（ACID）、数据一致性保障，适合存储元数据（类比：元数据是视频的“目录”，需精确索引）。
- 非结构化数据（视频流、图像帧）：采用分布式文件系统（如HDFS）或对象存储（如阿里云OSS），因具备高吞吐、水平扩展能力，适配海量视频文件的存储需求（类比：视频流是“内容”，需大容量存储）。
查询优化策略：
- 索引设计：结构化数据用B+树索引（如时间戳+摄像头ID组合索引），加速范围查询（如按时间检索）；非结构化数据用Elasticsearch倒排索引，支持内容检索（如人脸、行为分析）。
- 分库分表：垂直分库（按业务，如监控数据、报警数据分库）或水平分表（按时间，如按天分表），通过Sharding Key（时间+摄像头ID）拆分数据，避免单表过大，提升并发与查询性能。
数据量增长应对：
- 数据压缩：视频流采用H.265压缩（压缩比50%），依据是测试不同压缩比下，50%压缩比下存储节省约50%，视频质量损失可接受（画面清晰度无显著下降）；元数据用Zstandard压缩（JSON压缩），降低数据库存储压力。
- 流处理与缓存：使用Flink实时分析视频流（如运动检测、人脸识别），将结果写入Elasticsearch（查询）或MySQL（结构化存储）；缓存热点元数据（如常用摄像头数据）到Redis（LRU淘汰策略），降低数据库查询压力。
- 容灾方案：多区域部署（如阿里云可用区A、B），数据定期备份（HDFS快照每小时一次，OSS每日全量备份），MySQL启用binlog复制，确保RPO≤5分钟、RTO≤30分钟。

3) 【对比与适用场景】：

存储方案	定义	特性	使用场景	注意点
关系型数据库	结构化数据存储	强事务（ACID）、B+树索引高效	元数据（结构化）、事务性查询	单表数据量有限（通常<10亿）
分布式文件系统	海量非结构化数据存储	高吞吐、可扩展、容错	视频流、图像帧	读取慢，写入快（顺序写）
Elasticsearch	分布式搜索与分析引擎	倒排索引、实时搜索	内容检索（如人脸、行为分析）	写延迟高，适合查询
分库分表	数据库水平/垂直拆分	提升并发、查询性能	海量数据、高并发查询	需处理数据一致性（Sharding Key选择）
流处理与数据库集成	流处理框架（如Flink）与数据库协同	实时分析、数据同步	实时视频流分析、结果存储	需考虑数据格式转换与延迟
数据压缩与容灾	视频流压缩+多区域容灾	减少存储、保障可用性	数据量爆发、高可用要求	压缩比与质量平衡，备份策略需定期验证

4) 【示例】：

元数据存储（MySQL）：

CREATE TABLE video_metadata (
    id BIGINT PRIMARY KEY AUTO_INCREMENT,
    camera_id VARCHAR(50) NOT NULL,
    timestamp DATETIME NOT NULL,
    location JSON,
    event_type VARCHAR(20),
    index (camera_id, timestamp)  -- B+树索引
);

视频流存储（HDFS）：
视频文件路径：/hdfs/video/{camera_id}/{timestamp}.mp4
分库分表示例（按时间分库）：
- 库1：存储2023年1月-6月的视频元数据。
- 库2：存储2023年7月-12月的视频元数据。
- 表按天分表：video_metadata_20230101、video_metadata_20230102等。
流处理与数据库集成（Flink写入Elasticsearch）：
Flink作业读取HDFS视频流，提取特征后，将结果（如“人脸识别结果”）写入Elasticsearch索引（video_analysis），支持实时告警。

5) 【面试口播版答案】：
“面试官您好，针对视频大数据分析平台，我设计的架构是混合存储+分库分表+多级索引+流处理协同。结构化元数据（如摄像头ID、时间戳）用MySQL，因为需要强事务和一致性；视频流用HDFS/OSS，处理海量数据。查询优化上，结构化数据建B+树索引（时间戳+摄像头ID），加速按时间范围查询；非结构化用Elasticsearch倒排索引，支持内容检索（如人脸识别）。分库分表按时间分库（月为单位），按天分表，Sharding Key是时间+摄像头ID，避免单表过大。应对数据量增长，视频流用H.265压缩（50%压缩比），元数据用Zstandard压缩；用Flink实时分析，结果写入Elasticsearch；缓存热点元数据到Redis。容灾方面，多区域部署（如阿里云可用区），数据定期备份，MySQL启用binlog复制，RPO≤5分钟，RTO≤30分钟。这样既能保证数据一致性，又能高效处理海量视频流。”

6) 【追问清单】：

问题1：如何保证分库分表后的数据一致性？
回答要点：通过Sharding Key（时间+摄像头ID）设计，结合最终一致性（异步binlog复制），以及Redis缓存双写机制，确保跨库查询数据一致。
问题2：流处理框架如何控制延迟？
回答要点：Flink设置窗口大小为1秒，缓冲区10MB，确保实时分析延迟≤1秒，满足实时告警需求。
问题3：H.265压缩比50%的选择依据？
回答要点：测试不同压缩比（如30%、50%、70%），50%压缩比下存储节省约50%，视频质量损失可接受（画面清晰度无显著下降）。
问题4：容灾方案的具体RPO/RTO指标？
回答要点：RPO≤5分钟（数据丢失不超过5分钟），RTO≤30分钟（业务恢复时间不超过30分钟），通过多区域备份和binlog复制实现。

7) 【常见坑/雷区】：

坑1：Sharding Key选择不当（如按摄像头ID分库），导致热点数据集中，查询效率低。
坑2：流处理延迟控制不足（如窗口设置过大），导致实时分析延迟高，无法满足实时告警需求。
坑3：H.265压缩比选择过高（如70%），导致视频质量严重下降，影响分析准确性。
坑4：容灾方案未量化RPO/RTO，表述为“符合业务要求”，缺乏具体指标，可信度不足。
坑5：未考虑非结构化视频流存储，导致无法支持内容分析（视频流占数据量90%以上）。