360计划构建统一数据平台，请比较数据湖（如HDFS+Hive）和数据仓库（如星型模型+OLAP）的优缺点，并结合360的业务需求（安全产品销售、企业级安全解决方案）选择合适的架构？
答案
1) 【一句话结论】对于360的安全业务（包含海量非结构化安全日志、结构化销售数据等），推荐以数据湖（HDFS+Hive）为核心构建统一数据平台，结合数据仓库（星型模型+OLAP）用于核心业务报表。数据湖存储原始多源数据，支持灵活分析；数据仓库处理后的结构化数据，用于OLAP分析，两者互补满足360需求。
2) 【原理/概念讲解】数据湖（以HDFS+Hive为例）是采用分布式文件系统（如HDFS）存储原始数据（结构化、半结构化、非结构化），不预先处理，所有数据直接写入，后续通过Hive等工具分析，类似“原始数据水库”，强调存储原始、灵活处理。数据仓库（星型模型+OLAP）是通过ETL清洗、转换，按业务主题（如销售、安全）建模（星型模型），存储结构化数据，用于多维分析（OLAP），类似“整理后的湖泊”，数据经过处理，用于特定报表。类比：数据湖是“所有数据都存，后续取用”，数据仓库是“处理好的数据，用于报表”。
3) 【对比与适用场景】
| 特性/场景 | 数据湖（HDFS+Hive） | 数据仓库（星型模型+OLAP） |
|---|---|---|
| 定义 | 存储原始多源异构数据（结构化、半结构化、非结构化） | 经过ETL处理，按主题建模的结构化数据 |
| 存储方式 | 分布式文件系统（HDFS），支持大文件、可扩展 | 关系型数据库（如Oracle），结构化表 |
| 数据处理 | 原始数据，不预先处理，灵活 | 清洗、转换，预定义模型 |
| 查询方式 | Hive/Spark SQL（灵活） | OLAP引擎（如StarRocks），多维查询 |
| 使用场景 | 大数据分析、机器学习、非结构化数据（日志、文档）、灵活查询 | 业务报表、OLAP分析、预定义查询、核心业务报表 |
| 注意点 | 数据质量差，需后处理；扩展性好；处理结构化数据时，当数据量极大，Hive查询可能变慢（需优化） | 数据更新慢，扩展性不如数据湖；查询效率高（但仅适用于预定义模型） |
4) 【示例】
假设360安全日志通过Kafka实时采集，Flink处理后写入HDFS（数据湖），然后Hive查询攻击事件：
-- Hive查询数据湖中的安全日志（流处理写入）
SELECT
event_type,
source_ip,
target_ip,
timestamp
FROM
hdfs:/data/security_logs
WHERE
event_type = 'attack'
AND timestamp > '2023-10-01'
AND partition='2023-10';
销售数据存储为Parquet格式，按时间分区：
/data/sales_data/sales_2023/partition=2023-10
同时，数据仓库中销售主题的星型模型表（如sales_fact表）通过每小时同步数据湖中的结构化销售数据（如通过Spark SQL联邦查询）更新。
5) 【面试口播版答案】
面试官您好，关于360构建统一数据平台，数据湖和数据仓库的对比，核心结论是：对于360的安全业务（包含海量非结构化安全日志、结构化销售数据等），推荐以数据湖（HDFS+Hive）为核心，结合数据仓库（星型模型+OLAP）。具体来说，数据湖能统一存储多源异构数据（如日志、销售数据），支持灵活分析（如机器学习、日志查询）；数据仓库则处理后的结构化数据，用于核心业务报表（如销售趋势、安全事件统计）。比如，安全日志（非结构化）通过Kafka+Flink写入数据湖，用Hive查询攻击事件；销售数据（结构化）存储为Parquet并分区，用OLAP引擎做多维分析。两者结合，既能满足360的灵活分析需求，又能保证核心报表的效率。
6) 【追问清单】
- 数据湖的数据质量如何保证？
回答要点：通过数据治理（元数据管理用Apache Atlas，数据质量规则如日志去重、销售数据一致性校验，清洗用Spark ETL），确保数据质量，例如日志去重率95%，数据准确率99%。 - 数据湖与数据仓库如何结合？
回答要点：采用联邦查询（如Hive与星型模型数据库的联合查询，通过元数据服务统一管理），或数据同步（如每小时将数据湖中的结构化销售数据同步到数据仓库，用于OLAP分析）。 - 360安全日志的实时性需求，数据湖如何扩展？
回答要点：结合流处理（Kafka + Flink），实时写入数据湖，实现秒级分析；同时，对日志做列式存储（Parquet）并建立倒排索引，优化检索效率。 - 数据湖的存储成本控制？
回答要点：对冷数据（如历史日志）归档至S3 Glacier，采用TTL策略，冷数据存储成本降低50%；对热数据用HDFS，热数据压缩（如Snappy压缩），减少存储空间。 - 数据湖处理结构化数据的性能优化？
回答要点：使用列式存储（Parquet）、分区（按时间、事件类型）、索引（Hive的桶/分区），结合Spark SQL优化器，提升查询效率。
7) 【常见坑/雷区】
- 忽略非结构化数据的具体处理挑战：未说明安全日志的实时性需求，导致数据湖适用性论证不充分。
- 数据湖处理结构化数据的性能瓶颈描述不全面：未提及当数据量极大时，Hive查询可能变慢，缺乏优化方案。
- 数据湖与数据仓库结合的技术方案不具体：未说明联邦查询的具体实现（如元数据服务、数据同步频率）。
- 数据质量措施笼统：未给出具体技术（如元数据管理工具、数据清洗流程）和效果（如去重率、准确率）。
- 口播模板化：使用“核心结论”“具体来说”等机械词汇，缺乏自然对话过渡。