我处于使用 Azure 数据仓库中的外部表从 Azure 数据湖中读取数据的位置。
这使我们能够使用众所周知的 SQL 从数据湖中读取数据。
但是，另一种选择是使用 Data Lake Analytics 或 HDInsight 的某些变体。
性能方面，我没有看到太大的差异。我假设 Data Warehouse 在后台运行某种形式的分布式查询，转换为 U-SQL（？），那么为什么我们要使用与 U-SQL 语法略有不同的 Data Lake Analytics？
由于 SQL 中也提供了 python 脚本，我觉得我错过了 Data Lake Analytics 的一个关键目的，而不是成本（按批处理作业付费，而不是数据库的恒定运行时间）。
如果您的主要目的是查询存储在 Azure 数据仓库 (ADW) 中的数据，那么使用 Azure 数据湖分析 (ADLA) 并没有真正的好处。但是，一旦您在 ADLS 中存储了其他（非）结构化数据，例如 json 文档或 csv 文件，ADLA 的好处就变得显而易见，因为 U-Sql 允许您将存储在 ADW 中的关系数据与（un）连接起来结构化/nosql 数据存储在 ADLS 中。
此外，它使您能够使用 U-Sql 准备其他数据以直接导入 ADW，因此不再需要 Azure 数据工厂将数据导入您的数据仓库。有关更多信息，请参阅此博文：
ADLS 和 SQL DW 的常见用例如下。原始数据从各种来源被摄取到 ADLS。然后使用 ADL Analytics 将数据清理并处理成可加载的格式。从那里，可以通过 PolyBase 将高价值数据导入 Azure SQL DW。
..
您可以在外部表上使用 Create Table As Select (CTAS) 语句将存储为 ORC、RC、Parquet 或分隔文本文件格式的数据直接导入 SQL DW。
请注意，SQL 数据仓库中的 SQL 语句当前不会在后台生成 U-SQL。此外，ADLA/U-SQL 和 SDW 之间的用例也不同。
ADLA 为您提供了一个处理引擎来进行批量数据准备/烹饪以生成数据以构建数据集市/仓库，然后您可以使用 SQL DW 交互读取该数据集市/仓库。在上面的示例中，您似乎主要在做第二部分。如果您在大数据（而不仅仅是几十万行）上操作，在这些 EXTERNAL 表的顶部添加“视图”以在 SQL DW 中进行转换将很快遇到可伸缩性限制。