结合Azure Data Factory与Databricks实现分层架构的最佳实践咨询

核心设计原则 #

• 层间半持久化原则：摒弃「每层落业务库」或「全链路纯内存」的极端方案，采用低成本对象存储做层间缓存，平衡执行效率与可维护性
• 边界清晰原则：每层脚本仅负责当前层的转换逻辑，输入输出路径、处理规则完全解耦，禁止跨层读写
• 可观测性优先原则：所有层级的执行状态、数据校验结果均可被ADF直接读取，不依赖Databricks会话状态做链路管控
• 可回溯原则：所有层的输出数据保留版本，支持单层级独立重跑，不依赖上游全链路重新执行

落地最佳实践 #

解决I/O开销过高问题 #

核心思路是减少高成本存储的反复读写，复用计算资源

• 层间数据统一写入ADLS Gen2的Delta格式缓存目录，不要直接写入Azure SQLDB这类业务持久化库：Delta格式自带压缩、索引优化，Databricks读写速度比读写关系型数据库高5~10倍，同时避免了业务库的写入压力
• ADF调用Databricks作业时配置复用同一个常驻集群，不要每层都启动新集群：公共维表、广播变量等数据可直接保留在集群内存中，无需每层重复加载
• 分层脚本支持增量处理逻辑，仅处理当前批次的新增/变更数据，不需要全量扫描上游层的全量数据

解决链路追踪与层级重跑问题 #

核心思路是把状态管控逻辑从Databricks剥离，统一收敛到ADF侧

• 每个层级的Databricks脚本执行完成后，除了输出数据到缓存目录，还会生成对应的批次控制文件，记录当前批次的处理时间、数据量、校验值、执行状态等信息
• ADF流水线按层级拆分为独立的Databricks活动节点，每个节点执行前先校验上游层的控制文件状态，确认上游处理成功后再启动当前层的任务；执行完成后读取当前层的控制文件，把状态同步到ADF的运行日志中
• 每层脚本都预留输入参数位，支持通过dbutils.widgets.get()方法接收ADF传入的批次号、上游数据路径等参数，需要重跑特定层时，只需要在ADF中指定对应批次的上游路径，即可单独触发该层执行，不需要重新运行上游所有任务
• 错误告警直接绑定到ADF的对应层级活动节点，出错时自动返回该层的Databricks运行日志链接、错误信息，不需要登陆Databricks排查全链路日志

流水线编排参考 #

ADF流水线的基础编排结构如下：

• 批次触发节点（支持定时/事件触发）
• 摄入层Databricks活动：读取源端数据，清洗后写入ADLS的ingestion层目录，生成对应控制文件
• 加工层Databricks活动：读取ingestion层的Delta数据，完成关联、汇总等转换逻辑，写入propagation层目录，生成控制文件
• 数据集市层Databricks活动：读取propagation层的Delta数据，按业务需求建模后写入Azure SQLDB等最终交付存储
• 每个活动节点都配置独立的重试次数、告警规则、失败分支逻辑，支持在ADF控制台右键单独重跑指定节点

内容的提问来源于stack exchange，提问作者Frank