Cassandra海量时序数据表结构设计

前言:看到一篇老外写的讨论时序数据模型设计的博文,非常好,就试着翻译一下。Cassandra很适合存储时间序列数据。这里有个前提,数据模型要设计好,设计得好,轻轻松松处理TB级的数据,设计不好你会很痛苦。(原文链接:http://thelastpickle.com/blog/2017/08/02/time-series-data-modeling-massive-scale.html)

理解数据写入量级对集群的影响,是使用Cassandra进行时序数据处理的挑战之一。单一分区的快速写入将产生热点问题,进而影响到集群伸缩性。大分区影响repair、streaming和读性能。从一个大分区读取数据,将极大增加系统负载,并造成GC压力。Cassandra 4.0能改善大分区的性能,但是不能完全解决上述问题。未来很长时间内我们必须考虑大分区性能问题,并早做计划。

这篇博文里,我们将讨论一个称作“桶”的通用的Cassandra数据模型设计技巧。桶是一个很有效的策略,能帮助我们控制分区大小,并将写请求分散到集群各个节点。这里介绍两种桶。这两种桶可以组合使用,以实现更进一步的伸缩性。假设读者已具备分区的基本概念,并了解基本的CQL指令。

先看一个简单的数据模型设计例子:

CREATE TABLE raw_data (
    sensor text,
    ts timeuuid,
    readint int,
    primary key(sensor, ts)
) WITH CLUSTERING ORDER BY (ts DESC) 
  AND compaction = {'class': 'TimeWindowCompactionStrategy', 
                    'compaction_window_size': 1, 
                    'compaction_window_unit': 'DAYS'};

这个数据模型只保存简单的传感器数据。实际中我们采集的数据远远比一个整数复杂,但是这里我们只关注键设计。这里使用TWCS作为压紧策略(compaction strategy)。TWCS能帮助我们降低压紧(compact)大分区的负载,使CPU和I/O可控。但是光有TWCS还不够,如果不使用TTL,日积月累,分区会越来越大。大分区在repairing、streaming和读取数据时,会造成系统的极大负载。

为了打破大分区,首先看看第一种桶。我们基于时间片将大分区划分成小分区。理想情况下,分区大小应不要超过100MB。举例来说,如果单个传感器每天的数据在50MB-75MB之间,那么可以按传感器按天进行分区,就是一个传感器一天一个分区。当然只要分区大小不超过100MB,也可以按周、按月、按年进行分区。不管怎么分,为未来业务增长预留点空间。

下面修改数据模型,增加一个字段day,并修改分区键:

CREATE TABLE raw_data_by_day (
sensor text,
day text,
ts timeuuid,
reading int,
primary key((sensor, day), ts)
) WITH CLUSTERING ORDER BY (ts DESC) 
       AND COMPACTION = {'class': 'TimeWindowCompactionStrategy', 
                     'compaction_window_unit': 'DAYS', 
                     'compaction_window_size': 1};

下面是插入数据(这里使用now(),也可由应用产生TimeUUID):

INSERT INTO raw_data_by_day (sensor, day, ts, reading) 
VALUES ('mysensor', '2017-01-01', now(), 10);

这是限制分区大小的一种方式。如果要获取多天的数据,就要按天发起读请求,每天一个读请求,最后由应用将返回数据合并。这种获取方式的好处是,请求被分散到集群的各个节点,而不是单一的一个节点。我们也可以依赖客户端驱动发起并行请求。Python甚至提供了一个简便的函数帮助实现这种并发请求。下面是Python示例:

from itertools import product
from cassandra.concurrent import execute_concurrent_with_args

days = ["2017-07-01", "2017-07-12", "2017-07-03"]  # collecting three days worth of data
session  = Cluster(["127.0.0.1"]).connect("blog")
prepared = session.prepare("SELECT day, ts, reading FROM raw_data_by_day WHERE sensor = ? and day = ?")

args = product(["mysensor"], days) 
# args: ('test', '2017-07-01'), ('test', '2017-07-12'), ('test', '2017-07-03')

# driver handles concurrency for you
results = execute_concurrent_with_args(session, prepared, args)

# Results:
#[ExecutionResult(success=True, result_or_exc=),
# ExecutionResult(success=True, result_or_exc=),
# ExecutionResult(success=True, result_or_exc=)]

这个方案的一个变例,是为每个时间片创建一张表。比如一个月一张表,那么一年就有12张表:

CREATE TABLE raw_data_may_2017 (
    sensor text,
    ts timeuuid,
    reading int,
    primary key(sensor, ts)
) WITH COMPACTION = {'class': 'TimeWindowCompactionStrategy', 
                     'compaction_window_unit': 'DAYS', 
                     'compaction_window_size': 1};

这个方案的一个主要优点是便于归档,以及快速删除数据。比如,在每月的开始,我们可以把上个月的数据用parquet格式归档到HDFS或者S3(译者按:S3是AWS上的一种存储服务),这样可以充分利用便宜的存储实现数据分析功能。当Cassandra集群不再需要某些数据时,只要把表删除就完了,非常简单。你也许注意到,这个方案有些额外的运维工作,就是创建和删除表,所以当有归档的需求时,这个方案是合适的。也有其他归档的方法,因此这种形式的桶不是必须的。

上面的方案关注点在于避免一段较长的时间段内分区变得特别大。这个方案适用的业务场景是流量可预测的,并且变化很小。有可能遇到例外的情况,大部分分区比较正常,但是个别分区数据量特别大,以致超过单个节点的存储,或者某个分区流量瞬间变得很大,超出单个节点的处理能力。Twitter是个很好的例子,有些人拥有数千万的粉丝。程序需要对这些人使用不同的代码路径,以实现海量伸缩性。

另一种技巧是在任何时间点使用多分区方式,从而将数据分布到整个集群。好处是,我们可以用单个分区存储小数据,而使用多个分区处理大数据量的情况。

这个方案也有缺点,我们必须做好折衷。缺点是当读取数据时,我们必须使用聚合,这会带来额外的工作。另外让分页也很困难。我们需要实时监控分区的数据量,以便我们为每一块数据选择合适的分区数量。如果我们有太多的桶,结果我们读取一点点数据可能要访问很多分区。太少的桶,会导致大分区,进而造成压紧、repair、stream困难,并影响性能。

在下面的例子里,我们设想一个理想的模型,有人在一个像Twitter一样的社交网络里关注了很多人。大部分账户只用一个分区就能处理所有进来的消息。但是有人关注了数百万的账户。
声明:我并不知道Twitter怎么存储数据。这只是一个简单的例子用来讨论问题。

CREATE TABLE tweet_stream (
    account text,
    day text,
    bucket int,
    ts timeuuid,
    message text,
    primary key((account, day, bucket), ts)
) WITH CLUSTERING ORDER BY (ts DESC) 
         AND COMPACTION = {'class': 'TimeWindowCompactionStrategy', 
                       'compaction_window_unit': 'DAYS', 
                       'compaction_window_size': 1};

通过在分区键里增加bucket字段,我们扩展了前面的数据模型。现在一天可以进一步分成多个桶。当获取数据时,我们需要访问这些桶,并把数据聚合一起。我们插入一些数据演示一下:

cqlsh:blog> insert into tweet_stream (account, day, bucket, ts, message) VALUES ('jon_haddad', '2017-07-01', 0, now(), 'hi');
cqlsh:blog> insert into tweet_stream (account, day, bucket, ts, message) VALUES ('jon_haddad', '2017-07-01', 1, now(), 'hi2');
cqlsh:blog> insert into tweet_stream (account, day, bucket, ts, message) VALUES ('jon_haddad', '2017-07-01', 2, now(), 'hi3');
cqlsh:blog> insert into tweet_stream (account, day, bucket, ts, message) VALUES ('jon_haddad', '2017-07-01', 3, now(), 'hi4');

如果需要获取最新的消息,我们可以这样做:

from itertools import chain
from cassandra.util import unix_time_from_uuid1

prepared = session.prepare("SELECT ts, message FROM tweet_stream WHERE account = ? and day = ? and bucket = ? LIMIT 10")
# let's get 10 buckets 
partitions = range(10)
# [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]

args = product(["jon_haddad"], ["2017-07-01"], partitions)

result = execute_concurrent_with_args(session, prepared, args)

# [ExecutionResult(success=True, result_or_exc=),
#  ExecutionResult(success=True, result_or_exc=),
#  ExecutionResult(success=True, result_or_exc=),
#  ExecutionResult(success=True, result_or_exc=),
#  ExecutionResult(success=True, result_or_exc=),
#  ExecutionResult(success=True, result_or_exc=),
#  ExecutionResult(success=True, result_or_exc=),
#  ExecutionResult(success=True, result_or_exc=),
#  ExecutionResult(success=True, result_or_exc=),
#  ExecutionResult(success=True, result_or_exc=)]

results = [x.result_or_exc for x in result]

# append all the results together
data = chain(*results)
            
sorted_results = sorted(data, key=lambda x: unix_time_from_uuid1(x.ts), reverse=True)            

# newest stuff first
# [Row(ts=UUID('e1c59e60-7406-11e7-9458-897782c5d96c'), message=u'hi4'),
#  Row(ts=UUID('dd6ddd00-7406-11e7-9458-897782c5d96c'), message=u'hi3'),
#  Row(ts=UUID('d4422560-7406-11e7-9458-897782c5d96c'), message=u'hi2'),
#  Row(ts=UUID('d17dae30-7406-11e7-9458-897782c5d96c'), message=u'hi')]

这个例子仅仅使用LIMIT语句限制获取10条消息,懒惰的程序员把这些列表合并在一起,然后排序,然后就大功告成。如果要获取更多的数据,我们需要使用一个K-way合并算法。未来当我们对这个话题进一步阐释的时候,再做讨论。

现在你应该对如何在集群里分发数据和请求有了更好的理解。记住每个问题都是不同的,没有银弹。

你可能感兴趣的:(Cassandra海量时序数据表结构设计)