这是我正在处理的问题：
我有这个33 GB的tsv文件有2列，第一个是a_id，第二个是逗号分隔的b_id . 问题是，我需要能够检索b_id的所有a_id，所以我将文件加载到Spark中，我解析它，我平面映射它并将其插入由b_id分区的Cassandra表中 . 这个过程大约需要4个小时，每个分区需要10~15分钟，并加载所有200 M a_id，平均每个20 b_id，所以总共大约4 B行 .
问题是，因为一些b_id非常常见，其中一些分区非常大，最大的分区有170万个单元 . 所以我尝试计算a_id上的哈希并在我正在使用的表中添加一个新列（我实际创建了一个新的单独表），转换为复合分区键 . 结果是写入每个分区所需的时间增加了6倍！
起初，我认为问题出在我通过内置的python hash（）在Spark中进行的哈希计算，所以我用一个更天真的函数替换它，该函数只模拟a_id的最后20位我想要的“子分区”的数量（5），但没有改变......
我无论如何都不是Cassandra的专家，但对我来说这没有任何意义 . 为什么会这样？
1 回答
我不是百分之百确定没有看到你的PySpark代码，但我怀疑减速是因为你使用Python函数来操纵数据，这些函数不能被“推下”并在Spark Worker的JVM中完成 .
当你刚刚做一个简单的平面 Map （我假设在RDD上使用Spark API）时，Spark能够在JVM中执行该功能 . 但是，一旦你开始在这些API之外的Python中执行“自定义”工作，Spark必须在Spark工作者JVM和Python之间序列化和流式传输数据，以便它可以运行Python代码来操作数据 . 我相信它会在一个缓慢的套接字上做到这一点 . 您可以在此处查看有关PySpark内部的更多信息：
https://cwiki.apache.org/confluence/display/SPARK/PySpark+Internals