Spark是大数据分析领域基础软件之一,拥有相当大比例的用户群。Spark的作者之一 Michael Armbrust同时也是Delta Lake的作者。Michael Armbrust从实际工作经验中发现了Parquet(Spark的默认数据格式)的缺点,开发出了Delta Lake弥补了Parquet的缺点,解决了以下痛点问题:
第一:Spark任务半途失败问题
第二:RAW数据缺少严格的格式(schema)问题
第三:并发一致性的问题
第四:数据恢复问题
第五:海量小文件问题
第六:数据分区问题
第七:数据合规问题
Delta Log的事务性ACID,解决了损坏文件和schema错误的问题。
- 对于过小过多的数据文件,假定4个线程同时开始读,那么左上的20个小数据文件总读取时间将是t x 5=5t;
- 对于过大的数据文件(右上),总读取时间将是t(p3)=t max;
- 对于损坏数据文件(或者错误文件),左下,读取结果是失败(FAIL);
- Delta Lake自动调整数据文件到合适的大小(或分区),因此可以做到右下的最优解(Goal)。如下图:
问题假设: 有一个Delta Lake中的数据文件1.parquet。存在一条commit记录 000000.json(称为Delta Log)。这个时候User1和User2同时需要读写这个1.parquet文件。
Delta Lake如上图的协商流程来处理并发写冲突问题:
- 记录开始的版本,比如000000。
- 记录读/写 *** 作
- 开始竞争写,比如User1赢了,它写commit 000001.json
- User2输了,开始检查更新000001.json
- 再次竞争写,它写了commit 000002.json,如下图:
在不改变原始数据文件的情况下,读(2,2)的数据记录(下标从0开始),只需要扫描7个文件。如果是顺序读取则要扫描9个文件。仅仅依靠Z-Order算法就做到了性能的提升。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)