-
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
相关推荐
码界筑梦坊3 小时前
基于Spark的抖音数据分析热度预测系统生信学习小达人5 小时前
arcgis10.8 Toolbox中没有找到conversion tools模块Oo_Amy_oO6 小时前
Airflow+Spark/Flink vs. Kettle后端小肥肠6 小时前
港大团队开源LightRAG:知识图谱+双层检索,复杂问答准确率飙升30%计算机毕设定制辅导-无忧学长18 小时前
TDengine 权限管理与安全配置实战(二)2401_8979300618 小时前
Kibana 连接 Elasticsearch(8.11.3)教程计算机毕设定制辅导-无忧学长18 小时前
TDengine 快速上手:安装部署与基础 SQL 实践(一)塔能物联运维19 小时前
塔能科技:精准节能,擎动工厂可持续发展巨轮今天我又学废了19 小时前
Spark,HDFS概述青云交20 小时前
Java 大视界 -- 基于 Java 的大数据机器学习模型在图像识别中的迁移学习与模型优化(173)