Delta Lake底层技术详解

一、前言

Spark是大数据分析领域基础软件之一，拥有相当大比例的用户群。Spark的作者之一 Michael Armbrust同时也是Delta Lake的作者。Michael Armbrust从实际工作经验中发现了Parquet（Spark的默认数据格式）的缺点，开发出了Delta Lake弥补了Parquet的缺点，解决了以下痛点问题：
第一：Spark任务半途失败问题

第二：RAW数据缺少严格的格式（schema）问题

第三：并发一致性的问题

第四：数据恢复问题

第五：海量小文件问题

第六：数据分区问题

第七：数据合规问题

二、Delta Lake在大数据生态中的位置

三、Delta Lake支持的数据Connectors

四、Delta Table 和 Parquet Enhance

4.1 Delta Table解决1，2，3，4

Delta Log的事务性ACID，解决了损坏文件和schema错误的问题。

4.2 Parquet Enhance解决问题5，6

1. 对于过小过多的数据文件，假定4个线程同时开始读，那么左上的20个小数据文件总读取时间将是t x 5=5t；
2. 对于过大的数据文件（右上），总读取时间将是t（p3）=t max；
3. 对于损坏数据文件（或者错误文件），左下，读取结果是失败（FAIL）；
4. Delta Lake自动调整数据文件到合适的大小（或分区），因此可以做到右下的最优解（Goal）。如下图：

五、乐观锁解决并发写问题

问题假设： 有一个Delta Lake中的数据文件1.parquet。存在一条commit记录 000000.json（称为Delta Log）。这个时候User1和User2同时需要读写这个1.parquet文件。
Delta Lake如上图的协商流程来处理并发写冲突问题：

1. 记录开始的版本，比如000000。
2. 记录读/写操作
3. 开始竞争写，比如User1赢了，它写commit 000001.json
4. User2输了，开始检查更新000001.json
5. 再次竞争写，它写了commit 000002.json,如下图：
   

六、Z-Order提升读性能

在不改变原始数据文件的情况下，读(2,2)的数据记录（下标从0开始），只需要扫描7个文件。如果是顺序读取则要扫描9个文件。仅仅依靠Z-Order算法就做到了性能的提升。