Databricks Delta Lake并发问题：安全ID生成及写入冲突解决求助

1. 生成UUID作为唯一ID #

UUID（通用唯一识别码）是分布式场景下最省心的唯一ID生成方案，完全不需要集群协调，每个Notebook进程本地生成，理论上冲突概率可以忽略不计，完全满足5个并行Notebook的并发插入需求。

代码示例（Python）：

import uuid
# 生成32位十六进制UUID
unique_id = uuid.uuid4().hex
# 插入语句示例
spark.sql(f"""
INSERT INTO audit_table (id, task_name, start_time, end_time)
VALUES ('{unique_id}', 'task_A', current_timestamp(), NULL)
""")

代码示例（Scala）：

import java.util.UUID
val uniqueId = UUID.randomUUID().toString
spark.sql(s"""
INSERT INTO audit_table (id, task_name, start_time, end_time)
VALUES ('$uniqueId', 'task_A', current_timestamp(), NULL)
""")

2. 基于分区键+时间戳+随机数的复合ID #

既然已经按task_name分区，我们可以结合分区键、高精度时间戳和随机数生成唯一ID，既保证唯一性，又能让ID带有业务语义，方便后续查询过滤。

代码示例（Python）：

import time
import random

task_name = "task_A"
# 生成毫秒级时间戳+3位随机数
timestamp = int(time.time() * 1000)
random_suffix = random.randint(0, 999)
unique_id = f"{task_name}_{timestamp}_{random_suffix}"

# 插入语句
spark.sql(f"""
INSERT INTO audit_table (id, task_name, start_time, end_time)
VALUES ('{unique_id}', '{task_name}', current_timestamp(), NULL)
""")

这种方式下，同一task_name的作业即使在同一毫秒启动，3位随机数也能避免ID重复，同时ID包含分区键，后续按task_name查询时可以快速定位分区。

3. 基于Delta乐观锁的重试机制（补充方案） #

如果必须使用递增类ID（比如业务需要连续ID），可以结合Delta Lake的乐观并发控制，实现“生成ID-尝试插入-冲突重试”的逻辑：

• 先读取当前表的最大ID，加1作为新ID
• 尝试插入，如果因为ID重复抛出并发冲突异常，重新读取最大ID再尝试
• 设置重试次数（比如3次），避免无限循环

代码示例（Python）：

import time

def get_next_id():
    max_id_row = spark.sql("SELECT COALESCE(MAX(id), 0) AS max_id FROM audit_table").collect()[0]
    return max_id_row["max_id"] + 1

retry_times = 3
success = False
task_name = "task_A"

for _ in range(retry_times):
    try:
        new_id = get_next_id()
        spark.sql(f"""
        INSERT INTO audit_table (id, task_name, start_time, end_time)
        VALUES ({new_id}, '{task_name}', current_timestamp(), NULL)
        """)
        success = True
        break
    except Exception as e:
        # 捕获并发冲突相关异常，比如Delta的WriteConflictException
        if "WriteConflictException" in str(e):
            time.sleep(0.1)
            continue
        else:
            raise

if not success:
    raise Exception(f"插入失败，已重试{retry_times}次")

注意：这种方式仅适合并发量不大的场景（比如你当前的5个并行Notebook），如果并发量更高，建议优先用UUID方案。

关于更新并发的补充验证 #

你已经按task_name分区，Delta Lake的分区级乐观锁会减少冲突范围，建议测试时可以模拟多个Notebook同时更新同一task_name的记录，验证是否还会出现冲突。如果仍有问题，可以考虑在更新时加上WHERE条件的行级过滤，或者使用Delta的MERGE INTO语句，它本身具备并发安全的更新逻辑。

内容的提问来源于stack exchange，提问作者SK ASIF ALI