通过 JDBC 从 Spark 中提取 table 数据时出现 PostgreSQL 错误
PostgreSQL error when extracting table data via JDBC from Spark
我的 Spark 到 HAWQ JDBC 连接正常,但现在两天后从 table 中提取数据时出现问题。 Spark 配置没有任何变化...
简单的步骤 #1 - 从 HAWQ 中的简单 table 打印模式
我可以创建一个 SQLContext DataFrame 并连接到 HAWQ 数据库:
df = sqlContext.read.format('jdbc').options(url=db_url, dbtable=db_table).load()
df.printSchema()
打印:
root
|-- product_no: integer (nullable = true)
|-- name: string (nullable = true)
|-- price: decimal (nullable = true)
但是当实际尝试提取数据时:
df.select("product_no").show()
弹出这些错误...
org.apache.spark.SparkException: Job aborted due to stage failure: Task 0 in stage 0.0 failed 1 times, most recent failure: Lost task 0.0 in stage 0.0 (TID 0, localhost):
org.postgresql.util.PSQLException: ERROR: could not write 3124 bytes to temporary file: No space left on device (buffile.c:408) (seg33 adnpivhdwapda04.gphd.local:40003 pid=544124) (cdbdisp.c:1571)
at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2182)
at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1911)
at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:173)
at org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:615)
at org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:465)
at org.postgresql.jdbc2.AbstractJdbc2Statement.executeQuery(AbstractJdbc2Statement.java:350)
at org.apache.spark.sql.jdbc.JDBCRDD$$anon.<init>(JDBCRDD.scala:372)
at org.apache.spark.sql.jdbc.JDBCRDD.compute(JDBCRDD.scala:350)
at org.apache.spark.rdd.RDD.computeOrReadCheckpoint(RDD.scala:277)
at org.apache.spark.rdd.RDD.iterator(RDD.scala:244)
at org.apache.spark.rdd.MapPartitionsRDD.compute(MapPartitionsRDD.scala:35)
at org.apache.spark.rdd.RDD.computeOrReadCheckpoint(RDD.scala:277)
at org.apache.spark.rdd.RDD.iterator(RDD.scala:244)
at org.apache.spark.rdd.MapPartitionsRDD.compute(MapPartitionsRDD.scala:35)
at org.apache.spark.rdd.RDD.computeOrReadCheckpoint(RDD.scala:277)
at org.apache.spark.rdd.RDD.iterator(RDD.scala:244)
at org.apache.spark.rdd.MapPartitionsRDD.compute(MapPartitionsRDD.scala:35)
at org.apache.spark.rdd.RDD.computeOrReadCheckpoint(RDD.scala:277)
at org.apache.spark.rdd.RDD.iterator(RDD.scala:244)
at org.apache.spark.api.python.PythonRDD$WriterThread$$anonfun$run.apply(PythonRDD.scala:248)
at org.apache.spark.util.Utils$.logUncaughtExceptions(Utils.scala:1772)
at org.apache.spark.api.python.PythonRDD$WriterThread.run(PythonRDD.scala:208)
我尝试过的事情(但如果有更精确的步骤,我愿意再试一次):
- 在 HAWQ 主节点上尝试了 'df -i',但只有 1% 的利用率
- 在 HAWQ 数据库上尝试了 dbvacuum(不推荐使用 VACUUM ALL
在 HAWQ 上)
- 尝试创建这个微型新数据库(使用单个 table,3
列),运气不好
这不可能是真正的内存不足,所以是什么地方和什么原因导致的??
could not write 3124 bytes to temporary file: No space left on device
用于临时文件的卷已满。然后临时文件将在错误时被删除,因此您实际上不会在 df
.
中看到完整的卷
在大多数 Linux 系统上,这可能是一个临时文件系统,如 /tmp
。如果是这样,它由虚拟内存支持。要确认,请检查 mount
并检查 PostgreSQL 的 temp_tablespaces
(SHOW temp_tablespaces
) 的设置。如果它是空白的,PostgreSQL 将使用默认的表空间,它不太可能是 tempfs,但如果设置了它,请检查该表空间在哪里。如果它是 on tempfs,您可能需要移动它。
它也可能以某种方式填满了主表空间,但如果它目前只有 1% 的利用率,那是极不可能的。也许大规模失控的递归 CTE 可以做到,但这不太可能。
配额管理也是一种可能。可能配置了文件系统配额?
我的 Spark 到 HAWQ JDBC 连接正常,但现在两天后从 table 中提取数据时出现问题。 Spark 配置没有任何变化...
简单的步骤 #1 - 从 HAWQ 中的简单 table 打印模式 我可以创建一个 SQLContext DataFrame 并连接到 HAWQ 数据库:
df = sqlContext.read.format('jdbc').options(url=db_url, dbtable=db_table).load()
df.printSchema()
打印:
root
|-- product_no: integer (nullable = true)
|-- name: string (nullable = true)
|-- price: decimal (nullable = true)
但是当实际尝试提取数据时:
df.select("product_no").show()
弹出这些错误...
org.apache.spark.SparkException: Job aborted due to stage failure: Task 0 in stage 0.0 failed 1 times, most recent failure: Lost task 0.0 in stage 0.0 (TID 0, localhost):
org.postgresql.util.PSQLException: ERROR: could not write 3124 bytes to temporary file: No space left on device (buffile.c:408) (seg33 adnpivhdwapda04.gphd.local:40003 pid=544124) (cdbdisp.c:1571)
at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2182)
at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1911)
at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:173)
at org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:615)
at org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:465)
at org.postgresql.jdbc2.AbstractJdbc2Statement.executeQuery(AbstractJdbc2Statement.java:350)
at org.apache.spark.sql.jdbc.JDBCRDD$$anon.<init>(JDBCRDD.scala:372)
at org.apache.spark.sql.jdbc.JDBCRDD.compute(JDBCRDD.scala:350)
at org.apache.spark.rdd.RDD.computeOrReadCheckpoint(RDD.scala:277)
at org.apache.spark.rdd.RDD.iterator(RDD.scala:244)
at org.apache.spark.rdd.MapPartitionsRDD.compute(MapPartitionsRDD.scala:35)
at org.apache.spark.rdd.RDD.computeOrReadCheckpoint(RDD.scala:277)
at org.apache.spark.rdd.RDD.iterator(RDD.scala:244)
at org.apache.spark.rdd.MapPartitionsRDD.compute(MapPartitionsRDD.scala:35)
at org.apache.spark.rdd.RDD.computeOrReadCheckpoint(RDD.scala:277)
at org.apache.spark.rdd.RDD.iterator(RDD.scala:244)
at org.apache.spark.rdd.MapPartitionsRDD.compute(MapPartitionsRDD.scala:35)
at org.apache.spark.rdd.RDD.computeOrReadCheckpoint(RDD.scala:277)
at org.apache.spark.rdd.RDD.iterator(RDD.scala:244)
at org.apache.spark.api.python.PythonRDD$WriterThread$$anonfun$run.apply(PythonRDD.scala:248)
at org.apache.spark.util.Utils$.logUncaughtExceptions(Utils.scala:1772)
at org.apache.spark.api.python.PythonRDD$WriterThread.run(PythonRDD.scala:208)
我尝试过的事情(但如果有更精确的步骤,我愿意再试一次):
- 在 HAWQ 主节点上尝试了 'df -i',但只有 1% 的利用率
- 在 HAWQ 数据库上尝试了 dbvacuum(不推荐使用 VACUUM ALL 在 HAWQ 上)
- 尝试创建这个微型新数据库(使用单个 table,3 列),运气不好
这不可能是真正的内存不足,所以是什么地方和什么原因导致的??
could not write 3124 bytes to temporary file: No space left on device
用于临时文件的卷已满。然后临时文件将在错误时被删除,因此您实际上不会在 df
.
在大多数 Linux 系统上,这可能是一个临时文件系统,如 /tmp
。如果是这样,它由虚拟内存支持。要确认,请检查 mount
并检查 PostgreSQL 的 temp_tablespaces
(SHOW temp_tablespaces
) 的设置。如果它是空白的,PostgreSQL 将使用默认的表空间,它不太可能是 tempfs,但如果设置了它,请检查该表空间在哪里。如果它是 on tempfs,您可能需要移动它。
它也可能以某种方式填满了主表空间,但如果它目前只有 1% 的利用率,那是极不可能的。也许大规模失控的递归 CTE 可以做到,但这不太可能。
配额管理也是一种可能。可能配置了文件系统配额?