2 DataLake — 批流一体化的追风者( 三 )


3.3 缓存
由于 Delta 表中的对象及其日志是不可变()的 , 因此集群节点可以安全地将它们缓存在本地存储中 。云服务利用此功能为 Delta 表实现透明的 SSD 缓存 。(开源不可用)
3.4 数据布局优化
这个功能可自动优化表中对象的大小 , 并且会对数据记录进行聚类()(例如 , 将记录存储存储成形式以实现多个维度上的本地化)而不会影响正在运行的查询 。这个功能只有数砖的产品里面有 , 开源的Delta Lake是不包含这个的 。(开源不可用)
3.5 模式演变
如果表的模式发生变化 , Delta 可以继续读取旧的文件而无需重写它们 。之前降到过向后兼容就是这个。
3.6 审计日志
基于事务日志的审计功能 , 可以提高查询的速度和效率 。(开源不可用)
4.流批一体化的优化
可以通过下图看到实时方式和离线方式完全是在两套流程里进行 , 并且其中包含了多个步骤和组件 , 做到离线实时统一 , 一方面是去从整体计算上面去发力 , 另外我们组件层面尽可能的精简也是能否促成这个局面的一种方式 。
同样我们通过Delta Lake可以很好的去跟Spark生态的产品进行融合 , 包括了机器学习、离线实时数据查询、BI报表、实时分析等各个领域 。所以它能提供的能力很大程度上是我们目前正在寻求的一种解决当下问题的方式 , 所以看到这里是不是觉得的确有点意思呢?
5.事务日志原理
5.1 事务日志提交流程
将事务分解为原子提交 , 每当用户执行修改表的操作(例如插入、更新或删除)时 , Delta Lake将该操作分解为一系列由以下一个或多个操作组成的离散步骤:
5.2 处理流程
: Under the hood , 首先需要找到并选择那些包含与谓词匹配因而需要更新的数据的文件 。这个过程中 Delta Lake可以使用data 技术来加速这个过程 。将每个匹配的文件读入内存 , 更新相关行 , 并将结果写入新的数据文件 。
一旦 Delta Lake 成功地执行了 , 它就会在事务日志中添加一个提交 , 表明从现在开始将使用新的数据文件来代替旧的数据文件 。但是旧的数据文件没有被删除 。相反 , 它只是被标记成— 意思是这个文件只属于表的旧版本数据文件而不是当前版本的数据文件 。Delta Lake能够使用它来提供数据版本控制和时间旅行(time ) 。

2  DataLake — 批流一体化的追风者

文章插图
5.3 处理流程
+ :清理旧的文件 。运行命令永久删除满足以下条件的所有数据文件:不再是活动表的一部分 , 并且超过保留阈值(默认为七天) 。
5.4 MERGE处理流程
Delta Lake的MERGE操作帮助我们实现语义 , 它是实现了和的混合 。假设我们有一张目标表和一张源表 , 其中目标表包含新记录和对现有记录的更新 。具体实现原理是通过先用源表和目标数据进行inner join , 得到match的行之后 , 然后再通过 join去更新、删除或新增行 , 即当源表中的一条记录与目标表中现有的记录相匹配时 , Delta Lake 将更新该记录;当没有匹配时 , Delta Lake 将插入新记录;这里便通过join实现了操作 。
MERGE 的实现与或者的主要区别是其使用了 join , 这一事实允许我们在寻求提高性能时使用一些独特的策略 。
MERGE:性能调优
为了提升 MERGE 的执行性能 , 我们需要了解上面两个 join 中的哪个影响了程序的执行 。如果 inner join 是执行 MERGE 的瓶颈(比如找到 Delta Lake 需要重写的文件花费的时间太长了) , 那么我们可以采用以下的策略解决: