设计一个360的大数据平台架构，结合数据湖（存储原始日志）和数据仓库（存储加工后的数据），说明两者的数据流动和分离逻辑，以及如何实现数据共享？
答案
1) 【一句话结论】：在360大数据平台中，数据湖存储原始未加工的日志数据，数据仓库存储加工后的结构化分析数据，通过数据管道实现流动与分离，通过元数据管理、API服务实现数据共享。
2) 【原理/概念讲解】：数据湖（Data Lake）是存储原始、未经过滤或加工的数据集合，支持多种数据格式（如JSON、日志文件），类似“原始水库”，存储的是“原材料”；数据仓库（Data Warehouse）是存储经过ETL/ELT处理后的结构化数据，用于业务分析，类似“加工后的饮用水”，存储的是“成品”。数据流动逻辑是：原始日志首先写入数据湖，通过数据管道（如Kafka、Flink）进行清洗、转换，加载到数据仓库；分离逻辑基于数据生命周期——湖中是“原始阶段”，仓库是“加工阶段”，两者通过数据格式、处理复杂度区分。类比：数据湖像超市的“生鲜区”，存放未加工的食材；数据仓库像“熟食区”，存放加工好的菜肴，用户直接取用熟食，不用自己处理生鲜。
3) 【对比与适用场景】：
| 特性/场景 | 数据湖 | 数据仓库 |
|---|---|---|
| 定义 | 存储原始、未加工的日志/数据 | 存储经过ETL/ELT处理的结构化分析数据 |
| 特性 | 支持多种格式（结构化/半/非结构化），可扩展，成本较低 | 数据标准化，一致性高，面向分析，模型复杂 |
| 使用场景 | 日志分析、用户行为追踪、非结构化数据（如图片、视频）、探索性分析 | 报表、BI、决策支持、业务指标计算（如用户活跃度、转化率） |
| 注意点 | 数据质量差，需要治理；查询性能低（原始数据） | 数据模型设计复杂，扩展性相对有限；处理成本高（ETL/ELT） |
4) 【示例】：假设360的日志数据存储在HDFS（数据湖），用户访问日志（结构化日志，如JSON格式）每天写入数据湖。通过Spark读取数据湖中的日志文件，进行数据清洗（过滤无效记录、处理缺失值），然后转换（如聚合用户ID、时间戳、URL），最后写入数据仓库的“用户访问表”（如MySQL或Hive表）。伪代码示例（Spark SQL）：
// 读取数据湖中的日志文件
df = spark.read.format("json").load("hdfs://data-lake/user_access_logs/*")
// 数据清洗与转换
cleaned_df = df.filter("user_id is not null") \
.withColumn("visit_time", to_timestamp("timestamp")) \
.groupBy("user_id", "visit_time") \
.agg(count("url").alias("visit_count"))
// 写入数据仓库
cleaned_df.write.format("parquet").save("hdfs://data-warehouse/user_access")
5) 【面试口播版答案】：好的，面试官。在360的大数据平台架构中，我们采用“数据湖+数据仓库”的混合模式。数据湖用于存储原始的日志数据，比如用户访问日志、系统操作日志，这些数据是未经过滤或加工的，支持多种格式（JSON、日志文件等），类似“原始水库”，存储的是“原材料”；数据仓库则存储经过ETL处理后的结构化数据，用于业务分析，比如用户活跃度、转化率等指标，类似“加工后的饮用水”，存储的是“成品”。数据流动逻辑是：原始日志首先写入数据湖，通过数据管道（如Kafka、Flink）进行清洗、转换，然后加载到数据仓库；分离逻辑基于数据生命周期——湖中是“原始阶段”，仓库是“加工阶段”，两者通过数据格式、处理复杂度区分。数据共享方面，我们通过元数据管理（如Apache Atlas）统一管理湖和仓库的元数据，提供数据目录服务；同时，通过API服务（如RESTful API）暴露数据仓库的表，供业务系统调用；对于数据湖中的原始数据，提供轻量级查询服务（如HiveQL），支持探索性分析。这样既保证了原始数据的完整性，又通过加工后的数据支持业务决策，实现了数据流动与分离，并支持高效共享。
6) 【追问清单】：
- 问题1：数据湖中存储的原始日志如何保证数据质量？
回答要点：通过数据治理流程，如数据清洗规则（过滤无效记录、处理缺失值）、数据验证（如校验日志字段完整性）、元数据标注（记录数据来源、时间、格式），以及定期审计（如数据质量报告）。 - 问题2：数据共享的具体技术实现？
回答要点：数据湖通过Hive、Spark SQL提供查询接口；数据仓库通过API（如RESTful）、数据服务（如Kafka发布数据流）实现共享；元数据管理平台（如Atlas）提供统一目录，用户通过搜索元数据找到数据源。 - 问题3：数据管道的调度与监控？
回答要点：使用Airflow或Flink的调度组件，设置定时任务（如每天凌晨处理日志）；通过监控工具（如Prometheus、Grafana）监控管道的运行状态（如任务成功率、处理时间），并设置告警（如任务失败、延迟超过阈值）。 - 问题4：数据仓库的模型设计（如星型模型）？
回答要点：数据仓库采用星型模型，事实表存储业务指标（如访问次数、交易金额），维度表存储描述性信息（如用户、时间、产品），便于快速查询分析。 - 问题5：数据安全与权限控制？
回答要点：数据湖中的原始数据通过HDFS的访问控制（如ACL）和Kerberos认证保护；数据仓库通过数据库的权限管理（如角色、用户组）控制访问；敏感数据（如用户隐私信息）进行脱敏处理（如替换为哈希值），并记录访问日志。
7) 【常见坑/雷区】：
- 坑1：混淆数据湖和数据仓库的功能，认为两者可以替代。比如将原始日志直接加载到数据仓库，导致仓库数据量过大，查询性能下降；或直接从数据湖查询原始数据用于分析，忽略数据质量问题。
- 坑2：数据流动方向错误，比如直接从数据湖到业务应用，不经过数据仓库。这样业务系统需要处理原始数据，增加系统复杂度，且无法保证数据一致性。
- 坑3：数据共享方式单一，仅靠文件共享（如HDFS文件下载），缺乏API或数据服务。导致业务系统需要自行解析数据，效率低，且无法实时获取数据。
- 坑4：数据治理缺失，数据湖中数据无元数据，仓库中数据无标准。比如日志字段含义不明确，导致分析结果错误；或数据模型不一致，影响数据共享。
- 坑5：性能问题，数据湖中原始数据查询慢（如扫描整个日志文件），数据仓库查询快但处理复杂（如ETL过程耗时）。未考虑数据分区、索引优化，导致系统性能下降。