360手机卫士的AI应用中，需要处理海量用户行为日志，请设计一个数据存储与查询方案，确保低延迟查询和可扩展性。

1) 【一句话结论】采用“时序数据库+宽表存储+分布式缓存”的混合方案，通过时序数据库支撑低延迟时间范围查询，宽表存储支撑多维度聚合分析，分布式缓存加速热点数据访问，兼顾低延迟与可扩展性。

2) 【原理/概念讲解】老师口吻，解释关键概念：

• 时序数据库（如InfluxDB）：专为时间序列数据设计，按时间点存储（时间+数值），支持时间范围聚合（如最近7天用户行为），列式存储压缩率高，查询速度快。类比：时间轴上的“时间点记录”，适合按时间维度查询。
• 宽表存储（如ClickHouse）：列式数据库，适合多维度结构化数据（用户ID、应用ID、行为类型等），通过列式存储减少I/O，支持复杂聚合（如按应用统计行为次数）。类比：多维度的“表格”，适合多列聚合分析。
• 分布式缓存（如Redis）：内存存储，用于缓存热点数据（如高频查询的统计结果），毫秒级访问，减少数据库压力。类比：快速访问的“缓存池”，加速高频查询。

3) 【对比与适用场景】

数据库类型	数据类型	存储方式	查询特点	适用场景
时序数据库（如InfluxDB）	时间序列（时间+数值）	时间索引+列式存储	支持时间范围查询（如最近N天），低延迟	用户行为日志按时间点记录，时间范围查询（如实时统计）
宽表存储（如ClickHouse）	多维度结构化数据	列式存储（按列压缩）	支持多列聚合（如按用户/应用聚合行为），高压缩比	聚合分析（如用户行为分布、应用活跃度）
分布式缓存（如Redis）	键值/哈希/列表	内存存储	毫秒级访问	热点数据缓存（如高频查询的统计结果）

注意点：时序数据库不适合多维度复杂查询，宽表不适合实时时间范围查询，缓存需考虑击穿/雪崩。

4) 【示例】系统设计：

• 数据写入：用户行为日志（如用户ID, 应用ID, 行为类型, 时间戳, 事件值）写入InfluxDB（时间序列），同时写入ClickHouse（宽表，表结构：user_id, app_id, action_type, value, ts）。
• 数据查询：
  • 低延迟查询（如最近1小时用户行为）：通过InfluxDB的timeSeries查询；
  • 聚合查询（如按应用统计行为次数）：通过ClickHouse的聚合函数（如sum, count）；
  • 热点数据（如实时活跃用户数）：缓存到Redis（键：active_users, 值：用户ID列表），查询时先查Redis，未命中则查询数据库并更新缓存。

伪代码（写入InfluxDB）：

from influxdb import InfluxDBClient
client = InfluxDBClient(host='influxdb', port=8086, database='user_behavior')
data = {
    "measurement": "user_action",
    "tags": {"user_id": "u123", "app_id": "a456"},
    "fields": {"action_type": "click", "value": 1},
    "time": "2023-10-27T10:30:00Z"
}
client.write_points([data])

伪代码（查询InfluxDB）：

query = "SELECT value FROM user_action WHERE user_id='u123' AND app_id='a456' AND time > now() - 3600s"
result = client.query(query)

5) 【面试口播版答案】（约90秒）
“面试官您好，针对海量用户行为日志的存储与查询需求，我设计了一个混合方案，核心是结合时序数据库、宽表存储和分布式缓存，兼顾低延迟和可扩展性。具体来说，首先，用户行为日志按时间序列存储在InfluxDB中，因为它天然支持时间范围查询，比如最近1小时的点击行为，延迟低；然后，同时写入ClickHouse作为宽表，用于多维度聚合分析，比如按应用统计用户行为次数，列式存储压缩率高，查询速度快；另外，高频查询的热点数据（如实时活跃用户数）缓存到Redis，毫秒级访问，减少数据库压力。这样，时间范围查询用InfluxDB，聚合查询用ClickHouse，热点数据用缓存，三者结合，既能保证低延迟，又能通过分布式架构扩展，应对海量数据。”

6) 【追问清单】

• 问：如何处理数据分区，避免查询时扫描大量数据？
  答：按时间范围和用户ID/应用ID分区，比如InfluxDB按时间分桶，ClickHouse按user_id分表，减少查询扫描范围。
• 问：数据写入时序数据库和宽表的时间差如何保证？
  答：使用消息队列（如Kafka）异步写入，确保数据最终一致，延迟在秒级内。
• 问：缓存击穿或雪崩如何处理？
  答：缓存加互斥锁（分布式锁），或者预加载热点数据；雪崩用限流（如令牌桶）。
• 问：系统扩容时，如何保证查询一致性？
  答：数据库分片（如InfluxDB的shard，ClickHouse的partition），缓存集群（Redis集群），扩容时负载均衡。
• 问：数据备份和恢复方案？
  答：时序数据库的快照备份，宽表的定期备份，缓存数据持久化（如RDB），确保数据安全。

7) 【常见坑/雷区】

• 坑1：只选一种数据库，比如只用关系型数据库，无法满足时间序列和聚合查询的低延迟需求。
• 坑2：忽略缓存，导致所有查询都访问数据库，性能下降，高并发时可能超时。
• 坑3：数据分区不合理，比如按时间分区但查询跨多个分区，导致扫描大量数据，延迟高。
• 雷区：数据一致性，比如写入时序和宽表的时间差过大，影响分析准确性。
• 雷区：未考虑数据压缩，导致存储空间大，查询时I/O高。