背景
T0 和 TN 处理逻辑分离和使用计算框架不一致导致 存储浪费、计算口径不一致、计算框架(HiveSQL/SparkSQL/Flink)本身语义不同、流批统一数据对外服务难度高误差大、维护成本高等问题
流批一体化-实时数仓架构
左一为架构分层,左二为技术选型,左三为架构产品化,左四为架构产品化 模块划分、核心功能划分。
一、数据源
数据来源主要为前置机业务数据及其变更,其次为平台组件日志或服务以便于监控。
二、数据接入
对于累积的全量数据使用 DataX 或 Sqoop 等成熟工具批量导入到平台,对于 BinLog 使用相应的 CDC 工具(oracle->ogg, mysql->canal 等)流式导入到平台。
三、存储计算
使用 Kafka 作为存储组件,使用 Flink 作为实时计算引擎。
四、数据服务
按照使用需求和场景,
- 对于大屏、看板类的实时业务,可将 Kafka 数据同步到 Database、Redis、ElasticSearch 等 OLTP存储引擎,减少 Web 开发难度。
- 对于实时处理、在线分析等场景,可以基于 Kafka 消息队列订阅消费或构造实时数仓
- 对于离线分析,可以将 Kafka 实时数据入湖后基于数据湖满足 HiveOnMR、HiveOnSpark、HiveOnFlink 等使用场景
五、产品化
描述该架构具备的能力,有支持实时类业务、实时数仓、离线分析场景的能力。
六、前端开发平台
前端开发平台是基于浏览器、为数据开发人员提供的数据生产开发工具。
前端开发平台模块划分
1.元数据平台
a. 维护平台所有数据资产的元数据,包括数据源、Schema、主键、存储方式等信息
b. 数据血缘地图
2.任务调度平台
a. 调度: 平台所有任务都会构建成一张有向无环图。批处理任务、流处理任务都是图中有依赖关系的节点。以 sql 类型任务为主,支持提交 jar 包及其执行命令作为一个调度节点。
a.1 批处理调度: 将有边界的数据(Hadoop、DataBase、FileSystem)导入到平台存储。产出的数据可供后续流处理任务使用。
a.2 流处理调度: 任务常驻、处理无边界的数据,产出的数据可供后续流处理任务使用。
b. 数据血缘地图: 依据任务之间的依赖关系,构造数据血缘地图。简化数据开发人员口口相传、人工记忆 表逻辑计算-传递关系的模式。
3.监控平台
3.1 任务状态监控: 基于 Yarn、Flink 监控任务状态,Checkpoint、State 等
3.2 数据峰谷监控: 基于 Kafka 自身工具或者 Kafka Manager 监控数据波峰波谷,产出数量异常
3.3 运维监控: 组件自身、存储、网络
数据生产流程
对应上图的"存储计算"->"Kafka Flink"
架构优劣对比
相对第一版(借助支持高并发、随机多维查询的高性能缓存,监控维度表变更追溯事实表的可能变更),区别是:
- 不再使用"外部存储作为中间缓存",改为使用 Flink 引擎本身的 State
优势
a. 架构简单,降低了开发、运维成本
劣势
b.同一份维度表会在多个任务的状态中维护。且需要做好建模,尽量减少事实表维度化场景。
2.不再使用"维度更改追溯事实表机制",改为使用 主键 + 动态表(ChangeLog 流)。
优势
a.数据规模可控,且没有无效数据。e.g. App1 a join b; App2 a join c. b表 c 表变更都会汇总到 a 表对应的 topic 中以触发结果数据重计算,但是 App1和App2 均不需要关注对方的变更。无效变更既增加了 topic 存储成本,又增加了计算和数据湖操作成本。事实表扩展出去的业务逻辑越多,无效数据就越多,存储计算消耗越高,生产效率越低。架构能力上限较低。
b.任务粒度通用计算框架。e.g. App2 关联逻辑变更,则需要停止追溯框架、重新生成 版本级别的关联关系图,对于 App1 和其他 App 来说耦合度较高。
劣势
a.需要额外定义主键, 增加了人工成本
b.需要将基础表转化为动态表,增加了平台开发成本
生产模式对比
优势
- 无需存储多个版本(snapshot)的数据。数据只有一个版本: 最新版本
- 无需维护流处理、流处理两种计算逻辑及批流数据合并
劣势
- 思维方式需要从批处理模式切换到流处理模式,使用难度更高,增加了学习成本。
- 有部分计算逻辑基于 Spark 计算框架,切换到 Flink 需要很高的开发成本。
- 对数据生产模块的影响: 增加数据质控难度等
其他
- 颠覆了以往数据生产模式: T+0,T+1,T+N。
- Flink App 需要的内存较 Spark 少,但 Flink App 常驻进程。
本文暂时没有评论,来添加一个吧(●'◡'●)