cassandra - 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 Job列表：


需要单日运行客户端作业
需要单天运行客户端作业。 （应用允许过滤）
需要针对所有客户单个数据的特定作业
需要针对所有客户单个数据的特定作业


如果数据大小增加，作业将变慢。我们是否需要关注性能指标（cassandra / spark），还是将数据保留在不同的小表述中？

备份策略

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


卡桑德拉之路
https://docs.datastax.com/en/cassandra/2.1/cassandra/operations/ops_backup_restore_c.html
磁盘的外部数据源类型，如csv / flat文件等。

Answer 1

据我所知，您似乎还可以关于模式。
如果将来您可能会收到毫秒级的消息
您可能想要划分的级别甚至比一天中的级别还要低
你现在有。

但是日子可能还可以因为传感器很少
在不到几秒钟的时间内发送数据。我什至在一个项目上工作
我们按月分区，数据以秒为单位
这没什么大不了的。因此，从模式看齐
好。

模式似乎也涵盖了Spark作业。


可以，因为您一天可以获取所有数据而无需
太多麻烦了
我会避免应用过滤，特别是如果您每天有10 GB
随着时间的流逝只会变得更糟。如果您提供一些详细信息
关于为什么需要过滤的问题，我可能会帮忙。我的诚实建议是
避免所有这一切。
这需要您遍历日期分区。我猜
我最好的建议就是每天简单地回到历史。和
您需要一个聪明的终止条件。固定所有
客户（例如，不要过去超过x个月）。要么
您可以使其变得更智能，即当您进入客户的“所有”历史记录时
假设10天的桶都空了，您就停下来了。但这可能
棘手的是某些客户的停机时间更长。无论如何，你应该
这是可配置的。
这可能是一个很好的答案，但是如果您已经在使用spark
应该不是问题。


使用cassandra最好先准备好数据。所以你
模式可以正常工作1和2，你很好。 3也可以，但4是
总是有点棘手。通过设计是否每天将10 GB添加到集合中
而您想处理所有这些，则每个过程都将花费越来越长的时间
天。如果您需要所有数据，实际上没有什么可以做的。

通常在这种情况下，您会进行某种已经
假设您需要特定时间单位的总和和平均信息。
也就是说，如果您的报告是一整天的报告，那么您可以在cassandra中输入新内容
那天并存储结果。这样，您就不必重新处理它
每次都再次。因此，您的问题不是多个较小的表，而是
设计ETL操作的方式。

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

其他问题后更新答案：

问题1：如何每天获取每月都会被截断的数据

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)

这个想法本身并没有那么糟糕，但是我有几个担忧。第一
就是您会将一个客户端一天的所有数据放入单个分区。
根据获得的客户数量，这可能会变得太大。
通常，在IOT中，您希望将来自单个传感器的数据保留在单个分区中。
然后将一些时间维度键添加到分区键。这使得进行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隔离所需的分区。你应该
始终避免在表中的所有条目上花费过多的火花，因为这太昂贵了
我认为这是限制数据遍历的一种方法。这确实有效
我完成的一个项目进展顺利。

我现在将开始讨论问题2，但还将涉及问题1。
事实是，通常我不建议再次保留原始数据。
这不会使数据管理容易得多。我建议只使用
标准的卡桑德拉机制TTL。基本上，时间到了之后数据就会消失
到期。根据我的经验，很少需要比以下时间更长的原始数据
几个月。

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

基本上，我建议您考虑如何汇总数据，然后
在cassandra中制作其他表格，仅用于报告。这样你会
为您节省大量的处理时间。

您还必须考虑的另一件事是传感器延迟。
有时由于连接问题，传感器甚至会离线使用数天。
因此，当数据发生故障时，您必须具有某种策略来处理乱序数据
来到etl。

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

最重要的是，我认为增加月份表将无济于事
因为它将包含相同的数据，访问模式不会是
不同。