我有基于Azure数据工厂和Azure数据湖分析（U-SQL）制作ETL解决方案的经验。
但是似乎微软已经开始强制使用Azure Databricks。
U-SQL快要死了吗？自7月以来，我还没有看到任何有关新功能的消息。
即将到来的项目非常简单。我们在Azure Data Lake Storage上存储了约0.5 Tb的小型JSON文件。它们需要转换为平面表并以某种方式连接。
所以我的问题是为新项目ADF + U-SQL或ADF + DataBricks选择什么？
答案 0 :(得分：2)
Spark的数据工程/转换编程模型从根本上比U-SQL更具灵活性和可扩展性。
对于小型，简单的项目，您不会注意到有什么不同，我建议您随便使用任何熟悉的东西。对于复杂的项目和/或您希望需求有很大变化的项目，我强烈建议使用受支持的语言之一的Spark：Scala，Java，Python或R，而不要使用SparkSQL。推荐该标准的原因是，Spark的用于数据转换的领域特定语言（DSL）使SQL代码生成等效，这是所有BI /分析/仓储工具在幕后用来管理复杂性的窍门，非常容易。它允许在处理SQL时以不可能或不切实际的方式来组织和管理逻辑/配置/自定义，我们不应该忘记这种SQL已经有40多年的历史了。
对于Spark可能实现的抽象级别的一个极端示例，您可能会喜欢https://databricks.com/session/the-smart-data-warehouse-goal-based-data-production
如果您要处理肮脏/不受信任的数据（本例中为JSON），并且希望高度控制/自定义提取过程，我也建议使用Spark。在这种情况下，您可能会受益于spark-records库中用于防弹数据处理的一些想法。 https://databricks.com/session/bulletproof-jobs-patterns-for-large-scale-spark-processing
在使用Spark时，尤其是对于新用户而言，Databricks提供了最佳的托管环境。我们多年来一直是客户，负责管理数PB的非常复杂的数据。我们团队中的人来自SQL背景，不是软件开发人员，他们在Databricks笔记本中使用SparkSQL，但他们受益于数据工程和数据科学团队为他们创建的工具/摘要。
祝您的项目好运！