分析 Merge-on 条件 ， 得到 source 表中对应到 DeltaLake 表分区字段的字段 。统计得到分区字段的枚举列表 。将上步结果转化成 Filter 对象并应用 ， 进一步过滤裁剪数据文件列表 。读取最终的数据文件列表和 batch 的 source 数据关联得到最终需更新的文件列表 。通过 DPP 优化后 ， Spark 一个 batch（5min粒度）的处理延迟由最大20mins+ 减少到 最大~3mins ， 完全消除了过去因为处理时间过长导致延迟不断叠加的问题 。
使用 Zorder 提高读性能
在解决了数据的写入性能后 ， 我们又遇到了数据读取性能的问题 。
我们使用同样的数据（200亿+） ， 使用 Hive 计算 ， 平均延迟10min+ ， 而使用 DeltaLake 后 ， 平均延迟居然高达~11mins+ 。 分析后发现主要是没有对筛选列使用 Zorder 排序 ， 当开启 Zorder 后 ， 延迟则降低到了~24s ， 提高了近25X性能 。

基于 Zorder 对 DeltaLake 表进行查询优化 ， 主要会涉及两个方面的提升：
Dataskipping DeltaLake 会按照文件粒度统计各个字段的 max/min 值 ， 用于直接过滤数据文件 。Zorder 一种数据 layout 的方式 ， 可以对数据重排列尽可能保证 Zorder 字段的数据局部性 。Zorder 构建耗时优化
对哪些列开启 Zorder 是按需构建的 ， 常规情况构建时长~30mins ， 数据倾斜下 ， 构建Zorder 时长高达~90mins 。
针对这两种情况 ， 对 Zorder 进行了优化：
常规情况下 ， 对于多列的 Zorder ， 由多次遍历数据集改为遍历一次数据集来提升构建效率 。 构建时长从平均~30mins降低到~20mins 。数据倾斜下 ， 对于倾斜列所在的 bucket 做了热点分散 ， 构建时长从平均~90mins降低到~30mins 。
总体效果
经过了近半年多的开发和优化 ， 近期基于 DeltaLake 的离线数仓已经上线 ， 重点是提升分析的查询优化 ， 同时针对有小时全量需求的场景 ， 也同样提供了支持 ， 整体看的效果如下：
就绪时间更快：ODS 替换到 DeltaLake 后 ， 产出时间从之前凌晨2:00 - 3:00 提前到凌晨00:10左右 ， 产出时间提前了2个多小时 。能力扩展更广：大数据具备了支持小时全量表的能力 ， 利用 DeltaLake 增量更新的特性 ， 低成本的实现了小时全量的需求 ， 避免了传统方案下读取全量数据的消耗 。 目前已经应用到了部分核心业务中来 ， 构建小时级全量表 ， 同时时效性上保障从过去的~40mins降低到~10mins 。查询速度提升：我们重点提升的分析师的即席查询效率 ， 通过将分析师常用的数仓表迁移到 Deltalake 之后 ， 利用 Zorder 实现了查询加速 ， 查询速度从过去的数十分钟降低到~3mins 。 五、未来规划 随着 DeltaLake 在作业帮的使用 ， 当前还有一些问题有待解决：
提高修数效能 。使用 Hive 时我们可以方便的针对某个历史分区独立修复 ， 但是 DeltaLake 表修数时需要通过回退故障版本后的所有版本 。完全支持 Hive 引擎 。目前我们使用 DeltaLake ， 主要解决了过去使用 Hive 查询慢、使用 Presto 限制复杂查询的问题 ， 在复杂查询、低延迟上提供了解决方案 ， 但前面提到的 GSCD、Dataskipping 等特性 Hive 还不支持 ， 导致用户无法像使用 Hive 一样使用 DeltaLake 。支持 Flink 接入 。我们流计算系统生态主要围绕 Flink 构建 ， 引入 DeltaLake 后 ， 也同时使用 Spark ， 会导致我们的流计算生态维护成本加重 。 六、致谢 最后 ， 非常感谢阿里云 EMR 数据湖团队 ， 凭借他们在 DeltaLake 中的专业能力和合作过程中的高效支持 ， 在我们这次数据湖迁移过程中 ， 帮助我们解决了很多关键性问题 。
原文链接:http://click.aliyun.com/m/1000320972/
【病毒|作业帮基于 DeltaLake 的数据湖建设最佳实践】