2024年大数据最新实时数仓之实时数仓架构(Hudi)，2024年最新2024大数据开发面试题知识点总结

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

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

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

目前比较流行的实时数仓架构有两类，其中一类是以Flink+Doris为核心的实时数仓架构方案；另一类是以湖仓一体架构为核心的实时数仓架构方案。本文针对Flink+Hudi湖仓一体架构进行介绍，这套架构的特点是可以基于一套数据完全实现Lambda架构。实时数仓架构图如下：

• 技术框架

  • 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实时任务；

• 数仓架构

采用维度模型标准三层架构，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老爷子写了几百万字的著作，主要描述的是数据建模的思想。

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

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

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

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