HUDI数据湖，俩个核心两点：

1、采用读时模式设计，支持动态schema，动态表结构变更。（对比写时模式）

2、标准化统一和解决了大规模的数据存储问题。

3、高容错的任务调度管理策略，不用担心job失败重跑，也不用担心job重跑的效率问题。

 

下面一步步分析，离线数据仓库痛点有哪些？和思路

1、job任务出问题，从出错的job重跑

2、写时模式，表字段并更怎么办？

3、多个存储如何打通？kafka不能保存全量的数据，历史数据如何分析？

比如：

实时数据flink存储到hbase

离线数据sqoop存储到mysql

如何打通上述是俩个库？

以下篇幅是架构设计的对比。无分层架构、分层架构、数据湖架构的对比：

1、无分层架构，最大的问题就是数据ETL过来直接计算分析得出结果，没有保留原始数据，核心缺点：不能进行2次分析。

2、分层架构，如下：

ELT:通过flume，sqoop等工具从DB和文件抽取数据的称呼,他们都天然支持抽取数据到kafka中。抽取结构化数据（DB数据）、非结构化数据（图片、视频、文本）、半结构化数据（JSON、XML）

下图的意思，用flink算子编程来对数据进行加工，加工后输出到下一层的kafka中。

通过分层，解决了无层架构进行2次分析的问题。中间数据保存在kafka当中，kafka作为分层的持久化点，可以进行2次分析。

核心缺点：

1、kafka的数据存储能力有限，一般保存7天左右。

2、kafka流内的数据无法进行分析。

3、数据湖架构，如下：

数据湖hudi具有哪些功能：

数据湖hudi，可以对数据进行存储和快照，可以回溯和恢复数据，也提供查看的管理界面。

（最终总结的生产环境下好的架构结论）数据湖的一个企业级的架构设计：

以下篇幅是对hudi的知识点总结：

数据湖具备的哪些解决传统数仓问题的核心能力，如下：

hudi官方介绍：

数据湖的业界技术选型：

业内哪些公司使用了hudi:

hudin的内核:

核心一：Time 有三个数据处理的时间，用于解决因为延迟造成的数据时序问题。

1、到达的时间

2、提交的时间

3、记录的时间

核心二：Timeline，来解决因为延迟造成的数据时序问题。

核心三：

核心四：