使用 spark-cassandra 连接器在 cassandra 中写入时间
write times in cassandra using spark-cassandra connector
我有这个用例，我需要不断地听一个 kafka 主题并根据来自 Spark 流应用程序的列值写入 2000 个列族（每个 15 列.. 时间序列数据）。我有一个本地 Cassandra 安装设置。在使用 3 个内核和 12 GB 内存的 CentOS VM 上创建这些列族大约需要 1.5 小时。在我的 Spark Streaming 应用程序中，我正在做一些预处理以将这些流事件存储到 Cassandra。我 运行 对我的流媒体应用程序完成此操作所需的时间有疑问。
我试图根据密钥将 300 个事件保存到多个列族（大约 200-250），为此我的应用程序需要大约 10 分钟才能保存它们。这似乎很奇怪，因为将这些事件打印到按按键分组的屏幕需要不到一分钟的时间，但只有当我将它们保存到 Cassandra 时才需要时间。
我在将 300 万条记录保存到 Cassandra 时没有遇到任何问题。花了不到 3 分钟（但这是针对 Cassandra 中的单个列族）。
我的要求是尽可能实时，这似乎还差得远。生产环境每 3 秒大约有 400 个事件。
我是否需要对 Cassandra 中的 YAML 文件进行任何调整或对 cassandra-connector 本身进行任何更改
INFO 05:25:14 system_traces.events 0,0
WARN 05:25:14 Read 2124 live and 4248 tombstoned cells in system.schema_columnfamilies (see tombstone_warn_threshold). 2147483639 columns was requested, slices=[-]
WARN 05:25:14 Read 33972 live and 70068 tombstoned cells in system.schema_columns (see tombstone_warn_threshold). 2147483575 columns was requested, slices=[-]
WARN 05:25:15 Read 2124 live and 4248 tombstoned cells in system.schema_columnfamilies (see tombstone_warn_threshold). 2147483639 columns was requested, slices=[-]
WARN 05:25:15 Read 2124 live and 4248 tombstoned cells in system.schema_columnfamilies (see tombstone_warn_threshold). 2147483639 columns was requested, slices=[-]
WARN 05:25:15 Read 33972 live and 70068 tombstoned cells in system.schema_columns (see tombstone_warn_threshold). 2147483575 columns was requested, slices=[-]
WARN 05:25:15 Read 33972 live and 70068 tombstoned cells in system.schema_columns (see tombstone_warn_threshold). 2147483575 columns was requested, slices=[-]
INFO 05:25:16 ParNew GC in 340ms. CMS Old Gen: 1308020680 -> 1454559048; Par Eden Space: 251658240 -> 0;
WARN 05:25:16 Read 2124 live and 4248 tombstoned cells in system.schema_columnfamilies (see tombstone_warn_threshold). 2147483639 columns was requested, slices=[-]
WARN 05:25:16 Read 33972 live and 70068 tombstoned cells in system.schema_columns (see tombstone_warn_threshold). 2147483575 columns was requested, slices=[-]
WARN 05:25:17 Read 2124 live and 4248 tombstoned cells in system.schema_columnfamilies (see tombstone_warn_threshold). 2147483639 columns was requested, slices=[-]
WARN 05:25:17 Read 2124 live and 4248 tombstoned cells in system.schema_columnfamilies (see tombstone_warn_threshold). 2147483639 columns was requested, slices=[-]
WARN 05:25:17 Read 33972 live and 70068 tombstoned cells in system.schema_columns (see tombstone_warn_threshold). 2147483575 columns was requested, slices=[-]
WARN 05:25:17 Read 33972 live and 70068 tombstoned cells in system.schema_columns (see tombstone_warn_threshold). 2147483575 columns was requested, slices=[-]
INFO 05:25:17 ParNew GC in 370ms. CMS Old Gen: 1498825040 -> 1669094840; Par Eden Space: 251658240 -> 0;
WARN 05:25:18 Read 2124 live and 4248 tombstoned cells in system.schema_columnfamilies (see tombstone_warn_threshold). 2147483639 columns was requested, slices=[-]
WARN 05:25:18 Read 33972 live and 70068 tombstoned cells in system.schema_columns (see tombstone_warn_threshold). 2147483575 columns was requested, slices=[-]
WARN 05:25:18 Read 2124 live and 4248 tombstoned cells in system.schema_columnfamilies (see tombstone_warn_threshold). 2147483639 columns was requested, slices=[-]
WARN 05:25:18 Read 2124 live and 4248 tombstoned cells in system.schema_columnfamilies (see tombstone_warn_threshold). 2147483639 columns was requested, slices=[-]
WARN 05:25:19 Read 33972 live and 70068 tombstoned cells in system.schema_columns (see tombstone_warn_threshold). 2147483575 columns was requested, slices=[-]
WARN 05:25:19 Read 33972 live and 70068 tombstoned cells in system.schema_columns (see tombstone_warn_threshold). 2147483575 columns was requested, slices=[-]
INFO 05:25:19 ParNew GC in 382ms. CMS Old Gen: 1714792864 -> 1875460032; Par Eden Space: 251658240 -> 0;
W
我怀疑您在 cassandra 中遇到了与架构中定义的大量 CFs/columns 相关的边缘情况。通常，当您看到逻辑删除警告时，那是因为您弄乱了数据模型。然而，这些在系统 tables 中，所以很明显你对 tables 做了一些作者没有预料到的事情（很多很多 tables，可能 drop/recreating他们很多）。
添加这些警告是因为扫描过去的逻辑删除以查找活动列会导致内存压力，从而导致 GC，从而导致暂停，从而导致缓慢。
您能否将数据压缩到更少的列族中？您可能还想尝试清除墓碑（将 table 的 gcgs 降为零，运行 系统上的主要压缩是否允许？将其恢复为默认值）。
Spark-Cassandra connector 调优可以参考这篇blog。您将了解可以预期的性能数字。您还可以尝试另一个开源产品 SnappyData，即 Spark 数据库，它将在您的用例中为您提供非常高的性能。
我有这个用例，我需要不断地听一个 kafka 主题并根据来自 Spark 流应用程序的列值写入 2000 个列族（每个 15 列.. 时间序列数据）。我有一个本地 Cassandra 安装设置。在使用 3 个内核和 12 GB 内存的 CentOS VM 上创建这些列族大约需要 1.5 小时。在我的 Spark Streaming 应用程序中，我正在做一些预处理以将这些流事件存储到 Cassandra。我 运行 对我的流媒体应用程序完成此操作所需的时间有疑问。
我试图根据密钥将 300 个事件保存到多个列族（大约 200-250），为此我的应用程序需要大约 10 分钟才能保存它们。这似乎很奇怪，因为将这些事件打印到按按键分组的屏幕需要不到一分钟的时间，但只有当我将它们保存到 Cassandra 时才需要时间。
我在将 300 万条记录保存到 Cassandra 时没有遇到任何问题。花了不到 3 分钟（但这是针对 Cassandra 中的单个列族）。
我的要求是尽可能实时，这似乎还差得远。生产环境每 3 秒大约有 400 个事件。
我是否需要对 Cassandra 中的 YAML 文件进行任何调整或对 cassandra-connector 本身进行任何更改
INFO 05:25:14 system_traces.events 0,0
WARN 05:25:14 Read 2124 live and 4248 tombstoned cells in system.schema_columnfamilies (see tombstone_warn_threshold). 2147483639 columns was requested, slices=[-]
WARN 05:25:14 Read 33972 live and 70068 tombstoned cells in system.schema_columns (see tombstone_warn_threshold). 2147483575 columns was requested, slices=[-]
WARN 05:25:15 Read 2124 live and 4248 tombstoned cells in system.schema_columnfamilies (see tombstone_warn_threshold). 2147483639 columns was requested, slices=[-]
WARN 05:25:15 Read 2124 live and 4248 tombstoned cells in system.schema_columnfamilies (see tombstone_warn_threshold). 2147483639 columns was requested, slices=[-]
WARN 05:25:15 Read 33972 live and 70068 tombstoned cells in system.schema_columns (see tombstone_warn_threshold). 2147483575 columns was requested, slices=[-]
WARN 05:25:15 Read 33972 live and 70068 tombstoned cells in system.schema_columns (see tombstone_warn_threshold). 2147483575 columns was requested, slices=[-]
INFO 05:25:16 ParNew GC in 340ms. CMS Old Gen: 1308020680 -> 1454559048; Par Eden Space: 251658240 -> 0;
WARN 05:25:16 Read 2124 live and 4248 tombstoned cells in system.schema_columnfamilies (see tombstone_warn_threshold). 2147483639 columns was requested, slices=[-]
WARN 05:25:16 Read 33972 live and 70068 tombstoned cells in system.schema_columns (see tombstone_warn_threshold). 2147483575 columns was requested, slices=[-]
WARN 05:25:17 Read 2124 live and 4248 tombstoned cells in system.schema_columnfamilies (see tombstone_warn_threshold). 2147483639 columns was requested, slices=[-]
WARN 05:25:17 Read 2124 live and 4248 tombstoned cells in system.schema_columnfamilies (see tombstone_warn_threshold). 2147483639 columns was requested, slices=[-]
WARN 05:25:17 Read 33972 live and 70068 tombstoned cells in system.schema_columns (see tombstone_warn_threshold). 2147483575 columns was requested, slices=[-]
WARN 05:25:17 Read 33972 live and 70068 tombstoned cells in system.schema_columns (see tombstone_warn_threshold). 2147483575 columns was requested, slices=[-]
INFO 05:25:17 ParNew GC in 370ms. CMS Old Gen: 1498825040 -> 1669094840; Par Eden Space: 251658240 -> 0;
WARN 05:25:18 Read 2124 live and 4248 tombstoned cells in system.schema_columnfamilies (see tombstone_warn_threshold). 2147483639 columns was requested, slices=[-]
WARN 05:25:18 Read 33972 live and 70068 tombstoned cells in system.schema_columns (see tombstone_warn_threshold). 2147483575 columns was requested, slices=[-]
WARN 05:25:18 Read 2124 live and 4248 tombstoned cells in system.schema_columnfamilies (see tombstone_warn_threshold). 2147483639 columns was requested, slices=[-]
WARN 05:25:18 Read 2124 live and 4248 tombstoned cells in system.schema_columnfamilies (see tombstone_warn_threshold). 2147483639 columns was requested, slices=[-]
WARN 05:25:19 Read 33972 live and 70068 tombstoned cells in system.schema_columns (see tombstone_warn_threshold). 2147483575 columns was requested, slices=[-]
WARN 05:25:19 Read 33972 live and 70068 tombstoned cells in system.schema_columns (see tombstone_warn_threshold). 2147483575 columns was requested, slices=[-]
INFO 05:25:19 ParNew GC in 382ms. CMS Old Gen: 1714792864 -> 1875460032; Par Eden Space: 251658240 -> 0;
W
我怀疑您在 cassandra 中遇到了与架构中定义的大量 CFs/columns 相关的边缘情况。通常，当您看到逻辑删除警告时，那是因为您弄乱了数据模型。然而，这些在系统 tables 中，所以很明显你对 tables 做了一些作者没有预料到的事情（很多很多 tables，可能 drop/recreating他们很多）。
添加这些警告是因为扫描过去的逻辑删除以查找活动列会导致内存压力，从而导致 GC，从而导致暂停，从而导致缓慢。
您能否将数据压缩到更少的列族中？您可能还想尝试清除墓碑（将 table 的 gcgs 降为零，运行 系统上的主要压缩是否允许？将其恢复为默认值）。
Spark-Cassandra connector 调优可以参考这篇blog。您将了解可以预期的性能数字。您还可以尝试另一个开源产品 SnappyData，即 Spark 数据库，它将在您的用例中为您提供非常高的性能。