有一个交易系统日志每天新增约2.5TB，需要实现实时（延迟<5秒）精确去重（同一订单号只保留最新一条记录），并支持按订单号、用户ID、时间范围等多维度快速查询。给出最优架构设计方案，包括存储选型、分区策略、索引设计、数据生命周期管理和查询优化路径。
分类: technical
难度: hard
标签:
答题技巧
["为什么不适合直接使用MySQL / PostgreSQL","ClickHouse、Doris、Iceberg+Trino、Hudi、Kafka Streams + RocksDB 等方案对比","如何实现低延迟去重（upsert语义）","分区策略：时间分区 vs 订单号哈希分区 vs 复合分区","倒排索引、全文索引、布隆过滤器、Z-order曲线等的使用场景","数据分层（热/温/冷）与存储介质选择","查询引擎选型与SQL vs NoSQL权衡"]
参考答案
Kafka → Flink exactly-once + RocksDB状态后端做实时去重 → 写入Iceberg表（分区：dt + user_id模256），使用Merge-on-Read + Z-order索引优化多维查询。冷数据沉降到对象存储，查询统一走Trino + Iceberg。热数据1个月保留ClickHouse物化视图加速高频查询。