基于Delta Lake的Upserts数据湖方案

基于Delta Lake的Upserts数据湖方案_第1张图片

导读

基于HDFS的传统数据存储方案由于HDFS等存储平台的限制,只能增加文件不能修改文件中的内容。想要实现某条记录的变更,就需要读取对应的文件并进行重写,效率极低,而且容易引起数据不一致和冲突。Delta Lake是基于Apache Spark的下一代数据湖存储引擎,支持Merge命令,可以高效的完成upsert或删除。

基于Delta Lake的Upserts数据湖方案_第2张图片

1 为什么需要Upserts?

1 迎合GDPR,general data protection regulation《通用数据保护条例》,这个法案规定需要在使用个人敏感信息时,得到数据主体的同意,并提供自由的查看删除机制。

2 传统数据的CDC,change data capture 变更数据捕获:移动端和web端基于传统数据库实现低延迟的微服务,困难是各个数据库的数据如何统一分析,因此数据分析师需要构建各种ETL把数据汇总到统一的数据湖中。同步数据时经常涉及的变更来自于schema的修改、数据的增删改。

3 会话化:在广告分析或者用户行为分析中,基于会话的事件分析需求是很常见的。但是在数据湖中由于数据都是append追加模式,想要不断的更新会话信息还是比较困难的。比如想把同一个会话中的数据汇总成一条,保存在数据湖中。传统方案需要读取所有的数据,把新的事件追加到会话中,重新写入。

4 去重:一般来说数据湖的数据都是追加模式,因此经常需要在读取数据后进行去重。比如通过每天维护一个业务表的全量信息,使用时需要读取全部数据,按照id取最新的数据。

2 Upserts的挑战

数据湖基于文件,一般都是以追加的形式修改数据。当有数据需要改变时,经常需要读取全部内容重新写回到平台。这种方式:

1 低效:读写整个分区或者表更新少量的记录,会导致延迟和消耗。需要手动调优表和查询

2 出错:手工代码可能会出现BUG,多个操作同时处理一个表时可能报错。

3 难以维护:手工代码难以理解,追踪调试,随着使用的时间,更难维护

Delta Lake就是既能解决更新效率低下,又能进行并发读写控制,还支持时间回溯,查看历史任意时间的数据快照。

3 Delta中的Merge

基于Delta可以很轻松的使用Merge命令完成上面的操作,如下所述,当userId相同时,更新address字段;当userId没有出现在原表中时,则进行插入操作。

MERGE INTO users
USING updates
ON users.userId = updates.userId
WHEN MATCHED THEN
      UPDATE SET address = updates.addresses
WHEN NOT MATCHED THEN
      INSERT (userId, address) VALUES (updates.userId, updates.address)

整个Merge的流程大致:

内部会通过待更新的数据DataFrame与原表进行inner join,找到哪些文件存在数据交集。一方面读取找到的文件的全部内容,与待更新的表进行full outer join,并按照规则更新字段,存储到delta的数据目录,并标记为新增;另一方面直接把找到的文件标记为删除。

基于Delta Lake的Upserts数据湖方案_第3张图片

因此可以做到如下的优点:

1 细粒度,更新的内容以文件粒度进行修改,而不是分区维度;

2 高效,有数据跳过的机制(inner join后没有标记出的文件什么也不做),不需要全表读取重写

3 事务,基于乐观锁控制并发写入,基于快照机制支持并发读取

基于Delta Lake的Upserts数据湖方案_第4张图片

总结来说:

在不使用Delta Lake时,需要分析表中哪些分区需要重写;读取对应分区下的所有数据,与更新数据join,重写。

使用Delta Lake时,直接基于merge命令,自动完成数据的更新插入。

4 总结

基于delta lake的merge机制,可以自动完成数据的更新插入。而且这种数据更新插入以文件为最细粒度,效率高;支持事务;支持并发读写。可以很方便的实现批流的整合。

典型的应用场景:使用structured streaming以微批的形式把变更同步到delta lake,后面对接流或者批实现业务计算。

基于Delta Lake的Upserts数据湖方案_第5张图片

更多系列内容:

你可能感兴趣的:(大数据,大数据)