设计一个园区管理系统，需要整合设计院、施工方、监理方的多源异构数据（如CAD图纸、施工日志、传感器数据），请说明数据集成方案，包括数据清洗、转换、存储及数据一致性的保障措施。

1) 【一句话结论】采用“统一数据模型+分层ETL+混合存储架构+分布式一致性协议”的方案，通过标准化清洗、格式转换、分域存储，结合事件溯源与版本控制保障多源异构数据的一致性与可用性。

2) 【原理/概念讲解】首先解释多源异构数据的特点——来源多样（设计院CAD、施工方日志、监理方传感器）、格式各异（CAD二进制、日志文本、JSON/CSV）。数据集成需解决“翻译+统一+持久化”问题。

• 数据清洗：处理缺失值、异常值（如施工日志中的无效日期），类比“整理杂乱房间，去除垃圾”；
• 数据转换：将CAD几何数据转为空间矢量格式（如GeoJSON），日志文本转为结构化表（时间+工序+进度），类比“翻译不同语言”；
• 数据存储：根据数据特性选择存储（如CAD用对象存储+空间索引，日志用关系型数据库，传感器用时序数据库）；
• 数据一致性：通过分布式事务（如两阶段提交）或事件溯源（每个操作生成事件，回滚时重放事件）保障，类比“多人协作写文档，每一步都有版本记录”。

3) 【对比与适用场景】

组件	定义	特性	使用场景	注意点
数据清洗工具	用于处理数据质量问题（缺失/异常/重复）的工具	支持规则引擎、机器学习模型	CAD图纸元数据清洗、施工日志去重	需定制化规则，避免过度清洗丢失有效信息
数据转换框架	将数据从源格式转为目标格式的工具（如Apache Avro、Flink）	支持复杂转换（如几何计算、时间解析）	CAD几何数据转换、日志字段映射	需考虑性能，避免转换瓶颈
数据存储方案	根据数据特性选择存储（如HDFS+GeoMesa、Cassandra、InfluxDB）	HDFS适合大规模文件，Cassandra适合高并发，InfluxDB适合时序	CAD图纸存储、施工日志存储、传感器数据存储	需考虑数据访问模式（读/写频率）

4) 【示例】以施工日志（CSV）和传感器数据（JSON流）为例，清洗转换后存储。

• 数据清洗：读取施工日志CSV，过滤无效日期（如“2023-02-30”），填充缺失工序（用前序工序推断）；
• 数据转换：将日志中的“进度%”转为数值，将传感器JSON中的“温度”字段提取；
• 数据存储：清洗转换后的结构化数据存入MySQL（施工日志），传感器数据存入InfluxDB（时序）；
• 一致性保障：施工日志写入MySQL时使用分布式事务（如使用Seata），确保日志与进度表同步。

伪代码示例（ETL流程）：

# 数据清洗（施工日志）
def clean_log(log_data):
    valid_dates = log_data['date'] in valid_date_range
    valid_progress = log_data['progress'] in [0, 100]
    return log_data if valid_dates and valid_progress else None

# 数据转换（施工日志）
def convert_log(log_data):
    return {
        "project_id": log_data['project_id'],
        "date": log_data['date'],
        "task": log_data['task'],
        "progress": int(log_data['progress'])
    }

# 数据存储
def store_log(converted_data):
    db.insert("construction_logs", converted_data)

5) 【面试口播版答案】各位面试官好，针对园区管理系统多源异构数据集成问题，我的方案核心是“统一模型+分层处理+混合存储+一致性保障”。首先，数据清洗阶段，针对CAD图纸（二进制）、施工日志（文本）、传感器数据（JSON）的不同特点，分别设计清洗规则：比如施工日志过滤无效日期，CAD图纸提取元数据（如图纸编号、版本）；然后数据转换，将CAD几何数据转为空间矢量格式（如GeoJSON），日志文本转为结构化表（时间+工序+进度），传感器数据解析为时序字段（时间戳+温度+位置）；接着存储，CAD用对象存储（如MinIO）+空间索引（如GeoMesa），施工日志用关系型数据库（MySQL），传感器用时序数据库（InfluxDB）；最后保障一致性，通过分布式事务（如Seata）确保施工日志与进度表同步，对传感器数据采用事件溯源（每个数据点生成事件，回滚时重放事件）。这样能整合多源数据，保证数据一致性与可用性。

6) 【追问清单】

• 问题1：数据清洗的具体流程？如何处理CAD图纸中的缺失元数据？
  回答要点：针对CAD，通过API获取元数据（如图纸编号、版本），缺失时用设计院提供的元数据字典补充，异常值（如无效版本号）则标记并人工审核。
• 问题2：如何处理实时传感器数据？是否需要实时处理？
  回答要点：传感器数据采用流处理（如Apache Kafka + Flink），实时解析并存储到InfluxDB，同时写入历史数据库（如PostgreSQL），确保实时性与历史追溯。
• 问题3：数据一致性如何保障？是否考虑过数据冲突？
  回答要点：采用分布式事务（如Seata）处理施工日志与进度表的写入，对传感器数据采用事件溯源，通过事件序列号解决冲突（如最新事件优先）。
• 问题4：不同角色的数据权限如何控制？
  回答要点：通过RBAC（基于角色的访问控制）模型，为设计院、施工方、监理方分配不同权限（如设计院可查看CAD图纸，施工方可编辑施工日志），结合数据脱敏（如隐藏敏感信息）。

7) 【常见坑/雷区】

• 坑1：忽略数据格式差异，直接存储未转换的数据（如CAD二进制存入关系型数据库）。
  雷区：导致存储效率低、查询困难，需明确数据转换规则。
• 坑2：未考虑实时性需求，仅用批处理处理传感器数据。
  雷区：实时数据丢失，无法及时响应（如温度异常预警）。
• 坑3：数据一致性只说理论，未提及具体技术选型（如分布式事务的具体实现）。
  雷区：面试官会追问技术细节，需说明Seata、事件溯源等具体方案。
• 坑4：未考虑数据存储成本，所有数据都用同一存储方案。
  雷区：导致存储成本过高，需根据数据特性选择混合存储（如对象存储+时序数据库）。
• 坑5：数据清洗规则过于简单，未考虑业务逻辑（如施工日志中的工序依赖关系）。
  雷区：清洗后数据仍存在业务逻辑错误，需结合业务规则定制清洗逻辑。