4-1 流批一体的实时多维分析

大数据架构演进与流批一体方案

大数据架构演进

经典离线数仓架构

• 架构组成：数据源 → 操作数据层（ODS）→ 明细数据层（DWD）→ 汇总数据层（DWS）→ 应用数据层（ADS）
• 优点：架构简单，开发成本低，资源成本低，数据易管理，diff少
• 缺点：数据时效性差，缺少实时数据，表数量太多

Lambda架构

• 架构组成：数据源 → ODS → DW → Batch Layer（离线处理）+ Speed Layer（实时处理）→ Serving Layer
• 优点：保证数据准确性和时效性，兼容经典离线数仓体系
• 缺点：一个需求两套代码，资源占用多，实时数据和离线数据diff

Kappa架构

• 架构组成：数据源 → 消息队列 → 流式计算 → ODS → Real-time Layer + Serving Layer
• 优点：一套数据流，开发成本低，省掉离线数据流计算资源，实时离线数据逻辑统一
• 缺点：数据回溯成本高，复杂关联场景开发维护成本高，历史包袱的迁移成本高

流批一体方案

流批一体背景

• 旧架构流程：日志打点 → 离线采集 → 离线数据清洗 → 数据查询引擎多维分析 → 离线数据仓库（ODS/DW/DWS/ADS）→ 文件系统 → 消息队列 → 策略信号 → 实时报表 → 实时应用
• 旧架构问题：表太多，数仓分层建设导致表数量多，使用成本高；查询慢；实时分析弱；实时报表太定制化，缺少多维分析能力

流批一体整体方案

• 架构组成：数据源（日志打点/离线采集）→ 数据存储 → 数据清洗 → 实时数据仓库（分钟级宽表）→ 数据查询引擎（多维分析+自助报表）→ 文件系统 → 消息队列 → 策略信号 → 实时报表 → 实时应用
• 核心特点：数据离线清洗，天级别更新字段实时更新，流批一体分钟级merge，实时数据仓库分钟级宽表

关键问题突破

1. DB数据更新问题

• 背景：日志数据不会变化，但DB数据会更新；分布式文件系统不支持记录个别字段的update；计算窗口越大，吞吐能力和可维护能力变差
• 解决方案：CopyOnWrite机制，5分钟滚动合并；DB Binlog → 消息队列 → 流式计算 → 分钟级delta文件（初次dump base V1 → base V2 → ...delta...）

2. 多表关联问题

• 背景：离线场景多表关联（如Spark）需要多次关联，性能差
• 解决方案：流式计算初次dump tmpDelta → DB主表 base → delta → 流式计算初次dump DB关联表A → 流式计算初次dump DB关联表...deltaA → baseAdelta... → base...tmpBase → BaseV1 → BaseVn

3. DB和日志关联问题

• 背景：对缓存的读写和容量要求高，成本高；DB表吞吐高，存量记录多
• 解决方案：日志采集 → 消息队列 → 流式计算 → 分钟级delta文件；多表关联解决方案：DB关联表（热base/冷base）分离

4. 数据到位时间问题

• 背景：表A实时产出，表B T+1产出，表C T+2产出，宽表T+2产出
• 解决方案：数据分版本产出，按需实时化；字段实时产出（时效性不敏感数据T+1产出，复杂计算、第三方回传数据T+2产出）；V1可查询版本 → V2可查询版本 → 最终版本

总结和规划

总结

1. 架构选型要符合业务现状，解决业务实际问题
2. 架构选型要综合考量资源、复杂度、维护成本

规划

1. 引擎查询性能持续提升
2. 上层查询工具体验优化