来自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