Nosql 架构设计/备份策略

Question

我们将 cassandra 用于基于 IOT 的应用程序。目前我们每天收到 10 GB 的数据。我们以时间序列模型的方式将所有数据存储到 Cassandra 中的单个表中。将数据保存在单个表或多个表（年，月）中的最佳方法是什么。

架构：

CREATE TABLE SensorData (
    cid text,
    event_date date,
    event_time timestamp,
    data text,
    device_id text,
    device_type text,
    rawdata text,
    PRIMARY KEY ((cid, event_date), event_time)
) WITH CLUSTERING ORDER BY (event_time DESC)

Spark 作业列表：

1. 需要为单个日期运行客户端作业
2. 需要为单个日期运行客户端作业。 （应用允许过滤）
3. 需要针对所有客户端单个数据执行特定作业
4. 需要针对所有客户端单个数据执行特定作业

如果数据大小增加作业变慢。我们是否需要关注性能指标（cassandra/spark）或者我们应该将数据保存在不同的小表中。

备份策略

制定备份策略的最佳方法是什么？

1. 卡桑德拉方式 https://docs.datastax.com/en/cassandra/2.1/cassandra/operations/ops_backup_restore_c.html

2. 外部数据源类型到磁盘，如 csv/平面文件等。

Answer 1

据我所知，您似乎还可以。当谈到架构时。 如果将来您可能会收到毫秒级的消息 您可能希望分区的级别甚至低于一天级别 你现在拥有的。

但是一天可能还好。因为传感器很少 在几秒钟内发送数据。我什至参与了一个项目 我们按月分区，数据以秒为单位 这没什么大不了的。所以从模式看你是 好的。

Spark 作业似乎也包含在架构中。

1. 没问题，因为您可以在没有的情况下获取一天的所有数据 太麻烦了
2. 我会避免应用过滤，尤其是如果您每天有 10 GB 随着时间的推移，这只会变得更糟。如果你提供一些细节 关于为什么需要过滤我可能会有所帮助。我诚实的建议是 一起避免这一切。
3. 这需要您遍历日期分区。我猜 我最好的建议是每天简单地回到历史。和 你需要一个智能终止条件。要么固定为所有 客户（即不要进入过去，比如说超过 x 个月）。或者 你可以让它更聪明，即当你进入客户的“所有”历史时 假设 10 天桶是空的，你就停下来。但这可能 棘手的是一些客户的中断时间更长。无论如何，你应该做 这是可配置的。
4. 这可能是一个很好的答案，但如果您已经在使用 spark 这个 应该不是问题。

使用 cassandra 最好简单地预先准备数据。所以你的 架构工作正常对于 1 和 2，你很好。 3也可以，但4是 总是有点棘手。如果您每天将 10 GB 添加到一组中，则按照设计 而你想要处理所有这些，每次都需要越来越长的时间 天。如果您想要所有数据，您实际上无能为力。

通常在这种情况下，您会制作某种已经制作的 etl 假设您需要特定时间单位的总和和平均信息。 即，如果您的报告是一整天的，那么您在 cassandra 中创建新条目 那天并存储结果。这样你就不必重新处理它 每次再一次。所以你的问题不是多个较小的表，而是 您设计 ETL 操作的方式。

对于备份，我建议使用常规的 cassandra 工作流程。你提供的 在链接中工作正常。从来没有任何问题。我也写了 一些将东西导出到 csv 的工具，但这更适用于其他客户 以及希望对我们拥有的数据进行自己处理的公司。

附加问题后更新答案：

Q1：每天的数据将被每月截断，怎么样？

CREATE TABLE SensorData(
  cid text,
  event_date date,
  event_time timestamp,
  data text,
  device_id text,
  device_type text,
  rawdata text,
  PRIMARY KEY ((cid, event_date), event_time, device_id, device_type)
) WITH CLUSTERING ORDER BY (event_time DESC)

Q2：创建下表用于历史处理是否有意义：

CREATE TABLE SensorData_YYYYMM (
  cid text,
  event_date text,
  event_time timestamp,
  data text,
  device_id text,
  device_type text,
  rawdata text, PRIMARY KEY ((cid, event_date), event_time, device_id, device_type) 
) WITH CLUSTERING ORDER BY (event_time DESC)

这个想法本身并没有那么糟糕，但我有几个担忧。第一 是您会将一个客户日的所有数据放入单个分区中。 根据您获得的客户数量，这可能会变得太大。 通常在物联网中，您希望将来自单个传感器的数据保存在单个分区中。 并且您将一些时间维度键添加到分区键。这使得制作 etl 工作相对容易。 所以基本上第一张桌子的关键可能是((cid, device_id, event_date) event_time, device_type

其次，如果您曾经预计来自一台设备的两条消息 可能以相同的毫秒数进入系统，您可能会丢失数据。所以我会 建议您使用 timeuuid 输入 event_time。是的，这需要更多 空间，但您可以安全地应对可能会丢失一些的所有情况 未来的读数（当新客户进来时，你永远不知道多久 他们将发送）。使用 timeuuid，如果由于某种原因设备，您甚至是安全的 将聚合多条消息以节省带宽。

如果我描述了第一个表，您会遇到的一个问题 是否知道所有device_id 可能会成为问题 用ETL检查它。我建议有一张桌子 成为单个客户的所有device_id 的列表。而且每次你 为您还写入此表的客户端配置传感器。那么当 您正在进行聚合，即在 spark 中您可以轻松地组合 device_id 使用cid 和event_date 隔离您需要的分区。你应该 始终避免 spark 遍历表中过于昂贵的所有条目 在我看来，这是限制数据遍历的一种方法。这确实有效 在我工作的一个项目上做得很好。

我现在将开始讨论问题 2，但也会提及问题 1。 问题是，通常我不建议再次保留原始数据。 这不会使数据管理变得更容易。我建议只使用 标准 cassandra 机制 TTL。基本上数据会在一段时间后消失 过期。根据我的经验，原始数据很少需要超过 几个月。

即在一个项目中，我们使用关系数据库来存储 ETL 之后的数据 之所以完成，是因为查询要简单得多，而且没有学习曲线 对于数据分析师。在 ETL 完成后，我们将数据保存在所谓的 星型模式。这对我们来说非常有效。

基本上，我建议您考虑如何聚合数据，然后 仅在 cassandra 中为报告制作额外的表格。这样你会 为自己节省大量处理时间。

您必须考虑的另一件事是传感器延迟。 有时由于连接问题，传感器甚至会离线数天。 所以你必须有某种策略来处理乱序数据 来到等。

简单的一种是忽略乱序数据。介于两者之间的是 开始 etl 工作之前的合理延迟。即开始处理数据几个小时 午夜之后，确保数据已输入，然后执行 ETL 前一整天。最复杂的是更新聚合的 ETL 发现不符合要求的东西然后重新处理后的数据，但我会 建议不要使用这个。

底线是我认为拥有额外的月表不会有好处 因为它将包含相同的数据并且访问模式不会是那样 不同。