当Cassandra在k8s上时，我们使用Spark-Cassandra连接器的写入性能非常糟糕。为了清楚起见-我们试图编写一个具有1.3Bn唯一密钥（约30 GB）的DF，其中包含16个执行器，每个执行器具有4个核心和16 GB内存。我们有一个5节点的Cassandra集群（复制因子= 2），其中cassandra表如下所示：
CREATE TABLE <tablename> (hashed_id text PRIMARY KEY, timestamp1 bigint, timestamp2 bigint)写了大约8个小时……
我们如何编写DataFrame到Cassandra的示例代码：
df
.write
.format("org.apache.spark.sql.cassandra")
.mode("overwrite")
.option("confirm.truncate", "true")
.options(table=tablename, keyspace=cassandra_keyspace)
.save()我们最近开始使用Cassandra，并决定将其部署在Kubernetes上。我们正在Spark上运行一些ETL，需要直接写入Cassandra。
我们的设置是：
- Cassandra（4.0）使用K8ssandra操作符（1.6）部署在k8s上，位于traefik入口后面（无TLS）
- Spark（3.2）部署在Pyspark中的裸机ETL上，使用spark-cassandra-connector_2.12-3.2.0。
我在寻找任何关于如何配置Spark连接器使用在这样的情况下的所有节点的参考。我假设正在发生的是，连接器只能“看到”入口地址，并为其他节点取回内部IP。我们想按照例子here，但不确定我们如何配置Spark连接器使用这样的配置…
1条答案
按热度按时间vh0rcniy1#
有两个问题
1.为什么写入时间更长？
1.我不太清楚SCC在K8s入口中的作用。
回答问题#1
spark.cassandra.connection.resolveContactPoints当设置为true（默认）控制，如果我们需要解决接触点在开始（真），或在重新连接（假）。这对于Kubernetes或其他具有动态端点的系统很有帮助，这些端点可能会在应用程序运行时发生变化。确保您没有将其设置为false。spark.cassandra.coonection.host-这里给出的主机将用作C* 集群的初始联系点。在获得初始连接后，它将找到群集的整个拓扑。SCC配置参数在here中可用。您可以调整
Write Tuning Parameters，即以spark.cassandra.output.*开头的。此外，确保C* 集群的大小正确（例如硬件规格、数据模型等）来有效地运行。