scala - Spark 上的应用程序网络？

Question

我遇到了一些性能问题，有几个问题想问您:)我创建了一个 Scala 应用程序。该应用程序实时计算一些统计数据，例如来自 cassandra 数据库的 session ......。我使用 Spray 作为 http 框架来创建我的 API 。我使用 Spark 来计算和映射 cassandra 的结果。我使用 Spark-Submit 将我的应用程序放入 Spark 中。

您认为这是直接在 Spark 中开发应用程序的最佳方式吗？或者我应该在 Spark 之外创建一个应用程序(http)，并调用另一个应用程序仅用于使用 Spark 从 cassandra 计算数据？

我有 3 台服务器(1 台 32G 8 核，1 台 64G 8 核，最后一台 64G 12 核)进行测试(我知道如果我的集群中有相同的服务器应该会更好，但我暂时不能)。我用的是独立模式。我在spark_default.sh中的配置:

spark.deploy.defaultCores=28
spark.executor.memory=30G

目前速度很慢，需要 9 秒并有 3 个 Spark 特质:

• 一张 map 、一个排序和 1 次收集(需要 4 秒)
• 求和运算(需要 3 秒)
• 求和运算(需要 2 秒)

只是为了这样的结果:

{"result":"success","list":[{"item":"1474236000","value":6},{"item":"1474239600","value":3},{"item":"1474243200","value":3},{"item":"1474246800","value":3},{"item":"1474250400","value":3},{"item":"1474254000","value":8},{"item":"1474257600","value":4},{"item":"1474261200","value":11},{"item":"1474264800","value":1},{"item":"1474268400","value":3},{"item":"1474272000","value":18},{"item":"1474275600","value":6},{"item":"1474279200","value":4},{"item":"1474282800","value":2},{"item":"1474286400","value":2},{"item":"1474293600","value":4},{"item":"1474297200","value":10},{"item":"1474300800","value":10},{"item":"1474304400","value":8},{"item":"1474308000","value":6},{"item":"1474311600","value":8},{"item":"1474315200","value":4},{"item":"1474318800","value":4},{"item":"1474322400","value":6}],"nb_session":137.0,"old_nb_session":161}

你对我有什么建议吗？我不明白为什么这么慢:(

非常感谢

Answer 1

我建议您直接与 Cassandra 和 CQL 合作。如果您无法在 CQL 中反射(reflect)所有内容，您始终可以创建用户定义函数 (UDF)。

https://docs.datastax.com/en/cql/3.3/cql/cql_using/useCreateUDF.html

By default, Cassandra 2.2 and later supports defining functions in java and javascript. Other scripting languages, such as Python, Ruby, and Scala can be added by adding a JAR to the classpath. Install the JAR file into $CASSANDRA_HOME/lib/jsr223/[language]/[jar-name].jar where language is 'jruby', 'jython', or 'scala'

制作低延迟 Apache Spark 解决方案的选项之一是将数据保留在 Apache Spark 中(跨多个请求)，并仅查询每个请求中的缓存数据(并跳过从 cassandra 加载部分)。这并非易事。