如果您的归档文件很大，并且希望从中获取报告，则不能仅使用cassandra，因为它没有简单的方法来聚合数据。您将在相同的节点上配置hadoop和cassandra。
根据我的经验，如果您有大量的写操作（我们已经在备份系统的后端尝试过），那么归档（一次写入-多次读取）并不是cassandra的最佳用例。根据您的压缩策略，您将为此付出空间或iops的代价。添加的更改通过sstable层次结构进行传播，从而导致比原始更改多得多的写入。
不知道其他变量就不可能完整地回答您的问题：您要分配多少硬件（服务器、它们的ram/cpu/hdd/ssd）？每个“报告”条目的大小是多少？你每天有多少读写服务？您的存档存储现在有多大？

Cassandra也许可以。保留两个表、报表和报表存档。使用24小时零7年的ttl定义架构：

CREATE TABLE reports (
   ...
) WITH default_time_to_live = 86400;

CREATE TABLE reports_archive (
   ...
) WITH default_time_to_live = 86400 * 365 * 7;

使用新的时间窗口压缩策略（twcs）来最小化写放大。将报表元数据和报表二进制数据存储在单独的表中可能是有利的。
对于汇总分析，请使用spark和cassandra。您没有提到数据的大小，但粗略地说，每个cassandra节点1-3 tb就可以了。使用rf=3，您至少需要三个节点。