Django部署EC2时触发Databricks处理文件存S3的实现方案咨询

1. 架构可行性 #

完全可落地，属于Web应用与重计算逻辑解耦的标准生产实践，没有不可绕过的技术卡点。把CPU、内存消耗高的数据处理环节从EC2的Web服务层拆到Databricks运行，还能避免计算任务占满Web服务器资源，导致正常的页面访问、上传下载请求卡顿。

2. Notebook触发方案 #

你之前没找到直接触发Notebook的REST API是检索方向有偏差，Databricks原生就提供完整的Jobs REST API，完全不需要绕Lambda层做触发：

• 提前把处理逻辑的Notebook绑定为一个Databricks Job，直接调用/api/2.1/jobs/run-now接口，在请求体里就能传自定义参数（比如输入文件路径、输出路径、计算配置等）触发Notebook运行，鉴权用Databricks后台生成的个人访问令牌（PAT）即可，整个调用逻辑和普通第三方API没有区别。
• 如果你本身需要额外做请求流控、参数校验、多环境权限隔离，用AWS Lambda做中间层也完全可行：Lambda可以直接被API Gateway封装为标准REST接口，你的Django应用调用这个REST接口触发Lambda，Lambda内部再调用Databricks的Jobs API即可，整条链路没有兼容性问题，只是多了一层转发，会增加少量维护成本和延迟。

3. 存储选型建议 #

DBFS和S3都能实现文件读写，但优先选S3作为统一存储层，两者对比如下：

• 选S3的优势：EC2上的Django应用可以直接通过IAM角色权限读写S3，给用户提供下载时只需要生成S3预签名URL，不需要经过Databricks或者Django服务中转文件，带宽成本和服务器压力都更小；同时S3可以独立配置生命周期规则、存储分层、备份策略，成本和灵活性都更高；Databricks侧只要配置好S3访问权限（实例Profile或者挂载方式都可以），就能直接读写S3上的CSV文件，没有额外开发量。
• 选DBFS的劣势：DBFS是Databricks工作区的内置存储，EC2上的Django应用无法直接访问DBFS文件，必须通过Databricks的文件API中转下载，链路更长，权限配置更复杂，存储成本也比标准S3高，适合存Databricks计算过程中的临时中间文件，不适合存需要给Web端提供下载的最终输出文件。

4. 落地实现路径（生产可用） #

按以下顺序推进，能少走很多弯路：

• 第一步：打通基础存储链路。先完成EC2上Django应用的基础部署，创建专用S3桶，给EC2绑定的IAM角色添加对应S3桶的读写权限；在Databricks工作区配置S3访问权限，写个测试Notebook验证能正常读取S3上的测试CSV、处理后能写回S3指定路径，这一步不要急着写触发逻辑，先把存储权限跑通。
• 第二步：配置Databricks计算任务。把正式的数据处理Notebook注册为单Task的Databricks Job，计算资源选择自动启停的作业集群（比常驻的通用集群省70%以上成本），集群规格按你平时处理CSV的峰值数据量选即可。先用Postman之类的工具直接调用/api/2.1/jobs/run-now接口，传入测试文件的S3路径作为参数，验证任务能正常触发、跑完能正确输出结果到指定S3路径。
• 第三步：改造Django业务逻辑。替换原有的本地处理流程：用户上传CSV后，Django直接把文件存到S3的input/前缀路径下（建议按任务ID做子目录隔离，避免不同用户的文件重名覆盖），拿到文件S3路径后，直接调用Databricks Jobs API触发任务，同时在本地业务库记录任务ID、关联用户、输入输出路径、任务状态等信息。如果要加中间层，就把直接调用Databricks的逻辑放到Lambda里，Django调用Lambda的REST接口即可，逻辑完全一致。
• 第四步：配置状态回调与下载能力。不要在Django侧写轮询逻辑查任务状态，直接在Databricks Job上配置任务成功/失败的Webhook回调，任务跑完后自动请求你Django的回调接口更新任务状态；用户在前端看到任务完成后，Django为对应输出文件生成15-30分钟有效期的S3预签名URL，用户点击即可直接从S3下载文件，不需要Django服务做文件中转。

落地注意事项 #

• 所有API调用只传文件路径等元数据，绝对不要通过API传输CSV文件内容，大文件会直接导致接口超时。
• Databricks PAT令牌、S3相关密钥全部存在Django的环境变量或者AWS Secrets Manager里，不要硬编码在代码中，定期轮换即可。
• 提前给Databricks Job配置最大并发数，避免短时间内大量任务提交把集群资源打满。
• 输出文件在S3上可以配置7天自动删除的生命周期规则，避免无用文件长期存储产生额外成本。

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