如何有效合并PySpark数据名人堂?

时间:2019-02-03 18:15:56

标签: apache-spark merge pyspark apache-spark-sql

我在Pyspark中有两个数据框,它们已经合并了大约两天。第一个大约是6,000,000个特征x 2600行,第二个大约是30个特征x 2600行。我怀疑花了这么长时间才是合并之前spark的实际准备工作。这是我的代码:

from pyspark.sql import SQLContext
import pyspark
from pyspark.sql.functions import col, split, create_map, lit
from pyspark.ml import Pipeline
from pyspark.ml.classification import RandomForestClassifier
from pyspark.ml.feature import IndexToString, StringIndexer, VectorIndexer
from pyspark.ml.evaluation import MulticlassClassificationEvaluator

sql_c = SQLContext(sc)

df = sql_c.read.option("maxColumns", 10000000).option("header", "true").options(samplingRatio=0.01).option("inferSchema", "true").csv('join_rows_no_prepended_new_line.csv')

df2 = sql_c.read.option("maxColumns", 10000000).option("header", "true").options(samplingRatio=0.01).option("inferSchema", "true").option("delimiter", "\t").csv('metadata_merged.txt')

#create a new column with a SampleID that matches the SampleID columns from the metadata df.
df = df.withColumn('#SampleID', split(df['# Gene Family'], '\_')[0])

df = df.drop("# Gene Family")
feature_cols = df.columns
df = df.join(df2, col("df.SampleID Gene Family")==col("df2.#SampleID"), how='inner')

最后一行是运行单线程两天的那一行。在Pyspark中是否有更好的方法来进行数据准备或其他方面的工作?

谢谢。

1 个答案:

答案 0 :(得分:2)

  • Spark SQL绝对不是适合此工作的工具。

    由于Spark SQL将关系模型和查询计划程序与优化器一起使用,因此在列数方面存在大量的存储和计算开销。下限是线性的(表示模式的成本),但是实际上,查询计划器的复杂度要高得多,在最坏的情况下是指数级的。

    因此,当列数不超过几千时,可以很方便地使用Spark SQL,尽管可以在必要时将其推入较低的数万。数以百万计的列只是行不通。

  • 低效的纯文本格式可能不是这项工作的正确工具。

  • Spark ML可能不是适合该工作的工具。

    一般来说,只要数据稀疏,Spark ML算法就可以对宽范围的组合数据进行合理的操作。没有足够的信息来确定是否是这种情况。

    在某些情况下,Widish数据可以在Spark中处理,但与Spark ML中可用的数据相比,它需要更低级别的优化(更智能的编码,使用更低的精度数字)。

  • 一般来说,火花可能不是正确的工作工具。

    内置函数和常用软件包均假定您使用的数据较长且(相对)较窄*,并且对于非常宽的数据根本无法正常工作。可以使用自定义阅读器逻辑和自定义算法来解决此问题,但这不是开箱即用的,并且根据问题,找到可扩展的解决方案可能会面临挑战。

其中的一些问题很容易解决(例如,回落到RDD API以加载,解析和组装数据应解决优化程序瓶颈),其他问题则可能需要大量工作(具有短数据特征子集的集成模型可以只要可以确保有效地选择性访问数据,就可以并行进行有效的培训)。问题仍然在于,是否真的值得付出努力-数据量表明100GB数据范围内的某处-中档服务器的内存中无法处理的任何事情。


*当然,这并非特定于Spark。默认情况下,大多数分布式处理工具都会做出类似的假设。