请设计一个针对9377公司广告投放的系统架构，考虑农业行业的特点（多源异构数据、时效性、合规性要求），包括数据层、计算层、应用层的设计，并说明如何处理农业行业特有的数据（如种植端的大豆产量数据、加工端的库存数据、销售端的客户行为数据）用于广告投放的定向和优化。

1) 【一句话结论】
设计分层架构（数据层、计算层、应用层），结合农业多源异构数据特性，通过实时计算与合规引擎实现定向与优化，核心是数据融合与实时响应。

2) 【原理/概念讲解】
老师口吻：针对9377的广告投放系统，我们采用“数据层-计算层-应用层”三层架构，适配农业行业特点。

• 数据层：处理多源异构数据（种植端大豆产量、加工端库存、销售端客户行为）。存储方案：分布式文件系统（如HDFS）存非结构化数据（如传感器原始图像），消息队列（如Kafka）存实时数据，关系型数据库（如MySQL）存结构化基础数据（如客户ID）。
• 计算层：用流处理框架（如Flink）处理实时数据（如实时聚合产量），用批处理框架（如Spark）做离线模型训练（如预测产量）。
• 应用层：提供API接口，结合实时数据与模型结果，实现精准定向（如产量高区域投放采购广告）。
  农业行业特点：多源异构（数据类型多样）、时效性（产量数据实时性要求高）、合规性（数据隐私与广告内容法规）。类比：数据层像“数据仓库”，负责收集存储；计算层像“加工车间”，实时处理生成洞察；应用层像“销售终端”，根据结果调整投放。

3) 【对比与适用场景】

方案	定义	特性	使用场景	注意点
传统关系型数据库（如MySQL）	结构化数据存储	事务强一致性，查询稳定	库存数据、客户基础信息	不适合存储大量非结构化数据（如传感器原始图像）
分布式文件系统（如HDFS）	海量文件存储	高容错，适合离线处理	大豆产量传感器原始数据（非结构化）、历史图像数据	写入延迟较高，不适合实时数据写入
消息队列（如Kafka）	实时数据传输	高吞吐、低延迟，支持流处理	实时产量更新、客户行为事件（如点击、购买）	需要消费者处理数据，适合作为数据中转
Spark	批处理/流处理	生态丰富，支持复杂计算	离线数据分析、模型训练	流处理延迟较高（秒级）
Flink	实时流处理	低延迟（毫秒级），状态管理强大	实时数据计算、实时广告定向	配置复杂，状态维护成本高

4) 【示例】

• 数据层：种植端大豆产量数据存入Kafka主题“agri_yield”（字段：farm_id, crop_type, yield, timestamp）；加工端库存数据存MySQL表stock（id, product_id, quantity, update_time）；销售端客户行为数据存Redis（实时访问）+HDFS（离线分析）。
• 计算层（Flink伪代码）：

  from flink import Flink
  # 实时聚合产量
  yield_stream = Flink().read_from("kafka://agri_yield")
  real_time_yield = yield_stream.filter(lambda x: x.yield > 0) \
      .group_by("farm_id") \
      .sum("yield") \
      .write_to("redis://real_time_yield")
  # 计算客户购买频率
  customer_behavior_stream = Flink().read_from("kafka://customer_behavior")
  customer_freq = customer_behavior_stream \
      .group_by("customer_id") \
      .count() \
      .write_to("hdfs://customer_freq")
  

• 应用层API：

  GET /api/ad_targeting?crop_type=soybean&region=东北
  # 逻辑：获取东北区域实时大豆产量，结合购买过大豆的客户列表，生成定向广告
  

5) 【面试口播版答案】
各位面试官好，针对9377的广告投放系统，我设计了一个分层架构，包括数据层、计算层和应用层，核心是处理农业多源异构数据，满足实时性和合规性要求。
首先，数据层：针对农业行业多源异构的特点，我们采用分布式存储+消息队列的组合。比如种植端的大豆产量数据，通过传感器采集后存入Kafka，加工端的库存数据用MySQL存储，销售端的客户行为数据用Redis+HDFS。这样既能处理结构化和非结构化数据，又能保证实时数据的高吞吐。
然后是计算层，我们用Flink做实时计算，比如实时聚合每个农场的产量，结果写入Redis供应用层快速查询。同时用Spark做离线模型训练，比如根据历史数据预测产量，优化广告定向。
应用层提供API接口，结合实时产量和客户行为，实现精准定向，比如产量高的区域投放采购广告，高购买频率客户投放促销广告。最后，合规性方面，我们在数据层加入脱敏处理，应用层加入广告内容审核模块，确保符合农业相关法规。这样整个系统既能高效处理农业数据，又能满足广告投放的需求。

6) 【追问清单】

• 问题1：数据清洗的具体流程？
  回答要点：对传感器数据进行异常值检测（如产量负值），对客户行为数据进行去重（重复点击），对库存数据进行一致性校验（如库存与实际数量差异）。
• 问题2：系统如何保证实时性？
  回答要点：计算层使用Flink低延迟处理，数据层用Kafka保证数据实时传输，应用层通过Redis缓存实时数据，减少数据库查询延迟。
• 问题3：如果数据源增加（如气象数据），系统如何扩展？
  回答要点：数据层增加新的Kafka主题，计算层增加Flink处理节点，应用层调整API参数，无需大规模重构。
• 问题4：合规性措施具体有哪些？
  回答要点：数据隐私方面，对个人客户信息脱敏，存储加密；广告内容方面，加入农业相关法规审核模块，禁止虚假宣传。
• 问题5：系统的扩展性如何？
  回答要点：数据层采用分布式存储，计算层支持水平扩展，应用层通过API网关负载均衡，可支持大规模广告投放。

7) 【常见坑/雷区】

• 忽略实时性需求，使用传统批处理框架处理实时数据，导致广告定向延迟，影响效果。
• 数据源不明确，未区分种植、加工、销售端的数据类型和特点，导致数据融合困难。
• 合规性措施不足，未考虑数据隐私和广告内容法规，可能引发法律风险。
• 未考虑农业数据的时效性，比如产量数据更新频率高，系统未设计实时更新机制。
• 系统架构过于复杂，未考虑最小可运行版本，导致开发周期长，无法快速上线。