-
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
相关推荐
阿里云大数据AI技术5 小时前
StarRocks 助力数禾科技构建实时数仓:从数据孤岛到智能决策Lx35210 小时前
Hadoop数据处理优化:减少Shuffle阶段的性能损耗武子康14 小时前
大数据-99 Spark Streaming 数据源全面总结:原理、应用 文件流、Socket、RDD队列流阿里云大数据AI技术1 天前
大数据公有云市场第一,阿里云占比47%!Lx3521 天前
Hadoop容错机制深度解析:保障作业稳定运行T06205142 天前
工具变量-5G试点城市DID数据(2014-2025年向往鹰的翱翔2 天前
BKY莱德因:5大黑科技逆转时光鸿乃江边鸟2 天前
向量化和列式存储IT毕设梦工厂2 天前
大数据毕业设计选题推荐-基于大数据的客户购物订单数据分析与可视化系统-Hadoop-Spark-数据可视化-BigDatajava水泥工2 天前
基于Echarts+HTML5可视化数据大屏展示-白茶大数据溯源平台V2