数据湖：Hudi构建中台

        Hudi和DaltaLake对spark强绑定，建议使用Saprk。用Flink的话可能要改源码

三个开源数据湖技术：

都支持多数据格式，流批一体，acid语义保证，支持table schema

        delta：绑定了spark（一家公司），功能不完善

        hudi：在spark在2.4.3后可以和spark分开，现在也能支持python了。

                对flink支持不是特别好

        iceberg：抽象程度高，灵活，支持flink，presto。小文件处理不好

急着用就hudi，一两年以后则用iceberg

Hudi核心概念介绍

        数据写入hudi两种模式

                1：COW:写时复制，读写分离

                                复制一份数据然后写入复制出来的数据

                2：MOR：读时合并

                                读数据的时候先合并。读的时候先把两份数据合并再读出

        Hudi数据查询三种模式

                1：读优化：读取base文件，不读后来的

                2：增量   查到最新的数据

                3：快照查询   每段时间数据状态保留然后根据快照快速获取数据，能获取commit的快照数据

        

Hudi的架构：

        1：有序的时间轴元数据（可做数据回溯）

        2：分层分布的数据文件

        3：Index索引（书的目录）

然后提供Views去读数据

Hudi的源语（开始就不能停止的操作）

        1：支持对一条数据的细粒度数据的delete和update（不是物理删除而是逻辑删除，做字段标记是否删除）

        2：变更流：也可以做增量数据流，变更数据流的管道（如kafka）

Hudi表的设计

        ArrivalTime：到达Hudi时间

        committime：提交时间

        EventTim：事件时间

最关注事件时间EventTime

Hudi数据的删改：导入标记为update的数据和标记为delete的数据  

有序的数据时间轴：

        只要对hudi的数据有操作，就会在TimeLine上记录一个Instant时间点，hudi保证了操作的原子性（未提交就相当于无）和时间轴的一致性，数据可回滚，快照

        

Hudi表设计：

1：数据文件

        底层存储选择啥？

        数据目录和数据文件。分区中有FileGroup(分桶)中有FileSlices(一个parquet文件)

        hudie文件中记录操作

2：HudieKey

        每条数据有个唯一标识：将数据集中的唯一字段+所在分区联合起来当作唯一键。这样就增删改查

3：索引

        快速找到对应数据，布隆过滤器

Hudi的特性和功能：

        效率的提升，支持CURD语义，支持增量查询(一直有数据过来一直增量)，不再进行快照全量计算，只处理有变更的记录并且只重写已经更新/删除的部分，而不是重写整个分区甚至整张表，这些操作带来一个数量级的效率提升

        更快的etl派生pipeline，自动进行准实时增量计算，而不是Azkaban调度系统依赖触发任务运行进行ETL操作

        节省大量计算资源成本

        统一存储引擎

Hudi功能

        支持快速可插拔索引的upsert

        高效，只扫描新数据的增量查询

        原子性的数据发布回滚，支持恢复的savepoint

        具有多版本并发控制的风格设计的读写快照分离

        已有记录update/delet的自管理压缩

        审核数据修改的时间轴元数据

        全状态数据保留功能

Hudi的存储格式和查询类型

        读优化的列存储和写优化的行存储

Hudi提供的两种存储格式（两种不兼容）

        读优化的列存储：Parquet

        写优化的行存储：Avro

表类型

        写时复制

        读时合并

不同表如何加速（6种）见ppt

案例：数据湖解决问题

痛点

        支付的长尾属性：下次打车再支付上一次的

                一年以前的冷数据何时需要更新，数仓更新的话后面要逐层更新(级联更新)

        超长的业务窗口：

                窗口支付时间长达半年，回溯成本高

        迟到的数据无法预判：

                ODS层表随时变更，窗口的时间eventtime的时候无法回避迟到（比如网络延迟），那么等不等这些数据呢（上次的窗口已经触发计算了）。那么要重新计算是吗

        数据采集的pipeline无法保证可靠性

                部分写成功怎么办，逻辑错了写入脏数据怎么办，网络不稳定没有收到写成功的反馈再发送导致数据重复怎么办。

        数仓数据摄取延迟性高

                hive索引缺失，小文件多

        数据版本缺失

        不支持增量处理

        

Hudi如何解决这些痛点

长尾支付

        冷数据频繁更新

        Hudi的索引：行级别的upsert，可以读时合并，不会触碰冷数据，会写到新的文件

        然后增量查询：查询commit之间的数据变更，在下游upsert更新

超长业务窗口

        很久以前的数据拿出来再计算成本很高

        时间轴的功能：一个订单的所有时间都有，直接回溯到最初时间

驾驶舱无法对已经计算的再计算，无法确定时间窗口

        TimeLine：找到两次间增量数据，找到窗口

        增量查询：

数据采集可靠性

        部分失败：原子性操作，没commit就不算

        脏数据：写错了Rollback

        网络导致的数据重复：upsert是幂等性更新(每次都一样的)

数据链路太长找不到问题

        利用hudi的敏捷分析，找到数据问题

数据采集增量数据延迟高

        行级索引，行级upsert

小文件没问题

具体实现：

        kafka+flink+hudi(调度加工)+查询

1，hudi与spark解耦  flink流式写入

2，高效快速数据加工  写commit通知，调度集成

3，低延迟交互式查询

HudiWriteClient与Spark解耦

        要改源码，对自身能力要考虑下？？？

        希望数据批量写入hudi，这样就在timeline中留下记录