在360的日志存储项目中，需要处理PB级别的数据。请分享你在项目中的经验，包括如何设计存储扩展性、如何处理数据增长带来的性能问题，以及如何优化存储成本。

1) 【一句话结论】在PB级日志存储中，通过冷热分离的分层存储架构（热数据用分布式文件系统，冷数据用云对象存储）、数据分片与压缩技术，结合动态扩容与智能迁移策略，实现了存储扩展性、性能与成本的平衡。

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

• 分布式存储扩展性：通过水平扩展（分片、副本），将数据分散到多节点，支持数据量增长。类比：超市货架（热数据）和仓库货柜（冷数据），货架数量可增加，仓库容量可扩展。
• 冷热数据分离：根据数据访问频率（如TTL）划分热/冷数据，热数据存储在高速存储（如HDFS），冷数据迁移到低成本存储（如S3）。
• 数据压缩：使用LZ4、Snappy等算法减少存储空间，降低成本。
• 成本优化：按需付费模式，冷数据长期存储成本低，热数据按小时计费。

3) 【对比与适用场景】

方案	定义	特性	使用场景	注意点
分布式文件系统（如HDFS）	集群式文件系统，数据分块存储	高可靠性（副本），适合热数据，但成本高	日志热数据，需要高可用	扩展性有限，冷数据存储成本高
云对象存储（如S3）	弹性对象存储，按需扩容	弹性，冷热数据支持，成本按量付费	冷数据归档，长期存储	读取延迟较高，不适合热数据高频访问
冷热分离架构	分层存储，热数据快存储，冷数据归档	动态迁移，性能与成本平衡	PB级日志，混合访问模式	需要智能TTL策略，数据迁移成本

4) 【示例】（伪代码）

def write_log(log_data, access_freq):
    if access_freq == "hot":  # 热数据
        hdfs_client.write(log_data, "hdfs://path/hot_logs")
        hdfs_client.set_replication(3)
        hdfs_client.compress("lzo")
    else:  # 冷数据
        s3_client.put_object(log_data, "s3://bucket/cold_logs")

def migrate_cold_data():
    # 7天后迁移冷数据
    hdfs_client.list_files("hdfs://path/hot_logs").filter(lambda f: f.modified < 7_days_ago)
    hdfs_client.move_to_s3(f, "s3://bucket/cold_logs")

5) 【面试口播版答案】（约90秒）
“在360的日志存储项目中，我们面对PB级数据，核心是通过冷热分离+分布式架构实现扩展性。具体来说，热数据（近7天）存储在HDFS（副本3，LZ4压缩），冷数据（7天后）迁移到S3归档。性能上，通过日志类型分片（如web日志、app日志）和Redis缓存热点数据提升读取速度。成本优化方面，冷数据按月付费，热数据按小时计费，整体成本降低40%。”

6) 【追问清单】

• 数据分片导致的数据倾斜？
  回答要点：通过哈希分片（如MD5哈希取模），结合动态扩容，定期重新分片。
• 数据迁移的延迟如何控制？
  回答要点：采用异步迁移，优先迁移冷数据，不影响热数据访问。
• 如何保证数据一致性？
  回答要点：写入时HDFS副本同步，迁移后删除原副本，确保数据不丢失。
• 冷热数据划分的阈值如何确定？
  回答要点：根据访问频率（如7天无访问）、数据大小（如超过1TB），结合业务需求调整。
• 存储容量不足时怎么办？
  回答要点：动态扩容HDFS集群，增加节点，或增加S3存储桶容量。

7) 【常见坑/雷区】

• 忽略冷热数据分离，导致所有数据存储在昂贵快存储，成本过高。
• 数据分片不合理，导致某些分片负载过高，性能下降。
• 数据迁移策略过于激进，影响热数据访问。
• 未考虑数据压缩率，导致存储空间浪费。
• 未评估不同存储的读写性能差异，导致冷数据读取延迟过高。