-
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
相关推荐
智海观潮34 分钟前
DeepSeek在大数据领域正掀起一场深刻的变革陈煜的博客1 小时前
elasticSearch 增删改查 java apizskj_zhyl2 小时前
让科技之光,温暖银龄岁月——智绅科技“智慧养老进社区”星城国际站温情纪实不辉放弃3 小时前
Spark的累加器(Accumulator)梦想养猫开书店3 小时前
36、spark-measure 源码修改用于数据质量监控不辉放弃3 小时前
Spark的宽窄依赖大数据狂人3 小时前
深入剖析 StarRocks 与 Hive 的区别、使用场景及协同方案实践Freed&4 小时前
Elasticsearch 从入门到精通:术语、索引、分片、读写流程与面试高频题一文搞懂柏峰电子4 小时前
光伏气象监测系统:当阳光遇见科技Leo.yuan4 小时前
国内数据集成厂商有哪些?如何选择最适合的数据集成平台?