Spark DataFrame和卡桑德拉

Question

我们一直在使用Spark RDD API（Spark 2.0）来处理在Cassandra.Note中建模的数据，这些数据在Cassandra中建模以实现高效的读写。

然而，现在还有SparkSQLAPI，Spark DataFrame API，它也是一种替代的数据访问方法-http://spark.apache.org/docs/latest/sql-programming-guide.html

使用Spark RDD，我们使用CQL，使用Datastax Cassandra驱动程序API访问CassandraDB-http://docs.datastax.com/en/developer/java-driver/2.0/，类似于

val resultSets = new util.ArrayList[Row]()
val resultSet = CassandraConnector(SparkReader.conf).withSessionDo[ResultSet] { session =>
     val sel_stmt = QueryBuilder.select("yyy", "zz", "xxxx")
                .from("geokpi_keyspace", table_name)
                .where(QueryBuilder.eq("bin", bin))
                .and(QueryBuilder.eq("year", year))
                .and(QueryBuilder.eq("month", month))
                .and(QueryBuilder.eq("day", day))
                .and(QueryBuilder.eq("cell", cell))

    session.execute(sel_stmt)

    }
resultSets.addAll(resultSet.all())
})
resultSets.asScala.toList --> RDD[Row]

由于我们几乎直接使用CQL，它不允许您做Cassandra不支持的事情，如JOINS，因为Cassandra设计不支持它。然而，使用SparkSQL或Spark DataFrame API访问Cassandra数据库的替代方法为您提供了一个SQL类型abstraction.For底层关系数据库，这将是很好的。

但是使用这种抽象，比如JOIN来查询存储在Cassandra这样的NoSQL数据库中的数据，似乎是一种错误的抽象。在Spark中使用这种抽象，而对数据模型(分区键、聚集键等)一无所知，这对于数据的高效读写是如此重要，难道不会导致低效的代码生成和低效/缓慢的从底层Cassandra节点的数据检索吗？

Answer 1

我认为，您认为我们在使用Spark SQL时忽略数据模型的假设是不正确的，实际上我们是在非常严格的合同下工作的，其中数据源可能默认只处理基本的预测和选择，繁重的处理由Spark集群执行。

同时，在设计给定的连接器时，数据源开发人员可以自由地包含任何类型的领域或系统特定知识。JDBC数据源是一个很好的例子，你可以查看我的答案，例如当使用JDBC导入Postgres时，如何划分Spark RDD？以了解如何使用它来执行一些非标准操作。

虽然Cassandra Connector在这里似乎有一些限制（如果我错了，请原谅我，我没有广泛使用它），但它的RDD组件提供了一套广泛的Cassandra-aware操作，可用于执行服务器端操作和优化整个工作流。

无论如何，当Spark试图强制外部系统执行那里不支持的操作时，没有这种情况。

它不会导致高效的生成代码和高效/缓慢的数据检索吗

我们在这里必须问的基本问题是，为什么这会很重要。仅仅通过将给定的源用于分析工作，我们就隐含地接受了这样一个事实，即我们可能会以一种对其日常操作使用不典型的方式来强调给定的系统。

同时，如果我们使用的系统不支持数据处理管道中所需的某些操作，我们应该接受执行这些操作的成本可能明显高于优化系统。虽然低效的处理成本很高，但在选择技术堆栈和设计基础设施时，应该考虑到这一点。

最后，如果某些操作具有不可接受的性能影响（是的，连接代价高昂），那么应该在数据建模中反映出来。

由于我们几乎直接使用CQL，它不允许您执行Cassandra不支持的操作，例如JOINS，因为Cassandra设计不支持它。

正如已经解释过的，Spark SQL也没有。直接获取数据并稍后执行连接不会改变执行模型中的任何内容。

忽略此特定示例中没有任何内容是DataFrameAPI无法处理的，并且可以使用cassandraTable执行更复杂的检索。