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中留下记录