Delta Lake 在 Soul 的应用实践

一、背景介绍

（一）业务场景

传统离线数仓模式下，日志入库前首要阶段便是ETL，Soul的埋点日志数据量庞大且需动态分区入库，在按day分区的基础上，每天的动态分区1200+，分区数据量大小不均，数万条到数十亿条不等。下图为我们之前的ETL过程，埋点日志输入Kafka，由Flume采集到HDFS，再经由天级Spark ETL任务，落表入Hive。任务凌晨开始运行，数据处理阶段约1h，Load阶段1h+，整体执行时间为2-3h。

（二）存在的问题

在上面的架构下，我们面临如下问题：

1.天级ETL任务耗时久，影响下游依赖的产出时间。
2.凌晨占用资源庞大，任务高峰期抢占大量集群资源。
3.ETL任务稳定性不佳且出错需凌晨解决、影响范围大。

二、为什么选择Delta？

为了解决天级ETL逐渐尖锐的问题，减少资源成本、提前数据产出，我们决定将T+1级ETL任务转换成T+0实时日志入库，在保证数据一致的前提下，做到数据落地即可用。
之前我们也实现了Lambda架构下离线、实时分别维护一份数据，但在实际使用中仍存在一些棘手问题，比如：无法保证事务性，小文件过多带来的集群压力及查询性能等问题，最终没能达到理想化使用。

所以这次我们选择了近来逐渐进入大家视野的数据湖架构，数据湖的概念在此我就不过多赘述了，我理解它就是一种将元数据视为大数据的Table Format。目前主流的数据湖分别有Delta Lake(分为开源版和商业版)、Hudi、Iceberg，三者都支持了ACID语义、Upsert、Schema动态变更、Time Travel等功能，其他方面我们做些简单的总结对比：

开源版Delta

优势：

1.支持作为source流式读
2.Spark3.0支持sql操作

劣势：

1.引擎强绑定Spark
2.手动Compaction
3.Join式Merge，成本高

Hudi

优势：

1.基于主键的快速Upsert/Delete
2.Copy on Write / Merge on Read 两种merge方式，分别适配读写场景优化