实时湖仓架构演变

  1. queue + flink + mysql/redis :

    最初形态,flink做计算,结果插入数据库中,数据库的查询速度很快。缺点是不够灵活,只能查询计算好的聚合数据,想查其他维度或条件的数据,要从头开发一套完整的流程

  2. queue + flink + clickhouse(OLAP) :

    flink 只做 etl 和 join 形成宽表,结果导入支持向量化(?)的 clickhouse,查询在 ck 上做。缺点是 clickhouse 要用 ssd 和 好 cpu,价格昂贵

  3. queue + flink hive sink + hive (ad-hoc)

    用 flink 的 hive sink 代替 clickhouse, flink 还是只做 etl + join 宽表,只是查询从 OLAP 换成了存储便宜的 ad-hoc (即席查询)。由于 flink 的 hie sink 延迟是 checkpoint 级别的,一般几分种,所以这种结构做了离线数仓的近实时

  4. 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 主打离线数据湖和扩展性

  5. 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 之间是可以复用大量文件的,某些场景有上百倍的节省!

相关推荐
互联科技报30 分钟前
孙宇晨将出席迪拜Token2049 与特朗普次子共话加密未来
大数据
科技小E1 小时前
EasyRTC嵌入式音视频通信SDK智能安防与监控系统的全方位升级解决方案
大数据·网络·人工智能·音视频
刘翔在线犯法1 小时前
如何搭建spark yarn模式的集合集群
大数据·分布式·spark
富能量爆棚2 小时前
如何搭建spark yarn 模式的集群
大数据·javascript·spark
Betty_蹄蹄boo3 小时前
在Spark集群中搭建Standalone
大数据·分布式·spark
AORO_BEIDOU3 小时前
遨游三防|30200mAh、双露营灯三防平板,见证堆料天花板
大数据·科技·安全·智能手机·电脑·信息与通信
24k小善4 小时前
FlinkJobmanager深度解析
java·大数据·flink·云计算
Betty_蹄蹄boo4 小时前
如何搭建spark yarn模式的集群
java·大数据·spark
和算法死磕到底4 小时前
ubantu18.04(Hadoop3.1.3)之Flink安装与编程实践(Flink1.9.1)
大数据·flink
MXsoft6184 小时前
监控易一体化运维:巧用排班管理,提升运维协同效能
大数据·服务器·数据库