混合架构需统一语义层锚定口径，实时与离线链路协同而非拼凑；通过Data Catalog管理元数据、SQL Hint自动路由、实时补离线拼接、对账修复机制、智能服务路由及跨链路可观测性，实现快、准、义、判四者闭环。
SQL报表系统要兼顾实时性和稳定性，混合架构是常见解法：用实时链路满足秒级/分钟级看数需求，用离线链路保障数据准确性、一致性和复杂计算能力。关键不在“拼凑”，而在“协同”——两个链路共享模型、统一口径、可追溯、可对齐。
核心分层：统一语义层是混合架构的锚点
避免实时表和离线表各自建模、字段命名不一、逻辑重复。必须在中间层（如DWD或语义层）定义标准指标、维度、口径规则。例如：“订单支付金额”需明确是否含退款、是否去重、时区归属、统计粒度（按创建时间还是支付时间）。实时任务和离线任务都基于同一份语义定义产出数据，下游报表只需切换数据源，无需改逻辑。
- 推荐用Data Catalog管理指标元数据，标注来源类型（实时/离线）、更新频率、延迟SLA、血缘关系
- 语义层暴露的SQL接口应支持Hint或标签，让BI工具自动路由到合适的数据源（如/*+ source=realtime */）
- 同一张宽表，离线产出全量快照，实时产出增量变更，语义层做“实时补离线”的动态拼接（如查最近7天用实时，查历史用离线）
数据同步与一致性保障：不是复制，而是协同
实时链路（如Flink + Kafka + Doris/StarRocks）和离线链路（如Spark + Hive/Trino）并非独立运行。需设计轻量级对账与修复机制：
- 每小时/每天在关键汇总粒度（如“各渠道日支付GMV”）跑一致性校验，差异超阈值触发告警，并自动拉取离线结果覆盖实时热区（兜底策略）
- 实时写入时保留业务时间（event_time）和处理时间（proc_time），离线任务按业务时间分区，确保T+1离线结果能准确修正前序实时偏差
- 对高敏感指标（如资金类），强制走离线口径，实时只作趋势参考，报表中明确标注“实时估算值，以T+1离线为准”
报表服务层：智能路由 + 缓存分级
前端报表不应感知底层是实时还是离线。服务层需根据查询条件自动决策：
- 查“今天”或“最近1小时” → 路由至实时引擎，设置5秒超时，超时自动降级查离线缓存
- 查“上月”或带复杂JOIN/窗口函数 → 直接路由至离线引擎，预热常用报表结果到Redis或OLAP缓存
- 同一报表支持双源对比模式：左右分屏显示实时值 vs 离线值，标出差异率和可能原因（如“实时未收退款事件”）
运维与可观测性：把“混合”变成可管可控的状态
混合架构的复杂性体现在监控维度更多：不仅要盯任务成功率，还要看链路延迟、口径漂移、源端变更影响范围。
- 构建跨链路的延迟看板：对比同一批订单从产生→实时入库→离线落地的时间差，定位瓶颈环节
- 当上游表结构变更（如新增字段），自动扫描实时Flink SQL和离线Hive DDL，提示兼容性风险
- 为每个报表指标打标：source_type（realtime/offline/hybrid）、staleness（最大允许延迟）、recovery_method（自动修复/人工介入）
不复杂但容易忽略：混合不是为了炫技，而是让每一类查询都落在最合适的执行路径上。实时解决“快”，离线守住“准”，语义层定“义”，服务层做“判”。四者环环相扣，缺一不可。
