我有一个进程，在短时间内100+相同的databricks笔记本在一个相当强大的集群上并行运行。每个笔记本在其进程结束时会将大约100行数据写入存储在azuregen1datalake中的同一个delta-lake表。我看到delta的插入时间非常长，因为我只能假设delta在插入时会锁定表，然后在单个笔记本完成后释放它，以阅读为基础https://docs.databricks.com/delta/concurrency-control.html 这意味着不存在插入冲突，跨多个集群的多个写入程序可以同时插入数据。
对于100+笔记本，每个笔记本插入100行需要3个多小时。导致瓶颈的当前代码是：
df.write.format（“delta”）.mode（“append”）.save（“<path\”）
目前这个表上没有分区，这可能是一个修复方法，但是在继续这个过程之前，我是否遗漏了一些关于如何并行地获得不冲突的插入的内容？
1条答案
按热度按时间tyky79it1#
您必须在表的两种隔离级别之间进行选择，较弱的隔离级别是默认值，因此不会脱离隔离级别。https://docs.databricks.com/delta/optimizations/isolation-level.html
delta-lake具有occ（乐观并发控制），这意味着要写入表的数据将根据其他99个进程要写入的所有数据进行验证。这意味着正在进行100*100=10000次验证。https://en.wikipedia.org/wiki/optimistic_concurrency_control
还请记住，当100个笔记本中的最后一个笔记本完成时，您的数据处理架构将完成。也许100本笔记本中的一本或多本需要3个小时才能完成，而插页不是罪魁祸首？
如果长时间运行的笔记本不是这样，我建议您尝试将每个笔记本的结果数据存储在某种数据结构中（例如，将其存储在每个笔记本的100个文件中），然后将数据结构的数据（例如，文件）批插入到目标表中。
数据处理将是并行的，插入将不是并行的。