- 
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企微观察2 分钟前
企业微信如何正确营销获客?精准定位与场景触达的实践框架金融Tech趋势派37 分钟前
企业微信私有化服务商怎么选?从数据安全与定制化需求看适配方向艾莉丝努力练剑1 小时前
【Linux权限 (二)】Linux权限机制深度解析:umask如何决定默认权限与粘滞位的妙用武子康1 小时前
大数据-140 ClickHouse CollapsingMergeTree详解 外部数据源最小闭环HDFS/MySQL/Kafka文火冰糖的硅基工坊2 小时前
[人工智能-大模型-107]:模型层 - 神经元的功能角色:特征提取与相似度量化2501_938773992 小时前
《Hadoop 与 Spark 融合路径:基于 Spark on YARN 的部署与调优技巧》河南博为智能科技有限公司2 小时前
十六串口服务器-解决多设备联网难题2501_938791832 小时前
从原理到实操:彻底解决 Git .gitignore 文件不生效问题Elastic 中国社区官方博客3 小时前
如何在 Azure 虚拟机上部署 Elasticsearch2501_938773993 小时前
大数据离线处理:使用 Airflow 调度 Hive 脚本的工作流设计