Azure中小规模数据项目：是否仍需采用Databricks？

核心结论：可以用，且在长期视角下更具价值 #

• 成本可控性：Databricks支持按运行时长计费的Serverless模式，或者配置Single Node的Small实例（最低配），如果你的管道每天仅运行几次，每月成本其实很低，和Azure SQL存储过程的成本差异不大。甚至如果管道运行频率低，Databricks的按需启动模式比一直运行的SQL实例更省钱。
• 扩展性预留：虽然当前数据量只有90MB，未来不超过1TB，但业务需求可能变化——比如新增数据管道、添加数据校验/ enrichment逻辑、或者数据量意外增长。Databricks可以无缝扩容集群，不用重构整个转换层；而存储过程在数据量达到GB级后可能出现性能瓶颈，到时候再迁移反而更麻烦。
• 维护与协作效率：Databricks的代码（Python/Scala/SQL）可以放在Git里做版本控制，团队协作修改、回溯历史更方便；而Azure SQL的存储过程分散在数据库中，版本管理、多人协作都比较麻烦，尤其是逻辑变复杂后，可读性和维护性会急剧下降。
• 生态原生整合：和ADF、Data Lake Gen2、PowerBI的整合非常顺畅——ADF可以直接触发Databricks作业，数据在Data Lake里流转无需额外拷贝，PowerBI直接连接Databricks SQL端点，整个链路的配置成本远低于存储过程+SQL Server的组合。

• 数据溯源与故障排查：Landing层保留原始数据，Staging层存转换中间态，一旦后续BI报表出现数据异常，你可以快速回溯到原始数据，排查是源数据问题还是转换逻辑问题；如果只有Curated层，根本没法区分问题出在哪，排查成本极高。
• 逻辑迭代的灵活性：现在转换逻辑简单不代表一直简单——比如未来要加数据去重、字段校验、关联外部维度数据，分层架构可以在Staging层新增处理步骤，不影响Curated层的结构；单一Curated层的话，每次修改逻辑都要直接动最终数据，风险大，也不利于测试。
• 权限与安全隔离：分层可以实现更细粒度的权限控制：Landing层仅允许数据摄入服务写入，Staging层仅允许转换服务读写，Curated层开放给BI团队只读。这种隔离能有效避免误操作（比如BI团队误改原始数据），也符合数据安全的最佳实践。
• 兼容未来的实时需求：如果业务后续需要接入实时数据（比如用户行为日志、IoT数据），Medallion架构的分层可以平滑扩展——在Staging层添加实时流处理作业，数据直接流入Curated层；而单一Curated层很难兼容批量+实时的混合场景，重构成本很高。
• 团队技能的长期价值：Databricks的技能（Spark、Python数据处理）是当前数据工程领域的通用技能，团队掌握后可以复用在其他项目中；而存储过程的技能相对局限，长期来看不利于团队技术能力的提升。

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