来自Apache Flink 中文学习网站 侵权告知立删
3.1.2 Kappa架构
来自Apache Flink 中文学习网站 侵权告知立删
3.1.3 实时olap变体架构
来自Apache Flink 中文学习网站 侵权告知立删
3.1.4 常见架构对比
来自Apache Flink 中文学习网站 侵权告知立删
ps:lambda架构
开发割裂感：
• 表结构不同
• sql语法不同
资源浪费：
• 重复计算
• 重复存储
集群维护：
• 组件不同
• 计算引擎不同
数据一致性
3.2 实时数仓架构
3.2.1 方案一
优点：
￮ 便于数据回溯、重算和数据质量验证。
缺点：
￮ 通过批处理重算，需要维护两套代码，开发和维护成本高。
￮ 需要两套计算资源
适用场景：
￮ 超大规模历史数据计算，且这种场景比较频繁。
￮ 对数据质量要求极高，需要比对实时和离线的计算结果，甚至利用离线去修正实时的计算结果。
3.2.2 方案二
优点：
￮ 无需维护两套代码，开发迭代速度快。
￮ 数据回溯和重算方便，重算时间根据需求回溯的时间范围定。
￮ 只需流计算资源，资源占用小
缺点：
￮ ODS\DWD部分数据“不可见”，原始数据和中间数据不便于查询（解决方案：可通过重新消费指定时间范围的数据查询，或导入需要的数据到olap引擎）
￮ 依赖业务端反馈问题（解决方案：设计数据质量监控指标，实时监控报警）
适用场景：
ODS\DWD查询不频繁等
3.2.3 方案三
相对于方案二：
￮ 增加ODS层落地hive，排查分析原始数据比较方便，恢复历史数据的时候可获取hive数据写入kafka，然后按原流处理的逻辑重新处理即可，只需修改数据源为历史数据对应的topic。
￮ 需新增kafka写入hive逻辑
￮ 需新增从hive读取数据写入kafka
￮ 需新增整条链路历史数据对应的topic
如果觉得《mysql 层次查询 实时数据仓库如何做 – 数据库 – 前端 mysql5.7新特性》对你有帮助，请点赞、收藏，并留下你的观点哦！
