在360的投放系统中，用户行为日志（如点击、曝光、转化）数据量极大（PB级），需支持实时分析（如实时CTR计算）和离线回溯查询（如7日用户画像），请设计数据存储与处理方案。

360Web服务端开发工程师-投放方向难度：中等

答案

1) 【一句话结论】采用“流式实时处理+分布式离线存储”双轨方案，通过Kafka作为数据管道，Flink实现实时CTR等分析并写入HDFS实时表，HDFS+Hive支撑离线7日用户画像等查询，兼顾PB级数据的高吞吐与低延迟需求。

2) 【原理/概念讲解】老师口吻：同学们，360投放系统的用户行为日志（点击、曝光、转化）数据量极大（PB级），所以需要分“实时分析”和“离线回溯”两种场景设计。

实时分析（如实时CTR计算）要求低延迟（秒级），需用流式处理引擎（如Flink）。
离线回溯（如7日用户画像）允许分钟级延迟，需用分布式存储+SQL引擎（如HDFS+Hive）。
具体来说：
数据管道用Kafka，因为它能解耦生产者（日志采集）和消费者（计算/存储），支持高吞吐（PB级数据写入）和持久化（避免数据丢失）。
实时计算用Flink，它支持事件时间处理（解决日志乱序问题）、状态管理（如用户行为计数状态），能快速计算CTR（点击数/曝光数）。
离线存储用HDFS+Hive，HDFS是分布式文件系统，适合存储PB级数据；Hive提供SQL接口，方便离线查询（如7日用户画像）。
比如，点击日志写入Kafka后，Flink消费并计算实时CTR，结果写入HDFS的“realtime_ctr”表（Hive表），供实时查询；同时，历史日志写入HDFS，Hive生成“user_profile_7d”表，供离线查询。

4) 【示例】（以实时CTR计算为例，伪代码）：

// 生产者将点击/曝光日志写入Kafka主题“user_action”
producer.send("user_action", "{\"user_id\":\"123\",\"action\":\"click\"}")  
producer.send("user_action", "{\"user_id\":\"123\",\"action\":\"exposure\"}")  

// Flink消费Kafka并计算实时CTR
FlinkJob {  
  // 从Kafka读取数据  
  stream = KafkaSource("user_action")  
  // 按用户ID分组，统计曝光数和点击数  
  grouped = stream.keyBy("user_id")  
  state = grouped  
    .map(new ClickExposureMapper())  
    .keyBy("user_id")  
    .reduce(new CTRReducer())  
  // 输出到HDFS实时表  
  state.write(new HDFSWriter("hdfs://path/realtime_ctr"))  
}  

// Hive实时查询某用户实时CTR  
SELECT * FROM realtime_ctr WHERE user_id='123' ORDER BY timestamp DESC LIMIT 1

5) 【面试口播版答案】（约90秒）：
“面试官您好，针对360投放系统PB级用户行为日志的实时分析（如实时CTR）和离线回溯（如7日用户画像）需求，我设计的方案是采用‘流式实时处理+分布式离线存储’双轨架构。具体来说，通过Kafka作为数据管道，将点击、曝光等行为日志实时写入；用Flink处理实时流，计算CTR等指标并写入HDFS的实时表，支持秒级查询；同时，历史日志存储在HDFS，用Hive生成7日用户画像等离线表，满足分钟级以上的回溯需求。这样既保证了实时分析的低延迟，又支撑了离线查询的大规模数据处理。”

6) 【追问清单】

问题1：实时延迟如何保证？
回答要点：通过Flink的事件时间处理、状态管理（如检查点），以及Kafka的高吞吐分区策略（如按用户ID分区）。
问题2：离线存储的查询性能如何优化？
回答要点：Hive使用分区表（按日期分区）、索引表（如按user_id建索引），以及HDFS的分布式读取优化。
问题3：数据一致性如何保障？
回答要点：Kafka的持久化机制（commit log）、Flink的Exactly-Once状态处理（如使用Kafka作为状态后端），以及HDFS的副本机制。
问题4：容错性如何设计？
回答要点：Flink的容错机制（检查点、任务重试）、Kafka的副本机制（保证消息不丢失）、HDFS的副本存储（数据冗余）。
问题5：数据格式统一性如何处理？
回答要点：定义标准的数据格式（如JSON或Avro），所有生产者写入Kafka前统一序列化，消费者统一反序列化。

7) 【常见坑/雷区】

坑1：只考虑实时或离线单一方案（如只用Flink做所有处理，无法支撑离线查询；或只用HDFS+Hive，无法满足实时低延迟需求）。
坑2：消息队列分区策略不当（若Kafka分区数不足，会导致Flink任务处理能力受限，延迟增加）。
坑3：离线存储索引缺失（Hive表无分区或索引，导致7日用户画像查询延迟过长（如分钟级），无法满足业务需求）。
坑4：实时计算状态管理错误（Flink状态未持久化，导致重启后状态丢失，实时指标计算错误）。
坑5：数据格式不统一（不同生产者写入Kafka的数据格式不一致，导致Flink消费者解析失败，影响实时处理）。