-
queue + flink + mysql/redis :
最初形态,flink做计算,结果插入数据库中,数据库的查询速度很快。缺点是不够灵活,只能查询计算好的聚合数据,想查其他维度或条件的数据,要从头开发一套完整的流程
-
queue + flink + clickhouse(OLAP) :
flink 只做 etl 和 join 形成宽表,结果导入支持向量化(?)的 clickhouse,查询在 ck 上做。缺点是 clickhouse 要用 ssd 和 好 cpu,价格昂贵
-
queue + flink hive sink + hive (ad-hoc)
用 flink 的 hive sink 代替 clickhouse, flink 还是只做 etl + join 宽表,只是查询从 OLAP 换成了存储便宜的 ad-hoc (即席查询)。由于 flink 的 hie sink 延迟是 checkpoint 级别的,一般几分种,所以这种结构做了离线数仓的近实时
-
queue + flink CDC + iceberg
该方案用 iceberg 替换掉 hive 做离线数仓存储。好处是 iceberg 只负责存储,可以对外被实时流读取,也可以做离线查询。比 hive 的可用性强,而且数据更安全了,这意味着你可以做一些小数据的操作:比如 INSERT INTO 一些数据,DELTE \ UPDATE \ MERGE_INTO 有着更好的支持,而不是像 Hive 一样,要安全的动数据只能 INSERT OVERWRITE 整个分区。。缺点是 CDC 入离线数仓产生的文件不好控制,而且由于那个时候 iceberg 还不能支持 upsert (有就update,没有就insert),所以使用 flink CDC(Change Data Capture) 入仓所采用的"前天的一个全量表,合并今天的增量表,产生今天的全量表"的存储方式。使得每天一个全量表存储成本巨大。
实际业务为什么要用 CDC 同步 mysql呢?在 OLTP 系统中,为了解决单表数据量大的问题,通常采用分库分表的方式将单个大表进行拆分以提高系统的吞吐量。 但是为了方便数据分析,通常需要将分库分表拆分出的表在同步到数据仓库、数据湖时,再合并成一个大表。 目前 iceberg 支持 upsert 的特性, 但 Iceberg 主打离线数据湖和扩展性
-
flink cdc / kafka cdc + paimon :
paimon原生支持flink cdc,因为他的前身叫 flink table store. 而却设计成支持 upsert, 使用 lsm 树的格式
相比于 Flink SQL 入湖,Paimon 的 CDC 入湖不但可以将数据和 Schema 的变更一起同步到 Paimon 的表中。每天的离线视图可以通过 CREATE TAG 创建,Tag 是一个 snapshot 的引用。而且基于LSM数据结构的特点,只要增量数据不大,两个 TAG 之间是可以复用大量文件的,某些场景有上百倍的节省!
实时湖仓架构演变
烛影摇红透纱窗2024-09-27 9:03
相关推荐
互联科技报30 分钟前
孙宇晨将出席迪拜Token2049 与特朗普次子共话加密未来科技小E1 小时前
EasyRTC嵌入式音视频通信SDK智能安防与监控系统的全方位升级解决方案刘翔在线犯法1 小时前
如何搭建spark yarn模式的集合集群富能量爆棚2 小时前
如何搭建spark yarn 模式的集群Betty_蹄蹄boo3 小时前
在Spark集群中搭建StandaloneAORO_BEIDOU3 小时前
遨游三防|30200mAh、双露营灯三防平板,见证堆料天花板24k小善4 小时前
FlinkJobmanager深度解析Betty_蹄蹄boo4 小时前
如何搭建spark yarn模式的集群和算法死磕到底4 小时前
ubantu18.04(Hadoop3.1.3)之Flink安装与编程实践(Flink1.9.1)MXsoft6184 小时前
监控易一体化运维:巧用排班管理,提升运维协同效能