构建一个用于存储上游材料库存和供应数据的平台，需要考虑哪些技术选型？
长鑫存储智能研发难度：中等
答案
1) 【一句话结论】
核心选型围绕数据实时性、一致性、可扩展性，采用“消息队列（Kafka）+分布式数据库（TiDB）+列式数据仓库（ClickHouse）”的混合架构，满足上游材料库存的实时更新、供应链数据流处理及历史数据分析需求。
2) 【原理/概念讲解】
首先明确上游材料库存和供应数据的特性：高频实时更新（如供应商每日补货）、多源异构数据（供应商系统、ERP系统）、分析需求（库存周转率、供应商交付准时率）。
- 消息队列（Kafka）：异步通信中间件，用于解耦上游数据源（供应商系统）与存储系统，保证数据不丢失且高吞吐。类比：快递分拣中心，上游供应商是寄件人，Kafka是分拣中心，把包裹（库存变动事件）分发给不同仓库（数据库、数据仓库）。
- 分布式数据库（TiDB）：兼容MySQL协议的分布式数据库，支持高并发读写、强一致性（ACID），适合实时库存的增删改查操作。特性：水平扩展、事务支持、高可用。
- 列式数据仓库（ClickHouse）：列式存储结构，适合分析型查询（如聚合、统计），查询速度快。特性：列式存储、MPP架构、支持SQL。
3) 【对比与适用场景】
| 组件类型 | 定义 | 特性 | 使用场景 | 注意点 |
|---|---|---|---|---|
| 消息队列（Kafka） | 分布式消息系统，用于异步传输数据 | 高吞吐、低延迟、持久化、容错 | 上游数据采集（异步）、数据流处理、解耦系统 | 需要考虑分区和副本策略，避免数据丢失 |
| 分布式数据库（TiDB） | 兼容MySQL的分布式数据库 | 高并发读写、强一致性、水平扩展 | 实时库存数据存储（增删改查） | 需要合理设计表结构（如分区、索引），避免性能瓶颈 |
| 列式数据仓库（ClickHouse） | 列式存储的MPP数据仓库 | 查询速度快（聚合、统计）、支持SQL | 历史数据分析（库存周转、供应商评估） | 适合分析型查询，不适合实时事务操作 |
4) 【示例】
- 上游供应商系统发送库存更新事件到Kafka：
{ "material_id": "MX-001", "supplier_id": "S-1001", "action": "add", "quantity": 500, "timestamp": "2024-01-15T10:30:00Z" } - Kafka消费者将数据写入TiDB的实时库存表：
INSERT INTO real_time_inventory (material_id, supplier_id, quantity, update_time) VALUES ('MX-001', 'S-1001', 500, NOW()); - 同时写入ClickHouse的历史数据表：
INSERT INTO historical_inventory (material_id, supplier_id, quantity, update_time) VALUES ('MX-001', 'S-1001', 500, NOW()); - 查询实时库存：
SELECT material_id, SUM(quantity) AS total_quantity FROM real_time_inventory WHERE material_id = 'MX-001' GROUP BY material_id; - 查询历史供应数据：
SELECT material_id, supplier_id, SUM(quantity) AS total_supply FROM historical_inventory WHERE material_id = 'MX-001' AND update_time BETWEEN '2024-01-01' AND '2024-01-31' GROUP BY material_id, supplier_id;
5) 【面试口播版答案】
“面试官您好，针对存储上游材料库存和供应数据的平台，核心选型要考虑实时性、数据一致性和可扩展性。首先，上游供应商的库存变动是高频、异步的，所以用Kafka作为消息队列，解耦数据源和存储系统，保证数据不丢失且高吞吐。然后，实时库存存储用TiDB，它兼容MySQL，支持高并发读写和强一致性，比如库存扣减、补货操作能快速响应，同时保证数据准确。最后，对于历史数据分析，用ClickHouse这样的列式数据仓库，因为供应链数据有大量历史记录，列式存储查询速度快，比如分析某材料过去3个月的供应波动，或者供应商的交付准时率。这样整体架构是：上游供应商系统通过API将库存变动推送到Kafka，Kafka消费者将数据写入TiDB的实时库存表，同时写入ClickHouse的历史数据表，既保证了实时库存的准确性，又能支持后续的分析需求。”
6) 【追问清单】
- 问题1：如果数据量特别大，比如每天有百万级库存变动，Kafka的分区和副本怎么设置？
回答要点：分区数根据并发消费者数和吞吐量需求设置（如每个供应商一个分区），副本数设为3保证高可用，避免数据丢失。 - 问题2：TiDB的读写分离策略怎么设计？
回答要点：读写分离，主库负责写操作（库存更新），从库负责读操作（查询库存），提高查询性能，同时主库通过分片（如按material_id分区）水平扩展。 - 问题3：数据仓库的ETL流程如何保证数据一致性？
回答要点：使用CDC（Change Data Capture）技术从TiDB实时表同步数据到ClickHouse，确保历史数据与实时数据一致，同时设置数据校验规则（如库存数量非负）。 - 问题4：如何保证数据安全，比如供应商数据隐私？
回答要点：数据传输加密（TLS），存储加密（TiDB和ClickHouse支持加密存储），访问控制（基于角色的访问控制，限制供应商数据访问权限）。 - 问题5：如何监控平台的性能和故障？
回答要点：使用Prometheus+Grafana监控Kafka、TiDB、ClickHouse的指标（如QPS、延迟、CPU利用率），设置告警规则（如Kafka分区延迟超过阈值），定期检查数据一致性（如实时库存与历史库存的差值）。
7) 【常见坑/雷区】
- 坑1：只选单一数据库，忽略实时和离线需求，导致实时库存更新慢或历史分析性能差。
- 坑2：忽略消息队列的解耦作用，导致上游供应商系统与存储系统耦合，影响扩展性和稳定性。
- 坑3：数据仓库选错类型，比如用OLTP数据库做分析，导致查询性能差，无法满足历史数据分析需求。
- 坑4：未考虑数据一致性，比如库存更新和订单系统不同步，导致库存数据不准确。
- 坑5：忽略数据安全，比如未加密传输或存储供应商数据，违反隐私政策。