使用交叉连接时空间比较慢答案

【问题标题】：Slow spatial comparison when using cross join使用交叉连接时空间比较慢
【发布时间】：2017-04-01 09:10:21
【问题描述】：

我正在使用 U-SQL 来选择一个或多个形状内的所有对象。该代码有效，但确实很慢。有什么方法可以提高性能吗？

@rs1 =
    SELECT DISTINCT aisdata.imo,
                    portshape.unlocode
    FROM @lsaisdata AS aisdata
         CROSS JOIN
             @portsshape AS portshape
    WHERE Geometry.STMPolyFromText(new SqlChars(portshape.shape.Replace("Z", "").ToCharArray()), 0).STContains(Geometry.Point(aisdata.lon, aisdata.lat, 0)).IsTrue;

添加了有关我的问题的更多信息：

我已经注册了 Microsoft.SqlServer.Types.dll 和 SqlServerSpatial130.dll 以便能够在 U-SQL 中使用空间函数
我正在使用两个 AU 在 Data Lake Analytics 中运行我的工作。最初我使用了 10 个 AU，但“诊断”选项卡显示该作业过度分配了 8 个 AU，最大有用 AU 为 2。
使用下面的 UDT 代码运行该作业大约需要 27 分钟，而交叉连接几乎花费了所有时间
输入是一个 csv 文件 (66 Mb) 和一个 wkt 文件 (2.4 Mb)
我正在使用 Visual Studio 2015 和 Azure Data Lake Tools v2.2.5000.0
我尝试在 UDT 中封装一些空间代码，从而将性能提高到 27 分钟：

@rs1 =
SELECT DISTINCT aisdata.imo,
portshape.unlocode
FROM @lsaisdata AS aisdata
CROSS JOIN
@portsshape AS portshape WHERE portshape.geoShape.GeoObject.STContains(SpatialUSQLApp.CustomFunctions.GetGeoPoint(aisdata.lon, aisdata.lat).GeoObject).IsTrue;

【问题讨论】：

请详细一点！你是在本地运行吗？ “慢”有多长？多少数据？在 Azure 中拥有 200 个计算节点的工作怎么样？还是慢？什么版本的 Visual Studio？您安装了哪个版本的 Data Lake Tools？

标签： azure-data-lake u-sql

【解决方案1】：

首先，CROSS JOIN 将始终将您的数据分解为 NxM 矩阵。根据行数，这可能会使其非常昂贵并且可能难以估计正确的并行度。

其次，我假设您执行的空间连接是一项昂贵的操作。例如，如果您使用 SQL Server 2012 的空间功能（2016 具有可能更快一点的类型的本机实现），我假设您可能会获得类似的性能行为。大多数情况下，您需要空间索引来获得更好的性能。现在 U-SQL 不支持空间索引，但您可能可以通过使用抽象来近似相同的行为（例如对象的镶嵌并确定它们是否重叠），以便在您测试条件之前提供更快的预过滤/连接清除误报。

【讨论】：