将 SDO_GEOMETRY 类型序列化为文本真的很慢

Serializing SDO_GEOMETRY type to text really slow

我这几天一直在尝试通过 Microsoft Azure 数据工厂 (gen2) 将 Oracle table 中的 SDO_GEOMETRY 记录提取到 CSV 文件中。我的 select 语句如下所示:

select t.MY_GEOM.get_WKT() from my_table t

其中 MY_GEOM 列的类型为 SDO_GEOMETRY。它有效,但它真的非常慢。通过此方法提取 74000 条记录大约需要 2 小时。 如果没有这种转换(因此,没有 .get_wkt() 的普通 select 大约需要 32 秒,但当然结果是垃圾且无法使用。

有什么方法可以加快这个过程吗?我的猜测是问题出在服务器端,但我不是 DBA,无法直接访问它。我可以通过 SQL Developer 或从数据工厂连接到它。

那里包含的数据只是一些 LINESTRING(x1 y1, x2 y2, ...)

我也试过运行SDO_UTIL.TO_WKTGEOMETRY转换,但是同样慢。

如果您有任何建议,请告诉我。

亲切的问候, 帝舵

据我所知,不会对 ADF 中的数据源或接收器施加额外的负担,所以看起来这是使用 get_WKT() 方法的数据库端的性能瓶颈。

当然可以参考tuning guides in this link to improve your transfer performance.Especially for Parallel copy. For each copy activity run, Azure Data Factory determines the number of parallel copies to use to copy data from the source data store and to the destination data store.That's based on the DIU.

我在寻找不同的方法时找到了一个很好的解决方案。正如上面的一些评论所述,这个对我有用的解决方案包括两个步骤:

  1. 通过以下 select 语句
  2. 将 SDO_GEOMETRY LINESTRING 条目拆分为其坐标
SELECT t.id, nt.COLUMN_VALUE AS coordinates, rownum FROM my_table t, TABLE(t.SDO_GEOMETRY.SDO_ORDINATES) nt 

我只是在 Azure 数据工厂的普通副本 Activity 中使用它,将我的原始文件作为 CSV 保存到数据湖中。文件很大,比下一步创建的最终版本大4倍左右

  1. 通过一些 Databricks Scala Spark 代码将坐标聚合回字符串
val mergeList = udf { strings: Seq[String] => strings.mkString(", ") } 

val result = df.withColumn("collected", 
     collect_list($"coordinates").over(Window.partitionBy("id").orderBy("rownum")) 
  ) 
  .groupBy("id") 
  .agg(max($"collected").as("collected")) 
  .withColumn("final_coordinates", mergeList($"collected")) 
  .select("id", "final_coordinates")

val outputFilePrefix = s"$dataLakeFolderPath/$tableName"
val tmpOutputFolder = s"$outputFilePrefix.tmp"

result
  .coalesce(1)
  .write
  .option("header", "true")
  .csv(tmpOutputFolder)

dbutils.fs.cp(partition_path, s"$outputFilePrefix.csv")
dbutils.fs.rm(tmpOutputFolder, recurse = true)

final_coordinates 列以正确的顺序包含我的坐标(我遇到了一些问题)。而且我可以清楚地将文件保存回我的存储帐户。最后,我只保留了我感兴趣的适当的 CSV 文件。

正如我所说,它非常快。我的第一步大约需要 2.5 分钟,第二步需要几秒钟,而我需要 2 小时,所以,我对这个解决方案非常满意。