2024年大数据最全实时数仓之实时数仓架构(Hudi)(2)，2024年最新附带学习经验_开源实时数仓

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上大数据知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

需要这份系统化资料的朋友，可以戳这里获取

+ Kafka：用于接入数据源；
+ Flink CDC：如果直接接入业务数据源可以考虑CDC方式，如果通过Kafka缓冲接入业务数据可以忽略;
+ Flink：用于数据ETL，包括接入数据、处理数据及输出数据全链路数据计算任务；
+ Spark：用于数据ETL，包括处理数据及输出数据全链路数据计算任务；
+ Hudi：湖仓一体数据管理框架，用来管理模型数据，包括ODS/DWD/DWS/DIM/ADS等；
+ Doris：OLAP引擎，同步数仓结果模型，对外提供数据服务支持；
+ Hbase：用来存储维表信息，维表数据来源一部分有Flink加工实时写入，另一部分是从Spark任务生产，其主要作用用来支持Flink ETL处理过程中的Lookup Join功能。这里选用Hbase原因主要因为Table的Hbase Connector支持异步IO功能。
+ Hera：调度系统，用来调度离线Spark任务；
+ StreamX：Flink任务管理工具，用于部署管理以及监控Flink实时任务；
1
2
3
4
5
6
7
8
9

• 数仓架构

采用维度模型标准三层架构，ODS/DWD/DWS/DIM/ADS，分层架构符合Kimball维度模型建仓指导原则。

+ ODS层：增量方式接入业务数据和日志数据，ODS层分区保留当日增量结果，包含备份和支持下游数据源功能；
+ DIM层：维表加工分为几种情况：


	1. 静态维表/转码表/字典表这些日常不怎么变化的直接加载到Hudi即可，用于flink数据处理；如果应用端需要依赖这类表，Doris也得同步存储一份；
	2. 普通维表数据由Flink完成实时任务加工，由Spark任务完成离线数据修复，同时为了维表Join，维表还需要同步hbase一份(原因可以参考笔者另外一篇博客《Flink基于Hudi维表Join缺陷分析及解决方案》)，同时结果同步Doris，供终端引用。
+ DWD层：维度模型设计，采用事务表建模（目的尽量将单表数据设计关系降低到最低）、易于ETL实现；实时数据装载由Flink驱动，通过对ODS流进行Join、聚合和转行操作、以及对外部表以Lookup Join方式清洗数据(切记不能过分冗余维度数据，底层对数据做分离是核心设计思想，冗余越是过分、维护成本越高)，结果保存Hudi；离线任务修复由Spark实现，操作同一份数据，ETL要做好时间限制条件，避免离线任务影响实时任务，同时结果数据同步Doris，供终端引用；
+ DWS层：非必要不要轻易跨业务过程合并数据，其他参考DWD设计思路。
+ ADS层：面向业务场景编程，一套数据产品对应自己的一套数据，这里一般有两种实现思路可以参考：


	1. Flink/Spark驱动读取DWD/DWS/DIM数据加工ADS结果表，数据写入Hudi，同步Doris供下游引用；
	2. StarRocks高版本支持物化视图功能，可以借助物化视图实现ADS层；总结：无论是实时数仓还是离线数仓建设，问题根源一般来自于模型设计的不合理，要知道数据模型才是维度建模的灵魂，Kimball老爷子写了几百万字的著作，主要描述的是数据建模的思想。
1
2
3
4
5
6
7
8
9
10
11
12
13

• Flink+Hudi实时数仓架构缺点

基于Hudi湖仓一体架构虽然实时性比离线数仓要高很多，但是对比纯实时数仓而言，其延迟性一般在分钟级(到终端引用可能要延迟10~15分钟时间)，对于某些实时性要求较高场景并不适合。

• 常见问题

  • 数据源保序任务：一般来说接入数据源很难完全避免乱序场景发生，这种情况有两种方案可以参考：

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！**