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职位列表：

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

如果数据大小增加工作变慢。我们是否需要关注绩效指标（cassandra / spark），或者我们是否应该将数据保持在不同的小数据中。

备用策略

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

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

Answer 1

据我所知，你似乎是o.k.谈到架构。如果将来您可能会收到毫秒级的消息您可能希望分区的级别甚至低于日级别你现在有。

但是一天可能是o.k.因为传感器很少以超过几秒的速度发送数据。我甚至参与过一个项目我们按月分区的地方，数据在几秒钟内完成这并不是什么大不了的事。所以从模式par你 o.k。

Spark架构似乎也涵盖了它。

没关系，因为你可以获得一天的所有数据太麻烦了
我会避免应用过滤，特别是如果你每天有10 GB 随着时间的推移，这只会变得更糟。如果您提供一些细节为什么你需要过滤我可能会帮助。我诚实的建议是一起避免这一切。
这个要求您迭代日期分区。我猜我最好的建议就是每天回到历史。和你需要智能终止条件。要么全部固定客户（即不要过去让我们说超过x个月）。要么你可以把它变得更聪明，即当你进入＆＃34;所有＆＃34;客户的历史让我们停下来说10天后水桶是空的。但这可能一些客户有更长的停电时间是棘手的。无论如何，你应该做这是可配置的。
这可能是一个很好的答案，但如果你已经使用了火花这个不应该是个问题。

使用cassandra只需预先准备好数据就可以了。所以你的架构工作o.k.对于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)

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

其次是如果您预期来自一个设备的两条消息可能会因为相同的问题进入系统，您可能会丢失数据。所以我愿意建议您使用timeuuid类型进行event_time。是的，这需要更多空间，但你可以安全地反对你可能会松散一些的场景未来的读数（当新客户进来时，你永远不会知道多久他们会发送）。使用timeuuid，如果出于某种原因，您甚至可以安全使用该设备将聚合多条消息以节省带宽。

如果我描述的话，你会对第一张表有一个问题如果你知道所有的device_id，你可能会遇到问题用ETL翻看它。我建议有一张桌子是单个客户端的所有device_id的列表。每次你为客户提供传感器，您也可以写入此表。然后呢你正在进行聚合，即在火花中你可以轻松地组合device_id 使用cid和event_date隔离您需要的分区。你应该总是避免火花越过表中过于昂贵的所有条目在我看来，这是限制数据遍历的一种方法。这真的很有效我工作的一个项目很好。

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

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

基本上我建议你考虑如何聚合数据然后在cassandra中创建额外的表格仅用于报告。那样你会的节省了大量的处理时间。

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

简单的一种方法是忽略乱序数据。介于两者之间的东西是在开始etl工作之前有合理的延迟。即开始处理几小时的数据在午夜之后，确保数据存在，然后进行ETL 整整一天。最复杂的是更新ETL聚合你发现订单之外的数据，然后重新处理，但我愿意建议不要使用它。

底线是我认为有额外的月份表不会有益因为它将包含相同的数据，访问模式不会那样不同。

没有SQL Shema设计/备份策略

1 个答案: